GeneXus Visão Geral Modificado em Agosto, 2004 Copyright ARTech, all rights reserved

Transcrição

1 GeneXus Visão Geral Modificado em Agosto, 2004 Copyright ARTech, all rights reserved SÃO PAULO BRASIL Rua Samuel Morse 120 Conj (5511) MONTEVIDEO URUGUAY Av. 18 de Julio 1645 P.4 - (5982) CHICAGO USA 400 N. Michigan Ave. Suite (1312) CIUDAD de MÉXICO MÉXICO Calle Leibnitz N 20, desp (5255)

2 Tabela de Conteúdos INTRODUÇÃO... 2 O PROBLEMA TEÓRICO... 3 METODOLOGIAS TRADICIONAIS DE DESENVOLVIMENTO E PROBLEMAS ASSOCIADOS...3 METODOLOGIA INCREMENTAL...4 UMA IMPLEMENTAÇÃO DO DESENVOLVIMENTO INCREMENTAL: GENEXUS... 5 DESENHO...5 PROTÓTIPO...8 IMPLEMENTAÇÃO...9 MANUTENÇÃO...9 Impacto das mudanças sobre a base de dados:...9 Impacto das mudanças sobre os programas: DOCUMENTAÇÃO CONSOLIDAÇÃO DE VÁRIAS APLICAÇÕES E REUTILIZAÇÃO DE CONHECIMENTO CARACTERÍSTICAS ÚNICAS DE GENEXUS QUEM SÃO OS USUÁRIOS DE GENEXUS? /13

3 Introdução GeneXus é uma ferramenta inteligente, desenvolvida pela ARTech, cujo objetivo é ajudar o analista e os usuários em todo ciclo de vida das aplicações. O desenho e o protótipo são realizados e provados em um ambiente Windows, Windows NT/2000/XP. Quando o protótipo está totalmente aprovado pelos usuários, a base de dados e os programas de aplicação são gerados ou mantidos de forma totalmente automática, para o ambiente de produção escolhido. A idéia básica de GeneXus é de automatizar tudo aquilo que é automatizável: normalização dos dados e desenho, geração e manutenção da base de dados e dos programas de aplicação. Desta maneira evita-se que o analista fique voltado às tarefas rotineiras e tediosas, permitindo-lhe dar toda sua atenção àquilo que nunca um programa poderá fazer: entender os problemas do usuário. Como subproduto, GeneXus oferece uma documentação rigorosa, auto-suficiente e permanentemente atualizada. Este documento tem como objetivo ilustrar ao leitor sobre GeneXus e os problemas que o mesmo pode resolver. Conteúdo das seções seguintes: O problema teórico neste capítulo se faz uma descrição comparativa das metodologias tradicionais de desenvolvimento de sistemas e do desenvolvimento incremental. Uma implementação do desenvolvimento incremental: GeneXus. Características únicas de GeneXus. Quem são os usuários de GeneXus. 2/13

