LivroMaker

5/16/2018 LivroMaker - slidepdf.com

http://slidepdf.com/reader/full/livromaker-55ab579134263 1/42



MAKER Uma introdução ao ambiente

visual de desenvolvimento

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 livroe 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 no

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 ScapinRevisão: Heraldo VazEditoração eletrônica: S4 Editorial Ltda. ME.

Elsevier Editora Ltda.Conhecimento sem FronteirasRua Sete de Setembro, 111 – 16

oandar

20050-006 – Centro – Rio de Janeiro – RJ – Brasil

Rua Quintana, 753 – 8o

andar04569-011 – Brooklin – São Paulo – SP – Brasil

Serviço de Atendimento ao [email protected]

ISBN 978-85-352-5034-3

Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros dedigitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nossoServiç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 oubens, 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-FONTESINDICATO 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êndiceISBN 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





















































AgrAdec imentos

Durante a construção deste sonho, pude contar com o apoio de muitoscompanheiros de trabalho. Registro aqui meus agradecimentos aos pro-fissionais e amigos que contribuíram com idéias, com assistência durantea 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 paraa construção de alguns capítulos; a Diego Daltro, Samuel Carvalho e

Adam Santos, pelo importante papel que desempenharam nas fases deconfecçã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 opontapé inicial deste projeto e, claro, para a conclusão deste livro, queconsidero o primeiro de muitos.

Registro também minha eterna gratidão a Wellington Freire eMaurício Andrade, meus líderes, que acreditaram em meu potencial eme ofereceram todo o incentivo necessário para que, juntos, pudéssemosconcluir 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 epor ter me ajudado a manter o entusiasmo para ultrapassar as barreirase transferir para o papel minha expertise em Maker.

E agradeço ainda a todos que participaram deste projeto, dessabusca em ajudar os profissionais da área de tecnologia a quebrar seusparadigmas e a introduzi-los no mundo Maker.































sumário

1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. O Maker: Descrição do ambiente . . . . . . . . . . . . . . . . . . 92.1 Definição do Maker . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Fluxogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Webrun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Interface de Formulários . . . . . . . . . . . . . . . . . . . . . . 152.5 Maker Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 Abstração no Maker . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 Rastreabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.8 Depurador Visual. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.9 Internacionalização das Aplicações . . . . . . . . . . . . . . 212.10 Gap Semântico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.11 Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.12 Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3. Aplicação Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53.1 Definição e Tecnologias Utilizadas . . . . . . . . . . . . . . . . 253.2 Descrição dos Recursos e Modelo de Dados . . . . . . 25

3.3 Telas do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 Cenário Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


























v ÍND ICE

4. Formulários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1 Criando um projeto Maker . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Arquivo WFRE . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Introdução à criação de formulários . . . . . . . . . . . . . 354.2.1 Assistente de banco de dados . . . . . . . . . . . . 384.2.2 Aba Localizar . . . . . . . . . . . . . . . . . . . . . . . . 394.2.3 Formulário como produto final . . . . . . . . . . 404.2.4 Persistência de dados e chaves primárias . . . 414.2.5 Criação do Menu . . . . . . . . . . . . . . . . . . . . . 42

4.3 Configuração de acesso para visualização na Web . . 434.4 Criação do formulário Estado . . . . . . . . . . . . . . . . . . 44

4.5 Criação do formulário Cidade . . . . . . . . . . . . . . . . . . 454.5.1 Componente Lista Dinâmica . . . . . . . . . . . . 454.6 Criação do formulário Contato . . . . . . . . . . . . . . . . . 47

4.6.1 Subformulário . . . . . . . . . . . . . . . . . . . . . . . . 484.6.2 Assistente SQL . . . . . . . . . . . . . . . . . . . . . . . 49

4.7 Tela de Observação . . . . . . . . . . . . . . . . . . . . . . . . . . 534.7.1 Valor-padrão do formulário . . . . . . . . . . . . . . 54

4.8 Criação da forma tradicional . . . . . . . . . . . . . . . . . . . 57

4.8.1 Criação da tabela Parâmetro. . . . . . . . . . . . . 574.8.2 Criação do formulário Parâmetro . . . . . . . . . 59

5. Conhecendo fluxogramas . . . . . . . . . . . . . . . . . . . . . . . . . 6 35.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Eventos e Elementos que compõem um Fluxo . . . . 64

5.2.1 Processamento . . . . . . . . . . . . . . . . . . . . . . . 655.2.2 Ordem de execução e comportamento . . . . 665.2.3 Decisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2.4 Interação e Subfluxo . . . . . . . . . . . . . . . . . . . 70

5.3 Criação do cenário de exemplo . . . . . . . . . . . . . . . . . 715.3.1 Conhecendo os modos de trabalho

(Projeto, Normal e Gerente) . . . . . . . . . . . . 725.4 Construção do fluxo de validação . . . . . . . . . . . . . . . 73

