GENEXUS - Heurística_Apostila Teórica

Introduo Terica

1

Ferramentas e Metodologias

Nossa tarefa como profissionais de informtica consiste em desenvolver e manter aplicaes para apoiar ao usurio na sua atividade. Para realizar esta tarefa existem diferentes ferramentas e metodologias. GeneXus uma ferramenta para o desenvolvimento de aplicaes sobre bases de dados. Seu objetivo permitir a implantao de aplicaes no menor tempo e com a melhor qualidade possvel. Em linhas gerais, o desenvolvimento de uma aplicao implica tarefas de anlise, desenho e implementao. A maneira do GeneXus alcanar o objetivo anterior liberar as pessoas das tarefas automatizveis (como o desenho da base de dados), permitindo assim se concentrar nas tarefas realmente difceis e no automatizveis (como compreender os problemas do usurio). GeneXus emprega uma metodologia que tem um enfoque muito diferente das metodologias mais utilizadas. Aprender a utilizar GeneXus adequadamente vai alm de conhecer uma nova linguagem: o mais importante aprender sua metodologia.

2

Modelo da realidadeA partir das vises dos usurios

SatisfazMODELO DA REALIDADE

Engenharia Reversa

BASE DE DADOS

PROGRAMAS

VISES DE USURIOS

O primeiro problema enfrentado no desenvolvimento de aplicaes a obteno do conhecimento da realidade. Ningum dentro da empresa conhece os requerimentos e o alcance da aplicao para desenvolver toda a aplicao. Ento, como fazer para obter o conhecimento da realidade de uma forma suficientemente objetiva e detalhada ao mesmo tempo, que nos permita construir um modelo corporativo? Este conhecimento se encontra em cada uma das vises dos usurios. Cada usurio conhece bem os objetos que trabalha cotidianamente, a informao que ele gerencia, as regras que devem ser seguidas, os clculos que devem ser realizados. O ponto de partida da metodologia GeneXus : descrever as vises dos usurios para modelar o sistema; e a partir da definio da realidade do modelo, o GeneXus constri o suporte computacional - base de dados e programas - de forma totalmente automtica.

3

Desenvolvimento com GeneXus

REALIDADEDESCRIO DE OBJETOS

Utilizando GeneXus, a tarefa bsica do analista a descrio da realidade. Somente o homem pode desenvolver esta tarefa, j que s ele pode entender o problema do usurio. O analista GeneXus trabalha em alto nvel, em vez de realizar tarefas de baixo nvel como: desenhar arquivos, normalizar, desenhar programas, programar, buscar e eliminar os erros dos programas. Para comear o desenvolvimento de uma aplicao com GeneXus, primeiramente deve ser criado um novo projeto ou base de conhecimento. Uma vez criada uma nova base de conhecimento (em ingls : knowledge base; abreviado: KB), o seguinte passo descrever as vises dos usurios. Para isso, os objetos da realidade (prestando ateno aos substantivos que os usurios mencionam em suas descries, como por exemplo: clientes, produtos, faturas) e passar a defini-los mediante objetos GeneXus. Com a definio destes objetos, o GeneXus pode extrair o conhecimento, desenhar a base de dados e os programas da aplicao em forma totalmente automtica.

4

Desenvolvimento com GeneXus

REALIDADEDESCRIO DE OBJETOS

BASE DE CONHECIMENTO

Utilizando GeneXus, a tarefa bsica do analista a descrio da realidade. Somente o homem pode desenvolver esta tarefa, j que s ele pode entender o problema do usurio. O analista GeneXus trabalha em alto nvel, em vez de realizar tarefas de baixo nvel como: desenhar arquivos, normalizar, desenhar programas, programar, buscar e eliminar os erros dos programas. Para comear o desenvolvimento de uma aplicao com GeneXus, primeiramente deve ser criado um novo projeto ou base de conhecimento. Uma vez criada uma nova base de conhecimento (em ingls : knowledge base; abreviado: KB), o passo seguinte descrever as vises dos usurios. Para isso, os objetos da realidade (prestando ateno aos substantivos que os usurios mencionam em suas descries, como por exemplo: clientes, produtos, faturas) e passar a defini-los mediante objetos GeneXus. Com a definio destes objetos, o GeneXus pode extrair o conhecimento, desenhar a base de dados e os programas da aplicao em forma totalmente automtica.

5

Desenvolvimento com GeneXusREALIDADE

DESCRIO DE OBJETOS

BASE DE DADOS

BASE DE CONHECIMENTO

PROGRAMAS

A partir dos objetos definidos na base de conhecimento, GeneXus gera automaticamente tanto os programas de criao/reorganizao da base de dados como os programas da aplicao. Depois, se um objeto da realidade muda, so identificadas as novas ou diferentes caractersticas acerca do mesmo, ou encontrando objetos ainda no modelados. O analista GeneXus deve refletir sobre as mudanas correspondentes nos objetos GeneXus e a ferramenta se encarrega automaticamente de realizar as modificaes necessrias tanto na base de dados como nos programas associados. A metodologia GeneXus uma metodologia incremental, pois, parte da base da construo de um sistema mediante realizaes sucessivas. Em cada momento, o analista GeneXus define o conhecimento que tem e assim que passa a ter mais conhecimento (ou simplesmente um conhecimento diferente), reflete na base de conhecimento, e o GeneXus se ocupa de fazer automaticamente todas as adaptaes na base de dados e nos programas. Se GeneXus no for capaz de realizar automaticamente as modificaes na base de dados e nos programas, conforme sejam realizadas as mudanas que assim o requerem, o desenvolvimento incremental seria invivel

6

Alguns objetos GeneXus

Transaes(Trns)

Procedimentos(Procs)

Data Providers(DP)

Web Panels(Wbps)

e tem mais, que veremos...

Uma vez criada uma nova base de conhecimento, o passo seguinte consiste em comear a descrever os objetos da realidade mediante objetos GeneXus. Os objetos GeneXus mais importantes so: Transaes Permite definir os objetos da realidade que o usurio manipula (ex: clientes, produtos, fornecedores, faturas, etc.). So os primeiros objetos definidos, j que atravs das transaes, GeneXus infere o desenho da base de dados. Alm de ter por objetivo a definio da realidade e a conseqente criao da base de dados normalizada, cada transao tem associada uma janela para ambiente windows e outro para ambiente Web, para permitir ao usurio inserir, eliminar e modificar de forma interativa a base de dados. O analista GeneXus decidir se trabalha em ambiente windows, Web, ou ambos, e GeneXus gera os programas para isso. Procedimentos Permitem recuperar informao da base de dados, e ser mostrada na tela, em um arquivo ou impressa em papel. So as tpicas listagens ou relatrios. Alm disso, permitem atualizar informao da base de dados. Data Providers Permitem carregar e devolver dados hierrquicos para troca de informao entre objetos da mesma aplicao ou de outras aplicaes. Web Panels Permite ao usurio realizar interativamente consultas na base de dados, atravs de uma janela. Exemplo: uma web panel permite ao usurio ingressar uma faixa de caracteres, e mostra todos os clientes cujos nomes se encontram dentro dessafaixa. So objetos muito flexveis que podem ser usados para mltiplos usos. No permitem a atualizao da base de dados, somente consult-los.

7

Processo de desenvolvimento de uma aplicao com GeneXusTransaes(Trns)


Data Providers(DP)

Web Panels(Wbps)

Base de Conhecimento Base de Conhecimento

Base de Dados

Os primeiros objetos definidos so as transaes, j que a partir delas que o GeneXus extrai o conhecimento necessrio para desenhar o modelo de dados normalizado (em 3. forma normal). Depois vo se definindo os demais objetos que correspondam

8

Criao da Base de DadosTransaes(Trns)


Data Providers(DP)

Web Panels(Wbps)


Base de Dados

Programas Criao BD

GeneXus gera automaticamente os programas necessrios para criar a base de dados e os executa. Desta forma a base de dados criada pelo GeneXus de forma automtica.

9

Gerao dos Programas da aplicaoTransaes(Trns)


Data Providers(DP)

Web Panels(Wbps)


Base de Dados

Programas de Aplicao(Trns, Procs, Wbps, etc)

Depois, GeneXus gera programas de aplicao para interagir com a base de dados previamente criada.

10

Resultado final na Etapa de DesenvolvimentoTransaes(Trns)


Data Providers(DP)

Web Panels(Wbps)


Base de Dados

Programas de Aplicao(Trns, Procs, Wbps, etc.)

Uma vez criada a base de dados e gerados os programas, contamos com uma aplicao pronta para executar.

11

As vises dos usurios mudamNovas Transaes Novos Procedimentos Novos Data Providers Novos Web Panels


Base de Dados

Nova Nova Base Base de de Dados Dados

Programas de Aplicao(Trns, Procs, Wbps, DPs)

Durante o ciclo de vida da aplicao, vai surgir repetidamente necessidade de serem feitas modificaes na base de conhecimento, seja porque as vises dos usurios mudaram, ou porque devem ser feitas correes, ou acrescentar novos conhecimentos. As modificaes realizadas na base de conhecimento sero analisadas pelo GeneXus para avaliar a necessidade de efetuar mudanas na base de dados (por exemplo: modificao/criao de tabelas/ndices), ou no. Em caso de detectar mudanas para efetuar na base dados, o GeneXus vai detalhar os mesmos num relatrio de anlise de impacto (IAR: Impact Analisis Report), um relatrio que explica todas as mudanas sobre tabelas, ndices, dados, etc. que precisam ser realizados que refletem a nova realidade. Mesmo assim, no relatrio de anlise de impacto, se informam os eventuais problemas que as mudanas em questes podem ocasionar como ter inconsistncias ou redundncias.

12

Anlise de Impacto AutomticoNovas Transaes Novos Procedimentos Novos Data Providers Novos Web Panels

Anlise de impacto


Base de Dados



Algumas vezes a nova base de dados coincide com a anterior. Outras vezes isto no ocorre, e a base de dados sofre alguma modificao para representar a nova realidade. O analista deve estudar o relatrio de anlise de impacto e resolver se deseja realizar efetivamente as mudanas na base de dados, ou renunciar a base de dados e deixar como estava, ou fazer outras alteraes.

13

Gerao de Programas de Reorganizao da Base de DadosNovas Transaes Novos Procedimentos Novos Data Providers Novos Web Panels

Programas de Reorganiz.


Base de Dados



Se o analista opta por aplicar as mudanas propostas, dizemos que optou por reorganizar a base de dados. Utilizamos este termo para definir a ao de aplicar mudanas fsicas sobre a base de dados. GeneXus gera os programas que implementam as modificaes sobre as estruturas fsicas da base de dados, e mediante sua execuo nos brindar com uma nova verso da base de dados com as mudanas efetuadas.

14

Anlise automtica do impacto das mudanas sobre os programasNovas Transaes Novos Procedimentos Novos Data Providers Novos Web Panels


