III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Uma comparao entre o Paradigma Orientado a Notificaes (PON) e o Paradigma Orientado a Objetos (POO) realizado por meio da implementao de um Sistema de Vendas
Mrcio V. Batista1, Roni F. Banaszewski1, Adriano F. Ronszcka1, Glauber Z. Valena2, Robson R. Linhares1,2, Paulo C. Stadzisz1,2, Cesar A. Tacla1,2, Jean M. Simo1,2 Universidade Tecnolgica Federal do Paran - UTFPR 1Programa de Ps-Graduao em Engenharia Eltrica e Informtica Industrial - CPGEI 2Programa de Ps-Graduao em Computao Aplicada - PPGCA marcio.venancio, ronifabio, ronszcka, gvalencio {@gmail.com}, robson@dainf.ct.utfpr.edu.br, stadzisz, tacla, jeansimao {utfpr.edu.br}

Resumo
Este artigo apresenta uma reviso dos conceitos relacionados ao Paradigma Orientado a Notificaes (PON) e uma comparao, qualitativa e quantitativa, de duas verses de uma mesma aplicao. A primeira desenvolvida de acordo com os princpios do Paradigma Orientado a Objetos (POO) e a segunda inclusive de acordo com os princpios do PON. O PON se apresenta como uma alternativa aos Paradigmas de Programao Imperativa (PI), incluindo o POO, e aos Paradigmas de Programao Declarativa (PD), propondo-se a eliminar deficincias destes no que tange a aspectos de redundncias e acoplamento de avaliaes causais que impactam no desempenho e paralelismo/distribuio de aplicaes. A comparao apresentada neste artigo abrange particularmente questes relacionadas implementao e ao desempenho. O experimento demonstra que, embora o desempenho do PON tenha sido inferior ao do POO para a aplicao desenvolvida, em funo de caractersticas da aplicao e de um ambiente de execuo ainda no totalmente adaptado ao paradigma, existem aspectos relativos maneira como se concebe os programas em PON que podem ser levados em considerao e incentivar a utilizao deste em aplicaes com requisitos de paralelismo ou distribuio. Palavras chave: Paradigma Orientado a Notificaes (PON), Sistema de Vendas em POO e PON, Comparaes entre POO e PON.

Abstract
This paper presents a review of the concepts related to the Notification-Oriented Paradigm (NOP) and a qualitative and quantitative comparison of two versions of a certain application. The first developed according to the Object-Oriented Paradigm (OOP) principles and the second developed according to the NOP principles. The NOP presents itself as an alternative to the Imperative Programming (IP) paradigms, such as OOP, as well as to the Declarative Programming (DP) paradigms, with the purpose of eliminating deficiencies of those paradigms concerning to redundancy issues and coupling of causal evaluations, which affect the execution performance and parallelism/distribution of applications. The presented comparison includes issues related to implementation and relative performance of the applications. The experiment demonstrates that, even though the NOP performance is worse than OOP performance for the developed application, due to application characteristics and a runtime environment not completely adapted to NOP, there are some aspects related to the manner with the programs are designed in NOP which can be taken into consideration and encourage the use of NOP on applications requiring parallelism and distribution. Keywords: Notification Oriented Paradigm (NOP), Sales Order System in OOP, Comparisons between OOP and NOP.

III CONGRESO INTERNACIONAL 1. Introduo

DE

COMPUTACIN

TELECOMUNICACIONES

