Seguem algumas dicas para uma boa documentação de um fluxo

1 – Uso do objeto Comentário.

Este objeto não existe apenas para enfeite. Faça bom uso dele.

1.1 – Utilize-o para explicar a lógica usada na sua regra. Lembre-se que ninguém pensa igual, se a sua regra é complexa, utilize um objeto Comentário e explique resumidamente a lógica utilizada, assim quando outro desenvolvedor for dar manutenção no seu fluxograma ele conseguirá entender mais facilmente a lógica utilizada.

1.2 – Outro uso importante para este objeto é o detalhamento dos parâmetros de entrada e retornos do fluxo, usando um logo após o Início do fluxo explicando quais são os parâmetros de entrada e outro antes do Fim, detalhando o que é retornado.

1.3 – O Comentário também pode ser usado nas saídas de decisões para informar a ação a ser executada após o resultado daquela decisão.

2 – Documentando um objeto Processamento.

Não devem ser poupadas informações. Mas também não precisa escrever um livro dentro de um processamento, seja simples, mas completo. Seu processamento abre uma consulta em uma tabela? Não escreva simplesmente “Abrir Consulta”. Detalhe o processo, informe em qual tabela está sendo feita a consulta, qual o filtro usado nela. Está enviando um email? Não escreva simplesmente “Enviar Email”, informe qual será o destinatário, qual o objetivo do envio daquele email.

2 –Documentando um objeto Decisão.

Toda decisão é um questionamento, lembre-se disso quando for documentar este objeto. Escreva perguntas.

3 – Documentando um objeto Interação.

A interação é usada na maioria das vezes para exibição de mensagens de alerta ou de erro para o usuário. Comece escrevendo qual o tipo de mensagem usado, depois a própria mensagem.

4 – Nomes de variáveis.

O Maker não tem uma sintaxe obrigatória para a definição de variáveis, então faça proveito disso e deixe-as bem legíveis.

5 – Salvando um fluxo.

5.1 – Utilize o espaço “Descrição” das propriedades do fluxo (menu Arquivo -> Propriedades ou CTRL + P) para informar o objetivo do fluxo. A diferença será percebida ao associar o fluxo a um evento, ou chama-lo como Subfluxo, pois a descrição da regra será mostrada, da mesma forma como uma função nativa do Maker.
5.2 – Separe os fluxos por categorias e informe qual o formulário onde ele será usado. Caso seja um sistema grande, separado em módulos, informe a qual módulo a regra pertence. Isso facilitará na pesquisa do fluxo.

6 – Organizando o fluxograma.

Mantenha o fluxo organizado, linhas retas, objetos alinhados e com tamanhos relativos às suas descrições. Um macete bastante útil é usar um objeto Comentário bem pequeno para melhorar o aspecto visual.

Seguindo essas dicas a documentação do seu fluxograma ficará muito mais organizada e completa. A equipe ganhará mais tempo na manutenção, até mesmo o próprio desenvolvedor do fluxograma será favorecido, quando precisar dar manutenção daqui a alguns dias, meses ou anos.

Lembre-se: o fluxograma não está ali apenas para você “programar”. Ele é muito mais que isso. Ele é o seu diferencial com o Maker. Ele é a aproximação do desenvolvedor com o cliente, com o usuário final. Ele é a documentação do seu software que será entregue ao seu cliente, já que funcionalidade de documentação automática do Maker gera imagens de todos os fluxos presentes no sistema. Já teve a experiência de entregar a um cliente a documentação de um sistema gerada pela documentação automática do Maker, com os fluxos todos bem limpos, organizados, com uma documentação satisfatória? Pense nisso quando for desenvolver um fluxograma a partir de agora.

A iniciativa, lançada às vésperas do Natal pelo governador Confúcio Moura, de Rondônia, visa, segundo ele, modernizar o sistema fiscal estadual, tornando-o mais eficiente e vantajoso para todos por reduzir carga tributária, aumentar a arrecadação, promover o nivelamento das condições de concorrência entre os estabelecimentos comerciais com a informatização e formalidade, bem como, combater a sonegação fiscal e melhorar o controle interno tributário.

