Informações Gerais

Manual do Maker 2

previous page next page

Informações Gerais

Definição

O Webrun é um interpretador de sistemas gerados pelo Maker.

Características

1. Multicamadas

Os sistemas criados com o Maker funcionam em multicamadas. Em uma arquitetura de multicamadas, notamos claramente a separação da interface do usuário, do modelo de negócios e do acesso a dados.

A arquitetura multicamadas (Servidor, Banco de Dados e Aplicações) permite que cada parte do sistema seja executada em uma máquina diferente, otimizando os recursos da rede e oferecendo integração total entre as funcionalidades do sistema. Dessa forma, o balanceamento da carga da rede pode ser feito no nível mais otimizado possível, maximizando o desempenho.

O desenvolvimento de aplicações multicamadas é um recurso muito utilizado atualmente e permite que as aplicações se tornem menos dependentes da arquitetura geral de um sistema e possibilita uma manutenção mais rápida e menos complicada.

A arquitetura de sistemas multicamadas permite que a camada de apresentação do software seja independente da camada de controle de regras de negócios e que essa seja independente da camada de armazenamento dos dados. Dessa forma, é possível construir um software inteiro sem se preocupar se o armazenamento de dados será em arquivos simples, XML ou bancos de dados relacionais.

Além disso, softwares construídos dessa forma tornam-se mais manuteníveis, pois impedem que uma mudança em uma parte do software seja propagada para todo ele.

2. AJAX

O AJAX é uma metodologia moderna de atualização assíncrona de informações entre cliente e servidor, pois permite que os dados sejam trafegados sem que haja atualizações totais das páginas.

As aplicações desenvolvidas com o Maker utilizam-se da metodologia AJAX automaticamente para aumento da experiência do usuário e da performance do sistema, efetuando apenas requisições de atualização das informações que são necessárias no contexto.

3. Não utiliza Applets

Applets são pequenos programas feitos em Java, aplicativos que se servem da JVM (Java Virtual Machine) existente na máquina cliente ou embutida no próprio navegador do cliente para interpretar o seu bytecode, transferindo-se com as páginas web e os navegadores o executam. São independentes de browsers e de sistemas operacionais. Porém, Applets requerem uma gama de recursos instalados na máquina dos usuários, e geralmente tem a capacidade de interagir com e/ou influenciar seu programa hospedeiro, utilizando privilégios de segurança restritos, apesar de normalmente não serem requeridos a fazê-lo, além de serem mais lentos e inseguros.

JavaScript é uma linguagem de programação criada para atender, principalmente, à validação de formulários no lado cliente (programa navegador) e gerar interação com a página. Com ele é possível modificar dinamicamente os estilos dos elementos da página em HTML.

Em relação ao Javascript, os applets são mais lentos de processar, além de possuir espaço muito delimitado na página onde são executados, ou seja, não se misturam com todos os componentes da página, nem têm acesso a eles. É por isso que, com os applets de Java, não é possível realizar ações, como abrir janelas secundárias, controlar Frames, formulários, camadas, etc.

Com o Maker, todos os recursos são feitos sem a utilização de Applets. Os sistemas são baseados principalmente no AJAX, o que garante velocidade e segurança, além de não ser necessária a instalação da JVM na máquina do cliente.

4. Múltiplos Bancos

Um SGBD deve garantir a consistência e segurança dos dados, proporcionando ao seu usuário uma visão abstrata dessas informações ao omitir detalhes sobre as estruturas e técnicas utilizadas nos seus processos. Para isso, são usados modelos de dados: ferramentas conceituais usadas para descrição, semântica e relacionamento entre os dados e regras de consistência.

No entanto, a dependência de ferramentas de persistência pode ser um problema. Uma determinada empresa pode fazer uso de um SGBD e, por exigência de um de seus clientes, pode ser solicitado um banco de dados diferente do já utilizado. Com isso o custo para alterar e tornar seu sistema compatível com esse banco pode gerar trabalho a mais para a equipe de desenvolvimento. A depender do banco, a existência ou não de generators, triggers de after, before e outros tratamentos pode fazer com que consultas sejam reformuladas para atender a determinadas solicitações.