Anlise de Impacto sobre os programas

Nova Base de Dados

Novos Programas de Aplicao(Trns, Procs, Wbps, DPs)

Visto que se quer reorganizar a base de dados ou no, considerando as novas definies introduzidas, GeneXus estuda o impacto das alteraes sobre os programas atuais.

15

Gerao automtica de novos programasNovas Transaes Novos Procedimentos Novos Data Providers Novos Web Panels


Gerao de programas

Nova Base de Dados

Novos Programas de Aplicao(Trns, Procs, Wbps, etc.)

Por ltimo, GeneXus prossegue com a gerao/regerao dos programas de aplicao necessrios, obtendo assim uma nova verso da aplicao.

16

Nova realidade, com as mudanas na aplicaoNovas Transaes Novos Procedimentos Novos Data Providers Novos Web Panels


Nova Base de Dados

Novos Programas de Aplicao

Assim novamente teremos uma aplicao pronta para executar, com as mudanas aplicadas.

17

Environments O Lugar onde se armazena a informao para gerar a aplicao em certa plataforma de execuo se chama Environment.Environments:Implementation #1C# & SQL ServerC# Application SQL

Implementation #2 GeneXus ProjectC# & MySQLC# Application MySQL

Implementation #3Java & MySQLJava Application MySQL

Knowledge Base

O uso de vrios Environments implementaes da mesma aplicao.

permite

diferentes

18

Environments Quando se cria uma base de conhecimento (KB), GeneXus pede ao usurio que selecione o Environment que vai trabalhar:

Com estes dados, se cria automaticamente um Environment.

Para criar uma base de conhecimento, selecionar na barra do menu do GeneXus, o item File / New Knowledge Base. Em seguida vai aparecer um dilogo como o que segue:

Dever ser indicado; Nome da Knowledge Base: em nosso caso ser BillingSystem. Diretrio onde ser criada. O Environment por default: veja que so mostradas linguagens de programao. GeneXus os utilizar para criar os programas associados a base de dados. As opes oferecidas so: C# Environment, Java Environment e Ruby Environment. Language: Idioma em que vai aparecer os botes, mensagens, etc. No momento de criar a KB se comea a definir o ambiente de implementao (Environment) cujas definies sero depois completadas no momento de executar a aplicao (nome da base de dados, servidor, forma de conexo, etc).

19

Environments Para ver o Environment criado, selecionamos a janela de Preferences do Knowledge Base Navigator:

Default Environment

20

Environments Para ter implementaes em diferentes plataformas, criamos vrios Environments.

21

Environments Vemos os Environments criados:Environments:

C# & SQL Server

GeneXus ProjectJava & MySQL

Knowledge Base

O environment ativo indicado em negro e tem o icone de Play.

22

Metodologia IncrementalConstruir uma aplicao mediante aproximaes sucessivas.

DEFINIO INICIAL

A construo automtica da base de dados e programas permite ao GeneXus aplicar esta metodologia de desenvolvimento, conhecida como metodologia incremental. Como explicado anteriormente, este processo realizado mediante aproximaes sucessivas.

23

Metodologia IncrementalAplicar um desenvolvimento incremental, diferentes verses da aplicao. pode gerenciar

Verso para prototipao

Verso para colocar em produo

Referente a verses (do que se trata, como realizar, etc.) voltaremos no final. No momento suficiente saber que ao criar a base de conhecimento, os programas que estaremos executando, programas reais, sero uma verso da aplicao, de teste. Uma vez que resolvermos que essa verso est pronta para ser colocada em produo, basta fazer outra verso da aplicao, e pronto!.

24

Vantagens da Prototipao Permite ver resultados no incio Permite seguir os requerimentos do usurio Detecta os erros no incio O usurio se compromete com o desenvolvimento Sistemas de melhor qualidade

Toda comunicao susceptvel a erros: O usurio esquece certos detalhes O analista no toma nota de alguns elementos O usurio se equivoca em algumas situaes O analista interpreta mal algumas explicaes do usurio Como a implementao dos sistemas habitualmente uma tarefa que consome bastante tempo. E muitos destes problemas somente so detectados nos testes finais do sistema, o custo em tempo e dinheiro em solucion-los muito grande. Sabendo que a realidade no permanece esttica, por isto no razovel pensar que as especificaes no vo mudar at que o sistema seja implementado. A conseqncia de manter as especificaes, que se acaba implementando uma soluo relativamente insatisfatria. O impacto destes problemas diminui muito se for possvel testar cada especificao, imediatamente, e saber qual a repercusso de cada alterao sobre o resto do sistema. Uma primeira aproximao de resoluo deste problema, oferecida por diversos sistemas, a possibilidade de mostrar ao usurio formatos de janelas, relatrios, etc. animados por menus. Isto permite ajudar o usurio a ter uma idia de como o sistema ser construdo, porm no final, sempre aparecem surpresas. Uma situao bastante diferente seria colocar a disposio do usurio, para sua execuo imediata, uma aplicao funcionalmente equivalente desenhada, at nos mnimos detalhes. Isto o que faz o GeneXus: um prottipo GeneXus uma aplicao pronta, funcionalmente equivalente a aplicao de produo. Assim a aplicao pode ser totalmente provada antes de colocar em produo, e durante estes testes, o usurio afinal pode trabalhar com os dados reais, testando de uma forma natural no somente os formatos de telas, relatrios, etc., mas tambm suas frmulas, regras do negcio, estruturas de dados, etc. e trabalhar com seus dados reais. Isto somente possvel graas a construo automtica que o GeneXus realiza do suporte computacional (base de dados e programas).

25

Objeto Transao

A anlise de toda aplicao GeneXus comea com o desenho das transaes.

As transaes permitem definir os objetos da realidade.

Para identificar quais so as transaes que precisam ser criadas, se recomenda prestar ateno aos substantivos que o usurio menciona quando escreve a realidade.

Alm de ter por objetivo a definio da realidade a conseqente criao da base de dados normalizada, as transaes, igual como os demais objetos GeneXus, provocam a gerao de programas. Os programas oriundos das transaes tm o objetivo de permitir inserir, eliminar e modificar de forma interativa nas tabelas que tenham implicaes, controlando estes programas e a integridade referencial dos dados.

26

TransaesGeneralidades Definio Objeto a partir do qual GeneXus criar de forma automtica a base de dados na 3 forma normal Descrevem as vises dos usurios.

Contem toda a informao necessria referente os dados da aplicao e de como os usurios acessam o sistema para sua manipulao (inserir, modificar e eliminar). Elementos que as compem:

Alguns elementos das transaes, que sero vistos: Estrutura: Permite definir os atributos (campos) que compem a transao e a reao entre elas. A partir deles, o GeneXus conclui o desenho da base de dados: tabelas, chaves, ndices, etc. Web Form: Cada transao contm um Form (tela) Web mediante o qual se realiza inseres, eliminaes e alteraes no ambiente Web. Regras: As regras permitem definir o comportamento particular das transaes. Por exemplo, permitem definir valores por default para os atributos, definir validaes sobre os dados, etc. Eventos: As transaes suportam a programao orientada a eventos. Este tipo de programao permite definir cdigo ocioso, que se ativa em resposta a certas aes provocadas pelo usurio ou pelo sistema. Variveis: Permite a definio de variveis que so locais a Transao. Propriedades: Permitem definir certos detalhes referentes ao comportamento da transao. Documentao: Permite a incluso de texto tcnico, para ser utilizado como documentao do sistema. Ajuda: Permite a incluso de texto de ajuda, para ser consultado pelos usurios em tempo de execuo da transao. Category e Work With: Patterns (padres) que podem ser aplicados a Transao com a finalidade de implementar de forma automtica certa funcionalidade. Alguns destes elementos tambm esto associados a outros tipos de objetos GeneXus.

27

TransaesEstruturaExemplo: Precisa registrar informao de fornecedores.

Definir a transao Supplier, com estrutura: { SupplierId* SupplierName SupplierAddress SupplierPhone } Identificador de fornecedor Nome de fornecedor Endereo de fornecedor Telefone de fornecedor

A estrutura de uma transao permite definir que atributos integram a mesma e como esto relacionados. Por exemplo, se numa aplicao necessrio registrar informao de fornecedores, ter que ser definido uma transao, a qual podemos dar o nome Supplier e sua estrutura pode ser a seguinte: {SupplierId* SupplierName SupplierAddress SupplierPhone } Esta lista de nomes (um dos quais est sucedido do smbolo asterisco) corresponde aos atributos dos fornecedores que interessam ser mantidos. Ento, criamos uma transao de nome Supplier cuja estrutura composta dos atributos SupplierId*, SupplierName, SupplierAddress e SupplierPhone. Isto significa que cada fornecedor identificado por um cdigo SupplierId (o qual fica determinado pelo asterisco aps o atributo), ter um nome SupplierName, um endereo SupplierAddress e um telefone SupplierPhone. Para cada atributo definido na estrutura, deveremos indicar coisas como seu tipo de dados, descrio e alguns outros detalhes mais que veremos._____________________________________________________________________________1

O asterisco corresponde a uma notao terica que utilizamos para indicar que o atributo identificador. Como veremos, esse asterisco em GeneXus aparece representado por um cone de chave e o usurio pode configur-lo mediante um menu contextual que oferece esta possibilidade.

28

TransaesEstruturaEstrutura em GeneXus:

Atributos Chave Na pgina anterior foi explicado que o asterisco aps o atributo SupplierId indica que o mesmo o identificador na transao. Toda transao deve ter pelo menos um identificador, isto , um atributo ou conjunto de atributos que definam a unicidade da informao. No exemplo no vo existir dois fornecedores com o mesmo valor de SupplierId. Em definitivo se trata do conceito de chave primria, e para fazer a escolha dos atributos que a compem, devemos levar em considerao os requisitos da realidade do objeto. Nos casos em que no se pode determinar um identificador, deve-se optar por criar um atributo artificial (no existente na realidade), e que seu valor seja atribudo internamente, por exemplo, na forma correlativa. Como pode ser observado no editor de transaes GeneXus, um cone de chave representa o asterisco que usamos como notao terica. Atributo descriptor O cone com uma lupa representa o atributo que melhor descreve a transao. Em outras palavras seriam os atributos que tem maior carga semntica na transao. Por default o primeiro atributo na estrutura da transao que seja do tipo de dados character, se define como atributo descriptor. possvel definir outro atributo como descriptor utilizando o menu pop-up correspondente, assim como no definir nenhum.

29

TransaesEstruturaExemplo: Precisa registrar informao referente a fatura de venda.Invoice { InvoiceId* InvoiceDate CustomerId CustomerName

Identificador de fatura Data de fatura Identificador de cliente Nome de cliente

Detail { ProductId* Identificador de produto ProductDescription Descrio de produto ProductPrice Preo de produto InvoiceDetailQuantity Quantidade de produto levada da linha InvoiceDetailAmount Valor da linha de fatura } InvoiceAmount Valor total da fatura }