O programa, que pretende servir de modelo para outros estados brasileiros, tem por objetivo incentivar a exigência da nota fiscal a cada compra, o que garantirá, segundo os cálculos do governo, a restituição de 20% do ICMS em prêmios à população que participará em sorteios de valores de R$ 5 a R$ 25 mil a cada compra a partir de R$ 100. Luís Fernando Pereira da Silva, coordenador da Secretaria Estadual de Finanças (Sefin) e responsável pelo “Nota Legal Rondoniense”, revela que a expectativa é que a partir de 15 de março de 2012, Dia Internacional dos Direitos do Consumidor, sejam feitos os primeiros sorteios mensais dos bilhetes referentes a compras a partir de R$ 100, enquanto a restituição dos 20% das demais compras será feita nos meses de abril e outubro de cada ano.

Ofensiva na área de governo

Com o contrato em Rondônia, a Softwell Solutions , considerada uma das empresas de Tecnologia da Informação (TI) mais inovadoras do Brasil, está colhendo os frutos de uma estratégia de ofensiva sobre o mercado deTI governamental, desenhado no inicio do ano.

Wellington Freire - CEO da Softwell

Outros contratos de peso foram fechados na área governamental com o Centro de Processamento de Dados de Mato Grosso (Cepromat) , a Companhia de Entrepostos e Armazens Gerais de São Paulo (Ceagesp), com a Agencia Estadual de Tecnologia da Informação de Pernambuco ( ATI) e até com a Prefeitura de Feira de Santana, onde está instalado um dos mais interessantes sistemas de Saúde Digital do Brasil, revela Wellington Freire, presidente da Softwell Solutions. “Também temos contratos menores, com vários outros órgãos governamentais e prefeituras brasileiras que revelam que a nossa plataforma Maker serve muito bem ao propósito dos governos que se propõem a fazer mais, em menos tempo e gastando menos”, comenta Freire, destacando o ganho em produtividade com os investimentos na plataforma de desenvolvimento de software, que agora também ganhou uma versão para dispositivos móveis (smartphones, tablets, etc.).

O uso das novas tecnologias de informação no âmbito das administrações públicas com o intuito de melhorar a prestação de serviços para a sociedade constitui o que se convencionou chamar de E-Governo, que compreende uma série de atividades que vão além da simples presença de unidades governamentais na rede para o oferecimento de diversos serviços à população. As inovações, as tecnologias e os instrumentos associados ao E-Gov pela baiana Softwell Solutions, acompanham as principais diretrizes norteadoras da reforma da administração pública no Brasil, em sintonia com as tendências internacionais abrigadas sob a denominação “nova gestão pública”, cuja finalidade principal é suprir as necessidades coletivas das populações.

O esforço da Softwell por ganhar tração na administração pública faz sentido: os governos, nos seus diferentes níveis – municipal, estadual e federal – respondem por cerca da metade dos gastos de TI no país, que em 2010 ficou em torno de R$ 100 bilhões segundo a consultoria Gartner, a mais respeitada do mundo na área de TI.

Matéria Publicada no tibahia.com

O Webrun possui em sua estrutura de arquivos, as pastas Resource e também a Skins e dentro dela a pasta Default, como podemos visualizar na imagem logo abaixo.

No interior destas pastas, o Webrun armazena todas as imagens que são utilizadas para montar layout dos sistemas que serão executados por aquele contexto. Para que o desenvolvedor altere o layout dos seus sistemas ele tem a opção de alterar as imagens originais por imagens que for da sua escolha, lembrando que os nomes e a extensão devem continuar os mesmos das imagens originais.

Para alterar o skin da aplicação, devemos observar que na pasta Resource contém todas as imagens compõem a tela de seleção de sistemas e na pasta Skins contém todas as imagens que compõem a área principal da aplicação e dos formulários.

Para alterar qualquer imagem, sugerimos que utilize uma ferramenta que identifique qual o nome daquela imagem.

