DESENVOLVIMENTO BASEADO NO CONHECIMENTO

FILOSOFIA E FUNDAMENTOS TERICOS DO GENEXUS

por Breogn Gonda e Nicols Jodal Copyright Artech 1988 2012, todos os direitos reservados ltima atualizao, abril de 2012

RESUMO: TENTA-SE MOSTRAR , DE UMA MANEIRA SIMPLES E SISTEMTICA, A FILOSOFIA E OS EMBASAMENTOS TERICOS DO G ENE XUS. BOA PARTE DESTES ELEMENTOS J SO CONHECIDOS PELA COMUNIDADE GENEXUS, MAS ESTO COLETADOS PARCIALMENTE EM DIVERSOS DOCUMENTOS . O PROPSITO GENEXUS
AUTOMATIZAR TUDO AQUILO QUE FOR AUTOMATIZVEL ,

DO

TENDO

SEGUIDO A ORIENTAO GERAL DE VIABILIZAR UMA MUDANA DE PARADIGMA: DESCREVER EM VEZ DE PROGRAMAR .

SO

NECESSRIAS DESCRIES QUE , AO MESMO TEMPO , SEJAM NATURAIS PARA OS USURIOS ,

RIGOROSAS , COMPLETAS , CONSISTENTE E QUE POSSAM SER AUTOMATICAMENTE .

COMPREENDIDAS

E PROCESSADAS

ENCONTRAR UM BOM DESENHO DESTAS DESCRIES E IMPLEMENTAR OS MECANISMOS PARA PROCESS - LAS AUTOMATICAMENTE , TORNANDO DISPONVEL TODO CONHECIMENTO QUE POSSA SER INFERIDO A PARTIR DAS MESMAS , CONSTITUI O EMBASAMENTO CIENTFICO / TECNOLGICO DO
GENEXUS

INTRODUO
O propsito deste documento ajudar a entender as idias bsicas e os conceitos tericos que fizeram possvel o GeneXus, para compreender melhor a sua essncia e os novos desenvolvimentos que iro se produzir no futuro. O primeiro propsito do GeneXus era estabelecer um robusto modelo de dados. Uma vez construdo esse modelo com todo rigor, pde-se pensar numa ampliao, incorporando elementos declarativos como regras, frmulas, telas, data providers, etc., tentando descrever as vises de dados dos usurios e, assim, abranger todo o conhecimento dos sistemas de negcios. Por que se tentou abranger todo o conhecimento dos sistemas de negcios? Porque uma condio necessria para poder projetar, gerar e manter em forma 100% automtica os sistemas computacionais de qualquer empresa. Era evidente que num determinado momento a comunidade informtica optaria por este caminho e que seria bom antecipar-se em percorr-lo tanto quando fosse possvel.

Pgina 1

Mas, como abranger todo o conhecimento dos sistemas de negcios? Como abranger a casustica que tm os sistemas de negcios? A primeira verso do GeneXus (100% declarativa) pretendia resolver o problema de gerao e manuteno de 70% dos programas. O sistema se ocupava deles em forma automtica. Os 30% restantes deviam ser programados e mantidos manualmente. Os prospects entenderam que resolver automaticamente 70% de seu problema era muito bom e at duvidaram que a manuteno automtica fosse possvel: os primeiros em adotar o GeneXus o fizeram exclusivamente pensando no aumento de produtividade no desenvolvimento. Entretanto, alguns meses mais tarde, esses clientes apreciaram o grande aumento de produtividade que conseguiam no desenvolvimento, mas apreciaram ainda muito mais a manuteno automtica. Um ano depois do lanamento, o projeto GeneXus comeou a sofrer uma forte presso de seus clientes: o sucesso da manuteno automtica e as vantagens que isso acarretava fizeram que eles exigissem manuteno automtica para tudo o que, como pr-condio, exigia gerao automtica de tudo. Isso no tinha antecedentes no mercado internacional (realmente, muitos anos depois, o GeneXus continua sendo o nico produto no mundo que resolve estes problemas). Mas ento, qual hoje a essncia do GeneXus? A essncia do GeneXus conseguir um timo tratamento automtico do conhecimento dos sistemas de negcios. Eis a essncia. Atingido esse objetivo, existe um grande conjunto de subprodutos como: Projeto, gerao e manuteno automticos da base de dados e dos programas de aplicao necessrios para a empresa. Gerao, a partir do mesmo conhecimento, para plataformas mltiplas. Integrao do conhecimento de diversas fontes para atender a necessidades muito complexas com custos em tempo e dinheiro bem inferiores aos habituais.

Gerao para as tecnologias futuras, quando essas tecnologias estiverem disponveis, a partir do conhecimento que hoje abrigam os clientes GeneXus nas suas Knowledge Bases: GeneXus trabalha com o conhecimento puro, cuja validez totalmente independente das tecnologias da moda.

Pgina 2