5.4.1 Definindo parâmetros de entrada . . . . . . . . . 745.4.2 Adicionando componentes ao fluxo . . . . . . . 745.4.3 Padrões e configurações de salvamento . . . . 785.4.4 Camadas de um fluxo . . . . . . . . . . . . . . . . . . 795.4.5 Associando fluxo ao formulário . . . . . . . . . . . 80












































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

5.5 Construção do fluxo de interação com objetos . . . . . 815.6 Construção de fluxo com a execução de um

laço de repetição . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6. Fluxo na Prática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 16.1 Criação do formulário Consulta Mapa . . . . . . . . . . . 91

6.1.1 Biblioteca Google Maps . . . . . . . . . . . . . . . . 936.1.2 Subfluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.2 Criação do formulário Envio de E-mail . . . . . . . . . . 1026.2.1 Função Upload . . . . . . . . . . . . . . . . . . . . . . . 1046.2.2 Envio de E-mail . . . . . . . . . . . . . . . . . . . . . . 109

6.2.2.1 Estrutura de pastas dos anexos . . . 1156.2.3 Download do E-mail . . . . . . . . . . . . . . . . . . . 116

6.2.3.1 Acesso aos arquivos anexados(URL de Acesso) . . . . . . . . . . . . . . 116

7. Relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 97.1 Introdução à criação de Relatórios . . . . . . . . . . . . . . 119

7.1.1 Comportamento das áreas do relatório(bandas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.1.2 Componentes do relatório . . . . . . . . . . . . . . 1227.1.3 Alinhamento e espaçamento dos

componentes . . . . . . . . . . . . . . . . . . . . . . . . . 1267.1.4 Visualização e publicação do relatório . . . . . 127

7.2 Relatório com agrupamento . . . . . . . . . . . . . . . . . . . 1297.2.1 Filtrando o relatório . . . . . . . . . . . . . . . . . . . 129

7.2.2 Criando o Grupo . . . . . . . . . . . . . . . . . . . . . 1327.3 Relatório de Histórico de Contatos . . . . . . . . . . . . . . 135

7.3.1 Relacionando o Sub-relatório . . . . . . . . . . . . 137

8. Publicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 18.1 Webrun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.1.1 Maker.Commons . . . . . . . . . . . . . . . . . . . . . 1428.2 Publicação utilizando WAR . . . . . . . . . . . . . . . . . . . 143

8.3 Publicação utilizando JAR . . . . . . . . . . . . . . . . . . . . . 1458.4 Assistente de atualizações e configurações . . . . . . . . 147









































ÍND ICE

9. Rotinas práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 99.1 Exportação de um arquivo texto a partir do

banco de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

9.2 Leitura de um arquivo texto. . . . . . . . . . . . . . . . . . . . 1 5 59.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 . . . . . . . . . . . . . . . . . . . . . . . . 1 7 310.1 Controle de acesso no ambiente de

desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17310.1.1 Cadastro de grupos de usuários . . . . . . . . . . 173

10.1.2 Cadastro de usuários . . . . . . . . . . . . . . . . . . . 17410.1.3 Permissão de Acesso a objetos . . . . . . . . . . . . 17610.1.4 Restrição de acesso: controle de

concorrência . . . . . . . . . . . . . . . . . . . . . . . . . 17810.2 Controle de acesso no ambiente final . . . . . . . . . . . . 178

10.2.1 Cadastro de grupos de acesso e usuários . . . 17910.2.2 Permissão de acesso . . . . . . . . . . . . . . . . . . . . 181

10.3 Controle de Versão . . . . . . . . . . . . . . . . . . . . . . . . . . 183

10.4 Importação e exportação de objetos . . . . . . . . . . . . . 18410.4.1 Exportação . . . . . . . . . . . . . . . . . . . . . . . . . . 18510.4.2 Importação . . . . . . . . . . . . . . . . . . . . . . . . . . 186

10.5 Matriz de Rastreabilidade(Scanner de Dependências) . . . . . . . . . . . . . . . . . . . 187

Índice Remissivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8 9

































1introduçãoPor José Antonio Ramalho

A primeira forma de programar computadores é datada de 1940, quan-do os programadores desenvolviam algoritmos binários para seremexecutados no Eniac (primeiro computador do mundo). Um pouco

mais adiante, por volta de 1950, surge a linguagem de máquina, emque programas de computadores eram feitos com instruções de baixonível, tratando registradores dos processadores. Ainda nesta década, em1954, surge a primeira linguagem de programação, o Fortran, que per-mite escrever programas com o uso de estruturas muito mais intuitivasque os códigos binários e de máquina. De 1954 até hoje escrevemosalgoritmos 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 dedesenvolvimento de sistemas. O ciclo de desenvolvimento de um sistemapassava por etapas bem definidas, nas quais diferentes profissionais atuavamao 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é asua 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

fluxo das informações para poder criar um modelo informatizado doprocedimento 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 daquelesistema, e, desse material, especificações e desenhos de bancos de dadoseram criados com toda a lógica e relacionamentos necessários entre astabelas que o compunham.

Especificações detalhadas de campos e telas de digitação, consultase outras operações em vídeo eram criadas, assim como o desenho dolayout 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 oanalista lhe pedia e usar a linguagem adequada para aquele sistema paracriar 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 idase vindas do programador à mesa para estudar as listagens impressas etentar 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 porboa parte do atraso na entrega de um sistema. O programador não tinhacontato com o computador. Sua relação com ele era por meio de gabaritose 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áriofinal ainda não tocaria no computador por muitos anos.

Eu, particularmente, passei por quase todo esse ciclo. Comecei aprogramar em 1981, no início absoluto da era da microinformática. Nafaculdade, vivi o ciclo do mainframe; na prática profissional, encontreios primeiros microcomputadores do mercado.

Toda aquela hierarquia Analista/Programador/Operador parecianão existir mais, e, na frente do pequeno computador, eu tinha de










































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

desempenhar essas três funções. Lembro-me de que, então, se diziana 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çãode trabalho era bem real. As linguagens de programação passavam pormudanças e novas opções surgiam para aproveitar as facilidades dosmicrocomputadores.

O poderoso Cobol cedia espaço ao Basic, e um banco de dadoschamado dBase surgia para mudar de vez o cenário. Incorporando bancode 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 dadécada de 1980, uma nova ferramenta, o Clipper, tornou-se a linguagemdominante no ambiente de microcomputadores.

Então, milhares de programadores utilizavam essa linguagem, que,comparada às antigas Basic e Cobol oferecia muito mais versatilidadee 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 nuncaaceitava o fato de ter de escrever, escrever e escrever dezenas de linhaspara, por exemplo, exibir um único campo na tela, obter seu conteúdoe fazer a validação básica.

A criatividade para encontrar a solução para um problema e a belezade um sistema bem desenvolvido tinham de compartilhar horas e ho-ras de programação, que consistia do trabalho braçal de escrever milharesde linhas simplesmente para criar uma tela ou o layout de um relatório.

Um dia, porém, resolvi criar alguns programas para facilitar minhavida de programador. Com um formulário na tela, eu preenchia o nomedos 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 textoseria posicionado), o nome da variável que receberia o conteúdo, seutamanho e outas informações. E, depois de compilar e executar o pro-grama, se algum item ficasse fora da posição adequada, era necessárioalterar o código fonte e recompilar todo o sistema.