A capacidade de processamento computacional tem crescido em funo da evoluo das tecnologias neste contexto [Tanenbaum e Van Steen, 2002]. Entretanto, recursos oferecidos por solues computacionais modernas, tais como paralelismo e distribuio ou mesmo a utilizao da capacidade plena de cada processador, nem sempre so devidamente aproveitados em funo de limitaes das tcnicas de programao [Simo e Stadzisz, 2008, 2009]. Na verdade, tcnicas de programao baseadas no estado da arte, como o chamado Paradigma de Programao Orientada a Objetos (POO) ou os Sistemas Baseados em Regras (SBR), sofrem de limitaes intrnsecas de seus paradigmas. Estes paradigmas poderiam ser genericamente classificados como Paradigma Imperativo (PI) e Paradigma Declarativo (PD) que englobam respectivamente o POO e os SBR [Banaszewski, 2009]. Particularmente, estes paradigmas levam ao forte acoplamento de expresses causais e redundncias decorrentes das suas avaliaes. Estas limitaes dificultam a execuo paralela ou distribuda de programas e freqentemente comprometem o seu desempenho pleno mesmo em sistemas monoprocessados. Assim, existem motivaes para buscas de alternativas aos PI e PD, com o objetivo de eliminar ou diminuir as desvantagens deles [Banaszewski et al., 2007][Banaszewski, 2009][Gabbrielli, Martini, 2010][Roy e Haridi, 2004] [Simo e Stadzisz, 2008, 2009]. Neste mbito, uma alternativa o Paradigma Orientado a Notificaes (PON). O PON foi concebido a partir de uma teoria de Controle Discreto e Inferncia [Simo, 2001, 2005; Simo e Stadzisz, 2002, 2008, 2009; Simo, Stadzisz e Tacla, 2009; Simo, Stadzisz e Knzle, 2003]. Ele se prope a eliminar algumas das deficincias dos atuais paradigmas em relao a avaliaes causais desnecessrias e acopladas, evitando o processo de inferncia monoltico baseado em pesquisas por meio de um mecanismo baseado no relacionamento de entidades computacionais notificantes [Banaszewski et al., 2007][Banaszewski, 2009][Simo e Stadzisz, 2008, 2009]. Neste artigo apresentada uma aplicao comercial, relativa a pedidos de venda de mercadorias. A aplicao foi construda primeiramente em POO e posteriormente em PON. O artigo contempla mais precisamente os resultados da comparao do desempenho nas implementaes em POO e PON e tambm contempla reflexes sobre a mudana de paradigma de programao e o impacto dessa mudana no tocante ao desenvolvimento de programas. Este artigo est organizado como segue: a Seo 2 sucintamente reflete o estado da arte em paradigmas de programao. A Seo 3 apresenta o PON. A Seo 4 apresenta o caso de estudo abordado neste artigo. A Seo 5 apresenta os experimentos e resultados obtidos das comparaes entre POO e PON. A Seo 6 apresenta as consideraes finais e perspectiva para trabalhos.

2. Paradigmas de Programao
A utilizao de tcnicas de PI, particularmente POO, costuma atrair os desenvolvedores devido a questes como inrcia cultural, riqueza de abstrao e flexibilidades algortmicas. Em PI, em suma, concebem-se programas como seqncias de instrues utilizando-se para tanto de buscas sobre entidades passivas (dados e comandos) organizadas segundo uma lgica de execuo que envolve, inclusive, a avaliao de expresses causais (e.g. se-ento) [Banaszewski et al., 2007] [Brookshear, 2006][Gabbrielli e Martini, 2010]. Particularmente, estas expresses so freqentemente avaliadas desnecessariamente, degradando desempenho. Isto pode ser exemplificado considerando um conjunto de
2

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

expresses se-ento que avaliam os estados de objetos dentro de um lao de repetio dito infinito. Cada expresso condicional avalia certos estados dos atributos de objetos e, se aprovada, chama alguns mtodos dos objetos que podem mudar os estados dos atributos. Isto apresentado no Algoritmo 1 [Brookshear, 2006][Gabbrielli e Martini, 2010][Simo e Stadzisz, 2008, 2009].

Algoritmo 1 - Pseudocdigo do Paradigma Imperativo enquanto ( verdade ) faa se ( ( objeto1.atributo1 = 1 ) e ( objeto2.atributo1 = 1 ) ) ento objeto1.mtodo1(); objeto2.mtodo2(); fim-se ... se ( ( objeto1.atributoN = N ) e ( objeto2.atributoN = N ) ) ento objeto1.mtodoN(); objeto2.mtodoN(); fim-se fim-enquanto

Neste exemplo, observado que o lao de repetio fora a avaliao (ou inferncia) de todas as condies de maneira seqencial. Entretanto, muitas delas so desnecessrias porque somente alguns objetos tm o valor de seus atributos modificado. Isto at pode ser considerado no importante neste exemplo simples e pedaggico, sobretudo se o nmero N de expresses causais for pequeno. Entretanto, se for considerado um sistema complexo, integrando muitas partes como aquela, pode-se ter uma grande diferena de desempenho [Forgy, 1982][Friedman-Hill, 2003][Simo e Stadzisz, 2008, 2009]. Por sua vez, em PD, salientando SBR, existe a vantagem da programao em alto nvel. Primeiramente, define-se uma Base de Fatos composta por entidades como objetos com atributos/mtodos. Subseqentemente define-se a Base de Regras com relaes causais relativas aos elementos da Base de Fatos. Estas duas bases so processadas por meio de uma Mquina de Inferncia. Esta automaticamente compara regras e fatos (e.g. estados de atributos) gerando novos fatos e, portanto, um ciclo de inferncia. No obstante a organizao e mesmo eficientes algoritmos de inferncia, a programao em PD normalmente computacionalmente cara em termos de estruturas de dados a serem processadas [Scott, 2000][Simo e Stadzisz, 2008, 2009]. Independentemente, em uma anlise mais profunda, PI e PD so similares no tocante inferncia, que normalmente se d por entidades monolticas baseadas em pesquisas sobre entidades passivas ou voltadas passividade (i.e. fracamente reativas) que conduzem a programas com passos de execuo interdependentes. Estas caractersticas contribuem para a existncia de sobreprocessamento e forte acoplamento entre expresses causais e estrutura de fatos/dados, o que dificulta a execuo dos programas de maneira otimizada, bem como paralela ou distribuda [Gabbrielli e Martini, 2010][Simo e Stadzisz, 2008, 2009]. Ainda que haja alternativas outras de programao, como orientaes a eventos e mesmo orientao a dados, elas apenas atenuam ou fatoram o problema, no o resolvendo conforme discutido em [Banaszewski, 2009; Simo e Stadzisz, 2008, 2009].

