Você está na página 1de 42

MAKER

Uma introdução ao ambiente visual de desenvolvimento

MAKER Uma introdução ao ambiente visual de desenvolvimento COMPRE AGORA Compre o livro MAKER. Acesse o

COMPRE AGORA

Compre o livro MAKER. Acesse o link abaixo e faça o seu pedido. http://www.softwell.com.br/produto/livro-maker/

Preencha a ficha de cadastro no final deste livro e receba gratuitamente informações sobre os

Preencha a ficha de cadastro no final deste livro e receba gratuitamente informações sobre os lançamentos e as promoções da Elsevier.

Consulte também nosso catálogo completo, últimos lançamentos e serviços exclusivos no site www.elsevier.com.br

MAKER

Uma introdução ao ambiente visual de desenvolvimento

Leonardo Costa Borges

© 2011, Elsevier Editora Ltda.

Todos os direitos reservados e protegidos pela Lei n o 9.610, de 19/02/1998. Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou trans- mitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros.

Preparação de texto: Sandra Scapin Revisão: Heraldo Vaz Editoração eletrônica: S4 Editorial Ltda. ME.

Elsevier Editora Ltda. Conhecimento sem Fronteiras Rua Sete de Setembro, 111 – 16 o andar 20050-006 – Centro – Rio de Janeiro – RJ – Brasil

Rua Quintana, 753 – 8 o andar 04569-011 – Brooklin – São Paulo – SP – Brasil

Serviço de Atendimento ao Cliente

0800-0265340

sac@elsevier.com.br

ISBN 978-85-352-5034-3

Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendimento ao Cliente, para que possamos esclarecer ou encaminhar a questão. Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens, originados do uso desta publicação.

Embora os autores tenham colocado seu melhor esforço na escrita deste livro, eles não assumem qualquer res- ponsabilidade por erros ou omissões, ou qualquer dano que possa resultar das informações aqui apresentadas.

CIP-BRASIL. CATALOGAÇÃO-NA-FONTE SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ

B732m

Borges, Leonardo Costa Maker: introdução ao ambiente visual de desenvolvimento / Leonardo Costa Borges. - Rio de Janeiro: Elsevier, 2011.

Apêndice ISBN 978-85-352-5034-3

1. Programação para Internet. 2. Programas de computador. 3. Livros eletrônicos.

I. Título.

11-3696.

CDD: 005.3

CDU: 004.42

AgrAdecimentos

Durante a construção deste sonho, pude contar com o apoio de muitos companheiros de trabalho. Registro aqui meus agradecimentos aos pro- fissionais e amigos que contribuíram com idéias, com assistência durante

a construção dos textos e com fotos, vídeos, revisão, edição e publicação. Agradeço a Magno Queiroz e Mariana Lacerda, essenciais para

a construção de alguns capítulos; a Diego Daltro, Samuel Carvalho e Adam Santos, pelo importante papel que desempenharam nas fases de confecção dos vídeos, fotos e revisões, e em especial ao escritor José Antonio Ramalho, que dividiu comigo sua experiência e metodologia

– com tamanha atenção e disposição, Ramalho foi fundamental para o

pontapé inicial deste projeto e, claro, para a conclusão deste livro, que considero o primeiro de muitos.

Registro também minha eterna gratidão a Wellington Freire e Maurício Andrade, meus líderes, que acreditaram em meu potencial e me ofereceram todo o incentivo necessário para que, juntos, pudéssemos concluir este sonho. Agradeço, claro, à minha mãe, pelo amor e pelo dom de me trans- mitir tranqüilidade nos momentos em que eu corria contra o tempo e por ter me ajudado a manter o entusiasmo para ultrapassar as barreiras

e transferir para o papel minha expertise em Maker. E agradeço ainda a todos que participaram deste projeto, dessa busca em ajudar os profissionais da área de tecnologia a quebrar seus paradigmas e a introduzi-los no mundo Maker.

sumário

1. Introdução

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

2. O Maker: Descrição do ambiente

 

9

2.1 Definição

do

Maker.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

2.2 Fluxogramas.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

2.3 Webrun

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

2.4 Interface de Formulários

 

15

2.5 Maker

Report .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

16

2.6 Abstração

no

Maker .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

2.7 Rastreabilidade.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

2.8 Depurador

Visual.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

2.9 Internacionalização das Aplicações

 

21

2.10 Gap Semântico

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