4 O problema teórico Metodologias tradicionais de desenvolvimento e problemas associados A forma tradicional de desenvolver aplicações parte de uma premissa básica: é possível construir um modelo de dados estável da empresa. Baseado nessa premissa, a primeira tarefa que se encara é a análise de dados, onde se estuda a realidade de forma abstrata e se obtém como produto o modelo de dados da empresa. A segunda tarefa é desenhar a base de dados. É muito simples desenhar a base de dados partindo do modelo de dados já conhecido. Uma vez estudada a realidade desde o ponto de vista dos dados, faz-se o mesmo desde o ponto de vista das funções (análise funcional). Seria desejável que o estudo da realidade tivesse como produto uma especificação funcional que só dependesse da mesma. O que se faz nas metodologias mais usadas, por outro lado, é obter uma especificação funcional que se refere aos arquivos da base de dados (ou melhor, às entidades do modelo de dados, o que é essencialmente equivalente). Uma vez pronta a base de dados e a especificação funcional, passa-se à implementação das funções, existindo tradicionalmente para isso várias opções (linguagens de 3ª ou 4ª geração, geradores, interpretadores). Por outro lado, todas as formas de implementação vistam têm um problema comum: partem da premissa enunciada: é possíveis construir um modelo de dados estável da empresa, e esta premissa é falsa. Realmente não é possível fazer, de uma forma abstrata, um modelo de dados detalhado da empresa, com suficiente nível de detalhe e objetividade, porque ninguém a conhece como um todo. Por isso é necessário recorrer à várias pessoas, e cada uma delas projeta sobre o modelo, sua própria subjetividade. Uma conseqüência disto é que durante todo o ciclo de vida da aplicação se produzem mudanças no modelo. Mais ainda, considerando-se a situação ideal, onde se conhecem exatamente as necessidades, sendo então possível definir a base de dados ótima, o modelo não poderia permanecer estático, porque deve acompanhar a evolução da empresa. Tudo isto seria irrelevante, se a especificação funcional e a base de dados fossem independentes. Porém, dado que a especificação funcional se refere à base de dados, as inevitáveis modificações (manuais) nesta implicam modificações naquela. A maior conseqüência disto está constituída pelos custos muito altos de manutenção: na maioria das empresas que trabalham de uma maneira convencional se admite que 80% dos recursos que teoricamente estão destinados ao desenvolvimento, realmente sejam utilizados para a manutenção das aplicações já implementadas. Quando se trata de aplicações grandes a situação é pior ainda: esta manutenção começa muito antes da implementação, o que faz com que os custos de desenvolvimento cresçam de forma muito com respeito ao tamanho do projeto. Dado que é muito difícil, neste contexto, determinar e propagar as conseqüências das mudanças da base de dados sobre os processos, é habitual que em vez de fazer as mudanças necessárias, se opte por introduzir novos arquivos redundantes, com a conseqüente degradação da qualidade dos sistemas e o incremento dos custos de manutenção. 3/13

5 Metodologia incremental Uma maneira alternativa de resolver o problema passa pela substituição da premissa básica enunciada: assumir que não é possível construir um modelo de dados estável da empresa e, por outro lado, utilizar uma filosofia incremental. Um esquema incremental parece muito natural: não se encaram grandes problemas, senão que vamos resolvendo os pequenos problemas à medida que vão se apresentando. Qual vai ser a repercussão deste tipo de esquema sobre os custos de manutenção? Se fossem utilizadas, com este enfoque, as metodologias anteriormente resenhadas, essa repercussão seria muito grande: o modelo de dados se modificaria constantemente e os custos de manutenção seriam ainda muito maiores que os enunciados. Por outro lado, pode-se ver o seguinte: Não se conhece a base de dados, mas, cada usuário, conhece muitas bem as visões dos dados que ele utiliza no cotidiano. Essas visões dos dados podem ser de vários tipos: telas, listas, etc. Que compõem o aspecto exterior da aplicação: aquilo que é tangível para o usuário. Como o conhecimento destas visões pode ajudar a obter o modelo de dados? O assunto pode se transformar em um problema matemático? Se isso fosse possível, a matemática poderia oferecer uma ampla gama de recursos para ajudar a resolver automaticamente e, como conseqüência, se simplificaria muito a tarefa do analista. Uma reflexão interessante é a seguinte: a base de dados, as visões dos dados que têm os diferentes usuários deveriam poder derivar-se dela. Ou dito de outra maneira, a base de dados deve satisfazer a todas as visões conhecidas. Pode se demonstrar que, dado um conjunto de visões de dados de usuários, existe sempre uma base de dados mínima que as satisfaz, a qual, além disso é única. Neste estado, o problema se transforma em um problema matemático e então é preciso resolvê-lo para encontrar essa base de dados. Mas, como se implementa esta teoria? Trata-se de capturar o conhecimento que existe nas visões dos usuários, e sistematizálo em uma base de conhecimento. A característica fundamental desta base de conhecimento, que a diferencia dos tradicionais dicionários de dados, é sua capacidade de inferência: pretende-se que, em qualquer momento, se possam obter desta base de conhecimento, tanto elementos que foram colocados nela, como qualquer outro que se possa inferir a partir deles. Se este objetivo é atingido, a base de dados e os programas de aplicação passam a ser transformações determinadoras da base de conhecimento e isso permite: Gerá-los automaticamente. Frente a mudanças nas visões dos usuários: Determinar o impacto das mudanças sobre dados e processos Propagar essas mudanças gerando: o o programas necessários para converter os dados; programas da aplicação afetados pelas mudanças. 4/13