O desenvolvimento todo seguiu certas linhas mestras. Este documento tem o propsito de explicitar estas linhas mestras, de uma maneira simples e conceitual.

NOVO PARADIGMA: DESCREVER EM VEZ DE PROGRAMAR

Como pretendemos descrever a realidade? Pretende-se "descrever" em vez de "programar". Pretende-se maximizar as descries declarativas e minimizar as especificaes procedurais. Por que descrever em vez de programar? Esta pretenso constitui uma mudana essencial de paradigma e implica um choque cultural. As mudanas de paradigma tm o problema de sua lenta aceitao mas, se forem corretos (e este sem dvida o !), em determinado momento ocorrem os fatos que acarretam sua rpida aceitao geral. Quais so esses fatos a que nos referimos?: Hoje, a grande maioria dos sistemas se desenvolve e mantm com programao manual mas, qual tem sido a evoluo do mercado nos ltimos 40 anos? (dados do ano 2006) A complexidade dos sistemas aumentou em 2000% A produtividade das linguagens de programao aumentou em 150% Esta situao insustentvel para os negcios. Os custos crescem em forma desmedida.

Pgina 3

Podemos separar esses custos em duas dimenses: Dinheiro e Tempo. As empresas descobriram, graas disponibilidade de comunicaes rpidas e baratas, que podem atuar sobre a dimenso Dinheiro contratando o desenvolvimento e manuteno de seus sistemas em pases de baixos salrios e assim o fizeram intensamente nos ltimos anos. Na realidade, no foi resolvida a questo dos custos, mas trocou-se a unidade de medida: so basicamente as mesmas horas de trabalho ( essencialmente o mesmo trabalho), mas o preo da hora-homem bem menor. Se medirmos o custo em dinheiro, constataremos um forte abatimento. O que acontece com a dimenso Tempo? O precedente no aplicvel aos tempos. Os sistemas de negcios precisam responder a novas necessidades: as novas modalidades dos negcios, os perodos de auge alternados com as crises da economia, os novos dispositivos, os novos usurios, as novas necessidades / possibilidades de integrao. Os sistemas, por isso, tornam-se cada dia mais e mais complexos e os negcios esto sujeitos a um time to market cada vez mais crtico e que os empresrios no podem mudar. Como conseqncia, a cada dia mais negcios esto se prejudicando pelos tempos inadequados de desenvolvimento das novas solues e de manuteno das atuais. E hoje -mas sobre tudo num futuro prximo- ningum pode fazer bons negcios sem os sistemas adequados, em tempos oportunos e custos razoveis. . Esta situao no pode continuar assim por muito tempo e, primeiro aos poucos, hoje mais rapidamente, vm aparecendo exemplos disso: Em quase todos os pases mais desenvolvidos, muitas empresas esto cada vez mais lanando mo do outsourcing do desenvolvimento e a manuteno de sistemas. Este outsourcing geralmente envolve offshoring para pases de baixos salrios. Porm, ao mesmo tempo, h uma corrente crescente de empresas que seguem o caminho inverso visto que no obtiveram resultados convenientes com o mencionado outsourcing. A cada vez mais existem nos pases mais desenvolvidos empresas que experimentam grande violncia demitindo seus tcnicos e transferindo seu trabalho para tcnicos desconhecidos de pases longnquos. Evitar isso exige que os custos in house, que envolvem altos salrios, sejam similares aos do outsourcing. S ser possvel adotando tecnologias de muito alto nvel. necessrio um dramtico aumento da produtividade, porm, a produtividade das linguagens de programao h muito tempo j atingiu uma estabilizao. Como resolver o problema? Com melhores linguagens de programao? Os fatos demonstram que no! O problema no est nas linguagens de programao, mas na prpria programao. Como obter, ento, o aumento de produtividade necessrio? Fazendo desenvolvimento sustentado em conhecimento e no em programao: a soluo descrever em vez de programar!

Na Artech temos certeza disso e estamos preparados para essa exploso do mercado do desenvolvimento sustentado em conhecimento que se ir se produzir nos prximos anos.

Pgina 4