2.11 Profiler .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

2.12 Documentação

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

3. Aplicação Exemplo

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

3.1 Definição e Tecnologias Utilizadas

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

3.2 Descrição dos Recursos e Modelo de Dados

 

.

.

.

.

.

.

25

3.3 Telas

do

Sistema.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

27

3.4 Cenário

Exemplo.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

viii

ÍNDICE

viii ÍNDICE

4. Formulários

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

4.1 Criando um projeto Maker

 

32

4.1.1

Arquivo

WFRE .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

34

4.2 Introdução à criação de formulários

.

.

.

.

.

.

.

.

.

.

.

.

.

35

4.2.1 Assistente de banco de dados

 

38

4.2.2 Aba Localizar

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

39

4.2.3 Formulário como produto final

 

40

4.2.4 Persistência de dados e chaves primárias

 

41

4.2.5 Criação do Menu

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

42

4.3 Configuração de acesso para visualização na Web

43

4.4 Criação do formulário Estado

 

44

4.5 Criação do formulário

 

45

4.5.1

Componente Lista Dinâmica

 

45

4.6 Criação do formulário Contato

 

47

4.6.1 Subformulário .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

48

4.6.2 Assistente SQL

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

49

4.7 Tela de Observação

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

53

4.7.1

Valor-padrão do formulário

 

54

4.8 Criação da forma tradicional

 

57

4.8.1 Criação da tabela

 

57

4.8.2 Criação do formulário Parâmetro

 

59

5. Conhecendo fluxogramas

 

63

5.1 Definição .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

63

5.2 Eventos e Elementos que compõem um Fluxo

 

64

5.2.1 Processamento

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

65

5.2.2 Ordem de execução e comportamento

 

66

5.2.3 Decisão

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

69

5.2.4 Interação e Subfluxo

 

70

5.3 Criação do cenário de

 

71

5.3.1

Conhecendo os modos de trabalho

 

(Projeto, Normal e Gerente)

 

.

.

.

.

.

.

.

.

.

.

.

.

72

5.4 Construção do fluxo de validação

 

73

5.4.1 Definindo parâmetros de entrada

 

74

5.4.2 Adicionando componentes ao fluxo

 

74

5.4.3 Padrões e configurações de salvamento

 

78

5.4.4 Camadas de um fluxo

 

79

MAKER: Uma introdução ao ambiente visual de desenvolvimento

ix

5.5 Construção do fluxo de interação com

 

81

5.6 Construção de fluxo com a execução de um

 

laço de repetição

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

84

6. Fluxo na Prática

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

91

6.1 Criação do formulário Consulta Mapa

 

91

6.1.1

Biblioteca Google Maps

 

93

6.1.2

Subfluxo

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

95

6.2 Criação do formulário Envio de E-mail

.

.

.

.

.

.

.

.

.

.

102

6.2.1

Função

Upload .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

104

6.2.2

Envio de E-mail

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

109

6.2.2.1

 

Estrutura de pastas dos anexos

 

115

6.2.3

Download do

 

116

6.2.3.1

 

Acesso aos arquivos anexados

 
 

(URL de Acesso)

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

116

7. Relatórios .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

119

7.1 Introdução à criação de Relatórios

.

.

.

.

.

.

.

.

.

.

.

.

.

.

119

7.1.1

Comportamento das áreas do relatório

 
 

(bandas).

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

120

7.1.2 Componentes do relatório

 

122

7.1.3 Alinhamento e espaçamento dos

 
 

componentes.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

126

7.1.4

Visualização e publicação do relatório

 

127

7.2 Relatório com agrupamento

 

129

7.2.1 Filtrando o relatório

129

7.2.2 Criando o Grupo

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

132

7.3 Relatório de Histórico de Contatos

 

135

7.3.1

Relacionando o Sub-relatório

 

137

8. Publicação .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

141

8.1 Webrun

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

141

8.1.1

Maker.Commons

 

142

8.2 Publicação utilizando WAR

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

143

8.3 Publicação utilizando

 

145

x

ÍNDICE

x ÍNDICE

9. Rotinas práticas

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

149

9.1 Exportação de um arquivo texto a partir do

 
 

banco

de

dados.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

149

9.2 Leitura de um arquivo

 

155

9.3 Importação através de uma Planilha Excel

 

161

 

9.3.1

Criando uma Fonte de Dados ODBC

 

162

10.