A independência dessas ferramentas vem se tornando cada vez mais necessária. O uso de tecnologias que não dependem de um banco de dados em específico, possibilita um desenvolvimento rápido, barato e com alta performance.

Alguns frameworks vêm tornando possível essa independência de SGBD. O Hibernate é um desses exemplos. O sistema que faz uso desse framework abstrai o tipo de ferramenta para persistência de dados. Com isso, pode-se vincular uma aplicação desenvolvida em Java a um banco de dados FireBird, SQLServer, Oracle e outros. Entretanto, no desenvolvimento de um sistema fazendo uso do Hibernate, existe uma configuração particular, envolvendo um arquivo XML e algumas bibliotecas que são extremamente necessárias para essa independência. Com isso, torna-se imprescindível um tempo de estudo para sua utilização.

O Maker proporciona uma independência arquitetural em relação ao mecanismo de persistência, sem necessitar de configurações adicionais para obter essa característica. Nenhuma adição de bibliotecas, nenhum treinamento extra para desenvolver sistemas independentes de banco, de plataforma, etc. Para melhorar ainda mais, todo sistema gerado pelo Maker já possui todas essas características, sem que seja implementado nenhum módulo. Tudo isso já é nativo.

5. Multiplataforma

Na tentativa de reduzir custos e obter independência dos fornecedores de plataformas de hardware e software, as aplicações Web vêm se tornando cada vez mais atraentes aos usuários, que se tornaram cada vez mais exigentes, tendo em vista manter ou conquistar a liberdade de escolher qual sistema operacional (Windows, Linux, Mac), e/ou hardware (IA32, x86, RISC, ...)  executará sua aplicação, podendo optar por mais segurança, mais facilidade ou simplesmente isenção de licença de aplicativos ou sistemas operacionais. Seguindo essa tendência, o Maker consiste em uma IDE de desenvolvimento de sistemas Multiplataforma, altamente flexível, com portabilidade completa (tanto do cliente, quanto do servidor).