6 Uma implementação do desenvolvimento incremental: GeneXus GeneXus implementa esta teoria. Quando uma aplicação é desenvolvida com GeneXus a primeira etapa consiste em fazer o desenho da mesma registrando as visões de usuários (a partir das quais o sistema captura e sistematiza o conhecimento). Posteriormente se passa à etapa de prototipação, onde GeneXus gera a base de dados (estrutura e dados) e programas para o ambiente de protótipo. Uma vez gerado o Protótipo deve ser testado pelo analista e pelos usuários. Se durante os testes do protótipo se detectam melhorias ou erros, retorna-se à fase de desenho, realizam-se as modificações necessárias e, volta-se ao protótipo. Chamaremos este ciclo de Desenho / Protótipo. Uma vez que o protótipo está aprovado, passa-se à etapa de Implementação, onde GeneXus gera, também automaticamente, a base de dados e programas para o ambiente de produção. Resumindo, uma aplicação começa com um desenho, depois se prototipa, depois se implementa. Em qualquer um dos passos anteriores é possível voltar ao desenho para realizar modificações. Ciclos Desenho-Protótipo e Desenho-Produção Desenho Protótipo Produção A seguir serão detalhadas cada uma destas tarefas: Desenho Esta tarefa é realizada conjuntamente pelo analista e pelo usuário e consiste em identificar e descrever as visões de dados dos usuários. O trabalho é feito no ambiente do usuário. Este esquema permite trabalhar com um baixo nível de abstração, utilizando termos e conceitos que são bem conhecidos pelo usuário final. Uma conseqüência muito importante, é que a atitude do usuário se torna francamente participativa. O sistema passa a ser uma obra conjunta, e como o usuário acompanha permanentemente a evolução, a qualidade é muito maior que a habitual. 5/13

7 Conforme o que foi visto, GeneXus captura o conhecimento por meio de visões de objetos da realidade do usuário. Os tipos de objetos suportados por GeneXus são: Transações, Relatórios, Procedimentos, Work Panels, Web Panels, Temas, Menus, Data Views e Transações de Data Warehouse. A tarefa de desenho consiste, fundamentalmente, em identificar e descrever estes objetos. A partir destas descrições, e automaticamente, GeneXus sistematiza o conhecimento capturado e vai construindo, de forma incremental, a Base de Conhecimento. Esta Base de Conhecimento é um depósito único de toda informação do desenho, a partir da qual GeneXus cria o modelo de dados físico (tabelas, atributos, índices, redundâncias, regras de integridade referencial, etc.) e os programas de aplicação. Assim, a tarefa fundamental na análise e desenho da aplicação encontra-se na descrição dos objetos GeneXus. Vejamos detalhadamente os tipos de objetos GeneXus mais importantes: Transações Uma transação é um processo interativo que permite aos usuários criar, modificar ou eliminar informação da base de dados. Exemplos: Tela para criar, modificar ou eliminar os Clientes da Empresa. Tela de faturamento: processo que permite a um usuário criar faturas e inclusive imprimi-las. Uma tela permite ao usuário fazer várias ações como inserir, atualizar, eliminar, imprimir sem ter que voltar ao menu. Relatórios Um relatório é um processo que permite visualizar os dados da base de dados. Os dados podem ser enviados à tela ou à impressora. Com este objeto pode-se definir desde listas simples (por exemplo, listar os clientes) até listas muito sofisticadas, onde existam vários cortes de controle, múltiplas leituras à base de dados e parametrizações. Um relatório, porém, não pode atualizar a base de dados. Procedimentos Este objeto possui todas as características dos relatórios, permitindo, além disso, atualizar a base de dados. Os Procedimentos são muito usados para dois tipos de processos: Processo batch de atualização. Por exemplo: eliminar todas as faturas da data anterior a uma data específica e que já foram pagas. Subrotinas de uso geral. Por exemplo: rotina de extenso onde, dado um valor se devolve um literal com o valor por extenso (1010 => Mil e dez ). Processos a executar em um servidor de aplicações ou servidor de base de dados: processos (geralmente escritos em C/SQL, Java ou.net) para uma Multi Tier Architecture, para serem executados em um servidor de aplicações ou de bases de dados. Work Panels Um Work Panel é uma tela que permite ao usuário realizar consultas interativas à base 6/13