Maker: IDE em detalhes

 

173

10.1 Controle de acesso no ambiente de

 
 

desenvolvimento

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

173

10.1.1 Cadastro de grupos de usuários

.

.

.

.

.

.

.

.

.

.

173

10.1.2 Cadastro de usuários

 

174

10.1.3 Permissão de Acesso a

 

176

10.1.4 Restrição de acesso: controle de

 
 

concorrência .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

178

10.2 Controle de acesso no ambiente final

 

178

 

10.2.1 Cadastro de grupos de acesso e usuários

 

179

10.2.2 Permissão de

 

181

10.3 Controle de Versão

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

183

10.4 Importação e exportação de objetos

 

184

 

10.4.1 Exportação

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

185

10.4.2 Importação

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

186

10.5 Matriz de Rastreabilidade (Scanner de Dependências)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

187

Índice Remissivo

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

189

1

introdução

Por José Antonio Ramalho

A primeira forma de programar computadores é datada de 1940, quan-

do os programadores desenvolviam algoritmos binários para serem executados no Eniac (primeiro computador do mundo). Um pouco mais adiante, por volta de 1950, surge a linguagem de máquina, em que programas de computadores eram feitos com instruções de baixo nível, tratando registradores dos processadores. Ainda nesta década, em

1954, surge a primeira linguagem de programação, o Fortran, que per- mite escrever programas com o uso de estruturas muito mais intuitivas que os códigos binários e de máquina. De 1954 até hoje escrevemos

algoritmos do mesmo jeito, digitando caractere a caractere, byte a byte; percebe-se que houve uma pausa no formato da codificação. Surgiram,

é claro, muitos novos paradigmas, ferramentas de apoio à programação,

mas o formato da escrita do código ainda é o mesmo. Os microcomputadores mudaram a relação hierárquica na área de desenvolvimento de sistemas. O ciclo de desenvolvimento de um sistema passava por etapas bem definidas, nas quais diferentes profissionais atuavam ao longo do ciclo em tarefas específicas e limitadas em suas atribuições. Da percepção da necessidade de um sistema pelo usuário até a sua efetiva implementação, um leque de profissionais entrava em ação. De uma maneira genérica, o analista de sistemas recebia a soli- citação do sistema e, juntamente com os departamentos, levantava o

2

INTRODUÇÃO

2 INTRODUÇÃO

fluxo das informações para poder criar um modelo informatizado do procedimento manual existente. Os dados obtidos com o modo de operação do sistema eram transformados em fluxogramas, que ajudariam na definição dos procedi- mentos e nas rotinas computadorizadas necessárias à operação daquele sistema, e, desse material, especificações e desenhos de bancos de dados eram criados com toda a lógica e relacionamentos necessários entre as tabelas que o compunham. Especificações detalhadas de campos e telas de digitação, consultas

e outras operações em vídeo eram criadas, assim como o desenho do layout de relatórios de consulta impressa. Todas essas especificações eram passadas para um segundo pro- fissional, o programador. Ele deveria entender corretamente o que o analista lhe pedia e usar a linguagem adequada para aquele sistema para criar todos os componentes necessários. Nesse ponto, milhares ou até milhões de linhas de código eram escritas. O processo de testes e debug do sistema implicava inúmeras idas

e vindas do programador à mesa para estudar as listagens impressas e

tentar encontrar os problemas. Poderia ser simplesmente uma vírgula, ou um ponto colocado no lugar errado, ou um erro de lógica. Sem interface gráfica ou ferramentas de apoio para encontrar os erros, essa parte do sistema consumia inúmeras horas de trabalho e respondia por boa parte do atraso na entrega de um sistema. O programador não tinha contato com o computador. Sua relação com ele era por meio de gabaritos

e formulários, nos quais escrevia o código que era digitado por um digitador. Na época dos mainframes, adicionava-se a essa hierarquia os per- furadores de cartões e os operadores dentro do CPD, que iriam trocar fitas e discos quando isso fosse necessário. Uma vez que estivesse pronto, o sistema era passado para um operador, que seria o responsável pela operação do sistema. O usuário final ainda não tocaria no computador por muitos anos. Eu, particularmente, passei por quase todo esse ciclo. Comecei a programar em 1981, no início absoluto da era da microinformática. Na faculdade, vivi o ciclo do mainframe; na prática profissional, encontrei os primeiros microcomputadores do mercado. Toda aquela hierarquia Analista/Programador/Operador parecia não existir mais, e, na frente do pequeno computador, eu tinha de