Nveis de uma transao A transao Invoice consta de dois nveis: o primeiro nvel fica implcito, no necessitando de um jogo de chaves; e o segundo nvel corresponde ao conjunto de atributos que ficam definidos entre chaves . O fato de definir um segundo nvel significa que existem vrias instncias do mesmo, para cada instancia do nvel anterior. No exemplo, um cabealho da fatura e seus vrios produtos. Cada nvel de uma transao define um grupo de atributos que devem operar em conjunto, ou seja, se insere, elimina ou se altere conjuntamente na base de dados. Chamamos de transao plana a uma transao de um nvel s. Assim, podemos dizer que a transao Supplier a transao plana. A diferena da transao Invoice que contm dois nveis. comum falarmos de cabealho para o primeiro nvel e de linhas para o segundo. Para cada nvel da transao, deve ser indicado quais atributos atuam como identificador. O identificador de cada nvel pode ser composto somente de um atributo, como o caso das transaes que vimos at agora, ou pode ser composto por vrios atributos. Na transao Invoice o atributo InvoiceId o identificador do primeiro nvel, e o atributo ProductId + o atributo dos nveis superiores o identificador do segundo nvel. Este ltimo significa que para um nmero de fatura dado, no repetido o valor do atributo ProductId em distintas linhas. Uma transao pode conter vrios nveis paralelos, assim como aninhados. ____________________________________________________________________________1 O asterisco uma notao terica representando que o atributo que o antecede identificador na transao, o jogo de chaves tambm utilizado como notao terica, para representar que os atributos contidos formam parte de um nvel aninhado, e que tem uma representao visual em GeneXus distinta, mas indica o mesmo.

30

TransaesEstruturaEstrutura em GeneXus

Em GeneXus fica visualmente claro o nvel correspondente as linhas da fatura. A cada nvel de uma transao se deve atribuir um nome, tipo1 e descrio (exceto ao primeiro nvel, que recebe como nome o da transao). Nveis paralelos e aninhados Uma transao pode ter vrios nveis aninhados, assim como nveis paralelos. Por exemplo, no caso hipottico que uma fatura pode ter vrios pagamentos, poderamos definir dois tipos de estrutura, dependendo do que se quer representar:Invoice { InvoiceId* InvoiceDate CustomerId CustomerName InvoiceAmount Detail {ProductId* ProductDescription ProductPrice InvoiceDetailQuantity InvoiceDetailAmount} Payment {InvoicePaymentDate* InvoicePaymentAmount} } Invoice { InvoiceId* InvoiceDate CustomerId CustomerName InvoiceAmount Detail {ProductId* ProductDescription ProductPrice InvoiceDetailQuantity InvoiceDetailAmount Payment {InvoicePaymentDate* InvoicePaymentAmount}} }

Na estrutura da esquerda definido uma fatura que tem muitos produtos e muitos pagamentos, mas no tem relao direta entre os produtos e os pagamentos (a no ser pelo fato de pertencerem mesma fatura). Na estrutura da direita so registrados os pagamentos por produto comprado. fcil compreender que o segundo e o terceiro nvel da transao da esquerda so paralelos. Ambos esto aninhados ao primeiro nvel, mas entre eles, so paralelos. Na estrutura da direita, so todos os nveis aninhados.________________________________________________________________________________________1

Como veremos depois, o tipo que se define para um nvel de uma transao, ser utilizada para trabalhar com business components, conceito relacionada as transaes.

31

TransaesDefinio do modelo de dados: estruturas das transaes TransaoSupplier { SupplierId* SupplierName SupplierAddress SupplierPhone }

TransaoInvoice { InvoiceId* InvoiceDate CustomerId CustomerName Detail { ProductId* ProductDescription ProductPrice InvoiceDetailQuantity InvoiceDetailAmount } InvoiceAmount }

Tabela INVOICEInvoiceId* InvoiceDate CustomerId CustomerName InvoiceAmount

Tabela INVOICEDETAILInvoiceId* ProductId* ProductDescription ProductPrice InvoiceDetailQuantity InvoiceDetailAmount

Tabela SUPPLIERSupplierId* SupplierName SupplierAddress SupplierPhone

GeneXus utiliza a estrutura das transaes para capturar o conhecimento necessrio para definir automaticamente qual o modelo de dados que ser criado. Para poder realizar a normalizao da base de dados ser realizada numa 3 forma normal, GeneXus deve extrair as dependncias funcionais existentes entre os atributos definidos na base de conhecimento. Na base de conhecimento de nosso exemplo, temos definido na transao Supplier e de sua estrutura GeneXus extramos as seguintes dependncias funcionais: SupplierId {SupplierName, SupplierAddress, SupplierPhone}

Dadas estas dependncias funcionais, GeneXus determina que deve criar uma tabela que ter por default o mesmo da transao (SUPPLIER)1, e que estar conforme nem mais nem menos que pelos quatro atributos anteriores, sendo SupplierId a chave primria da mesma:

SUPPLIER

SupplierId

SupplierName

SupplierAddress

SupplierPhone

Diremos que a transao Supplier tem a tabela associada SUPPLIER quando inserir, modificar ou eliminar pela transao, assim estaro armazenando, modificando ou eliminando fisicamente na tabela associada. _____________________________________________________________________1

Na documentao, para distinguir o nome de uma tabela do nome de uma transao escreveremos o nome da tabela em maisculo.

32

A partir da estrutura da transao Invoice, GeneXus determina que deve criar duas tabelas: Tabela INVOICE, correspondente ao primeiro nvel da transao:

Chave primria: InvoiceId

INVOICE

InvoiceId

CustomerId

CustomerName

InvoiceDate

InvoiceAmount

Tabela INVOICEDETAIL correspondente ao segundo nvel da transao:

INVOICEDETAIL

InvoiceId

ProductId

ProductDescription InvoiceDetailAmount

ProductPrice

InvoiceDetailQuantity

Chave primria: {InvoiceId, ProductId} Chave estrangeira: InvoiceId j que as dependncias funcionais so: InvoiceId {CustomerId, CustomerName, InvoiceDate, InvoiceAmount} {InvoiceId, ProductId} {ProductDescription, ProductPrice, InvoiceDetailQuantity, InvoiceDetailAmount} Observe que a chave primria da tabela INVOICEDETAIL a concatenao do identificador do primeiro nvel, InvoiceId, com o identificador do segundo nvel, ProductId. A regra geral: a chave primria da tabela correspondente a um nvel n de uma transao se obtm em concatenar os identificadores dos n-1 nveis anteriores aninhados, com o identificador desse nvel. GeneXus atribuiu um nome pr-determinado s tabelas que cria. A tabela associada ao primeiro nvel de uma transao atribui o mesmo nome que o da transao; e as tabelas dos nveis subordinados so atribudas a concatenao dos nomes dos nveis. Por isso que a tabela associada ao segundo nvel da transao Invoice recebe o nome de INVOICEDETAIL, sendo que o nome do primeiro nvel o da transao INVOICE, e o segundo nvel DETAIL. Os nomes das tabelas podem ser modificados pelo analista GeneXus quando o desejar.

33

TransaesEstruturaAo definir as novas transaes:

Customer { CustomerId* CustomerName CustomerAddress CustomerGender }

Sexo do cliente

Product { ProductId* ProductDescription ProductPrice ProductStock }

Depois de ter modelado a transao Invoice, damos conta que existem informaes de clientes e produtos que interessante manter independente das faturas. Isto , os clientes e os produtos so dois objetos de realidades independentes das faturas, para isso necessrio criar duas novas transaes "Customer" e "Product" detalhadas acima. Dependncias funcionais Com estas novas transaes definidas, aparecem novas dependncias funcionais: CustomerId {CustomerName, CustomerAddress, CustomerGender, CustomerStatus} ProductId {ProductDescription, ProductPrice, ProductStock} Que conduzem diretamente a criao de duas novas tabelas:

CUSTOMER

CustomerId

CustomerName

CustomerAddress

CustomerGender

Chave primria: CustomerId E:PRODUCT ProductId ProductDescription ProductPrice ProductStock

Chave primria: ProductId

34

TransaesNormalizao: alteraes nas tabelasTabela INVOICEInvoiceId* InvoiceDate CustomerId CustomerName InvoiceAmount

Tabela CUSTOMERCustomerId* CustomerName CustomerAddress CustomerGender

Tabela SUPPLIERSupplierId* SupplierName SupplierAddress SupplierPhone

Tabela INVOICEDETAILInvoiceId* ProductId* ProductDescription ProductPrice InvoiceDetailQuantity InvoiceDetailAmount

Tabela PRODUCTProductId* ProductDescription ProductPrice ProductStock

O conjunto total de dependncias funcionais existentes requer algumas modificaes nas tabelas INVOICE e INVOICEDETAIL desenhadas previamente para que o desenho da base de dados permanea na 3 forma normal1. Se representarmos sobre as tabelas CUSTOMER e INVOICE as dependncias funcionais encontradas para os seus atributos:

Podemos ver claramente que INVOICE viola a 3 forma normal (existe uma dependncia funcional transitiva): InvoiceId CustomerId CustomerId CustomerName InvoiceId CustomerName por tanto GeneXus normaliza, tirando o atributo CustomerName da tabela INVOICE: Agora CustomerName somente estar na tabela CUSTOMER.

_______________________________________________________________________________1

Para mais informao sobre as formas normais (3 forma normal, etc.) recomendamos a leitura do documento Fundamentos de bases de dados relacionais, que est includo no captulo Anexos do curso GeneXus no presencial. Do contrrio, pode pedir ao docente.

35

Agora veremos as dependncias funcionais encontradas nas tabelas PRODUCT e INVOICEDETAIL: podemos perceber claramente que a tabela INVOICEDETAIL est violando a 3 forma normal (existem atributos que dependem de forma parcial da chave primria): ProductId {InvoiceId, ProductId} ProductDescription ProductDescription ProductId {InvoiceId, ProductId} ProductPrice ProductPrice

Portanto GeneXus normaliza, tirando os atributos ProductDescription e ProductPrice da tabela INVOICEDETAIL: ProductDescription e ProductPrice somente ficaro na tabela PRODUCT.

36

TransaesRelaes: estabelecidas pelos nomes de atributos Conceitos iguais devem ter o mesmo nomeInvoice { InvoiceId* CustomerId CustomerName ... } Customer { CustomerId* CustomerName } Invoice { InvoiceId* InvoiceCustomerId ... } Customer { CustomerId* CustomerName }

Conceitos diferentes NO devem ter o mesmo nomeInvoice { InvoiceId* Date CustomerId CustomerName ... }

incorreto

VendorInvoice { VendorInvoiceId* Date SupplierId* SupplierName ... }