Na primeira versão das minhas rotinas criadoras de código euprecisava editar a posição do campo na tela e recompilar; no aprimora-










































4 INTRODUÇÃO

mento da rotina, criei um banco de dados que armazenava todas essasinformações, de modo que o sistema não precisasse ser recompilado. Aoser 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 aexecução dos programas em Clipper ainda era em uma janela DOS.

As linguagens que rodavam em DOS começaram a enfrentar umanova realidade. Para os usuários, o ambiente gráfico era muito maisagradável de se trabalhar. O mouse e o cursor foram ganhando muitos

adeptos; a famosa tecla Tab, usada para saltar o foco de um componentepara 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 oWindows um ambiente de desenvolvimento que fosse atraente para osdesenvolvedores.

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, naqual o desenvolvedor criava objetos ou entidades uma única vez e depoispodia modificar suas características e alterar seu comportamento. Porexemplo, se um campo tivesse um valor negativo, sua cor de exibiçãoseria vermelha. Em programação convencional seriam necessárias variaslinhas 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 objetosbastaria informar que o atributo “cor” do objeto seria vermelho caso ovalor fosse negativo.

Essa mudança começou a criar dificuldades para muitos desenvol-vedores. Quando chegou o ambiente gráfico, o desenvolvedor, além daorientaçã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 barrade ferramentas do ambiente, clicar sobre a área de trabalho e simples-mente escrever o nome do campo que, em menos de um segundo, todasas consistências necessárias estavam prontas e funcionando. O tempo











































de desenvolvimento de uma tela de entrada de dados caia mais de dezvezes se comparada às linguagens procedurais.

Os mais conservadores abominavam esse ambiente. Um clima de

insegurança se abatia sobre os programadores que, orgulhosos, de seutrabalho braçal, assumiam a propriedade ciumenta do código de umaaplicação.

Sem ter o controle do código, eles não tinham mais a sensação depropriedade, e essa insegurança começou a se espalhar de forma veladapela comunidade de desenvolvimento. Ainda hoje, dez anos depois nonovo século, muitos desenvolvedores ainda resistem aos novos ambientesde desenvolvimento.

Felizmente, ou infelizmente para eles, chegou um ponto em quea troca do parque instalado de hardware e as novas versões de sistemaoperacional eliminaram de vez a possibilidade de manter as antigaslinguagens e ferramentas de desenvolvimento.

As linguagens tradicionais, como o C e o Basic, ganharam versõesvisuais, que utilizavam a plataforma gráfica para o desenvolvimento, masainda exigiam do programador a codificação de milhares e milhares delinhas 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 àsaplicações.

Embora as ferramentas tenham facilitado o desenvolvimento, amaioria delas incorria na necessidade de se trabalhar em algum momen-to o código gerado por ela. Ou seja, o desenvolvedor precisava continuarsendo 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 eraproprietário, exclusivo de um fabricante ou outro, passou a fazer partede um ativo comum da humanidade.