MAKER: Uma introdução ao ambiente visual de desenvolvimento

3

desempenhar essas três funções. Lembro-me de que, então, se dizia na brincadeira que quem trabalhava com microcomputadores era um “anapropégua”, isto é, um analista, um programador e um operador que trabalhava como uma égua. Brincadeiras à parte, a concentração de trabalho era bem real. As linguagens de programação passavam por mudanças e novas opções surgiam para aproveitar as facilidades dos microcomputadores. O poderoso Cobol cedia espaço ao Basic, e um banco de dados chamado dBase surgia para mudar de vez o cenário. Incorporando banco de dados e linguagem de programação, o produto oferecia uma com- binação que tornava o desenvolvedor cada vez mais dono da aplicação. Foi o começo da era das Software Houses. Na segunda metade da

década de 1980, uma nova ferramenta, o Clipper, tornou-se a linguagem dominante no ambiente de microcomputadores. Então, milhares de programadores utilizavam essa linguagem, que, comparada às antigas Basic e Cobol oferecia muito mais versatilidade

e rapidez de desenvolvimento. Contudo, como qualquer linguagem,

exigia que o programador escrevesse linha por linha todo o código ne- cessário para a criação de suas rotinas e procedimentos. Tornei-me um bom programador nessa linguagem, mas nunca

aceitava o fato de ter de escrever, escrever e escrever dezenas de linhas para, por exemplo, exibir um único campo na tela, obter seu conteúdo

e fazer a validação básica. A criatividade para encontrar a solução para um problema e a beleza de um sistema bem desenvolvido tinham de compartilhar horas e ho- ras de programação, que consistia do trabalho braçal de escrever milhares de linhas simplesmente para criar uma tela ou o layout de um relatório. Um dia, porém, resolvi criar alguns programas para facilitar minha vida de programador. Com um formulário na tela, eu preenchia o nome dos campos, suas regras de consistência e posição na tela (sim, naquela época era necessário dizer a linha e a coluna da tela em que um texto seria posicionado), o nome da variável que receberia o conteúdo, seu tamanho e outas informações. E, depois de compilar e executar o pro- grama, se algum item ficasse fora da posição adequada, era necessário alterar o código fonte e recompilar todo o sistema. Na primeira versão das minhas rotinas criadoras de código eu precisava editar a posição do campo na tela e recompilar; no aprimora-

4

INTRODUÇÃO

4 INTRODUÇÃO

mento da rotina, criei um banco de dados que armazenava todas essas informações, de modo que o sistema não precisasse ser recompilado. Ao ser executado, ele lia o banco de dados e executava os comandos para desenhar a tela ou o relatório. Onde não havia Windows, essa situação ocorria no ambiente DOS. Mesmo com a proliferação do Windows a partir da versão 3.1, no começo da década de 1990, o ambiente de desenvolvimento e a execução dos programas em Clipper ainda era em uma janela DOS. As linguagens que rodavam em DOS começaram a enfrentar uma nova realidade. Para os usuários, o ambiente gráfico era muito mais agradável de se trabalhar. O mouse e o cursor foram ganhando muitos adeptos; a famosa tecla Tab, usada para saltar o foco de um componente para outro de uma tela, dava espaço para os cliques. As linguagens baseadas no banco de dados dBase, como FoxPro, Clipper e outras menos expressivas, não conseguiram migrar para o Windows um ambiente de desenvolvimento que fosse atraente para os desenvolvedores. Além das dificuldades em se adaptar ao mouse, os programadores, de início, não lidaram bem com a nova forma de desenhar sistemas que as ferramentas gráficas ofereciam. Um pouco atrás no tempo, até mesmo as linguagens mais populares, como Clipper, estavam incorpo- rando orientação a objetos, uma nova abordagem de programação, na qual o desenvolvedor criava objetos ou entidades uma única vez e depois podia modificar suas características e alterar seu comportamento. Por exemplo, se um campo tivesse um valor negativo, sua cor de exibição seria vermelha. Em programação convencional seriam necessárias varias linhas de código para obter o conteúdo, fazer as comparações e exibir o valor com uma nova cor, mas em programação orientada por objetos bastaria informar que o atributo “cor” do objeto seria vermelho caso o valor fosse negativo. Essa mudança começou a criar dificuldades para muitos desenvol- vedores. Quando chegou o ambiente gráfico, o desenvolvedor, além da orientação a objetos, tinha de aprender a também lidar com o ambien- te de desenvolvimento gráfico. Nele, bastava clicar num botão na barra de ferramentas do ambiente, clicar sobre a área de trabalho e simples- mente escrever o nome do campo que, em menos de um segundo, todas as consistências necessárias estavam prontas e funcionando. O tempo