Conceitos iguais devem ter o mesmo nome e conceitos diferentes devem ter nomes diferentes. O GeneXus estabelece as relaes atravs dos nomes dos atributos, de modo que, quando encontra atributos com o mesmo nome em diferentes transaes, entende que trata-se do mesmo conceito, e mediante este conhecimento que pode normalizar. No exemplo que estamos utilizando, quando o GeneXus encontra o atributo de nome CustomerId tanto na transao "Customer" como na transao "Invoice", analisa que: o atributo tem o mesmo nome em ambas transaes, assim possuem o mesmo conceito. Na transao "Customer" CustomerId est marcado como identificador, o qual significa que chave primria na tabela fsica CUSTOMER; ento na tabela fsica INVOICE ser chave estrangeira. O atributo CustomerName, por sua parte, tambm se encontra tanto na transao "Customer" como na transao Invoice, mas a diferena de CustomerId, no est marcado como identificador em nenhuma transao do modelo; com isso, o GeneXus entende que trata-se de um atributo secundrio. As dependncias funcionais indicam que o CustomerName o determina CustomerId: InvoiceId CustomerId CustomerId CustomerName assim que o GeneXus incluir a CustomerName na tabela fsica CUSTOMER (e no na tabela fsica INVOICE). Atributos primrios e secundrios Um atributo se qualifica como primrio quando o mesmo identificador em alguma transao do modelo. No exemplo que estamos vendo, CustomerId um atributo primrio, j que identificador na transao "Customer". CustomerName, na verdade um atributo secundrio j que no identificador em nenhuma transao do modelo.

37

Atributos Armazenados e Inferidos Ao definir as transaes "Customer" e "Product", inclumos nelas certos atributos que no eliminados da transao Invoice. Os atributos CustomerId e ProductId, sero includos nas transaes "Customer" e "Product" respectivamente, e ao serem marcados como identificadores das mesmas, passaro a serem atributos primrios. O atributo CustomerName, por sua vez, se agregou na transao "Customer"; e os atributos ProductDescription e ProductPrice na transao "Product". Estes so atributos secundrios. Todos os atributos antes mencionados esto em mais de uma transao: partindo do princpio que continuam na transao Invoice tal como foi definido no princpio, e foram includos nas transaes "Customer" e "Product" respectivamente, porque notamos a necessidade de criar estes objetos. Posteriormente, apresentamos 3 estruturas das transaes em questo, para poder visualizlas juntas:Invoice { InvoiceId* InvoiceDate CustomerId CustomerName Detail { ProductId* ProductDescription ProductPrice InvoiceDetailQuantity InvoiceDetailAmount } InvoiceAmount } Customer { CustomerId* CustomerName CustomerAddress CustomerGender }

Provavelmente voc est se perguntando qual a razo dos atributos secundrios CustomerName, ProductDescription e ProductPrice continuam na estrutura da transao "Invoice". A explicao a seguinte: as estruturas das transaes, no so equivalentes s estruturas de tabelas fsicas. Nas estruturas das transaes podem ser includos atributos que no estaro nas tabelas fsicas associadas s mesmas, j que na hora de reorganizar a base de dados, o GeneXus analisa o conjunto total de dependncias funcionais existentes na base de conhecimento, e cria - ou modifica, segundo o caso - as tabelas fsicas, deixando-as na 3 forma normal. Agora, com que finalidade temos deixado os atributos secundrios CustomerName, ProductDescription e ProductPrice na estrutura da transao Invoice? Foram deixados para poder inclu-los em algum dos elementos do objeto da transao, por exemplo, nos forms (GUI-Windows e/ou Web) associados a transao Invoice, e assim poder visualizar os valores destes atributos em tempo de execuo. Ditos atributos, como temos explicado, no ficam armazenados na tabela INVOICE, nem na tabela INVOICEDETAIL; por exemplo, em tempo de execuo quando o usurio ingressa atravs de algum dos forms (GUI-Windows e/ou Web) um valor de CustomerId (atributo que armazenar na tabela INVOICE sendo chave estrangeira), a continuao mostrar CustomerName correspondente. Dizemos que o atributo CustomerName um atributo inferido na transao "Invoice", j que seu valor no est armazenado em nenhuma das tabelas associadas a mesma, mas sim que se infere isto , se obtm - da tabela CUSTOMER, dado o valor do atributo CustomerId. Analogamente, os atributos ProductDescription e ProductPrice tambm so inferidos na transao Invoice, j que no se encontram armazenados nas tabelas associadas mesma, mas sim que seus valores se inferem na tabela PRODUCT, para serem mostrados na tela.38

Product { ProductId* ProductDescription ProductPrice ProductStock }

TransaesEstrutura conveniente usar padres para os nomes dos atributos.

Facilitam a tarefa de dar nome. Facilitam a tarefa de integrao de bases de conhecimento. Facilitam a leitura do cdigo gerado.

39

TransaesEstrutura Nome de atributos: Nomenclatura GIK Componente de Entidade + Categoria [+ Qualificador + Complemento]Entity Component Cliente Cliente Cliente Cliente Fatura Fatura FaturaDetalhe FaturaCompra Category Id Nome Data Data Id Data Quantidade Id Vencimento Inicial Final Qualifier

e em ingls:Entity Component Customer Customer Customer Customer Invoice Invoice InvoiceDetail VendorInvoice Due Start End Qualifier Category Id Name Date Date Id Date Amount id

A ARTech definiu um padro para a nomenclatura de atributos: o GeneXus Incremental Knowledge Base (GIK) que utilizado pela comunidade de usurios GeneXus. Nesta nomenclatura, o nome de um atributo se forma com 4 componentes (alguns opcionais, assinalados entre parnteses retos): Componente de Entidade + Categoria [+ Qualificador + Complemento] 1 Posteriormente descrevemos em que consiste cada componente: Componente de Entidade (ou Objeto): uma Entidade um ator (ex: Customer), o objeto evento (ex: VendorInvoice, Fatura de Venda) que intervm em uma dada aplicao, representado por uma transao GeneXus. Um Componente de Entidade representa qualquer nvel subordinado ou paralelo que defina a entidade. Exemplo: A fatura tem os seguintes componentes, Invoice (cabealho), InvoiceLine (linhas da fatura). Se sugere um tamanho de 10 caracteres para representar o componente da Entidade. Categoria: a Categoria semntica do atributo que define o rol que o mesmo assume dentro do objeto e dentro do ambiente da aplicao. Sugere que no ultrapasse os 10 caracteres. Exemplos: Id (identificador), Code (cdigo), Name (nome), Date (data), Description (descrio), Price (preo), Stock (estoque)._____________________________________________________________________________1

Para pases que utilizem lnguas nas quais os adjetivos so colocados depois do substantivo. Em ingls ao contrrio, por isso a categoria (ou substantivo) vai no final. 2 Ou um conjunto de Transaes paralelas e/ou subordinadas, que falaremos mais adiante.

40

Qualificador: qualquer adjetivo ou advrbio, entorno de 10 caracteres, diferenciao conceitual ao nome do atributo para que o torne nico. Em geral refere ao texto que qualifica a categoria: Data de Vencimento. Exemplos: Start (inicial), End (final), Due (vencimento)

que agregue

Complemento: Texto livre at completar a quantidade de caracteres significativos (30) para o nome. No slide se mostram alguns exemplos de nomes de atributos. Nota 1: As letras maisculas permitem estabelecer fronteiras entre os componentes que formam os nomes dos atributos. Nota 2: Para cada componente se podem utilizar a quantidade de caracteres desejada, ainda se sugere utilizar 10 e que o nome completo no seja superior a 30.

41

DemoUma vez criada a base de conhecimento: criao das primeiras transaes

Uma vez criada a base de conhecimento, a mesma ficar aberta para comear a criar as transaes. A criao de objetos, se realiza pressionando Ctrl+N. Os objetos criados ficaro ou na pasta Objects que se pode ver no Folder View da janela KB Navigator. Se desejar que o objeto ao ser criado fique guardado em outra pasta, se deve posicionar em dita pasta e depois fazer click com o boto direito do mouse. No menu escolher New, Object. Tambm poder ser indicado a pasta no quadro de criao de um objeto como se v na imagem. mostrado um dilogo onde se deve escolher o tipo de objeto que se deseja criar (neste caso o tipo de objeto: transao), dar um nome ao objeto que se est criando (por exemplo: Customer), uma descrio longa, e a pasta na qual guardar o objeto:

Uma vez criada a transao, a mesma ficar aberta para que se defina sua estrutura.

42

TransaesDefinio de atributos F4

Para definir um atributo, simplesmente deve-se digitar no primeiro campo de uma linha (ou ramo) da estrutura, o nome do atributo que se deseja criar. Mediante a tecla de tabulao pode-se passar aos seguintes campos para indicar o tipo de dados do atributo, assim como sua descrio, e no caso que o mesmo venha a ser uma frmula (conceito que veremos em breve), como calcul-la. Com a tecla Enter pode-se passar a seguinte linha, para definir outro atributo. Uma vez definidos os atributos na estrutura da transao, somente restar guardar/salvar as mudanas. Caso necessite modificar o nome de um atributo, seu tipo de dados, descrio, nulabilidade, ou frmula, bastar dar um duplo clique sobre o campo desejado, e o mesmo habilitado e pode ser editado. Aps as alteraes as mudanas precisam ser salvas novamente. Para indicar que um ou mais atributos so identificadores na transao, deve-se selecion-los e pressionar CTRL+K; aparecero com um smbolo de chaves. Para definir o incio de outro nvel na transao, deve-se digitar CTRL+L, e automaticamente se produz uma endentao e o usurio dever dar um nome a esse nvel, assim, como definir o nome de seu tipo de dado e uma descrio para o nvel. Para indicar que um atributo de um dos nveis da transao ser o atributo descriptor, deve-se selecionlo e clicar CTRL +D. GeneXus conta com menus pop-up, que so menus que se abrem quando o usurio est posicionado em determinado contexto e fazendo click com boto direito do mouse. Por exemplo, ao clicar com o boto direito do mouse sobre um atributo da estrutura, abre-se um menu pop-up sobre o atributo selecionado, que oferece varias utilidades, como por exemplo indicar que o atributo chave (opo Toggle key), tira-lo da estrutura, pass-lo a um seguinte nvel de animao, etc. Cada atributo contm propriedades. Algumas delas (as fundamentais e obrigatrias) so as que se oferecem diretamente na estrutura para seu ingresso inline. Para acessar o dilogo que permite configurar todas as propriedades de um atributo, deve-se selecionar o item Properties do menu contextual, ou pressionando a tecla F4. Na figura alteramos a propriedade Autonumber que como veremos oportunamente, permite autonumerar atributos chave primria._______________________________________________________________________________________1 2

Veremos sua utilidade enquanto estudarmos os business components. Tambm chamados contextuais visto que variam segundo o contexto.

43

