UM FRAMEWORK PARA SISTEMAS BASEADOS EM CONHECIMENTO NO CONTEXTO DA METODOLOGIA COMMONKADS

(1)

G ´ECEN DACOME DE MARCHI

UM FRAMEWORK PARA SISTEMAS BASEADOS EM CONHECIMENTO NO CONTEXTO DA METODOLOGIA

COMMONKADS

MARING ´A 2010

(2)

(3)

G ´ECEN DACOME DE MARCHI

UM FRAMEWORK PARA SISTEMAS BASEADOS EM CONHECIMENTO NO CONTEXTO DA METODOLOGIA

COMMONKADS

Dissertação apresentada ao Programa de Pós-Gradução em Ciência da Computação da Universidade Estadual de Maringá, como requisito para obtenção do grau de Mestre em Ciência da Computação.

Orientadora: Profa. Dra. Maria Madalena Dias

MARING ´A 2010

(4)

Dados Internacionais de CatalogaçãonaPublicação (CIP) (Biblioteca Central UEM, Maringá – PR., Brasil)

Marchi, Gécen Dacome

M317m Um framework para sistemas baseados em

conhecimento no contexto da metodologia CommonKADS / Gécen Dacome Marchi. Maringá, 2010.

77 p. : il., figs.

Orientadora : Profª. Drª. Maria Madalena Dias.

Dissertação (mestrado) Universidade Estadual de Maringá, Programa de PósGraduação em Ciência da Computação, 2010.

1. Framework CommonKADS. 2. Sistema de conhecimento Cloud computing Framework

CommonKADS. 3. CommonKADS. 4. Computação nas nuvens.

I. Dias, Maria Madalena, orient. II. Universidade Estadual de Maringá. Programa de PósGraduação em Ciência da Computação. III. Título.

CDD 21.ed. 006.332

(5)

(6)

(7)

Agradecimentos

A minha esposa, por me apoiar e ter sido paciente com as longas noites de estudo.` Ao meu filho, por ter sido fonte de inspiração e se privar de minha presença.

Aos meus pais, me confortando com palavras de confianc¸a e incentivo.

A minha orientadora pelo seu apoio e presença durante a realização deste trabalho.`

Ao meu amigo Maur´ılio, que me incentivou e não negou esforços para me ajudar desde os primeiros dias do Mestrado até a entrega deste trabalho.

A toda a coordenadoria do Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, pela compreensão, apoio e oportunidade de estar concluindo este curso.

A CAPES - Coordenação de Aperfeiçoamento de Pessoal de N´ıvel Superior, pelo ininter- rupto apoio financeiro.

i

(8)

ii

(9)

Resumo

O processo de desenvolvimento de sistemas de conhecimento exige metodologias espec´ıficas, sendoCommonKADSa mais conhecida e utilizada atualmente. Para agilizar esse processo, podem ser usados frameworks que têm como objetivos a reutilização e a obtenção de software com alta coesão e baixo acoplamento. Estas caracter´ısticas são desejadas pelos engenheiros e desenvolvedores de software, principalmente por facilitarem a manutenção. A alta dependência de especialistas de dom´ınio durante o desenvolvimento e o uso de sistemas de conhecimento leva a uma maior exigência de comunicação, tanto entre os desenvolvedores e esses especialistas quanto entre esses

últimos e o sistema. A comunicação entre o desenvolvedor e os especialistas de dom´ınio pode ser facilitada com a construção dos modelos da metodologiaCommonKADS, os quais são utilizados para representação do conhecimento e das caracter´ısticas gerais do sistema a ser implementado. Para aumentar a disponibilidade de sistemas de conhecimento e facilitar a sua comunicação com os especialistas de dom´ınio e demais usuários, pode-se usar serviços WEB. A principal contribuição deste trabalho é o desenvolvimento de umframework, denominado Knowframe auxilia a construção de sistemas de conhecimento, facilitando o mapeamento dos conceitos da metodologiaCommonKADSpara implementação de sistemas de conhecimento e preservando a estrutura de projeto. Este frameworkpossibilita também, que esses sistemas sejam disponibilizados como serviços WEB de forma simples e transparente ao desenvolvedor.

iii

(10)

iv

(11)

Abstract

In addition to requiring the use of methodologies, techniques and tools for building knowledge systems, as in the development of any kind of software should be considered the complexity of these systems and high dependence on domain experts. The complexity ranges from the acquisition of knowledge and explanation to its representation and distribution. To make the process of developing systems for more systematic knowledge, there are specific methodologies, CommonKADS is the best known and currently used, and to expedite this process can be used as frameworks that have goals and achieving reuse of software with high cohesion and loosely. These characteristics are desired by the engineers and software developers, especially by facilitating maintenance. The high dependence on domain experts during the development and use of systems of knowledge leads to greater demand for communication both among developers and experts such as between the latter and the system. Communication between developers and domain experts can be facilitated with the construction of models of the CommonKADS methodology, which are used for knowledge representation and general characteristics of the system being implemented. To increase the availability of knowledge and facilitate their communication with domain experts and other users, you can use web services. In this context, this paper presents a Framewok developed according to the CommonKADS design methodology, where the main concern is the manner of acquisition and knowledge representation. This framework, as well as facilitate the construction of knowledge systems, enables these systems are available as web services.

v

(12)

vi

(13)

Sum ´ario

Lista de Figuras ix

Lista de Tabelas xi

1 Introduc¸˜ao 1

1.1 Contexto e Motivac¸˜ao . . . 1

1.2 Objetivos . . . 2

1.2.1 Objetivos espec´ıficos: . . . 2

1.2.2 Contribuic¸˜oes . . . 2

1.3 Metodologia . . . 3

1.4 Organizac¸˜ao do Trabalho . . . 4

2 Revisão Bibliográfica 7 2.1 Considerações Iniciais . . . 7

2.2 Engenharia do Conhecimento . . . 7

2.2.1 CommonKADS . . . 8

2.2.2 Modelo do Conhecimento . . . 10

2.2.3 Modelo de Projeto . . . 18

2.2.4 Outras Metodologias . . . 29

2.3 Computac¸˜ao nas nuvens . . . 31

2.4 Frameworks . . . 34

2.4.1 Classificac¸˜ao . . . 35

2.4.2 Padr˜oes de Projeto . . . 36

2.5 Trabalhos Relacionados . . . 39

2.5.1 KBeansShell . . . 39

2.5.2 Knowledge Representation Package . . . 40

2.5.3 UPML(Unified Problem-solving Method Development Language): A Framework for knowledge system reuse . . . 41

2.6 Considerac¸˜oes Finais . . . 42

3 OFrameworkKnowframe 43 3.1 Considerac¸˜oes Iniciais . . . 43

3.2 Vis˜ao Geral . . . 43

3.3 Projeto doFramework . . . 44

3.3.1 Caso de Uso: EnviarPlugins . . . 44

vii

(14)

3.3.2 Caso de Uso: Gerenciar Bases de Conhecimento . . . 47

3.3.3 Caso de Uso: Executar Tarefa . . . 50

3.3.4 Caso de Uso: Recuperar Processamento . . . 52

3.4 A APITask Plugin . . . 55

3.4.1 Requisitos para Implementac¸˜ao de umPlugin . . . 58

3.4.2 Realizando requisic¸˜oes aosPlugins . . . 59

3.5 Mapeamento da MetodologiaCommonKADSpara o Knowframe . . . 60

3.6 Ferramentas Utilizadas . . . 61

4 Aplicação do Knowframe 63 4.1 Considerações Iniciais . . . 63

4.2 Modelo do Conhecimento . . . 63

4.3 Modelo de Projeto . . . 64

4.4 Registro e Teste doPlugin . . . 65

5 Conclus˜oes 71 5.1 Trabalhos futuros . . . 72

Referˆencias Bibliogr´aficas 73

viii

(15)

Lista de Figuras

1.1 Metodologia . . . 4

2.1 Modelos doCommonKADS . . . 9

2.2 Exemplo de Conceito (CONCEPT) . . . 13

2.3 Exemplo de Relac¸˜ao(BINARY-RELATION) . . . 13