MAKER: Uma introdução ao ambiente visual de desenvolvimento

5

de desenvolvimento de uma tela de entrada de dados caia mais de dez vezes se comparada às linguagens procedurais. Os mais conservadores abominavam esse ambiente. Um clima de insegurança se abatia sobre os programadores que, orgulhosos, de seu trabalho braçal, assumiam a propriedade ciumenta do código de uma aplicação. Sem ter o controle do código, eles não tinham mais a sensação de propriedade, e essa insegurança começou a se espalhar de forma velada pela comunidade de desenvolvimento. Ainda hoje, dez anos depois no

novo século, muitos desenvolvedores ainda resistem aos novos ambientes de desenvolvimento. Felizmente, ou infelizmente para eles, chegou um ponto em que

a troca do parque instalado de hardware e as novas versões de sistema operacional eliminaram de vez a possibilidade de manter as antigas linguagens e ferramentas de desenvolvimento.

As linguagens tradicionais, como o C e o Basic, ganharam versões

visuais, que utilizavam a plataforma gráfica para o desenvolvimento, mas ainda exigiam do programador a codificação de milhares e milhares de linhas para desenvolver a lógica mais intrínseca dos sistemas. Algumas ferramentas, como o Delphi, ganharam espaço, pro- movendo com muita facilidade a integração do banco de dados às aplicações. Embora as ferramentas tenham facilitado o desenvolvimento, a maioria delas incorria na necessidade de se trabalhar em algum momen- to o código gerado por ela. Ou seja, o desenvolvedor precisava continuar sendo um programador especializado em alguma linguagem. Como a tecnologia não para, a internet se estabeleceu nos últimos anos como a plataforma e a interface para aplicações. Tudo o que era proprietário, exclusivo de um fabricante ou outro, passou a fazer parte de um ativo comum da humanidade. Um sistema que rode num navegador rompe as barreiras físicas

e elimina as dificuldades de implementação devido a diferenças de sistemas operacionais ou de hardware utilizados pelos usuários. Com a internet, além de todas as mudanças, o desenvolvedor tinha de aprender novas ferramentas ou protocolos para integrar à sua aplicação.

Vi muitas grandes empresas, bem estabelecidas em seus ambientes

tradicionais, enfrentarem grandes dificuldades para migrar suas aplica-

6

INTRODUÇÃO

6 INTRODUÇÃO

ções para a internet. Verdadeiras colchas de retalhos eram criadas para se conseguir entregar a informação ao usuário por meio de um navegador. Olhando os últimos dez anos, muita coisa mudou para os de- senvolvedores. Além de se tornarem profissionais multidisciplinares, tendo que desempenhar várias funções numa única ocupação, o foco de seu trabalho deixou de ser a programação e passou a ser a solução dos desafios propostos. Surge aí um novo profissional, que prefiro chamar de analista de negócios, um profissional técnico com visão de negócios. Num mercado extremamente competitivo, onde custos e prazos são cada vez menores, as empresas precisam dispor de ferramentas e profissionais capazes de entregar as soluções nos prazos e orçamentos propostos, e tudo isso com um nível de exigência do usuário cada vez maior.

O desenvolvedor do futuro, que não mais terá esse adjetivo, será

aquele que conseguir entender o negócio do cliente, ou da sua empresa,

e transformar as necessidades expostas em soluções e sistemas prontos. Para o usuário, sempre irá importar a aparência e a funcionalidade

do sistema. O que estiver por trás da tela não terá a menor importância. Do ponto de vista técnico, considerações sempre deverão ser feitas com o intuito de utilizar plataformas de desenvolvimento e execução que sejam rápidas e de baixo custo. Nesse contexto de mudanças, vi surgir uma ferramenta que, para mim, conseguiu reunir como nenhuma outra características únicas para o desenvolvimento: o Maker.

O Maker é uma ferramenta que permite desenvolver qualquer sis-

tema sem a necessidade de se programar uma linha sequer. O produto é