Name: o nome do atributo. Utilizado para identific-lo. Description: A Descrio ou mais propriamente Nome extenso uma definio ampliada do atributo. O atributo deve ser bem identificvel com essa descrio, com independncia do contexto, e principalmente deve ser entendvel pelo usurio final. Deve ser um identificador global do atributo, isto , no se deve atribuir dois atributos na base de conhecimento com a mesma descrio, j que ser atravs desta descrio que o usurio final poder selecionar atributos para definir suas prprias consultas na base de dados, com o GXQuery, executando relatrios dinmicos (tema bastante simples, mas que no ser abordado neste curso). Relacionadas a esta propriedade, esto s propriedades Title, Column Title e Contextual Title. As 2 primeiras por default tem o mesmo valor especificado no Description, podendo ser modificado. Title: A descrio aqui inserida colocada por default ao lado do atributo, cada vez que se utilize em sadas planas como, por exemplo: no primeiro nvel dos forms das transaes (veremos em breve os forms). Column Title: A descrio aqui inserida por default como o ttulo do atributo, cada vez que for includo na coluna de um grid. (no caso de uma transao somente se trata de um atributo inferido, como por exemplo o atributo ProductDescription na transao Invoice)1. Contextual Title: Quando o atributo pertence ao segundo nvel de uma transao, e no inferido (exemplo InvoiceDetailQuantity em Invoice), o nome da coluna do grid da transao pega desta propriedade. Observe que por default se pega da propriedade Description, mas tirando o nome da transao, pois assume o contexto. Type Definition Based on: Permite associar um domnio ao atributo. Ao atribuir um domnio a um atributo, certas propriedades do atributo so desabilitadas (como por exemplo, Data Type e Length) tomando os valores do domnio. Em caso do atributo no pertencer a um domnio, o programador deixar o valor [none] nesta propriedade, e as propriedades correspondentes ao tipo de dados do atributo estaro habilitadas para serem ingressadas. Data Type: Permite indicar o tipo de dados do atributo, onde escolhido um dos tipos de dados suportados pelo GeneXus. Dependendo do tipo de dados selecionados, haver certas propriedades, ou outras, para configurar. Length: Permite indicar o tamanho do atributo. Se na propriedade Data Type indica que o atributo numrico, ento, dever ser considerado que o tamanho inclui as posies decimais, o ponto decimal o sinal. Esta propriedade estar desabilitada quando o tipo de dados escolhido requer estabelecer um tamanho (por exemplo, quando trata do tipo de dados Date). Decimals: Se a propriedade Data Type indica que o atributo numrico, esta propriedade oferecida, para especificar a quantidade de decimais. O valor 0 neste campo, indica que trata um inteiro.

de

Signed: Se na propriedade Data Type se indica que o atributo numrico, esta propriedade oferecida, para indicar se tem sinal ou no. O valor por default False, o que indica que no sero representados valores negativos. Validation Value Range: Permite indicar uma faixa de valores vlidos para o atributo. Por exemplo: 1:20 30: - significa que os valores vlidos so entre 1 e 20; e 30 ou maior. 1234 - significa que os valores vlidos so 1, 2, 3 o 4. 'S' 'N' - significa que os valores vlidos so 'S' ou 'N'.

Picture: Permite indicar o formato de edio para a entrada e sada do atributo. Dependendo do tipo de dados do atributo, determinadas propriedades abaixo desta classe so disponibilizadas. O GeneXus fornece um nmero maior de propriedades dos atributos que as j mencionadas; dependendo do valor que se escolhe para determinada propriedade, so disponibilizadas certas propriedades relacionadas ou outras. recomendvel a leitura de todas as outras propriedades e no somente estas, acessando o Help do GeneXus.________________________________________________________________________________________1 O atributo tambm pode estar num objeto objeto Web Panel. Nesse caso, de aparecer como coluna, sempre ser oferecido por default para o nome da mesma o de sua propriedade Column Title. 2 Os domnios sero abordados mais adiante no curso, mas em resumo, o objetivo dos domnios realizar definies de dados genricos. Por exemplo: pode-se definir um domnio de nome Price e tipo de dados Numeric(10,2) e depois associar este domnio para todos os atributos que armazenam preos. Tem a vantagem que se depois desejar modificlo por exemplo para Numeric(12,2), tem que modificar somente a definio do domnio e automaticamente todos os atributos baseados nesse domnio herdam essa mudana.

44

Control Info Um atributo pode associar um tipo de controle. Os possveis tipos de controles: - Edit - Radio Button - Check Box - Combo Box - List Box - Dynamic Combo Box - Dynamic List Box A associao de certo tipo de controle de um atributo, serve para especificar o tipo de controle por default que ser usado pelo atributo, cada vez que seja incluso em um form. Quando um atributo definido com um tipo de dados bsico, o tipo de controle associado a ele o Edit, podendo ser alterado pelo programador para qualquer um dos outros tipos. Em geral GeneXus escolhe o tipo de controle para um atributo dependendo de seu tipo de dados. Se um domnio enumerado, como veremos, escolher Radio Button ou Combo Box, dependendo da quantidade de valores de domnio. No grupo Control Info do dilogo de edio das propriedades de um atributo, onde o programador pode mudar o tipo de controle associado ao atributo; e dependendo do tipo de controle escolhido, uma informao distinta pode ser solicitada. Logo, cada vez que um atributo agregado em um form, apresentar automaticamente com o tipo de controle que tenha associado. Nota No caso de associar ao atributo o tipo Edit, poder especificar que disfarce seus valores, mostrando os de outro atributo (propriedade InputType), e incluso que sugira os valores possveis ao usurio, a medida que este v digitando (propriedade Suggest), entre outras, como veremos depois, quando estudarmos Descries ao invs de cdigos. Tambm se pode escolher a cor da fonte da letra que se deseja associar por default ao atributo, assim como a cor de fundo, de modo que cada vez que se agregue o atributo em um form, se apresente automaticamente com as cores que ele tenha associado (ver grupo Appearance).

45

TransaesAtributos: Tipos de Dados Numeric, Character, Date, Boolean VarChar- Equivalente a Character, exceto na forma que armazenada no BD. - Propriedades Maximum Length e Avarage Length associadas.

Long Varchar- Permite armazenar textos longos, comentrios, etc. (memo).

DateTime- Permite armazenar uma combinao de data e hora.

Blob- Permite armazenar qualquer tipo de informao: texto, imagens, vdeos, planilhas, etc., na base de dados.

Numeric: Permite armazenar dados numricos. Quando se seleciona este tipo de dados se deve indicar a quantidade total de dgitos do nmero, a quantidade de posies decimais, e se permite sinal ou no. Exemplo: Se definimos que o tipo de dados do atributo InvoiceAmount numrico de tamanho 10, com decimais 2, e sem sinal, estamos especificando que representar nmeros com at 7 dgitos na parte inteira e 2 decimais (7 dgitos na parte inteira + ponto + 2 dgitos para os decimais = 10 dgitos). Character: Permite armazenar qualquer tipo de texto (caracteres e dgitos). Para este tipo de dados, deve ser indicado o tamanho. Exemplo: O atributo CustomerName que utilizamos para armazenar o nome de um cliente, de tipo Character e sabemos que nunca um nome ter mais de 20 caracteres, podemos fixar o tamanho: 20. Date: Permite armazenar uma data. Exemplo: O atributo InvoiceDate que utilizamos para armazenar a data de uma fatura, ser deste tipo de dados. O formato a utilizar para as data (dia-ms-ano, ms-dia-ano), se configura em forma genrica para todo o modelo dentro de um tipo especial de objeto, o objeto Language correspondente a linguagem que vai ser gerado o modelo. O objeto language existe para poder ter uma mesma aplicao traduzida em qualquer linguagem. A escolha de apresentar o ano com 2 dgitos ou 4, se configura com a propriedade Picture de cada atributo. Boolean: permite que um atributo ou varivel assuma os valores lgicos: True, False.

46

VarChar: Permite armazenar texto de tamanho varivel. Sua funo, em contraposio ao Character, otimizar o armazenamento na base de dados. Quando se seleciona o tipo de dados Varchar no dilogo de definio do atributo se acrescentam as 2 seguintes propriedades: Maximum Length e Avarage Length. A primeira para indicar o tamanho mximo de caracteres que podero armazenar, enquanto que a segunda para indicar o tamanho mdio de caracteres que se vai armazenar pelo geral. Exemplo: Quando se define um atributo do tipo Character e tamanho 60, se inserimos um dado que ocupa 25 caracteres, a capacidade restante de armazenamento do atributo (35 caracteres), se completa com brancos. O tipo de dados Varchar, aperfeioa o armazenamento da seguinte forma: se definir Avarage Length (por exemplo: 25), e Maximum Length (por exemplo: 60); ento, se o dado tem tamanho menor ou igual que 25, fica armazenado no campo (se completa brancos), exceto nos casos em que o dado seja de tamanho maior que 25, quando ficam armazenados os primeiros 25 caracteres no campo, e o resto em um rea de overflow. Em contrapartida a vantagem de otimizao do armazenamento, para os casos que se utilize a rea de overflow, ser necessrio realizar um acesso adicional tanto para a leitura como para a gravao do dado. O tipo de dados Varchar equivalente ao tipo Character em todos os sentidos, exceto na forma em que armazena os caracteres na base de dados. Podem ser aplicadas todas as funes e operadores existentes para o tipo de dados Character. Se o DBMS no suporta este tipo de dados, se criar o atributo do tipo Character. Long Varchar: Permite definir um atributo memo; isto , normalmente utilizado para armazenar textos grandes, comentrios, etc. Ao selecionar este tipo de dados deve-se indicar um tamanho mximo de caracteres. Existem duas funes para manipular este tipo de dados: GXMLines e GXGetMLi. GXMLines retorna a quantidade de linhas que tem um atributo Long Varchar, tendo como parmetro o nome do atributo, e a quantidade de caracteres que se deseja considerar por linha. Exemplo: &cantlin = GXMLines( AtribMemo, 40 ). O GXGetMLi por sua vez, extrai uma linha do atributo Long Varchar (para depois imprimi-la, por exemplo), tendo como parmetro o nome do atributo, o nmero da linha desejado, e a quantidade de caracteres que deseja considerar por linha. Exemplo: &txt = GXGetMLi( AtribMemo, 1, 40 ). Geralmente estas 2 funes so usadas combinadas, j que primeiro consulta a quantidade de linhas que tem certo atributo Long Varchar, indicando a quantidade desejada de caracteres por linha, e depois prossegue extraindo o contedo das linhas, utilizando um loop at chegar ltima linha, e desta forma eles so impressos, por exemplo. DateTime: Permite armazenar uma combinao de data e hora. A propriedade Picture deste tipo de dados, permite escolher o que desejamos mostrar sobre a data, e o que desejamos mostrar sobre a hora. Referente a data podemos escolher entre: no mud-la, mud-la e apresentar o ano com 2 dgitos, mud-la e apresentar o ano com 4 dgitos. Referente a hora podemos escolher entre: mudar somente 2 dgitos para a hora (no administrando minutos nem segundos), mudar 2 dgitos para a hora e 2 dgitos para os minutos (no administrando segundos), mudar 2 dgitos para a hora, 2 dgitos para os minutos e 2 dgitos para os segundos. Os valores antes mencionados no afetam a forma de armazenar o tipo de dados, caso no seja especificado a forma de aceitar ou mostrar seu contedo. Nota: Em caso de no alterar a data, s a hora, o valor da data que ficar no campo ser o mnimo suportado pelo DBMS, e ser reconhecido pelo GeneXus como data vazia ou nula. No que se diz respeito hora, os valores no aceitados (minutos e/ou segundos) sero armazenados com valor zero. Blob: As aplicaes requerem cada vez mais manter e trabalhar com este tipo de informao. O tipo de dados Blob permite armazenar esta diversidade de informao na prpria base de dados, aproveitando assim os diferentes mecanismos de integridade e controle fornecido pelos DBMSs. Este tipo de dados somente pode ser utilizado quando se tem um DBMS. Para aprofundar o conhecimento nesse tipo de dados entrar no Help GeneXus.