2.4 Exemplo de Tipo de Regra . . . 14

2.5 Exemplo de Base de Conhecimento . . . 15

2.6 Exemplo de Inferˆencia - adaptado de (Schreiber et al., 1999) . . . 16

2.7 Exemplo de Tarefa - adaptado de (Schreiber et al., 1999) . . . 18

2.8 Projeto e Implementac¸˜ao . . . 19

2.9 Arquitetura de Referˆencia . . . 22

2.10 Arquitetura de Referˆencia - Modelo do Aplicativo . . . 23

2.11 O padr˜aoPlugin . . . 38

3.1 Vis˜ao Geral dos M´odulos doFramework . . . 45

3.2 Diagrama de Casos de Uso . . . 46

3.3 Diagrama de Classes - EnviarPlugins . . . 47

3.4 Diagrama de Sequˆencia 1 - EnviarPlugins . . . 48

3.5 Diagrama de Sequˆencia 2 - EnviarPlugins . . . 48

3.6 Diagrama de Classes - Gerenciar Bases de Conhecimento . . . 49

3.7 Diagrama de Sequˆencia - Listar Bases de Conhecimento . . . 50

3.8 Diagrama de Sequˆencia - Listar Esquemas . . . 50

3.9 Diagrama de Sequˆencia - Listar Tipos de Regra . . . 51

3.10 Diagrama de Sequˆencia - Editar e Salvar Regras . . . 51

3.11 Diagrama de Classes - Executar Tarefa . . . 53

3.12 Diagrama de Sequˆencia - Editar e Salvar Rule Type . . . 54

3.13 Diagrama de Classes - Recuperar Processamento . . . 54

3.14 Diagrama de Sequˆencia - Recuperar Processamento . . . 55

3.15 Diagrama de Classes - APITask Plugin . . . 56

3.16 Diagrama de Classes -Anotac¸˜oes. . . 57

3.17 Diagrama de Classes -Dom´ınio . . . 58

3.18 Exemplo de Implementac¸˜ao dePlugin . . . 59

3.19 Exemplo de URL - Execuc¸˜ao de Tarefa . . . 59

3.20 Exemplo de URL - Recuperac¸˜ao de Processamento . . . 60

4.1 Modelo do Conhecimento - CML . . . 64 ix

(16)

4.2 Diagrama de Classes . . . 66

4.3 Utilização da anotaçãoRuleTypeInstance. . . 66

4.4 GUI para envio e registro dePlugins . . . 67

4.5 GUI para alteração de Expressões . . . 67

4.6 GUI - Teste . . . 68

4.7 GUI - Resposta do Teste . . . 69

x

(17)

Lista de Tabelas

2.1 Sum´ario de caracter´ısticas das metodologias para sistema baseado em conhecimento. Fonte (Dias e Pacheco, 2009) . . . 30 3.1 Mapeamento da MetodologiaCommonKADSpara o Knowframe . . . 62

xi

(18)

xii

(19)

Lista de Siglas

XML:Extensible Markup Language

OKBC:Open Knowledge Base Connectivity

UPML:Unified Problem-solving Method Development Language KBS:Knowledge-based Systems

PSM:Problem-solving Methods

CORBA:Common Object Request Broker Architecture ORB:Object Request Broker

DCOM:Distributed Component Object Model ODMG:Object Data Management Group OMT:Object Modelling Technique

OOSE:Object Oriented Software Engineering RDD:Responsibility Driving Design

SDL:Specification and Description Language MSC:Message Sequence Charts

MAS:Multiagent Systems

UML:Unified Modeling Language;

MOO:A Methodology for Online Optimization through Mining the Offline Optimum;

SPEDE:Structured Process Elicitation and Demonstration Environment;

MIKE:Model-based and Incremental Knowledge Engineering;

MOKA:Methodology for Knowledge-Based Engineering Applications;

OTK:On-To-Knowledge;

XP.K:eXtreme Programming of Knowledge-based systems;

CML:CommonKADS Model Language DFD: Diagrama de Fluxo de Dados MVC: Modelo-Visualizac¸˜ao-Controle ATM:Asynchronous Transfer Mode REST:Representational State Transfer API:Application Programming Interface HTTP:HyperText Transfer Protocol GUI:Graphical User Interface

JEE:Java Platform Enterprise Edition JSP:Java Server Pages

URL:Uniform Resource Locator XSD:XML Schema Definition

IDE:Integrated Development Environment

xiii

(20)

xiv

(21)

C

AP

´

ITULO

1 Introduc¸ ˜ao

1.1 Contexto e Motivac¸ ˜ao

Além da exigência do uso de metodologias, técnicas e ferramentas para a construção de sistemas de conhecimento, como ocorre no desenvolvimento de qualquer tipo de software, devem ser consideradas também a complexidade desses sistemas e a alta dependência de especialistas de dom´ınio. A complexidade vai desde a aquisição e elucidação do conhecimento até a sua representação e distribuição.

Dessa forma justifica-se o surgimento de diversas metodologias com o objetivo de fornecer suporte à construção de aplicativos para gestão de conhecimento, tais como: Vital (Shadbolt et al., 1993), SPEDE (Structured Process Elicitation and Demonstration Environment) (Cottam et al., 1998), CommonKADS (Schreiber et al., 1994), MAS-CommonKADS (Iglesias et al., 1998), MIKE (Model-based and Incremental Knowledge Engineering) (Angele et al., 1998a), MOKA (Methodology for Knowledge-Based Engineering Applications) (Oldham et al., 1998), OTK (On-To-Knowledge) (Sure e R., 1999), XP.K (eXtreme Programming of Knowledge-based systems) (Knublauch, 2002).

Dentre elas se destaca a Metodologia CommonKADS que fornece suporte a todo o processo de especificação de um sistema de conhecimento e é, atualmente, a mais utilizada no desenvolvimento de sistema baseado em conhecimento, conforme (Sutton e Patkar, 2009), (Silva, 2008), (Viegas et al., 2006), (Vieira, 2006), (Lambert et al., 2005), (Ko e Vas, 2003), (Post et al., 1997) e (Sandberg e de Hoog, 1996).

1

(22)

2 1. Introdução Por outro lado, observa-se uma corrida por grandes organizações como: VMware, Sun Microsystem, IBM, Amazon, Google, Micrisoft e Yahoo para disponibilizar infra-estrutura onde serviços baseados na web possam ser disponibilizados para atender a grande demanda de clientes que consomem este tipo de serviço (Leigang e Mingqing, 2009) (Maggiani, 2009) (Zhang e Zhou, 2009) (Vouk, 2008).

Porém, segundo (Schreiber et al., 1999), a utilização de CommonKADS, desenvolvimento de sistemas de conhecimento que possibilitem a disponibilização de serviços web, são questões de investigação e, mesmo relatando que pesquisas estavam sendo realizadas, não se encontrou nenhum trabalho publicado.

E neste contexto que se insere este trabalho, cujo propósito é possibilitar aos aplicativos que´ tenha sido projetados utilizando CommonKADS possam ser disponibilizados por ambientes web e que possam ser consumidos por clientes. Também facilitar o mapeamento do projeto para a implementação.

1.2 Objetivos

O objetivo deste trabalho é o desenvolvimento do Knowframe, umFrameworkpara o dom´ınio de aplicações constru´ıdas para gestão de conhecimento, baseadas na metodologia Common- KADSe por meio desteFrameworkdisponibilizar serviços web.

1.2.1 Objetivos espec´ıficos:

• Aprofundar o entendimento de engenharia e gest˜ao de conhecimento, especificamente da metodologiaCommonKads;

• Estudar os conceitos e fundamentos deFrameworkse Padr˜oes de Projeto, para identificar os padr˜oes de projeto adequados para neste trabalho;

• Projetar oFrameworkutilizando UMLUnified Modeling Language;

• Realizar uma aplicação prática usando oframeworkknowframe.

1.2.2 Contribuic¸ ˜ oes

A principal contribuição deste trabalho é a disponibilização do Framework Knowframe, desenvolvido na linguagem de programação Java, que é uma das linguagens mais populares atualmente.