tão versátil que chega a causar desconfiança - “Mas como é possível?!”. Ele possui características de uma ferramenta de modelagem de dados, de um construtor de relatórios e de ambiente gráfico de desenvolvimento, tudo isso integrado e compilando aplicativos que rodam num navegador,

o que torna suas aplicações absolutamente universais. Quem vê o Maker pela primeira vez pergunta imediatamente em que linguagem ele irá compilar a aplicação. E quando ouve a resposta - “Em qual você quer?” -, a desconfiança aumenta. Mas basta sentar-se diante do micro e olhar as características do programa para constatar que, sim, isso é possível.

MAKER: Uma introdução ao ambiente visual de desenvolvimento

7

Mas onde eu escrevo o código?” Aí é que está a grande mudança de paradigma do Maker: não precisa escrever nenhum código. Toda a

parte de entrada de dados, de consultas e de relatórios é feita pela in- terface gráfica, algo que a maioria das ferramentas de desenvolvimento possui. Utilizando um recurso chamado Fluxos, o desenvolvedor escreve

a lógica da aplicação a partir de elementos gráficos de um fluxograma, ou seja, a linguagem de programação são os fluxogramas, e todos os algoritmos serão escritos de forma visual. Finalizado o fluxo, a aplicação é montada para ser rodada em um

navegador. Se algo não tiver ficado bom, basta o desenvolvedor retornar

à interface gráfica e refazer o fluxo, mas nunca editar um código textual.

O produto já possui inúmeras rotinas e funções prontas, que

cobrem boa parte das necessidades de desenvolvimento, mas rotinas

muito específicas já criadas pelo desenvolvedor podem ser facilmente incorporadas ao sistema, preservando investimentos já feitos.

O Maker é o verdadeiro nirvana dos desenvolvedores. Dois dias

de contato intenso com ele fizeram-me ver o quanto essa ferramenta pode impactar positivamente o tempo de desenvolvimento de sistemas criados para serem usados por meio de um navegador. Sua integração com e-mail e outros sites da internet permite a criação de sistemas absolutamente atuais, que integram o dia a dia dos usuários cada vez mais conectados com suas atividades diárias. Para mim, que posso me considerar um verdadeiro dinossauro na história da informática, o Maker conseguiu reunir o que há de melhor para o desenvolvimento de sistemas, e tudo isso sem limitar o desenvol- vedor a nenhum tipo de linguagem ou ambiente operacional.

José Antonio Ramalho

Escritor e autor de mais de 108 livros. Nessa coleção de livros escritos por ele encontram-se obras voltadas para bancos de dados e linguagens de programação. Com uma vasta experiência em desenvolvimento de softwares, Ramalho acompanhou todo o processo de evolução das linguagens de programação, desde as de baixo nível até as do presente momento, em que o paradigma é outro e a abstração faz parte do cotidiano.

2

o mAker:

descrição do Ambiente

2.1 definição do mAker

Diante de todos os conceitos abordados na introdução, o esperado é que façamos uma definição formal do Maker bem como uma descrição sucinta do ambiente, apresentando suas principais funcionalidades e seus benefícios. Tradicionalmente, IDEs (Integrated Development Environment) são ferramentas cujo objetivo é agilizar o processo de desenvolvimento de softwares, porém só são utilizadas na etapa de codificação ou de escrita do software. O Maker pode ser definido como uma plataforma para o desenvolvimento de aplicações que possui diversas particula- ridades, as quais serão descritas ao longo deste capítulo. É conside- rado uma plataforma porque é capaz de interagir em diversas etapas do processo de desenvolvimento, desde a documentação e elicitação de casos de uso até a codificação e manutenção que serão realizadas na plataforma. Com isso, nota-se que o paradigma que o define e mais se aproxima do seu formato de codificação é o Desenvolvimento de Software Orientado a Negócios, segundo o qual o foco do processo de desenvolvimento é o resultado. As tecnologias, como as linguagens, são meros instrumentos utilizados para materializar o negócio em uma solução computacional.

10

O MAKER: DESCRIÇÃO DO AMBIENTE

10 O MAKER: DESCRIÇÃO DO AMBIENTE

Uma característica muito importante e inovadora é o fato de a ferramenta possuir uma linguagem de programação visual, que são os fluxogramas, representando uma evolução no formato da escrita de algoritmos, pois até então era utilizado um padrão textual para a escrita de códigos.

