Com o crescente desenvolvimento das telecomunicações, foi-se tornando mais “vulgar” o uso do maior sistema de comunicação global – a Internet, que nos permite ter um maior leque de comodidades na nossa própria casa, ou seja, permite-nos fazer um número sem fim de tarefas, sem ser necessário sair de casa, e por consequentemente, não ter de esperar em filas, não ter problemas com o tempo, ...

Por estas e outras razões, apareceu o Comércio Electrónico, permitindo-nos fazer compras como se estivéssemos num grande Hipermercado, muitas das vezes sem qualquer tipo de ajudas sobre os produtos que são vendidos ou então com ajudas muito medíocres.

Assim foi-se tornando necessário personalizar esse comércio, tentando torná-lo mais pessoal, mais ao gosto de cada utilizador, para que este não se perca nesse “novo mundo”.

Foi então que surgiu a necessidade da criação de sistemas que ajudem as pessoas a comprar aquilo que realmente precisam/querem. Foi nesse âmbito que surgiu um projecto chamado “Assistente Pessoal Digital ”, que sendo baseado em RBC (Raciocínio Baseado em Casos) tem como função tornar as transacções mais simples e mais pessoais.

No capitulo 2 faz-se um breve introdução a conceitos gerais e sobre a situação actual sobre o Comércio Electrónico.

No capitulo 3 introduz-se o RBC descrevendo-o, e mostrando as suas fases principais.

No capitulo 4 introduz-se teoricamente a base do nosso trabalho (APD) e as suas características principais.

No capitulo 5 fala-se nas tecnologias que foram usadas para desenvolver este trabalho, bem como uma breve noção explicativa delas.

No capitulo 6 fala-se do nosso trabalho na prática, ou seja, da arquitectura geral do nosso trabalho, a estrutura de dados

2. Comércio Electrónico (CE)

2.1 Definição

Electronic Commerce (EC) – the process of arranging the tranfer of goods or services, settling or performing payments and exchanging customer information. [NoBrNe00]

O Comercio Electrónico, como já foi dito atrás é um campo em larga expansão, que está por assim dizer, dividido em duas partes principais:

- em mercados virtuais (virtual markets);

- e em organizações virtuais (virtual organizations).

No primeiro tipo referido, encaixam por exemplo, os referidos leilões, onde se negoceia com simulações de mercados, onde são feitas as compras através de sistemas de apoio que podem ser orientadas para melhor servir o vendedor, ou o consumidor.

As organizações virtuais tentam estabelecer um interesse, entre uma sociedade de agentes, na rede por forma a produzir ou fornecer um determinado produto a um consumidor final.

Devido à natureza dos sistemas multi-agentes, podemos modelar através de uma forma incremental de passos, um sistema capaz de compreender ambas as áreas.

Podemos ainda ver o Comercio Electrónico e as Organizações Virtuais como sistemas computadorizados na sua essência, uma vez que para implementarem os seus “ambientes”, por forma a poderem “trocar” informação de uma forma rápida, usam tecnologias cliente – servidor, intranet ou agentes, ou seja, CE e OV podem ser unificadas.

O mais simples CE, que provém de uma companhia que tenta vender algo a um consumidor final, através da Internet, pode concerteza ser visto como uma pequeno elemento de uma grande OV . Esta construção recursiva, só é possível porque uma agente, dependendo das circunstâncias, tanto pode ser um comprador como um vendedor.

2.2 Situação actual

O Comércio Electrónico, neste momento, ainda está muito longe de chegar ao fim de todas as potencialidades que esta tecnologia nova oferece. Isto porque, muitos consumidores ainda não acreditam, por alguma razão, neste novo comércio, é difícil, como todos sabemos, garantir transacções seguras através da Internet, e também, porque é difícil um consumidor comum conseguir encontrar o que realmente deseja no meio de tanta informação e produtos.