A portabilidade de um programa de computador é a sua capacidade de ser compilado e/ou executado em diferentes arquiteturas, seja de hardware, seja software. O termo pode ser usado também para se referir à possibilidade de executar um software sem a reescrita de um código-fonte para uma outra plataforma de hardware ou software. Java, Perl, PHP, .NET(C#, J#) por exemplo, são linguagens de programação portáveis que permitem compilar a aplicação uma vez apenas para que ela possa ser executada em qualquer plataforma que possua a respectiva máquina virtual. Não existe necessidade de produzir uma versão compilada para cada sistema computacional em que se deseje executar a aplicação.

As aplicações Web também obtêm essa portabilidade. Elas estão em uma camada superior, usando um protocolo padrão para transferência de dados (http, https, ...), sendo executada por qualquer browser popular (IE, Firefox....).

No caso do Maker, essa portabilidade oferecida é devido ao fato de se conseguir reunir as ferramentas necessárias para desenvolver um software que seja acessível nos principais navegadores. Sendo assim, não dependem de plataforma.

Essa portabilidade irá permitir que as plataformas de hardware e software sejam substituídas sem nenhuma mudança visível ao usuário. Quando usado de forma cliente-servidor, o Maker conserva a característica de multiplataforma, já que os servidores utilizam o software Servlet Container que é disponível para diferentes arquiteturas, e é utilizada uma linguagem-padrão Java.

6. Escalabilidade

O crescimento constante da demanda de usuários vem causando quedas de desempenho, com baixos tempos de resposta, congestionamento da rede e interrupção de serviços (DoS).

Uma abordagem para solucionar isso é tornar o servidor de aplicação mais poderoso com o uso de uma arquitetura em cluster, na qual múltiplas máquinas funcionam como um único servidor.

Um cluster é definido como um grupo de servidores executando a mesma aplicação web simultaneamente, aparecendo para o mundo como se fosse um único servidor, ou ainda: "Um sistema paralelo ou distribuído que consiste na coleção de computadores interconectados que são utilizados como um só, unificando seus recursos computacionais" (G. Pfister, um dos arquitetos da tecnologia de clusters).

Isso possibilita a distribuição do trabalho nos servidores, o que é chamado de balanceamento de carga.

O Maker possui um ambiente de execução que suporta clustering sem modificações nos sistemas, assim que é implantado

7. Ambiente Web

Atualmente, utilizar aplicações Web é uma tendência mundial que vem crescendo fortemente. As aplicações Web vêm cada vez mais substituindo as aplicações desktop, fato que foi potencializado bastante graças à Web 2.0 e ao crescimento e evolução das tecnologias de desenvolvimento web.

Tal crescimento pode ser explicado pelo fato de aplicações Web possuírem recursos que muitas vezes as tornam uma melhor alternativa em comparação com as aplicações desktop. Alguns destes recursos são: maior acessibilidade da aplicação (de qualquer lugar do mundo, a qualquer hora, em qualquer plataforma), acesso concorrente, dispensa instalação no cliente, etc.

As aplicações desenvolvidas com o Maker já estão totalmente integradas no ambiente web, oferecendo todas as características de tal plataforma sem necessidade de nenhum conhecimento das tecnologias web pelo usuário. Também não há perda de tempo preocupando-se com compatibilidade cross-browser.

8. Segurança

Os sistemas criados pelo Maker já têm implícitos, em suas construções, componentes que garantem a sua segurança. As características que tornam os sistemas criados pelo Maker seguros são:

  • Criptografia - utilizamos criptografia forte para persistência de dados cruciais do ambiente, criptografia de senha (one-way hash): DES, MD5 e Blowfish.

  • HTTPS (HyperText Transfer Protocol Secure) - é uma implementação do protocolo HTTP sobre uma camada SSL ou do TLS, essa camada adicional permite que os dados sejam transmitidos por uma conexão criptografada e que se verifique a autenticidade do servidor e do cliente por meio de certificados digitais.

  • Auditoria em log - o sistema armazena informações detalhadas em um ambiente seguro de todas as ações de um usuário nos sistemas gerados.

  • Permissões de acesso - o ambiente permite definições de políticas de acesso detalhadas em todos os elementos do sistema (formulários, componentes, relatórios, entre outros).

  • Java Authentication e Authorization Service (JAAS), Java Cryptography Extension (JCE) e Java Secure Socket Extension (JSSE)

9. Interoperabilidade

Interoperabilidade é a capacidade de um sistema de se comunicar com outros sistemas (semelhantes ou não). Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos.

O Maker possibilita a interoperabilidade ao permitir que outros sistemas possam acessar seus recursos e também fornece métodos de alto nível para que um sistema gerado por ele possa acessar outros sistemas. Para isso, o Maker utiliza a tecnologia de Web Service, que é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.

Arquitetura

1. Camada de Dados

É a camada de persistência do Webrun. Ela dá suporte a qualquer banco de dados relacional que implemente JDBC. Atualmente, homologamos os seguintes bancos de dados:

  • Oracle

  • SQL Server

  • Firebird / Interbase

  • PostgreSQL

  • MySQL

Essa camada não utiliza tecnologias de terceiros (ex: Hibernate, EJB, entre outros). A razão disso está no pré-requisito ”r;não deve haver dependência de robustos servidores de aplicações”.

Essa camada trabalha sem estado com o SGDB, o que permite distribuição através de clusters. O controle transacional é explicado como segue.

1.1 Transações

Uma transação é uma unidade indivisível a ser executada, ou seja, é realizada ou descartada por completo - princípio da atomicidade. Além disso, deve ser consistente, isolada e durável - ACID. Ela pode finalizar de duas formas: por confirmação de todas as operações que engloba (commit), isto é, as alterações no banco de dados são permanentes, ou pelo cancelamento das operações (rollback).

O Maker, assim como o EJB, proporciona suporte automático para transações distribuídas em aplicações. Essas transações podem alterar dados atomicamente em múltiplas bases de dados.

Cada formulário do Maker, que acessa um conjunto de dados, controla uma transação ”mestre”, e para cada dependência, que também acesse um conjunto de dados, é aberta uma transação aninhada. Como dependências, podemos citar subformulários, regras de negócio, grids, formulários linkados entre outros. Seguindo o princípio da atomicidade, as alterações em dados só são confirmadas se todas as transações forem concluídas com êxito. Com isso, podemos até alterar mais de uma fonte de dados que o Maker permitirá/garantirá a atomicidade.

O Maker também armazena dados em memória para serem postados posteriormente. Esse comportamento ocorre para situações de Mestre-Detalhe, em que, teoricamente, os dados de um detalhe só podem ser incluídos após o mestre existir. Porém, o Maker permite a inclusão de dados no detalhe e esses dados só são confirmados quando o mestre for incluído.

Por padrão, as transações do Maker são do tipo READ_COMMITED, o que significa que o processo B vai enxergar os dados do processo A, quando ele fizer um commit.

2. Camada Servidor

Compatível com containers J2EE JSP e Servlet e servidores de aplicação J2EE. Servidores homologados:

  • Tomcat

  • JBoss+Tomcat

2.1 Componentes da Camada Servidor

2.1.1 Servidor de Aplicações Web

Controla todas as requisições de clientes. Identifica a ação correspondente, valida autorizações e as encaminha para o Gerenciador de Interface HTML.

Padrões de projeto utilizados: MVC, Abstract Factory, Adapter.

2.1.2 Gerador de Interface HTML

Responsável por apresentar em HTML os diversos componentes do sistema. Cada componente do sistema tem um ”Apresentador” correspondente que deve ter o método ”design” implementado. Na ação ”Desenhe”, por exemplo, o Gerador de Interface HTML itera os componentes da requisição e chama o método ”design” de cada um deles.

Padrões de projeto utilizados: Abstract Factory, Composite e Singleton.

2.1.3 Gerenciador de Lógicas de Negócio

Responsável por executar regras de negócio da aplicação. Caso a regra de negócio ainda não tenha sido executada uma vez, o gerenciador irá compilar a classe correspondente e depois executá-la.

Padrões de projeto utilizados: Factory Method, Prototype e Singleton.

2.1.4 Gerenciador de Sistemas

Responsável por manter as definições de um ou mais sistemas. Um sistema é composto por componentes que podem ser: formulários, controles visuais, regras e relatórios.

Padrões de projeto utilizados: Bridge, Proxy, Abstract Factory e Mediator

2.1.5 Gerenciador de Banco de Dados

Responsável por toda a comunicação com as diversas fontes de dados de um sistema. Encapsula funcionalidades de consulta, atualização e remoção de dados e garante o seu controle transacional, quando isso não é assegurado pelo SGDB.

3. Camada Cliente

Responsável por apresentar os dados e por interagir com o usuário. Suporte a diversos navegadores:

  • Internet Explorer

  • Mozilla (Firefox)

Tecnologia

  • JAVA (JDK 1.5,generics e autobox) (J2EE 1.4, JSP, Servlets e JSTL)

  • Apache Tomcat 5.5.x, 6.x ou JBoss 4.x

  • Interface JDBC (Type 4) para acesso a dados

  • Troca de dados em XML

  • WebServices

  • Javascript 1.5

  • Gerador de relatórios: PDF, JPG, RTF, HTML e XLS

  • Suporte à biometria (Nitgen)

  • AJAX (metodologia)

Dúvidas Frequentes

1 - O Maker trabalha com as diferentes fases de desenvolvimento de um software?

Na fase de análise, o Maker ajuda na prototipação e no desenho das regras de negócio associadas a cada caso de uso. Os artefatos da prototipação (interfaces e regras) são utilizados no produto final a ser desenvolvido.

2 - Em relação à usabilidade, o Maker disponibiliza componentes e formulários em uma interface amigável e de fácil utilização ou requer um estudo mais aprofundado para seu uso?

Os formulários e o conjunto de componentes disponibilizados pelo Maker foram estressados em relação à sua usabilidade. Cerca de 10 mil usuários finais dos sistemas gerados com a ferramenta ajudaram a atingir o nível de usabilidade atual. Todavia, a ferramenta provê mecanismos de interceptação do comportamento-padrão de seus componentes, através de eventos, para que eles possam se comportar da forma que o desenvolvedor desejar. Para comportamentos e aparências inerentes ao run-time, nós disponibilizamos mecanismos de personalização dos mesmos através de assistentes de configuração. É importante salientar que qualquer comportamento que a ferramenta não disponibilize poderá ser implementado visualmente através do fluxograma, que é a metodologia adotada pelo Maker para desenho de regras de interface e de negócio.

Portanto, a aplicação de padrões de usabilidade que não forem disponibilizados pela ferramenta é possível ser implementados pelo desenvolvedor.

3 - Em quais linguagens as aplicações do Maker são geradas?

Aplicações completas são geradas em JAVA/JavaScript e SQL dos bancos Oracle, SQL Server, Postgre  e Firebird. Atualmente, estamos implementando .NET, ou seja, futuramente as aplicações desenvolvidas dentro da filosofia Maker poderão ser portadas para .NET sem nenhuma implementação.

Na versão atual, rotinas isoladas podem ser geradas diretamente do fluxo para as linguagens C.

Disponibilizamos um mecanismo para cadastramento de novas linguagens, construído com o próprio Maker, e fornecemos também um manual técnico.

4 - O que o Maker utiliza e implementa para conseguir manter um alto grau de segurança?

  • Https SSL (Secure Sockets Layer)

  • Criptografia de senha (one-way hash): DES, MD5 e Blowfish

  • Java Authentication e Authorization Service (JAAS), Java Cryptography Extension (JCE) e Java Secure Socket Extension (JSSE).

  • Suporte a leitores biométricos (Nitgen e Secugen)

5 - Existe a possibilidade de o sistema se integrar com os mecanismos padrões de autenticação utilizados no mercado?

A possibilidade está na interceptação dos eventos de sistema ”Ao Autenticar” e ”Ao Autorizar”. A partir daí, o desenvolvedor está livre para interoperar com qualquer outro sistema de autenticação e autorização e devolver respostas coerentes ao nosso sistema.

É possível integrar com o SIGAI se ele for interoperável.

Atualmente, não homologamos MySQL, porém isso é questão de tempo, visto que, em teoria, qualquer banco que tenha implementação JDBC é suportado.

6 - Os códigos gerados podem ser operados e executados com total independência? Em quais condições? A retirada do Webrun será manual ou automática?

O processo de geração do código consiste em gerar os fontes do sistema solicitado e mesclá-los com fontes que também são utilizadas pelo webrun, pois existe um framework comum entre os dois. Depois de gerado, ele poderá ser compilado em qualquer IDE de desenvolvimento JAVA. A retirada é manual.

7 - Como se comporta a ferramenta (Maker) para os sistemas operacionais, Linux e Windows? Atende aos dois? Quanto às aplicações geradas pela ferramenta são independentes de plataforma? No servidor, como funcionam os procedimentos para instalação?

Nosso ambiente de desenvolvimento (cliente) só é compatível com ambientes Windows, porém os sistemas desenvolvidos com a ferramenta são independentes de sistema operacional.

Do lado do servidor, disponibilizamos para Windows instaladores com Tomcat mais Postgre mais Webrun, como sugestão. Caso deseje um pacote diferente, deverá criá-lo.

Linux é, por natureza, um ambiente mais árduo de se operar, devido à sua vasta quantidade de distribuições. Sendo assim, como qualquer outra ferramenta, faz-se necessário desenvolver conhecimentos mais avançados para instalar um sistema criado.

8 - Que padrão possui a documentação das aplicações geradas pelo maker?

A documentação segue o padrão da Práxis, porém é um relatório normal do sistema e pode ser editado pelo desenvolvedor. Como qualquer relatório, podem-se gerar saídas não editáveis (PDF) ou editáveis (DOC ou HTML).

9 - O Maker utiliza premissas do modelo RAD (Rapid Application Development)?

O Maker utiliza algumas das primitivas do RAD. Algumas delas não se aplicam ao nosso modelo de desenvolvimento, porém, sua essência está de acordo com nossa proposta:

  • permite o desenvolvimento rápido de aplicações;

  •  enfatiza um ciclo de desenvolvimento extremamente curto;

  • cada função principal pode ser direcionada para a uma equipe RAD separada e então integrada a formar um todo;

  • criação e reutilização de componentes;

  • usado principalmente para aplicações de sistemas de informações;

  • desenvolvimento é conduzido em um nível mais alto de abstração;

  • visibilidade mais cedo (protótipos);

  • maior flexibilidade;

  • envolvimento maior do usuário;

  • redução de custos;

  • aparência padronizada.

10 - Como se comporta a ferramenta no quesito controle de transação e integridade do banco de dados?

O Maker, assim como o EJB, proporciona suporte automático para transações distribuídas em aplicações. Essas transações podem alterar dados atomicamente em múltiplas bases de dados.

Cada formulário do Maker, que acessa um conjunto de dados, controla uma transação ”mestre” e, para cada dependência, que também acesse um conjunto de dados, é aberta uma transação aninhada. Como dependências, podemos citar subformulários, regras de negócio, grids, formulários linkados entre outros. Seguindo o princípio da atomicidade, as alterações em dados só são confirmadas se todas as transações forem concluídas com êxito. Com isso, podemos até alterar mais de uma fonte de dados, que o Maker permitirá/garantirá a atomicidade.

O Maker também armazena dados em memória para serem postados posteriormente. Esse comportamento ocorre para situações de Mestre-Detalhe, em que, teoricamente, os dados de um detalhe só podem ser incluídos após o mestre existir. Porém, o Maker permite a inclusão de dados no detalhe e esses tais dados só são confirmados quando o mestre for incluído.

Por padrão, as transações do Maker são do tipo READ_COMMITED, o que significa que o processo B vai enxergar os dados do processo A quando ele fizer um commit.

11 - A ferramenta possibilita a personalização de sua aplicação em tempo de execução?

Como a ferramenta tem um modo de trabalho de interpretador, modificações podem ser feitas e visualizadas instantaneamente. Essas modificações podem ser realizadas por um desenvolvedor ou pelo usuário final, desde que ele tenha adquirido uma licença do Maker e esteja devidamente treinado.

12 - A ferramenta permite que o usuário possa definir nomes de arquivos/diretórios gerados automaticamente, para quê dê condições de o usuário padronizar uma estrutura de diretórios compatível com a dos sistemas desenvolvidos e seguindo o processo de desenvolvimento?

Depende do gerador de código e do framework que roda por baixo do Webrun.

13 - Gera código para .NET C# ?

Aplicações completas são geradas em JAVA/JavaScript e SQL dos bancos Oracle, Sql Server, Postgre  e Firebird. Atualmente, estamos implementando .NET, ou seja, futuramente, as aplicações desenvolvidas dentro da filosofia Maker poderão ser portadas para .NET sem nenhuma implementação.

Na versão atual, rotinas isoladas podem ser geradas diretamente do fluxo para as linguagens ABAP4, COBOL, C e outras.

Disponibilizamos um mecanismo para cadastramento de novas linguagens, construído com o próprio Maker, e fornecemos também um manual técnico.

14 - É possível, com o código gerado, publicar uma aplicação em um provedor externo ou interno, sem a instalação do módulo runtime/api ?

Sim. Existem duas formas:

1) Utilizando um runtime para interpretação dos sistemas criados com o Maker, porém esse runtime pode ser rodado em servidores de aplicações homologados.