3. Paradigma Orientado a Notificaes (PON)

O PON encontra inspiraes no PI, tais como a flexibilidade algortmica e a abstrao em forma de classes/objetos da POO. O PON tambm aproveita conceitos prprios do PD, como facilidade de programao em alto nvel e a representao do conhecimento em regras dos SBR. Assim, o PON prov a possibilidade de uso (de parte) de ambos os estilos de programao em seu modelo, ainda que os evolua e mesmo os revolucione (de certa

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

maneira) no tocante ao processo de inferncia ou clculo lgico-causal [Simo e Stadzisz, 2008, 2009; Banaszewski, 2009]. De fato, o PON apresenta resposta aos problemas destes paradigmas, como repetio de expresses lgicas e reavaliaes desnecessrias delas (i.e. redundncias estruturais e temporais) e, particularmente, o acoplamento forte de entidades no tocante s avaliaes ou clculo lgico-causal. Justamente, o PON apresenta outra maneira de realizar estas avaliaes ou inferncias por meio de entidades computacionais de pequeno porte, ativas e desacopladas que colaboram por meio de notificaes pontuais e so criadas a partir do conhecimento de regras. Mais precisamente, o PON possui objetos que tratam dos elementos da base de fatos, que so genericamente modelados pela classe FBE (Fact Base Element), conforme a Figura 1. Cada FBE trata de seus atributos por meio de objetos da classe Attribute e seus servios por meio de objetos da classe Method. Os objetos FBE, por meio de seus Attributes e Methods, so passveis de correlao causal por meio de Rules, as quais se constituem em elementos fundamentais do PON.

Figura 1: Principais entidades do PON e seus relacionamentos por notificao

A Figura 2 apresenta um exemplo de Rule, na forma de uma regra causal. Mesmo se passvel de representao nesta forma, cada Rule uma entidade computacional composta por outras entidades, conforme Figura 1, que podem ser vislumbradas do ponto de vista de objetos/classes. Por exemplo, a Rule apresentada composta por um objeto Condition e um objeto Action. A Condition trata da deciso da Rule, enquanto a Action trata da execuo das aes da Rule. Assim sendo, Condition e Action trabalham juntas para realizar o conhecimento lgico e causal da Rule.

Figura 2: Exemplo de uma Rule em PON [Banaszewski, 2009]

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Esta Rule apresentada na Figura 2 faria parte de um controle de manufatura inteligente, onde equipamentos so tratados a partir de objetos inteligentes (smart-drivers em verdade) que so subtipos de FBE. A Condition desta Rule lida com a deciso de transporte de pea a partir de uma Mesa (Smart-Table) para um Torno (Smart-Lathe) utilizando um Rob (Smart-Robot). Na verdade, esta Condition composta por trs Premises que se constituem em outro tipo de objeto inteligente. Estas Premises em questo fazem as seguintes verificaes sobre as FBEs: a) o Torno est livre? b) o Rob est livre? c) h pea na posio 2 da Mesa? Assim, conclui-se (em geral) que os estados dos atributos das FBEs compem os fatos a serem avaliados pelas Premises. Na verdade, cada Premise avalia o estado de um (ou mesmo dois) Attributes de FBE. De fato, para cada mudana de estado de um Attribute da FBE, ocorrem automaticamente avaliaes (lgicas) somente nas Premises relacionadas com eventuais mudanas nos seus estados. Igualmente, a partir da mudana de estado das Premises, ocorrem automaticamente avaliaes (causais) somente nas Conditions relacionadas com eventuais mudanas de seus estados. Isto tudo se d por meio de uma cadeia de notificaes entre objetos inteligentes, o que se constitui no fundamento do PON conforme modelado na Figura 1 e esboado na Figura 3. Em suma, cada Attribute notifica as Premises relevantes sobre seus estados somente quando se fizer efetivamente necessrio. Cada Premise, por sua vez, notifica as Conditions relevantes dos seus estados usando o mesmo princpio. Baseado nestes estados notificados que a Condition pode ser aprovada ou no. Se a Condition aprovada, a respectiva Rule pode ser ativada executando sua Action. Outrossim, o conhecimento de quem se deve notificar se d na composio das Rules, em um dado ambiente de desenvolvimento PON [Banaszewski, 2009]. Por sua vez, uma Action tambm um objeto inteligente que se conecta a objetos inteligentes de outro tipo, as Instigations. Neste exemplo, a Action contm duas Instigations para: a) ativar o Rob para transportar peas da Mesa (posio 2) para o Torno; e b) preparar o Torno para receber a pea. Efetivamente, o que uma Instigation faz instigar um ou mais mtodos responsveis por realizar servios ou habilidades de uma FBE. Cada mtodo da uma FBE tambm tratado por um objeto inteligente, chamado de Method. A execuo de um Method geralmente muda o estado de um ou mais Attributes. Na verdade, os conceitos de Attribute e Method representam uma evoluo dos conceitos de atributos e mtodos de classe da OO. A diferena o desacoplamento explcito da classe proprietria e a inteligncia colaborativa pontual para com Premises e Instigations [Simo e Stadzisz, 2008].