Muitas tecnologias foram e estão a ser desenvolvidas no campo da segurança na Internet, mas no campo de ajudar os consumidores a encontrarem o que realmente querem não existem muitas tecnologias, e a maioria dos catálogos online não aproveitam o facto de puderem usar a interactividade com o consumidor para melhor o ajudar, pois se o conseguir ajudar/satisfazer plenamente, ele voltará e provavelmente divulgará esta tecnologia a seus amigos/familiares, e as pessoas começaram a acreditar nas verdadeiras potencialidades desta nova tecnologia.

3. Raciocínio Baseado em Casos (RBC)

3.1 Definição

O Raciocínio Baseado em Casos consiste em que dado um problema, encontrar e justificar uma solução, através da reconstituição duma experiência do passado, reutilizando e adaptando o conhecimento anterior ao novo caso, passível de poder ser inserido na memória de casos.

O Raciocínio Baseado em Casos tem como objectivo racionar com base em experiências anteriores para solucionar problemas actuais, para isso suportando-se de uma base de dados de casos acumulados ao longo do tempo. Isto facilita a aquisição de conhecimentos que se resume à colecção de casos passados das soluções e dos resultados destas.

O estudo do Raciocínio Baseado em Casos, surge com duas motivações [Sc82]: uma motivação cognitiva, que consiste em desenvolver sistemas que emulem o comportamento humano, e uma motivação pragmática, que consiste em desenvolver sistemas inteligentes que se mostrem eficientes.

Um RBC pode-se resumir a quatro fases principais, como podemos ver na seguinte figura:

Figura 1: Modelo de Raciocínio Baseado em Casos

3.2 As Quatro Fases de um RBC

3.2.1 Recuperação

Neste fase do RBC, tenta-se recuperar o(s) caso(s) similar(es) para se poder dar uma resposta válida ao novo caso apresentado. Para que isso seja possível será necessário, logo na fase da formulação do problema, que se identifiquem os atributos relevantes, sendo depois, seleccionado entre os escolhidos o que se adequa mais ao problema actual.

3.2.2 Adaptação

Este é a fase onde o RBC adapta o conhecimento e a informação contida no(s) caso(s) para resolver o problema, sendo a adaptação automática muito difícil, ou seja a solução recuperada não é directamente utilizável, o que normalmente requer o feedback do utilizador.

3.2.3 Revisão e Reparação

O RBC, nesta fase, reve solução proposta, e caso esta não se adapte ao tipo de utilizador em questão, irá tentar repará-la, tentando arranjar uma proposta equivalente, que melhor se adapte ao utilizador.

3.2.4 Aprendizagem

Chegada a esta fase com sucesso, o RBC, vai aprender com a experiência presente, por forma a que esta possa ser útil na resolução de problemas futuros, como outras foram para a resolução dela mesma. Para isso integra-se ou altera-se na base de conhecimento existente, um novo caso ou um caso existente, respectivamente.

Quantas mais experiências existirem no repositório de casos, mais eficaz ficará o modelo de RBC, para resoluções de problemas futuros.

4. Assistente Pessoal Digital (APD)

4.1 Definição

Um Assistente Pessoal Digital não passa de um modelo de Raciocínio baseado em Casos, mas em que os casos são produtos, ou seja um RBC aplicado ao Comércio Electrónico.

Sendo este um sistema baseado no modelo RBC, as várias fases são muitos idênticas tanto no seu funcionamento como na sua descrição.

Figura 2: RBC ciclo de vida para Comércio Electrónico [WBW 98]

4.2 Exemplo de como deve funcionar APD

Com a implementação destes assistentes tentou-se criar um vendedor tradicional na Internet por forma a facilitar a “vida” às pessoas que se “deslocassem” a esses “novos comércios tradicionais”.

A implementação deste assistente, que como devem supor não é muito simples, uma vez que vamos tentar que um computador replique um ser humano na sua essência, ou seja, que em qualquer questão de um “cliente” saibamos o que ele quer e que o assistente faça o seu melhor para ajudar (mutuamente o “cliente” e o “vendedor”).

Para melhor demonstrar o que foi dito atras, temos um exemplo de um cliente que não sabe exactamente o que quer.

“ Cliente: Bom dia, procuro um monitor.