2) Pela exportação das classes já compiladas (formulários, regras e relatórios).

Os servidores de aplicações homologados são Tomcat (puro) e JBOSS.

15 - Permite personalização de Menus por parte do Usuário?

Os sistemas gerados podem seguir uma proposta padrão definida no Maker, porém pode-se customizá-la ou até descartá-la totalmente.

Para customizar a proposta do Maker, podem ser criados novos Skins através de imagens e folhas de estilo.

16 - Permite personalização de Layout por parte do Usuário?

Os sistemas gerados podem seguir uma proposta-padrão definida no Maker, porém pode-se customizá-la ou até descartá-la totalmente.

Para customizar a proposta do Maker, podem ser criados novos Skins por meio de imagens e folhas de estilo.

17 - Permite personalização de Formulário por parte do Usuário?

Os sistemas gerados podem seguir uma proposta-padrão definida no Maker, porém pode-se customizá-la ou até descartá-la totalmente.

 

Para customizar a proposta do Maker, podem ser criados novos Skins por meio de imagens e folhas de estilo.

18 - Permite fazer DEBUG passo a passo do código gerado?

Não é passo a passo, porém é funcional. É feito pela inserção da funcionalidade "ponto de parada” nos locais específicos dentro das regras de negócio. Dispõe das ações "avançar” e "interromper”, além de visualização do conteúdo das variáveis.