8 de dados. Quanto mais os usuários utilizam o computador para trabalhar, mais se torna necessária a utilização de diálogos sofisticados, que lhe permitam sentar-se para pensar frente ao mesmo. Os work panels permitem desenhar este tipo de diálogos do usuário. Por exemplo: um work panel que mostra a lista de clientes e que permite (à escolha do usuário) ver quais são suas faturas ou suas dívidas. Web Panels São similares ao conjunto de Work Panels, mas são usados em browsers em ambiente Internet/Intranet/Extranet. Temas Os temas são criados com o Editor de Temas. O Editor de Temas é uma ferramenta gráfica que define todos os elementos visuais de uma aplicação, como fontes, tabelas, botões, etc. Logo em seguida, o tema se associa aos objetos GeneXus. Os valores dos Temas podem ser mudados no momento da execução, o que permite que as aplicações Web sejam mais dinâmicas e à medida do usuário. Menus Um menu é uma tela que contêm uma série de opções fixas que o usuário seleciona para executar. Data Views Permitem considerar correspondências entre tabelas de bases de dados pré-existentes e tabelas GeneXus. e tratá-las com a mesma inteligência, como se fossem objetos GeneXus. GeneXus trabalha com o conhecimento puro Partindo dos objetos descritos, o modelo de dados físico é desenhado com base na Teoria de Bases de Dados Relacionais e garante uma base de dados em terceira forma norma (sem redundância). Esta normalização é efetuada automaticamente por GeneXus. O analista pode, por outro lado, definir redundâncias que, a partir disso, passam a ser administradas (controladas ou propagadas, segundo corresponda), automaticamente por GeneXus. O depósito de GeneXus mantém as especificações de desenho em forma abstrata, ou seja, não depende do ambiente objeto, o que permite que, a partir do mesmo depósito, possam ser geradas aplicações funcionalmente equivalentes, para serem executadas em diferentes plataformas. Múltiplas Plataformas / Arquitetura de Múltiplas Camadas Como conseqüência do que foi dito anteriormente, é possível por exemplo, que um usuário de uma aplicação IBM AS/400 centralizada desenvolvida 100% com GeneXus, possa fazê-la funcionar total ou parcialmente em um ambiente JAVA ou.net sem ter que modificar os objetos originais. Por outro lado, as especificações funcionais são totalmente independentes da base de dados, pelo que se mantêm válidas mesmo depois de mudanças nesta. Esta propriedade permite que GeneXus possa manter automaticamente todos os programas que gera. 7/13