(23)

1.3 Metodologia 3 Outra contribuição é a aplicação prática realizada poderá servir de referência na construção de sistemas de gestão de conhecimento, para projetos que utilizem técnicas de Orientação a Objetos, em outras linguagens de programação.

Além de facilitar a utilização doCommonKADSo Knowframe deve contribuir para que as aplicações constru´ıdas com esta metodologia possuam propriedades como: alta coesão e baixo acoplamento, arquitetura plugável e orientada a interfaces, facilidade de realização de alterações promovendo maior reuso.

1.3 Metodologia

A presente trabalho é de caráter exploratório e de natureza qualitativa, envolvendo pesquisa bibliográfica e documental. Qualitativa porque considera que há um v´ınculo indissociável entre o mundo objetivo e a subjetividade do sujeito que não pode ser traduzida em números (Gil, 1991). Não requer o uso de métodos e técnicas estat´ısticas (Silva e Menezes, 2001).

Exploratória, pois, visa proporcionar maior familiaridade com o problema com vistas a torná-lo expl´ıcito ou construir hipóteses. Neste caso, faz-se uso de levantamento bibliográfico e análise de exemplos que estimulem a compreensão (Gil, 1991).

Como ilustrado na Figura 1.1 iniciou-se este trabalho realizando um levantamento bibli- ográfico sobre CommonKADS, Frameworks e Computação nas Nuvens. A respeito de Com- monKADSgrande ênfase foi dada aos Modelos do Conhecimento e de Projeto devido à maior relevância destes modelos para este trabalho. Após realizado o estudo sobre Frameworks classificou-se este como umFrameworkde dom´ınio de aplicação e também foram identificadas caracter´ısticas comuns entre o objetivo de um Framework e da metodologia CommonKADS, um exemplo é a reutilização de análise, projeto e código. Computação nas Nuvens é atualmente muito utilizada e disponibilizada por várias empresas, sendo esta a motivação para que este Frameworkfosse executado e disponibilizado em um ambiente de execução que pudesse prover suas funcionalidades como serviço.

Após a realização dos estudos iniciais deste trabalho, seguiu-se com a identificação dos principais requisitos e melhores práticas de construção de uma aplicação utilizando Common- KADS, que serviu de linha guia para a fase de definição daAPIna etapa de Projeto. Nesta etapa, além da definição daAPIe dos metadados sobre os artefatos de codificação doFramework, foi definido como os serviços do ambiente poderiam ser disponibilizados para serem acessados pelos clientes, optou-se por uma arquiteturaREST.

Definido aAPI e o ambiente de Execução doFramework seguiu-se com a implementação da API do Framework e do ambiente de Execução seguido de uma aplicação do Knowframe, servindo de exemplo para a análise e compreensão.

(24)

4 1. Introduc¸˜ao

Figura 1.1:Metodologia

Ressalta-se que a ilustração da figura 1.1 não demonstra a natureza c´ıclica da construção deste trabalho pois a cada fase retornava-se nas fases anteriores quando se fazia necessário.

1.4 Organizac¸ ˜ao do Trabalho

Este trabalho est´a organizado da seguinte forma:

No Cap´ıtulo 2 são apresentados os principais conceitos que fundamentam a realização deste trabalho.

(25)

1.4 Organização do Trabalho 5 O Cap´ıtulo 3 é descrito o trabalho incluindo uma visão geral doFramework e detalhes do projeto e implementação.

O Cap´ıtulo 4 ´e demostrado o estudo de caso desenvolvido utilizando oFrameworkproposto.

Por fim, no Cap´ıtulo 5 são apresentadas a conclusão, sugestões e trabalhos futuros.

(26)

6 1. Introduc¸˜ao

(27)

C

AP

´

ITULO

2 Revis ˜ao Bibliogr ´afica

2.1 Considerac¸ ˜ oes Iniciais

Neste cap´ıtulo são apresentados os principais conceitos e caracter´ısticas das áreas envolvidas neste trabalho. Inicia-se pela metodologia CommonKADS, o segundo item apresentado é Computação nas nuvens e é realizado também uma descrição sucinta do estilo REST. Para que haja um bom entendimento sobre a importância do uso deframeworksno desenvolvimento de software, é necessário sua descrição, conforme é apresentado neste cap´ıtulo.

Também faz parte deste cap´ıtulo, a descrição sucinta de trabalhos encontrados na literatura que, de uma forma ou outra contribu´ıram para a realização deste trabalho.

2.2 Engenharia do Conhecimento

A engenharia do conhecimento evoluiu a partir do final dos anos de 1970 em diante, vem da arte de construir sistemas especialistas, sistemas baseados em conhecimento e sistemas de conhecimento intensivo. Schreiber et al. (1999) utiliza esses termos indistintamente, mas a final o que ´e conhecimento?

Conhecimento é um termo que todos nós temos um bom entendimento intuitivo do que significa, mas é dif´ıcil de definir de uma maneira formal. Muitas pessoas tentam chegar a definições satisfatórias, mas essas parecem ser boas aproximações. Do ponto de vista de engenharia de sistemas, a melhor maneira de ver o conhecimento é como um tipo especial

7

(28)

8 2. Revisão Bibliográfica de informação, dessa forma a Engenharia do conhecimento visa fornecer ferramentas e técnicas para modelar e representar o conhecimento (Schreiber et al., 1999).

2.2.1 CommonKADS

Segundo Schreiber et al. (1994) CommonKADS é resultante de uma série de pesquisas internacionais e projetos de aplicações de engenharia do conhecimento desde 1983. A metodologia tem sido progressivamente estendida, oferecendo uma abordagem estruturada que é baseada em alguns pensamentos ou princ´ıpios adquiridos a partir da experiência dos autores, pesquisadores e colaboradores ao longo dos anos. Os princ´ıpios fundamentais são (Schreiber et al., 1994):

• Engenharia do conhecimento não é um tipo de ”mineração na cabeça do especialista”, mas consiste em construir modelos de diferentes aspectos do conhecimento humano.

Na visão doCommonKADS, um projeto de conhecimento implica na construção de um conjunto de modelos que juntos são partes importantes dos produtos entregues pelo projeto.

• O princ´ıpio do n´ıvel de conhecimento: na modelagem do conhecimento, primeiro concentra-se na estrutura conceitual do conhecimento, deixando os detalhes de programac¸˜ao para mais tarde.

Na visão do CommonKADS, o conhecimento deve ser modelado para refletir o dom´ınio do mundo real e o artefato gerado deve preservar a estrutura conceitual da análise do conhecimento que é chamado de projeto de preservação da estrutura.

• Conhecimento tem uma estrutura interna estável que é analisável por distinguir papéis e tipos de conhecimentos espec´ıficos.

O conhecimento pode ser complexo, mas não é caótico, o conhecimento parece ter uma estrutura interna bastante estável, no qual reconhecemos padrões semelhantes.

• Um projeto de conhecimento deve ser gerenciado pelo aprendizado de suas experiˆencias utilizando um modelo espiral controlado.

CommonKADSfavorece uma abordagem de gestão configurável e equilibrada do projeto, mais flex´ıvel do que o modelo em cascata e mais controlada do que prototipagem rápida.

A Figura 2.1 apresenta o conjunto de modelos doCommonKADS que é a expressão con- creta dos princ´ıpios fundamentais citados anteriormente e constitui o núcleo da metodologia CommonKADS. Os modelos estão separados em três grupos pois devem responder as seguintes perguntas (Schreiber et al., 1994):

(29)

2.2 Engenharia do Conhecimento 9

Figura 2.1:Modelos doCommonKADS (Schreiber et al., 1999)

1. Por quê? - Por que um sistema de conhecimento é uma solução em potencial? Para quais problemas? Que benef´ıcios, custos e impactos organizacionais ele terá? O entendimento do ambiente e do contexto organizacional é o ponto mais importante deste questionamento.

2. Qual? - Qual é a natureza e a estrutura do conhecimento envolvidos? Qual a natureza e a estrutura de comunicação correspondentes? Obter a descrição conceitual do conhecimento utilizado na realização de uma tarefa é um dos pontos chave deste questionamento.

