Liv Ro Maker

MAKERUma introdução ao ambientevisual 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

MAKERUma 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

o andar

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

Rua Quintana, 753 – 8o andar

04569-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 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 assu mem 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ê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

AgrAdec imentos

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

vi i i ÍND ICE

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 Cidade . . . . . . . . . . . . . . . . . . 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 Parâmetro. . . . . . . . . . . . . 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 exemplo . . . . . . . . . . . . . . . . . 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 5.4.5 Associando fluxo ao formulário . . . . . . . . . . . 80

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

5.5 Construção do fluxo de interação com objetos . . . . . 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 E-mail . . . . . . . . . . . . . . . . . . . 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 JAR . . . . . . . . . . . . . . . . . . . . . 145 8.4 Assistente de atualizações e configurações . . . . . . . . 147

x ÍND ICE

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 texto . . . . . . . . . . . . . . . . . . . . 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 objetos . . . . . . . . . . . . 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 acesso . . . . . . . . . . . . . . . . . . . . 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

1introduçãoPor 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

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

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

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

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


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

çõ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.


“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 RamalhoEscritor 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.

2o mAker: descr içã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 : DESCR IÇÃO DO AMB IENTE

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.

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.

figurA 2.1 A sintaxe dos fluxogramas.


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

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

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


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.

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.

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

figurA 2.4 Algoritmo para efetuar uma migração de dados.

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


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.

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

figurA 2.6 Mecanismo de funcionamento do Webrun.


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

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.7 Interface de confi-guração de controle de permissões.

figurA 2.8 Log de auditoria.


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.

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.

figurA 2.9 Exemplo de uma aplicação escrita em Maker.


2.5 mAker report

Assim como para a construção de formulários, o Maker dispõe de uma estrutura bastante intuitiva para se construir relatórios. Esse mó-dulo é denominado de Maker Report, uma ferramenta muito poderosa para se construir relatórios, que dispõe de muitos componentes, tais como: 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ção de um formulário com o Maker.

figurA 2.11 Maker Report, uma estrutura para a 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. Por ser uma ferramente muito intuitiva e utilizar linguagem de programa-ção visual, a curva de aprendizado é extremamente baixa, e basta um treinamento de 40 horas para capacitar profissionais de tecnologia a se tornarem 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 alguma metodologia 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 precisam ser 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 abordagem tradicional, pois sempre que se muda um requisito torna-se bem difícil dimensionar seu impacto nas etapas subsequentes. A utilização de uma única ferramenta, ou seja, de uma plataforma, garante total segurança em mudanças, uma vez que os impactos estarão automaticamente mapeados. 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ção de 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ásicas deste formulário (inclusão, exclusão e consulta a registros). As Figuras 2.12 e 2.13 mostram melhor essa integração.

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


Outro recurso bem inovador da ferramenta é o repositório de funcionalidades, que permite o reaproveitamente de tudo o que se constrói em Maker. Em projetos de software, é comum ter de refazer funcionalidades, seja por falta de organização, de documentação ou de compatibilidade 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 de integração em Maker.

figurA 2.13 Mecanismo de criação automática do modelo de dados em Maker.


fluxo ou relatório) escrita em Maker, basta clicar nela e arrastá-la para o projeto, que, de uma forma visual, o reaproveitamento acontecerá. A Figura 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 quantidade excessiva de ferramentas utilizadas em um processo tradicional de desen-volvimento, sendo muito comum efetuar uma correção em um trecho de software e esta implicar diversos erros no projeto como um todo. O Maker dispõe de um mecanismo capaz de monitorar as funcionalidades e de apresentar todas suas interdependências; com isso, no momento de se fazer a correção ou a alteração de alguma funcionalidade, este módulo mostrará o impacto causado ao longo do projeto, proporcionando mais segurança e maturidade às manutenções implementadas. A Figura 2.15 ilustra este recurso

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

figurA 2.14 Repositório de 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 e em total sinergia com os recursos de abstração implementados pelo Maker. Para uma linguagem de programação visual, o mais trivial é que se tenha um depurador visual, e o que há de mais interessante neste é 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 dos depuradores tradicionais, como BreakPoints, Concluir Regra, Saltar Processamento, Sair da Regra, Pausar a Regra, são implementados com a principal vantagem da depuração nas camadas cliente e servidor. Todas as Variáveis declaradas nos fluxogramas poderão ser acessadas e alteradas pelo Depurador, que se mostra também um grande recurso facilitador em etapas de manutenções em sistemas. A Figura 2.16 ilustra melhor este mecanismo.

Observe que no código (fluxograma) ilustrado há uma figura que representa um ponto de parada (BreakPoint) e, ao lado, tem-se uma janela com os valores das variáveis declaradas no fluxo depurado.