Vendedor: Faz ideia das características que pretende?

Cliente: Não sei, mas queria um recente.

Vendedor: Tenho aqui 3 monitores recentes de marcas conceituadas e um nosso muito bom a um preço óptimo.

Cliente: Porreiro, fico com o vosso.”

Por outro lado temos um exemplo de um cliente que deseja comprar um determinado equipamento, e este não se encontra disponível, sendo oferecido um similar.

“ Cliente: Bom dia, procuro um monitor Nokia 447Xs.

Vendedor: Pedimos desculpas, mas não temos esse produto em stock, mas temos um equivalente Nokia 447 Pro. Deseja comprar, a diferença de preços é mínima

Cliente: Porreiro, compro o Nokia 447 Pro.”

De seguida temos um cliente que deseja um produto que não se encontra em stock, o nosso vendedor resolve o problema juntando dois produtos existentes em stock que em conjunto tem a mesma função que o pretendido inicialmente.

“ Cliente: Bom dia, procuro um Hub 10/100 de 10 portas.

Vendedor: Pedimos desculpas, mas não temos esse produto em stock, mas temos um produto que em duplicado tem a mesma função que o pretendido. Temos um Hub 10/100 de 6 portas.

Cliente: Não tenho a certeza de que isso resulte.

Vendedor: Confie em Nós, se não funcionar retornar-lhe-emos o dinheiro.

Cliente: Porreiro, aceito a proposta.”

Como último exemplo, também temos um cliente que pretende fazer uma compra. Esta compra por sua vez é de um produto antigo, que foi substituído por uma outra versão.

“ Cliente: Boa Tarde, procuro um disco de 3 Gigas da Maxtor.

Vendedor: Pedimos desculpas, mas esse produto foi retirado do mercado. Temos como seu substituto o disco de 4 Gigas da Maxtor.

Cliente: Porreiro, parece que eu ando desactualizado, então levo esse.”

5. Tecnologias Usadas

5.1 Linguagem

A linguagem utilizada para desenvolver este projecto foi o java, que como vimos e nos debatemos, é um grande pretendente “à subida do trono das linguagens”, visto que sendo multi-plataformas pode correr em vários sistemas operativos (Linux, Windows, etc), e que pode correr directamente num browser de Internet (Netscape Communicator, Internet Explorer) através de applets.

Sendo também uma linguagem não muito complicada, e orientada ao objecto, suporta facilmente interfaces do tipo cliente/servidor através de RMIs (Remote Method Invocation).

5.2 Java

O primeiro problema que nos surgiu foi na escolha da linguagem de programação a ser utilizada. Visto que o comercio electrónico é hoje em dia identificado pela Internet, achamos que precisávamos de uma linguagem que nos trouxesse vantagens neste ramo, para alem disso necessitávamos de uma linguagem que fosse simples no que trata a conexão a uma base de dados. O JBDC foi programa que nos permitiu estabelecer a ligação entre o código java e a base de dados em Access, para tal incluímos query’s em SQL.

Optamos também por esta linguagem, como era de esperar, por ser orientada a objectos, o que por entre outras razões a utilização de classes beneficiou-nos tanto na estruturação do trabalho como na possibilidade de programação em grupo.

5.3 RMI

Remote Method Invocation é o significado das siglas RMI. Este método permite-nos estabelecer uma ligação entre um servidor e vários clientes, neste caso o servidor fornece serviços/objectos que serão úteis para o cliente. Existem 3 clientes diferentes dois que podem ser corridos através de uma página Html, e um terceiro que tem como objectivo a administração do PDA, quer em Linux e em Windows.

5.4 HTML

Foi criado por nós uma página HTML que permite o acesso a várias informações relacionadas com o projecto, até mesmo este relatório em página web. Existem ainda dois links para duas applets, uma de criação de um profile de utilizador e outra que permite gerir esse profile como também poder fazer as procuras em que se centra o nosso trabalho.

5.5 Access