Attributes Attribute1.1 Attribute1.n FactaBase.1 FactBases Method1.1 FactBase.n Method1.n Method2.1 Method2.n Methods Attribute2.1 Attribute2.n

Premises Premise.1 Premise.2 Premise.3 Premise.4 Premise.n

Conditions Condition.1 Condition.n Rule.1 Rules

Instigation.1 Action.1 Instigation.2 Instigation.3 Instigation.n Instigations Actions Action.n Rule.n

Figura 3: Inferncia por Notificaes [Simo e Stadzisz, 2008, 2009] 5

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Com isto considerado, nota-se que a essncia da computao no PON est organizada e distribuda entre entidades autnomas e reativas que colaboram por meio de notificaes pontuais. Este arranjo forma o mecanismo de notificaes, o qual determina o fluxo de execuo das aplicaes. Por meio deste mecanismo, as responsabilidades de um programa so divididas entre os objetos do modelo, o que permite execuo otimizada e desacoplada (i.e. minimamente acoplada) til para o aproveitamento correto de mono-processamento, bem como para o processamento distribudo. A natureza do PON leva a uma nova maneira de compor software, onde os fluxos de execuo so distribudos e colaborativos nas entidades. Muito embora o PON permita compor software em alto nvel na forma de regras, sem o conhecimento de sua essncia, este conhecimento deveras importante. Por exemplo, importante saber dos impactos de desempenho e das estratgias de distribuio, como o agrupamento de elementos de maior fluxo de notificaes juntos. Assim sendo, o PON permite uma nova maneira de estruturar, executar e pensar os artefatos de software. Outrossim, o PON atualmente est materializado na forma de um framework/wizard em C++ enquanto uma linguagem e compilador PON permanecem como um trabalho futuro. Muito embora um paradigma possa se materializar em outro (como um programa POO materializado em uma linguagem procedimental) e isto seja natural em paradigmas emergentes, seria mais confortvel e apropriado um ambiente efetivamente voltado para o PON [Banaszewski, 2009]. Neste nterim, a atual materializao do PON foi comparada em termos de processamento com implementaes PI/POO e PD/SBR. No caso de PI/POO houve comparaes com programas C++ OO usuais. No caso de PD/SBR, houve comparaes com dois shells, CLIPS e RuleWorks, que usam o eficiente motor de inferncia RETE. Estas comparaes apresentaram resultados a favor do PON, ainda que sobre toy problems [Banaszewski, 2009]. Tambm houve outras comparaes qualitativas e assintticas favorveis ao PON, inclusive em relao a motores de inferncia como RETE, TREAT, LEAPS e HAL [Banaszewski, 2009]. Todavia, outros testes sobre aplicaes reais so necessrios para demonstrar efetivamente a eficincia e eficcia do PON em relao aos atuais paradigmas de programao.

4. Caso de Estudo Sistema de Vendas de Produtos

Este artigo apresenta um caso de estudo com caractersticas de softwares usuais do mercado. Mais precisamente, o caso de estudo proposto consiste em um sistema de pedido de vendas o qual foi implementado em POO e de maneira equivalente em PON. Subseqentemente foram efetuados testes comparativos entre a implementao em POO e a em PON.

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Figura 4: Diagrama de classes do sistema de pedido de vendas.

Ao bem da verdade este tipo de sistema amplamente empregado em estabelecimentos que trabalham com venda de mercadorias. A Figura 4 apresenta o diagrama de classes do sistema proposto. Em sua a classe Pedido a fundamental do sistema, sendo composta por uma associao com classes Cliente, FormaPagamento e ListaItensPedidos. Ainda possvel verificar que a classe Produto especializada em trs tipos diferentes de produtos, que possuem polimorficamente tratamentos distintos.