47

TransaesDefinio de variveisEm todo objeto GeneXus possvel definir variveis. As variveis so visveis somente dentro do objeto; isto , so locais. Editor similar ao da estrutura das transaes:

possvel definir variveis do tipo coleo (qualquer tipo de dados).

Para definir variveis em determinado objeto, deve selecionar o seletor Variveis, como se mostra na figura. Este seletor mostra variveis definidas por default (Standard variveis, como por exemplo a varivel Today que contem a data do sistema) para o objeto, e permite definir variveis novas atravs de um editor similar ao das transaes. Tambm se pode ir a opo Insert do menubar e escolher Variables. No quadro de dilogo que se mostra para selecionar New Varivel.

Este dilogo solicita o nome da varivel, sua descrio, tipo de dados e tamanho, o domnio, de forma anloga quando se define um atributo. A propriedade Dimensions permite indicar se a varivel ser escalar ou se tratar de um vetor (1 dimenso) o matriz (2 dimenses). O valor que oferece por default esta propriedade escalar.

48

Based On Oferece uma forma rpida de definir uma varivel. Quando se seleciona, se mostra um dilogo que mostra todos os atributos definidos na base de conhecimento; em dito dilogo, simplesmente se deve selecionar um atributo, e em seguida se defini automaticamente uma varivel com o mesmo nome e a mesma definio que o atributo. Vale declarar que se podem selecionar vrios atributos, criando nesse caso uma varivel para cada atributo selecionado, com suas mesmas caractersticas. Por outra lado, possvel definir variveis dentro do editor de cdigo de cada objeto (source, eventos, etc.), fazendo uso do menu contextual (boto direito) depois de escrever o nome da varivel. Isto , ao escrever &nomeDeVariavel (ex: &x) e pressionar boto direito do mouse. No menu contextual depois escolher Add Varivel. Variveis coleo possvel definir variveis coleo sobre qualquer tipo de dados oferecido por GeneXus. Para isso basta clicar na correspondente casinha no editor de variveis, ou indicar o valor True na propriedade Collection associada as variveis. Para percorrer depois os itens colecionados em dita varivel, se deve utilizar a estrutura de controle For in. Por exemplo, temos definido a varivel &myNumbers de tipo Numeric(4.0) Para percorrer os valores armazenados se dever criar uma nova varivel de tipo Numeric (4.0). Criamos ento a varivel &OneNumber, e declaramos: For &OneNumber in &myNumbers ---------Endfor

49

TransaesDomnios Objetivo: Realizar definies genricas. Quando os domnios devem ser utilizados? Atributos e/ou variveis com a mesma definio. Exemplo: Atributos ProductPrice InvoiceDetailAmountPreo do produto Valor total da linha

Domnios

comum ter numa base de conhecimento, atributos que compartilhem definies similares, mas que no tenham nenhuma relao. Por exemplo, comum definir todos os nomes, como atributos do tipo character e tamanho 20; ou todos os valores, como atributos do tipo numrico e tamanho 10.2. O objetivo dos domnios permitir realizar definies genricas. Como exemplo, o atributo InvoiceDetailAmount do tipo numrico e tamanho 10.2, assim como o atributo ProductPrice que do mesmo tipo e tamanho, na mesma base de conhecimento. Desse modo, podemos definir um domnio de nome Price, que seja do tipo numrico com tamanho 10.2, e a cada um dos atributos mencionados atribuir o domnio valores Price. A vantagem de faz-lo assim, que se no futuro surgir a necessidade de mudar a definio dos atributos que representam valores, a mudana realizada uma nica vez (no domnio Price), propagando-se este automaticamente aos atributos InvoiceDetailAmount e ProductPrice.

50

TransaesDomnios Domnios enumerados: manter o estado do cliente: Active, On Hold,

Closed

dominio Status

Atributo CustomerStatus de domnio StatusSe trabalha com os nomes ao invs de trabalhar com os valores: CustomerStatus = Status.Active

Existe a possibilidade de trabalhar com domnios enumerados (aqueles que representam valores finitos e particulares). Nas linguagens de programao so bem conhecidos. O caso tpico de uso para os dias da semana, quando se precisa que uma varivel tenha um dos seguintes valores: Segunda-feira, Tera-feira, Quarta-feira, Quinta-feira, Sexta-feira, Sbado, Domingo. Em nosso caso, vamos adicionar estrutura da transao Customer um atributo que representa o estado do cliente no sistema num determinado momento. Pode estar active, on hold ou closed. Uma forma de represent-lo definindo um domnio Status, que corresponde ao tipo de dados Character(1) mas para o qual explicitamente dizemos que no queremos que possa ter todos os valores desse tipo de dados, mas apenas 3: A, H e C, e dizemos tambm que queremos trabalhar dando nomes a estes 3 valores e trabalhar com seus nomes. Assim, ao A associamos o nome Active, ao H OnHold e ao C Closed. Associando ao atributo CustomerStatus o domnio Status (observar que, devido terminao do nome do atributo, ao inserir o atributo na estrutura depois de ter definido o domnio isto automaticamente sugerido pelo GeneXus) no atributo da tabela internamente ser salvo um dos 3 valores: A, H ou C, porm, no teremos de lembrar esses valores, mas sim seus cdigos: Active, OnHold e Closed. J tnhamos outro atributo com domnio enumerado: CustomerGender. Nesse caso, possua apenas 2 valores: Female e Male. Observar como o Control Info oferece para o ControlType um Combo Box ao invs de um Edit. Isto far sentido quando vermos o Form de uma transao um pouco mais adiante.

51

TransaesDomnios

Assim como o domnio pode ser associado a um atributo (e a outro domnio), da mesma forma pode ser associado a uma varivel. Um mesmo domnio pode ser referido tanto a atributos como a variveis, j que o objetivo exatamente o mesmo. Como definir um domnio? Existem vrios caminhos: 1) Opo Domains do Folder View: Mediante um editor similar ao das variveis, pode ser definido um novo domnio. 2) Visto que na tela de configurao das propriedades de um atributo onde se atribui a um atributo um domnio existente, em dita tela, se oferece um boto para criar um domnio novo. Idem com o dilogo de definio de variveis. 3) Na estrutura da transao possvel definir um novo domnio no campo de definio do tipo de dados de um atributo, simplesmente escrevendo sobre essa mesma linha, o nome do domnio, e atribuindo o tipo de dados. Por exemplo, digitando Price = Numeric(10.2) sobre a coluna Type do atributo que se est definindo, fica tambm definido o domnio de nome Price, com o tipo de dados Numeric(10.2).

52

TransaesWeb Form

Cada transao tem um Web Form.

Por default criado ao gravar a estrutura da transao, podendo ser modificado pelo programador.

Para cada transao, GeneXus cria um form web, que ser a interface com o usurio. criado por default por GeneXus ao momento de gravar a estrutura da transao, e contem todos os atributos includos na mesma, com suas respectivas descries, alm de alguns botes. Se bem criado por default, possvel modific-lo para deix-lo mais vistoso, mudar por exemplo controles de tipo edit a outros tipos de controles, agregar e/ou tirar botes, etc.

53

TransaesWeb Form da transao InvoiceControl Error Viewer

GRID

No exemplo que se mostra o form Web correspondente a transao Invoice. Atravs deste form o usurio final poder ingressar, modificar e eliminar faturas na aplicao Web. O controle Error Viewer se utiliza para poder colocar e programar no lugar onde queremos que as mensagens gerais sejam mostradas ao usurio final de uma transao Web. Poderemos especificar entre outras coisas o lugar onde queremos que este controle esteja dentro do form, seu tipo de letra, cor, etc..Observe que o segundo nvel da transao aparece no form como um control grid.

54

TransaesWeb Form da transao Customer

Domnios bsicos controles Edit Domnios enumerados controles Combo Box

55

TransaesPaletas de ferramentas para o desenho de Forms

Inserir controles: Opo View do Menubar \ Other Tool Windows \ Toolbox

Cortar, copiar e colocar controles:

Podemos definir um controle como uma rea da interface com o usurio, que tem uma forma e um comportamento determinado. Existem diferentes controles: - Texto: Permite colocar texto fixo - Atributo/Varivel: Permite colocar atributos ou variveis. - Linha horizontal - Error Viewer - Tabela: Inserir tabelas no form - Grid: Permite definir grids de dados. - Boto: Permite incluir botes nos forms. - Bitmap: Permite definir bitmaps estticos, etc. Paleta de ferramentas para inserir controles: Quando se est editando um form, se encontra disponvel uma paleta de ferramentas (Toolbox) que oferece os controles possveis de inserir no mesmo. Simplesmente se deve selecionar o controle e arrast-lo sobre o form.

56

TransaesControles em Web Form Cada controle do Web form pode ter associada uma classe, de um objeto theme (tema) determinado que est associado ao objeto. Ao criar uma KB, se cria por default o tema GeneXus X e todos os objetos criados tero este tema associado. Isto permite que o desenho da interface seja independente da programao. Cada tema vai ter muitas classes definidas para cada tipo de controle. O analista somente associa um tema ao objeto, e uma classe a cada controle do form e no precisa se preocupar com o desenho dos mesmos. O controle herda o desenho da classe do tema associado.