19 - Ainda com relação ao DEBUG, precisa de alguma ferramenta complementar?

É disponibilizado um mecanismo de debug conforme item anterior. Está em fase de implementação um DEBUG totalmente visual (visualiza a regra de negócio/fluxo passo a passo).

20 - Implementa efetivamente os conceitos de Orientação à Objetos?

Para o uso do Maker, não são necessários os conceitos de OO, visto que é outro paradigma. Nas aplicações geradas, nossa camada de persistência acessa diretamente tabelas, porém já desenvolvemos para serem geradas com OO e estamos em fase de homologação.

21 Implementa controle de Acesso a nível de menu dinâmico, com base em Grupos?

Sim. Nosso Controle de Acesso é bem completo, inclusive, pode integrar com outros mecanismos de autenticação/autorização (através de webservices, por exemplo). Temos também suporte nativo a leitores biométricos.

22 - Implementa Controle de Acesso a nível de Tipo de Operação (Atualização / Exclusão) por Tela e Grupos?

Sim. Nosso Controle de Autorização é por grupo/tela/componentes e tem as seguintes chaves: visível, apenas leitura, habilitado, escrita, remoção e atualização.

23 - Permite que o código gerado seja exportado e utilizado em qualquer servidor de aplicação-padrão J2EE?

Teoricamente, sim. Atualmente, já homologamos o JBOSS e o Tomcat (puro), sem nenhuma implementação ou problema. Para rodar em qualquer servidor, será necessário uma avaliação caso a caso.