Algoritmo 2 Pseudocdigo da criao de um pedido de venda. inicio cria um objeto pedido enquanto (cliente vazio ou invlido) inicio solicita cliente se (cliente informado no existe na base de dados de clientes) inicio retorna cliente invlido fim fim adiciona referncia do cliente ao pedido enquanto (produto vazio ou invlido) inicio enquanto (sesso vazia ou invlida) inicio solicita sesso se (sesso for diferente de 1, 2 ou 3) inicio retorna sesso invlida fim fim se (sesso = 1) inicio cria Produto tipo Eletro fim

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

seno se(sesso = 2) inicio cria produto tipo Livraria fim seno se(sesso = 3) inicio cria produto tipo Perecvel fim solicita cdigo do produto se (produto informado no existe na base de dados de produtos) inicio retorna produto invlido fim se (sesso = 3) inicio se (data de validade do produto for anterior a data atual) inicio retorna produto invlido e vencido fim fim solicita quantidade a ser vendida do produto se (quantidade vendida for maior que o estoque do produto) inicio retorna produto invlido e sem estoque suficiente para venda fim cria um objeto item com referncia para o produto vendido adiciona a lista de itens do pedido a referncia do item vendido se (cliente desejar informar mais produtos) inicio retorna produto invlido, isso causar nova solicitao de produto fim fim enquanto (forma pagamento vazia ou invlida) incio solicita forma de pagamento se (forma pagamento for diferente de Vista ou Prazo) inicio retorna forma de pagamento invlida fim se (forma de pagamento for Prazo) incio se(credito do cliente for menor que o valor total da venda) inicio retorna forma de pagamento invlida e crdito insuficiente fim fim fim adiciona ao pedido a referncia para a forma de pagamento se (tipo do cliente = 0) inicio no concede desconto no valor total do pedido 8

III CONGRESO INTERNACIONAL

fim

DE

COMPUTACIN

TELECOMUNICACIONES

se (tipo do cliente = 1) incio concede desconto de 5% fim ... se (tipo do cliente = 20) inicio concede desconto de 95% fim salvar pedido na base de dados de pedidos vendidos. fim

Figura 5: Fluxograma da venda de produtos.

No Algoritmo 2 apresentado o pseudocdigo da criao de um pedido de vendas, e na

9

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Figura 5 apresentado o fluxograma. Para que uma venda seja efetuada, necessita-se primeiramente informar o cliente do pedido. Em seguida, o setor do produto que se pretende vender. Escolhido o setor, devem ser informados os produtos que iro compor o pedido. O sistema possui validaes quanto existncia de produtos e clientes. Ademais, verifica-se o estoque disponvel de tais produtos. Se o produto escolhido para venda pertencer ao setor de perecveis, verifica-se sua data de validade. Na ocorrncia de produto vencido, sua venda no ser permitida. Aps todo o ciclo de informe de produtos, a venda poder ser finalizada informando a forma de pagamento. Existem apenas duas formas de pagamento possveis, Vista ou Prazo. O cliente, em seu cadastro, possui informaes sobre seu limite de crdito. Caso a forma de pagamento escolhida tenha sido Prazo, o sistema verifica se permitido que o cliente efetue a compra, confrontando o seu valor total e o limite de crdito do cliente. Ademais, no cadastro do cliente h uma informao que lhe concede um tipo de classificao. Utiliza-se este tipo para a concesso de descontos especiais durante a finalizao da venda. Existe um total de 20 tipos de clientes que dispem de descontos de 5% a 95%. O sistema foi escolhido devido relevncia de sua utilizao. Existem muitos sistemas deste mesmo domnio construdos totalmente em POO. A construo de uma verso em PON instiga grande interesse, pois, das aplicaes criadas em PON at ento, no existe nenhuma com cunho comercial e do mesmo domnio da aplicao apresentada nesse artigo.