A Microsoft tem poucos adeptos, mas existem algumas coisas que trabalham, mal mas trabalham e visto que precisávamos de uma base de dados, foi a primeira em que nos centramos visto as facilidades de tratamento da informação. Posteriormente esta base de dados poderá ser convertida para Informix, tendo em conta o tempo de entrega do projecto (muito menos de 6 meses) não arriscamos dar tamanho salto devido á complexidade existente.

5.6 ODBC

Como nos é dito pela Microsoft o ODBC é uma aplicação que faz a ligação entre uma base de dados (neste caso em Access) e uma linguagem de programação (java através do JDBC) sendo fácil a sua utilização, isto é, para aceder á informação utilização statements SQL.

5.7 SQL

Structured Query Language, que como o próprio nome indica é uma linguagem estruturada que permite fazer perguntas (“SELECT * FROM Products WHERE Name = ?”) , inserções(“INSERT INTO EquivalentList (EquivalentId,Equivalent) VALUES (?,?)”), remoções(“DELETE FROM Products WHERE Name = ?”) e updates(“UPDATE ProductTypes SET Description = ? WHERE Description = ?”), de uma forma simples como os próprios exemplos indicam.

6. Generic PDA in Uminho

6.1 Arquitectura

Figura 3: Representação das várias arquitecturas utilizadas

O ODBC faz a ligação com a base de dados Access através de uma opção que este mesmo dispõe, onde é indicado o nome da ligação que se pretende fazer e onde é indicado igualmente o local onde se encontra a base de dados.

Feita esta operação é necessário transmitir a informação na bd, para a linguagem Java. Esta ligação é feita através de um driver que “converte” o ODBC em JDBC (“sun.jdbc.odbc.JdbcOdbcDriver” e "jdbc:odbc:" + <nome da ligação introduzida em ODBC> ,"",""). Como a informação neste momento já está disponibilizada, é necessário que o servidor possa disponibilizar esses mesmos dados, para tal é utilizado o método RMI (remote method invocation), que por sua vez utiliza stubs. Posto isto os clientes (utililzador e administrador) podem utilizar a informação de uma maneira fiável. O utilizador quando executa as suas procuras, faz o acesso ao servidor e este por sua vez utiliza o raciocinio baseado em casos (CBR) juntamente com o cálculo de similaridades.

6.2 Estrutura da Base de Dados

6.2.1 Tabela de Produtos

Caixa de texto: Esta tabela contém :

o ProductId : identificador interno do produto;

o Name : titulo do produto;

o Image : local onde se encontra a imagem;

o ComplitudeRules : através de uma característica de um produto podemos indicar uma ou mais características;

o ConfigurationRules : poderá permitir alterar uma determinada propriedade do produto;

o Perguntas : A estudar.

o Respostas : Idem aspas aspas.

o Stock: número de produtos disponíveis para venda

o Substitute: id do(s) produto(s) que vieram substituir o actual que deixou de ser comercializado;

o Price : preço do produto;

o Wharehouse : local onde se encontra o produto;

o Equivalentid : id para uma base de dados de produtos equivalentes;

o Interest : percentagem de interesse de venda deste produto (Equivalentes);

o Sales : número de vendas efectuadas desse produto;

o ProductTypedId : identificador do produto que se encontra acima na arvore.

6.2.2 Tabela da ListaEquivalente, Características e Help

ListaEquivalente : Contém uma lista de todos os identificadores dos artigos equivalentes. No caso de o vendedor não dispor de um determinado produto, pode sempre indicar ao utilizador um outro que tem o mesmo objectivo final.

Características : Base de dados de todas as características que podem ser seleccionadas pelos diversos produtos, ou seja, através desta tabela é possível criar novas tabelas que vão permitir caracterizar um determinado produto como por exemplo o monitor ( ver relações entre tabelas ). Cada característica tem associado a si um determinado tipo de dados (ver Tipodados) e um identificador de ajuda (ver Help).

Help : Pequena BD que contém informação que pode ajudar o utilizador a perceber melhor uma determinada característica.

6.2.3 Tabela TipoDados e Substituição