2.2 fluxogrAmAs

Os fluxogramas vêm para quebrar o paradigma de codificação es- crita caractere a caractere. Quando se fala em código, este, erradamente, sempre é associado a letras. Fluxos nada mais são que uma linguagem de programação visual, em que algoritmos são escritos visualmente, disso advindo muitas vantagens. Desse modo, é muito mais fácil capacitar um profissional em uma linguagem visual, por exemplo, do que em uma sintaxe tradicional escrita, pois os algoritmos escritos em fluxos são en- tendidos facilmente e, em consequência, são mais fáceis de ser mantidos que aqueles escritos em uma linguagem tradicional, que não são nada intuitivos. A Figura 2.1 a seguir ilustra a sintaxe dos fluxogramas.

figurA 2.1

A sintaxe dos fluxogramas.

dos fluxogramas. figurA 2.1 A sintaxe dos fluxogramas. Todas as notações já conhecidas das linguagens de

Todas as notações já conhecidas das linguagens de programação tradicionais, como desvios, laços, condicionais, comentários, passagem de parâmetros, retornos, podem ser expressadas em um fluxograma. Entendendo que um algoritmo é a combinação de lógica de programa- ção adicionada a funcionalidades prontas, pode-se concluir que toda e qualquer lógica poderá ser expressada em fluxos. As funcionalidades, por sua vez, representam a API (Application Programming Interface) nativa que já vem embarcada na ferramenta; são centenas de funções de diversas categorias (acesso a banco, manipulação de arquivos, bibliotecas matemáticas, etc.) que fazem parte de um pacote interno do Maker.

MAKER: Uma introdução ao ambiente visual de desenvolvimento

11

Considere, por exemplo, um algoritmo que verifica se um cliente

é maior de idade. A Figura 2.2 a seguir ilustra o algoritmo escrito na linguagem PL-SQL.

a seguir ilustra o algoritmo escrito na linguagem PL-SQL. figurA 2.2 Algoritmo que verifica se um

figurA 2.2

Algoritmo que verifica se um cliente é maior de idade, escrito na linguagem PL-SQL.

A Figura 2.3 ilustra o mesmo algoritmo escrito em Maker, ou seja,

na linguagem dos fluxogramas. É possível observar que sua compreensão

é bem mais simples.

possível observar que sua compreensão é bem mais simples. figurA 2.3 Algoritmo que verifica se um

figurA 2.3

Algoritmo que verifica se um cliente é maior de idade, escrito em Maker.

Outra característica importante é o fato de o Maker implementar o conceito de independência tecnológica, ou seja, em tese, um código es- crito em Maker poderá ser executado em qualquer arquitetura-alvo, pois o algoritmo implementado não depende da plataforma de execução (atual- mente, as tecnologias suportadas para execução são Java e .Net). De modo similar, a aplicação também independe do banco de dados, sendo possível substituí-lo em qualquer tempo do ciclo de vida do software. É interessante ressaltar que a ferramenta sempre proporciona ao programador todo o poder necessário para que ele possa expressar sua criatividade e exercitar seu conhecimento de lógica de programação na construção dos fluxogra- mas, isto é, qualquer algoritmo que seja de lógica de programação poderá ser expressado na notação visual dos fluxogramas.

12

O MAKER: DESCRIÇÃO DO AMBIENTE

12 O MAKER: DESCRIÇÃO DO AMBIENTE

Considere, por exemplo, um algoritmo para efetuar uma migração de dados, que lê informações de um banco de dados Oracle e grava informações em um Postgres. O fluxograma mostrado na Figura 2.4 representa esta situação.

figurA 2.4

Algoritmo

para efetuar

uma

migração de

dados.

figurA 2.4 Algoritmo para efetuar uma migração de dados. Percebe-se, neste caso, a representação de um

Percebe-se, neste caso, a representação de um fluxo com chamadas a fluxos externos, que simbolizam a modularização, e um laço que percor- re a tabela que será migrada. Ao se expandir a funcionalidade executada no processamento “Carrega dados da Tabela de Origem” percebe-se uma operação de atribuição a uma variável chamada Tabela de uma função intitulada Abrir consulta. A Figura 2.5 a seguir ilustra o que foi descrito.

figurA 2.5

Rrepresentação de um fluxo com chamadas a fluxos externos em algoritmo para efetuar uma migração de dados.