MODELO DE DADOS
Historicamente a comunidade informtica comeou trabalhando com apenas um modelo fsico com muitas rigidezes. Depois, foi introduzindo outros modelos com o objetivo de ganhar maior flexibilidade e obter certa permanncia das descries. O trabalho mais importante sobre a questo foi o relatrio de 1978 do grupo ANSI SPARC [1] que introduz trs modelos: Modelo Externo no qual se representam as vises externas dos dados. Modelo Lgico ou Conceitual: outro modelo (geralmente um modelo E-R) que se pretendia obter por abstrao da realidade. Modelo Fsico: referia-se fundamentalmente ao esquema da base de dados. A idia era desenvolver paralelamente os trs modelos para que os programas s interagissem com o Modelo Externo e, a partir do Modelo Lgico fazer um "mapping" entre esses programas e a base de dados (Modelo Fsico) e com isso tornar independentes os programas da base de dados. O relatrio foi muito elogiado no momento e, depois, quase esquecido. S um fabricante a incios da dcada de 80 tentou implementar este esquema de trs modelos. Foi o Cincom Systems para seu produto SUPRA e para diferentes linguagens acessando a base de dados SUPRA. Fora isso, o relatrio ANSI SPARC continua sendo conceitualmente vlido at hoje. A maior diferencia a tecnologia disponvel. Nos anos que se passaram, as mudanas tecnolgicas tm sido muito importantes. Analisando a questo luz da tecnologia atual, conclumos que podem existir vrios modelos, mas o modelo realmente importante para os usurios e os desenvolvedores, o Modelo Externo: nele coletamos o conhecimento exterior e o resto, como outros modelos auxiliares que poderiam ajudar, deve e pode se inferir automaticamente a partir do mencionado Modelo Externo. Neste trabalho enfatizamos no Modelo Externo, que contm o conhecimento genuno e no qual se assenta a essncia e a singularidade do GeneXus (o qu). Face a novas possibilidades da tecnologia e necessidades dos clientes, o primeiro a fazer ampliar esse Modelo Externo.

CARACTERSTICAS QUE DEVE TER NOSSO MODELO

Certamente os objetos-tipo do GeneXus podem evoluir no futuro obedecendo, no entanto, a certos princpios que seria bom mencionar aqui. Mas existe uma pergunta prvia: quem so os detentores do conhecimento nas organizaes? O nico conhecimento objetivo e bastante detalhado aquele que os usurios possuem a todo nvel sobre as vises dos dados que eles utilizam, precisam ou desejam. No existe, em troca, conhecimento objetivo sobre os prprios dados. por isso que devemos privilegiar o concreto sobre o abstrato, porque os usurios, que podem ser mltiplos e ter os perfis e papis mais diversos dentro da empresa, lidam bem com elementos concretos de seu ambiente e nem tanto com conceitos abstratos: a representao do conhecimento deve ser simples, o bastante detalhada e objetiva.

Pgina 5

Parece adequado basear-nos em um Modelo Externo que rena estas vises. Um Modelo Externo no pode conter nenhum elemento fsico ou interno tais como arquivos, tabelas, entidades, relaes entre entidades,ndices ou qualquer outro que possa ser deduzido automaticamente do mesmo (e que podem variar com o tempo). Quais elementos so desejveis e quais elementos so inaceitveis no GeneXus? Estamos tentando criar um modelo com as seguintes caractersticas: Conhecimento adequado para seu tratamento automtico. Modelo com o qual um software de computador possa trabalhar automaticamente. Ou seja, o conhecimento de nosso modelo deve ser compreensvel e opervel automaticamente. Consistncia. Modelo sempre consistente. Ortogonalidade. Os objetos que num determinado momento constituem o modelo devem ser independentes entre si. A adio de um novo objeto, sua modificao ou eliminao no acarretar a necessidade de modificar nenhum outro objeto. Projeto, gerao e manuteno automticos da base de dados e dos programas. Dentre as coisas que um software de computador pode fazer automaticamente com o modelo, so essenciais o projeto, a gerao e a manuteno automticos da base de dados e dos programas. Escalabilidade. Os elementos anteriores expressam as caractersticas qualitativas que deve ter nosso modelo. Mas pretende-se resolver problemas grandes. Para isso, precisamos que os mecanismos de armazenamento, acesso e inferncia do modelo atuem eficientemente com independncia do tamanho do problema.

MARCO DE REFERNCIA
Como representar o conhecimento de uma maneira rigorosa? Devemos estabelecer um conjunto de objetos-tipo predefinidos atravs dos quais seja possvel representar bem a realidade e que sejam automaticamente compreensveis e operveis. Um caminho que seguiu a indstria na maioria dos casos, partir de um modelo de dados E-R ou similar. Mas como obter o modelo de dados correto? Um modelo de dados corporativo precisa de centenas ou ainda milhares de tabelas. Tradicionalmente, os modelos de dados eram desenhados mediante um processo de abstrao (atravs de interlocutores que tivessem o conhecimento suficiente da empresa, identificar seus objetos relevantes e suas relaes e introduzir no modelo as correspondentes entidades e relaes). Este processo de abstrao era fortemente subjetivo: quem, na organizao, tinha um bom conhecimento dos dados? Quem tinha um bom conhecimento dos objetos e relaes relevantes que constituam o input do modelo de dados? A resposta clara e contundente: ningum. Era preciso, ento, solicitar o conhecimento de multiplicidade de pessoas e cada uma delas ia adicionando sua prpria subjetividade. Onde estava o conhecimento objetivo e suficientemente detalhado necessrio para construir nosso modelo? Certamente no existia na organizao esse conhecimento sobre os dados. Entretanto, cada usurio, a qualquer nvel, conhecia muito bem as vises de dados que utilizava, que necessitava, ou que desejava: ningum conhece os dados mas todos trabalham permanentemente com vises desses dados. Optou-se por tomar essas vises de dados como input bsico do modelo mas, como descrev-las objetivamente?