TipoDados : Como o próprio nome indica, esta tabela contém todos os tipos de dados que podem ser utilizados:

· Datatypeid : identificador do tipo de dados;

· Domain: intervalo do tipo de dados;

· Datatype: nome do tipo de dados;

· DomainType : tipo do domínio;

· SimilarityFunction : função de similaridade associada á característica em causa;

· Description : descrição que pode ajudar o utilizador a perceber melhor o tipo de dados inserida.

Substituição : Identificador do artigo que substitui, o produto que deixou de ser vendido/comercializado.

6.2.4 Tabela TipoUtilizador e Utilizadores

Caixa de texto:

TipoUtilizador : Diversos perfis do utilizador disponíveis. Cada tipo de utilizador terá características que vão permitir distinguir os utilizadores existentes e consequentes critérios de tratamento de informação. Existe um campo chamado Active que serve para o Administrador poder bloquear ou não o acesso de um determinado utilizador.

Utilizadores : Informação relevante sobre cada utilizador. Utilizamos os campos que se encontram entre Entertainment e PersonalFinance de modo a podermos diferenciar cada um dos utilizadores, cada campo indica um determinado gosto que altera o modo como classificamos o utilizador.

6.2.5 Tabela Countries

Country : nome do país;

Quotation : campo que permite cotar um determinado país, isto para ajudar na criação do tipo de utilizador.

6.3 Relações entre tabelas

Figura 4: Relações da base de dados

Nota : Este diagrama foi criado na versão do Microsoft Access.

Existem 4 tabelas distintas :

· Produtos : Contém toda a informação necessária para se poder criar uma página na Web.

· Utilizadores : Contém os perfis de utilizador possíveis que nos irão auxiliar, no nosso ponto de vista, a dar uma resposta mais acertada.

· Caracteristicas : Ver tabela de caracteristicas.

· Countries : Tabela que contem uma lista de todos os países para que possam ser escolhidos na form de inserção ou alteração de um profile de um utilizador.

6.4 Exemplo de Execução

6.4.1 Servidor

O servidor é feito em Java RMI para poder receber mais que um pedido ao mesmo tempo e despacha-los. Este recebe a informação/pedidos tanto do(s) administrador(es) como dos utilizadores, e faz a ligação com a base de dados, modificando-a.

O servidor para ser executado basta executar na directoria do projecto a seguinte linha:

java –D java.security.policy = Server\policy –D java.rmi.server.codebase = file:///obj\ org.eu.nsk.pda.Server.pdaServer

ficando a espera dos pedidos.

6.4.2 Administração

Este cliente, é o cliente tipo para administração, que serve para criar e configurar a base de dados desejada. Para isso é-lhe pedido que insira o login (visto que pode haver mais do que um administrador), a sua respectiva password e o host onde se encontra o servidor a correr.

Depois do login aceite, o administrador entrara para o seguinte nível em que lhe serão proporcionadas bastantes opções de criação/configuração de base de dados existentes ou não.

Estas alterações serão depois visíveis na base de dados e sentidas pelos utilizadores e/ou outros administradores.

Entre os menus disponíveis, aqueles talvez mais relevantes para a parte de administração serão:

· O menu Type que de momento apenas contém uma opção que é a Operations, aonde se poderão fazer todas as operações necessárias a esta função.

Neste novo frame pode ser vista a árvore de todos os tipos existentes. Em que no tag Descrition está descrito o nome do tipo, tal como na árvore, bem como por quem foi criado, em que data e quais as suas unidades. No tag Range (Ilustrado), existem ainda três sub tag’s, noRange, em que não existe qualquer range para este tipo, Enumeration, em que o Range é dado por uma enumeração e Interval, em que o Range é dado por um intervalo. Na última Tag principal pode ser inserida, ou escolhida a função similaridade, aonde existe pelo menos a função por defeito.

· O menu Products, permite escolher uma das seguinte três operações, Operations (Ilustrada a seguir), em que se pode executar todas as operações com produtos, Find Products, em que é permitido localizar e editar um produto por nome e List All, em que são listados todos os produtos de uma forma um pouco mais detalhada.