Um sistema que rode num navegador rompe as barreiras físicase elimina as dificuldades de implementação devido a diferenças desistemas operacionais ou de hardware utilizados pelos usuários. Com ainternet, além de todas as mudanças, o desenvolvedor tinha de aprendernovas ferramentas ou protocolos para integrar à sua aplicação.

Vi muitas grandes empresas, bem estabelecidas em seus ambientestradicionais, enfrentarem grandes dificuldades para migrar suas aplica-










































6 INTRODUÇÃO

ções para a internet. Verdadeiras colchas de retalhos eram criadas para seconseguir 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 focode seu trabalho deixou de ser a programação e passou a ser a soluçãodos desafios propostos.

Surge aí um novo profissional, que prefiro chamar de analista denegócios, um profissional técnico com visão de negócios.

Num mercado extremamente competitivo, onde custos e prazossão cada vez menores, as empresas precisam dispor de ferramentas e

profissionais capazes de entregar as soluções nos prazos e orçamentospropostos, e tudo isso com um nível de exigência do usuário cada vezmaior.

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 funcionalidadedo 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 feitascom o intuito de utilizar plataformas de desenvolvimento e execuçãoque sejam rápidas e de baixo custo.

Nesse contexto de mudanças, vi surgir uma ferramenta que, paramim, conseguiu reunir como nenhuma outra características únicaspara 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, deum 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 emque linguagem ele irá compilar a aplicação. E quando ouve a resposta- “Em qual você quer?” -, a desconfiança aumenta. Mas basta sentar-sediante do micro e olhar as características do programa para constatarque, sim, isso é possível.
















































“Mas onde eu escrevo o código?” Aí é que está a grande mudançade paradigma do Maker: não precisa escrever nenhum código. Toda aparte de entrada de dados, de consultas e de relatórios é feita pela in-

terface gráfica, algo que a maioria das ferramentas de desenvolvimentopossui. Utilizando um recurso chamado Fluxos, o desenvolvedor escrevea 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 osalgoritmos serão escritos de forma visual.

Finalizado o fluxo, a aplicação é montada para ser rodada em umnavegador. 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, quecobrem boa parte das necessidades de desenvolvimento, mas rotinasmuito específicas já criadas pelo desenvolvedor podem ser facilmenteincorporadas ao sistema, preservando investimentos já feitos.

O Maker é o verdadeiro nirvana dos desenvolvedores. Dois diasde contato intenso com ele fizeram-me ver o quanto essa ferramentapode impactar positivamente o tempo de desenvolvimento de sistemascriados para serem usados por meio de um navegador. Sua integração

com e-mail e outros sites da internet permite a criação de sistemasabsolutamente atuais, que integram o dia a dia dos usuários cada vezmais conectados com suas atividades diárias.

Para mim, que posso me considerar um verdadeiro dinossauro nahistória da informática, o Maker conseguiu reunir o que há de melhorpara o desenvolvimento de sistemas, e tudo isso sem limitar o desenvol-vedor a nenhum tipo de linguagem ou ambiente operacional.

José Antonio RamalhoEscritor e autor de mais de 108 livros. Nessa coleção de livros escritospor ele encontram-se obras voltadas para bancos de dados e linguagensde programação. Com uma vasta experiência em desenvolvimento de

softwares, Ramalho acompanhou todo o processo de evolução daslinguagens 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.









































2o 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çãosucinta do ambiente, apresentando suas principais funcionalidades eseus benefícios.

Tradicionalmente, IDEs (Integrated Development Environment)são ferramentas cujo objetivo é agilizar o processo de desenvolvimentode softwares, porém só são utilizadas na etapa de codificação ou deescrita do software. O Maker pode ser definido como uma plataformapara 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 etapasdo processo de desenvolvimento, desde a documentação e elicitação decasos de uso até a codificação e manutenção que serão realizadas naplataforma. Com isso, nota-se que o paradigma que o define e maisse aproxima do seu formato de codificação é o Desenvolvimento deSoftware Orientado a Negócios, segundo o qual o foco do processode desenvolvimento é o resultado. As tecnologias, como as linguagens,são meros instrumentos utilizados para materializar o negócio em umasolução computacional.






























10 O MAKER: DESCR IÇÃO DO AMBIENTE

Uma característica muito importante e inovadora é o fato de aferramenta possuir uma linguagem de programação visual, que são osfluxogramas, representando uma evolução no formato da escrita de

algoritmos, pois até então era utilizado um padrão textual para a escritade 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 linguagemde programação visual, em que algoritmos são escritos visualmente, dissoadvindo muitas vantagens. Desse modo, é muito mais fácil capacitar umprofissional em uma linguagem visual, por exemplo, do que em umasintaxe tradicional escrita, pois os algoritmos escritos em fluxos são en-tendidos facilmente e, em consequência, são mais fáceis de ser mantidosque aqueles escritos em uma linguagem tradicional, que não são nadaintuitivos. A Figura 2.1 a seguir ilustra a sintaxe dos fluxogramas.