Como exemplo, vamos inicialmente alterar a imagem de fundo da aplicação. Localize a imagem “enterprise.jpg” e substitua pela imagem desejada (lembre-se de manter o mesmo nome), esta imagem está na pasta Resource.

Tela principal sem modificações:

Tela principal após alteração:

Este procedimento modifica apenas a tela inicial do sistema.

Após ter logado no sistema, como dito anteriormente as imagens serão somente da pasta Skins, e então podemos começar alterar as imagens desta pasta, por exemplo, a imagem de background agora será a da pasta Skins, então é só ir até a pasta encontra-la e altera-la, lembrando, mantendo o mesmo nome sempre. A imagem de fundo terá o nome background_(versão do Webrun utilizada).jpg nesse caso background_enterprise.jpg trocando as imagens ficará assim.

Tela principal sem alterações:

Tela principal após alterações:

E o mesmo pode ser feito nos formulários de trabalho do seu sistema, os ícones da barra de navegação, por exemplo, podem ser alterados por ícones escolhidos pelo desenvolvedor, pois, todos são imagens se encontram na pasta Skins. Como podemos visualizar nas figuras a seguir.

Formulários com imagens padrão:

Formulários com imagens personalizada:

Depois de alterar as imagens é só parar o serviço do Webrun, apagar a pasta work e a pasta cacheCompressed do seu contexto, limpar o cache dos navegadores e iniciar o serviço novamente. Pronto, seu sistema já terá uma cara diferente.

Porém se houver a necessidade de republicar o seu contexto, você perderá todas as alterações realizadas, a não ser que copie a pasta Skins para outro local, republique o seu contexto e substitua a pasta atual pela copiada anteriormente. Só que este é um procedimento cansativo e repetitivo.

Um macete bem interessante é utilizar o recurso “Maker.Commons”, essa pasta foi desenvolvida para servir como um pasta espelho do seu contexto na hora da execução do sistema. O Servidor ao invés de procurar os arquivos no contexto, ele primeiro verifica se não existe na pasta Maker.Commons, lembrando que se o arquivo for para substituir algum arquivo do seu contexto deve ter a mesma assinatura, nome.extensão ex: background_enterprise.jpg
A grande vantagem de usar a pasta Maker.Commons é que se por um acaso o desenvolvedor trocar seu Webrun, por exemplo para uma versão mais nova, ou se tiver que republicar seu contexto não perderá seus arquivos modificados, é só manter seu contexto com o mesmo nome. Para maiores informações de como utilizar a pasta Maker.Commons acesse o manual online da softwell, disponível em http://suporte.softwell.com.br/maker/manual2_7/pt/dicas_e_truques/webrun/utilizacao_da_pasta_maker_commons.htm

E para aqueles que realmente querem desenvolver aplicações com design diferenciado, com o Maker e um pouco de criatividade pode-se desenvolver aplicações bastante personalizadas, definir formulário principal, importar bibliotecas de terceiros, Applets e muito mais, pronto agora é só usar a criatividade e correr para o abraço.

Aplicação criada com o Maker

O que é?

Uma Trigger é um bloco de comandos SQL que é automaticamente executado quando um comando INSERT, DELETE ou UPDATE é executado em uma tabela do banco de dados.

Por que são utilizadas?

As triggers são usadas para impor e manter a integridade referencial de baixo nível, o objetivo da mesma não é retornar resultados de consultas. A principal vantagem é que com a trigger podemos possuir lógica de processamento complexa.

As triggers podem ser utilizadas para atualizações e exclusões em cascata através de tabelas relacionadas em um banco de dados, definir mensagens de erro personalizadas, manter dados desnormalizados e fazer comparações de transações no banco de dados.

Partindo para a ideia e criando a trigger

Agora que já sabemos o que é uma trigger e onde utilizá-las, pensaremos no seguinte caso. Ao inserir ou excluir dados de uma determinada tabela, a trigger guardará em uma tabela de log as informações destas ações. Pronto, com a ideia em mente, partiremos para a parte prática, mão a obra!