3. Como? - Como o conhecimento deve ser implementado no sistema computacional?

Como a arquitetura de software e os mecanismos computacionais devem ser vistos. Os aspectos técnicos da implementação são o principal foco neste questionamento.

Um conjunto pré-definido de modelos cada um focando um aspecto responde a todas as essas perguntas. Apesar de cada um dos modelos direcionar o detalhamento de um aspecto, todos juntos fornecem uma visão para compreensão do problema. A seguir, estes modelos estão descritos conforme Schreiber et al. (1994):

Modelo da Organização: apoia a análise das principais caracter´ısticas de uma organização, a fim de descobrir problemas e oportunidades para sistemas de conhecimento, estabelecer sua viabilidade e avaliar o impacto das ações de conhecimento pretendidas na organização.

(30)

10 2. Revisão Bibliográfica Modelo da Tarefa: representa as subpartes relevantes de um processo de negócio. O modelo de tarefa analisa o layout global da tarefa, suas entradas e sa´ıdas, pré-requisitos e critérios de desempenho, bem como dos recursos e competências necessários.

Modelo do Agente: responsável pela execução das tarefas, descreve as caracter´ısticas dos agentes, em particular suas competências, autoridades e restrições para agir. Além disso, relaciona as ligações de comunicação entre agentes necessários para executar uma tarefa.

Modelo do Conhecimento: o objetivo do modelo de conhecimento é explicar em detalhes os tipos e estruturas do conhecimento utilizados na realização de uma tarefa. Descreve o conhecimento envolvido no dom´ınio do projeto. Com este modelo, é poss´ıvel detalhar como o conhecimento está relacionado em cada tarefa, quais agentes o possuem e como seus componentes relacionam-se entre si. O modelo do Conhecimento deve ser compreendido pelas pessoas que estão envolvidas no projeto, pois deve ser um importante ve´ıculo de comunicação entre especialistas e usuários.

Modelo de Comunicação: é responsável por modelar a transação de comunicação entre os agentes envolvidos em uma tarefa, de forma independente de implementação ou de conceito, como ocorre no modelo de conhecimento.

Modelo do Projeto: os modelos anteriores podem ser vistos como especificações de requisitos para um sistema de conhecimento. O modelo do projeto deve conter a conversão das informações contidas nos modelos anteriores, consideradas como especificações de requisitos, em especificações técnicas do sistema quanto à arquitetura, plataforma de implementação, módulos de softwares, construtores de representação e mecanismos computacionais necessários para implementar as funções verificadas nos modelos de conhecimento e de comunicação.

Na Figura 2.1 observa-se que os modelos de organização, tarefa e agente são os fatores cr´ıticos de sucesso para a construção de um sistema de conhecimento, pois capturam as informações base para os próximos modelos. Os modelos de conhecimento e de comunicação produzem uma descrição conceitual das funções e dados que devem ser capturados e entregues por um sistema de conhecimento, e o modelo de projeto converte tudo em uma especificação técnica que serve de apoio para a implementação do software.

Nas subseções 2.2.2 e 2.2.3 os Modelos de Conhecimento e de Projeto são detalhados, pois estes se fazem relevantes para este trabalho.

2.2.2 Modelo do Conhecimento

Nesta subseção, são apresentados conceitos e caracter´ısticas do modelo de conhecimento conforme Schreiber et al. (1994).

(31)

2.2 Engenharia do Conhecimento 11 O modelo de conhecimento é uma ferramenta que nos ajuda a esclarecer a estrutura de uma tarefa de processamento da informação intensiva de conhecimento. O modelo de conhecimento da aplicação fornece uma especificação dos dados e das estruturas de conhecimento necessária para a aplicação. O modelo foi desenvolvido como parte do processo de análise. É, portanto, formulado no vocabulário da aplicação, ou seja, tanto no dom´ınio (por exemplo, carros, casas, navios) e quanto na tarefa de racioc´ınio (por exemplo, a avaliação, a configuração, diagnóstico).

O modelo de conhecimento não contém quaisquer termos de implementação espec´ıficos, estes são deixados para a fase de projeto.

O modelo de conhecimento tem uma estrutura que é, em essência, semelhante aos modelos tradicionais de análise em engenharia de software. A tarefa de racioc´ınio é descrita por meio de uma decomposição hierárquica de funções ou ”processos”. Os tipos de dados e conhecimentos que as funções operam são descritos utilizando-se de um esquema semelhante a um modelo de dados ou modelo de objetos. As notações são, em propósito, similares aquelas encontrados em outros métodos contemporâneos.

Um modelo de conhecimento possui trˆes partes, cada uma captura um grupo de estruturas de conhecimento relacionadas. Cada parte ´e uma categoria de conhecimento. A primeira categoria

é chamada de conhecimento do dom´ınio, esta categoria indica o conhecimento espec´ıfico do dom´ınio e tipos de informações necessárias para comunicação a respeito do mesmo. A segunda categoria do modelo de conhecimento contém o conhecimento de inferência, este descreve os passos básicos de inferência necessárias para fazer uso do conhecimento do dom´ınio. Esta categoria pode ser vista como blocos de construção do racioc´ınio de máquina. Na engenharia de software, as inferências constituem o mais baixo n´ıvel de decomposição funcional. A terceira categoria de conhecimento é o conhecimento de tarefa, que descreve os objetivos que uma aplicação tem como fim, e como estes objetivos podem ser realizados por meio de uma decomposição em sub-tarefas e (ultimamente) inferências.

Nos pr´oximos sub-itens s˜ao apresentados os detalhes de cada categoria de conhecimento.

Conhecimento de Dom´ınio

O conhecimento do dom´ınio descreve as principais informações estáticas e objetos do conhecimento em um dom´ınio de aplicação. Uma descrição de conhecimento de dom´ınio consiste em um ou mais esquemas de dom´ınio e uma ou mais bases de conhecimentos, são descritos a seguir:

Esquema de Dom´ınio: descreve a estrutura da informação/conhecimento estático do dom´ınio da aplicação, assemelha-se a um modelo de dados ou modelo de objetos.

(32)

12 2. Revisão Bibliográfica Base de conhecimento: uma base de conhecimento contém instâncias de tipos espec´ıficos em um esquema de dom´ınio.

O modelo do conhecimento fornece um conjunto de construções de modelagem para especificar o esquema do dom´ınio de uma aplicação. Muitas construções são similares a aquelas encontradas em modelagem de dados moderna. Utiliza-se a notação fornecida pelo diagrama de classe UML, além das construções inclu´ıdas para cobrir aspectos de modelagem que são espec´ıficos de sistemas intensivos de conhecimento, as três principais construções são:

• Conceito: um CONCEPT (conceito) descreve um conjunto de objetos ou instâncias que ocorrem no dom´ınio da aplicação e que possuem caracter´ısticas semelhantes. A noção de conceito é semelhante ao que é chamado de ”classe”ou ”instância de uma classe”em outras abordagens. Uma diferença com abordagens orientadas a objetos é que emCON- CEPT não se inclui funções (isto é, operações, métodos) na descrição de conceitos.

Exemplos de conceitos no dom´ınio de e-comerce podem ser: um carrinho de compras e um produto, apresentados na Figura 2.2.

Caracter´ısticas de CONCEPT pode ser descrita de diversas maneiras. A maneira mais simples é definir um ATTRIBUTE (atributo) de um conceito. Um atributo pode conter um VALUE (valor), informações que instâncias de conceitos possuem. Essas partes da informação devem ser atômicas, o que significa que elas são representadas como simples valores. Assim, um conceito não pode ter um atributo que contém uma instância de um outro conceito como o seu valor, na realidade isso é uma relação que é descrito a seguir. O modelo do conhecimento também suporta a especificação de generalização/especialização, conceitos podem ser organizados em hierarquias por meio de construçõesSUBTYPE-OF.

Observa-se na Figura 2.2 o exemplo de dois conceitos representados utilizando o diagrama de classe UML e logo abaixo sua representação em CML(CommonKADS Model Language) que é uma linguagem que pode ser utilizada para definição do modelo de conhecimento.