24 - Implementa geração automática de documentação em moldes similares a produtos como o Java Doc?

Sim. O código gerado é comentado segundo a especificação do Java Doc.

25 - Permite algum tipo de integração com outros Frameworks, tipo Jcompany? A preocupação é de alguma preservar investimentos já realizados.

Dentro do ambiente de definição das regras (fluxos), é possível fazer chamadas a classes externas pela funcionalidade ”executar JAVA”, porém, além de necessitar de um especialista para implementar de forma correta, é conveniente avaliar os benefícios (manutenções futuras em linha de código), pois, pela agilidade que o Maker proporciona no processo de desenvolvimento (até 60x), aconselhamos (re)-desenvolver toda a aplicação no Maker. Além de facilitar a manutenção (tudo em fluxo), vai garantir que futuramente a aplicação possa rodar em outras linguagens/plataformas homologadas pela Softwell (.NET por exemplo).

26 - O que é preciso ter instalado no cliente para rodar as aplicações geradas pelo Maker?

Um dos servidores de aplicações homologados. Se quiser usar o ReportBuilder como gerador de relatórios em ambiente Linux, precisa do Wine. Opcionalmente, pode ser usado o Jasper. Temos também um conversor ReportBuilder -> Jasper.

27 - Como fazemos a manutenção de nossos modelos de Dados Orientado à Objeto? (Persistência)