Após seleccionada a função Operations é apresentado o seguinte frame :

Em que aparece uma lista de todos os produtos existentes, e aonde pode adicionar uma produto, Editar um produto, a fim de alterar alguma coisa nesse produto, renomear um produto e por fim remover um produto. Ao adicionar um produto, aparecerá o seguinte frame, aonde poderá preencher toda a informação relativa ao produto:

6.4.4 Utilizadores

6.4.4.1 NewUser

Este cliente foi compilado de modo a que possa trabalhar como applet, o que leva a ter de ser chamado numa pagina Html.

Iremos agora falar das restrições que achamos necessárias para o bom funcionamento do programa.

Caixa de texto:

Como é obvio o user login deverá ser introduzido e este não poderá existir na base de dados, também será necessário escolher uma password de modo a que o user tenha alguma privacidade (password e retype password deverão ser consistentes). Todos os outros campo não são obrigatórios, no entanto existem algumas verificações de veracidade como se pode verificar no Email(xxx@xx.xx). Existe ainda uma verificação do número de dias dependendo do mês e ano.

Por fim existem dois botões que servem: um para criar o utilizador (Create User) e o outro para abandonar a aplicação (Exit). No caso de existir irregularidade será visualizada uma frame com o primeiro erro detectado.

6.4.4.2 UserExists

Este cliente também foi compilado de modo a que possa trabalhar como applet, o que leva também a ser chamado numa página Html.

Caixa de texto:

Esta aplicação começa por nos enviar uma frame que nos solicita o login(já existente) e uma password. As únicas verificações que fazemos são a existência ou não do login e a coerência da password em relação ao respectivo utilizador.

Após o acesso garantido, podemos escolher a opção de alterar o perfil actual do utilizador.

Caixa de texto: Esta frame como a de inserção tem algumas diferenças. Não podemos alterar o User Login, e quando é-nos apresentada já retém os valores que se encontravam na base de dados.

Existem também dois botões tal como na inserção, mas em vez de inserir é feita uma actualização em tempo real, isto é, a informação nunca sai da base de dados, existe sempre um utilizador visto que enviamos os novos dados para a base de dados e dizemos que é para ser feita uma actualização lá.

7. Conclusão

Para já apenas nos encontramos numa primeira fase, sendo por isso muito cedo para tirar muitas conclusões, mas podemos já adiantar que estamos a gostar bastante do projecto que escolhemos e que o estamos achar bastante interessante, uma vez que se baseia em algo que poderá vir a ter muita utilidade num futuro próximo, caso seja bem implementado e depois bem utilizado.

Numa próxima fase, já poderemos falar mais afincadamente sobre a implementação do problema, uma vez que para já ainda estamos a decidir alguns aspectos que virão a ser bastante relevantes.

Como nos parece um pouco óbvio ainda não podemos fazer uma análise crítica aos resultados, mas esperamos poder faze-la em breve.

7.1 Fases a Desenvolver Posteriormente

Tendo sido feito nesta etapa do projecto, a primeira fase do modelo do PDA baseado em RBCs (Recuperação), bem como toda especificação do projecto e implementação dos diversos interfaces gráficos e conexões ao servidor, esperamos num futuro próximo poder dedicarmo-nos a seguinte fase do modelo do PDA baseado em RBCs, ou seja à fase de Adaptação.

8. Bibliografia

“Raciocínio baseado em casos” – Paulo Novais e José Neves;

“Raciocínio baseado em casos” – Fotocopias disponibilizadas pelo docente da cadeira;

“Intelligent Sales Support on the Web” - Ivo Vollrath, Wolfgang Wilke, Ralph Bergmann;

“Experience – Based Mediator agents as the basics of an electronic commerce system” – Paulo Novais, Luis Brito e José Neves;

“Java In A Nutshell” – David Flanagan;

“JDBC API Tutotial and Reference, Second Edition” – Seth White, Maydene Fisher, Rick Cattell, Graham Hamilton e Mark Hapner;