Todas as notações já conhecidas das linguagens de programaçãotradicionais, como desvios, laços, condicionais, comentários, passagemde 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 equalquer 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, bibliotecasmatemáticas, etc.) que fazem parte de um pacote interno do Maker.

figurA 2.1 A sintaxe dosfluxogramas.






































Considere, por exemplo, um algoritmo que verifica se um clienteé maior de idade. A Figura 2.2 a seguir ilustra o algoritmo escrito nalinguagem 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.

Outra característica importante é o fato de o Maker implementar oconceito de independência tecnológica, ou seja, em tese, um código es-

crito em Maker poderá ser executado em qualquer arquitetura-alvo, pois oalgoritmo implementado não depende da plataforma de execução (atual-mente, as tecnologias suportadas para execução são Java e .Net). De modosimilar, a aplicação também independe do banco de dados, sendo possívelsubstituí-lo em qualquer tempo do ciclo de vida do software. É interessanteressaltar que a ferramenta sempre proporciona ao programador todo opoder necessário para que ele possa expressar sua criatividade e exercitarseu 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.

figurA 2.2 Algoritmoque verificase um clienteé maior deidade, escritona linguagemPL-SQL.

figurA 2.3

Algoritmoque verificase um cliente

é maior deidade, escritoem Maker.







































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

representa esta situação.

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 executadano processamento “Carrega dados da Tabela de Origem” percebe-se umaoperação de atribuição a uma variável chamada Tabela de uma funçãointitulada Abrir consulta. A Figura 2.5 a seguir ilustra o que foi descrito.

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

figurA 2.4

Algoritmopara efetuarumamigração dedados.

figurA 2.5

Rrepresentação

de um fluxocom chamadasa fluxosexternos emalgoritmo paraefetuar umamigração dedados.


































Em geral o Maker é confundido com diversos produtos, comogerador de códigos, ferramenta Case, Framework, ferramenta de gestãode processos (pelo fato de usar a mesma notação de fluxogramas). De

fato, o produto não é nenhuma das ferramentas citadas, mas, sim, umaplataforma para o desenvolvimento de aplicações com alto grau deintegraçã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 quepossui 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, decompilação do software na arquitetura-alvo escolhida, de registrode Log de auditoria para transações na aplicação, etc. Para executarsob regime de publicação, o Webrun é acoplado ao software escrito emMaker, de modo que ambos integram um único pacote de publicação,

constituindo então um único produto. A Figura 2.6 a seguir ilustra omecanismo de funcionamento do Webrun.

Após o acoplamento ou a compilação, o que se tem é o ilustradono lado direito da Figura 2.6.

No controle de autenticação e autorização, o Webrun dispõe deum mecanismo robusto, em que as unidades mais atômicas dos sistemas(os componentes) podem ser controladas, e permissões serão atribuídasou negadas. Nesse processo, são contemplados Menus, Submenus

figurA 2.6

Mecanismo defuncionamentodo Webrun.


































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

O Webrun também implementa um robusto controle de Log paratodas as transações efetuadas no sistema. Ou seja, todo o Log de auditoriavem 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.7

Interfacede confi-guração decontrole depermissões.

figurA 2.8

Log deauditoria.






















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 administradoresdo sistema.

É interessante ressaltar que uma aplicação escrita em Maker éexecutada em uma robusta arquitetura de camadas, de forma que todosos conceitos de execução de aplicações Web, como balanceamento decarga, escalabilidade, clusterização, etc., são aplicáveis ao softwaredesenvolvido em Maker.

2.4 interfAce de formuláriosPara a construção de formulários, o Maker dispõe de um meca-

nismo visual de componentes, em que objetos poderão ser dispostosem qualquer parte do formulário, bastando clicar e arrastá-los para aposiçã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 possuimuita riqueza visual e facilidade de customização nesse aspecto, o quedá total poder ao programador para a criação de formulários com umalto grau de usabilidade sob o ponto de vista do usuário final. A Figura2.10 ilustra a criação de um formulário com o Maker.

figurA 2.9

Exemplode umaaplicaçãoescrita emMaker.


































2.5 mAker report

Assim como para a construção de formulários, o Maker dispõe deuma estrutura bastante intuitiva para se construir relatórios. Esse mó-dulo é denominado de Maker Report, uma ferramenta muito poderosapara se construir relatórios, que dispõe de muitos componentes, taiscomo: caixas de texto, códigos de barra, gráficos, referências cruzadas,

sub-relatórios, aba de dados, aba de cálculo, bandas de detalhe, cabe-çalho, rodapé, etc. (Ver Figura 2.11.)

figurA 2.10

Criaçãode um

formuláriocom o Maker.

figurA 2.11

MakerReport, umaestrutura paraa construção

de relatórios.

























Diante de todas as interfaces apresentadas e suas respectivas faci-lidades, nota-se o quanto é simples e produtivo utilizar o Maker. Porser uma ferramente muito intuitiva e utilizar linguagem de programa-