• Relação: relação entre conceitos é definida como uma construçãoRELATIONouBINARY - RELATION. Relações podem ser usadas no padrão comum entidade - relacionamento, mas também podem ser usadas para tipos de modelagem mais complexas. Para cada argumento, a cardinalidade (algumas vezes chamada de multiplicidade) pode ser definida.

A cardinalidade padrão é 1, significa que a cardinalidade padrão na relação é obrigatória.

A Figura 2.3 mostra um exemplo de relação binária com uma representação em UML e em CML, nota-se que essa representação é similar a de um conceito, pois pode conter

(33)

Figura 2.2: Exemplo de Conceito (CONCEPT)

atributos também, mas difere com relação aos argumentos que são os outros dois conceitos.

Figura 2.3:Exemplo de Relac¸˜ao(BINARY-RELATION)

• Tipo de regra: um RULE TYPE (tipo de regra) é semelhante a uma relação, onde o antecedente e o consequente podem ser vistos como argumentos. Mas os argumentos são de natureza diferente. Antecedentes e consequentes de um tipo de regra não são instâncias de conceito, mas representam expressões sobre essas instâncias.

A Figura 2.4 apresenta um exemplo de um tipo de regra, nesse caso o tipo de regra restrição de crédito é definida de forma gráfica, a figura mostra também as expressões que estão relacionadas à regra.

A noção de ”regra”, como é utilizada noCommonKADSnão está ligada de alguma forma a implementação espec´ıfica de regras formais. Um tipo de formalismo pode ser uma técnica adequada de codificação, mas não há garantia nem uma necessidade para que isso seja verdade. Os tipos de regra são um ve´ıculo de análise e devem capturar as dependências lógicas estruturais que ocorrem em um dom´ınio de aplicação.

(34)

14 2. Revis˜ao Bibliogr´afica

Figura 2.4: Exemplo de Tipo de Regra

Um esquema de dom´ınio descreve tipo de conhecimento de dom´ınio, tais como conceitos, relações e tipos de regra. Uma base de conhecimento contém exemplos desses tipos de conhecimento. Por exemplo, no dom´ınio de diagnóstico de carro, poder´ıamos ter uma base de conhecimento com instâncias de tipos de regra.

Na Figura 2.5 tem-se apenas um esquema, mas, em aplicações mais complexas, há muitas vezes uma necessidade de introduzir vários esquemas de dom´ınio.

Um fato que pode ser ressaltado é que não há necessidade que a base de conhecimentos seja completada durante a análise, frequentemente um conjunto de instâncias parciais é suficiente nas fases iniciais de desenvolvimento e é completado quando modelo de conhecimento estiver suficientemente estável.

Conhecimento de Infer ˆencia

Conhecimento de dom´ınio é descrito como uma estrutura de informação. No conhecimento de inferência descreve-se como esta estrutura estática pode ser utilizada para realizar um processo de racioc´ınio. Os principais itens de conhecimento de inferência são: as inferências, os papéis de conhecimento e as funções de transferência.

Uma função folha (ou seja, uma inferência) é descrita na ´ıntegra por meio de uma especificação declarativa da sua entrada e sa´ıda. O processo interno de inferência é uma caixa preta, e não

é considerado de interesse para a modelagem de conhecimento. Esta abordagem proporciona uma diretriz para decidir quando parar a decomposição funcional, um problema que ocorre

(35)

Figura 2.5: Exemplo de Base de Conhecimento

com frequência na análise de sistema. Destaca-se a caracter´ıstica que a inferência utiliza e o conhecimento contido em alguma base de conhecimento para derivar novas informações a partir de sua entrada dinâmica.

Podem ser distinguidos dois tipos de papéis de conhecimento, papéis dinâmicos e estáticos.

Papéis dinâmicos são entradas em tempo de execução e sa´ıdas de inferências. Cada invocação de inferência possui diferentes instanciações de papéis dinâmicos. Os papéis estáticos tipicamente correspondem ao armazenamento de dados.

Um conjunto de inferências pode ser representado graficamente em uma estrutura de in- ferência. A Figura 2.6 mostra um exemplo deste tipo de inferência com a utilização das seguintes convenções:

• Retângulos representam papéis dinâmicos de conhecimento. O nome do papel de conhecimento está escrito no retângulo.

• Ovais representam inferências. Setas são utilizadas para indicar dependência de entrada e sa´ıda entre os papéis e as inferências.

(36)

• O nome de papel estático está escrito entre duas linhas horizontais compactas. Esta representação é propositalmente semelhante ao armazenamento de dados em DFD (Di- agrama de Fluxo de Dados). Papéis estáticos estão ligados através de uma linha à in- ferência em que são utilizados. Incluir papéis estáticos é opcional nas estruturas de inferência, onde a ênfase recai sobre os aspectos dinâmicos de fluxo de dados.

Figura 2.6:Exemplo de Inferˆencia - adaptado de (Schreiber et al., 1999)

Um papel de conhecimento constitui um nome funcional para um conjunto de objetos de dom´ınio que podem desempenhar este papel. Algumas operações de inferência operam sobre ou produzem um determinado objeto, outras trabalham sobre um conjunto de objetos. Isto pode levar a ambiguidades nas estruturas de inferência, por exemplo, se uma inferência produz um objeto e uma outra inferência trabalha sobre um conjunto desses objetos, possivelmente gerados por algumas invocações repetidas da primeira inferência.

Para ilustrar o exemplo de inferência da Figura 2.6 pode-se mapear esta inferência para o dom´ınio de empréstimo de carro. O papéis dinâmicos candidato e concedido podem ser mapeados respectivamente para os conceitos pessoa e empréstimo, o modelo causal pode ser mapeado para o tipo de regra da Figura 2.4. Ou seja, a inferência age sobre o conceitopessoa, utilizando as expressões definidas no tipo de regra da Figura 2.4, tendo como resultado o conceitoempréstimo.

E, finalmente, pode-se citar a função de transferência que é uma função que transfere um item de informação entre o agente de racioc´ınio descrito no modelo de conhecimento e o mundo

(37)

2.2 Engenharia do Conhecimento 17 exterior (um outro sistema, alguns usuários). Funções de transferência são caixas pretas do ponto de vista do modelo de conhecimento.

Conhecimento de Tarefa

Um aspecto importante do conhecimento é o que se quer fazer com ele. Quais são os objetivos que pretende-se alcançar com a aplicação de conhecimentos?

A seguir est˜ao relacionados alguns objetivos t´ıpicos:

• Avaliar um pedido de hipoteca a fim de minimizar o risco de perder dinheiro.

• Encontrar a causa de uma avaria em uma fotocopiadora, a fim de restabelecer o servic¸o o mais rapidamente poss´ıvel.

• Projetar um elevador para a um novo edif´ıcio.

Conhecimento de tarefa é a categoria do conhecimento que descreve essas metas e as estratégias que serão empregadas para realizar esses objetivos. Conhecimento de tarefa é normalmente descrito em um modo hierárquico: tarefas de alto n´ıvel comoProjetar elevador são decompostas em pequenas tarefas, que por sua vez podem ser divididas em tarefas ainda menor.

No n´ıvel mais baixo de decomposição de tarefa, as tarefas estão ligadas a inferências e funções de transferência, podemos observar essa divisão na Figura 2.7.

Dois tipos de conhecimento executam um papel proeminente na descrição da tarefa de conhecimento: a tarefa e o método de tarefa. Uma tarefa define um racioc´ınio objetivo em termos de um par entrada-sa´ıda. Por exemplo, uma tarefa tipicamente deDiagnósticotem como entrada uma reclamação e produz como sa´ıda uma categoria de falha mais comprovada. Um método de tarefa descreve como uma tarefa pode ser realizada por meio de uma decomposição em sub-funções. A tarefa e o método de tarefa podem ser melhor compreendidos, respectivamente, da visãoo que(o que deve ser feito) e da visãocomo(como é feito) sobre tarefas de racioc´ınio.