figurA 2.15 Visualizador de depen-dências do Maker.


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 ser transposta pelos fornecedores de sistemas é o idioma em que tal apli-cação será executada; sistemas multilinguagem precisam ser ofertados para 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 um sistema 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 de depuração de um fluxo.


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

Algumas palavras, como se pode notar, não possuem tradução fidedigna; 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 hiato existente entre a solução que foi implementada e a que o cliente de fato esperava. Essa situação acontece porque nenhum dos envolvidos no 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 de modelagem e o programador só entende de tecnologia. O Maker, por utilizar uma notação universal, que são os fluxogramas, reduz distân-cias, permitindo que os softwares implementados sejam mais precisos e conformes ao que foi solicitado. A Figura 2.18 ilustra bem esta linha de raciocínio.

figurA 2.17 Tabela de tradução de expressões do sistema para outros idiomas.


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 de se fazer. Os problemas mais comuns são algoritmos malfeitos, muitos laços aninhados, drivers de conexões lentos, SGBDs com altos tempos de respostas, etc. O Maker possui um mecanismo (Profiler) que ajuda a identificar pontos de gargalo e lentidão nas aplicações e se mostra muito 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 o Maker, os softwares implementa-dos são mais precisos e conformes ao que foi solicitado.

figurA 2.19 O Profiler é eficiente na customização de aplica-ções relati-vamente a performance.


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 mostram que mais de 90% das aplicações criadas não são documentadas ou a documentação existente está completamente desatualizada. Para sanar este problema, o Maker se vale de um mecanismo automatizado de documentação que utiliza engenharia reversa. A ferramenta cria um modelo de documentação capaz de esclarecer todas as características relevantes do software com um padrão extremamente simples e de fácil compreensão, o que, certamente, reforça a necessidade de menos ma-nutenção em softwares escritos em Maker, pois sempre se tem a garantia de que estão documentados.

figurA 2.20 Cadastro de dados gerais da docu-mentação do sistema.

3AplicAção exemplo

3.1 definição e tecnologiAs utilizAdAs

A aplicação que construiremos no decorrer deste livro será uma agenda 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ão 2.6, e o banco de dados PostgreSQL, versão 8.2. Trata-se de um sistema de agenda pessoal que permitirá a cada usuário gerir sua própria agenda mediante consultas em tela e relatórios. A aplicação será autenticada por meio de login e senha, o que garantirá que apenas pessoas autorizadas poderã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 com cada contato, o qual poderá ser visualizado em um relatório.

3.2 descrição dos recursos e 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 se baseia 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 as tabelas Endereço e Contato, já que todos os dados relacionados a ende-reço estão separados em outra tabela, até mesmo a cidade, comentada no parágrafo anterior. Este processo é transparente para o usuário, pois o 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 e sim à Cidade, visto que toda cidade pertence ao um Estado. Assim, para saber o Estado de um contato basta saber a cidade em que ele reside.

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

A única entidade que não possui relacionamento direto com a tabela 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 o modelo de dados da aplicação que será construída no decorrer do livro.

figurA 3.1 Modelo de dados da agenda de contatos que será construída no 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), é a tela que possui o maior número de informações. Esta tela terá campos como nome, telefone, e-mail, foto, endereço, entre outros. A Figura 3.2 ilustra a aba Cadastro do formulário Contato.

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

figurA 3.2 Aba Cadastro do formulário Contato.

figurA 3.3 Dados do endereço da tabela Endereç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 na Figura 3.4.

A aplicação irá disponibilizar o recurso de envio de e-mail como forma de comunicação com o usuário, por esse motivo existe o campo para 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 com os recursos mais importantes utilizados em um Webmail. Essa tela permitirá o envio de e-mails com anexos, uma vez que é possível enviar arquivos para o servidor e depois recuperá-los (baixá-los). A Figura 3.5 ilustra a tela de envio de e-mail.

A aplicação irá dispor de relatórios que ajudarão o usuário a gerir seus contatos. Um desses relatórios é a Lista de Contatos, que apre-sentará todos os contatos cadastrados no sistema, como ilustrados na Figura 3.6.

figurA 3.4 Mapa dispo-nibilizado pela funcio-nalidade de geolocaliza-ção.


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

3.4 cenário exemplo

Ao longo deste livro construíremos, como exemplo, um pequeno cenário, o qual exploraremos de forma didática, construindo regras de negócios mais simples, sem interferir na aplicação. Para aprender o con-ceito de fluxograma, trabalharemos com esse cenário, que é constituído de 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 envio de e-mail.

figurA 3.6 Relatório de Contatos.


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

figurA 3.7 Tabelas interligadas do cená-rio-exemplo.

MAKERUma introdução ao ambientevisual de desenvolvimento

COMPRE AGORA

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



Documents

Liv Ro Maker