Criando a trigger no Maker

Com base nas informações acima, nosso fluxo ficará da seguinte forma:

Adicione um objeto Processamento e no Montador de expressão selecione a função Executar Atualização:

Salve o fluxo na camada Banco de dados.

Selecionaremos o formulário onde será adicionado a trigger, neste caso o formulário de cadastro de produtos, e em seguida clicaremos em Definições.

Clique sobre o botão Associar ações à tabela, observe que será aberta uma tela onde serão exibidos todos os fluxos que foram salvos na camada banco de dados.

Clicaremos sobre o fluxo que será utilizado, neste exemplo “adicionar log” e logo após, sobre o botão compilar. Será gerado o script no banco de dados:

Em seguida, fecharemos a tela e clicaremos sobre a aba Eventos. Localizaremos o evento que disparará a trigger.

Como queremos criar um log para produtos inseridos, selecionaremos o evento Depois de Inserir.

Agora, informaremos a regra utilizada e clicaremos sobre o botão Adicionar.

Como nossa trigger, possui parâmetros de entrada, deveremos associá-los aos campos da tabela. Clicaremos sobre o campo “parâmetros” da grade de Eventos e executaremos os procedimentos demonstrados abaixo:

Associado os parâmetros aos campos, clicaremos sobre o botão OK e em seguida sobre o botão Compilar.

Observe que a nossa trigger foi criada e está pronta para ser utilizada.

Fecha a tela de Associação de ações, salve o formulário, execute-o no Webrun, insira um novo registro e observe que a trigger foi disparada criando um log do evento na tabela.

Pronto, agora sabemos como criar e utilizar uma trigger no Maker!

Um dos principais problemas ao desenvolver uma aplicação para o Mobile é justamente o cuidado ao gerar uma versão nova desta aplicação. Neste tópico iremos abordar alguns dos problemas mais freqüentes que podem ocorrer durante o processo de atualização de uma aplicação:

• Problemas com tabelas ou campos não encontrados no Simulador

Ao realizar uma alteração na estrutura do banco da aplicação é necessário gerar uma nova versão desta. Depois de gerar esta nova versão devemos sempre tomar o cuidado de limpar o banco de dados (no menu lateral do Simulador) pois quando abrimos uma aplicação nesta plataforma um arquivo com o banco (SQLite) da aplicação é criado, caso seja a primeira vez que o mesmo seja aberto, e ao abrir uma versão mais recente deste mesmo projeto não implica em recriar o banco novamente. Logo evitamos assim erros do tipo “tabela não encontrada” ou “campo não existe” durante a execução da aplicação. Abaixo segue um exemplo desse tipo de erro:

Neste caso uma tabela nova, MSE_TESTE, foi adicionada o projeto e o banco não foi recriado.

Este tipo de problema dificilmente ocorrerá nos dispositivos (smartphones e tablets) pois no caso deles a aplicação antiga geralmente é desinstalada antes que a nova seja instalada novamente no aparelho.

• Erro ao sincronizar após atualizar aplicação

Assim como no simulador foi necessário limpar o banco de dados para atualizar a sua estrutura, um procedimento semelhante deverá ser feito no Maker Mobile Manager antes de iniciar o sincronizador, devido à alteração realizada na estrutura do banco.

Neste caso devemos novamente baixar o arquivo de sincronização na tela Lista de projetos em compilação.
Selecione a versão mais recente do projeto na grade e clique no botão Sincronizador:

Ao baixar este arquivo, vá até o Maker Mobile Manager através do Webrun e carregue novamente o arquivo do sincronizador baixado anteriormente na tela Painel de configuração (caso tenha dúvida de como fazer este procedimento acesse este link).

Observe que depois de carregado este novo arquivo as tabelas que já foram criadas antes estarão marcadas no checkbox Existe, e as novas não estarão marcadas.

Marque a opção de criar as tabelas que ainda não existem no banco do Manager (ou remover alguma delas caso não exista mais). Depois de carregado as novas tabelas da aplicação no Manager, reinicie o serviço do Webrun e pronto, sua aplicação estará atualizada também para sincronizar.

