UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
1
EMC 6607
Sistemas Especialistas aplicados à Engenharia (3 créditos)
Objetivo
Apresentar os principais aspectos teóricos e práticos relacionados ao desenvolvimento de Sistemas Especialistas (SE), enfocando sua aplicação no contexto do Projeto de engenharia.
Ementa
Histórico sobre SE. Vantagens e desvantagens de SE. Componentes e ciclo de vida de um SE. Aspectos relativos à definição do domínio de conhecimento. Técnicas de aquisição e representação do conhecimento. Validação e verificação de SE. Utilização de ferramentas SHELL.
• Programa
1. Definições básicas relacionadas a SE. Distinção entre SE e Programas Convencionais. Crescimento da aplicação de SE. Definição e tipos de sistemas SHELL.
2. Viabilidade de SE para certos tipos de problemas. Estudo das características de SE atualmente utilizados em aplicações práticas. Identificação de áreas de projeto aplicáveis para SE.
3. Processo de desenvolvimento de SE - dificuldades mais comuns encontradas. Técnicas de representação do conhecimento. Definição do domínio de aplicação. Escolha da técnica mais apropriada. Seleção da ferramenta SHELL.
4. Questões Humanas relacionadas ao desenvolvimento de SE. Engenharia de conhecimento. Perfil do engenheiro de conhecimento. Questões éticas em SE.
5. Aquisição do conhecimento. Relacionamento com os especialistas do domínio. Diferentes perfis de especialistas. Aplicação de ferramentas computacionais. Protótipo inicial como instrumento para facilitar a aquisição.
6. Validação e Verificação de SE - Comparação com técnicas utilizadas em sistemas convencionais. Metodologia de validação. Casos práticos e procedimento recomendável.
7. Aplicação de ferramentas. Introdução à programação utilizando sistemas SHELL. Estrutura geral, formas de representação do conhecimento, desenvolvimento de exemplos.
Forma de apresentação do conteúdo.
• Aulas expositivas e práticas. • Demonstração de sistemas. • Utilização de recursos disponíveis na Internet.
Forma de Avaliação Trabalhos e apresentação de seminários ao longo da disciplina. Avaliação conceitual geral no final da disciplina.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
2
Bibliografia Básica
1. WATERMAN, D. A., A Guide to Expert Systems, Addison-Wesley Publ. Company, 1986.
2. DYM, C.L. and LEVITT, R.E..Knowledge-based Syst. in Eng., McGraw-Hill, 1991.
3. GIARRATANO, Joseph and RILEY, Gary, Expert Systems- Principles and
Programming, Second Edition, PWS Publishing Company, 1994.
4. GONZALEZ, Avelino J. and DANKEL, Douglas D., The Engineering of Knowledge-
Based Systems- Theory and Practice, Prentice-Hall, Inc., 1993.
5. RICH, E. and KNIGHT, K.. Artificial Intelligence, McGraw-Hill Book Company, 1991.
6. SILVA, Jonny C.. Expert System Prototype for Hydraulic System Design Focusing on Concurrent Engineering Aspects. Tese de Doutorado, Engenharia Mecânica da UFSC, março 1998.
7. ALVES, Guilherme D.. Sistema Especialista Protótipo para Diagnóstico de Falhas em um Sistema Hidráulico Naval. Dissertação de Mestrado em Engenharia Mecânica. Universidade Federal de Santa Catarina, Florianópolis, abril 2001.
8. NORDLANDER, Tomas E.. AI Surveying: Artificial Intelligence in Business, Dept. of Management Science and Statistics, De Monfort University, UK, September 2001.
9. GIARRATANO, Joseph C. CLIPS User´s Guide, Version 6.2- March 2002.
10. VINADÉ, Cesar Augusto do Canto. Sistematização do processo de projeto para confiabilidade e mantenabilidade aplicado a sistemas hidraulicos e implementação de um sistema especialita. Tese de Doutorado em Engenharia Mecânica, UFSC, abril 2003.
11. PASSOS, Alexandra dos. Desenvolvimento de Sistema Especialista aplicado à Assistência Técnica: Estudo de caso em uma organização fabricante de produtos de telecomunicações. Dissertação de Mestrado em Eng. Mecânica, UFSC, março 2005.
12. Starr, R. R.. Contribuições para a detecção de vazamentos em tubulações de gás natural: uma abordagem baseada em conhecimento. Dissertação de Mestrado em Eng. Mecânica, UFSC, julho 2006.
13. Mecabô, L. Desenvolvimento de um protótipo de sistema especialista para apoio à manutenção de turbocompressores de gás natural. Dissertação de Mestrado em Eng. Mecânica, UFSC, junho 2007.
Alguns websites de interesse CLIPS: A Tool for Building Expert Systems www.ghg.net/clips/CLIPS.html Aplicações de Sistemas Especialistas www.attar.com/pages/cases.htm AI Yahoo LINKS : www.yahoo.com/Science/Computer_Science/Artificial_Intelligence/ Artificial Intelligence History: www.aaai.org/AITopics/html/history.html
Página da disciplina: www.laship.ufsc.br/jonny/sist_esp/
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
3
Sumário 1. Introdução
• Definições básicas relacionadas a SE.
• Distinção entre SE e Programas Convencionais.
1.1. Origem dos Sistemas Especialistas 1.1.1. Distinção entre abordagem heurística e algorítmica
1.2. Algumas distinções entre SE e programas convencionais. 1.3. Diferentes perspectivas sobre SE 1.4. Vantagens relacionadas a Sistemas Especialistas 1.5. Elementos de um Sistema Especialista 1.6. Definições 1.7. Outras Definições 1.8. Típicas diferenças entre SE e programas convencionais
2. Crescimento da Aplicação de Sistemas Especialistas 3. Viabilidade de Sistemas Especialistas para certos tipos de problemas
3.1. Adequação da área de aplicação 3.2. Disponibilidade De Recursos
4. Processo de desenvolvimento de Sistemas Especialistas 4.1. Estágios gerais no desenvolvimento de Sistemas Especialistas 4.2. O problema da plataforma 4.3. Manutenção e evolução de SE 4.4. Possíveis erros no desenvolvimento de SE
5. A definição de Qualidade em Sistemas Especialistas 6. Ciclo de vida de um Sistema Especialista
6.1. Custos de Manutenção 6.2. Diferentes modelos de ciclo de vida
7. Definição do Domínio de Aplicação e Identificação das Fontes de Conhecimento 8. Projeto da Base de Conhecimento 9. Escolha da ferramenta de desenvolvimento
9.1. Questões quanto à escolha da ferramenta 9.2. Condições de suporte da ferramenta 9.3. Confiabilidade 9.4. Mantenabilidade 9.5. Características da tarefa
10. Escolha da equipe de desenvolvimento 10.1. Escolha do Engenheiro de Conhecimento 10.2. Desvantagens de ter um especialista como EC 10.3. Escolha do líder da equipe 10.4. Escolha do especialista
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
4
10.5. Critérios relativos à equipe 10.5.1. Sistemas pequenos
10.5.2. Sistemas de médio porte
10.5.3. Sistemas de grande porte
10.6. Problemas relativos à interação com especialistas 10.6.1. O Especialista Cínico 10.6.2. Especialista "sumo sacerdote" no domínio 10.6.3. O Especialista paternalista 10.6.4. O Especialista incomunicável 10.6.5. O Especialista descuidado
11. Estrutura do processo de aquisição do conhecimento 11.1. A entrevista inicial 11.2. Organização das sessões para aquisição do conhecimento 11.3. Sessões para definição de conhecimento genérico 11.4. Sessões para solução de problemas específicos
12. Organização Do Conhecimento 12.1. Técnicas observacionais 12.2. Técnicas intuitivas
13. Protótipo Inicial na aquisição do conhecimento 13.1. Impacto desta abordagem sobre o perfil do EC
14. Relação entre protótipo e sistema final 15. Verificação e Validação
15.1. Comparação de Verificação e Validação (V&V) com Programas Convencionais
15.2. Verificação 15.3. Validação
15.3.1. Metodologias de Validação
15.3.2. Testes de campo
15.3.3. Validação de subsistemas
15.3.4. Quando é apropriado validar?
16. Algumas observações sobre Orientação a Objetos 17. Incerteza
17.1. Redes Bayesianas 17.1.1. Vantagens e desvantagens das Redes Bayesianas
18. Lógica Difusa (Fuzzy Logic) 18.1. Definição de termos 18.2. Operadores difusos
ANEXO 1- Roteiro do 1o trabalho ANEXO 2- Roteiro do 2o trabalho
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
5
Proposta de Programa (número de aulas por tópico)
1.1 Introdução - apresentação do programa. Aspectos gerais da disciplina. 01
1.2 Definições básicas sobre SE. Distinção entre SE e Programas Convencionais. 01
1.3 Crescimento da aplicação de SE. Definição e tipos de sistemas SHELL. 01
2.1 Viabilidade de SE para certos tipos de problemas. 01
2.2 Estudo das características de SE atualmente utilizados em aplicações práticas. Identificação de áreas de projeto aplicáveis para SE.
02
3.1 Processo de desenvolvimento de SE - dificuldades mais comuns encontradas. 01
3.2 Técnicas de representação do conhecimento. Definição do domínio de aplicação. Escolha da técnica mais apropriada. Seleção da ferramenta SHELL.
03
4.1 Questões Humanas relacionadas ao desenvolvimento de SE. Engenharia de conhecimento. Perfil do engenheiro de conhecimento. Questões éticas em SE.
02
5.1 Aquisição do conhecimento. Relacionamento com os especialistas do domínio. Diferentes perfis de especialistas.
01
5.2 Aplicação de ferramentas computacionais. Protótipo inicial como instrumento para facilitar a aquisição.
01
6.1 Validação e Verificação de SE - Comparação com técnicas utilizadas em sistemas convencionais.
01
6.2 Metodologia de validação. Casos práticos e procedimento recomendável. 01
7.1 Aplicação de ferramentas. Introdução à programação utilizando sistemas SHELL. Estrutura geral e desenvolvimento de exemplos
05
7.2 Seminários de avaliação 02
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
6
1. Introdução
• Definições básicas relacionadas a SE.
• Distinção entre SE e Programas Convencionais.
1.1. Origem dos Sistemas Especialistas
No início dos anos 70, os pesquisadores em IA reconheceram que o conhecimento
genérico para solução de problemas e as técnicas de busca desenvolvidas na década anterior
eram insuficientes para resolver os problemas em fase de pesquisa e orientados a aplicações
da época. Eles concluíram:
O que era necessário era conhecimento específico sobre um domínio de
aplicaçãoparticular e limitado, em vez de conhecimento genérico aplicado a vários domínios.
Esta conclusão levou ao desenvolvimento de sistemas baseados em conhecimento ou
sistemas especialistas (SE). Desde sua origem, a área de sistemas especialistas tornou-se um
dos principais tópicos da IA.
De simples conceitos gerados em pesquisas esta área evoluiu para uma indústria de
milhões de dólares em aplicações práticas.
O conhecimento representado em SE é de especialistas de um domínio. Uma parte deste
conhecimento é composta de relações de causa e efeito. Estas relações ou regras práticas
(rules of thumb) originam-se da experiência dos especialistas e são comumente denominadas
heurísticas.
As heurísticas representam conhecimento informal, ou atalhos, que permitem um
especialista rapidamente pesquisar a solução de um problema sem ter que realizar uma
análise detalhada de uma situação particular, porque ou uma análise de um problema similar
já foi realizada, com êxito, anteriormente ou uma relação foi aprendida de uma tentativa mal
sucedida de um problema similar.
O especialista pode até nem se lembrar de todos os detalhes da análise anterior, mas
reconhece que se uma abordagem já funcionou a contento, a mesma abordagem irá
provavelmente se adequar a um problema similar em questão.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
7
Uma heurística frequentemente fornece uma solução correta para um problema.
Contudo, considerando que isto não representa uma análise exaustiva, pode ocasionalmente
fornece respostas incorretas ou mesmo falhar em prover qualquer resposta. Esta falha em ser
sempre bem sucedida é baseada na aplicação de uma escolha "aceitável" em vez de uma
resposta completamente certa.
Isto ocorre porque:
• Algumas vezes o número de possibilidades a serem examinadas pode ser muito
grande.
• Uma avaliação algorítmica aplicada a cada possibilidade para verificar se esta é uma
resposta correta e muito complexa, ou
• A avaliação algorítmica é desconhecida e deve ser aproximada.
Um especialista é uma pessoa que possui habilidades que lhe permite concluir a partir de
experiências e rapidamente focalizar no núcleo de um dado problema. Enquanto um não-
especialista pode abordar um problema de forma sistemática, empregando uma metodologia
orientada e procedural (caso esta realmente exista), esta abordagem pode ser muito
complicada e suscetível a erros ou ainda pode necessitar um esforço e tempo inaceitáveis.
Este uso cego de uma metodologia pode ser resultado de um entendimento limitado a respeito
do domínio de conhecimento e suas relações de causa e efeito.
Um especialista, por outro lado, tem um maior êxito na solução de problema, pois já
adquiriu um conjunto valioso de relações de causa e efeito com base em sua experiência.
Um especialista é capaz de usar este conhecimento básico para rapidamente reconhecer as
características relevantes de um problema, categorizá-lo de acordo com tais características e
corretamente definir uma solução.
1.1.1. Distinção entre abordagem heurística e algorítmica
Exemplo: Um potencial comprador de uma residência, com plano arquitetônico definido
deseja uma estimativa de custo antes de comprometer-se em fechar o contrato com um
construtor.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
8
Caso 1: Um certo construtor determinar o preço da obra após uma análise detalhada dos
custos.
Isto envolve calcular cuidadosamente a quantidade de material necessário para obra;
contatar um fornecedor de materiais para obter lista de preços; avaliar cotações de
empreiteiras sobre o custo de mão-de-obra; determinar as taxas de supervisão; permitir uma
adequada margem para contingências, etc. Este processo tem a vantagem de praticamente
garantir o resultado preciso (considerando inexistência de erros de cálculo) e implica em
muito pouco risco para o construtor. Todavia, a desvantagem é que isto envolve um
considerável esforço e tempo. O que acontece se o comprador precisa a cotação para hoje?
Caso 2: Um construtor especialista.
Um construtor especialista tem uma outra opção. Ele compara o tamanho desta casa
com outras que já tenha construído. Ao encontrar uma obra com aproximadamente a
mesma metragem, ele obtém uma estimativa inicial (baseada em experiência) do preço por
metro quadrado. Então analisa as diferenças entre as construções que podem aumentar ou
reduzir a estimativa. Tais diferenças podem incluir inclusões como uma piscina
(aumentando em cerca de $15 mil), simplificações nas instalações de cozinha (reduzindo em
$1,5 mil) ou exclusão do tipo menor número de banheiros (reduzindo em $6 mil). Após
avaliar tais diferenças, ele é capaz de realizar a estimativa em cerca de 30 minutos.
Obviamente, a vantagem é que o especialista pode fornecer uma rápida cotação. A
desvantagem é que existe a possibilidade que uma consideração mal feita torne a
estimativa inválida. Porém, se o indivíduo é um verdadeiro especialista, isto é improvável
que aconteça.
A primeira abordagem é algorítmica: completa, detalhada e altamente precisa, mas
possivelmente inadequada devido às limitações de tempo e esforço.
A segunda abordagem é heurística: não tão completa e detalhada, mas talvez o
bastante precisa e desenvolvida em função das limitações de tempo e recursos disponíveis.
Sendo assim, enquanto os resultados de procedimentos algorítmicos são sempre
precisos, são freqüentes os casos onde uma estimativa heurística com quase a mesma
precisão pode ser obtida com muito menos esforço. Porém apenas especialistas são capazes
de obtê-la e, às vezes, existe o risco de cometer erros.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
9
1.2. Algumas distinções entre SE e programas convencionais.
• A separação do conhecimento de um domínio específico de como ele é aplicado.
• Uso de conhecimento altamente específico.
• Aplicação de abordagem heurística, em vez de algorítmica, do conhecimento
empregado.
• Capacidade de explicar como as soluções foram obtidas.
• O conhecimento é apresentado de forma explícita.
1.3. Diferentes perspectivas sobre SE
Função Relacionamento
Gerente Para que posso usá-lo?
Programador Como posso melhor implementá-lo?
Pesquisador Como posso expandi-lo?
Usuário Como este sistema poderá me auxiliar?
Vale a pena as mudanças e o investimento para aquisição?
Quão confiável é o sistema?
1.4. Vantagens relacionadas a Sistemas Especialistas
• Aumento da disponibilidade do conhecimento - com este tipo de sistema a
experiência torna-se mais disponível.
• Redução do custo - o custo de acesso ao conhecimento por usuário é bastante
reduzido.
• Redução do risco - Sistemas Especialistas podem ser usados em ambientes perigosos
para o ser humano.
• Permanência - diferentemente de especialista humano (EH) que pode aposentar-se,
pedir demissão ou vir a falecer, o conhecimento armazenado em SE terá permanência.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
10
• Múltiplas especialidades - o conhecimento de múltiplos EH poderá estar disponível
para trabalhar simultaneamente e continuamente em um problema a qualquer tempo. Além
disto, o nível de conhecimento combinado de vários EH pode superar o de um único
especialista.
• Aumento da confiabilidade - SE podem aumentar a confiança que uma solução
correta foi tomada, pois fornecem uma segunda opinião para um especialista ou servem como
desempate no caso de múltiplos EH discordarem entre si. Certamente, isto não ocorrerá se o
sistema foi desenvolvido por um dos EH. Um SE sempre concordará com o especialista, a
menos que um erro tenha sido cometido pelo especialista (ou no desenvolvimento do
sistema). Erros podem ser cometidos por EH como conseqüência de cansaço ou sob estresse.
• Explicação - um SE pode (ou deve) explicitamente explicar em detalhes as razões que
levaram a uma conclusão, enquanto que um EH pode estar cansado, não desejar ou não ser
capaz de prover tal explicação todo o tempo. Esta característica de SE pode aumentar a
confiança na solução adotada.
• Resposta rápida - em algumas aplicações pode ser necessária uma resposta rápida ou
em tempo real. Dependendo do software e hardware utilizados, um SE pode responder mais
rapidamente e ser mais disponível que um EH.
• Resposta completa, * consistente e imparcial em todas as condições - Isto pode ser
muito importante em aplicações de tempo real e situações de emergência quando um operador
pode não operar na eficiência máxima devido a estresse ou fadiga.
• Tutor inteligente - um SE pode atuar como um tutor conduzido um estudante através
de certos problemas e explicando as razões da solução.
• Banco de dados inteligente - um SE pode ser usado para acessar um banco de dados
de uma forma mais inteligente.
• Alta performance - o sistema deve ser capaz de responder em um nível de
competência igual ou superior a um especialista do campo de conhecimento. Isto implica
dizer que a solução apresentada pelo sistema deve ser de alta qualidade.
O processo de desenvolver um SE tem também um benefício indireto, pois o
conhecimento dos EH deve ser formulado de forma explícita para ser modelado via
computador.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
11
Por que a capacidade de prover explicação é fundamental?
Uma das razões é que algo de grande valor pode depender das respostas do sistema.
Devido ao seu grande potencial de causar dano, um SE deve ser capaz de justificar sua
resposta de forma semelhante a um EH.
A capacidade de explicação é importante também na fase de desenvolvimento do
sistema para confirmar se o conhecimento foi corretamente adquirido e modelado no sistema.
Tal aspecto é fundamental no debugging do sistema, pois pode prevenir erros de sintaxe ou
conceitos mal entendidos entre o Engenheiro de Conhecimento (EC) e o EH. Outra razão é o
fato de que devido à forma como um típico SE é desenvolvido é muito difícil entender seu
funcionamento através da leitura da listagem. Pois, o fluxo de execução não é seqüencial.
1.5. Elementos de um Sistema Especialista
1.6. Definições
• Interface com o usuário - mecanismo de comunicação entre usuário e o SE.
• Módulo de explicação - esclarece as razões encontradas pelo SE.
• Memória operacional - um "banco de dados" de fatos usados pelas regras.
MÁQUINA DE INFERÊNCIA
AGENDA
BASE DE
CONHECIMENTO
(REGRAS)
MEMÓRIA
OPERACIONAL
(FATOS)
HABILIDADE DE
EXPLICAÇÃO
HABILIDADE DE AQUISIÇÃO DE
CONHECIMENTO
INTERFACE COM O USUÁRIO
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
12
• Máquina de Inferência - mecanismo que decide quais regras são satisfeitas, prioriza
as regras satisfeitas e executa a regra de maior prioridade.
• Agenda - uma lista das regras priorizadas pela Máquina de Inferência, cujas condições
são satisfeitas pelos fatos ou objetos na memória operacional.
• Módulo de aquisição - propicia ao usuário uma forma automática para inserir
conhecimento no sistema, sem necessitar codificação por parte do EC.
O módulo de aquisição é um atributo adicional em muitos sistemas. Algumas
ferramentas de desenvolvimento (SHELL) oferecem um mecanismo para indução de regras.
Contudo, a maioria dos exemplos que permitem indução é baseado em conhecimento advindo
de uma forma relativamente simples e bem classificada.
• Algumas comparações - Dos modelos propostos pela teoria cognitiva de Newel e
Simon (base dos sistemas especialistas)
• A Memória Operacional - atua como memória de curto prazo, uma vez que é usada
para armazenamento temporário de conhecimento (fatos) durante a solução de um problema.
• A Base de Conhecimento (regras) - representa uma memória de longo prazo, onde o
conhecimento permanente é armazenado.
Uma REGRA corresponde a uma pequena e modular parte do conhecimento (chunk).
Na solução de problemas, um especialista humano organiza partes do conhecimento de
forma flexível através de conexões com outras partes. Embora a memória de longo prazo
possa armazenar centenas de milhares destas partes, a capacidade da memória de curto prazo
é muito pequena. Isto pode ser exemplificado da seguinte forma:
A maioria dos seres humanos consegue visualizar mentalmente apenas em torno de 4 a
7 números ao mesmo tempo. Certamente, conhecemos mais do que esta quantidade, que na
verdade está armazenada na memória de longo prazo.
Na busca de uma solução, uma parte do conhecimento é ativada (ou estimulada) e
desencadeia a ativação de outras partes. Para que tal processo ocorra, é necessário a
existência de um processador cognitivo que tenta determinar que REGRAS serão ativadas
por um conjunto determinados de estímulos (FATOS).
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
13
• A Máquina de Inferência - corresponde ao processador cognitivo.
Funções da Máquina de Inferência
• Selecionar que regras são ativadas
• Priorizar as regras selecionadas
• Ativar ou disparar as regras selecionadas na prioridade selecionada
• Processar a "refração" das regras disparadas
(Analogia com o neurônio)
1.7. Outras Definições
• Engenharia de Conhecimento - processo de desenvolvimento de um SE
• Engenheiro de Conhecimento - responsável por desenvolver um SE
• SHELL - ferramenta computacional para implementação de um SE.
• Usuário - pode ser o usuário final (sem conhecimento do domínio), o engenheiro de
conhecimento ou o próprio especialista do domínio.
1.8. Típicas diferenças entre SE e programas convencionais
Característica Programa Convencional Sistema Especialista
Controle Declaração explícita Máquina de Inferência
Controle e dados Integração implícita Separação Explícita
Solução via Algoritmo Regras e inferência
Resolução Algorítmica correta Regras
Entrada de dados Assumida correta Incompleta, incorreta.
Entrada imprevista Dificuldade para manipular Muito adequado
Saída Sempre correta Varia com o problema
Explicação Nenhuma Geralmente
Aplicações Numérica, arquivos e texto Manipulação simbólica
Execução Geralmente seqüencial Regras mais apropriadas
Projeto do sistema Estruturado Pouco ou nenhum
Facilidade de mudança Difícil Razoável
Expansão Feita em saltos Incremental
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
14
2. Crescimento da Aplicação de Sistemas Especialistas
Desde o início da década de 70 (quando o paradigma de SE foi estabelecido) vários
sistemas já foram desenvolvidos, aqui estão alguns exemplos:
SISTEMA FUNÇÃO
MYCIN (76) Diagnóstico de doenças baseada em amostra de sangue e especificação de tratamento para infecção. Desenvolvido pela Universidade de STANFORD.
XCON/R1 (82) Configuração de sistemas computacionais
Obs.: Desenvolvido pela Digital Equipament Corporation (DEC) em parceria com a Universidade de Carnegie Mellon, com sua aplicação, a DEC já economizou milhões de dólares por ano.
PROSPECTOR
(78)
Análise geológica de dados para prospecção de minerais
Obs.: Através PROSPECTOR foi descoberta uma jazida valendo $100 milhões.
ISIS (84) Geração de planos de alocação de mão-de-obra para chão de fábrica. Desenvolvido pela parceria da Universidade de Carnegie Mellon e Westinghouse Electric Corporation.
GENAID (86) Monitoramento e diagnóstico de condições operacionais de grande geradores em tempo real. Desenvolvido pela Westinghouse Electric Corporation com suporte da Texas Utilities e da Universidade de Carnegie-Mellon
LES (87) Monitoramento e diagnóstico do processo de abastecimento de oxigênio líquido em tanque de naves espaciais. Desenvolvido por MITRE Corporation e NASA-KSC (Kennedy Space Center)
PTRANS (83) Suporte ao controle da manufatura e distribuição da DEC. Desenvolvimento conjunto entre DEC e Universidade de Carnegie-Mellon.
DENDRAL Interpretação espectrogramas de massa para identificar os elementos químicos.
DELTA (83) Diagnóstico / conserto de locomotivas GE. Desenvolvido pela General Electric e atualmente encontra-se em uso nesta empresa.
INTERNIST
(82)
Suporte ao médico no processo de diagnose de infecções de hospitalares. Desenvolvido pela Universidade de Pittsburgh.
REACTOR Diagnóstico / conserto de acidentes em reatores
STEAMER
(84)
Instrução de operação de máquinas a vapor. Desenvolvido pela Marinha Americana em colaboração com a BBN Corporation.
CADHELP Instrução para CAD
SOPHIE Instrução para diagnóstico de falhas em circuitos eletrônicos
DIPMETER Análise geológica de dados para prospecção de petróleo.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
15
http://www.osha.gov/oshasoft/
OSHA - Organization of Safety and Health Administration, US Department of Labor -
Desenvolveu alguns Sistemas Especialistas (com versões demo) para aplicações industriais.
Exemplos:
• HAZARD AWARENESS ADVISOR - um sistema especialista para identificar os
riscos nos ambientes industriais. O sistema apresenta um relatório com as recomendações da
OSHA.
• $AFETY PAYS - uma ferramenta para auxiliar empregadores na análise do impacto
financeiro com doenças ou acidentes ocupacionais que causam dias fora do trabalho.
• Lead Construction Advisor - fornece regras gerais e orientação sobre procedimentos
ligados à exposição o chumbo em construções.
• Fire Safety Advisor - apresenta as normas gerais da OSHA para segurança contra
incêndio, emergências e sistemas de detecção de incêndio.
• Asbestos Advisor 2.0 - sistema dedicado a proprietários, gerentes e locatários de
prédios. Após uma entrevista o sistema apresenta um relatório sobre regras quanto à
exposição ao asbesto.
• Confined Spaces Advisor 2.0 - o sistema auxilia na definição quanto à identificação e
permissão relativa às tarefas em espaços confinados.
3. Viabilidade de Sistemas Especialistas para certos tipos de problemas
Selecionar a aplicação correta com base numa razão correta pode acarretar numa positiva
influência no sucesso final do projeto. Enquanto selecionar mesmo uma aplicação certa por
uma razão não adequada pode não ser tão satisfatório.
Os critérios para analisar a viabilidade de SE consistem em vários fatores que podem ser
agrupados em duas categorias:
• Adequação da área de aplicação
• Disponibilidade de recursos
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
16
A seguir são apresentadas algumas orientações sobre cada uma destas categorias. Nem
todas estas orientações devem ser necessariamente seguidas, mas a grande maioria delas deve
ser considerada.
3.1. Adequação da área de aplicação
Muitas falhas de projetos envolvendo SE podem ser atribuídas a uma definição
inapropriada da aplicação. Algumas questões a considerar: O problema realmente existe? A
técnica de SE é aplicável? A abordagem de SE é realmente justificável?...
• O problema realmente existe?
Esta é a primeira questão a ser considerada. O risco de desenvolver um projeto para um
problema que realmente não existe é que a solução não terá real impacto na operação da
organização. Desta forma o interesse nesta tecnologia pode diminuir ou até desaparecer antes
que aplicações de real valor sejam reconhecidas. Além disto, tal aspecto pode ser
erroneamente tomada por alguns como justificativa para indicar uma falha da tecnologia.
Contra-exemplo: O problema de visitantes numa fábrica de equipamentos de combate a
incêndio. Uma solução em busca de um problema, e não um problema real para o qual deve-
se desenvolver uma solução.
A verdadeira questão a ser considerada é se um sistema especialista proposto representa
um valor considerável para a organização. Considerável valor não necessariamente significa
econômico, mas pode envolver, por exemplo, prestígio ou imagem da empresa.
Quanto maior o valor mais a organização estará disposta a se empenhar no
desenvolvimento do sistema.
• A técnica de SE é aplicável?
Para auxiliarem neste aspecto, certas sub-questões são postas, a busca destas razões
representa em si um processo inexato, e por tanto heurístico.
• O tipo de problema reproduz o conhecimento humano na busca de solução?
Uma resposta positiva implica que SE pode ser a solução adequada, enquanto uma
resposta contrária não necessariamente numa má aplicação.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
17
• O tipo de problema é heurístico em sua natureza ou é predominantemente
algorítmico?
Nenhuma tarefa é apenas de uma forma, a maioria dos problemas no mundo real contem
ambos elementos.
A chave é qual é a forma predominante.
• O conhecimento ou especialização muda periodicamente ou permanece
constante?
Se o conhecimento muda freqüentemente o tipo de problema é aplicável para SE devido
à sua facilidade inerente em incorporar mudanças.Isto também pode justificar a aplicação de
SE para problemas predominantemente algorítmicos, mas cujas regras mudam
freqüentemente.
• Se experiência é envolvida, ela é relativamente bem entendida e aceita?
Se são difíceis de desenvolver para domínios que não são bem desenvolvidos.
Exemplo: é relativamente simples identificar, organizar e representar a experiência de
como diagnosticar um problema num automóvel, mas bem mais difícil fazer o mesmo com
relação a interpretar sinais de rádio de ondas extra-terrestes ou astrologia. Por outro lado, se a
experiência pode ser adequadamente reduzida a fórmulas e modelos matemáticos então
programas convencionais podem ser mais adequados.
• As entradas do problema são sempre corretas e completas?
Se a resposta é não então SE podem apresentar uma vantagem distintiva.
• O problema pode ser resolvido por outros meios?
Embora SE ofereçam excelentes características para resolver algum tipo de problema,
estas características poderão não ser necessárias para outros. Em certos casos, a melhor
solução pode não ser computacional. Exemplo: um simples mapa pode ser a solução no caso
do contra-exemplo.
• O problema passa o teste do telefone?
Este teste questiona se um especialista, através apenas de uma conversação por telefone,
pode apresentar suficiente solução para permiti-lo a resolver um problema. Este teste não
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
18
deve ser tomado ao pé da letra. O teste é um meio de classificar o tipo de conhecimento que é
necessário para resolver o problema. Ele certifica que o tipo de conhecimento não é de
natureza visual, auditiva ou táctil. Embora uma limitada porção deste tipo de conhecimento
pode ser manipulada por um SE caso a informação seja claramente categorizada e organizada,
uma predominância deste tipo de conhecimento pode tornar o desenvolvimento de um SE
extremamente difícil.
• A abordagem via SE é justificável?
O custo de desenvolver um SE é geralmente bem superior ao de programas
convencionais. Por várias razões, primeiro é necessário recursos (software e "hardware")
apropriados. Além disto, há a necessidade de pessoal especializado, tais pessoas são difíceis
de encontrar, implicam em alto custo e/ou difíceis de treinar. Sendo assim, a solução via SE
deve ser avaliada de acordo com a relação custo/benefício como qualquer outro projeto.
3.2. Disponibilidade de Recursos
Mesmo que um problema específico possa satisfazer todos os critérios anteriores, ainda
assim pode não se tornar uma implementação bem-sucedida. Alguns fatores podem
comprometer o projeto.
Primeiro, o engenheiro de conhecimento deve ser altamente capacitado.
Em segundo lugar, como tais projetos não existem isoladamente eles estão sujeitos a
algumas restrições geralmente encontradas em governo, indústrias, e organizações acadêmicas
que afetam o desenvolvimento de projetos. Sendo assim, as próximas questões devem ser
consideradas muito cuidadosamente.
• Existe apoio gerencial para o projeto?
A menos que o desenvolvedor seja proprietário da empresa ou tenha um excelente
relacionamento com a direção (CEO), sempre haverá conflitos com a gerência. O apoio da
gerência não garante o sucesso do projeto, mas a falta dele implica quase que certamente em
sua falha. Tal apoio pode se apresentar de várias formas, todas essenciais à implementação
bem sucedida do projeto.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
19
• Disponibilidade de tempo
Isto é a primeira e a mais importante forma de apoio. Existem excelentes aplicações que
nunca decolaram devido à falta de tempo do engenheiro de conhecimento.
A gerência deve ser bastante consciente da natureza de trabalho intensivo em
desenvolver um SE. Além disto, a equipe de engenharia de conhecimento deve considerar o
desenvolvimento sua maior prioridade.
• Ferramentas e treinamento
A escolha das ferramentas de desenvolvimento pode ser geralmente restrita por
parâmetros fora do controle direto da gerência.
O treinamento pode variar de alocar tempo ao engenheiro de conhecimento para estudar
materiais sobre a ferramenta até providenciar cursos específicos sobre a ferramenta.
• Disponibilidade do Especialista
Neste aspecto, dois problemas podem ocorrer.
• Os especialistas do domínio, devido à sua especialidade em uma área, podem ser
altamente requisitados. Neste sentido, sua disponibilidade pode ser muito limitada.
• Em algumas organizações o especialista e o EC podem pertencer a diferentes
unidades. Neste caso, a gerência deve ser um nível suficientemente alto para abranger as duas
unidades.
• Existe apoio da parte do Especialista?
O especialista cooperativo que está estimulado pela idéia de ver seu conhecimento
reproduzido é ideal. Todavia, em si, este conceito pode parecer uma ameaça à segurança do
especialista, acarretando o fato dele não se mostrar cooperativo.
• O Especialista é competente?
Em muitos casos o EC não é capaz de julgar se o especialista é competente, devido à sua
falta (do EC) de conhecimento sobre o domínio. Além disto, isto pode ser delicado para
questionar. Contudo, é fundamental para o sucesso do projeto que o especialista seja
verdadeiramente especialista no domínio.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
20
A decisão mais importante que o EC deve tomar é se assegurar que existe mais de uma
fonte de conhecimento disponível. Seria ideal ter dois ou três especialistas comprometidos
com o projeto. Todavia, nesta abordagem existe um risco, ou seja, o principal especialista
pode considerar isto uma ofensa.
• O Especialista é bem articulado?
Isto implica dizer que o especialista deve ser articulado para transmitir não apenas
"conhecimento dos livros" mas também, e mais importante, sua própria experiência.
O especialista altamente qualificado no problema que afirma: "a solução é tão óbvia, que
qualquer idiota pode ver" ou "não posso explicar porque esta é a solução apenas que ela é",
não de grande assistência.
Neste sentido, o especialista deve ser capaz de verbalizar o processo aplicado para
resolver um problema e propor uma solução. O EC dispõe de várias técnicas para "extrair"
este conhecimento, as quais serão apresentadas posteriormente.
• "O Especialista está fisicamente próximo?"
A distância pode limitar o acesso do EC ao especialista, o que pode retardar o processo
de desenvolvimento. Embora um especialista cooperativo pode superar tal deficiência.
4. Processo de desenvolvimento de Sistemas Especialistas
Como em qualquer projeto, o desenvolvimento de um SE depende dos recursos
disponíveis bem como de como o processo é organizado e gerenciado.
O gerenciamento do projeto deve englobar:
Gerenciamento da Atividade (processo)
Planejamento - Definir atividades
• especificar prioridades das atividades
• recursos
• principais eventos (milestones)
• duração
• responsabilidades
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
21
Cronograma - Definir datas de início e término
• resolver conflitos no encaminhamento de atividades de igual prioridade
• monitorar o desenvolvimento
• análise de planos, prazos e atividades
Gerenciamento do Produto
• organizar as diferentes versões do produto
• gerenciar propostas de mudança e avaliações do impacto
• definir pessoal para executar as modificações
• instalar novas versões do produto
Gerenciamento dos recursos
• prever necessidade de recursos
• aquisição de recursos
• definir responsabilidades para otimizar o uso dos recursos
• prover recursos críticos para minimizar gargalos
4.1. Estágios gerais no desenvolvimento de Sistemas Especialistas
• Estudo de Viabilidade
• Protótipo Rápido (Inicial) - um SE rapidamente desenvolvido para demonstrar idéias,
despertar entusiasmo e impressionar o alto nível de gerência.
• Sistema Refinado (αααα- teste) - Verificação interna do sistema em problemas reais,
executada pelos EC e EH
• Teste de Campo (ββββ- teste) - sistema testado por usuários selecionados (não EC ou
EH)
• Sistema comercial - validado e testado. Documentação do usuário, treinamento e
rápido apoio ao usuário via telefone ou e-mail.
• Manutenção ou evolução - corrigir bugs e ampliar as capacidades.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
22
4.2. O problema da plataforma
Dependendo do número de sistemas a serem fornecidos (amplitude do mercado), o
problema de "para qual plataforma o SE será desenvolvido?" Pode ser um importante fator
no desenvolvimento, o qual deve ser considerado nos estágios iniciais do processo.
De uma forma ideal, os SE devem ser capazes de operar num hardware padrão. Todavia,
muitos sistemas desenvolvidos em LISP necessitam de microprocessador especial, que
aumenta substancialmente o custo. Deve também ser prevista a comunicação do SE com
outros programas.
4.3. Manutenção e evolução de SE
Neste contexto, estas atividades são tarefas com fim menos definido (open-ended
activity) que no caso de programas convencionais. Devido ao fato de SE não serem baseados
em algoritmos, seu desempenho depende do conhecimento. Sendo assim, a medida que um
novo conhecimento é adquirido e o antigo modificado, o desempenho do sistema melhora.
No aspecto comercial, os desenvolvedores de SE devem estar atentos aos desejos dos
usuários, também no aspecto de melhoramento. A identificação e correção de bugs deve ser
uma alta prioridade.
Num sentido bem real, um sistema especialista comercial pode nunca realmente ser
concluído, ele apenas melhora.
4.4. Possíveis erros no desenvolvimento de SE
• Erros no conhecimento do especialista - como o especialista é a fonte de
conhecimento, seus erros podem se propagar através de todo o processo. A detecção destes
erros pode ocorrer quando o conhecimento é explicitado. Para projetos de missão crítica, onde
vidas humanas ou propriedades estão em risco, deve ser necessário definir procedimentos
formais (com um painel de especialistas e gerentes) para certificar o conhecimento do
especialista.
• Erros de semântica - erros deste tipo ocorrem quando o significado do conhecimento
não é apropriadamente comunicado. Como exemplo, suponha que o especialista diga "você
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
23
pode extinguir um incêndio com água" e o engenheiro de conhecimento interprete "todo
incêndio pode ser extinto com água". O erro de semântica pode ocorrer se o EC interpretar
erroneamente as respostas do EH, ou o EH interpretar erroneamente as perguntas do EC, ou
ambos.
• Erros de sintaxe - estes são erros simples, correspondem a formas incorretas de
definir regras, fatos, etc... As ferramentas de desenvolvimento devem apontar tais erros.
• Erros na máquina de inferência - alguns bugs devem aparecer apenas em
circunstâncias especiais (por exemplo, ordenamento de condicionais em uma regra), tais bugs
devem ser difíceis de detectar. A maioria dos sistemas tem uma lista de usuários, e bugs já
consertados, esta experiência deve ser a principal fonte para solucionar este tipo de erro.
• Erros na cadeia de inferência - este tipo pode ser causado por uma combinação dos
tipos anteriores e mais uma incorreta especificação do encadeamento de regras ou uma má
interação entre regras.
Outras possibilidades são propagação de incerteza nas regras e não-monotonicidade.
No processo de busca de uma solução um especialista humano usa certas hipóteses que
posteriormente são provadas falsas, sendo assim as conclusões tomadas com base nestas
hipóteses devem ser reconsideradas. Sendo assim, sistemas que admitem não-
monotonicidade devem ser capazes de modelar tal propriedade.
• Erros devidos aos limites de ignorância - como os especialistas humanos conhecem
a extensão de seu conhecimento, seu desempenho gradativamente (espera-se) decresce a
medida que se aproximam deste limite. Tal característica deve ser prevista em SE.
5. A definição de Qualidade em Sistemas Especialistas
Qualidade é um termo difícil de descrever num sentido geral porque significa coisas
diferentes para pessoas diferentes. Uma forma de definir qualidade é um conjunto dos
atributos desejáveis de um objeto em uma determinada escala. Os atributos e seus valores são
chamados métricas.
Por exemplo, a confiabilidade de um dispositivo é uma métrica de sua qualidade, uma
medida deste atributo é o MTBF (Mean Time Between Failures).
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
24
A lista a seguir fornece algumas métricas relativas à qualidade de SE
• Saídas corretas para entradas corretas
• Saídas completas para entradas corretas
• Saída consistente para a mesma entrada
• Confiável, ou seja, o sistema não deve abortar (com freqüência) devido a bugs.
• Utilizável e preferencialmente amigável ao usuário
• De fácil manutenção, de fácil melhoramento
• Validado, comprovado que satisfaz as necessidades do usuário
• Viável economicamente
• Código re-aproveitável para outras aplicações
• Compatível com outros ambientes (hardware/software)
• Permite interface com outros softwares
• Código compreensível. Sistema preciso
• Gradativa queda de desempenho na fronteira do conhecimento
• Base de conhecimento verificável
• Facilidade de explicação
Uma lista de métricas permite mais facilmente priorizá-las, pois pode ser que haja
conflitos entre as métricas. Por exemplo, aumentar a fase de testes de um sistema para
assegurar sua precisão aumentará também o custo. Decidir quando os testes devem terminar
envolve vários fatores como cronograma, custo e requisitos. De forma ideal, todos estes
fatores devem ser satisfeitos. Na prática, alguns serão mais importantes.
6. Ciclo de vida de um Sistema Especialista
O conceito do ciclo de vida fornece uma continuidade que conecta todos os estágios do
desenvolvimento. O planejamento para manutenção e evolução nas primeiras fases do ciclo de
vida reduz os custos nos estágios posteriores.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
25
6.1. Custos de Manutenção
Para sistemas convencionais, a manutenção tipicamente responde por cerca de 60 a 80
% dos custos e é geralmente de duas a quatro vezes o custo do desenvolvimento original.
Embora haja limitada informação deste tipo para SE, pelo fato de ser uma tecnologia
nova, os dados devem ser provavelmente piores.
Sistemas Especialistas que executam bastante inferência com base em incertezas são
mais suscetíveis a maiores custos de manutenção e evolução.
6.2. Diferentes modelos de ciclo de vida
• Modelo cachoeira (waterfall) - muito familiar entre programadores de sistemas
convencionais. Neste modelo, cada estágio termina com uma verificação e validação para
minimizar qualquer problema naquele estágio. (Apresentar figura e discutir)
• Modelo codificar-&-corrigir - mais comum entre programadores iniciantes. Neste
caso, uma certa parte do código é implementada e então consertada quando não funciona
adequadamente. As deficiências deste "modelo" levaram ao desenvolvimento de outros.
• Modelo incremental - este modelo é um refinamento do waterfall. A idéia básica é
desenvolver o sistema com base em incrementos de sua funcionalidade.
O modelo incremental foi usado com sucesso no desenvolvimento de grandes programas
convencionais. Este modelo é também aplicável a sistemas especialistas onde o incremento de
regras amplia as capacidades do sistema numa escala de vários níveis (de um assistente, para
um coadjuvante e finalmente para um especialista).
A principal vantagem do modelo incremental é que o acréscimo nas capacidades
funcionais é mais fácil de testar, verificar e validar que no caso de estágios individuais como
no modelo waterfall.
Com este modelo, os custos de incorporar correções no modelo são menores.
O modelo incremental é equivalente a dizer que o sistema na forma de protótipo inicial
se desenvolve ao longo do ciclo de vida, ao invés de implementar um protótipo apenas
determinar os requisitos do futuro sistema, ou seja, o protótipo que evolui é o próprio sistema.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
26
7. Definição Do Domínio De Aplicação E Identificação Das Fontes De
Conhecimento
Tarefa Objetivo
Identificação da fonte
Quem e quais são as fontes de conhecimento, sem considerar disponibilidade
Importância Priorizar a lista das fontes em ordem de importância
Disponibilidade Listar as fontes de conhecimento de acordo com a disponibilidade. Livros e outros documentos são em geral mais disponíveis que especialistas humanos.
Seleção da fonte Selecionar as fontes com base na importância e disponibilidade
8. Projeto da Base de Conhecimento
Tarefa Objetivo
Representação Especificar como o conhecimento será representado, isto dependerá e implicará na seleção da ferramenta de desenvolvimento
Estrutura de controle no sistema
Definir como as regras terão interação entre si, partição da agenda ou uma regra global para gerenciar o fluxo de informações
Estrutura interna de Fatos
Especificar de forma consistente a estrutura interna de fatos, o que auxiliar o entendimento do fluxo de informações
Projeto preliminar da interface
Especificar o projeto da interface e obter o mais rápido possível um retorno no usuário sobre a interface.
Planejamento dos testes
Determinar como o código será testado e como os resultados serão analisados.
Estratégia de implementação
Definir como o sistema será implementado, ou seja, que modelo de desenvolvimento será adotado.
Elaboração de relatório
Documentar o projeto, incluindo todas as definições anteriores
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
27
9. Escolha da ferramenta de desenvolvimento
Escolher o correto escopo (meta, finalidade, objetivo) do problema e selecionar a
ferramenta certa para desenvolvimento são duas das mais difíceis decisões a tomar no projeto
de um SE.
Selecionar a ferramenta é uma tarefa difícil, pois, a maioria dos sistemas não foi
desenvolvida para aplicação a uma classe particular de problemas.
Lei de Davis:
Para cada ferramenta existe uma tarefa perfeitamente adequada a ela.
Todavia o contrário não é verdade, ou seja, para uma dada tarefa pode existir uma gama
de ferramentas igualmente se aplicam. Em alguns casos, a ferramenta foi escolhida por
motivos errôneos.
• O engenheiro de conhecimento já conhecia o sistema.
• A ferramenta era a mais eficiente disponível para o hardware a ser usado.
• A ferramenta foi desenvolvida e então domínios foram pesquisados para testá-la- "a
solução buscando um problema"
9.1. Questões quanto à escolha da ferramenta
• A ferramenta oferece à equipe de desenvolvimento a capacidade e sofisticação
necessária?
• As condições de suporte da ferramenta são adequadas considerando as restrições de
tempo do projeto?
• A ferramenta é disponível?
• Existe manutenção da ferramenta?
• A ferramenta possui as características sugeridas pelas necessidades do problema em
questão?
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
28
Os fatores de desenvolvimento (tempo, recursos financeiros, pessoal, etc.) influenciam a
decisão sobre que tipo de ferramenta escolher: uma linguagem de programação (tipo LISP ou
PROLOG) ou um sistema de engenharia de conhecimento (SHELL).
As linguagens de programação oferecem maior flexibilidade, mas geralmente requerem
da equipe de desenvolvimento a implementação da máquina de inferência para acessar a base
de conhecimento. Em geral, o desenvolvimento leva mais tempo com uma linguagem de
programação, mas o resultado pode ser mais adequado ao domínio do problema.
Por outro lado, sistemas SHELL, apesar de oferecerem menos flexibilidade, fornecem
mais orientações e mecanismos de como representar e acessar o conhecimento. O
desenvolvimento deve ser mais fácil, rápido barato com este tipo de sistema, mas pode
resultar num sistema tão eficiente quanto um implementado em linguagem de programação.
A orientação neste sentido é: Escolher a ferramenta que complementa os aspectos
fortes da equipe de desenvolvimento.
9.2. Condições de suporte da ferramenta
Estas devem incluir mecanismos de depuração (debugging), editores de base de
conhecimento, adequadas interfaces (I/O), e mecanismos de explicação.
9.3. Confiabilidade
O desenvolvimento será seriamente comprometido se a ferramenta não for confiável.
Ferramentas não suficientemente validadas podem causar problemas devido a testes
incompletos, documentação obsoleta e a linguagem ainda está em especificação.
É mais provável que a ferramenta seja confiável se existe uma grande comunidade de
usuários e considerada robusta e bem depurada.
Orientação: Não implementar um SE numa ferramenta ainda em desenvolvimento.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
29
9.4. Mantenabilidade
A manutenção é de responsabilidade do desenvolvedor da ferramenta, um sistema antigo
pode ser um problema se seu criador não tiver mais interesse em mantê-lo ou fornece
adequada documentação.
Orientação: Não escolha uma ferramenta que deva ser mantida por você mesmo.
9.5. Características da tarefa
Aspectos como:
• forma de representação do conhecimento,
• habilidade de programação da equipe de desenvolvimento e
• tipo de encadeamento de regras a ser aplicado é determinante para a seleção da
ferramenta
Uma vez escolhida a ferramenta, considere implementar um sistema protótipo num prazo
de quatro a seis semanas para testar a eficácia do sistema. Isto envolve aplicar a ferramenta
para resolver um problema pequeno, mas representativo no domínio de interesse.
Esta etapa coincide com a necessidade de implementar um protótipo rapidamente para
verificar se o escopo do problema e o esquema de representação estão bem fundamentados.
Durante esta fase, considere com particular atenção a velocidade de execução, pois se o
sistema levar horas ou minutos, em vez de segundos, para obter respostas parciais, então
testes e refinamentos serão lentos e o desenvolvimento poderá estar comprometido.
Outro aspecto de relevância é que a medida que o sistema se torna mais complexo, a
performance da ferramenta deve decair gradualmente e não abruptamente.
10. Escolha da equipe de desenvolvimento
Uma etapa decisiva é a escolha da equipe. O tamanho e a composição desta equipe varia
grandemente dependendo de vários fatores, a seguir abordados:
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
30
10.1. Escolha do Engenheiro de Conhecimento
Algumas características:
• Competência - assim como na engenharia de software, o EC deve possuir habilidades
de interpretar os requisitos de uma tarefa e o projeto da solução de forma bem clara. Sendo
assim, um completo entendimento de engenharia de conhecimento e das ferramentas é um
requisito.
• Organização - a capacidade de analisar os requisitos de projeto e planejar uma
solução geral no estágio inicial é importante. O processo de gerar um protótipo de forma
rápida determina a validade da solução proposta. Se a solução é cuidadosamente organizada e
estruturada, as chances de ser incorreta são bem menores.
• Paciência - apesar de ser possível adotar o modelo incremental e obter um protótipo
de maneira relativamente rápida, o desenvolvimento do sistema pode ser um processo
demorado, principalmente em projetos de grande e médio porte. O tempo entre a definição do
projeto e seu término pode levar de três a quatro anos. Consequentemente é necessário uma
considerável paciência para acompanhar um projeto até seu final.
Outro aspecto importante é que a rotatividade de pessoal pode ser um grande problema,
pois o desenvolvimento do sistema depende grandemente de como a equipe interpreta o
conhecimento sobre o domínio de aplicação.
• Facilidade de relacionar-se (friendliness)- não é possível subestimar a importância
da habilidade do EC de interagir facilmente com outras pessoas. O EC dedica grande parte de
seu tempo para entrevistar e interagir com especialistas. Tais especialistas podem ou não ter
resistência a participar do projeto, de qualquer forma sua paciência será levada ao limite.
• Habilidade de comunicação interpessoal - para ser efetivo, o EC deve ter a
capacidade de se comunicar com os mais variados especialistas, alguns dos quais podem ser
muito difíceis de lidar.
• Interesse em expandir o conhecimento - aqueles que pretendem desempenhar o
papel de EC devem apreciar aprender sobre novos assuntos, caso contrário poderá haver um
desestímulo durante o projeto resultando em rotatividade de pessoal.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
31
• Auto Confiança - como a atividade do EC pode envolver interação com um domínio
de conhecimento bem diverso, isto pode levar a uma certa frustração do EC, posto que este
terá pouco envolvimento com cada domínio, ou seja, é pouco provável que chegará a ser um
especialista em um domínio específico.
O candidato ideal a EC é alguém com um excelente entendimento sobre sistemas
baseados em conhecimento e uma compreensão básica sobre o domínio de aplicação. Tal
pessoa provavelmente não demande extensa "atividade de doutrinação" num certo domínio
para ser familiarizado com este domínio. Na realidade, tal combinação é rara e em muitos
casos soluções de compromissos devem ser estabelecidas.
É mais fácil ensinar quase-especialistas a arte da engenharia de conhecimento que
ensinar analistas de sistemas os princípios básicos de um domínio do conhecimento para o
qual eles não foram preparados.
Algumas vezes pode ser vantajoso que o EC seja completamente "novo" e imparcial num
certo domínio de conhecimento. Isto pode acarretar o domínio a ser mais amplamente tratado
e resultar numa melhor base de conhecimento. Todavia, existe uma desvantagem: a aquisição
de conhecimento pode levar muito tempo, devido ao tempo necessário para o EC entender o
domínio de aplicação.
Qualquer que seja a situação é fundamental que o EC tenha uma fundamentação em
representação e aquisição de conhecimento, pois estas são suas responsabilidades principais.
10.2. Desvantagens de ter um especialista como EC
• o sistema não refletirá o conhecimento de uma coletividade sobre o domínio;
• a granularidade do sistema (ou seja, o nível de detalhe) pode não ser apropriado à
tarefa (em geral muito detalhista);
• apesar disto, não se pode dizer que um especialista nunca seja um EC, isto depende do
domínio, e principalmente, do próprio especialista; nesta abordagem a vantagem é que não
serão necessárias entrevistas e nem a curva de aprendizagem no domínio.
O contrário, todavia é verdade, ou seja, o EC nunca deve desempenhar o papel do
especialista e tomar decisões sobre o sistema sem consultar o especialista.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
32
Alguém só se torna um verdadeiro especialista desempenhando tarefas específicas e
não apenas interagindo com um especialista.
10.3. Escolha do líder da equipe
Os critérios para definição do líder dependem do tamanho da equipe e da sofisticação
técnica do sistema. Contudo, independente disto, esta pessoa deve possuir uma significativa
experiência no desenvolvimento de sistemas baseados em conhecimento. Isto inclui:
• um entendimento a respeito da aquisição de conhecimento,
• suficiente experiência na implementação,
• bom entendimento da linguagem de programação,
• e se possível uma percepção e compreensão do domínio.
Tal lista de requisitos é bastante ampla e um aspecto mais realístico seria que o líder
tenha pelo menos um conhecimento compatível com o domínio.
10.4. Escolha do especialista
• Competência - pode ser medida de várias formas: anos de trabalho, publicações,
patentes no domínio, reputação entre os pares, etc.
• Capacidade de Articulação - isto facilita grandemente o processo de aquisição do
conhecimento. O especialista deve ser capaz de explicar precisamente como e porque chegou
a uma conclusão.
• Auto-confiança - o especialista deve estar seguro de sua posição na organização. É
muito difícil trabalhar com alguém numa posição defensiva sobre seu papel.
• Disponibilidade - o desenvolvimento de SE é uma tarefa que demanda tempo,
portanto o especialista deve satisfazer também este critério.
• Mente aberta - uma abertura para novos campos da tecnologia é importante. Pois a
resistência pode ser um grande obstáculo no desenvolvimento do sistema.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
33
• De fácil relacionamento - embora não seja um requisito absoluto, se existe uma
escolha, trabalhar com um especialista que trata os outros de forma equânime é uma
vantagem.
• Entusiástico - isto auxilia não apenas o processo de entrevista, mas também, e
principalmente, o tempo das entrevistas quando são necessárias a documentação e compilação
de dados.
10.5. Critérios relativos à equipe
O fator mais determinante para composição da equipe é a complexidade do sistema em
desenvolvimento. Considerando que haja uma relação direta entre o tamanho do sistema e sua
complexidade (o que nem sempre é verdadeiro), a descrição das equipes pode ser dividida em
três categorias de sistemas, a saber, pequeno, médio e grande:
10.5.1. Sistemas pequenos - contem aproximadamente de 100 a 200 regras. O
conhecimento neste tipo de sistema pode ser exclusivamente heurístico ou uma combinação
de procedural e heurístico. A experiência usada nestes sistemas pode estar disponível em
literatura ou através de contatos pessoais com especialistas.
Algumas características destes sistemas podem incluir:
• Geralmente empregam regras como principal forma de representação do
conhecimento.
• Usam sistemas Shell disponíveis comercialmente.
• Normalmente são implementados em PC's.
• Geralmente são desenvolvidos pelo próprio especialista.
• Usam um único especialista se um engenheiro de conhecimento é necessário.
Caso um engenheiro de conhecimento seja necessário haverá apenas um. A duração é de
cerca de 6 meses. Estes tipos de sistemas são ideais para treinamento de novos engenheiros de
conhecimento. Pelo fato de serem relativamente pequenos, é realístico afirmar que tais
sistemas sejam desenvolvidos por estudantes em um semestre acadêmico.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
34
10.5.2. Sistemas de médio porte - tais sistemas envolvem domínios mais complexos
onde a solução é tipicamente heurística. Estes sistemas contem aproximadamente de 250 a
1000 regras. No entanto, o número de regras nem sempre reflete a complexidade do sistema,
pois outras formas de representação, tais como frames, podem ser usadas. Apesar disto, o
número de regras pode fornecer uma maneira conveniente de classificar os sistemas.
Estrutura da equipe
• pelo menos um engenheiro de conhecimento, às vezes mais de um;
• no mínimo um especialista do domínio;
• possivelmente um analista de sistemas, em tempo parcial.
Atividades do líder da equipe - estruturar o sistema, o que minimiza possibilidades de
modificações ao longo do projeto. Também coordena as entrevistas com os especialistas, e
supervisiona as tarefas do engenheiro de conhecimento júnior. Este por sua vez é responsável
por implementar e validar a base conhecimento.
O analista de sistemas auxilia os EC's na interface do SE com outros sistemas como
banco de dados. Mesmo que vários especialistas sejam empregados no projeto, é importante
que um especialista atue como principal fonte de conhecimento. Os outros especialistas
podem servir para verificar e também esclarecer o conhecimento implementado.
Um importante ponto deve ser destacado. No desenvolvimento de um SE de porte médio
ou grande, pode ser arriscado empregar um especialista como EC. Pois, o sistema tenderia a
refletir suas opiniões e não a de outros especialistas. Embora isto seja aceitável em sistemas
de pequeno porte, não é o caso de sistemas maiores onde é necessária uma maior gama de
conhecimento. A duração de projetos de médio porte, da sua concepção à implementação, é
tipicamente de 1 a 2 anos.
10.5.3. Sistemas de grande porte - possuem em geral mais de 1000 regras. Aplicam
uma combinação de diferentes técnicas de representação do conhecimento. São desenvolvidos
para problemas de natureza altamente heurística.
Uma estrutura típica para projetos deste porte compreende:
• vários EC's juniores sob a supervisão de um líder (um EC mais experiente);
• um analista de sistema a tempo integral;
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
35
• um gerente geral do projeto.
A logística inerente a tais projetos possivelmente leva o problema a ser dividido em
vários componentes, que são implementados independentemente, cujas fronteiras devem ser
definidas pelo líder da equipe. Sempre é necessário definir que o conhecimento não esteja
sendo duplicado, isto está entre as tarefas do líder da equipe.
Uma grande diferença deste tipo de projeto, comparando com os anteriores, é a
necessidade de incluir um gerente para lidar com orçamento e aspectos organizacionais
comuns a qualquer projeto de grande porte.
10.6. Problemas relativos à interação com especialistas
Segue abaixo uma lista de diferentes perfis de especialistas e formas de abordá-los.
10.6.1. O Especialista fraco ou tímido
Este tipo de especialista teme perder seu emprego ou status na organização caso um
SE seja desenvolvido para desempenhar sua função. Como conseqüência disto, ele raramente
fornece uma resposta direta a qualquer questão. Este tipo é o mais difícil para se trabalhar
inicialmente, mas frequentemente o mais fácil de se modificar. Neste caso, o EC deve ser
capaz de convencê-lo de que o SE será implementado para livrá-lo de tarefas mais rotineiras.
Alguns argumentos
• o SE permitirá o especialista se concentrar em tarefas mais desafiadoras;
• o SE não poderá substituir totalmente um humano. Tais sistemas carecem de
conhecimento de senso comum e criatividade, limitam-se a realizar um sub-conjunto das
tarefas do especialista;
• um SE não realizar descobertas. Isto ainda será a tarefa do especialista;
• a importância e o significado das realizações do especialista são demonstrados pelo
interesse da empresa em codificar sua experiência.
• a área da Inteligência Artificial representa uma nova tecnologia, a qual alguém se
sentirá interessado em aprender.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
36
O mais importante é que o EC deve ser cuidadoso no trato com tal especialista,
para não despertar insegurança.
10.6.2. O Especialista Cínico
Um especialista deste tipo, num caso extremo, detesta seu trabalho, a empresa e seu
chefe, e até mesmo a idéia de participar no projeto de um SE. Por várias razões (senioridade,
salário, benefícios) prefere continuar na empresa.
Algumas dicas para identificar este tipo de especialista:
• constante recusa em gravar entrevistas;
• críticas de seus pares e/ou superiores;
• outro sinal de amargura
Este tipo pode compartilhar informação de forma relutante, ou em casos raros, fornecer
propositadamente informação incorreta. Se a única opção for trabalhar com tal especialista, o
EC deve tomar as seguintes providências:
• Examinar cuidadosamente toda informação passada, pois pode haver o risco de
sabotagem do projeto. Isto reforça a importância dos testes de validação e de empregar outros
especialistas como revisores;
• Mostrar simpatia ao especialista. Caso ele perceba o EC também como "vítima" da
organização poderá criar uma identificação;
• Apelar para o senso de profissionalismo do especialista. Isto pode ser obtido através
de uma atitude consciente e precisa do EC, geralmente isto se aplica mais quando ambos
trabalham na mesma organização.
10.6.3. Especialista "sumo sacerdote" no domínio
Este tipo considera-se acima de todos em seu domínio. Encara o EC como um ser
ignorante que gasta seu tempo com questões banais, se arriscando a pensar que ele, o
especialista, pode ser substituído por uma máquina.
Para este tipo, a tecnologia de SE está extremamente subdesenvolvida. Por causa de sua
arrogância, este tipo pode ser muito difícil de se interagir, nunca está disponível para reuniões,
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
37
permite várias interrupções durante as poucas audiências, e não se interessa em cumprir as
tarefas entre as reuniões.
O EC deve ser paciente para lidar com tal especialista, deve conquistar a conquistar sua
confiança, através da capacidade intelectual mostrada com o desenvolvimento de um
protótipo. Isto ganhará o respeito do especialista e poderá convencê-lo da viabilidade da
tecnologia.
Reclamar aos superiores é improvável de resultar em melhoras no comportamento deste
tipo devido ao alto status do especialista na organização, de fato pode até piorar o
relacionamento.
10.6.4. O Especialista paternalista
Semelhante a um "velho" professor que deseja auxiliar e agradar um bom ouvinte através
da narrativa de suas proezas. Este tipo é difícil de trabalhar apesar de suas boas intenções,
pois geralmente fala demais. Este tipo de relação professor-aluno pode ser muito benéfica ao
processo de aquisição de conhecimento se adequadamente gerenciada.
Na interação com tal especialista, o EC deve tentar: minimizar os longos discursos com
diplomacia, e prosseguir para outras questões. Muitas vezes senso de humor pode atingir o
efeito desejado.
10.6.5. O Especialista incomunicável
Este tipo se expressa via questões curtas e não elabora sobre suas respostas- isto pode
frustrar o EC. Este perfil não pretende provocar um dano ao projeto, apenas é um indivíduo
calado e introspectivo. Neste tipo de interação, a paciência é extremamente importante.
O EC deve explorar cuidadosamente as respostas e explicações, deve estudar o domínio
de conhecimento para tentar desvendar outros ângulos enfoques que podem não ser óbvios
para ele.
10.6.6. O Especialista descuidado
É uma variação do perfil anterior. Nunca discorda do EC, pois simplesmente levaria
muito tempo para explicar as razões. O EC deve ter um cuidado extra para entender o domínio
a fim de verificar o conhecimento do especialista. O uso de gravação, se o especialista
concorda, pode forçá-lo a pensar mais sobre suas respostas.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
38
10.6.7. O Especialista "pseudo conhecedor da AI"
Este tipo já leu um ou dois artigos sobre sistemas especialistas e pensa que já conhece
tudo. Este perfil pode subestimar o processo de aquisição de conhecimento e tentar se
envolver em detalhes da implementação do sistema que são da responsabilidade do EC.
Este especialista pode continuamente sugerir melhorias no processo de entrevistas e
tentar conduzir o EC. A forma de lidar com tal perfil e tentar gentilmente mostrar quem ele é
e quem é o EC.
11. Estrutura do processo de aquisição do conhecimento
Este processo pode se apresentar de várias formas, mas independente destas a aquisição
se processa um a um. De forma ideal, tal processo consiste em uma série de entrevistas, cada
uma com diferentes aspectos.
11.1. A entrevista inicial
Principal objetivo do primeiro encontro- estabelecer uma relação harmoniosa com o
especialista. Neste sentido, o EC deve tentar deixar uma boa impressão. Isto pode ser obtido
mostrando ao especialista que o EC já tentou adquirir um certo entendimento básico do
domínio de conhecimento antes do encontro.
Uma típica agenda
• Introdução e uma conversa leve
• Uma explicação do que são sistemas especialistas e sua relação com o projeto.
• Uma discussão sobre a importância do projeto (se aplicável)
• Uma discussão sobre o que é esperado do especialista e também o que ele pode
esperar do EC.
• Uma discussão de materiais para leitura que o especialista recomenda para que o EC
possa se familiarizar com o domínio.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
39
• A programação para o próximo encontro.
Nesta primeira reunião as vantagens de um projeto deste tipo devem ser claramente
expostas. A profundidade da discussão deve ser determinada pelo grau de conhecimento que o
especialista tem sobre informática. Caso o especialista não tenha conhecimento sobre esta
área, pode ser necessária a definição de termos básicos.
Um ponto chave é tornar o especialista familiarizado com o que será feito e não os
detalhes de como será feito.
As regras básicas que definem o desenvolvimento de um SE devem ser discutidas. O
principal requisito para estabelecer uma relação harmoniosa entre o especialista e o EC é a
identificação das expectativas de ambos. É crítico que o especialista saiba deste o princípio o
que lhe será solicitado em termos de tempo, esforço e cooperação. Da mesma forma, é
importante que ele saiba o que pode esperar do EC. Por exemplo, no processo de aquisição de
conhecimento, será necessário apenas obter do especialista uma orientação geral e o EC
saberá definir os passos posteriores?
Se o especialista não pode ou não deseja se comprometer com o projeto, é melhor saber
disto no início de tal forma que alternativas possam ser exploradas.
Juntamente com esta discussão, deverá haver uma descrição do processo de entrevistas,
uma explicação do que é o processo incremental, e possivelmente alguns aspectos sobre
verificação e testes.
É importante que esta primeira reunião seja curta, não mais que uma hora. Lembrando
que o objetivo principal é estabelecer uma relação harmoniosa com o especialista.
11.2. Organização das sessões para aquisição do conhecimento
Estas podem ser classificadas em dois grupos:
• sessões para definição de conhecimento genérico
• sessões para solução de problemas específicos
O conhecimento adquirido das sessões do primeiro tipo, embora importante e educativo,
provavelmente não será codificado na base de conhecimento, mas será vital para obter o
entendimento necessário para a solução de problemas específicos.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
40
11.3. Sessões para definição de conhecimento genérico
As sessões que seguem a entrevista inicial são deste tipo.
Os principais objetivos são:
• Entender melhor o domínio
• Entender as opiniões e pontos de vista do especialista sobre o domínio.
• Continuar desenvolvendo uma relação harmoniosa com o especialista
Antes destas sessões o EC deve ter se familiarizado com a literatura sugerida pelo
especialista e conhecer o vocabulário e o entendimento básico do domínio, para capacitá-lo a
dialogar com o especialista.
Neste tipo de sessão, a aquisição de conhecimento se dá principalmente através de
questões abertas. Este tipo de questão requer uma discussão e não pode ser respondida
apenas com sim, não, um termo ou um número.
Geralmente, os especialistas apreciam a oportunidade de falar abertamente sobre o
domínio. Além disto, este tipo de questão serve com um aprendizado para o EC. Mesmo
especialistas que são relutantes ou desconfiados tornam-se mais cooperativos com este tipo de
questão. Com este tipo de questão, o EC verifica seu entendimento básico sobre o domínio. Se
alguns conceitos ou termos não são entendidos, é aqui o momento de perguntar.
O risco com as questões abertas é que o especialista pode divagar nas respostas, e um
considerável tempo pode ser perdido.
Este tipo de questões requer uma boa dose de tato e paciência do EC para manter
controle da entrevista sem provocar desconforto no especialista.
Entrevistas deste tipo podem variar de uma a três horas de duração. É frequentemente
difícil e indesejável marcar períodos mais longos com especialistas, pois estes são muito
requisitados.
A habilidade de manter a concentração também diminui após duas ou três horas. Caso
seja uma opção, é melhor agendar tais reuniões para o período da manhã, pois a mente ainda
está "fresca" e menos provável que o especialista já tenha se envolvido com algum problema.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
41
As entrevistas via questões abertas devem continuar até que o EC tenha obtido um
adequado entendimento do problema, das opiniões e pontos de vista do especialista.
11.4. Sessões para solução de problemas específicos
Uma vez que o EC tenha obtido o entendimento básico do problema, o processo
incremental terá início com a definição de uma sub-área que servirá de primeira parte do
conhecimento a ser representada.
Apesar de ter sua definição um tanto quanto nebulosa esta sub-área deve envolver
problemas que são:
• Bem entendidos pelo especialista em questão.
• Relativamente bem compreendidos pelo EC.
• De largura e profundidade suficientes para representar dificuldades na solução de
problemas do domínio.
• Suficiente pequena para requerer apenas de dois a três meses de esforço.
Nesta ocasião deve-se modificar a abordagem de questões genéricas, amplas, para
questões altamente direcionadas.
O objetivo destas entrevistas é mostrar como o especialista soluciona os problemas
específicos. Muitas das questões aqui empregadas são do tipo questões fechadas, cujas
respostas podem ser do tipo sim/não ou números.
Durante estas entrevistas, deve-se estar atento para manter o especialista focalizado no
problema em questão, diplomaticamente evitando que ele divirja das questões apresentadas.
Esforços devem ser feitos no sentido de relacionar cada entrevista com as demais,
resumir e revisar o conhecimento adquirido nas entrevistas anteriores.
Esta revisão permite ao especialista verificar quão corretamente o conhecimento foi
entendido, e promove uma continuidade do processo de aquisição.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
42
12. Organização Do Conhecimento
Uma técnica de organização do conhecimento bastante utilizada é conhecida como saída-
entrada-meio. A seqüência é:
• Identificar as respostas ou soluções para o problema em questão - as saídas do
sistema. Estas representam os objetivos que o especialista e o EC têm quando buscam uma
resposta. No caso de existir mais de uma resposta, as diferenças entre elas devem ser
claramente identificadas e entendidas pelo EC.
• Identificar as fontes de informação que o especialista usa para deduzir a solução - as
entradas do sistema. Como estas entradas são identificadas, determinadas e geradas deve
também ser entendido pelo EC.
• Finalmente e mais importante, determinar as conexões entre entradas e saídas - o
meio. Estas conexões representam o núcleo do conhecimento do especialista. Algumas
entradas podem não ser necessárias inicialmente. Adicionalmente, algumas metas
intermediárias ou hipóteses podem ser requeridas para se completar as conexões.
Exemplo: um sistema especialista para diagnose de mau funcionamento no sistema de
refrigeração de automóveis.
O sistema baseia-se no fato de que o motorista não tem conhecimento de mecânica e que
a comunicação entre o motorista e o sistema se dá via telefone, ou seja, o especialista não vê o
automóvel.
O EC define uma lista de possíveis problemas que podem ocorrer com o sistema de
refrigeração do automóvel.
SAÍDAS: as possíveis saídas deste tipo de problema são:
• Vazamento no radiador.
• Correia quebrada no ventilador.
• Bomba de água defeituosa.
• Perda de refrigerante por evaporação devido à folga da tampa do radiador.
• Mangueira de água quebrada ou rachada.
• Refrigerante congelado.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
43
ENTRADAS: as informações que um mecânico necessita para diagnosticar o mau
funcionamento do sistema são:
• Indicador de temperatura no painel.
• Vapor saindo do capô do motor.
• Condições ambientais.
• Poça de refrigerante embaixo do motor.
A fim de relacionar as entradas às saídas, o especialista define regras. Algumas destas
apresentadas a seguir:
Regra 1: a presença de indicação "quente" no medidor de temperatura no painel
geralmente implica que pelo menos um problema existe.
Regra 2: a ausência de indicação "quente" não necessariamente implica na ausência de
um problema.
Regra 3: uma grande poça de refrigerante embaixo do motor pode indicar vazamento no
radiador, mangueiras quebradas, e/ou bomba defeituosa.
Regra 4: uma pequena poça de refrigerante embaixo do motor geralmente implica na
bomba defeituosa.
Regra 5: ausência de poça de refrigerante e uma indicação “quente” no medidor de
temperatura indicam uma correia quebrada no ventilador.
Regra 6: uma temperatura ambiente abaixo de 10o F sugere o refrigerante congelado.
Regra 7: a presença de um ruído chiado e uma pequena poça de refrigerante embaixo do
motor indica vazamento no radiador e/ou mangueiras.
Embora as técnicas baseadas em entrevistas sejam muito utilizadas, elas nem sempre são
as mais eficientes. A razão disto é que alguns especialistas por mais interessados que sejam
em cooperar com o EC têm dificuldade em verbalizar o conhecimento.
Nestes casos, técnicas alternativas devem ser empregadas, estas podem ser divididas em
duas categorias:
• Observacionais - onde o EC observa o especialista em sua tarefa e busca entender seu
método de resolução
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
44
• Intuitiva - onde o EC tenta se tornar um "pseudo-especialista" e implementa parte do
conhecimento sobre o domínio.
12.1. Técnicas observacionais
• Observação em silêncio no local
Devido ao fato do raciocínio do especialista não sofre interrupção, ele pode executar uma
tarefa de forma bem eficiente.
Com a falta de interação o EC pode deixar de perceber detalhes sobre a forma de solução
adotada. Consequentemente, esta técnica deve ser considerada apenas para se ter uma noção
geral do problema, e não para obter conhecimento detalhado.
• Observação no local com discussão
Se o problema é rotineiro para o especialista, não haverá uma grande diferença devido à
interação. Caso contrário, o especialista pode ter uma certa dificuldade em obter a solução.
Alguns sintomas de que essa técnica não é adequada: hesitação para tomar uma decisão,
sinais de desconforto, ou recusa em criar uma solução perante o EC.
• Exercitando o especialista
Baseia-se em preparar casos especiais de dificuldade variável para exercitar o
especialista. Isto considera o fato de que, em algumas áreas, os problemas são em sua maioria
rotineiros.
Formas destas técnicas:
• Tarefas com informações limitadas - neste caso, uma tarefa rotineira é executada,
mas o especialista não conhece uma certa informação que tipicamente é disponível.
• Tarefas com restrições - uma tarefa típica é desempenhada, mas o especialista deve
executá-la com restrições, por exemplo, de tempo.
• Descrição e análise de problemas
Esta técnica é baseada na análise de problemas clássicos de um domínio de
conhecimento. Geralmente, são usados problemas de sala de aula que representam
importantes relações no domínio.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
45
A análise destes problemas pelo EC é tipicamente na forma de estudo de caso, onde
algumas questões chaves são:
• Por que tais problemas são usados para ensinar este domínio?
• Quais são as características que tornam cada um destes problemas importantes?
12.2. Técnicas intuitivas
Estas técnicas são idealmente aplicadas para situações onde o EC já tem um significativo
entendimento do processo de tomada de decisão e deseja verificar quão correto é este
entendimento.
Estas técnicas não são aplicadas geralmente para aquisição, mas sim verificação de
conhecimento antes de representá-lo. Neste caso, o EC e o especialista trocam de papéis, e o
EC tenta resolver um problema na presença de um especialista. Este processo pode esclarecer
e modificar abordagens previamente consideradas como adequadas e pode fornecer novas
informações de como proceder a solução.
13. Protótipo Inicial na aquisição do conhecimento
No início do desenvolvimento de sistemas computacionais, tinha-se como padrão tentar
obter uma completa e correta especificação do sistema antes de começar sua implementação.
Todavia, para SE, a experiência demonstra que tal forma não mostrou-se eficiente.
No início do projeto, as idéias das pessoas envolvidas do que é necessário e como isto se
dará na prática são difusas e imprecisas.
Uma especificação pode ser difícil de entender, particularmente se for usado um jargão
computacional, e é extremamente difícil se imaginar como será "um sistema dinâmico"
partindo-se de uma "descrição estática".
O processo de "prototipagem" envolve desenvolver um modelo relativamente barato e
mais simples de um futuro produto, e usá-lo como um dispositivo para aprender sobre o
futuro trabalho.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
46
Todavia, se este processo não for disciplinado pode ser perigoso, pois o ciclo de
construir, modificar e descartar pode se repetir indefinidamente.
No contexto de sistemas especialistas, prototipagem geralmente envolve três aspectos:
• Protótipo descartável - isto implica em desenvolver um modelo com a intenção de
aprender com base nele e depois descartá-lo.
• Protótipo incremental - uma versão para teste de um produto. Neste caso, um projeto é
dividido em pequenos projetos e a cada estágio de incremento na funcionalidade do sistema,
uma versão é apresentada para teste da parte a ser adicionada no sistema.
• Protótipo evolutivo - contínua modificação de uma versão em estágio de operação.
Neste sentido, o sistema deve ser concebido para permitir constantes atualizações.
Na prototipagem, um aspecto chave a ser investigado é a interface do sistema. Alguns
estudos mostram que tal aspecto pode significar até 50 % do esforço no desenvolvimento.
13.1. Impacto desta abordagem sobre o perfil do EC
Caso a prototipagem seja adotada, o conhecimento técnico do EC sobre programação
deve ser consideravelmente mais amplo que no caso de considerar apenas um "modelo no
papel".
Com o protótipo inicial, a equipe de EC tem condições de receber um rápido retorno
sobre:
• escopo de conhecimento
• necessidades dos usuários
• validade das decisões tomadas no projeto.
Com isto, caso uma mudança de paradigma seja necessária seu impacto será minimizado
pelo fato da mudança ter sido constatada num estágio inicial do desenvolvimento.
O desenvolvimento do protótipo envolve o seguinte ciclo:
• adquirir partes do conhecimento das fontes
• implementar tais partes no sistema
• rever o resultado da implementação com especialistas
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
47
• refinar a base de conhecimento para corrigir os problemas detectados
• adquirir outras partes de conhecimento ...
Com a progressiva adição de módulos, a base de conhecimento pode ser rapidamente
obtida, ainda que com uma funcionalidade parcial, e colocada em teste, embora não esteja
completa. Tal abordagem não é aplicável para Programas Convencionais, que por sua
natureza procedural, geralmente devem ser completamente implementados antes do uso.
14. Relação entre protótipo e sistema final
Algumas referências recomendam que o protótipo seja descartado após sua avaliação e
se inicie o desenvolvimento do sistema final da estaca zero, a menos que todas as decisões
tomadas no protótipo sejam justificadas (um cenário bem raro).
Aspectos Gerais sobre o Protótipo Inicial
• A base de conhecimento deve ser suficiente para resolver alguns subproblemas de
início ao fim, mas relativamente pequena para não requerer um significativo esforço. Por
exemplo, num sistema para diagnóstico de problemas em veículos, um protótipo inicial pode
corresponder ao sistema de injeção de combustível.
• Uma vez que o conhecimento, as entradas e saídas de, por exemplo, 5 a 10
subproblemas tenham sido implementadas e para expandir o sistema o processo seja
simplesmente repetitivo, então o protótipo inicial estará concluído.
• A equipe de desenvolvimento deve aprender o máximo possível com o protótipo
inicial. E determinar quanto do sistema final já está implementado no protótipo.
• O esforço esperado deve ser em torno de 2 a 4 semanas para um sistema pequeno, e de
2 a 4 meses para sistemas de médio e grande porte.
• A interface é um aspecto importante a ser verificada com o protótipo. Todavia, a
equipe não deve alocar tempo para a interface em detrimento da base de conhecimento.
• O protótipo deve ser validado da mesma forma que o sistema final será. Assim, alguns
usuários do futuro sistema devem ser permitidos e até estimulados a usarem o protótipo.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
48
• Um relatório final deve ser escrito na conclusão do protótipo, incluindo aspectos de
sua validação.
15. Verificação e Validação
O futuro de Sistemas Especialistas será severamente comprometido, se os
desenvolvedores destes sistemas não atribuírem a devida atenção ao problema da
confiabilidade. Além disto, considerando o fato que SE são considerados programas
"inteligentes", a perda de credibilidade pelo usuário pode resultar de conclusões errôneas do
sistema.
As principais fontes de erro em SE são:
• A falta de especificação do sistema, ou quando esta existe, a falta de seu cumprimento.
• Erros de semântica e sintaxe introduzidos durante a implementação do sistema (bugs).
• A incorreta representação do domínio, resultando numa solução errônea ou na
incapacidade de encontrar uma solução para o problema.
A verificação aborda as duas primeiras categorias de erros. Examinando o cumprimento
das especificações e assegurando a consistência e abrangência da base de conhecimento, que
são afetadas por erros de semântica ou sintaxe.
A validação envolve várias questões, como as descritas acima, mais ainda, busca detectar
se o domínio de conhecimento está correto e que o sistema desenvolve as soluções de forma
correta e precisa.
15.1. Comparação de Verificação e Validação (V&V) com Programas
Convencionais
O que torna V&V diferentes em sistemas convencionais?
Parte disto origina-se de como SE são diferentes de sistemas convencionais.
• SE não são de natureza completamente objetiva. A estrutura de solução de problemas
neles representada é baseada em impressões subjetivas. De fato, para algumas aplicações
se a mesma situação for apresentada a dois especialistas de mesma competência, cada
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
49
um pode decidir abordar o problema de forma diferente, ainda que correta, tendo como
resultado duas soluções diferentes. Mesmo que ambas as soluções sejam apropriadas, cada
especialista considerará sua solução a melhor e a do outro menos ótima.
• Uma certa dose de incerteza é tolerada em sistemas especialistas. As soluções não são
sempre precisas e exatas, mas têm uma incerteza ou imprecisão ou devido aos dados ou ao
domínio de conhecimento.
• Enquanto para certas aplicações programas convencionais podem ser verificados em
laboratórios, SE, por outro lado, não podem facilmente ser verificados em laboratórios.
Isto porque eles geralmente não geram um modelo físico, mas sim a impressão compilada de
um sistema físico.
• Em sistemas convencionais, a questão de correção dos resultados de um teste não é em
geral um problema, pois o verificador do sistema sempre pode determinar se a resposta
fornecida pelo programa está certa ou não. No caso de SE, como estes modelam o
conhecimento de um especialista sobre um domínio, um especialista humano está sempre
envolvido. Isto implica que um especialista (ou um grupo de especialistas) é o avaliador final
da eficácia de um SE.
Dadas estas diferenças, novos métodos de avaliar SE são necessários para assegurar sua
confiabilidade. Nenhuma técnica única foi desenvolvida que tenha ganho aceitação universal,
ao invés disto, recomenda-se a combinação destas técnicas.
15.2. Verificação
Um dos objetivos da verificação é assegurar que existe uma correspondência entre a
especificação do sistema e o que este realmente executa.
Duas etapas compreendem a verificação de SE: 1 - verificar que o sistema adere às suas
especificações e 2 - verificar quanto à existência de erros de semântica e sintaxe na base de
conhecimento.
Quanto às especificações:
• O adequado paradigma de representação do conhecimento foi implementado.
• A técnica de raciocínio adequada foi empregada.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
50
• O projeto e implementação foram modulares.
• O sistema tem uma interface apropriada com outros sistemas.
• A interface do usuário corresponde às especificações.
• A forma de explicação foi apropriada ao usuário pretendido.
• Os requisitos de tempo de execução do sistema foram satisfeitos.
• O sistema tem manutenção conforme o grau especificado.
• O sistema satisfaz as especificações de segurança.
• Foram adotadas medidas de segurança para proteger que a base de conhecimento seja
modificada sem autorização.
A verificação de regras quanto a erros de sintaxe deve checar:
• Regras redundantes - duas regras são redundantes se elas possuem premissas
idênticas e levam a conclusões idênticas. Isto também acontece mesmo quando as conclusões
não são sintaticamente idênticas, mas levam ao mesmo significado, exemplo:
Se a umidade for alta e a temperatura quente
Então haverá tempestades com trovões
OU
Se a temperatura é quente umidade for alta
Então haverá tempestades com raios.
Redundância semântica é menos comum, porém mais difícil de detectar porque o sistema
não conhece a diferença entre o significado das conclusões.
• Regras conflitantes - quando a premissa de duas regras é idêntica, mas suas
conclusões são conflitantes.
• Regras incluídas - uma regra é incluída por outra se esta tem mais restrições
condicionais com as conclusões idênticas. Exemplo:
(Regra 7)
Se a temperatura está quente e
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
51
a umidade está alta
a pressão barométrica é baixa
Então Haverá trovoadas
(Regra 8)
Se a temperatura está quente e
a umidade está alta
Então Haverá trovoadas
A regra 7 está incluída na regra 8, porque a primeira tem uma condição a mais que a
última.
• Regras circulares - conjunto de regras que apresentam um encadeamento entre si
formando loops. (já apresentado)
• Condicionais desnecessárias - quando duas regras com conclusões idênticas têm
quase as mesmas premissas.
• Regra sem-saída (dead-end rules) - no encadeamento direto, estas são regras cujas
ações não afetam qualquer conclusão e não são usadas por outras regras para gerar outras
conclusões.
• Regras "perdidas" - são caracterizadas por fatos que não são usados no processo de
inferência, conclusões não afetadas por qualquer outra regra ou função, ou falhas em cobrir
todos os possíveis valores das entradas.
Se o marcador de combustível indica vazio
Então o tanque está vazio
Neste caso, se a conclusão não for empregada para conectar a premissa à solução do
problema de partida do motor, então esta será uma regra perdida.
• Regras inatingíveis - no sistema de encadeamento direto, este tipo de regra indica que
suas premissas jamais serão satisfeitas, ou pela ausência de certas regras ou pela falta de
dados de entrada. Isto é equivalente a uma "regra sem-saída" no sistema de encadeamento
reverso.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
52
Validação
Esta tarefa é inerentemente mais complexa que verificação. Envolve a determinação da
eficácia do sistema final com relação às necessidades e requisitos do usuário.
O Que Validar?
A validação da base de conhecimento pode ser executada validando:
• os resultados intermediários
• os resultados finais
• alguma combinação destes
Os resultados finais são as metas principais do sistema, portanto tais resultados não
podem estar ausentes na validação. Todavia, a validação de resultados intermediários pode
fornecer valiosas orientações quanto à operação do sistema e auxiliar a rapidamente corrigir
problemas a custo relativamente baixo.
15.2.1. Metodologias de Validação
• Validação Informal - avaliação superficial e qualitativa através de reuniões com um
ou mais especialistas do domínio. Embora, tal avaliação seja útil durante o desenvolvimento
de um módulo da base de conhecimento, este método não pode ser considerado satisfatório
com único meio de avaliar a base de conhecimento.
• Validação Formal - isto requer testes predefinidos, onde o sistema é tratado como
uma "caixa preta", tendo suas saídas comparadas com respostas de especialistas. Na
comparação, as opiniões dos especialistas podem variar de simples respostas na forma de sim
ou não, ou uma faixa de valores, tanto qualitativos como quantitativos. Se esta abordagem é
adotada, os desenvolvedores devem assegurar que os especialistas/usuários não têm
dificuldade em operar o sistema.
Uma forma alternativa de eliminar as dificuldades dos usuários é apenas apresentar os
resultados a um painel de avaliadores. Deve ser considerado, que alguns especialistas podem
ser favoráveis ou desfavoráveis ao uso de computadores, o que neste caso pode influenciar na
opinião deles sobre o sistema.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
53
É recomendável definir um painel de avaliadores com uma combinação de membros que
participaram do desenvolvimento e membros externos. Isto confere objetividade e, ao mesmo
tempo, diminui a tendência de preconceitos na avaliação.
Uma alternativa de avaliação é baseada no Teste de Turing. Neste contexto, a um
avaliador são apresentados resultados obtidos pelo sistema e de um especialista. A idéia
básica deste teste é muito simples, porém sua implementação pode ser complicada. O tipo de
saída do sistema deve ser na forma de um diálogo. A vantagem desta abordagem é a
eliminação da parcialidade pró ou contra o uso de computadores.
Um aspecto adicional a ser considerado na elaboração de testes de avaliação é o fato de
que à medida que o número de regras ou classes no sistema cresce, o conjunto de testes
exaustivos expande exponencialmente.
15.2.2. Testes de campo
Independente de quantos testes sejam realizados na fase de desenvolvimento ou quão
exaustivos estes sejam, através dos testes de campo sempre descobrem-se erros inesperados
ou efeitos indesejáveis.
No teste protótipo existe um risco inerente:
O sistema pode perder credibilidade antes dos usuários operarem o produto final.
Recuperar esta credibilidade pode ser difícil.
Algumas etapas para diminuir este risco.
• Os usuários devem ser receptivos ao conceito de SE.
• Eles devem estar conscientes que estão testando apenas um protótipo.
15.2.3. Validação de subsistemas
Este método requer que a base de conhecimento seja particionada em submódulos. Uma
metodologia adequada de projeto requer que o sistema seja modular, porém este método
possui duas desvantagens:
• Nem todos os sistemas são claramente decompostos em sub-sistemas independentes.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
54
• A validação de todos sub-sistemas não equivale à validação do sistema completo.
15.2.4. Quando é apropriado validar?
A abordagem mais amplamente aceita é que o processo de validação deve começar com
a especificação do sistema e prosseguir ao longo de seu desenvolvimento. Mesmo assim, deve
existir uma validação formal no "estágio final" do sistema.
A validação formal deve se iniciar tão logo o protótipo inicial seja desenvolvido. Neste
estágio, geralmente conhecido como teste-alfa os objetivos iniciais do projeto do sistema são
reconsiderados e as necessárias modificações são feitas.
16. Algumas observações sobre Orientação a Objetos
(defclass designer (is-a USER)
(role concrete)
(pattern-match reactive) ;; importante para permitir que o objeto seja usado no lado esquerdo da regra. (Ver manual pag. 97.)
(slot id (type SYMBOL) (create-accessor read-write) )
)
Regras usando objetos:
(defrule <nome da regra>
;; this rule is necessary because of inconsistence in the user input
(object (is-a <nome da classe>) <uso de alguma variável baseada no slot>... )
..outros condicionais
=>
;;ações da regra
)
Considerações para definição de classes (manual pag. 105)
• a hierarquia da classe deve ser definida em incrementos lógicos de especialização
usando a relação "is-a"
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
55
• uma classe é desnecessária se ela possui apenas uma instância
• uma classe não deve ser identificada com o mesmo nome de uma instância e vice-
versa (isto é apenas para eliminar alguma confusão)
Algumas funções para manipulação de objetos:
(do-for-instance ((?var <nome da classe>)) (comparação de algum atributo)
(progn ... ações
)
)
Exemplo: imprimir o nome do valor do slot nome de uma instância pessoa cuja idade seja maior que 20
(do-for-instance ((?alguem PESSOA)) (> ?alguem:idade 20)
(progn (printout t "pessoa com idade maior que 20" ?alguem:nome)
)
)
(do-for-all-instances ( (?var1 <nome da classe>) (?var2 <nome da classe>) )
(comparação de atributos das instâncias)
(progn ... ações
)
)
Exemplo: imprimir os nomes das pessoas com mesma idade
(do-for-all-instances ( (?x1 PESSOA) (?x2 PESSOA) ) (eq ?x1:idade ?x2:idade)
(progn (printout t "estas pessoas tem a mesma idade" ?x1:nome e ?x2:nome)
)
)
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
56
17. Incerteza
Mesmo considerando que existem aplicações de SE que podem ser implementadas com
solução (abordagem) exata, muitos outros requerem um raciocínio inexato envolvendo fatos
ou regras com incerteza. Exemplos clássicos de sistemas que lidam com incerteza são
MYCIN e PROSPECTOR.
Nestes sistemas, conclusões são obtidas mesmo quando todas as evidências para provar
completamente tais conclusões não são conhecidas.
Embora seja possível obter uma conclusão mais confiável através de mais testes, existem
problemas com o aumento de tempo e custo de testes. Estas restrições de tempo e custo são
particularmente importantes no caso de tratamento médico. Atrasar um tratamento devido a
mais testes aumenta os custos e, enquanto isto, o paciente pode vir a falecer.
No caso de mineração, o custo de testes adicionais também é um fator significante. Pode
ser mais vantajoso iniciar as escavações se tem 95% de chance de sucesso do que gastar mais
centenas de milhares de dólares para se obter um grau de confiança de 98%.
As fontes de incerteza possíveis em SE podem ser causadas por problemas nos dados,
por exemplo:
• dados ausentes ou não disponíveis;
• os dados podem estar presentes mas não confiáveis ou ambíguos devido aos erros de
medida, ou medições conflitantes, etc.
• a representação dos dados pode ser imprecisa ou inconsistente
• os dados podem ser apenas a melhor suposição do usuário
• os dados podem ser baseados em valores "default" e tais valores podem ter exceções
Além disto, a incerteza pode ser causada pelo conhecimento modelado:
• representar as melhores suposições dos especialistas que são baseadas em associações
plausíveis ou estatísticas que eles observaram
• não ser apropriado em todas as situações
Considerando estas várias fontes de erro, a maioria dos SE requer a incorporação de
alguma forma de representação de incerteza.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
57
Ao se implementar um esquema de incerteza, deve-se considerar três questões principais:
• como representar dados incertos
• como combinar dois ou mais dados incertos
• como gerar inferência usando-se dados incertos
17.1. Redes Bayesianas
Um dos mais conhecidos métodos de modelar incerteza é a chamada Rede Bayesiana.
Este método é baseado na Teoria da Probabilidade.
Como se sabe, os SE descrevem o conhecimento no formato Se-Então, no caso de uma
regra Bayesiana, este formato é acrescido de um fator de probabilidade:
Se X é verdadeiro
Então Y pode ser concluído com probabilidade p
Por exemplo:
Se o paciente está resfriado
Então o paciente irá espirrar (0.75)
Contudo, o que ocorre quando se observa a presença de Y (i.e. o paciente espirrou) sem
nada se saber sobre a existência de X (ou seja, o paciente está resfriado)?
O que se pode concluir sobre a possibilidade do paciente estar resfriado?
Neste contexto, uma regra bayesiana descreve como calcular esta probabilidade.
p(H | E) - a probabilidade da existência da hipótese H dada a existência do evento E.
p(H) e p(E) - descrevem as probabilidades das existências da hipótese H e evento E,
respectivamente
Exemplo: sejam H- hipótese e E- evidência
Considerando que:
)(
)(*)|()|(
Ep
HpHEpEHp =
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
58
H- paciente esteja resfriado, E- paciente está espirrando
p(H)= p(paciente esteja resfriado)= 0.2
p(E | H)= p(paciente esteja espirrando | ele esteja resfriado)= 0.75
p(E | ~H)= p(paciente esteja espirrando | ele não esteja resfriado)= 0.2
Então
p(E)= p(paciente esteja espirrando)
Observação: vale destacar que a probabilidade de certo efeito dada uma certa hipótese,
ou seja, p(E | H), é o fundamento de toda a construção da base de conhecimento, e deve ser
conhecida a priori.
Calcular a probabilidade do paciente estar resfriado considerando o fato dele estar
espirrando.
P(H|E) =(0.75)*(0.2)/(0.31)= 0.48387
Calcular a probabilidade do paciente estar resfriado considerando que ele não esteja
espirrando.
Sendo assim o fato do paciente estar espirrando aumenta a probabilidade dele estar
resfriado de aproximadamente 2,5 vezes (de 0.2 para 0.48). Enquanto que o fato dele não estar
espirrando diminui a probabilidade de estar resfriado de 3 vezes.
No exemplo apresentado, uma evidência afeta apenas uma hipótese. Contudo isto deve
ser generalizado pelo fato de que no mundo real se trabalha com "m" hipóteses e "n"
evidências.
31.0)8.0(*)2.0()2.0(*)75.0()(
)(~*)|~()(*)|()(
=+=
+=
Ep
HpHEpHpHEpEp
)(
)(*)|()|(
Ep
HpHEpEHp =
07246.0)31.01(
)2.0(*)75.01(
)(~
)(*)|(~)|~( =
−
−==
Ep
HpHEpEHp
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
59
Desta forma a equação que determina a probabilidade de uma certa hipótese Hi baseada
num conjunto de evidências E1, E2...En, é dada por:
Esta probabilidade é definida como a probabilidade a posteriori da hipótese Hi com a
observação das evidências E1, E2...En.
Tal equação é derivada do fato de que as evidências são eventos condicionalmente
independentes com base na hipótese. Esta suposição causa dificuldades na implementação
deste método.
A fim de exemplificar a aplicação deste método considere o seguinte problema:
Três hipóteses mutuamente exclusivas
H1- paciente resfriado
H2- paciente é alérgico
H3- paciente é sensível à luz
E duas evidências condicionalmente independentes
E1- paciente espirra e E2- paciente tosse
Apresenta-se a seguinte tabela de probabilidades
i=1
(resfriado)
i=2
(alergia)
i=3
(sensibilidade à luz)
p(Hi) 0.6 0.3 0.1
p(E1|Hi) 0.3 0.8 0.3
p(E2|Hi) 0.6 0.9 0.0
Neste caso, sendo observada a evidência E1 (paciente espirra), pode-se calcular a
probabilidade posterior da hipótese do paciente estar resfriado (H1)
)...(
)(*)|...()...|(
21
2121
n
iinni
EEEp
HpHEEEpEEEHp =
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
60
17.1.1. Vantagens e desvantagens das Redes Bayesianas
O aspecto mais significante é que este método é fundamentado na lei das probabilidades.
É considerada a forma mais bem estabelecida de todos os métodos de manipulação de
incerteza. Também possui uma semântica bem definida para suporte à decisão.
Algumas desvantagens
• Este método requer uma significante quantidade de dados probabilísticos para
construir a base de conhecimento. Por exemplo, um sistema de diagnóstico tendo 50
conclusões detectáveis (p) e 300 características observáveis e relevantes (q) requer um
mínimo de 15050 (p*q + p) valores de probabilidades, assumindo que todas as conclusões
sejam eventos mutuamente exclusivos, que as características sejam condicionalmente
independentes para cada conclusão e se todas as características são valores coerentes. Caso
estas considerações não sejam satisfeitas a inteira rede pode ser comprometida.
• Em que são baseadas as probabilidades usadas?
Se estas são baseadas em estatística, o tamanho das amostras deve ser suficiente de tal
forma que as probabilidades obtidas sejam precisas. Se os valores foram fornecidos por
especialistas humanos, estes valores são consistentes e amplos?
• Com freqüência o tipo de relação entre a hipótese e a evidência é importante para
determinar como a incerteza deve ser modelada. Reduzir esta associação a simples números
remove informações relevantes que podem ser necessárias para uma manipulação adequada
da incerteza. Por exemplo, redes bayesianas para sistemas de diagnóstico médico falharam em
obter aceitação, pois médicos desconfiam de sistemas que não possam fornecer explicações
descrevendo as conclusões obtidas, tal aspecto é difícil de modelar via rede bayesiana.
4.01.0*3.03.0*8.06.0*3.0
6.0*3.0
)(*)|(
)(*)|()|(
1
11111 =
++==
∑ ii HpHEp
HpHEpEHp
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
61
• A redução das associações a números também elimina a aplicação deste conhecimento
em outras tarefas. Por exemplo, neste tipo de sistema as associações que permitiriam explicar
o encadeamento lógico ao usuário são perdidas.
18. Lógica Difusa (Fuzzy Logic)
Em meados da década de 60, Zadeh desenvolveu o conceito de conjuntos difusos para
considerar vários conceitos usados no raciocínio humano que são intrinsecamente vagos e
imprecisos, tais como alto, velho, etc... Mais tarde ele desenvolveu a lógica difusa para
considerar a imprecisão de "quantificadores" usados na linguagem natural, tais como muito,
poucos, etc...
Pelo fato de que muitos especialistas expressam seu conhecimento usando conceitos
similares aos conjuntos difusos, a lógica difusa aplica-se naturalmente aos sistemas
especialistas.
18.1. Definição de termos
Dado um conjunto S={S1,S2,...,Sk} de possíveis membros de um outro conjunto C, o
predicado difuso Fp classifica os membros de S na faixa [0 1] dependendo do grau de
pertinência em relação ao conjunto C.
Fp(Si) -> [0 1]
Fp(Si)= 1 define a pertinência de Si em relação a C, e
Fp(Si)= 0 define a não-pertinência
Os valores entre 0 e 1 descrevem a medida do grau com que um dado elemento Si
satisfaz um certo predicado Fp. Sendo assim, este predicado define o conjunto difuso.
Sp= {<si ni> si ∈ S, ni ∈ [0 1], Fp(si)= ni}
Todas as operações fundamentais da teoria de conjuntos foram expandidas com seus
correspondentes conjuntos difusos.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
62
• dois conjuntos difusos Sa e Sb são iguais se e somente se A(Si)=B(Si) para todos
elementos Si.
• O complemento de um conjunto difuso Sp é definido como ~Sp e tem o predicado
Fp~(Si)= 1- Fp(Si).
• O conjunto difuso Sa é um subconjunto de Sb se e somente se A(Si)≤ B(Si) para todos
elementos Si.
• A união de dois conjuntos difusos, Sa e Sb , é um conjunto difuso Sc onde C(Si)=
MAX[A(Si), B(Si)] para todos Si.
• A interseção de dois conjuntos difusos, Sa e Sb , é um conjunto difuso Sc onde C(Si)=
MIN[A(Si), B(Si)] para todos Si.
Exemplo classificação de pessoas conforme a altura
Altura alto baixo gigante
1,5 0.00 1.00 0.00
1,6 0.08 0.92 0.04
1,7 0.32 0.68 0.08
1,75 0.50 0.50 0.18
1,8 0.82 0.18 0.32
1,9 0.98 0.02 0.50
2,0 1.00 0.00 0.75
Esta tabela representa três conjuntos difusos (alto, baixo e gigante) com seus valores de
pertinência (ni).
Como se definem os conjuntos "estatura média" e "não estatura média"?
Pode-se dizer que estatura média é definida como um indivíduo nem alto e nem baixo.
Portanto é a interseção dos conjuntos "não alto" e "não baixo". E por definição o conjunto
"não estatura média" é o complemento desse. Sendo assim, tem-se:
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE ENGENHARIA MECÂNICA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
Sistemas Especialistas aplicados à Engenharia Prof. Jonny Carlos da Silva, Dr. Eng.
63
Altura Não alto Não baixo Estatura
média
Não
Estatura média
1,5 1.00 0.00 0.00 1.00
1,6 0.92 0.08 0.08 0.92
1,7 0.68 0.32 0.32 0.68
1,75 0.50 0.50 0.50 0.50
1,8 0.18 0.82 0.18 0.82
1,9 0.02 0.98 0.02 0.98
2,0 0.00 1.00 0.00 1.00
Por exemplo, se João tem entre 1,70 e 1,75 a possibilidade dele ser considerado alto será:
Poss (João ∈ Alto)= MAX ni ∈ {1,70; 1,75}= 0,50
18.2. Operadores difusos
• & lógico. Poss(A & B)= MIN [Poss(A),Poss(B)]
• OU lógico. Poss(A + B)= MAX [Poss(A),Poss(B)]
• Implica. A proposição de que se A então B Poss(B|A)= MIN[1, (1-Poss(A) +Poss(B))]
Modificadores comumente usados: "muito" muito A= A2 "não" não A= 1-A "extremamente" A =2A2 para valores entre 0 e 0.5
=(1- 2(1-A)2) para outros valores
Este operador de intensificação reduz o grau de "difusão" do conjunto.
Apesar desta técnica ser amplamente aplicada, ainda existe o debate sobre sua
viabilidade tendo em vista as dificuldades inerentes à técnica. Sobretudo, o desenvolvimento
das funções de pertinência não é trivial, e geralmente requer um tempo mais longo que o
desenvolvimento da base de conhecimento.
AAmenosoumais =±"...."