ção visual, a curva de aprendizado é extremamente baixa, e basta umtreinamento de 40 horas para capacitar profissionais de tecnologia a setornarem aptos a desenvolver aplicações em Maker.

2.6 AbstrAção no mAker

A produtividade alcançada no Maker é diretamente relacionada

ao alto poder de abstração que a ferramenta implementa, em que algu-mas etapas do processo de desenvolvimento são suprimidas e integradas.Sabemos que, em geral, a implementação de softwares segue algumametodologia de desenvolvimento; das metodologias disponíveis, algu-mas foram criadas com base em engenharias tradicionais, de modo que,para o desenvolvimento de um sistema, determinadas etapas precisamser cumpridas para a obtenção do sucesso no final do projeto. As eta-pas a serem cumpridas costumam ser oito (especificação de requisitos,

análise de requisitos, prototipação, modelagem, implementação, testes,homologação e implantação), sempre feitas em ferramentas distintas,o que torna muito moroso manter um projeto a partir desta abordagemtradicional, pois sempre que se muda um requisito torna-se bem difícildimensionar seu impacto nas etapas subsequentes. A utilização de umaúnica ferramenta, ou seja, de uma plataforma, garante total segurançaem mudanças, uma vez que os impactos estarão automaticamentemapeados. Com a utilização do Maker, o desenvolvedor perceberá a

aglutinação de algumas etapas, pois, por meio de abstração, ele permite,por exemplo, que se faça prototipagem, modelagem e implementaçãode uma só vez. Quando se cria um formulário em Maker, automatica-mente se obtém protótipo, modelo de dados e implementações básicasdeste formulário (inclusão, exclusão e consulta a registros). As Figuras2.12 e 2.13 mostram melhor essa integração.

Na Figura 2.13, a seguir, percebe-se de forma bem clara como oMaker ajuda a reduzir o tempo de desenvolvimento de softwares. Elasimboliza o mecanismo de criação automática do modelo de dados, noqual o Maker cria de uma só vez protótipo, modelo e implementação.








































Outro recurso bem inovador da ferramenta é o repositório defuncionalidades, que permite o reaproveitamente de tudo o que seconstrói em Maker. Em projetos de software, é comum ter de refazerfuncionalidades, seja por falta de organização, de documentação ou decompatibilidade entre tecnologias. Com o recurso de repositório, aliado

à abstração, o reaproveitamento de funcionalidades se dá de forma trans-parente, ou seja, para reaproveitar alguma funcionalidade (formulário,

figurA 2.12

Exemplo deintegração

em Maker.

figurA 2.13

Mecanismode criaçãoautomáticado modelo

de dados emMaker.
























fluxo ou relatório) escrita em Maker, basta clicar nela e arrastá-la parao projeto, que, de uma forma visual, o reaproveitamento acontecerá. AFigura 2.14 ilustra este recurso.

2.7 rAstreAbilidAde

Um problema clássico em projetos de software é a falta de docu-mentação e a consequente falta de rastreabilidade entre as funcionalida-

des implementadas. Este problema também é agravado pela quantidadeexcessiva de ferramentas utilizadas em um processo tradicional de desen-volvimento, sendo muito comum efetuar uma correção em um trechode software e esta implicar diversos erros no projeto como um todo. OMaker dispõe de um mecanismo capaz de monitorar as funcionalidadese de apresentar todas suas interdependências; com isso, no momento dese fazer a correção ou a alteração de alguma funcionalidade, este módulomostrará o impacto causado ao longo do projeto, proporcionando mais

segurança e maturidade às manutenções implementadas. A Figura 2.15ilustra este recurso

A figura mostra, na coluna à esquerda, uma relação de todas fun-cionalidades escritas no Maker; na coluna central, os objetos dos quaiso objeto analisado depende, ou seja, é mostrada uma dependência des-cendente da funcionalidade analisada; e na coluna à direita, os objetosque dependem da funcionalidade analisada, isto é, uma dependênciaascendente. Trata-se de um poderoso recurso que, sem dúvida nenhu-ma, facilitará bastante a vida dos desenvolvedores em momentos demanutenções nos sistemas.

figurA 2.14

Repositóriode funcionali-dades.


































2.8 depurAdor VisuAl

Ainda quanto a aspectos de manutenção em softwares, é funda-

mental e necessário haver um mecanismo de depuração eficiente eem total sinergia com os recursos de abstração implementados peloMaker. Para uma linguagem de programação visual, o mais trivial éque se tenha um depurador visual, e o que há de mais interessanteneste é sua capacidade de depurar códigos (fluxogramas) compilados

tanto para a camada Cliente quanto para a camada servidor, de for-ma a abstrair este detalhe do desenvolvedor. Todos os conceitos dosdepuradores tradicionais, como BreakPoints, Concluir Regra, Saltar

Processamento, Sair da Regra, Pausar a Regra, são implementados coma principal vantagem da depuração nas camadas cliente e servidor.

Todas as Variáveis declaradas nos fluxogramas poderão ser acessadas ealteradas pelo Depurador, que se mostra também um grande recursofacilitador em etapas de manutenções em sistemas. A Figura 2.16 ilustramelhor este mecanismo.