Caso a alteração da estrutura do banco tenha sido apenas a criação ou remoção de algum campo de uma tabela já existente, remova a tabela alterada do manager e a crie novamente, marcando o checkbox Remover e depois Criar na linha da tabela que foi alterada.

Diferentemente do sub-tópico anterior, este é um problema que poderá acontecer em qualquer plataforma, pois o sincronizador tentará atualizar uma tabela no banco do Manager que ainda não existe.

Através de fluxogramas, editores visuais ao estilo WYSWYG (What You See Is What You Get) e outros artefatos, o Maker disponibiliza variados recursos para construção de aplicações web. Formulários de interface com usuário, stored procedures, webservices e regras de negócio são desenvolvidas em uma interface 100% visual, o que torna esta ferramenta diferente de qualquer outra encontrada no mercado.
Esse diferencial representa uma grande contribuição para a computação corporativa que se traduz em agilidade no processo de desenvolvimento de software e valor para as corporações.

Regras de negócio: As regras de negócio são representadas através de fluxogramas e entidades visuais. O uso do fluxograma, por representar graficamente a ordem de execução de um processamento, parece óbvio em informática, entretanto, eram utilizados apenas como um recurso didático para o ensino de lógica de computação até a chegada do Maker.

Depois de elaborar as regras em fluxogramas, é possível escolher em qual das três camadas serão executadas: cliente, servidor ou banco. Regras servidoras podem ser transformadas em webservices.

Manutenção das aplicações: Outro importante benefício é o processo de manutenção no software produzido, o qual se tornou ainda mais fácil. A abordagem visual possibilita que outro desenvolvedor realize a manutenção na aplicação, e não somente quem a criou (como acontece na maioria das linguagens, inclusive por falta de documentação das aplicações). Através dos fluxos, centenas de funções e regras são encapsuladas em unidades visuais que podem ser agrupadas em diferentes níveis de complexidade sendo abstraídas numa unidade funcional. Desse modo, pode-se acompanhar a seqüência de execução de um processamento através da representação em modo gráfico e visual.

Independência tecnológica: Outro grande problema na produção de software é a dependência da tecnologia. A aplicação gerada com o Maker não fica dependente do mesmo (como é frequente questionado pelos desenvolvedores). O Maker gera todas as definições do seu sistema que são armazenadas em tabelas do banco de dados, ou numa estrutura XML, para serem lidas por um “motor” e convertidos para a linguagem fim. Esse “motor”, denominado Webrun, processa as aplicações para funcionar nas plataformas Java e dotNet dentro do servidor de aplicação WEB. Caso a linguagem “da moda” mude daqui a alguns anos, basta ajustar o motor e todas as aplicações feitas em Maker estarão atualizadas tecnologicamente, preservando, desta forma, os milhões investidos na construção dos sistemas que continuaram retratando a lógica do negócio.

Funções nativas: O Maker disponibiliza nativamente uma vasta e extensível API voltada para a produtividade no desenvolvimento de aplicações. Atualmente são disponibilizados mais de 500 funções organizadas em categorias, como por exemplo, funções de email, formulários, banco de dados. Temos casos de empresas que ampliaram o conjunto de funções para casa dos milhares.

Produtividade: Por fim, os testes mais recentes indicam que, através do Maker, é possível aumentar a produtividade de desenvolvimento de um projeto centenas de vezes. De forma prática, isso significa que um projeto de 6 meses pode ser concluído em apenas uma semana ou até menos com o uso do Maker.

Atualização tecnológica: Apenas com a melhora no processo de comunicação entre os atores envolvidos no processo de desenvolvimento, o Maker já consegue incrementar de forma impressionante o desenvolvimento de software. Não obstante, permite o envolvimento de especialistas que não necessariamente dominam as linguagens envolvidas na construção de sistemas para Web (HTML, JavaScript, Java, …). Como exemplo, um desenvolvedor especialista em Clipper ou Cobol pode ser inserido no processo de desenvolvimento de aplicações Web.