9 Hoje é comum que uma mesma aplicação tenha algumas partes sendo executadas em uma plataforma e algumas em outras, e que todas possam se comunicar corretamente. O desenvolvimento com GeneXus permite que uma aplicação possa ser dividida de maneira que possa ser executada em diferentes plataformas e para cada uma delas gerada a linguagem mais adequada, obtendo assim arquiteturas de múltiplas camadas (multi-tier) fazendo um melhor uso dos recursos disponíveis. Protótipo Nas tarefas de desenho estão implícitas as dificuldades de toda comunicação humana: O usuário se esquece de certos detalhes; O analista não toma nota de alguns elementos; O usuário se engana em algumas apreciações; O analista interpreta mal algumas explicações do usuário. Mas, além disso, a implementação de sistemas é, habitualmente, uma tarefa que leva bastante tempo, pelo que: Como muitos destes problemas só são detectados nos testes finais do sistema, o custo (tempo e dinheiro) para solucioná-los é muito grande; A realidade muda, por isso, não é razoável pensar que se podem congelar as especificações enquanto se implementa o sistema; A conseqüência do congelamento das especificações é que se acaba implementando uma solução relativamente insatisfatória. O impacto destes problemas diminuiria muito se conseguisse testar cada especificação imediatamente e pudéssemos saber qual é a repercussão de cada mudança sobre o resto do sistema. Uma primeira aproximação a isto, oferecida por diversos sistemas, é a possibilidade de mostrar ao usuário formatos de telas, relatórios, etc. Animados por menus. Isto permite ajudar o usuário a ter uma idéia de que sistema será construído mas, posteriormente, sempre se aparecem surpresas. Uma situação bastante diferente seria colocar a disposição do usuário para sua execução, imediata, uma aplicação funcionalmente equivalente a desejada, até nos mínimos detalhes. Isto é o que faz GeneXus: um protótipo GeneXus é uma aplicação pronta, funcionalmente equivalente à aplicação de produção. A diferença entre prototipação e produção consiste em que a primeira é feita em um ambiente de microcomputador, enquanto que a produção é realizada em ambiente objeto do usuário (IBM iseries, Cliente / Servidor, JAVA,.NET). O protótipo permite que a aplicação seja totalmente testada antes de passar à produção. Durante estes testes, o usuário final pode trabalhar com dados reais, ou seja, que testa de uma forma natural, não somente formatos de telas, relatórios, etc. mas também fórmulas, regras do negócio, estruturas de dados, etc. A filosofia de GeneXus é de desenvolvimento incremental. Quando se trabalha em um ambiente tradicional as mudanças no projeto, feitas durante a implementação e, sobretudo, aquelas que são necessárias logo depois que o sistema está implantado, são muito caras. GeneXus resolve este problema: constrói a aplicação com uma metodologia de aproximações sucessivas que permite, uma vez detectada a necessidade de mudanças, prototipá-las e testá-las imediatamente por parte do usuário, sem custo adicional. 8/13

10 Implementação GeneXus gera automaticamente o código necessário para: Criar e manter a base de dados; Gerar e manter os programas para manipular os objetos descritos pelo usuário. Os ambientes e linguagens atualmente suportados são: Plataformas Plataformas de Execução JAVA, Microsoft.NET, Pocket PC Sistemas Operacionais Servidores IBM OS/400, LINUX, UNIX, Windows NT/2000/2003 Servers, Windows NT/2000/XP/CE Internet JAVA, ASP.NET, Visual Basic (ASP), C/SQL, HTML Banco de Dados IBM DB2 UDB, Informix, Microsoft SQL Server, Oracle, PostgreSQL, MySQL Linguagens JAVA, C#, C/SQL, COBOL, RPG, Visual Basic, Visual FoxPro Servidores Web Microsoft IIS, Apache, WebSphere, etc. Múltiplas Arquiteturas Arquiteturas de múltiplas camadas, baseadas na Web, cliente/servidor e centralizadas (iseries) Ferramentas de Business Intelligence e Workflow Soluções de Reporting, Data Warehousing e Workflow para todos os servidores suportados. Manutenção Esta é talvez a característica mais importante de GeneXus, e a que o diferencia de maneira mais clara de seus concorrentes: a manutenção, tanto da base de dados (estrutura e conteúdo) como dos programas, é totalmente automática. A seguir se explica o processo de manutenção, diante de mudanças na descrição de algum objeto GeneXus (visão do usuário): Impacto das mudanças sobre a base de dados: Análise de impacto: Uma vez descritas as mudanças das visões de usuários, GeneXus analisa automaticamente qual é o impacto dos mesmos sobre a base de dados e produz um relatório onde explica como deve ser feita a conversão dos dados e, se for o caso, que problemas potenciais tem essa conversão (inconsistências por dados velhos perante novas regras, etc.). O analista decide se aceita o impacto e continua ou não. 9/13