Pgina 6

Era necessrio estabelecer um slido marco de referncia sobre o qual fazer as demais descries. Esse marco de referncia est constitudo pelos Atributos. Elemento semntico fundamental: Atributo Existem atributos, cada atributo tem um nome, um conjunto de caractersticas e um significado. Para se ter um modelo de grande potncia expressiva, alm dos elementos sintticos que toda a comunidade informtica maneja sem dificuldades, devemos representar nele elementos semnticos. Mas difcil trabalhar automaticamente com a semntica. Para tratar automaticamente um elemento semntico, precisamos dar-lhe uma representao sinttica. Escolheu-se um nico elemento semntico para ser representado em nosso modelo: o significado de cada atributo. O segundo elemento bsico ento:significado, que no nosso modelo definimos da seguinte maneira: significado (atr) = nome (atr) Os nomes dos atributos passam a ser essenciais para o modelo. So necessrias normas claras para que sejam atribudos de maneira a garantir sua consistncia atravs do modelo todo. A esses efeitos, adotamos a URA (Universal Relational Assumption) que, essencialmente, significa que um atributo ter o mesmo nome em todos os lugares onde ele vier a aparecer, e que no haver dois atributos diferentes (com significado diferente) compartilhando o mesmo nome. Alm disso, necessrio que os nomes sejam auto-explicativos e muito fceis de entender por terceiros.

O terceiro elemento bsico , ento, a URA (Universal Relational Assumption). Porm, a realidade nos mostrou que a URA no basta, portanto, estabelecemos subtipos de atributos e, a seguir, subtipos de grupos de atributos. O quarto elemento est constitudo, ento, pelos subtipos. RESUMINDO: o atributo, tal qual o caracterizamos aqui (com as consideraes sobre significado, URA e subtipos), o elemento semntico fundamental da teoria do GeneXus: constitui o marco de referncia sobre o qual edificamos os modelos GeneXus.

Pgina 7

DESCRIO DA REALIDADE
Depois de introduzir o marco de referncia, descreveremos a realidade atravs de um conjunto de instncias de objetos-tipo, que especificaremos com base nos seus atributos e mediante os quais iremos coletar as caractersticas da realidade a representar.

TRANSAES
Cada usurio tem uma ou mltiplas vises dos dados que utiliza cotidianamente. Entre estas vises, podemos pensar num primeiro tipo: aquele que rene aquelas que se utilizam para manipular os dados (introduzir, modificar, eliminar e visualiz-los em forma limitada), estas vises de usurios so chamadas de Transaes e constituem o primeiro objeto-tipo do GeneXus. Cada transao tem um conjunto de elementos: Estrutura dos dados da Transao: os dados se apresentam conforme uma estrutura e devemos ter uma maneira de coletar essas estruturas com todo rigor. A seguir, veremos a estrutura de uma transao que todos conhecemos: a de uma Nota Fiscal simples.

[FATURA] Cdigo_de_Fatura * Data_de_Fatura Nome_de_Cliente Endereo de_Cliente (Cdigo_de_Produto* Descrio_de_Produto Quantidade_Vendida_Produto_na_Fatura Preo_Venda_ Produto_na_Fatura Importe_Linha_Fatura)

Pgina 8

Sub_Total_Fatura Desconto_Fatura IVA_Fatura Total_Fatura