5. Experimentos e Resultados
Os experimentos realizados foram divididos em duas etapas. As etapas foram assim divididas com base nas verses do Framework PON utilizadas. Na primeira etapa, foi utilizada a verso original, ou seja, a primeira verso estvel concebida por Banaszewski [Banaszewski, 2009]. A segunda etapa contemplou testes com a verso otimizada do Framework. Essa verso foi desenvolvida pelo quarto autor deste artigo com a ajuda dos demais autores. Em todas as etapas dos experimentos foram criados vrios pedidos de venda com o mesmo contedo, ou seja, mesmo cliente, mesmo produto, mesma forma de pagamento. Esse ambiente foi executado para a verso do sistema puramente desenvolvida sobre os princpios do POO e igualmente para a verso concebida em PON. Foram criados 100, 1000 e 10000 pedidos para os casos de testes, sendo realizadas trs repeties do mesmo experimento para garantir a veracidade dos dados. Para o sistema desenvolvido em PON foi criado um total de 48 regras, das quais so ativadas apenas 14 nos testes das Tabelas 1, 2 e 3. Nos testes da Tabela 4, por sua vez, 21 regras so ativadas. As demais regras no foram instigadas, devido ao fato de o PON tratar o cenrio de redundncia temporal de maneira mpar, evitando testes desnecessrios e redundantes. Ainda, os experimentos foram executados em um PC com processador Core 2 Duo com 3 Gigabytes de memria RAM. Para que fosse possvel executar os testes de maneira mais idnea possvel, o ambiente utilizado foi o prompt de comando (Ms-Dos) sendo executado em modo de segurana do Microsoft Windows 7. A seguir so apresentados na Tabela 1, os resultados referentes primeira etapa dos experimentos.
Total de Pedidos 100 POO 208 PON 281 Percentual de Desempenho PON (%) 35,09 (+) 10

III CONGRESO INTERNACIONAL

1000 10000

DE

COMPUTACIN
2028 22734

TELECOMUNICACIONES
46,65 (+) 32,04 (+)

2974 30019

Tabela 1: POO x PON utilizando a verso original do Framework PON Na Tabela 1, possvel constatar que o sistema escrito puramente em POO obteve um menor tempo de execuo quando comparado ao mesmo sistema escrito puramente em PON. O cenrio criado na primeira etapa dos experimentos no possibilitou ao PON explorar alguns problemas do POO. A organizao do cdigo desenvolvido em POO est de certa forma otimizada, pois no apresenta redundncia temporal, e no executa repeties e testes desnecessrios. Ademais, os pedidos criados so compostos apenas por um produto. Muitos testes causais que verificam a validade dos dados do pedido tambm no foram executados na ntegra, pois as informaes contidas nos pedidos so todas vlidas (i.e. cliente, produto, forma de pagamento).

Na segunda etapa dos experimentos novos testes foram realizados, porm, com algumas alteraes. Cada pedido composto por um total de cinco produtos. Foi adicionado tambm um indicador de tipo de cliente que oferece 20 tipos distintos de classificao. Este indicador prov um desconto especial ao concluir a venda. Esta verificao foi implementada no cdigo da verso em POO de modo aninhado (i.e. Se e Seno Se). Nos Algoritmos 3 e 4 possvel visualizar a representao da redundncia temporal na verso em POO e em PON respectivamente. Com isso foi possvel criar uma tpica redundncia temporal, a fim de verificar sua ocorrncia e no que isso reflete.
Algoritmo 3 Redundncia temporal presente na verso em POO para concesso de desconto. se (c->getTipoCliente() == 0) if (c->getTipoCliente() == 0) ento { percentualDesconto = 0.0; percentualDesconto = 0.0; fim-se } seno se (c->getTipoCliente() == 1) else if (c->getTipoCliente() == 1) ento { percentualDesconto = 0.5; percentualDesconto = 0.5; fim-se } ... ... seno se (c->getTipoCliente() == 20) else if (c->getTipoCliente() == 20) ento { percentualDesconto = 0.95; percentualDesconto = 0.95; fim-se }

Algoritmo 4 Redundncia temporal representada com regras causais e Rules PON. Rule ruleDesc0 If App atTipoCliente = 0 Then App setValue(0.0) ... Rule ruleDesc1 If App atTipoCliente = 1 Then App setValue(0.5) Rule ruleDesc20 If App atTipoCliente =20 Then App setValue(0.95)

RuleObject* ruleDesc0 = new RuleObject("Desc0", scheduler,Condition::CONJUNCTION); ruleDesco0->addPremise(new Premise(app->atTipoCliente, 0, Premise::EQUAL)); ruleDesc0->addInstigation(app->atPercentualDesconto, 0.0); ruleDesc0->end(); RuleObject* ruleDesc1 = new RuleObject("Desc1", scheduler, Condition::CONJUNCTION); ruleDesc1->addPremise(new Premise(app->atTipoCliente, 1, Premise::EQUAL)); ruleDesc1->addInstigation(app->atPercentualDesconto, 0.5); ruleDesc1->end(); 11

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

... RuleObject* ruleDesc20=new RuleObject("Desc20", scheduler, Condition::CONJUNCTION); ruleDesc20->addPremise(new Premise(app->atTipoCliente,20, Premise::EQUAL)); ruleDesc20->addInstigation(app->atPercentualDesconto, 0.95); ruleDesc20->end();

Nas tabelas a seguir (Tabelas 2, 3 e 4), os resultados apresentados foram obtidos durante a segunda etapa dos experimentos.
Total de Pedidos 100 1000 10000 POO 780 8003 103688 PON 936 9968 122725 Percentual de Desempenho PON (%) 20,00 (+) 24,55 (+) 18,36 (+)