É um outro paradigma. Se formos tentar encaixar o paradigma adotado pelo Maker com a OO, não conseguiremos, pois é outro conceito. O Maker é mais bem visto sob o aspecto da análise essencial do que da análise OO. Nós focamos na lógica do negócio, garantidos pela infroestrutura que roda por baixo.

28 - De que forma é implementada a Persistência? Utiliza o Hibernate?

Breve. Nós temos um modelo nosso. Nós procuramos não usar tecnologias do mercado por saber que não existe um consenso que defina qual a melhor. Também não encontramos uma tecnologia de persistência que atendesse tanto a pequenos sistemas quanto a grandes sistemas. Sempre os requisitos mínimos eram muito altos para sistemas simples. Assim, decidimos criar a nossa.

Porém, sabendo da necessidade de alguns clientes, decidimos fornecer outras opções para nossa camada de dados. Sendo assim, estamos atualmente homologando o uso do EJB como modelo de persistência e logo em seguida estaremos iniciando a geração com Hibernate.

Essa possibilidade de mudar a camada de dados será oferecida a partir da versão 2.5 do Maker.

29 Implementa versionamento de registros e auditoria de alteração de registros? De que forma?

Sim e é parametrizado. Logamos em tabelas de banco, portanto podem ser criados relatórios de LOG.