Nesta representao existem trs grupos de atributos: um prlogo ou cabealho, que ocorre uma nica vez e que aparece no incio, um corpo que ocorre um certo nmero de vezes, e um eplogo ou p que ocorre uma nica vez. Dentro do prlogo, ao lado do atributo, aparece Cdigo_de_Fatura um *, o que significa que para cada Fatura (cada ocorrncia do Prlogo e do Eplogo) existe um nico Cdigo_de_Fatura; depois, h entre parnteses um conjunto de atributos: isso significa que este conjunto de atributos pode ocorrer mltiplas vezes dentro de cada Fatura e costumamos chamar este grupo repetitivo de corpo: o corpo deve ter um identificador, que identifica bem cada uma de suas linhas dentro da Fatura. Neste caso o Cdigo_de_Produto e essa condio apontada colocando um * direita. Depois do encerramento do grupo repetitivo encontramos um eplogo ou p. Este Diagrama de Estrutura de Dados bem como o utilizado atualmente pelo GeneXus que tem caractersticas mais grficas, tomam como antecedente os introduzidos nos trabalhos do Warnier-Orr [2] e Jackson [3]. Regras: provavelmente haver um conjunto de regras que afetam transao, como as seguintes. No haver duas Faturas com o mesmo Cdigo_de_Fatura. O Cdigo_de_Fatura ser atribudo correlativamente. A Data_de_Fatura tomar como opo por defeito a data do dia de sua emisso. A Data_de_Fatura no poder ser menor data de emisso da mencionada Fatura. No ser admitida nenhuma Fatura que deixar negativo o Estoque_do_Produto para algum de seus produtos. No ser admitida nenhuma Fatura que faa que o Saldo_Devedor_do_Cliente envolvido ultrapasse seu limite de crdito. Quando a aceitao de uma Fatura determine que o Estoque_do_Produto < Ponto_de_Pedido_Produto, para algum de seus produtos, dever ser ativada a rotina de Abastecimento (Produto). Frmulas: provavelmente haver um conjunto de frmulas que afetam a transao, como as seguintes. Importe_Linha_Fatura = Quantidade_Vendida_Produto_na_Fatura * Preo_Venda_Produto_na_Fatura Sub_Total_Fatura = sumatria dentro da Fatura (Cdigo_de_Fatura) de Importe_Linha_Fatura Desconto_Fatura = funo de clculo do desconto (Cdigo_de_Fatura) IVA_Fatura = funo de clculo do IVA (Sub_Total_Fatura Desconto_Fatura) Total_Fatura = Sub_Total_Fatura Desconto_Fatura + IVA_Fatura Saldo_Devedor_do_Cliente = sumatria de faturas impagas (Cdigo_de_Cliente) Elementos de apresentao: necessrio associar ao objeto elementos de apresentao como formatos de telas para seu desdobramento no Windows ou num Browser, estilos grficos e de dilogo, etc.

Pgina 9

As transaes so declarativas e capturando o conhecimento que existe nelas e sistematizando-o numa Knowledge Base obtm-se boa parte da descrio da realidade procurada.

CONSIDERAES SOBRE AS TRANSAES E A TEORIA RELACIONAL DO CODD [4].

Uma interpretao ligeira deste objeto, pode levar a pensar que nosso modelo entra em franca contradio com o Modelo Relacional do Codd: existem novos elementos como frmulas e subtipos que no esto includos no Modelo Relacional do Codd e grupos repetitivos, explicitamente excludas nele. O Modelo Relacional e o nosso modelo tm objetivos diferentes. Isso ser visto mais adiante, mas devemos ter claro que em nenhum momento Codd afirmou que a realidade est composta por um conjunto de relaes, o que seria um absurdo, mas sim que para armazenar adequadamente os dados e operar com eles, o modelo relacional muito adequado. O Modelo Relacional est voltado a obter uma boa representao dos dados numa Base de Dados, obedecendo a algumas condicionantes muito desejveis: eliminar a redundncia e introduzir um pequeno conjunto de regras, e evitar assim as maiores fontes de inconsistncia dos dados e introduzir um conjunto de operadores que permitam manipular os dados a bom nvel. O Modelo Externo ser utilizado para obter e armazenar o conhecimento. Este modelo pretende a representao mais direta e objetiva possvel da realidade. Por isso, tomamos as vises dos diferentes usurios. Estas vises so armazenadas no modelo. A seguir, captura-se todo o conhecimento contido nelas, sistematizando-o para maximizar as capacidades de inferncia. Neste contexto, o Modelo Relacional (ou melhor, um super-conjunto dele) utilizado para representar e/ou manipular os dados: corresponde ao chamado Modelo Interno ou Fsico ao que refere o relatrio ANSI SPARC mencionado. Na nossa teoria utiliza-se fortemente o Modelo Relacional.

PROCEDIMENTOS
Pgina 10