Uma tarefa define uma função complexa de racioc´ınio. A tarefa de alto n´ıvel tipicamente corresponde a uma tarefa identificada no modelo de tarefa. A especificação de uma tarefa nos diz quais são suas entradas e sa´ıdas. A principal diferença de uma função tradicional e uma tarefa é que a tarefa é descrita em uma forma independente de dom´ınio. A tarefa, tal como inferências, são especificadas em termos de nomes de papéis funcionais. Existem, no entanto, duas diferenças principais entre tarefas e inferências:

• Não se inclu´ı papéis estáticos na especificação de tarefas. Papéis estáticos só são introdu- zidos em n´ıvel de inferências.

(38)

Figura 2.7: Exemplo de Tarefa - adaptado de (Schreiber et al., 1999)

• Não se especifica o mapeamento dos papéis sobre os termos espec´ıficos de dom´ınio. O mapeamento é uma forma indireta: papéis de tarefa estão ligados a papéis de inferência por meio da estrutura de controle. Papéis de inferência associados têm cada um mapeamento para a construção de dom´ınio.

Sobre Método de tarefa pode-se dizer que descreve como uma tarefa é realizada por meio de uma decomposição em sub-funções. Tais sub-funções pode ser uma outra tarefa, uma inferência definida no conhecimento de inferência, ou uma função de transferência. O núcleo do método

é formado por estruturas de controle que descrevem em que ordem as sub-funções devem ser realizadas.

2.2.3 Modelo de Projeto

Nesta subseção são descritas as etapas da construção do Modelo de Projeto conforme apresentadas em (Schreiber et al., 1999).

O Modelo de Projeto apoia a transformação de requisitos especificados no modelo de análise e este modelo em um software. A principal entrada para o processo de desenvolvimentoCom- monKADS é o Modelo de Conhecimento, o qual pode ser visualizado como uma especificação dos requisitos para a solução de problemas.

(39)

Figura 2.8:Projeto e Implementac¸˜ao Adaptado de (Schreiber et al., 1999)

No desenvolvimento do sistema, o ponto de vista e o vocabulário são bem diferentes, em comparação com outros modelos. O desenvolvimento do sistema se preocupa com o software e sua organização interna. É como se fug´ıssemos do dom´ınio da aplicação e começássemos a prestar atenção no sistema resultante. Os outros modelos podem ser vistos como precursores dos requisitos para este processo de desenvolvimento, isto pode ser observado na Figura 2.8.

O desenvolvimento de sistemas de conhecimento intensivo não é muito diferente em sua essência do desenvolvimento de qualquer outro sistema de informação. Neste caso, também assume-se que exista um conhecimento prévio em métodos de desenvolvimento e engenharia de software em geral, sendo a arquitetura de software uma questão central ao processo de desenvolvimento. Uma arquitetura de software descreve a estrutura do software em termos de subsistemas e módulos.

O Modelo de Projeto apresenta uma arquitetura de referência que pode ser usada para sistemas de conhecimento baseados em CommonKADS. Uma arquitetura de referência é o esqueleto de uma arquitetura que pode ser o subs´ıdio para uma série de sistemas, consiste em um meio poderoso que prove apoio ao processo de desenvolvimento. A arquitetura de

(40)

20 2. Revisão Bibliográfica referência doCommonKADSusa um importante princ´ıpio de projeto moderno, que é o princ´ıpio de desenvolvimento com preservação da estrutura. Este princ´ıpio prega que tanto o conteúdo quanto a estrutura da informação contida nos modelos de análise são preservados durante o desenvolvimento, este princ´ıpio facilita a transparência e a manutenção do projeto, garantindo um projeto de alta qualidade.

A preservação da estrutura garante que o processo de desenvolvimento possa suprir critérios de qualidade, tais como:

• Possibilidade de reutilização da programação: o desenvolvimento com preservação de estrutura prepara o caminho para a reutilização de fragmentos da programação de um sistema de conhecimento, pois o propósito e papel dos fragmentos de programação são explicitados estes podem ser de vários tipos e tamanhos, desde implementações de in- ferências até implementações de um grupo de inferências que controlam o conhecimento.

• Facilidade de manutenção e adaptabilidade: a preservação da estrutura do modelo de análise possibilita detectar alguma omissão ou inconsistência no produto implementado em uma porção particular do modelo, simplificando a manutenção consideravelmente, além de facilitar futuras expansões de funcionalidade. Experiências com sistemas desen- volvidos com preservação de estrutura indicam que eles realmente são muito mais fáceis de manter do que sistemas convencionais.

• Explicação: a necessidade de explicar a lógica subjacente ao processo de racioc´ınio

é uma caracter´ıstica t´ıpica dos sistemas de conhecimento intensivo. A abordagem de preservação da estrutura facilita o desenvolvimento que explicam o processo de racioc´ınio no vocabulário do modelo de conhecimento.

• Apoio à obtenção de conhecimento: a descrição do modelo de conhecimento pode se encaixar ao papel de informação semântica sobre partes do código fonte. Essa informação adicional pode ser usada para dar apoio à obtenção,debuge refinamento de conhecimento em vários aspectos.

O desenvolvimento com preservação de estrutura está também sendo publicamente recomen- dado em engenharia de software em geral, especialmente na área de projeto e modelagem orientados a objetos. A motivação nesse caso segue um racioc´ınio parecido, com ênfase na facilidade de reutilização e manutenção.

Um processo comum de desenvolvimento começa com a especificação da arquitetura do software. Assim que sua estrutura geral é definida pela arquitetura, pode-se especificar a arquitetura com mais detalhes. Essa é a base para o aplicativo em si. Além disso, as decisões de

(41)

2.2 Engenharia do Conhecimento 21 desenvolvimento devem ser tomadas considerando as plataformas de software e hardware que serão utilizadas na implementação. Essas decisões devem ser tomadas no in´ıcio do processo de desenvolvimento, pois podem influenciar todo o processo, no CommonKADSutiliza-se os mesmos conceitos.

A seguir estão descritas as etapas de construção do modelo de projeto.

Primeira etapa: Arquitetura de Desenvolvimento do Sistema

NoCommonKADShá uma arquitetura de referência definida que pode ser usada para a maioria dos aplicativos. Essa arquitetura é descrita em dois n´ıveis de granularidade.

Primeiro com alta granularidade tem-se aArquitetura Global do Sistema que se baseia na metáfora MVC (Modelo-Visualização-Controle), conforme Figura 2.9. A arquitetura MVC foi desenvolvida para programas na linguagem de programação SmallTalk-80, essa arquitetura possui três subsistemas:

• Modelo do aplicativo: especifica as funções e dados que resultam na funcionalidade do aplicativo. No caso de um sistema baseado em CommonKADS, o modelo do aplicativo contém as funções racionais. Os dados do modelo do aplicativo são as respectivas bases de dados de conhecimento e os dados dinâmicos manipulados durante o processo racional.

• Visão: especifica visualizações externas das funções e dados do aplicativo, exibindo objetos do aplicativo numa tela de interface com o usuário. A visualização disponibiliza informação estática e dinâmica para agentes externos, como usuários e outros sistemas em software. A separação de objetos do aplicativo de suas visualizações é um dos pontos fortes de uma arquitetura do tipo MVC. A arquitetura original em MVC tem maior foco em visualização de objetos em interface com usuário, mas pode ser usada para criar interfaces com outros sistemas em software.

• Controle: o subsistema de controle é na verdade a unidade central de comando e controle, ativa funções do aplicativo e decide o que fazer quando os resultados retornam. O controle também define suas próprias visualizações de objetos para exibir informações. O controle implementa o modelo de comunicação, em particular o controle das informações especificadas no plano de comunicação e por dentro das transações.

Na arquitetura MVC, as entradas no sistema são tratadas pelo controle. O controle pode enviar mensagens de ativação para uma ou mais funções do aplicativo, o que no caso do CommonKADSnormalmente são funções racionais (como a ativação de uma tarefa).

Após ter descrito aArquitetura Global do Sistemapode-se detalhar o subsistema do Modelo do Aplicativo, este contém os elementos do software que deveriam realizar as funções e dados