30 - Foi oferecida a possibilidade de imprimir os dados apresentados em tela. Existe ferramenta específica para criação a de relatórios? Permite a criação de relatórios complexos, com diversos níveis de quebra e totalização?

Sim. Faz parte do ambiente Maker um gerador de relatórios bastante poderoso, o ReportBuilder. Também há a possibilidade de usar Jasper (que, inclusive, é aconselhado para ambientes não windows).

31 - Hoje utilizamos o Struts, Façades, Classes de Negócio, de Persistência, etc. Como funciona esse fluxo de requisições no Maker? É implementado em uma única classe do Produto?

Nós implementamos um MVC nosso para o código gerado. Não utilizamos frameworks do mercado; implementamos o nosso.

O conceito do Maker é não necessitar tocar no código gerado nunca. Assim, com o tempo, vocês verão que tais tecnologias não se tornam necessárias. O Maker não é uma ferramenta para desenvolvimento JAVA. O Maker é um completo ambiente que tem a possibilidade de exportação para outras linguagens, inclusive JAVA.

32 - É bastante usual para as Software Houses, implementar sistemas Multi-Empresa e Multi-Filiais, compartilhando informações entre as mesmas. O Maker permite este tipo de Implementação?

Sim. Desenvolver sistemas multiempresas é apenas uma questão de especificação. Interoperamos também com outros sistemas por meio de webservices e sockets.

33 - Já existem Software Houses usando o produto para o desenvolvimento de Software sob medida? Podem nos dar referências?

As aplicações pesadas Freire Informática - desde versão beta, prefeituras que tem estrutura de TI e desenvolvedores free lance.

34 - Para quais linguagens além do Java, o produto está preparado para gerar código?

As aplicações completas são geradas em JAVA/javaScript e SQL dos bancos oracle, sql server, postgre  e firebird. Atualmente, estamos implementando .NET, ou seja, futuramente, as aplicações desenvolvidas dentro da filosofia Maker poderão ser portadas para .NET sem nenhuma implementação. Rotinas/algoritmos podem ser geradas diretamente do fluxo para diversas linguagens ABAP4/COBOL/C/outras (disponibilizamos um mecanismo para cadastramento de novas linguagens, construído com o próprio Maker, e fornecemos também um manual técnico).

____________________________________________________________________________

Caso este tópico não tenha comentário satisfatório, envie e-mail para [email protected]

previous page start next page