externos em algoritmo para efetuar uma migração de dados. Ou seja: a variável Tabela receberá o

Ou seja: a variável Tabela receberá o valor resultante da função (API interna) Abrir consulta.

MAKER: Uma introdução ao ambiente visual de desenvolvimento

13

Em geral o Maker é confundido com diversos produtos, como gerador de códigos, ferramenta Case, Framework, ferramenta de gestão de processos (pelo fato de usar a mesma notação de fluxogramas). De fato, o produto não é nenhuma das ferramentas citadas, mas, sim, uma plataforma para o desenvolvimento de aplicações com alto grau de integração, abstração e alta performance.

2.3 Webrun

Para ser executada, uma aplicação escrita em Maker precisa estar acoplada a um dispositivo chamado Webrun. Trata-se de um motor (Engine) para a execução dos softwares codificados em Maker que possui diversas atribuições, como realizar todo o controle de autenti- cação e autorização bem como o de permissões na aplicação final, de compilação do software na arquitetura-alvo escolhida, de registro de Log de auditoria para transações na aplicação, etc. Para executar sob regime de publicação, o Webrun é acoplado ao software escrito em Maker, de modo que ambos integram um único pacote de publicação, constituindo então um único produto. A Figura 2.6 a seguir ilustra o mecanismo de funcionamento do Webrun.

2.6 a seguir ilustra o mecanismo de funcionamento do Webrun. figurA 2.6 Mecanismo de funcionamento do
2.6 a seguir ilustra o mecanismo de funcionamento do Webrun. figurA 2.6 Mecanismo de funcionamento do

figurA 2.6

Mecanismo de

funcionamento

do Webrun.

Após o acoplamento ou a compilação, o que se tem é o ilustrado no lado direito da Figura 2.6. No controle de autenticação e autorização, o Webrun dispõe de um mecanismo robusto, em que as unidades mais atômicas dos sistemas (os componentes) podem ser controladas, e permissões serão atribuídas ou negadas. Nesse processo, são contemplados Menus, Submenus

14

O MAKER: DESCRIÇÃO DO AMBIENTE

14 O MAKER: DESCRIÇÃO DO AMBIENTE

e componentes de formulários. A Figura 2.7 representa a interface de configuração de controle de permissões.

figurA 2.7

Interface

de confi-

guração de

controle de

permissões.

Interface de confi- guração de controle de permissões. O Webrun também implementa um robusto controle de

O Webrun também implementa um robusto controle de Log para todas as transações efetuadas no sistema. Ou seja, todo o Log de auditoria vem nativo nas aplicações escritas em Maker, de maneira que, ao im- plementar suas aplicações, o desenvolvedor não precisa se ater na cons- trução de tal funcionalidade. A Figura 2.8 ilustra essa funcionalidade.

figurA 2.8

Log de

auditoria.

se ater na cons- trução de tal funcionalidade. A Figura 2.8 ilustra essa funcionalidade. figurA 2.8

MAKER: Uma introdução ao ambiente visual de desenvolvimento

15

Todas as operações de inclusão, alteração e exclusão são armazena- das sob a forma de Log e podem ser consultadas pelos administradores do sistema. É interessante ressaltar que uma aplicação escrita em Maker é executada em uma robusta arquitetura de camadas, de forma que todos os conceitos de execução de aplicações Web, como balanceamento de carga, escalabilidade, clusterização, etc., são aplicáveis ao software desenvolvido em Maker.

etc., são aplicáveis ao software desenvolvido em Maker. figurA 2.9 Exemplo de uma aplicação escrita em

figurA 2.9

Exemplo

de uma

aplicação

escrita em

Maker.

2.4 interfAce de formulários

Para a construção de formulários, o Maker dispõe de um meca- nismo visual de componentes, em que objetos poderão ser dispostos em qualquer parte do formulário, bastando clicar e arrastá-los para a posição desejada. Trata-se de uma interface WYSIWYG (What-You- See-Is-What-You-Get). O que você vê é o que você obtém), que possui muita riqueza visual e facilidade de customização nesse aspecto, o que dá total poder ao programador para a criação de formulários com um alto grau de usabilidade sob o ponto de vista do usuário final. A Figura 2.10 ilustra a criação de um formulário com o Maker.

16

O MAKER: DESCRIÇÃO DO AMBIENTE

16 O MAKER: DESCRIÇÃO DO AMBIENTE

figurA 2.10