(42)

Figura 2.9:Arquitetura de Referˆencia Adaptado de (Schreiber et al., 1999)

especificados durante a análise. Em termos deCommonKADS, o modelo do aplicativo contém as funções racionais (tarefas e inferências) e as estruturas de informação e conhecimento (o dom´ınio de conhecimento). A arquitetura de referência desse subsistema é exibida na Figura 2.10, esta é baseada nos seguintes princ´ıpios:

1. A arquitetura deveria seguir o princ´ıpio de desenvolvimento com preservação de estrutura, dando suporte ao mapeamento facilitado do material de análise para transposição ao projeto, além de disponibilizar ganchos para refinamentos espec´ıficos do desenvolvimento que possam ser necessários.

2. Por diversos motivos, a arquitetura com decomposic¸˜ao de componentes orientada a objetos foi selecionada para esse subsistema, tais como:

(43)

• Apesar de alguns dos componentes de análise terem caráter funcional (como tarefas e inferências), suas descrições durante a análise são de um objeto de informação.

Tarefas e inferências são descritas de modo declarativo, o que pode ser facilmente mapeado como uma especificação de objeto.

• A integração e/ou coordenação com outros sistemas torna-se mais importante na etapa de desenvolvimento. Como a orientação a objetos é o paradigma que prevalece atualmente em engenharia de software, um projeto baseado nesse paradigma de um sistema de conhecimento intensivo facilitará a integração.

• Além disso, muitos ambientes de implementação usam uma abordagem orientada a objetos, o mapeamento para um ambiente desse tipo será mais fácil.

Figura 2.10: Arquitetura de Referˆencia - Modelo do Aplicativo (Schreiber et al., 1999)

(44)

24 2. Revisão Bibliográfica A ideia por trás dos objetos na Figura 2.10 é que se incorporam as estruturas do modelo de conhecimento no projeto e adicionam-se detalhes espec´ıficos da implementação. Por exemplo, na Figura 2.10 foi introduzido o objeto inference method (método de inferência). Esse objeto não aparece durante a análise, pois inferências são especificadas como uma caixa-preta. Porém, durante o desenvolvimento deve-se especificar um método (ou algoritmo) para que a inferência seja implementada, utilizando os papéis especificados para tal inferência. Outros objetos da arquitetura são incorporados diretamente da análise, mas contém detalhes adicionais, espec´ıficos do desenvolvimento. Por exemplo, osdynamic roles(papéis dinâmicos) têm um tipo de dados associado, assim como um número de operações de acesso/modificação que habilitam o uso dos papéis dinâmicos como a memória de trabalho do sistema racional.

Segunda etapa: Identificar a plataforma de implementac¸ ˜ao

Em teoria, pode-se desenvolver um sistema independentemente da plataforma de implementação que será utilizada. Pode-se fazer um projeto orientado a objetos e implementá-lo em COBOL.

Deve levar mais tempo do que se fosse escolhida uma linguagem adequada, mas a princ´ıpio não há limitação inerente. Na prática, porém, tudo isso importa.

E por essa razão que normalmente é uma boa prática identificar no in´ıcio do projeto quais´ são as limitações em relação à plataforma de implementação. Isso significa que se a plataforma

´e fixada pelo cliente desde o in´ıcio, deve-se tomar cuidado.

As etapas 2 e 3 se influenciam mutuamente. Caso a seleção de plataforma seja livre, deve ser selecionada a que se adéque melhor às decisões de arquitetura. Uma diretriz importante a citar é que, não havendo limites externos para essa etapa, adiá-la para após a execução da terceira etapa.

Atualmente a escolha de uma plataforma de implementação é basicamente uma escolha de software. O número de plataformas de hardware diminuiu consideravelmente e os softwares mais populares estão dispon´ıveis em plataformas diferentes. Portanto, deve-se concentrar na escolha do software.