As Transaes, como foi visto, permitem de maneira declarativa descrever as vises de dados dos usurios e, como conseqncia, entesourar o conhecimento necessrio para projetar, gerar e manter de maneira totalmente automtica, a Base de Dados e os programas que os usurios necessitem para manipular suas prprias vises de dados. Mas isto no suficiente: existe a necessidade de processos batch ou similares. Estes processos no se podem inferir a partir do conhecimento fornecido pelas vises de dados. Quando foi liberada a primeira verso do GeneXus, as transaes resolviam cerca de 70% do problema, gerando os programas correspondentes. Faltava 30% dos programas. Para se obter 100% de cobertura s necessidades dos clientes, foi necessrio lanar mo de um objeto que permitisse descries procedurais: uma linguagem procedural de alto nvel. Como deve ser essa linguagem? Consideramos as melhores linguagens procedurais disponveis no mercado e analisado suas caractersticas. Encontraram-se construes interessantes como a conhecida For Each End For, que permite trabalhar em forma simples e em bom nvel com conjuntos de registros. Entretanto, todas as linguagens analisadas tm um problema srio: nelas necessrio referir-se a elementos fsicos de baixo nvel como tabelas e, por isso, o desenvolvedor deve saber no momento de escrever o programa, de quais tabelas deve considerar cada atributo. Para o GeneXus esta uma caracterstica inaceitvel porque uma conseqncia dela seria: se um atributo mudar a tabela, a descrio deixar de ser vlida! Em outras palavras: as tabelas no integram o Modelo Externo e, por isso, qualquer especificao que as contiver pode no ser ortogonal, por isso no poderamos garantir a manuteno automtica das aplicaes geradas. A soluo foi desenhar uma linguagem que utilizasse uma sintaxe inspirada nas mais avanadas construes das melhores linguagens mas na qual em hiptese nenhuma fosse utilizado como argumento algum elemento no pertencente ao Modelo Externo. Assim, por exemplo, em vez de nos referir a tabelas, referiremos aos conjuntos de atributos necessrios para executar uma ao dada e o sistema, em tempo de gerao automtica, quem determina quais so as tabelas envolvidas e, se for o caso, os ndices utilizados e como faz-lo e, com isso, gera o programa. No entraremos aqui no detalhe da sintaxe da linguagem. uma linguagem procedural, com instrues para manipular os dados e que tem as instrues lgicas e aritmticas normais de uma linguagem procedural de alto nvel. A caracterstica mais importante desta linguagem que suas descries mantm-se vlidas em face s mudanas estruturais da base de dados. Desta maneira, foi possvel resolver todos os problemas casusticos encontrados, respeitando sempre as linhas mestras de consistncia e ortogonalidade do GeneXus. Quais so os principais pontos altos e baixos deste objeto? Ponto muito alto: suas capacidades procedurais complementam as capacidades declarativas das Transaes (e, conforme veremos mais adiante, de outros objetos GeneXus) e garantem a resoluo de qualquer problema de sistemas de negcios.

Pgina 11

Ponto baixo: a tarefa de escrever descries procedurais permite menor produtividade que a de fazer descries declarativas, como o caso das Transaes. Novas capacidades: Na verso X do GeneXus adiciona-se um novo objeto (Data Provider) que se define em forma totalmente declarativa a partir do resultado que se deseja obter e, como output, dado o contexto adequado, nos d uma mensagem com esse resultado. Este objeto nos permite diminuir poderosamente a necessidade de Procedimentos

Os objetos-tipo mais importantes so Transao, Procedimento e Data Provider. Com eles possvel fazer uma muito razovel descrio da realidade embora, com o tempo, introduziram-se um conjunto importante de novos objetos, alguns dentre eles para conseguir que nossa descrio fosse completa e simples (GXflow que permite descrever os fluxos de trabalho das operaes do negcio e gerar o cdigo necessrio para utilizar o servidor especializado em gerenci-los), outros para permitir dilogos mais amigveis com os usurios medida que as novas arquiteturas disponveis o permitissem (Work Panels, Web Panels, GXportal), outros para facilitar a reutilizao do conhecimento permitindo um aumento da produtividade muito importante (Business Components, Patterns), outros para levar ao terreno dos usurios finais a formulao das consultas s Bases de Dados (GXquery) ou s DataWarehouses (GXplorer). Estes objetos podem combinar-se para resolver as necessidades mais complexas. completo o conjunto de objetos-tipo do GeneXus?: No algo que possa ser demonstrado teoricamente. Mas podemos afirm-lo empiricamente: os mais de 50000 desenvolvedores GeneXus no mundo todo desenvolvem sistemas importantes 100% com o GeneXus. Isso constitui uma amostra bem representativa da comunidade informtica em geral e da prpria realidade e prova que, efetivamente, completo para as necessidades dos sistemas de negcios de hoje. Mas no um conjunto fechado: provavelmente no futuro iro aparecer novas necessidades que nos levem a introduzir novos objetos-tipo, para satisfaz-las.

A IMPORTNCIA DO MODELO RELACIONAL NA CONSTRUO DA KNOWLEDGE BASE

Dado um conjunto de vises de dados razovel pensar que exista um nico modelo relacional mnimo que o satisfaa. No o demonstraremos aqui, mas se esta assero for certa, podemos encontrar um procedimento de engenharia inversa que, partindo do conjunto de vises de dados, d como resultado o esquema da mencionada base de dados relacional mnima. Obter este procedimento de engenharia inversa foi o primeiro grande resultado de pesquisa do projeto GeneXus. Depois, construir a necessria Knowledge Base sobre ele foi um muito importante e bem-sucedido trabalho permanente.

Pgina 12

MODELO EXTERNO E KNOWLEDGE BASE