Observe que no código (fluxograma) ilustrado há uma figura que

representa um ponto de parada (BreakPoint) e, ao lado, tem-se umajanela com os valores das variáveis declaradas no fluxo depurado.

figurA 2.15

Visualizadorde depen-

dências doMaker.






























2.9 internAcionAlizAção dAs AplicAções

Com a disseminação do mundo virtual, cada vez mais as distân-cias estão se encurtando. As aplicações nas nuvens já são realidades, e

é preciso torná-las mais acessíveis. Para isso, a primeira barreira a sertransposta pelos fornecedores de sistemas é o idioma em que tal apli-cação será executada; sistemas multilinguagem precisam ser ofertadospara estar em total sinergia com clientes espalhados no mundo todo.Internacionalizar softwares é uma tarefa dispendiosa, que requer mui-to tempo para a codificação de mecanismos capazes de executar umsistema fora de seu idioma-padrão. No Maker, esta tarefa é muito fácil,pois basta executar o módulo de internacionalização e o software, au-

tomaticamente, estará pronto para ser executado no idioma escolhido.Também neste caso o Maker faz uso da abstração para facilitar esta

figurA 2.16

Exemplo dedepuração de

um fluxo.
























tarefa ao desenvolvedor, que não precisará escrever nenhum código,regra, fluxograma ou algoritmo para transcrever uma aplicação Makerpara outros idiomas. A Figura 2.17 ilustra este módulo.

Algumas palavras, como se pode notar, não possuem traduçãofidedigna; nesses casos, quando o dicionário do tradutor não tiver con-seguido traduzir, a tradução manual do termo terá de ser feita.

2.10 gAp semântico

O Maker ajuda a reduzir outro problema clássico em projetos de

desenvolvimento de software, que é o gap semântico, ou seja, o hiatoexistente entre a solução que foi implementada e a que o cliente defato esperava. Essa situação acontece porque nenhum dos envolvidosno processo de desenvolvimento fala a mesma língua, ou seja, o usuá-rio só entende de negócios, o especialista de domínio só entende demodelagem e o programador só entende de tecnologia. O Maker, porutilizar uma notação universal, que são os fluxogramas, reduz distân-cias, permitindo que os softwares implementados sejam mais precisose conformes ao que foi solicitado. A Figura 2.18 ilustra bem esta linhade raciocínio.

figurA 2.17

Tabela detradução deexpressõesdo sistemapara outrosidiomas.































2.11 profiler

Sempre que se constrói uma aplicação incorre-se em alguns pro-blemas de performance, e identificá-los nem sempre é algo simples dese fazer. Os problemas mais comuns são algoritmos malfeitos, muitoslaços aninhados, drivers de conexões lentos, SGBDs com altos tempos

de respostas, etc. O Maker possui um mecanismo (Profiler) que ajudaa identificar pontos de gargalo e lentidão nas aplicações e se mostramuito eficiente quando estas precisam ser customizadas e evoluídas,principalmente quanto a performance. A Figura 2.19 ilustra tal módulo.

figurA 2.18

Com oMaker, os

softwaresimplementa-dos são maisprecisos econformesao que foisolicitado.

figurA 2.19

O Profiler éeficiente na

customizaçãode aplica-ções relati-vamente aperformance.

































2.12 documentAção

A falta de uma documentação clara, concisa e atualizada é outra

barreira a ser quebrada em projetos de software. Estatísticas mostramque mais de 90% das aplicações criadas não são documentadas ou adocumentação existente está completamente desatualizada. Para sanareste problema, o Maker se vale de um mecanismo automatizado dedocumentação que utiliza engenharia reversa. A ferramenta cria ummodelo de documentação capaz de esclarecer todas as característicasrelevantes do software com um padrão extremamente simples e de fácilcompreensão, o que, certamente, reforça a necessidade de menos ma-

nutenção em softwares escritos em Maker, pois sempre se tem a garantiade que estão documentados.

figurA 2.20

Cadastro dedados geraisda docu-mentação do

sistema.























3 Apl icAção exemplo

3.1 definição e tecnologiAs utilizAdAs

A aplicação que construiremos no decorrer deste livro será umaagenda de contatos, cuja finalidade é permitir o envio de correspondên-

cias sob a forma de e-mails, cartas e contatos telefônicos.Para a construção dessa agenda utilizaremos a IDE Maker, versão2.6, e o banco de dados PostgreSQL, versão 8.2. Trata-se de um sistemade agenda pessoal que permitirá a cada usuário gerir sua própria agendamediante consultas em tela e relatórios. A aplicação será autenticada pormeio de login e senha, o que garantirá que apenas pessoas autorizadaspoderão visualizar as informações dos contatos.

A aplicação terá recursos interessantes de interatividade com os

contatos, como localização geográfica do contato e cadastro de obser-vações. Será gerado um histórico de todas as interações realizadas comcada contato, o qual poderá ser visualizado em um relatório.

3.2 descrição dos recursose modelo de dAdos