11 Geração de programas de conversão: Uma vez que os problemas são solucionados, ou melhor, se aceita a conversão default, que GeneXus realiza de forma padronizada, geram-se automaticamente os programas para fazer a conversão (estrutura e conteúdo) da base de dados antiga para a nova. Execução dos programas de conversão: Logo em seguida se passa ao ambiente de execução que corresponda (protótipo, produção Internet, produção Cliente / Servidor, etc.) e se executam os programas de conversão. Impacto das mudanças sobre os programas: Análise de impacto: Em seguida, GeneXus analisa o impacto das mudanças sobre os programas e produz um diagnóstico informando que programas devem ser gerados ou re-gerados e proporciona também para o programa novo ou, um diagrama de navegação ou, um pseudo-código, à escolha do analista. Geração de novos programas: Em seguida o sistema gera ou re-gera automaticamente todos os programas. Documentação Todo o conhecimento previsto pelo analista, ou inferido por GeneXus, está disponível em um depósito ativo, que constitui uma completa documentação on-line, permanentemente atualizada. Consolidação de várias aplicações e reutilização de conhecimento. Várias aplicações podem ser desenhadas e prototipadas simultaneamente, por diferentes equipes, utilizando GeneXus. Estas equipes podem intercambiar especificações de desenho utilizando o módulo KNOWLEDGE MANAGER. Isto permite uma flexibilidade ideal: o analista trabalha com inteira liberdade em um ambiente de protótipo, com uma pequena base de conhecimento e, só quando sua aplicação está pronta, desde o ponto de vista do usuário, deve tomar em conta a base de conhecimento coorporativa, que geralmente é muito grande. Nesse momento, com poderosas ajudas automáticas, se estabelece o impacto que terá a nova aplicação ou a modificação da pré-existente, sobre o modelo corporativo e, se é o caso, se faz as mudanças para garantir a consistência, de uma maneira muito simples. Com este esquema é possível reutilizar, por exemplo, Bases de Conhecimento licenciadas de terceiros. 10/13

12 Características únicas de GeneXus GeneXus tem algumas características únicas que o distinguem de seus concorrentes. Entre elas podemos destacar: Interativo: o ponto de partida é a descrição natural dos objetos pelo usuário. A descrição de cada objeto é totalmente independente da descrição dos outros, de modo que no caso de que seja necessário modificar a descrição de algum, isto não implicará na necessidade de modificação manual da descrição de qualquer outro. A curva de aprendizagem é curta. O desenho, a criação e a manutenção da base de dados são totalmente automáticos. A aplicação (base de dados e programas) tem sempre, sejam quais forem as modificações que tenham sofrido, a melhor qualidade: A base de dados é sempre ótima, Não se modificam programas: quando já não são adequados, geram-se outros novos, ótimos e não remendados, que os substituem. Linguagens poderosas e de altíssimo nível para a definição de PROCESSOS, WORK PANELS e WEB OBJECTS, assim como uma definição de MENUS muito simples. Nestas linguagens as descrições dos processos são feitas sem referir-se aos arquivos envolvidos, que são inferidos automaticamente em tempo de geração. Esta característica permite uma total independência entre os dados e ditas especificações. Como conseqüência, as especificações de alto nível de GeneXus não precisam modificações da base de dados. Utilização dos arquivos ou bases de dados pré-existentes como próprios de GeneXus. Manutenção 100% automática: O conjunto destes elementos permite a GeneXus gerar e manter automaticamente 100% dos programas nas aplicações normais de tipo comercial, administrativo, financeiro ou industrial Fácil distribuição do conhecimento corporativo para facilitar o desenvolvimento de novas aplicações. Simples e poderosa solução para Data Warehousing. Verificação automática de consistência e consolidação entre aplicações desenvolvidas separadamente. Independência de plataforma e de arquitetura. Simplicidade: GeneXus utiliza os recursos mais avançados da inteligência artificial para que o analista e os usuários, possam usá-lo de uma forma muito simples. 11/13

13 Quem são os usuários de GENEXUS? Mais de clientes no mundo utilizam GeneXus e os produtos GeneXus para criar e integrar aplicações de missão crítica que facilmente se adaptam às implacáveis mudanças do negócio. A tecnologia GeneXus permite aos nossos clientes usar seu know-how exclusivo nas plataformas tecnológicas líderes do mercado. Nossos clientes corporativos vão desde empresas médias a muito grandes, numa grande variedade de indústrias. Hoje representam 70% do nosso faturamento. Nossos clientes do tipo casas de software (ISV o Independente Software Vendors) compreendem pequenas, médias e grandes empresas de software que constroem suas soluções utilizando a tecnologia GeneXus. Este segmento representa atualmente 30% do nosso faturamento, mas está crescendo rapidamente. GeneXus and ARTech are trademarks or registered trademarks of ARTech Consultores S.R.L. ARTech recognizes that all other trademarks contained herein are property of their respective holders 12/13