Tabela 2: POO x PON com redundncia temporal e 5 produtos no pedido utilizando a verso original do Framework do PON

No experimento da Tabela 2, possvel verificar os resultados da execuo do sistema em um cenrio de redundncia temporal. Neste contexto, ao final de 100 execues obtm-se o equivalente a 19 testes falsos multiplicado por 100 iteraes, totalizando 1.900 testes. Aps 1.000 iteraes realizadas, totalizar 19.000 testes. Por fim, ao completar 10.000 iteraes, ter-se- 190.000 testes realizados desnecessariamente. No obstante, no experimento apresentado na Tabela 2, no h a ativao de todas as regras, assim como no cenrio da Tabela 1, pois todos os dados inseridos no pedido so vlidos, no resultando em ativao de regras (verificao de informaes invlidas). De acordo com os resultados apresentados na Tabela 2, observa-se que o sistema escrito em PON se mostrou com o pior tempo de execuo. Na Tabela 3 possvel verificar os resultados do experimento utilizando a verso otimizada do Framework PON. Tal verso apresenta melhorias em relao verso original no tocante as notificaes pontuais realizadas entre os elementos do PON.
Total de Pedidos 100 1000 10000 POO 780 8003 103688 PON 739 7992 87027 Percentual de Desempenho PON (%) 5,55 (-) 0,14 (-) 16,07 (-)

Tabela 3: PON com redundncia temporal e 5 produtos no pedido utilizando a verso otimizada do Framework PON.

Os resultados apresentados na Tabela 3 constatam uma melhora no tempo de execuo do sistema desenvolvido com a verso otimizada do Framework PON. Esta constatao pode ser verificada quando comparamos os resultados obtidos pela verso do sistema em PON, mostrados na Tabela 2, com os resultados da Tabela 3. Ademais, os resultados da Tabela 3 so melhores quando comparados ao tempo de execuo da verso do sistema em POO apresentados na Tabela 2. Na Tabela 4 o cenrio dos experimentos foi alterado. Em suma, o total de regras avaliadas foi acrescido. Para que mais regras fossem avaliadas durante o processo de execuo dos experimentos, foram inseridos cdigos invlidos (i.e. cliente, produto e forma de pagamento). Outrossim, regras que verificam a validade do produto e o crdito do cliente durante a venda prazo foram instigadas.
Total de Pedidos POO PON Percentual de Desempenho PON (%) 12

III CONGRESO INTERNACIONAL

100 1000 10000

DE

COMPUTACIN
894 9646 115253

TELECOMUNICACIONES
3,58 (+) 2,05 (+) 12,81 (+)

926 9844 130021

Tabela 4: POO x PON com redundncia temporal, 5 produtos no pedido e mais testes causais, utilizando a verso otimizada do Framework do PON

Ainda na Tabela 4, possvel verificar que a diferena de tempo de execuo entre os dois paradigmas, inicialmente com poucos pedidos criados, mnima. Ademais, os nmeros mostram que o sistema desenvolvido em PON conseguiu resultados de tempo de execuo muito prximos aos do sistema desenvolvido em POO. No obstante, era esperado um melhor tempo de execuo do PON frente ao POO, isto porque h mais testes desnecessrios e redundncias no experimento da Tabela 4. Tais resultados podem ter sido alcanados devido a possveis problemas ou rudos com a preempo do Sistema Operacional. Por fim, novos testes em melhores ambientes so vislumbrados.

7. Concluses
Esse artigo apresentou um sistema comercial relativo a pedidos de venda de mercadorias. O sistema foi desenvolvido a priori em POO e posteriormente em PON. Contemplou-se ainda o desempenho das duas implementaes. Os dados dos experimentos em geral posicionaram o POO com resultados um pouco melhores ante ao PON. Entretanto, essas constataes no so suficientes para julgar a verso do sistema sobre os princpios do POO como superior a verso em PON. Isto se d porque estas primeiras comparaes se deram em ambiente preemptivo, portanto passvel de rudo, e devido a atual materializao do PON na forma de um Framework/wizard desenvolvido sobre a linguagem C++. Neste mbito, apesar de no ser a materializao ideal, o Framework do PON tem sido freqentemente otimizado e, com isso, ganhos de desempenho considerveis vm sendo alcanados. No obstante, o PON carece de um compilador prprio, bem como tcnicas para composio de sistemas de forma mais simples. Definitivamente, uma linguagem de programao e um compilador devem ser desenvolvidos para que o PON alcance todo o seu potencial. Como um ensejo para trabalhos futuros, a mesma aplicao poder ser estendida com a criao e ativao de mais regras. Outrossim, a aplicao poder apresentar efetivamente testes mais fidedignos com nmero maior de repeties, particularmente em um ambiente mais puro e sem preempes (e.g. Linux). Por fim, os experimentos realizados constatam que o desenvolvimento de sistemas concebidos em PON so plausveis. Apesar de o Framework utilizado para a materializao do paradigma necessitar de algumas correes e melhorias, o seu estado atual permite o desenvolvimento de sistemas funcionais.