A Knowledge Base tem inicialmente associado um conjunto de mecanismos de inferncia e contm regras gerais [5] independentes de qualquer aplicao particular. Ao descrever a realidade do usurio objeto armazenam-se as descries no Modelo Externo. O sistema, automaticamente, captura todo o conhecimento contido no Modelo Externo e o sistematiza, acrescentando-o tambm Knowledge Base. Adicionalmente, sobre o conhecimento anterior, o sistema infere logicamente um conjunto de resultados que ajudam a melhorar a eficincia das inferncias posteriores. GeneXus trabalha permanentemente sobre a Knowledge Base. Todo o conhecimento da Knowledge Base equivalente ao contido no Modelo Externo (subconjunto dela), j que consiste no prprio Modelo Externo mais regras e mecanismos de inferncia independentes desse Modelo Externo e um conjunto de outros elementos automaticamente inferidos a partir dele. O desenvolvedor pode alterar o Modelo Externo, modificando objetos da realidade do usurio, e as modificaes iro se propagar em forma automtica a todos os elementos necessrios: outros elementos da Knowledge Base, Base de dados e programas da aplicao. Da mesma maneira, o desenvolvedor no pode alterar diretamente nenhum elemento no pertencente ao Modelo Externo. Este trabalho ocupa-se apenas do Modelo Externo (o qu) e se abstm de tratar a Knowledge Base, que o contm e o mantm, (e que forma parte do como: um sofisticado conjunto de ferramentas matemticas e lgicas que embasam os processos de inferncia e resultados intermdios utilizados para aumentar a eficincia dessas inferncias). No necessrio conhecer nada do como para fazer um timo uso do GeneXus. O que mais importante?: O qu ou o como? Nenhum funciona sem o outro, mas se o qu no for correto, tudo estar errado. Do anterior pode-se inferir algo muito importante, que vai muito alm da implementao atual do GeneXus: TODO o conhecimento est contido no Modelo Externo e, por isso, amanh poderamos suportar a Knowledge Base de uma maneira totalmente diferente e o conhecimento de nossos clientes continuaria sendo utilizvel sem nenhum problema.

Pgina 13

Em resumo: A Knowledge Base e os mecanismos de inferncia associados constituem uma grande mquina de inferncia. Um bom exemplo disto : dada uma viso de dados podemos inferir em forma totalmente automtica o programa necessrio para sua manipulao.

DIAD E PROTOTIPAO
A prototipao um grande recurso e utilizando-o adequadamente evita-se uma exagerada dependncia do teste final ou, ainda, da posta em andamento (o Dia D, onde tudo ocorre e a Lei de Murphy particularmente aplicada). Pelas caractersticas do GeneXus, tudo pode-se provar a qualquer momento e, em particular, pode-se prototipar cada objeto no momento mais oportuno para faz-lo. Esta possibilidade sempre muito importante e conseqncia direta da teoria do GeneXus e, em particular, de sua propagao automtica das mudanas, caracterstica relevante e exclusiva.

SUMRIO DE CONCEITOS BSICOS DO GENEXUS

Tratamento automtico do conhecimento. Baseado na existncia de um modelo da realidade objeto: Modelo Externo com o qual um software de computador possa trabalhar automaticamente. Em particular, que permita: Consistncia: Modelo sempre consistente. Ortogonalidade: os objetos que constituem o Modelo Externo so independentes entre si. Adicionar um novo, sua modificao ou eliminao no implicar a necessidade de modificar nenhum outro objeto. Gerao e manuteno automticas da base de dados e dos programas. Modelo Externo: O conhecimento essencial corresponde a um "Modelo Externo", que no pode conter nenhum elemento fsico ou interno: arquivos, tabelas, entidades, relaciones entre entidades, ndices ou qualquer elemento que possa ser deduzido automaticamente do mencionado "Modelo Externo".

Pgina 14

Integrao: o GeneXus tem um conjunto de objetos prprios totalmente integrados por concepo mas, a partir de sua verso X, permite integrar outros elementos, outros mdulos ou produtos desenvolvidos pela Artech ou por terceiros.