Para separar os aspectos de desenho grfico de um site web, dos aspectos de programao propriamente dito, existe um tipo de objeto chamado Theme (Tema em portugus). O objetivo desta separao paralelizar o desenvolvimento de um site Web, permitindo ao programador aproximar-se das tarefas de programao, e apoiar-se em um design grfico para que defina as questes de desenho. Desta maneira o design grfico configurar o tema escolhido pelo programador, e o programador somente dever aplic-lo aos objetos de sua base de conhecimento. Um objeto tema conter um conjunto de classes, para cada tipo de controle dos que podem aparecer no form Web de um objeto GeneXus. Por exemplo, ter vrias classes para o controle boto, algumas para o controle atributo, uma classe para o controle Error Viewer, etc. Quando se cria uma base de conhecimento, automaticamente aparecer dentro do Folder View da pasta Customazation com objetos Theme pr-definidos que podero ser importados na KB. Por default se importa o de nome Genexus X. Este tema contem um conjunto de classes associadas aos diferentes controles existentes. Os objetos com form Web que vo sendo criados tero por default associado este Theme, e cada controle que aparea em seus forms ter associado uma classe desse tema, para este controle.

57

TransaesControles em Web Form

Deste modo, quando o analista cria a transao "Customer e informa sua estrutura, ao grav-la pode ver que o Form Web ter automaticamente o aspecto mostrado na tela acima esquerda. Quem deu o formato a todos os controles se no foi o analista exatamente? Pois bem, todas as transaes tero associado por default o tema GeneXus X e todos os controle colocados no form, tero classes deste tema associadas. Se sobre o Text Bloxk (controle de texto) mostrado acima (Name), se editam suas propriedades (F4), pode-se observar a propriedade Class, que tem configurada a classe TextBlock. Esta propriedade pode ser mudada pelo analista. Ao clicar o combo box poderemos ver uma lista de classes possveis para esse controle (so as que figuram no tema associado). A direita mudamos a classe para uma de nome Title e no form podemos ver a repercusso no desenho do TextBlock. No entraremos em detalhe neste tema no presente curso.

58

DemoComo executar a aplicao?Opo Build \ Run Developer Menu, ou pressionar a tecla F5. F5: Dispara automaticamente todas as aes necessrias para executar a aplicao Se BD no existe, se cria automaticamente(sempre e quando usurio e password tenham permisso de DBCreator)

Lembremos que no momento de criao da KB, se indicou o gerador por default a ser utilizado. Agora deve completar a informao necessria para terminar de definir o ambiente de implementao. Database name: Nome da base de dados que estar associada a aplicao. Server name: Nome do servidor da base de dados que a administra. Use trusted connection: Yes (dever indicar o usurio e contra-senha vlido no DBMS) No Consideraes: Se a base de dados no existir, GeneXus a criar, sempre e quando o usurio e contrasenha configurados na janela de dilogo tenham permisso de DBCreator no DBMS.

59

Processo de BuildO processo de Build inclui todas as tarefas necessrias para a execuo da aplicao: Verificao de alteraes na BD, Reorganizao (se for necessrio), Especificao, Gerao e Compilao. No inclui a execuo.KBDBASE IMPACT ANALYSIS REORGANIZATION

SPECIFICATION

GENERATION

Aplicao pronta para executar

COMPILATION

APPLICATION

O processo de Build executado em background, permitindo realizar outras tarefas enquanto o mesmo estiver correndo, por exemplo continuar com o desenvolvimento.

Cada vez que se executa a aplicao (F5), GeneXus realiza uma comparao entre as definies atuais de todos os objetos e as definies da ltima execuo. Esta comparao que o GeneXus faz, se chama anlise de impacto. Este nome auto-descritivo: GeneXus analisa o impacto causado pelas novas definies, e o resultado da anlise de impacto um relatrio de anlise de impacto (IAR: Impact Analisis Report) que informa ao programador quais alteraes fsicas ou estruturais precisam ser realizadas na base de dados associada. Se por exemplo se criou uma nova transao, isto provocar (tal como o objetivo das transaes) que se criam as tabelas correspondentes na base de dados (ver pgina seguinte).

60

IAR e ReorganizaoCreate se estiver tudo OK sero construdos os programas no Environment e vai executar...