O sistema é composto de sete tabelas: Contato, Endereço, Cate-goria, Cidade, Estado, Observação e Parâmetro. A tabela Contato é a























26 APL ICAÇÃO EXEMPLO

principal entidade do sistema, visto que toda a lógica da aplicação sebaseia nela.

Ao cadastrar um contato, o usuário terá de informar de que cidade

ele é e sua categoria. São informações importantes para a retirada de rela-tórios, que também podem servir para gerar gráficos e dados sumarizados.

No processo de cadastramento, o usuário estará manipulando astabelas Endereço e Contato, já que todos os dados relacionados a ende-reço estão separados em outra tabela, até mesmo a cidade, comentadano parágrafo anterior. Este processo é transparente para o usuário, poiso Maker dispõe de componentes para ocultar as operações que lhe

sejam indiferentes.Também faz parte do endereço o Estado em que o contato reside,

mas essa informação não está diretamente ligada à tabela Endereço esim à Cidade, visto que toda cidade pertence ao um Estado. Assim, parasaber o Estado de um contato basta saber a cidade em que ele reside.

Toda interação feita com o contato é armazenada na tabelaObservação, e todo registro nessa tabela possui a informação de qualcontato o originou. A tabela Observação também possui um campo paraidentificar o tipo de interação registrada, como um e-mail enviado ouuma observação adicionada.

A única entidade que não possui relacionamento direto com atabela Contato é a tabela Parâmetro, que armazena informações sistê-micas, como configuração de e-mail e de Twitter. A Figura 3.1 ilustra omodelo de dados da aplicação que será construída no decorrer do livro.

figurA 3.1

Modelo dedados daagenda decontatosque seráconstruídano decorrer

deste livro.







































3.3 telAs do sistemA

A tela de Cadastro de Contatos é a principal funcionalidade do

sistema. Composta por três abas (Cadastro, Endereço e Localizar), é atela que possui o maior número de informações. Esta tela terá camposcomo nome, telefone, e-mail, foto, endereço, entre outros. A Figura 3.2ilustra a aba Cadastro do formulário Contato.

Oriundo da tabela Endereço, os dados do endereço do contato sãoexibidos na aba Endereço, conforme ilustrado na Figura 3.3.

figurA 3.2

Aba Cadastrodo formulário

Contato.

figurA 3.3

Dados do

endereçoda tabelaEndereço.























Na aplicação estará disponível a funcionalidade de geolocalização,e tomaremos como base o endereço do contato para ilustrar esse recurso,que será encontrado na tela de contatos. O usuário poderá visualizar

o endereço do contato por meio de um mapa, conforme ilustrado naFigura 3.4.

A aplicação irá disponibilizar o recurso de envio de e-mail comoforma de comunicação com o usuário, por esse motivo existe o campopara registrar o endereço de e-mail do contato.

Todo e-mail enviado a partir da aplicação é armazenado no banco

de dados e pode ser posteriormente recuperado. A funcionalidade consiste de uma tela de envio de e-mail comos recursos mais importantes utilizados em um Webmail. Essa telapermitirá o envio de e-mails com anexos, uma vez que é possível enviararquivos para o servidor e depois recuperá-los (baixá-los). A Figura 3.5ilustra a tela de envio de e-mail.

A aplicação irá dispor de relatórios que ajudarão o usuário a gerirseus contatos. Um desses relatórios é a Lista de Contatos, que apre-

sentará todos os contatos cadastrados no sistema, como ilustrados naFigura 3.6.

figurA 3.4

Mapa dispo-nibilizadopela funcio-nalidade degeolocaliza-ção.
































Ainda estarão disponíveis na aplicação mais três tipos de relatórioenvolvendo os contatos e suas ações dentro do sistema: relatório decontatos por categoria, relatório diário das ações/interações realizadaspelo usuário e histórico de cada contato.

3.4 cenário exemplo

Ao longo deste livro construíremos, como exemplo, um pequenocenário, o qual exploraremos de forma didática, construindo regras denegócios mais simples, sem interferir na aplicação. Para aprender o con-ceito de fluxograma, trabalharemos com esse cenário, que é constituídode duas tabelas interligadas (Funcionário e Departamento), no qual

iremos realizar operações básicas, e, dessa forma, não comprometere-mos nossa aplicação. Esse cenário encontra-se ilustrado na Figura 3.7.

figurA 3.5

Tela de enviode e-mail.

figurA 3.6

Relatório deContatos.
























O capítulo que acabamos de ver aborda as características daaplicação-exemplo que será construída ao longo deste livro. Todos osrequisitos são apresentados e seu escopo é definido. O capítulo abordadesde a modelagem de dados até a interface final com usuário. Sãoapresentados relatórios e telas que transmitem uma noção do que seráa aplicação.

figurA 3.7

Tabelasinterligadas

do cená-rio-exemplo.
















MAKER Uma introdução ao ambiente

visual de desenvolvimento

COMPRE AGORA

Compre o livro MAKER. Acesse o link abaixo e faça o seu pedido.









Documents

LivroMaker