As seguintes caracter´ısticas s˜ao relevantes `a escolha do software:

• Disponibilidade de uma biblioteca de objetos de visualização: a falta de um recurso como esse implica sem dúvida em trabalho extra em implementação. Um sistema processador em massa poderia ser uma exceção.

• Representação declarativa do conhecimento: o conhecimento no sistema (muitas vezes em forma de ?regras?) deve estar dispon´ıvel de tal maneira que possa ser gerenciado, atu- alizado ou refinado facilmente. Portanto, uma representação declarativa do conhecimento

´e a melhor, o que pode ser um problema em alguns ambientes orientados a objetos.

(45)

• Interface padrão para outros softwares: muitas vezes é necessário que se acesse um ou mais bancos de dados. Deve-se então utilizar um protocolo que interaja com o banco de dados. Para um sistema distribu´ıdo, é desejado que se use uma interface padrão do tipo CORBA.

• Tipagem de linguagem: dada a natureza do sistema desejado, uma tipagem orientada a objetos do software simplifica o mapeamento de análise e desenvolvimento a serem trans- posto para programação. Numa linguagem como Prolog, com quase nenhuma tipagem o projetista tem de construir seu próprio tipo de representação.

• Fluidez de controle: o ambiente tem suporte a uma abordagem de passagem de mensagens? ´E poss´ıvel ter v´ariasthreads?

• Apoio a CommonKADS: o software fornece uma implementação da arquitetura Com- monKADS, possui um pacote de bibliotecas CommonKADS? Suporta uma ligação com uma ferramenta case CommonKADS? Esses dois recursos agilizam a implementação consideravelmente e são bastante úteis se um protótipo é necessário.

Terceira etapa: Especificando os componentes da arquitetura

Nesta etapa do processo de desenvolvimento são definidos os componentes da arquitetura com mais detalhes, em particular as interfaces entre subsistemas e/ou entre módulos de sistema, como é apresentado a seguir.

OControle: realiza uma abordagem de controle guiada por eventos com um componente central de controle. As seguintes decisões são t´ıpicas em um processo como este. O controle deve controlar algo automaticamente? Será poss´ıvel a interrupção da execução de uma tarefa?

Haverá necessidade de processamento concorrente. A necessidade de recursos complexos de arquitetura para o controle depende seriamente da complexidade do modelo de comunicação.

Normalmente para sistemas simples os seguintes recursos s˜ao geralmente necess´arios:

• Gerenciadores de eventos que ativem func¸˜oes de modelo do aplicativo a pedido de um agente (evento) externo.

• Gerenciadores de eventos que recebam funções de transferência no modelo do aplicativo.

• Gerenciadores de eventos para eventos internos, em especial eventos que sejam gerados por funções de transferência.

• Gerenciadores de eventos que exibam informac¸˜ao sobre os processos de racioc´ınios.

(46)

• Gerenciadores de eventos que abortem a execução de uma função.

Normalmente, cada transação será implementada como um gerenciador de eventos ou como

uma combinação desses. O controle define seus objetos de visualização para representar meta-informação sobre os processos de controle do sistema.

NoModelo do aplicativo, se concentra o n´ucleo doCommonKADSeste ´e subdividido nos sub-itens:

• Tarefa (task): é necessário definir duas operações: (1) uma operação de inicialização que possa ser usada para gerar valores de entrada da tarefa; e (2) uma operação execute que deve iniciar o método de tarefa correspondente. Para esta última é necessário decidir se o valor de retorno é booleano, o que indicaria sucesso ou falha do método de tarefa. Essa decisão depende do tipo de controle utilizado no item abaixo.

• Método de tarefa (task method): as duas decisões principais para o desenvolvimento de um método de tarefa são relacionadas a operacionalização da estrutura de controle. A primeira decisão se relaciona com a linguagem de controle utilizada. O controle em modelos de conhecimento é comumente especificado de modo imperativo, mas ainda

é definido em pseudo-programação informal. O designer deve decidir sobre um conjunto de instruções para a implementação das estruturas de controle. Deve-se também considerar construções de controle para processamentos concorrentes e sincronização.

Parte da linguagem de controle é obtida pela execução de operações em outros objetos da arquitetura como papéis dinâmicos, tarefas, inferências e funções de transferência (todas as subfunções). A segunda decisão se relaciona com o local onde a estrutura de controle é definida. Numa abordagem orientada a objetos parece natural visualizar esse local como a implementação de um método execute, mas isso pode destruir sua natureza declarativa.

• Inferência (inference): como uma tarefa, o desenvolvimento do objeto de inferência baseado na informação contida no modelo do aplicativo. No desenvolvimento é comum supor que uma inferência tem uma espécie de memória interna para as soluções encontradas.

Essa memória é reiniciada toda vez que uma tarefa que precisou de inferência é conclu´ıda.

Uma execução de inferência falha se não há nenhuma solução nova encontrada. As decisões de desenvolvimento relacionadas com a inferência têm relação com a definição de operações que habilitam a execução de inferências. Comumente são necessárias três operações: executeque obtém as entradas de inferência estáticas e dinâmicas e iniciam o método de inferência,has-solutionenew-solutionque são testes que podem ser realizados pelo método de tarefa.

(47)

• Método de inferência (inference method): durante a análise, o engenheiro de conhecimento toma um ponto de vista de dedução automatizada de uma inferência em particular:

será especificada uma inferência de maneira tal em que esta saiba que é poss´ıvel derivar uma conclusão, dado o conhecimento dispon´ıvel, não importando quão complexa a derivação possa ser na prática. Na análise, a ênfase cai em uma descrição orientada por competências: é poss´ıvel fazer essa inferência em princ´ıpio, e qual é a informação necessária para sua realização? Um método de inferência especifica uma técnica computacional que faz esse trabalho. Os métodos de inferência podem ser vistos como parte de inferências, ou seja, inclu´ıdos na implementação da operação execute. Na prática o que ocorre é que muitos aplicativos apenas requerem métodos simples de ligação de regras, além de alguns métodos de seleção.

• Papéis Dinâmicos: para os papéis dinâmicos há duas decisões de arquitetura a tomar. A primeira é em relação a quais tipos de dados dão suporte aos papéis dinâmicos? Normal- mente temos elementos únicos, conjuntos (set, desordenado e sem duplicatas), sacolas (bag, desordenado e com duplicatas permitidas) e listas (list, ordenado e com duplicatas permitidas), e posteriormente quais operações esses tipos de dados dão suporte? Por exemplo, para conjuntos podem ser úteis as operações de selecionar (select, obter um objeto aleatório do conjunto), adicionar (add, adicionar elementos ao conjunto) e subtrair (subtract, excluir elementos do conjunto).

• Papel estático: a arquitetura precisa habilitar funções de acesso, que podem fornecer todas as instâncias de um papel de conhecimento, apenas uma instância de um papel de conhecimento ou verificar se existe certa entrada de conhecimento. Normalmente se tem todas as instâncias de um papel de conhecimento, sendo suficiente para a maioria dos aplicativos. As funções de acesso normalmente delegam o pedido para as funções de acesso definidas para a o banco de dados de conhecimento correspondente.

• Base de conhecimento, com relação as bases de conhecimento existem três decisões a serem tomadas:

– Decidir sobre o formato de representação para as instâncias de tipos de regra. Não necessariamente utiliza-se um formalismo de produção de regras, um formalismo relacional pode ser suficiente.

– Definir funções de acesso e modificação. Estas funções de acesso normalmente correspondem às necessidades das funções de acesso do objeto papel estático.

– As bases de conhecimento estão sujeitas a modificações e/ou analise de funções.

Essas funções estão relacionadas com as funções de edição, que permitem que um

(48)

28 2. Revisão Bibliográfica mantenedor de conhecimento possa atualizar, depurar e/ou aperfeiçoar as bases de conhecimento do sistema.

• Construção de Dom´ınio: os conceitos fazem parte dessa construção, relações e tipos de regras são comumente inclu´ıdos somente para fins de documentação e não requerem quaisquer recursos adicionais de arquitetura.

Visualizações: as visualizações apresentam o sistema aos agentes externos. Para atingir este objetivo, devem ser disponibilizados recursos como janelas, menus, navegadores e figuras, entre outros. E também para garantir a integridade das visualizações a arquitetura deve possuir objetos que liguem o modelo do aplicativo a uma ou mais visualizações, mantendo-as sempre consistentes entre si.

Dois tipos de interfaces de usu´ario s˜ao normalmente requeridas para sistemas de conhecimento intensivo:

• Interface com o usuário final: o objetivo do sistema é disponibilizar o conhecimento dos especialistas a relativos leigos, dessa forma a interface com este tipo de usuário deve fornecer as facilidades requeridas para manipular as funcionalidades do sistema de conhecimento.

• Interface com o especialista: normalmente é necessária uma interface adicional para permitir a interação do especialista com o sistema. Essa interface deve permitir ao especialista localizar os processos racionais do sistema na terminologia do modelo de conhecimento e também prover recursos para editar, refinar e estender bancos de dados de conhecimento.

Quarta Etapa: Especificando o aplicativo dentro da arquitetura

Na ´ultima etapa, o desenvolvimento deve ser completado, indicando as partes espec´ıficas do aplicativo dentro da arquitetura. Podem-se distinguir duas etapas desse processo:

• Mapear a informação de análise na arquitetura: partindo da arquitetura de referência fica claro que a informação de análise, especialmente o modelo de arquitetura, pode ser mapeado facilmente em componentes da arquitetura, criando diversas instâncias de componentes da arquitetura. Por exemplo, para cada tarefa no modelo de conhecimento, um objeto de tarefa da arquitetura correspondente deve ser criado. Esse processo de mapeamento pode ser feito manualmente ou por algum meio automatizado. Quando realizado de forma automatizada a margem de erros é reduzida, por isso essa forma é a prefer´ıvel.

(49)

• Adicionar detalhes necessários para o desenvolvimento do aplicativo: neste item são relacionados os componentes da arquitetura que geralmente necessitam de alguns cuidados adicionais, são eles:

– Controle: neste ressalta-se uma transformação do modelo de comunicação em uma especificação de controle. Alguns fatores que podem dificultar o desenvolvimento do Controle são: interação externa complexa, controle de usuário sobre os processos racionais concorrentes e no caso de um sistema em tempo real, o projetista deve estar familiarizado com a literatura especializada sobre o assunto.

– M´etodo de tarefa: formalizar as estruturas de controle do m´etodo na linguagem de controle prevista pela arquitetura.

– Inferência: deve-se escrever uma especificação na inicialização de um método de inferência. Essa inicialização de método deveria mostrar como os papéis estáticos e dinâmicos são mapeados em argumentos do método de inferência.

– Método de inferência: para cada inferência, o engenheiro deve especificar ou selecionar um método de inferência. Esses métodos podem ser métodos racionais descritos na literatura de IA ou simples algoritmos padrão (organização, seleção de subconjuntos, etc.).

– Papel dinˆamico: deve-se escolher um tipo de dados para cada papel, essa escolha ´e limitada pelos tipo de dados definidos pela arquitetura.

– Visualizações: a escolha do tipo de visualização é guiada por princ´ıpios de desenvolvimento da interface do usuário, os quais já foram descritos adequadamente em outros trabalhos.

2.2.4 Outras Metodologias

De acordo com (Dias e Pacheco, 2009), a partir da década de 90 surgiram propostas de metodologias para auxiliar o desenvolvimento de sistema de conhecimento, tais como: Vital (Shadbolt et al., 1993), SPEDE (Structured Process Elicitation and Demonstration Environment) (Cottam et al., 1998), CommonKADS (Schreiber et al., 1994), MAS-CommonKADS (Iglesias et al., 1998), MIKE (Model-based and Incremental Knowledge Engineering) (Angele et al., 1998a), MOKA (Methodology for Knowledge-Based Engineering Applications) (Oldham et al., 1998), OTK (On-To-Knowledge) (Sure e R., 1999), XP.K (eXtreme Programming of Knowledge-based systems) (Knublauch, 2002). Geralmente essas metodologias definem etapas e modelos para o desenvolvimento de sistemas baseado em conhecimento. Para a representação dos modelos utiliza-se UML (Unified Modeling Language) e ontologia.