No exemplo, criar as 2 transaes Customer e Invoice e dar F5, aparece o relatrio de anlise de impacto que pode se ver, onde so listados entre outras coisas, a estrutura que ter cada tabela que ser criada, com seus atributos, tipo de dados, os ndices que sero criados sobre as tabelas, as chaves estrangeiras (observar que o relatrio da tabela INVOICE diz que se referenciar a tabela CUSTOMER (isto acontece pelo atributo CustomerId da transao Invoice que se chama igual que o atributo CustomerId de CUSTOMER, constituindo portanto uma chave estrangeira a dita tabela). Se o programador est de acordo com os alteraes estruturais informadas no relatrio de anlise de impacto, poder prosseguir, passando a reorganizar a base de dados. O trmino reorganizar refere a efetuar alteraes fsicas na base de dados. Se na alterao o programador encontra algo informado no relatrio de anlise de impacto no era o que pretendia obter, poder no efetuar a reorganizao, e as redefinies convenientes so criadas. Quando se decide efetuar uma reorganizao GeneXus gera programas (na linguagem escolhida quando se criou a KB) que implementam as modificaes a serem realizadas na base de dados. A execuo destes programas tem como resultado a obteno de uma nova verso da base de dados com as alteraes efetuadas. O seguinte passo ser obter os programas da aplicao associados aos objetos GeneXus. Para isso GeneXus dever especificar, gerar e compilar os programas da aplicao. Especificar um objeto significa que GeneXus analisar tudo o que foi definido em cada um dos elementos que o compem: estrutura, forms, ou outros elementos segundo corresponda. GeneXus verificar a sintaxe das definies, a validez do definido, e como resultado da especificao mostrar ao usurio uma listagem de navegao, na qual informar a lgica interpretado, e se tem alguma advertncia ou erro. Gerar um objeto, significa que GeneXus escrever linhas de cdigo que implementem a programao do mesmo, na linguagem escolhida. Compilar os programas significa que o cdigo escrito (gerado) seja convertido a linguagem de mquina (binrio) para que possam ser executados.61

Execuo

62

Opo Build da barra do menu de GeneXus

Opes do item Build: Build All e Rebuild All: Estas opes so utilizadas quando no se est seguro do impacto das alteraes e se quer ter atualizadas as ltimas definies. A opo Build All realiza todas as aes que estejam pendentes, enquanto que Rebuild All fora todas elas. As aes so: - Salvar todos os objetos que no estejam salvos. - Reorganizar a base de dados, se for necessrio. - Especificar somente os objetos que foram modificados (se selecionou Build All), ou forar a especificao de todos (selecionou Rebuild All). - Gerar os objetos - Compilar os objetos definidos Main - Compilar o Developer Menu Build / Rebuild Developer Menu: Similar as opes anteriores mas aplicadas somente ao Developer Menu. No o executa. Run Developer Menu: Executa todas as aes que estejam pendentes e executa o Developer Menu. - Salva todos os objetos que no estejam salvos. - Reorganiz-la a base de dados, se for necessrio. - Especifica somente os objetos que foram modificados. - Gera os objetos. - Compila e executa o Developer Menu.

63

Build / Rebuild / Run options: Opes aplicadas a objetos definidos como Main. Disparam as seguintes aes: - Salvam os objetos que no estejam salvos. - Reorganizao a base de dados, se for necessrio. - So especificados somente os objetos que sofrerem alteraes (se selecionou Build), ou se fora a especificao de todos os objetos pertencentes a rvore de chamadas do objeto Main (quando selecionado Rebuild). - Gerao - Compilao do objeto Main - Execuo do objeto Main (quando selecionado a opo Run) Build / Run with this only options: Build e execuo do objeto definido como Startup. Por default o objeto Startup o Developer Menu. - Salvam todos objetos que no estejam salvos. - Reorganizao a base de dados, se for necessrio. - Especificam somente o objeto selecionado. - Geram somente o objeto selecionado. - Compilam o objeto Startup - Se executa o objeto Startup (se selecionou Run). Set As Startup Object: O objeto indicado passar a ser o objeto Startup da aplicao, ou seja o objeto que finalmente se executa quando se pressione a tecla F5. Por default o objeto Startup o Developer Menu. Create Database Tables: Cria novamente as tabelas. Se perdem os dados que podero estar armazenados previamente. Impact Database Tables: Se realiza um impacto sobre as tabelas da base de dados.

64

TransaesModos em tempo de execuo Os diferentes modos podem ocorrer ao executar uma transao, dependendo da operao que se realize: Modo Insert: Indica que se est efetuando uma insero Modo Update: Indica que se est efetuando uma atualizao Modo Delete: Indica que se est efetuando uma eliminao Modo Display: Indica que se est efetuando uma consulta

Dependendo do ambiente de gerao, existem algumas diferenas referentes operacionalidade das transaes em tempo de execuo. Diante da plataforma, cada vez que se realize uma operao de insero, atualizao, eliminao, ou consulta da base de dados atravs de uma transao, existem um modo associado.

65

TransaesEm tempo de execuo

&GxRemove: Varivel do sistema para eliminar linhas.

Para agregar uma nova linha

Sempre vai mostrar um nmero de linhas vazias fixas para ser ingressadas pelo usurio (valor configurvel pelo analista a nvel do grid, em sua propriedade Rows). Por default so mostradas 5 linhas vazias. Se o usurio ingressou as 5 linhas e necessita ingressar mais, bastar pressionar New Row, ou simplesmente pressionar Enter e uma nova linha agregada. Para poder eliminar linhas em execuo, GeneXus incorpora automaticamente no grid do form Web uma primeira coluna com uma varivel do sistema de nome &GxRemove, em forma de check box. Para visualizar este check box, se deve pressionar o boto direito do mouse sobre a linha a ser eliminada. Depois deve pressionar o boto Confirm.

66

TransaesMaster PagesAs Master Pages fornecem uma forma de centralizar o layout e o comportamento comum em somente um objeto e reutiliz-lo em qualquer outro objeto sem ter que programar.

Criadas automaticamente automaticamente com a KB

Ter um look&feel consistente hoje em dia um dever de toda aplicao Web. Criar e manter cada pgina de uma aplicao Web assegurando a consistncia com o resto do site toma grande tempo de programao. Ao criar uma base de conhecimento GeneXus X cria tambm dois objetos de tipo Master Page: AppMasterPage: Para a aplicao. PromptMasterPage: Para os prompts. As Master Pages fornecem uma forma de centralizar o layout e o comportamento comum em um objeto somente e reutiliz-lo em qualquer outro objeto sem ter que programar. Isto significa que a modificao de alguma parte do layout ou do comportamento comum to fcil como modificar em um nico objeto e pronto! Em uma mesma base de conhecimento podem ser definidas quantas Master Pages como se deseje. Quando estudarmos o objeto Web Panel compreenderemos que uma Master Page ser em particular uma Web Panel categorizado como Master Page com todo o Layout e comportamento comum a todas as pginas do site, dentro deste objeto se deixa um espao para carregar em cada oportunidade a pgina que corresponda (o contedo varivel do site). Isso se faz no controle presente no form de nome Content Placeholder.

67

TransaesMaster Pages Propriedade Master Page

As pginas web que implementam o contedo varivel, se associam a Master Page, de maneira que cada vez que sejam executadas, carreguem com esse contexto (o da Master Page).

68

Demo Agregar a transao Product que no foi definida e ver como ficam os cones em Invoice

O que acontece ao fazer F5?

Observe como depois de criar a transao Product GeneXus normaliza e indica graficamente na estrutura da transao Invoice que os atributos, antes prprios da tabela INVOICEDETAIL, agora sero inferidos, atravs da nova chave estrangeira ProductId. A chave primria da tabela INVOICEDETAIL continua sendo composta: {InvoiceId, ProductId}, mas alm disso, o atributo ProductId sozinho, ser uma FK na tabela PRODUCT, a partir da qual se inferem os atributos ProductDescription e ProductPrice. Depois do F5, naturalmente ser informado a necessidade de reorganizar a base de dados, criando a tabela PRODUCT e modificando a tabela INVOICEDETAIL da maneira que indicamos nos pargrafos anteriores. O que acontece com os registros j existentes na tabela INVOICEDETAIL, para os que possuiam valores de ProductDescription e ProductPrice? Como ser visto quando executar, o programa de reorganizao agrega uma rotina para criar os registros de produtos na tabela PRODUCT com essa informao pr-existente. O que acontecer se existia o mesmo produto em vrias linhas de diferentes faturas?

69

INTEGRIDADE REFERENCIAL

70

Integridade ReferencialDiagramas

COUNTRY1

CountryId* CountryName

CUSTOMERN

CustomerId* CustomerName CountryId

O conceito de integridade referencial um conceito que se refere s bases de dados relacionais. Se refere que deve fazer a consistncia entre os dados das diferentes tabelas de uma base de dados relacional. As tabelas de uma base de dados relacional esto relacionadas por atributos que tem em comum. Estas relaes implicam que os dados das tabelas no sejam independentes, ou seja, ao inserir, modificar ou eliminar registros de uma tabela tem que ser levado em considerao os dados das outras tabelas para que sempre se conserve a consistncia da informao na base de dados. Se temos um modelo de dados relacional com as tabelas: COUNTRY (CountryId, CountryName) Chave Primria: CountryId CUSTOMER (CustomerId, CustomerName, CountryId) Chave Primria: CustomerId Chave Estrangeira: CountryId (COUNTRY) CustomerAddress, CustomerGender,

O fato do atributo CountryId est na tabela CUSTOMER ser uma chave estrangeira com respeito a tabela COUNTRY, estabelece uma relao entre ambas as tabelas. A relao entre elas pode ser representada com o diagrama mostrado. No Diagrama de Bachman, a seta simplesmente representa a existncia de uma instancia da tabela mostrada, para cada instancia da outra (para cada cliente existe um e somente um pas). A seta dupla representa a ocorrncia de vrias instncias da tabela apontada, para cada instancia de outra tabela (para cada pas, existem muitos clientes). Dizemos que a relao entre a tabela COUNTRY e a tabela CUSTOMER 1 de N (1 a muitos). Reciprocamente, a relao entre CUSTOMER e COUNTRY N de 1 (muitos a 1).71

Integridade ReferencialDiagramas COUNTRY1 NTem que verificar existncia do COUNTRY referenciado.

CUSTOMER

Na transao Customer: se inserir um novo registro, ou se modificar o CountryId de um registro

COUNTRY1 N

Na transao Country: se quer eliminar um registro

CUSTOMER

Tem que verificar se no existe nenhum CUSTOMER que o referencie.

Na terminologia GeneXus, dizemos que existe uma relao de subordinao entre ambas as tabelas. Dizemos que: COUNTRY est superordinada a CUSTOMER CUSTOMER est subordinada a COUNTRY Significando que: Quando se cria ou modifica um registro na tabela subordinada (CUSTOMER), deve existir o registro relacionado na tabela superordinada (COUNTRY). Quando se elimina um registro na tabela superordinada (COUNTRY), no devem existir registros relacionados na tabela subordinada (CUSTOMER). Devido a esta relao entre as tabelas, a informao contida nelas no independente, e necessrio realizar controles para que os dados sejam consistentes. A estes controles se chama de Integridade Referencial e basicamente so os seguintes: Quando se insere ou modifica um registro na tabela CUSTOMER, o valor ingressado no atributo que chave estrangeira (CountryId), deve existir como valor de chave primria de um registro na tabela COUNTRY. Quando se elimina um registro na tabela COUNTRY, no devem existir registros na tabela CUSTOMER cujos valores da chave estrangeira (CountryId), sejam iguais ao valor da chave primria do registro que se deseja eliminar. GeneXus gera os programas associados as transaes, incluindo no cdigo gerado estes controles de Integridade Referencial. Por esta razo, se o usurio final insere (ou modifica) um cliente atravs da transao "Customer", validado automaticamente que o valor ingressado no cdigo de pas CountryId, exista como chave primria de um registro na tabela COUNTRY. Em caso de falhar este controle de integridade referencial, uma mensagem mostrada ao usurio indicando que no se encontrou esse pas.

72

Integridade Referencialndices

Os ndices so vias de acesso eficientes as tabelas. GeneXus cria automaticamente alguns deles, e outros devero ser criados pelo programador quando este assim o determine, baseando-se em critrios de otimizao. Existem quatro tipos de ndices em GeneXus: Primrios Estrangeiros De usurio Temporrios De todos eles, os nicos que no so criados automaticamente por GeneXus so os de usurio. Enquanto aos tipos de ndices que so criados por GeneXus, a diferena que existe entre eles o momento em que so criados e o tempo durante o qual se mantm. - Os ndices primrios e estrangeiros so criados no momento de criar ou reorganizar as tabelas que compem a base de dados, e depois so mantidos automaticamente por GeneXus. - Os ndices temporrios, por sua vez, so criados ao executar as aplicaes, para acessar a tabelas ordenadas por algum atributo ou conjunto de atributos para ele/eles que no existe um ndice de usurio criado; estes se criam em tempo de execuo das aplicaes, so utilizados e depois so eliminados. NDICES PRIMRIOS E ESTRANGEIROS GeneXus cria para cada tabela um ndice por sua chave primria (ndice primrio), e um ndice por cada chave estrangeira que a tabela tenha (ndices estrangeiros). Por que criar ndices primrios e estrangeiros para as tabelas no incio de forma automtica, sendo que depois devem ser mantidos? Sejam as tabelas COUNTRY e CUSTOMER, que vimos um par de pginas atrs, criadas em nosso modelo de dados a partir das estruturas das transaes "Country" e "Customer. Existe entre estas tabelas uma relao 1-N, que ocorre pelo fato de que o atributo CountryId na tabela CUSTOMER uma chave estrangeira com respeito a tabela COUNTRY.

73

Integridade Referencialndices primrios e estrangeirosCountryId* CountryNamePK

ICountry

ICustomer CustomerId* CustomerName ... FK ICustomer1 CountryId

PK

CountryId CountryName 1 2 3 Uruguay United States China

CustomerId 4 1 3 2

CustomerName Ann Silver John Smith Mary Jones Jessica Deep

CountryId 1 1 1 2

Se na transao Country queremos eliminar United States:

O programa deve buscar sobre CUSTOMER se existe registro com CountryId = 2 para que essa busca seja eficiente: ndice estrangeiro (ICustomer1)

Por existir esta relao, o GeneXus inclui nos programas associados s transaes "Country" e "Customer", os controles de integridade referencial pertinentes. Estes controles so: Se o usurio final insere ou modifica um cliente atravs da transao "Customer", ser validado automaticamente assim que o valor ingressado na chave estrangeira CountryId exista como chave primria de um registro na tabela COUNTRY. Caso o controle de integridade referencial falhe indicado ao usurio que no foi encontrado este pas. Para controlar isto, deve-se buscar na tabela COUNTRY a existncia de um registro que tenha esse valor de CountryId como chave primria; devemos consultar a tabela COUNTRY, buscando pela chave primria, sendo que, a busca pode ser otimizada se existir um ndice pela chave primria em dita tabela. Se o usurio final tentar eliminar um pas atravs da transao "Country" validado automaticamente que no existam clientes no pas atribudo com chave estrangeira; em caso de encontrar um registro na tabela CUSTOMER, cujo valor de chave estrangeira CountryId seja o que se deseja eliminar, ser indicado ao usurio que no possvel eliminar o pas (j que do contrrio ficariam dados inconsistentes na base de dados). Para controlar isto, devemos consultar a tabela CUSTOMER, buscando pela chave estrangeira CountryId. Esta busca ser otimizada se existir um ndice por CountryId na mesma. Controle de unicidade de chave primria Outro controle que o GeneXus tambm inclui nos programas associados s transaes a unicidade da Chave Primria; isto , em nenhuma tabela podero existir dois registros com o mesmo valor na Chave Primria. Para controlar isto, quando o usurio final tentar inserir um registro, validado automaticamente que o valor ingressado para a Chave Primria, no exista como Chave Primria de outro registro na tabela. Para fazer esta busca com eficincia, devemos utilizar o ndice primrio da tabela. Concluindo, o GeneXus ao criar cada tabela da base de dados, cria tambm seu ndice primrio, e um ndice estrangeiro por cada Chave Estrangeira que a tabela contenha. A criao destes ndices permite realizar os controles de integridade referencial e de unicidade de chave primria acessando as tabelas de forma eficiente.

74

Integridade Referencialndices de Usurio O analista os cria sobre uma tabela. Deve ser categorizado conforme for aceito valores repetidos (duplicate) ou no (unique).

Se na realidade modelada, dois clientes podem ter o mesmo nome:

CustomerId 1 2 3

CustomerName Ann Ann Mary

CountryId 1 2 1

NDICES DE USURIO Estes ndices devem ser definidos explicitamente pelo analista. No so definidos automaticamente. Dividem-se em duplicate e unique: Um ndice de usurio duplicate definido para atributos de uma tabela que possam ter vrios registros com o mesmo valor nos mesmo (isto , se define para atributos que no so uma chave candidata). Este tipo de ndices se define fundamentalmente para acessar os dados ordenados por determinados atributos de forma eficiente. Por exemplo, supondo que o nome do cliente no chave na tabela de CUSTOMER (seus valores podem se repetir) poderemos definir um ndice de usurio duplicate para o atributo CustomerName, sendo muito til para realizar consultas e relatrios que necessitem que sejam ordenados por nome. Um ndice de usurio unique utilizado para especificar que um conjunto de atributos chave candidata em uma tabela (diferente da chave primria). Esta a forma de representar chaves candidatas no modelo de dados. Com isso conseguimos que o GeneXus incorpore automaticamente o controle de unicidade correspondente nas transaes associadas. Por exemplo, se o nome

GENEXUS - Heurística_Apostila Teórica

Documents

Transcript of GENEXUS - Heurística_Apostila Teórica