TENDNCIAS DO GENEXUS
GeneXus um produto com uma permanente evoluo. As tendncias desta evoluo podem ser representadas sobre quatro dimenses: COMPLETUDE, PRODUTIVIDADE, UNIVERSALIDADE e USABILIDADE. COMPLETUDE: Mede a percentagem de cdigo do sistema do usurio que gerado e mantido automaticamente pelo GeneXus. Desde 1992 a completude alcanada pelo GeneXus sempre de 100%, Este um compromisso fundamental porque permite a propagao automtica das mudanas, o que representa uma diminuio dramtica dos custos de desenvolvimento e manuteno. UNIVERSALIDADE: Mede a cobertura das diferentes plataformas importantes disponveis no mercado. Hoje GeneXus suporta todas as plataformas vivas, entendendo-se por plataformas vivas aquelas que tm uma importante e crescente base instalada (por exemplo: se as plataformas do Cloud Computing vierem a se transformar em sucesso, elas devero ser rapidamente suportadas pelo GeneXus). Desta maneira, GeneXus oferece aos clientes uma grande liberdade de eleio: se uma aplicao for desenvolvida para uma determinada plataforma, com o GeneXus o cliente pode sempre transferi-la para outra plataforma suportada sem custos importantes. PRODUTIVIDADE: Mede o aumento de produtividade do desenvolvimento com o GeneXus sobre o desenvolvimento com programao manual. O objetivo de aumento de produtividade do GeneXus foi, durante muitos anos, de 500%, o que era suficiente. Mas os sistemas de que precisam os clientes so a cada dia mais complexos porque existem novos dispositivos e novas necessidades; por cima de tudo, precisam de sistemas que preencham suas necessidades, por complexas que elas sejam, e que, no entanto, permaneam simples para os usurios que, em geral, no podero ser treinados. Adicionalmente, esses sistemas devem ser desenvolvidos cada vez em tempo menor: o time to market cada vez mais crtico. No ano 2004 modificaram-se esses objetivos passando a 1000% para a verso 9 e a 2000% para a verso X. USABILIDADE: Mede a facilidade de uso. E pretende faz-lo com carter geral: facilitar o uso aos usurios tcnicos, mas tambm aumentar o alcance permitindo que cada vez mais usurios no tcnicos possam utilizar GeneXus com proveito. S o fato de utilizar GeneXus acarreta um grande aumento da usabilidade: um desenvolvedor GeneXus pode construir excelentes aplicaes para uma determinada plataforma sem precisar de um conhecimento profundo dessa plataforma o que significa um nvel mnimo importante de usabilidade. Mas pretendemos ir muito alm: pretendemos que muitos mais usurios, cada vez com menos prrequisitos tcnicos, possam se beneficiar do uso do GeneXus.

Pgina 15

A verso X ir melhorar poderosamente a usabilidade e essa tendncia continuar nas prximas verses.

COMO CONTINUAMOS? EST NOSSO MODELO EXTERNO ESCRITO EM PEDRA?

Certamente no, os princpios so permanentes e a experincia mostra a validez do feito. Mas sempre devemos observar o GeneXus criticamente para ampli-lo e assim poder descrever da maneira mais simples possvel os novos casos que a realidade vai colocar .

BIBLIOGRAFIA E REFERNCIAS
[1] ANSI-SPARC: Final report of the ANSI/X3/SPARC DBS-SG relational database task group (portal ACM, citation id=984555.1108830) [2] WARNIER-ORR: Warnier, J.D. Logical Construction of Programs. Van Nostrand Reinhold, N.Y., 1974.; Orr, K.T. Structured Systems Analysis. Englewood Cliffs, NJ, 1977: Yourdon Press; Kenneth T. Orr, Structured Systems Development, Prentice Hall PTR, Upper Saddle River, NJ, 1986. [3] JACKSON: Jackson, M.A. Principles of Program Design. London: Academic Press, 1975. [4] CODD: E. F. Codd, A relational model of data for large shared data banks, Communications of the ACM, v.13 n.6, p.377-387, June 1970 [5] REGRAS: Sem prejuzo das regras particulares que tem o modelo associado de uma determinada empresa, existem regras gerais, de validez permanente e independentes de qualquer aplicao. A ttulo de exemplo, veremos o seguinte: Necessidade da Consistncia: No pretendemos aqui tratar o tema detalhadamente, mas a principal fonte de regras, como em todas as cincias, a consistncia: supomos que a realidade consistente e, como conseqncia, toda representao que dela faamos necessariamente deve s-lo. Partindo deste princpio, podemos inferir muitas regras de validez geral que enriquecero nosso modelo. Um caso particular, simples mas muito importante, o da integridade referencial:

Pgina 16

1. Dado X, atributo simples ou composto, que chave de uma determinada tabela T1, se X aparece tambm em uma tabela T2, dada
uma fila de T2, deve existir uma fila de T1 onde T1.X = T2.X

2. Dado X, atributo simples ou composto, que chave de uma determinada tabela T1, e E, atributo simples ou composto tal que E =
subtipo(X), se E aparece em uma tabela T2, dada uma fila de T2, deve existir uma fila de T1 onde T1.X = T2.Y

3. Dado E, atributo simples ou composto, que aparece em uma Tabela T2 tal que no existe uma tabela T1 onde E chave nem X
(tal que E = subtipo(_X)) chave , E s pode aparecer na Tabela T2.

Pgina 17

CONTEDO
INTRODUO ..........................................................................................................................................................1 NOVO PARADIGMA: DESCREVER EM VEZ DE PROGRAMAR ......................................................................3 MODELO DE DADOS ..............................................................................................................................................5 MARCO DE REFERNCIA .....................................................................................................................................6 DESCRIO DA REALIDADE ...............................................................................................................................8 MODELO EXTERNO E KNOWLEDGE BASE ....................................................................................................13 SUMRIO DE CONCEITOS BSICOS DO GENEXUS ......................................................................................14 TENDNCIAS DO GENEXUS...............................................................................................................................15 BIBLIOGRAFIA E REFERNCIAS .......................................................................................................................16

Pgina 18