Referncias
[Banaszewski et al., 2007] Banaszewski, R. F.; Stadzisz, P. C.; Tacla, C. A.; Simo, J. M. Notification Oriented Paradigm (NOP): A software development approach based on artificial intelligence concepts, in Proceedings of the VI Congress of LAPTEC, Santos, Brazil, 2007.

13

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

[Banaszewski, 2009] Banaszewski, R. F. Paradigma Orientado a Notificaes: Avanos e Comparaes. Dissertao de Mestrado, CPGEI/UTFPR, Curitiba, 2009. Disponvel em: http://arquivos.cpgei.ct.utfpr.edu.br/Ano_2009/dissertacoes/Dissertacao_500_2009.pdf. [Brookshear, 2006] Brookshear, J. G. Computer Science: An Overview. Addison Wesley, 2006. [Gabbrielli e Martini, 2010] Gabbrielli, M., Martini, S. Programming Languages: Principles and Paradigms. Series: Undergraduate Topics in Computer Science. 1st Edition, 2010, XIX, 440 p., Softcover. ISBN: 978-1-84882-913-8. [Forgy, 1982] Forgy, C. L. RETE: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem, Artificial Intelligence N. 19, pg 17-37 - North- Holland, 1982. [Friedman-Hill, 2003] Friedman-Hill, E. Jess in Action: Rule Based System in Java. Greenwich, CT, USA: Manning Publications Co, 2003. [Roy e Haridi, 2004] Roy, P, V., Haridi, S. Concepts, Techniques, and Models of Computer Programming. MIT Press, 2004. [Scott, 2000] Scott, M. L. Programming Language Pragmatics, 2 Edition, p. 8, San Francisco, CA, USA: Morgan Kaufmann Publishers Inc, 2000. [Simo, 2001] Simo, J. M. Proposta de uma Arquitetura de Controle para Sistemas Flexveis de Manufatura Baseada em Regras e Agentes. Dissertao de Mestrado, CPGEI/UTFPR, Curitiba, 2001. [Simo, 2005] Simo, J. M. A Contribution to the Development of a HMS Simulation Tool and Proposition of a Meta-Model for Holonic Control. Tese de Doutorado, CPGEI/UTFPR, Curitiba, 2005. Disponvel em: http://arquivos.cpgei.ct.utfpr.edu.br/Ano_2005/teses/Tese_012_2005.pdf. [Simo e Stadzisz, 2002] Simo, J. M.; Stadzisz, P. C. An Agent-Oriented Inference Engine applied for Supervisory Control of Automated Manufacturing Systems. In: J. Abe & J. Silva Filho, Advances in Logic, Artificial Intelligence and Robotics (Vol. 85, pp. 234-241). Amsterdam, The Netherlands: IOS Press Books, 2002. [Simo e Stadzisz, 2008] Simo, J. M.; Stadzisz, P. C. Paradigma Orientado a Notificaes (PON) Uma Tcnica de Composio e Execuo de Software Orientado a Notificaes. Pedido de Patente submetida ao INPI/Brazil (Instituto Nacional de Propriedade Industrial) em 2008 e a Agncia de Inovao/UTFPR em 2007. N INPI Provisrio 015080004262. N INPI Efetivo PI0805518-1. Patente submetida ao INPI. Brasil, 2008. [Simo e Stadzisz, 2009] Simo, J. M.; Stadzisz, P. C. Inference Process Based on Notifications: The Kernel of a Holonic Inference Meta-Model Applied to Control Issues. IEEE Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans, Vol. 39, Issue 1, 238-250, Digital Object Identifier 10.1109/TSMCA.2008.20066371, 2009. [Simo, Stadzisz e Knzle, 2003] Simo, J. M.; Stadzisz, P. C.; Knzle, L. Rule and Agentoriented Architecture to Discrete Control Applied as Petri Net Player. 4th Congress of Logic Applied to Technology, LAPTEC, 101, p. 217, 2003. [Simo, Stadzisz e Tacla, 2009] Simo, J. M., Stadzisz, P. C.; Tacla, C. A. Holonic Control Meta-Model. IEEE Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans, Vol. 39, NO 5, September 2009. Pg. 1126-1139. [Tanenbaum e Van Steen, 2002] Tanenbaum, A.S.; Van Steen, M. Distributed Systems: Principles and Paradigms, Prentice Hall, 2002.
14

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

15