As Peripécias de um Desenvolvedor Maroto

O que é Ciclo de Vida do Defeito ou Bug em Testes de Software?

noreply@blogger.com (Gabriel Sima) — Sun, 13 Sep 2015 16:24:00 +0000

O ciclo de vida do defeito ou bug ocorre sempre que um defeito é identificado durante o ciclo de vida da aplicação e termina quando o defeito tem seu estado alterado para 'fechado' após ser confirmada a sua correção. Lembre-se: o Ciclo de vida do defeito é relacionado ao bug encontrado durante os testes.

Bugginho Developer

O bug tem estados diferentes dentro do ciclo de vida, o que pode ser mostrado na figura abaixo:

Ciclo de Vida de um defeito

O ciclo de vida do Defeito ou do Bug incluem os seguintes passos ou estados:

New (Novo): Quando um defeito é identificado e cadastrado na primeira vez. Seu estado é dado como Novo,
Assigned (Atribuído): Após o testador ter cadastrado o defeito, seus Gerente verifica se esse defeito é realmente novo e então atribui o defeito para que o desenvolvedor e seu time possa corrigí-lo. Seu estado é dado como Atribuído.
Open (Aberto): Neste estado, o desenvolvedor já começa a análise e o trabalho para a correção do defeito.
Fixed (Corrigido): Quando o desenvolvedor faz alterações no código, então, ele muda o estado do Bug para 'Corrigido' e o passa ao Time de Testes.
Pending retest (Pendente Reteste ou Revalidação): Após corrigir o defeito, o desenvolvedor entrega essa alteração para que o testador refaça o teste. Neste caso, o teste está pendente aguardando o fim do teste, logo, seu estado é pendente reteste.
Retest (Reteste): Neste estágio, o testador começa a fazer o reteste da alteração feita pelo desevolvedor, que repassou ao tester para reteste. É neste estágio que o testador informa ao desenvolvedor se o defeito foi corrigido ou não.
Verified (Verificado ou Validado): O testado testa novamente a correção após ele ser corrigido pelo desenvolvedor, se o defeito não for mais localizado no Software, então, o testador informa que o defeito foi consertado e muda o estado para "Validado" ou "Verificado".
Reopen (Reaberto): Se o defeito ainda existir mesmo após o mesmo ter sido corrigido pelo desenvolvedor, o testador muda o estado para 'Reaberto', Então, o defeito inicia todo o ciclo de vida novamente.
Closed (Fechado): Uma vez que o defeito foi corrigido, testado e verificado que o Defeito não mais existe, o testador muda o estado para 'Fechado'. Este estado informa que o defeito está corrigido, testado e aprovado.
Duplicate (Duplicado): Se o defeito é repetido ou existe mais de menção do mesmo defeito, então um desses defeitos recebe o estado de "duplicado".
Rejected (Rejeitado): Se o desenvolvedor identificar que o defeito não é novo, ele rejeita tal defeito. Então, seu estado é modificado para "Rejeitado".
Deferred (Postergado): O defeito quando tem seu estado alterado para "Postergado" é porque ele será corrigido em versões futuras do software. As razões para isso, é que o defeito pode ser de baixa prioridade, falta de tempo ou o defeito pode não causar sérios danos ao funcionamento do Software e com isso, pode ser postergado.
Not a bug (Não é um defeito): Esse estado é dado para o defeito quando não existir qualquer alteração nas funcionalidades da aplicação. Por exemplo: se o cliente pergunta sobre alguma alteração na parte visual ou nas disposições dos campos como a troca de cor de algum texto, isso não é um defeito, apenas houve uma mudança não informada no design da aplicação.

Fonte: ISQTB

4. Técnicas de Modelagem de Testes - O que é análise de Teste? Ou como identificar as condições para o Teste?

noreply@blogger.com (Gabriel Sima) — Thu, 10 Sep 2015 01:58:00 +0000

Análise de Teste: Identificando condições para teste
A análise do teste é o processo que procura por algo que possa ser convertido em informações para teste. Também é chamada de Base do Teste.

A base do teste é a informação necessária para começar a análise do teste e criar nossos próprios casos de teste. É uma documentação na qual casos de teste são baseados, tais como requisitos, especificações de projeto, análises de risco de produto, arquitetura e interfaces com o usuário.
Podemos utilizar os documentos da base de teste para compreender o que o sistema fará quando for construído. Em alguns casos, os testes pode se basear no conhecimento que o usuário tem do sistema e isso pode não estar documentado.
Da perspectiva do teste, nós olhamos a base de testes para ver o que pode ser testado. Essas são as condições de teste. Uma condição de teste é algo que nós podemos testar.
Enquanto identificamos as condições de teste ideal dentro das muitas condições que temos e então selecionar quais delas serão realmente úteis em nossos casos de testes, a isso chamados de possibilidade de teste.
Como já é sabido, testar tudo no sistema é impraticável, tal procedimento é chama-se teste exaustivo. Devemos escolher apenas um conjunto dos testes possíveis. Na prática, tal conjunto pode ser pequeno diante do tamanho sistema, porém, ele tem uma grande probabilidade de encontrar a maioria dos defeitos.
Precisamos de muita inteligência no processo para organizar nosso conjunto e a essa inteligência damos o nome de técnicas de teste. As condições para teste que foram escolhidas, vão depender da estratégia de teste ou de uma abordagem de teste mais detalhada. Por exemplo, precisam ser baseados no risco, modelos de sistema e etc.
Uma vez identificada a lista de condições para o teste, é muito importante priorizá-los, então a condições mais importante será identificada. Tais condições podem ser identificadas por dados de testes bem como para entradas e para saídas, por exemplo diferentes tipos de registros, diferentes tamanhos de registros ou campos em um registro. As condições de teste estão documentadas na IEEE 829 que se chama "Especificação de Modelagem para Testes".

Fonte: ISTQB

Como passar no Exame de Certificação de Testes Foundation da ISTQB/BSTQB (CTFL) de primeira like a boss ou like a Messi

noreply@blogger.com (Gabriel Sima) — Tue, 08 Sep 2015 14:30:00 +0000

Aqui temos algumas dicas e macetes para passar no Exame de Certificação Nível Foundation (CTFL) da BSTQB/ISTQB.

Bem, fazendo pela BSTQB, em português,o resultado demora 6 dias para ser divulgado, já se fizer na ISTQB o resultado sai na hora... por acaso alguém já conhece a piada sobre o Inferno Brasileiro? é quase a mesma coisa.

Estude todo o Syllabus do Foundations. Vamos cobrir, ou pelo menos tentar, todo o Syllabus em nosso Blog. Os Tópicos, 5 no total, são explicados de maneira própria dentro de cada assunto e suas terminologias que caem normalmente no exame.
Após ler todo o conteúdo do Syllabus corretamente, faça alguns simulados e responda à questionários. Você pode fazer alguns aqui. Uma outra dica muito importante: Nunca estude inicialmente pelos simulados, isso pode causar mais confusão do que auxílio, tente seguir à risca essa receitinha de bolo, que você vai se dar bem.
Fazer o simulado te dará uma idéia dos tópicos que vão precisar de mais atenção. Também vai te ajudar a entender as diferentes perguntas que são feitas.
Após resolver algumas questões dos questionários ou simulados, volte ao Syllabus e leia-o novamente. Sim, isso mesmo, leia-o novamente, é muito importante.
Isso vai te ajudar a entender os tópicos e as terminologias de uma forma melhor e você terá uma melhor compreensão dos tópicos.
Você também pode fazer uma lista de terminologias e as definições que caem normalmente no Exame, através dos simulados.
Você precisar ter bastante atenção à alguns tópicos como teste de Caixa Preta (Partição de Equivalência, Análise de Valor Limite), teste de Caixa Branca, teste de Cobertura e Tipos de Cobertura com cobertura de Declaração, cobertura de Decisão e cobertura por Condição.
Após ler todo o syllabus duas vezes e resolver alguns questionários, tente fazer um simulado dentro do tempo de prova, ou seja, 40 questões dentro de 60 minutos.
Isso significa que você terá 1,5 minutos,ou um minuto e meio, para responder cada questão. Esse tempo é suficiente para resolver perguntas de múltipla escolha.
Candidatos conseguem se preparar em até dois meses ou menos, mesmo trabalhando e com suas esposas a TPM.

Algumas dicas à respeito das questões do exame:

As questões são apresentadas de um modo em que todas as opções são bastante parecidas. Então, é muito importante, estar relaxado e ler a questão e suas opções com muito cuidado..
Se você encontrar mais de uma resposta correta, então comece eliminando as óbvias, após fazer isso, foque-se na terminologia ou definição ou resposta e então faça a marcação correta.
Leia a questão duas ou três vezes e tente compreendê-la. Existem algumas palavras na questão que precisam de maior atenção como "NÃO", "NUNCA","TODOS","TUDO" e etc.
Após responder as questões do simulado, verifique as suas respostas e veja a sua pontuação. Você precisa resolver 26 questões corretamente, no mínimo, para passar no exame.

Desde que você tenha lido todo o Syllabus por duas ou três vezes e resolvido 20 à 30 questionários em um tempo estimado. Eu acho que você está pronto para fazer o exame e passar de primeira Like a Boss.

Mas, se mesmo assim você não se sentir seguro, você pode fazer um curso excelente aqui

E aí, você vai me perguntar:
- Gabriel, e o Teste de Caixa Cinza, o famigerado Grey Box?
E eu vou responder com o maior prazer:
- Grande amigo, esse negócio de Grey é coisa de Teoria da Conspiração, Área 51, isso é com o pessoal do Arquivo X. E agora tem umas Testers ai que só querem saber de 50 Testes de Caixa Cinza... melhor a gente não tocar muito nesse assunto não... Véi na boa! Isso nem está na documentação da ISTQB, porque Grey Test é um híbrido tipo o Chupacabras,Optimus Prime... essas coisas!
E mais uma vez: The treta has planted!

Fonte: ISTQB

Quais são as fases do Ciclo de Vida de Desenvolvimento de Software (SDLC) ?

noreply@blogger.com (Gabriel Sima) — Tue, 08 Sep 2015 02:06:00 +0000

Essa é para puxar na memória.
Lembra quando você tinha essa matéria, que era decoreba, na faculdade ou no curso tecnico de processamento de dados? (Caramba! Curso de Processamento de Dados... acho que entreguei a minha idade agora!).
Pior que tinha sempre um professor que as colocava fora de ordem e na multipla escolha tínhamos que acertar qual a ordem certa, mas tinha sempre aquela maldita opção das "N.R.A." - Nenhuma das Respostas Acima, pois é...
Hoje em dia, por mais que você a ignore, ela tem um peso muito grande.
Gigantes como a Microsoft estão focando suas equipes e aplicativos em frameworks que facilitam o SDLC, porém, com um outro nome: o ALM (Application Lifecycle Management) - Gerencimento do Ciclo de Vida da Aplicação. O nome ficou mais bonito e pomposo, mas na prática é a mesma coisa. A única grande novidade é que, na Microsoft com o Team Foundation Server, você pode escolher entre utilizar CMMI, Agile ou Scrum para gerenciar o seu trabalho. Mas, isso é assunto pra um outro artigo, quando eu abordar um ALM completo com TFS e depois um ALM completo totalmente Open Source, com Jenkins.
Se você ainda está na faculdade e está às voltas com essa sigla, que você acha que tem parte com o Capiroto, fique tranquilo, vamos exorcizar essa pobre alma em algumas linhas abaixo.
Existem várias abordagens definidas e projetadas para desenvolvimento de Software que são utilizadas/empregadas durante o processo. Tais abordagens também são definidas como Modelos de Processos do Desenvolvimento de Software, por exemplo, temos o Modelo Cascata, Modelo Incremental, Modelo V, que não é o de Vingança, o Modelo Iterativo e etc etc). Cada modelo de processos segue um ciclo de vida específico na sua forma de produzir sucesso, ou fama lê-se Martin Fowler, no desenvolvimento de software.
Os modelos de ciclo de vida do Software descrevem suas fases e a ordem nas quais devem ser executadas. Cada fase produz entregáveis necessários para que a próxima fase tenha início, ou seja, são fases dependentes - pegando um pouquinho de carona com o pessoal PMI na veia. Requisitos são traduzidos em Modelagem. Código é produzido de acordo com a modelagem - pelo menos deveria - no que é chamada de fase de desenvolvimento. Após Codificar, os "Codar", os testes de verificação do produto final para verificar se estão de acordo com o que fora levantado, se sim, então podemos "subir" a aplicação em Produção, que é quando o usuário vai poder utilizar o Sistema e fazer os milagres que sempre faz em encontrar erros e também dizer "pior que isso funciona!".
É verdade que listamos muitos modelos, mas você vai me perguntar:
- Gabriel, você tá doidão? e o Scrum, XP e outras abreviações ágeis?
A minha resposta será:
- Estão no Desenvolvimento Iterativo!
The treta has planted!
Apesar da treta estar plantada, existem 6 fases padrão, pelo menos por enquanto, em todo ciclo de vida de desenvolvimento de um Software, o SDLC ou o ALM da Skynet e do Ultron não contam:

Levantamento de Requisitos e Análise
Modelagem
Implementação ou Codificação - (É a gente mesmo!)
Testes - (É nóis na fita, ladrão!)
Publicação ou Implementação em Produção
Manutenção ou Sustentação

1) Levantamento de Requisitos e análise: Requisitos do Negócio são levantados nessa fase. Essa fase é o foco principal dos colaboradores e dos gerentes de projeto e dos POs também - pros agilistas ficarem no meu blog. - Entrevistas com gerentes, colaboradores envolvidos no negócio e usuários de todos os tipos e espécies em seu habitat natural, todos são colocados em fila para determinar, inspecionar e nos ensinar cada vez melhor , veja bem! - sobre as Regras de Negócio envolvidas, tais como: Quem vai utilizar o Sistema? Quais dados serão inseridos no Sistema? Quais dados o sistema irá mostrar aos usuários? Estas são perguntas gerais que devem ser respondidas durante a fase de levantamentos de requisitos (É, realmente deveriam né? mas a realidade... bem, a realidade... xá pra lá!). Após o levantamento de requisitos, estes são analisados, validados e é estudada a possibilidade do que deve ou não ser incorporado aos requisitos do sistema a ser desenvolvido.

Finalmente, é... ainda não acabou, um documento de Especificação de Requisitos é criado e serve (uhum, sei!) como guia para as próximas fases do Modelo.

Diante do que foi dito nessa primeira fase, você já notou como tudo fica mais difícil quando um requisito é mal modelado ou quando uma Estória de Usuário é entregue sem Regra de Aceitação ou quando uma Regra de Aceitação é mal feita ou a própria Estória de Usuário na verdade é um Épico e você não compreendeu? Olha bem o quanto de dinheiro é gasto nessa fase e quanto que se ainda vai gastar caso algo dê errado. Pensa aí e depois coloca lá nos comentários, vamos debater sobre isso.

2) Modelagem: Nessa fase, o produto e o ambiente, são modelados e projetados de acordo com as especificações de requisitos estudadas e informadas na fase 1. O projeto do sistema ajuda a especificar o hardware e os requisitos também auxiliam no geral à Arquitetura do Sistema - não existe almoço grátis. As especificações de projeto e modelagem de sistema servem como entrada para a próxima fase.

3) Implementação ou Codificação: Ao receber os documentos de modelagem, o trabalho é dividido em módulos/unidades e a codificação atual é iniciada. Assim que esta fase começa a produzir o código propriamente dito, o foco principal é para o desenvolvedor. Essa é a fase mais longa do ciclo de vida do desenvolvimento de software, para quem não acredita, aqui vai uma estorinha "das trincheiras" que tá na moda: Imagine que Deus (Gerente de Projetos) avisa pra você que a humanidade vai acabar ("cara, esse projeto é de emergência") e ainda te avisa que vão chover 40 dias e 40 noites ("... esse projeto tem muita gente graúda, precisamos entregar isso logo senão estamos fritos...") e então te manda construir uma arca ("Cara, faz de um jeito rápido que dê pra entregar e tá bom. Rodou... Xablau!") e aí vem a chuva, quando você ainda está terminando os testes de aceitação, mas o XGH - Extremme Go Horse - é quem manda e o resto você já sabe né... não é à toa que essa fase 3 é a mais demorada. Em alguns lugares ela dura por anos... (o grifo é nosso).

4) Teste: Após o código ser desenvolvido, ele é testado de acordo com o que está escrito nos requisitos, aí que começa o "sapeca iá iá", para verificar se o Produto está realmente resolvendo os problemas dos quais fora contratado para resolver nas fases anteriores, o que significa, que se tudo der certo, saber também se a equipe de desenvolvimento vai ganhar uma PLR gorda no final do ano ou um Cestão (ferrados! é claro). Durante essa fase, todos os testes que a mente maligna e criativa do tester criar serão utilizados: Teste unitário, Teste de Integração, Teste de Sistema, Teste de Aceitação e dentre outros. Não especifiquei todos porque estou escrevendo antes de dormir e não quero ter pesadelos.

5) Publicação em Produção: Ufa! depois que nosso trabalho sobreviveu a fase de testes, vamos faturar. O produto é entregue e publicado em produção para que o cliente o utilize.

6) Maintenance: Mas, nem tudo são flores e quando os clientes começam a utilizar o sistema de forma massiva, e é aí que eles fazem cada coisa...operam verdadeiros milagres, até cheat codes utilizam, então os problemas começam a aparecer e precisam ser solucionados de tempos em tempos. Tal processo, onde damos um carinho e uma amolecida no nosso produto desenvolvido, é mais conhecido como Manutenção ou Sustentação, mas o usuário teima em chamar de Porcaria, fazer o quê?

Fonte: ISTQB

Qual o significado de Defeito, Bug ou Erro e Falhas em Teste de Software?

noreply@blogger.com (Gabriel Sima) — Mon, 07 Sep 2015 22:00:00 +0000

Um regrinha rápida para compreender:

1) Erro é cometido por um ser humano

2) um Defeito é gerado no Sistema, quando programado de forma errada.

3) Falha é o que é retornado para o usuário através de um aviso na tela.

4) Bug é quando uma grande quantidade de erros, defeitos ou falhas são encontrados no Software.

Para evitar essa dor de cabeça quando o seu Produto de Software for entregue, é muito útil que se use o Teste de Software, como já dissemos, durante todo o seu ALM.
Agora, vamos de definição.

Definição:

Um defeito é um erro ou um bug, dentro da aplicação quando ela é criada. Um desenvolvedor quando está modelando e construindo o Sistema, pode cometer enganos ou erro. Esses enganos ou erros significam que existem falhas no Sistema, tais falhas são chamadas de defeitos.
Quando o resultado atual desvia do resultado esperado durante os testes então isso é um defeito. Consequentemente, qualquer desvio da especificação mencionado no Documento de Especificação funcional do produto é considerado um defeto. Em empresas diferentes isso é frequentemente chamado de bug, issue, problema ou incidente.
Quando a Produto final não supre a expectativa do usuario final ou não respeita os Requistos Modelados, então isso resultado em um Bug ou Defeito. Esses defeitos, ou bug, ocorrem porque houve um erro de lógica ou erro no código que resulta em uma falha ou resultado imprevisivel ou imprevisto.

Informações adicionais sobre Defeitos/Bugs:

Quando uma aplicação ou um Produto de Software é testado, se um grande número de defeitos são encontrados então ela é considerada "Bugada" ou que contém um "Bug".

Quando um testador encontra um Bug ou um Defeito,é necessário informar sobre os mesmos com os desenvolvedores. Para tal, ele coloca tais defeitos em um Relatório detalhando os passos efetuados até chegar no defeito encontrado, esse Relatório tem vários nomes: Relatório de Bugs, Relatório de Issues, Relatório de Defeitos, Relatório de Problemas e etc.

Este Relatório consiste, basicamente, em conter a seguinte informação:

ID do Defeito – Todo Bug ou Defeito tem um número de identificação único.
Descrição do Defeito – A explicação sobre o que foi encontrado.
Versão do Produto – A versão do Produto, aplicação, no qual o defeito é encontrado.
Detalhes Passo a passo – Os passos detalhados do problema com prints de tela anexados para que os desenvolvedores possam simular o mesmo em seu ambiente.
Data do Ocorrido – A data de quando o Bug foi encontrado e relatado.
Reportado Por – As informações do Testador que encontrou e reportou o Problema, tais como o nome e o Id do Testador.
Estado – O Estado do defeito como: Novo, Encaminhado à alguém, Aberto, Retestado, Verificação, Fechado, Falho, Igorado ou Deferred e etc.
Corrigido por – Os detalhes do desenvolvedor que corrigiu o defeito como Id e Nome do Desenvolvedor.
Data de Finalização – A data em que o defeito foi resolvido e a entrada finalizada.
Severidade – Baseado na severidade (Crítica, Principal, Menor), nos diz sobre o impacto do defeito ou bug na aplicação.
Prioridade – Baseado em um conjunto de prioridades (Alta, Média, Baixa), a ordem de corrigir o defeito pode ser dada.

Fonte: ISTQB

1. Fundamentos de Teste - 1. O que é Teste?

noreply@blogger.com (Gabriel Sima) — Mon, 07 Sep 2015 20:20:00 +0000

Teste de software é o processo de executar uma aplicação com a intenção de encontrar bugs. Também pode ser definido como o processo de validação e verificação feito em um software:

Atende aos requisitos técnicos e de negócios que orientaram seu design e desenvolvimento.
Trabalha como esperado.

Pode ser implementado com características similares.

Colocando uma Máquina de Raios-X sobre a definição de Teste de Software, a vemos em partes, como já dizia Jack:

1) Processo: Testar é um processo, e esse processo é melhor do que uma atividade única, ou fazer algo de uma única vez e validar no final.

2) Ativo em todo o Ciclo de Vida: Teste é um processo que é executado durante todo o Ciclo de Vida da Aplicação (ALM).

O processo de modelagem dos testes, desde o inicio e durante o ciclo de vida, pode ajudar a prevenir defeitos antes que estes sejam introduzidos no código. Algumas vezes é definido como “verificação da base de testes de acordo com a modelagem do Sistema.”

A Base de Testes inclui documentos, tais como as especificações de Requisitos e de Modelagem da aplicação.

3) Teste Estático: Quando executado, pode encontrar defeitos sem precisar executar o código. O Teste Estático inclui revisão de documentos (incluindo código fonte da aplicação) e análise estática de código. É um teste útil e barato. Esse tipo de teste é muito executado pelas IDEs modernas como Visual Studio, Eclipse, NetBeans e afins, para ver na prática, basta errar alguma palavra reservada da linguagem ou algum comando que a IDE vai sublinhar o erro e com isso evitando que a aplicação seja montada e executada até que o erro seja corrigido.

4) Teste Dinâmico: Em um teste dinâmico, o código fonte que precisamos testar é executado, ou "rodado", para demonstrar como ele responde. É feito durante o processo de validação. Exemplos de testes dinâmicos: teste unitário, teste de integração, teste de sistema e etc.

5) Planejamento: Precisamos planejar o que queremos fazer. Controlando as atividades do teste, informando o progresso do teste e o estado do sistema durante os testes, ou seja, como o sistema responde durante essa tarefa, é muito importante anotar tudo o que se encontra e depois fazer uma reunião para selecionar que informação realmente importa ou não.

6) Preparação: Precisamos escolher qual tipo de teste faremos, escolhendo as condições para teste e modelando os casos de teste.

7) Avaliação: Durante a avaliação, precisamos checar os resultados e avaliar o software sob nossa responsabilidade e os critérios de compleição, critério de "passou", "falhou" ou "inconclusivo", que nos ajuda a decidir quando terminar de testar e se o produto passou nos testes propostos.

8) Produtos de Software e artefatos de resultado gerados: Junto com o teste de código, os testes de Requisitos e as especificações de modelagem e outros documentos relacionados ao usuário, materiais de treinamento são muito importantes.

Fonte: ISTQB

Integração Contínua em .NET – Parte I

noreply@blogger.com (Gabriel Sima) — Tue, 05 Aug 2014 01:45:00 +0000

Automatizando seus Processos de Construção, Compilação, Testes, Documentação e Implementação de seus Sistemas em .NET

Nesta primeira parte de nossa série sobre Integração Contínua – mais conhecida na comunidade como CI, o leitor aprenderá sobre o aspecto técnico e psicológico em implementar o conceito de Integração Continua e as vantagens e desvantagens de implementá-la nas organizações vencendo as objeções que aparecem durante o processo até a sua adoção em definitivo.

Nesta Série, nós também introduziremos o leitor com o uso muitas ferramentas gratuitas e de baixíssimo custo tais como Subversion, MSBuild, NAnt, Jenkins e CruiseControl.NET que são partes de um processo completo de Integração Contínua e demonstraremos em detalhes como usar estas ferramentas,neste artigo demonstraremos um processo de Integração Contínua simples. Vamos criar um pequeno Sistema de aprovação de execução de builds que nos dará um maior controle para que nossas alterações sejam publicadas em ambientes estáveis de desenvolvimento, Homologação e Produção. Criaremos um Estudo de Caso que será levado à efeito com o uso da Integração Contínua ao longo desta série. Contaremos o caso da Empresa de Software Fictícia Imbróglio de Códigos LTDA e como a mesma conseguiu se salvar da falência total implementando lentamente o que chamamos de Os 7 Ciclos do Sucesso para a Integração Contínua.

Como desenvolvedores, estamos interessados em desenvolver nossas aplicações da melhor forma possível para os nossos clientes como um minimo de esforço. Mas, nos tempos atuais, com aplicações mais complexas e tendo cada vez mais "partes móveis", criar grandes aplicações está se tornando cada vez mais difícil, mesmo com o avanço nas ferramentas de desenvolvimento, tais como o Visual Studio e .NET Framework. Uma das chaves para a melhoria da produtividade,e consequentemente das aplicações entregues, é a automatização da parte repetitiva do trabalho e a Integração Contínua é uma das melhores formas de se fazê-lo.

Não podemos crer que o Processo de Integração Contínua seja a bala de prata ou a solução para todos os males, mas onde ela tem sido implementada, tem tido grande sucesso e melhorias no processo de software para as equipes de desenvolvimento.

A Integração Contínua, também conhecida como CI - Continuous Integration - é o ponto central do desenvolvimento de software atualmente. De fato, quando a CI é introduzida em uma empresa, torna-se o grande divisor de águas, ela altera radicalmente a forma como as equipes pensam sobre todo o processo de desenvolvimento. A CI tem o potencial de permitir e executar uma série de melhorias contínuas e incrementais nos processos, indo de um processo de simples agendamento de construção - vamos usar o termo build – até o processo de Entrega Contínua que culmina no processo de publicação nos demais ambientes para Teste, Homologação ou Produção.

Uma boa infraestrutura que possibilite a Integração Contínua pode simplificar o processo de desenvolvimento até a entrega do software ou de sua iteração, auxiliando a identificação e correção de falhas rapidamente. Também facilita a disponibilização de uma dashboard muito útil no Projeto tanto para desenvolvedores quanto para outros profissionais da empresa que não são desenvolvedores e, ultimamente, ajuda equipes a agregar mais valores ao negócio e ao produto sendo desenvolvido para o cliente. Todo time de desenvolvimento, não importando se grande ou pequeno, deve implementar e pensar como Integração Contínua.

O que é a Integração Contínua?

Voltando aos dias dos Projetos desenvolvidos utilizando a Metodologia em Cascata e controlando os cronogramas com gráficos de Gantt, bem antes da introdução das práticas de Integração Contínua, o tempo e a energia da equipe de desenvolvimento era drenada diretamente para um procedimento chamado de Fase de Integração, que era executado sempre um passo anterior à entrega do software. Durante esta Fase, a alteração do código era feita por alguns desenvolvedores ou pequenos times que eram reunidos de forma isolada e se juntavam apenas na integração de todo o trabalho já feito. Era um trabalho complicado, na maioria das vezes durava meses, em uma integração com mudanças de código conflitando entre si. Era muito dificil antecipar quais tipos de problemas iriam ocorrer durante este processo e era ainda mais oneroso corrigir os erros provenientes de tais integrações pois envolviam quase sempre retrabalho e reengenharia de código criado meses ou semanas antes. Este processo complicado, oneroso e doloroso, cheio de riscos e perigos, frequentemente causava um grande atraso na entrega, custos não planejados e, como resultado de tudo isso: clientes insatisfeitos. A Integração Contínua nasceu para resolver estes problemas e sanar estas dificuldades. Na sua forma mais simples, a CI envolve ferramentas que monitoram seus Sistema de Controle de Versão (Box 1) buscando sempre alterações. Logo que uma alteração no código é identificada, O Servidor automaticamente compila e testa o código de sua aplicação. Se algo dá errado, a ferramenta imediatamente notifica os desenvolvedores para que eles possam corrigir o problema imediatamente. Mas, a Integração Contínua pode fazer muito mais do que isso.

Sistema de Controle de Versão (SCM).

É um software que tem como principal funcionalidade, controlar versões de um documento qualquer,ou seja, cada alteração que é feita neste documento, se torna uma versão deste e o SCM controla de forma sequencial tais versões. Tal software é muito utilizado em ambientes de desenvolvimento seja ele corporativo ou não.

A Integração Contínua pode também ajudar a equipe a manter a saúde do seu código, monitorar automaticamente a qualidade de código e as métricas em seu código e desta forma auxiliar a manter a Dívida Técnica (Box 2) controlada e os custos de manutenção baixos.

Dívida Técnica.

Dívida Técnica descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo.

A visibilidade pública das métricas de qualidade de código encoraja os desenvolvedores a terem um maior cuidado quanto à qualidade de seu código e melhorá-lo, devemos lembrar que o principal fundamento da Integração Contínua não é punir, mas sim facilitar a manutenção do código afinal de contas o código é de todos. Combinando testes de aceitação, a CI pode também funcionar como uma ferramenta de comunicação, mostrando um verdadeiro Raio-X do estado atual do Projeto em andamento dentro e fora da equipe. Pode simplificar e acelerar a entrega auxiliando a automação do processo, deixando a publicação da última versão da aplicação totalmente automática ou permitindo a operação com apenas um aperto de botão. Em sua essência, a Integração Contínua age sempre na redução de riscos à aplicação e seu desenvolvimento nos dando uma resposta rápida.

Desta idéia, tiramos então uma conclusão lógica: precisamos sempre enviar qualquer alteração de nosso código para teste antes de entrar em produção. De certa forma, o uso da Entrega Contínua, está intrinsecamente ligado a Integração Contínua, posto que esta termina e começa aquela que nada mais é do que automatizar uma implementação do website, devolver um módulo pronto ou outra atividade de fim pois a Integração Contínua é atividade de meio. Então, uma abordagem pura da Integração Continua pode não ser apropriada para todas as equipes. Um exemplo disto, é que muitos usuários não vêem com bons olhos novas versões de software sendo entregues muitas vezes em uma semana e com isto as solicitações para que os mesmos façam seus testes de aceitação e acabam por preferir um ciclo mais espaçado e com um prazo no qual o mesmo possa efetuar tais Testes.

O processo de Integração Continua, e em particular Publicação Continua - Continuous Deploy - e Entrega Contínua - Continuous Delivery, são muito mais do que entregar produtos para os usuários de forma rápida. Quanto tempo seu time faz pequenas alterações de códigos antes de ir para produção? Quanto custa o processo de resolver problemas que ocorreram há muito tempo gerando grandes demandas de falha? Para que o CI possa resolver todos os nossos problemas, devemos não só programar como Integração Contínua como também devemos pensar como Integração Contínua.

Corrigir builds quebrados se torna prioridade absoluta e não devem deixar estagnar o processo. O processo de implementação precisa ser automatizado, com nenhum passo manual envolvido.

Uma das definições mais conhecidas de Integração Contínua foi dita por Martin Fowler que diz: “Integração Continua é uma prática dentro de desenvolvimento de software onde membros de um time integram seu trabalho freqüentemente, normalmente cada um executa no mínimo uma a várias integrações por dia. Cada integração é verificada por um build automatizado (incluindo os testes) para identificar erros de integração o mais rápido possível. Muitas equipes vêem nesta forma de trabalho uma redução significativa nos problemas de integração e permitem uma equpe desenvolver software de uma forma coesa mais rapidamente.”

Resumindo, um processo automatizado que constrói, testa, analisa e implementa uma aplicação para ajudar e garantir que o processo funcione corretamente seguindo as melhores práticas e as tornem entregáveis. Este processo é executado em cada mudança de código fonte e permite resposta imediata para a equipe de desenvolvimento. Diante disto, temos um termo que precisamos compreender que é o Build. O Build, nada mais é do que o processo de compilar, analisar e entregar o assembly pronto para implementação. Exemplificando, pode ser que, desenvolvamos uma camada da aplicação e commitemos seu código dentro do Controle de Versão, logo, o Sistema de Integração Continua, quando for executar a sua tarefa rotineira, irá compilar, testar e posteriormente gerar o assembly no local já pronto.

Processos de Desenvolvimento para Integração Contínua

Seu processo de desenvolvimento é ágil? Em sua equipe é utilizada Extremme Programming - XP -, Scrum ou algum outro? Sua companhia é profundamente enraizada em usar o método Cascata? Seu processo está em algum lugar entre Ágil e Cascata? A resposta a estas perguntas não importa, porque todas as equipes sem exceção devem seguir um processo parecido com o que é mostrado a seguir.

1. Baixa o código fonte, necessário para a programação, de seu SCM.

2. Faz alterações neste código.

3. No Visual Studio, clica em Build e espera que o código compile com sucesso.

4. Volta ao passo dois, caso o Visual Studio identifique erros.

5. Executa os testes unitários, e espera que tudo fique verde, ou seja, que passe em todos.

6. Volta ao passo dois, caso o teste unitário falhe, neste caso, o desenvolvedor vê um alerta vermelho e pode ver mais de um.

7. Refatora o código tornando-o mais compreensível e então volta ao passo cinco.

8. Efetua o envio do seu código alterado para o SCM, este trabalho é chamado de commit.

Vendo o processo demonstrado no parágrafo anterior e quando começamos a utilizar o CI, notamos que seguimos o mesmo processo. Porém, para o CI, o processo ainda vai mais além, posto que ele faça todos estes passos e ainda continua após o commit do código por parte do desenvolvedor, como veremos a continuação dos passos mais adiante.

9. O Servidor de CI observa as alterações no SCM.Quando encontra qualquer nova alteração, ele efetua um download da última versão do código contendo o último commit.

10. O Servidor de CI efetua o build do código.

11. O Servidor de CI executa o teste unitário.

12. O Servidor de CI envia os resultados do builds e o resultado dos testes para um sistema de comunicação, normalmente e-mail, mas também pode ser em SMS, Mensageiro instantâneo ou outro, para informar aos membros do time o estado do build.

Tipos de Construção para a Integração Contínua

Os passos da Integração Contínua que descrevemos anteriormente nos trazem o entendimento de que cada vez que um desenvolvedor altera e sobe o código, um build é acionado, porém, em verdade, este é o último objetivo e a razão pela qual este processo é chamado de Integração Contínua.

Uma forma de começar a configurar o seu Servidor de CI é obter as últimas alterações de seu código e efetuar o build.

No próximo passo, adicione os testes unitários. E então, execute esta operação diariamente, que chamaremos de Build diário.

Mas, veremos que, em um determinado momento, um build diário inclui outras coisas que não nos atendem quando fazemos um build incremental. Quando temos builds executados todos os dias, podemos adicionar a este processo mais dois ou três builds que apenas constroem e testam o software. Não demorará e estaremos construindo e adicionando compilações diferentes para fazer coisas diferentes o tempo todo. Existem tipos de builds que dependem do ambiente e da natureza das aplicações, alguns dos builds mais comuns são mostrados na tabela 1.

Tipo de Build	Descrição
Contínuo ou Incremental	É executado quando o código é commitado no SCM. Executa uma compilação rápida e um ou outro Teste Unitário.
Diário ou Noturno (Daily ou Nightly Builds)	Executa uma compilação e um gama maior de testes unitários e em alguns casos pode executar testes adicionais como testes de aceitação e teste de Interface de usuário.
Semanal	Executa a compilação, testes de unidade completos e testes adicionais como testes de aceitação, testes de fumaça e afins.
QA	Cria um build apenas para verificações do pessoal do Setor de Qualidade contendo as métricas para tal.
Staging ou Pré-Produção	Consiste em ser um servidor que age como uma réplica perfeita do ambiente de produção, também pode ser chamado de pré-produção em alguns lugares. Nesta categoria, o build é executado e retornando sucesso, deixa os assemblies disponíveis para testes em pré-produção.
Release	Cria um conjunto de instalação e então efetua os testes de instalação e todos os outros processos necessários ao funcionamento do sistema em Produção e retorna o feedback.

Tabela 1. Tipos de Build

O build mais importante, e é justamente o que nos dá o resultado mais rápido, é o build contínuo ou incremental. Tal build é automaticamente chamado quando o CI identifica uma alteração no código fonte commitado no SCM. Como este build é executado muitas vezes durante o dia e um build pode ser executado logo após o término de outro. Este pode ser executado a cada cinco ou dez minutos.

Ocupando o segundo lugar em frequência, por ser executado em um período mais espaçado, é o build diário, também chamado de build noturno. Tal antítese pode ter gerado alguma confusão, posto que a pergunta que se faz é: ele é noturno ou diário? A resposta é: não importa, posto que ele seja executado uma vez por dia e preferencialmente quando não se tem quase nenhuma atividade na infra-estrutura, pode ser um horário durante o dia em que todos devem ter ido almoçar ou durante a madrugada, por isso a dualidade, que pode ser conflitante em alguns casos, de conceitos. Tal tipo de build é agendado para que execute todo um gama de testes unitários em todo o código, sem exceção, por isso que é muito importante ter um seu Projeto uma estratégia de testes para os módulos bem definida para que estes builds nos devolvam a informação verossímil e necessária, também verificamos a qualidade do software utilizando Cobertura de Códigos e Métricas de software.

Outro tipo de build é o Build Semanal, que executa automaticamente e de forma usual sempre aos finais de semana. Uma vez por semana é o suficientes para medirmos a qualidade de nosso código e executar Testes adicionais com ferramentas para testes de fumaça como Selenium, FitNesse e NUnitForms. Também, podemos criar a documentação de nosso código utilizando SandCastle e fazer a Integração Contínua de nossa base de dados.

Para um controle maior da data de liberação das novas versões do seu sistema, além do build semanal, também seria recomendado um build de release.

O propósito do build do release é criar um conjunto de instalação e executá-lo. Este build normalmente é executado manualmente. Mas, após o build ser iniciado, todos os outros passos são executados automaticamente. No build de release, o CI compila todo o código Fonte, executa todos os testes criados, incrementa o número de versão e etc. Então é criado o conjunto de artefatos para a implementação do mesmo e posterior teste desta implementação. Podem existir outros tipos de builds de acordo com as necessidades.

CI em alguns passos para a sua organização

A Integração Contínua não é a solução para todos os nossos problemas como já foi dito anteriormente. Claro que introduzir a CI dentro da empresa nos mostra um caminho a percorrer através de ciclos distintos. Cada um destes ciclos envolve melhorias que são incrementais entre si para todo o corpo técnico, sejam eles servidores ou profissionais da equipe de desenvolvimento bem como melhorias na cultura e estrutura de trabalho. Vamos mostrar nos parágrafos seguintes, um pouco de cada ciclo organizado do mais elementar ao mais maduro em uma empresa fictícia, a Imbróglios no Código LTDA, que estava à beira da falência, mas que acabou se organizando e utilizou a CI como o ponto inicial de sua alavancagem e crescimento Financeiro, dos 10 Analistas Iniciais dentro do Estado do Rio de Janeiro, a Imbróglios hoje em dia emprega mais de 3.000 profissionais de TI nos cinco continentes, muitos dos Analistas da época tornaram-se gestores. A Imbróglios no Código estava à beira da falênca, mas não por erros apenas de seus profissionais de desenvolvimento, mas por não disporem de uma infraestrutura competitiva. Enfim, a empresa havia parado no tempo e começou a ouvir as opiniões de seus colaboradores, em reuniões diárias, como último recurso para evitar a completa bancarrota, nestas reuniões a palavra Integração Contínua e outros termos sobre o mesmo assunto foram mencionadas e também os gestores identificaram que membros da equipe já detinham tal conhecimento oriundo de experiências anteriores, mas que no passado a gerência não os permitia implementar tais idéias porque "não havia espaço no cronograma e o tempo era curto". Apesar de uma parte da equipe declarar oposição diante desta medida, que veremos como tal resistência foi combalida, a Diretoria comprou a idéia e deu um prazo de 5 meses a contar daquele momento e transcrevemos abaixo os trechos mais importantes da consultoria na qual este autor tomou parte e participou do processo para que o leitor acompanhe ciclo por ciclo como a Integração Contínua pode mudar a filosofia de trabalho de uma organização.

Primeiro Ciclo. Não existe Servidor de Build. Inicialmente, a equipe ainda não dispõe de nenhum tipo de Servidor Central de builds. O Software é compilado e construído manualmente na máquina do desenvolvedor, mesmo que se use um Script NAnt ou similar. O Código Fonte dos Projetos é armazenado em servidores centralizados, mas desenvolvedores nem sempre commitam suas alterações neste Servidor. Antes que uma versão estável ser liberada, um desenvolvedor executa a integração, das alterações no código fonte da aplicação, de forma manual, este processo gera um grande prejuízo no que tange a ultima parte: integração manual de código.

Segundo Ciclo. Builds Noturnos ou Diários (Nightly ou Daily). O time agora dispõe de um servidor para builds e builds automatizados são agendados em um período regular, sendo tipicamente à noite ou durante o dia quando o fluxo de trabalho é interrompido por algum período - horario de almoço coletivo, reunião diária entre equipes ou afins, algo que cause queda de utilização do link. Estes builds apenas compilam os códigos, ainda não existem Testes Unitários sendo executados. Testes Unitários quando existem, não são parte integral ou obrigatória do processo de build. Desenvolvedores commitam suas alterações de Código Fonte regularmente, normalmente, no final do dia. Se um membro da equipe de desenvolvimento efetua um commit de seus códigos e este conflita com o trabalho de outro membro da equipe, o servidor de builds alerta toda a equipe via e-mail na manhã seguinte. Porém, faz-se mister que o time ainda utilize o servidor de builds com o único propósito de informar as quebras e nada mais, logo a equipe acaba se sentindo desobrigada à corrigir toda a compilação interrompida para corrigir apenas aquele build em sua estação de trabalho, e o build pode ficar quebrado no servidor de por um tempo maior.

Terceiro Ciclo. Builds Noturnos e Automação de Testes Básicos. O time agora já está começando a tirar proveito da Integração Contínua com Testes automatizados mais seriamente. O servidor de build está configurado para dar início a um novo build assim que um novo código é commitado para o SCM e aos membros do time é permitida a livre visualização da alteração do código gerou a execução do Build e qual o impacto desta mudança. Além disso, o script que executa o build compila a aplicação e executa um conjunto de testes unitários ou testes de integração automatizados. Com relação ao envio de mensagens à equipe, o servidor de builds também envia um alerta aos membros do time sobre problemas na integração utilizando não só o e-mail, mas como outras formas mais proativas como mensageiros instantâneos. Builds que ficam quebrados agora são corrigidos mais rapidamente.

Quarto Ciclo. Tem início a Revolução das Métricas. Agora a equipe dispõe de verificação da Qualidade de Código automatizada e validação de métricas quanto à cobertura do código junto às melhores práticas, auxiliam muito na verificação para a eficiência dos nossos testes. Existe um build que incide apenas sobre a verificação da qualidade do código, ou seja, em um processo que é executado de forma distinta dos outros builds mostrados anteriormente, este ocorre sempre, de forma separada, sobre a versão mais estável que está sendo executada, também gera uma documentação sobre a API utilizada para a criação da aplicação, facilitando assim a organização do código e escalabilidade da infraestrutura da aplicação ao longo do tempo o que facilita a chegada de novos membros à equipe e diminui o tempo de treinamento do novo recurso. Este tipo de implementação da CI ajuda a equipe a manter a qualidade do código sempre em alto nível, informando ao time quais métricas/práticas de testes estão sendo eficientes e úteis ao processo. O time também dispõe de um Painel de Acompanhamento de Builds, que consiste em mostrar os resultados de todo o Projeto em um Monitor na Sala ou no corredor da empresa de forma que todos tenham visibilidade de todos os processos de CI que estejam sendo executados e os status destes.

Quinto Ciclo. Testando de forma mais aprofundada e automatizada. Os benefícios da Integração Congtínua são intimamente relacionados à práticas de testes bem consolidadas dentro da equipe. Agora, práticas como Desenvolvimento Orientado a Testes, TDD, são largamente utilizados resultando em um crescimento na confiança dos resultados dos builds automatizados. A aplicação não é mais simplesmente compilada e testada, mas se o teste tem sucesso, este é automaticamente implementado para um servidor de aplicação para testes de outros tipos tais como testes de Aceitação e Testes de Desempenho e chegando a este ponto, já podemos começar o 6º e penúltimo ciclo, o dos Testes de Aceitação e Implementação que levará a empresa à filosofia da Entrega Contínua.

Sexto Ciclo. Testes automatizados de Aceitação e uma implementação melhor elaborada. O Desenvolvimento Orientado à Testes de Aceitação é praticado, guiando esforços de desenvolvimento e providenciando sempre relatórios de alto nível do estado atual do Projeto. Estes testes automatizados utilizam ferramentas para Desenvolvimento Orientado a Comportamentos, BDD, que agem como agentes para comunicação e documentação assim como as ferramentas de testes que publicam relatórios sobre os resultados de testes nos termos de negócio que profissionais que não sejam de desenvolvimento possam entender. Uma vez que testes de alto nível sejam automatizados dentro do projeto o mais cedo possível no processo de desenvolvimento, eles também dão a idéia de que melhorias foram implementadas e o quanto falta para a entrega da iteração ou do Projeto como um todo. A aplicação é automaticamente implementada no ambiente especifico para testes junto ao pessoal da Qualidade, ou QA, tão logo as alterações sejam commitada no SCM ou em uma base de build noturno. Uma versão estável do software projetado poder ser implementada em ambiente controlado, como pré-produção por exemplo, utilizando um build executado manualmente, caso a Equipe de Testes julgar estável. A equipe de desenvolvimento também será capaz de utilizar o servidor de build para proteger a versão estável gerando um rollback para uma versão anterior, se algum erro brusco e crítico ocorrer.

Sétimo Ciclo. Entrega Contínua. Existe um confiança colocada nos testes automatizados de Unidade, de Integração e de Aceitação de tal forma que as equipes podem aplicar as técnicas de implementação automatizada no Ciclo 6, porém, caso tudo corra bem, podem permitir que o CI implemente-as diretamente em produção em caso positivo dos builds. É este tipo de procedimento que configura a Entrega Continua e pelo que pudemos ver no decorrer deste processo,a única intervenção humana neste processo foi executada no ciclo 6 para testes de implementação.

Será dentro destes ciclos que nossa série de artigo irá funcionar, utilizaremos estes 7 ciclos de forma a mostrar de forma prática para o leitor como que o CI vai evoluindo dentro da Organização e como o nosso script de build vai sendo incrementado durante a implementação das melhorias. Porém, diante de toda esta revolução como foi visto anteriormente, grandes objeções surgem por estarmos lidando com o fator humano que não é feito à mudanças. Podemos vencer os mais resistentes com simples respostas para complexas perguntas e será o que veremos à seguir.

Lidando com a resistência às mudanças

Com todos estes builds acontecendo e membros da equipe tendo que modificar a sua rotina e efetuar atualizações em seus códigos, com os códigos mais atuais para se manterem atualizados motivados por um servidor de SCM, de forma freqüente, ou seja, quase que diariamente, podemos encontrar certas objeções dos membros do time e as mais comuns veremos a seguir.

CI aumenta a manutenção. Algum membro terá de manter o Sistema de CI. Tal procedimento fará com que este membro saia de seu escopo de ser apenas um desenvolvedor. No início, existirá um tempo maior que gerará um excesso de trabalho ao membro da equipe, porém, o time terá uma grande economia de tempo posto que o grande gargalo conhecido, que era o da Integração manual, não irá ocorrer e tornará o teste da aplicação mais simples. Muitas equipes informam, e isso é facilmente encontrado na Grande Rede, que após o processo de CI ser implantado, as rotinas de manutenção demoram menos que uma hora por semana na média.

Estas mudanças são rápidas demais e são muitas. É difícil se adaptar a uma nova forma de se fazer algo. Não implementar tudo de uma só vez. Começar com um build simples executado uma vez ao dia e então adicionar um teste unitário. Após o time se sentir mais confortável e se acostumar com esta rotina podem adicionar um ou mais builds por dia ou começar a executar uma Análise de Código. Por implementar o processo em pequenos passos e mostrar que estes pequenos passos nos retornam grandes resultados - principalmente em tempo e facilidade, teremos mais aceitação dentro deste novo processo.

CI implica em uma custo adicional de hardware e de software. Comece com um PC antigo como seu servidor de CI se conseguir. Eventualmente, vamos precisar melhorar o hardware para que possamos executar builds de forma mais veloz (devemos nos lembrar de que um build de integração, demora no mínimo, 5 minutos), mas para builds executados de duas à três vezes ao dia, máquinas antigas também vão nos atender. Se as ferramentas que informarmos nesta série forem utilizadas como recomendamos, o seu custo com software será mínimo.

Desenvolvedores devem compilar e testar. Não estamos tirando estas responsabilidades dos desenvolvedores. Estamos apenas movendo boa parte do trabalho mais demorado e oneroso para um Sistema automatizado. Tal medida fará com que os membros da equipe possam produzir mais e resolver melhor os problemas de Regras de Negócios que existam na aplicação, logo esta medida fará com que os desenvolvedores fiquem mais produtivos aonde importa: Escrever e identificar erros no código.

O Projeto é longo demais ou está adiantado demais para que adicionemos o CI. Embora seja muito melhor e mais fácil se colocar um projeto na CI desde o seu início, a verdade é que, muito do trabalho que é feito é justamente dentro de manutenção dos nossos Projetos já existentes. Um projeto que já exista pode não ter Testes Unitários, mas podemos utilizar um SCM e precisar fazer builds destes. Podemos nos beneficiar da CI não importando o tempo e o tamanho do Projeto.

Se a CI for colocada em seu devido lugar, muitos dos problemas mais conhecidos dentro de um Projeto de Software: do desenvolvimento à entrega e manutenção devem ocorrer. Mais adiante, vemos muitas razões para que se utilize o CI em seu processo de desenvolvimento.

Riscos Reduzidos. Implementando bons processos de CI, criaremos software com uma performance muito melhor que a habitual porque já teremos feito os testes unitários e testes de integração de código muito mais cedo dentro do processo, então aumentamos as chances de corrigir erros também muito cedo. Falaremos sobre Riscos na próxima e derradeira seção desta primeira parte.

Produto implementado de forma simples. Se automatizarmos o processo de instalação. Nós saberemos sobre o comportamento de sua instalação antes de receber um feedback de problemas do cliente.

Visibilidade de Projeto. O mecanismo de feedback permite aos membros da equipe saber sobre os resultados do build e onde estão os problemas. Os problemas podem ser corrigido o quanto antes e esta abordagem reduz custos e o tempo gasto corrigindo problemas.

Não permita que as objeções dos membros nos obrigue a recuar ou resistir. A resistência inicial irá diminuir gradualmente quando a equipe começar a trabalhar diretamente com o Sistema de CI. Uma Terapeuta Familiar muito conhecido em outros países chamada Virginia Satir criou o Modelo de Mudanças Satir que se refere sobre como as famílias lidam com a mudança. E transportando algumas diretrizes para lidar com a equipe, temos a seguir algumas boas recomendações. E este processo de mudança envolve cinco passos.

Passo 1. Status Quo Tardio. Todos estão trabalhando normalmente no processo atual e todos sabem como ele funciona.

Passo 2. Resistência. Um novo elemento é introduzido no seio da equipe. As pessoas são sempre hesitantes para mudar a sua rotina. Se o status quo funciona muito bem, por que modificá-lo?

Passo 3. Caos. O novo elemento introduzido é adotado. Não há uma forma normal de fazer novas coisas. Rotinas diárias são despedaçadas.

Passo 4. Integração. Pessoas se ajustam lentamente ao novo modo de se fazer coisas. Fica mais fácil fazer o trabalho de convencimento se utilizar esta abordagem. E começam a utilizá-lo, mas de forma gradual.

Passo 5. Novo status quo. O novo elemento já está totalmente integrado ao Sistema. As pessoas agora o vêem como Normal e voltamos ao passo 1.

Quase todos os times acabam adotando novas metodologias de uma hora para outra. Este processo por soar familiar. Assim como lutamos contra a resistência da equipe, sejamos persistentes em implementar as mudanças. Os membros do time em breve vão aceitá-las. Alguns membros vão adotar o CI mais rápido que outros alguns podem precisar de uma dose maior de convencimento. Talvez seja necessário mostrar a eles como o CI reduz os riscos e os custos e benefícios dentro do processo de desenvolvimento.

Custo Benefício da Integração Contínua

Seu cliente não gosta de riscos. Seu gerente não gosta de riscos. Seu Gerente de Projetos precisa ter planos para mitigar os riscos. No fim, não vamos gostar de riscos. CI é sempre apontado como uma redução nos riscos. Talvez o maior risco dentro do desenvolvimento de software é o não cumprimento de prazos, em outras palavras o projeto sendo entregue mais tarde do que o acordado e contratado. Por causa do mecanismo de feedback no processo de CI, os membros do time sempre vão saber do estado do build atual, que nos auxilia a saber se o projeto está dentro dos prazos.

Veremos o mecanismo de feedback mais adiante em nossa série de artigos.

O outro grande risco é o risco de defeito, os chamados bugs. Como já mostramos anteriormente, que quanto mais tardia é a política de defeitos aplicada a um projeto, maior será o custo para corrigi-los. Algumas estimativas sugerem que o custo para a correção de um defeito gira em torno de R$3.500,00 em média para corrigir um simples defeito de software em aplicações internas. Anos atrás, uma companhia de antivírus bem conhecida gerou defeito dentro de um de seus pacotes de atualização. Este pequeno defeito fez com que os clientes perdessem confiança naquele antivirus e forçaram a empresa a reduzir seus rendimentos trimestrais e previsões orçamentárias de receita em US$8.000.000,00. Não gostaríamos de ver a nossa empresa passar por algo parecido.

Uma das vantagens da CI neste ponto é que os defeitos são corrigidos tão logo eles são identificados. Integrando e testando o software a cada build, podemos identificar e corrigir defeitos no processo. Discutiremos Testes Unitários mais adiante em nossa série de Artigos.

Sempre fizemos algumas perguntas para saber o andamento de nosso projeto como: consideramos quantos caminhos diferentes podem existir em nosso código fonte? testamos a combinação de cada if/else? Quantos casos de declarações switch foram testadas? respondemos estas perguntas implementando a Cobertura de Código.

Cobertura de Código é a metodologia que verifica quais caminhos serão testados e quais não serão. Uma grande solução quando o assunto é cobertura de código é que podemos automatizá-la em nosso processo de CI. É humanamente impossível de serem testadas todas as combinações de cobertura existentes, mas quanto mais for testado, menos problemas serão descobertos pelo seu cliente.

Outro risco conhecido são as atualizações em Bancos de Dados. Nunca foi fácil adicionar campos para uma tabela ou novas tabelas em um Banco de Dados.

Com Integração Contínua em Banco de Dados, teremos ciência se as mudanças implementadas trabalham corretamente e sem perda de dados. Demonstraremos Integração Contínua em Bancos de Dados mais adiante nesta série.

Desenvolvedores odeiam padrões de codificação e arquiteturais, mas têm seu propósito útil: permitem que a aplicação siga as melhores práticas, fazem com que a aplicação funcione melhor e fica mais fácil de manter. Revisões de Código identificam muitos problemas; mas, como Revisão de Código é um processo manual, algumas coisas podem se perder. Então, por que não automatizar a verificação da padronização em seu processo de CI? cobriremos também a Revisão de Código mais adiante nesta série.

Comentários são colocados raramente no código e a documentação quase não existe. Muitos dizem que se formos ágeis, não precisamos de documentação, mas isso não é verdade. O Manifesto Ágil diz que o trabalho é mais valorizado que a documentação. Mas, a documentação é ainda necessária, especialmente se estivermos criando assemblies a serem utilizados por outras equipes ou outras pessoas em forma de APIs. Esta é outra oportunidade para automatizar seu processo com processos de CI. Cobriremos esta parte também nesta série de artigos mais adiante.

Como saberemos que o processo de instalação/implementação funcionou corretamente? Existem poucas coisas que frustram mais usuários do que não conseguirem instalar ou implementar uma aplicação. É fácil ver problemas escondidos no Projeto que sem um sistema de CI só seria identificado muito depois do processo de desenvolvimento, quando os problemas já se tornaram bem mais difíceis e caros para se corrigir. Agora que já sabemos o que a Integração Continua é e como ela pode melhorar nossos processo de desenvolvimento nas próximas partes veremos o processo de CI ser implementado gradualmente seguindo os ciclos informados nesta primeira parte.

Nesta primeira etapa de nossa série sobre a Integração Contínua, vimos os grandes problemas que são encontrados em projetos, organizações e equipes de forma que preparamos o leitor para os desafios que serão encontrados nesta busca pela excelência em seus projetos e tal excelência começa com o Sistema de Integração Contínua. O maior obstáculo para a implementação não está no Projeto em si, mas na resistência das equipes em implementá-lo dentro das organizações.

Assim que a resistência é combalida demonstrando no dia a dia como a CI é útil e viável, a implementação começa a mudar de forma lenta, mas drástica a forma como as organizações interagem dentro do Projeto de Software. Tendo mais agilidade, as equipes conseguem melhores resultados.

Spring.NET: Uma introdução

noreply@blogger.com (Gabriel Sima) — Sat, 24 Aug 2013 02:12:00 +0000

O Spring.NET é um port para a linguagem .NET do famoso Projeto do Framework de integração, o Spring, da empresa SpringSource, atualmente uma empresa do grupo VMWare, para a linguagem Java, tal framework já é bastate consolidado no meio Java até por, na época de sua criação, implementar tecnologias que a linguagem não tinha como padrão em sua JDK, tecnoogias estas que atualmente já fazem parte de projetos da comunidade principalmente a CDI - Component Dependency Injection, que hoje é uma JSR na comunidade Java, sendo largamente implementada agora na versão 6 de seu JDK. O Spring Framework também deu início ao Projeto para o Enterprise JavaBeans 3.0 onde utiliza muitos padrões de projeto implementados no Spring Framework e o principal deles é justamente a Injeção de Dependências, sendo esta a base de sua integração. Porém, a mesma tecnologia sendo portada para .NET ainda não teve o mesmo sucesso e nem mesmo a mesma quantidade de adeptos.
Muito disso se deve a existência de outros frameworks e conteineres para injeção de dependências tais como: Ninject, Castle Windsor dentre outros já bastante conceituados no mundo .NET. O Spring.NET pode facilmente ocupar este espaço por ser um framework de "curta curva de aprendizado" o que implica que o mesmo é bem mais fácil de se aprender e de se executar e também, a injeção de dependências. A Injeção de Dependências é apenas um de seus vários módulos e é a sua base principal. Diante disso o Spring.NET tira toda a sua vantagem diante dos outros frameworks de Injeção de dependências porque o Spring.NET não faz só este trabalho, faz mais do que isso: integra desde Camada de Acesso a Dados à Camada de Apresentação, bem como Queue Messaging, WebServices, Integração com WCF e por aí vai, utilizando o Spring.NET como integrador de suas aplicações, ele permite e garante a estabildade permitindo ao desenvolvedor que não se preocupe com a sua infraestrutura: coleta de lixo, instanciação de objetos, performance e escalabilidade. Qual seria a vantagem de se usar o mesmo framework para Integrar todas as camadas? creio que todo desenvolvedor ou Arquiteto procura algo deste porte para sua aplicações, o que será decisivo para o uso ou não do Spring.NET será apenas a arquitetura e principalmente o custo e o tempo do Projeto. Entendendo bem como funciona a Injeção de Dependências, o desenvolvedor consegue dominar o Spring.NET por completo.

Os Módulos do Spring.NET
O Spring.NET detém 18 módulos de Integração que participam de todo o ciclo de vida de um projeto: de sua análise até os teste finais para entrega do software. Vamos listá-los:
- Arquitetura de Base
Esta arquitetura é a que sustenta o Spring.NET e sobre ela que as integrações são executadas.
1) Core - Núcleo principal que é utilizado como Container para Injeção de Dependências e as funcionalidades principais, que são as interfaces de uso para esta infraestrutura de Injeção.
2) AOP - Aspect Oriented Programming - Programação Orientada a Aspectos contendo suas Suporte a Modelo AOP, Infraestrutura utilizando o Padrão de Projetos Proxy e a Biblioteca Aspect Library. O Spring.NET é um dos poucos frameworks que pode ser utilizado como container AOP também, esta tecnologia na linguagem Java já é bastante consolidada e utilizada, por isso ela também foi trazida para o Spring.NET para que suas facilidades em Projetos também sejam exploradas pelas Equipes que utilizam o .NET.
- Arquiteturas implementadas pelo Spring.NET para integração.
São as arquiteturas de integração propriamente ditas na qual o Spring disponibiliza tendo esta integração sempre facilitada pela Injeção de Dependências. Temos os seguintes módulos:
a) Camada de Dados (Gerenciamento de Transação): NHibernate;
b) Mensageria (Messaging) (Utilizando sempre através do Microsoft MSMQ): Apache NMS, Tibco EMS;
c) Serviços (Abstração de Serviços Portáveis, ou seja, WebServices, SOA e afins): Enterprise Services, Web Services e Serviços WCF.
d) Camada de Apresentação: MVC
e) Teste Unitário: NUnit e MSTest
f) Scheduling ou Agendamento de Tarefas: Quartz.NET
Neste artigo, vamos implementar a Arquitetura básica e o Módulo de Core. Em artigos futuros falaremos de todos os Módulos e arquiteturas.

Imagem 1. Módulos do Spring.NET

A Imagem 1 nos dá uma impressão do tamanho deste framework e suas implementações internas.

Injeção de Dependências com o Spring.NET

O Spring.NET e seu assembly Spring.Core implementam a Injeção de Dependências utilizando os dois tipos existentes: via Setter e via Construtor. Tomemos como exemplo uma Classe que fará a persistência de um Cliente e uma Classe que será responsável por abrir a conexão com a Base de Dados. Para este exemplo usamos as Classes respectivamente: ClienteDAL e Conexao. Estas duas Classes nos farão compreender melhor os dois tipos de Injeção de Dependências existentes e como estes são utilizados pelo Spring.NET.
Injeção de Dependências via Construtor
Neste tipo de Injeção, A Classe injetada estará encapsulada dentro de um parâmetro que será passado ao construtor, lembrando que este parâmetro deve ser tipado com a Classe a ser injetada, como mostram os Trechos de Código 1 e 2:

Trecho de Código 1. Classe Conexao

 public class Conexao{ 
  #region Construtor
  //Digitando ctor e pressionando a tecla TAB duas vezes
  //O Visual Studio cria um construtor padrão      
  public Conexao() 
  {
     //Algoritmo para acesso ao Banco de Dados
  }
  #endregion
 }

Esta nossa Classe Conexão fará o acesso ao Banco de Dados e será necessária em nossa classe de persistência. Esta será injetada no construtor da Classe ClienteDAL via parâmetro tipado como Conexao. Como mostrado no Trecho de Código 2.

Trecho de Código 2. Injeção da Classe Conexão no construtor de ClienteDAL

#region Propriedades
        /// <summary>
        /// Propriedade que será utilizada para Injeção via Construtor
        /// </summary>
        public Conexao conector { get; set; }
        #endregion

        #region Construtores

        public ClienteDAL()
        {

        }

        /// <summary>
        /// Construtor para Injeção de Dependências 
        /// via Construtor
        /// </summary>
        /// <param name="conexao"></param>
        public ClienteDAL(Conexao conexao)
        {
            this.conector = conexao;
        }
#endregion

Neste ponto, observando o construtor da classe ContatoDAL, podemos notar que o parâmetro chamado conexao está tipado com a nossa Classe Conexao, logo já temos a nossa injeção de dependências pronta para uso, o Spring.NET utiliza do padrão singleton juntamente com o Service Locator, ou seja, abre apenas uma instância desta Classe diretamente, caso a mesma não esteja instanciada, ela o é automaticamente, sempre que o construtor é ativado. O que torna o uso bastante racional. Pronto, agora você já pode usar seus métodos de persistência preocupando-se apenas com as operações de CRUD.
Injeção de Dependências via Setter
Nesta modalidade de Injeção de Dependências, utilizamos um "setter" para que nele possamos Injetar a Classe que proverá todo o serviço necessário. Como podemos ver no Trecho de Código 3.
Neste modo, podemos utilizar uma interface para enriquecer a nossa codificação, posto que no momento da implementação da Injeção, podemos fazer com que a Classe Injetada possa utilizar a interface facilitando a abstração em um ambiente de “Mundo Real”. Neste momento, vamos utilizar esta Injeção via Setter em uma Classe de Regra de Negócio que irá utilizara a Interface IClienteDAL para prover a injeção de dependências para ClienteDAL

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using IntroSpringNet.Modelo;

namespace IntroSpringNet.Persistencia
{
    public interface IClienteDAL
    {
        void Salvar(Cliente cliente);
    }
}

Agora que criamos a nossa interface, vamos criar usar um trecho de código para exemplificar esta injeção.

#region Propriedades

public IClienteDAL DAL { get; set; }

#endregion

#region Métodos

public Boolean CadastrarCliente(Cliente cliente)
{
  DAL.Salvar(cliente);
  return true;
}

#endregion

Podemos ver na que a propriedade DAL recebe a Interface IClienteDAL onde receberá a injeção de ClienteDAL. A Classe CadastrarCliente, utiliza DAL e não há a necessidade de instanciar o objeto, posto que o Spring já está controlando o objeto em seu contêiner via setter.
Como o Spring gerencia os Objetos para a DI.
O Spring.NET tem uma forma peculiar de gerenciar seus objetos, todos estes objetos são registrados em um arquivo .xml, ele pode ser os descritores do próprio .NET, ou seja, os arquivos .config – App.Config se standalone ou Web.Config se Web. Pode-se utilizar estes arquivos ou neste arquivos fazer um apontamento para outro XML, posto que o Spring.NET tem um cabeçalho bem peculiar, no Trecho de Código 4, temos um exemplo de arquivo .XML com header e configuração de gerência de objetos registrados. Sem este arquivo, o Spring.NET não poderá funcionar posto que nele estão todas as funcionalidades necessárias para que o contêiner seja inicializado e que o mesmo reconheça todos os objetos através do parsing, ou seja, o arquivo é totalmente validado antes de ser utilizado

Trecho de Código 4. Configuração do Spring.NET em arquivo de configuração XML

<configSections>
    <sectionGroup name="spring">
      <section name="context" type="Spring.Context.Support.ContextHandler
               , Spring.Core"/>
      <section name="objects" type="Spring.Context.Support.DefaultSectionHandler
               ,Spring.Core"/>
    </sectionGroup>
  </configSections>
...
<spring>
    <context>
      <resource uri="config://spring/objects" />
    </context>
    <!-- Objetos para Injeção de Dependências -->
    <objects xmlns="http://www.springframework.net">
      <!-- Conexao -->
      <object name="Conexao" type="DAL.FonteDeDados.Conexao, DAL"/>
            
      <!-- ContatoDAL -->
      <object name="ContatoDAL" type="DAL.Persistencia.ContatoDAL, DAL">
        <constructor-arg ref="Conexao"/>
      </object>
      
      <!-- ManterContato -->
      <object name="ManterContato" type="BLL.Negocio.ManterContato, BLL">
        <property name="Dao" ref="ContatoDAL" />
      </object>
      
    </objects>
  </spring>
...

Dentro da tag configSection no início do arquivo, temos a tag sectionGroup, dentro desta temos mais dois sections com o atributo de name, estes atributos significam que neste arquivo temos o acesso ao Contexto e que nele também existem objetos a serem gerenciados pelo Conteiner de Injeção de Dependências. Com relação ao Contexto, significa que temos de chamar a interface IApplicationContext dentro de nossa aplicação para que o Spring.NET possa acessar as configurações deste arquivo para iniciar o contêiner de Injeção de Dependências.
Na seção que contêm a tag de nome Spring, temos a configuração e registro dos objetos que serão utilizados pelo contêiner de DI. Veremos este trecho mais de perto através do Trecho de Código 5.

Trecho de Código 5. Seção de Configuração do Spring e seus objetos

<spring>
    <context>
      <resource uri="config://spring/objects" />
    </context>
    <!-- Objetos para Injeção de Dependências -->
    <objects xmlns="http://www.springframework.net">
      <!-- Conexao -->
      <object name="Conexao" type="DAL.FonteDeDados.Conexao, DAL"/>
            
      <!-- ContatoDAL -->
      <object name="ContatoDAL" type="DAL.Persistencia.ContatoDAL, DAL">
        <constructor-arg ref="Conexao"/>
      </object>
      
      <!-- ManterContato -->
      <object name="ManterContato" type="BLL.Negocio.ManterContato, BLL">
        <property name="Dao" ref="ContatoDAL" />
      </object>
      
    </objects>
  </spring>

Nesta seção, a tag context logo abaixo do inicio da seção completa o que está presente na configSection do Trecho de Código 4, onde temos o atributo chamado object. Ambas context e resource estão interligados a esta configSection.
Com relação aos objetos gerenciados pelo Spring se encontra dentro da tag object que é registrada através de objects onde tem o nome de serviço apontando para HTTP://www.springframework.net, neste momento, iniciando o registro das Classes no contêiner de DI do Spring.
Cada tag object contém alguns atributos, sendo os mais importantes name e type. Name recebe um valor qualquer, como uma identificação, ela não precisa ser igual ao nome da Classe, mas por convenção o segue apenas para questões de documentação caso existam muitos em um arquivo de gerenciamento. Já type, somos obrigados a colocar o nome completo da classe, seguido de uma virgula (,) e o nome do assembly,como visto no Trecho de Código 6.

Trecho de Código 6. Um objeto simples registrado.

<!-- Conexao -->
<object name="Conexao" type="IntroSpringNet.Persistencia.Conexao, IntroSpringNet"/>

O objeto em questão significa que para o Conteiner a Classe DAL.FonteDeDados.Conexao no Assembly DAL foi registrada com o nome de Conexao
Caso a tag object só tenha estes registros signfica que é apenas uma Classe sendo apontada e nada mais. Porém, quando fazer as injeções via setter ou via Construtor precisamos colocar mais uma tag dentro de object para informar ao Spring que dentro desta Classe gerenciada, o contêiner ainda precisa efetuar a Injeção de Dependencias. No Trecho de Código 7, vemos um exemplo de Injeção via Construtor das classes criadas nos Trechos de Código 1 e 2.

Trecho de Código 7. Injeção via construtor registrada no arquivo de configuração do Spring.NET

<!-- ClienteDAL -->
<!-- Injeção via Construtor -->
<object name="ClienteDAL" type="IntroSpringNet.Persistencia.ClienteDAL, IntroSpringNet">
<constructor-arg ref="Conexao"/>
</object>

Este objeto registrado no Trecho de Código 7 pela sua implementação nos mostra que não é um objeto simples, na tag constructor-arg significa que a Classe informada tem um construtor e que o parâmetro injetado é a classe registrada com o nome de Conexao, pois ref significa “fazer referência a um objeto registrado no container”. Então caso a interface IApplicationContext registre o objeto de nome ClienteDAL, ele automaticamente registrará dentro da Classe ClienteDAL, em seu construtor o tipo do argumento será a classe que está atrelada ao nome Conexao e para nosso entendimento é o mesmo objeto registrado no Trecho de Código 6, ou o nosso objeto simples.
A diferença no registro via setter é que ao invés de constructor-arg apenas chamamos a tag property, apontando a propriedade onde a Classe é injetada no setter. Como nos mostra o Trecho de Código 8.

Trecho de Código 8. Injeção vai Setter registrada no contêiner do Spring.NET

<!-- ManterContato -->
<!-- Injeção via Setter -->
<!-- Injeta ClienteDAL dentro de DAL
 DAL é tipada pela interface, logo a mesma é preenchida por ClienteDAL
-->
<object name="ManterCliente" type="IntroSpringNet.Negocio.ManterCliente, IntroSpringNet">
  <property name="DAL" ref="ClienteDAL" />
</object>

Este objeto informa que a propriedade DAL receberá a injeção do objeto ClienteDAL mostrado no Trecho de Código 7.

Implementação do Acesso aos Objetos

Agora faremos com que todas estas configurações acima funcionem plenamente. Neste trecho, vamos utilizar a fachada IApplicationContext do Spring para acessar o contêiner de Injeção de Dependências. Como no exemplo do Trecho de Código 8.

Contato contato = new Contato();
contato.NomeCompleto = "Luis Gabriel Nascimento Simas";
contato.Email = "gabrielsimas@gmail.com";
contato.Linkedin = "http://br.linkedin.com/in/gabrielsimas/";
contato.Twitter = "@gabnascimento";
contato.Facebook = "http://www.facebook.com/luisgabrielsimas";

IApplicationContext di = ContextRegistry.GetContext();
IContatoDAL dal = (ContatoDAL)di.GetObject("ContatoDAL");

dal.Salvar(contato);

Em di, lemos o arquivo de configuração, em dal, carregamos o objeto gerenciável do arquivo de configuração que contém o id contendo o valor “ContatoDAL”, o mesmo objeto do Trecho de Código 7.

Conclusão

Neste artigo bastante introdutório sobre o Spring.NET, vimos um pouco de sua base principal, que é a Injeção de Dependências, em artigos futuros falaremos de cada um dos módulos do Spring.NET de forma bastante prática.

Referências
Spring.NET Framework - http://www.springframework.net/
Documentação do Spring.NET - http://www.springframework.net/documentation.html
Injeção de Dependências/DI de Martin Fowler - http://www.martinfowler.com/articles/injection.html

Introdução ao NHibernate

noreply@blogger.com (Gabriel Sima) — Fri, 23 Aug 2013 21:09:00 +0000

Neste post, mostrarei uma pequena introdução ao NHibernate que é um framework de ORM portado para a plataforma .NET originário do framework Hibernate, um framework de bastante sucesso e utilizado até então, para a linguagem Java. Diante deste port, o NHibernate ainda é um projeto novo em constante evolução, tanto que ainda não acompanha seu “irmão” mais famoso com as grandes facilidades e opções de mapeamento mais rápido, principalmente com o uso de anotações, que em .NET são chamados de atributos – São interfaces que são utilizadas para “decorar” Classes, um substituo dos arquivos XML, tão odiados pelos programadores –que facilitam muito o dia-a-dia.
Tal framework foi criado pela JBoss, criadora do Hibernate, porém, com o tempo foi criada a NHForge que cuida diretamente do controle deste framework em site diferenciado, o NHForge.org.

Estrutura do NHibernate

Vemos a estrutura básica do NHibernate na Imagem 1.

Imagem 1. Diagrama arquitetônico do NHibernate

Na Imagem 1, podemos observar que o NHibernate é acoplado diretamente entre O Banco de Dados a sua aplicação, porém, podemos observar também que os objetos persistentes – persistent objects – são utilizados através da aplicação e, através de conexão com o NHibernate, nos dá a entender que são as peças mais importantes desta engrenagem. Podemos também observar que dentro do domínio do NHibernate vemos o mapeamento em arquivos XML – Seção XML Mappings e o arquivo de configuração do .NET, App.config ou Web.config. Fique certo de que o NHibernate, como uma Camada de Acesso aos Dados e, posteriormente de persistência, de sua aplicação, estão fortemente acoplados porque todas as outras camadas, caso existam, são totalmente dependentes destes objetos de persistência para E/S de dados. Seria muito interessante mostrar uma visão mais detalhada da arquitetura em tempo de execução do NHibernate, porém isso não é possível pelas formas diferentes de abordagens e configurações, destas separamos duas: As arquiteturas simples e detalhada.
Na sua arquitetura simples, faz com que a aplicação disponibilize suas próprias conexões utilizando o ADO.NET e gerencie suas próprias transações. Esta abordagem usa um pequeno conjunto de APIs do NHibernate, como podemos verificar na Imagem 2.

Imagem 2. Subconjunto de APIs do NHibernate

Na arquitetura Detalhada, existe uma abstração da aplicação totalmente diferente do uso das APIs do ADO.NET e deixa o NHibernate controlar e cuidar dos detalhes, permitindo assim que o mesmo cumpra o seu papel de Framework ORM, estes objetos dos quais o NHibernate faz uso internamente mostrados na Imagem 3 e posteriormente explicados um a um.

Imagem 3. Objetos presentes na Arquitetura Detalhada do NHibernate

Abaixo, listamos alguns dos objetos mais importantes presentes na Imagem 3:

ISession (NHibernate.ISession)
Um objeto single-threaded, ou seja, exclusivo por instância, e de curta duração que representa a conversa entre a aplicação e a unidade de persistência. Encapsula uma conexão ADO.NET. É uma factory para ITransaction. Mantém um cache de primeiro nível, mandatório, ou seja, sob demanda, de objetos persistentes. Este cache é utilizado quando o grafo de objetos é utilizado ou busca de objetos por identificador.

Persistent Objects and Collections
São objetos contendo estados de persistência e funções de negócio, tais objetos são sempre de curta duração e single-threaded. Estes podem ser Classes POCO, o que mais importa sobre estes é que são sempre associados com uma, somente uma ISession. Assim que uma ISession é finalizada, eles são desconectados e liberados para serem utilizados por quaisquer camadas na aplicação, isto quer dizer que pode ser utilizados como um DTO para transferência de dados de/para a Camada de Apresentação.

Transient Objects and Collections
Objetos Transientes (de curta duração, não persistidos em Banco de Dados) e Coleções
são instâncias de Classes que não estão atualmente associados com uma ISession. Eles podem ser instanciados ou não pela aplicação e sendo assim não foram ainda persistidos ou podem ser instanciados por uma ISession fechada.

ITransaction (NHibernate.ITransaction)
Esta Interface é opcional. É um objeto utilizado pela aplicação para especificar unidades de trabalho atômicas ou não. Aplica abstração de uma transação encapsulada do ADO.NET. Um ISession pode se utilizar de várias ITransaction em alguns casos.

IConnectionProvider (NHibernate.Connection.IConnectionProvider)
O Uso desta interface é opcional. Uma Factory para conexões e comandos ADO.NET. Aplica abstração de uma implementação específica e concreta de IDbConnection e IDbCommand. Não é exposto para a aplicação, mas, pode ser extendido/implementado pelo desenvolvedor.

IDriver (NHibernate.Driver.IDriver)
Uma interface que encapsula provedores ADO.NET diferentes, tais como convenções para nomes de parâmetros e convenções suportadas para uso com o ADO.NET. Seu uso é opcional.

ITransactionFactory (NHibernate.Transaction.ITransactionFactory)
Uma Factory para instancia de ITransaction. Não é exposta a aplicação, mas pode ser extendida/implementada pelo desenvolvedor. Seu uso é opcional.

Ao usar a arquitetura simples, a aplicação não utiliza nem ITransaction/ITransactionFactory e muito menos IConnectionProvider para utilizar o ADO.NET diretamente.

Neste artigo não utilizaremos todos estes objetos.

Classes POCO para uso com o NHibernate

Existem 4 regras principais para Classes POCO serem “reconhecidas” pelo NHibernate:

1) Use propriedades para campos persistentes.
2) Implemente um construtor padrão, ou seja, vazio.
3) Crie uma propriedade Identificadora, ou Id.
4) Utilize classes que não sejam sealed e use métodos virtuais.

Mapeamento do NHibernate

Atualmente, o mapeamento no NHibernate pode ser executado utilizando um arquivo XML ou com um novo projeto onde são utilizados atributos para decorarem as classes, primeiramente, vamos ao mapeamento utilizando o XML.

Mapeamento por Arquivo XML
O Mapeamento XML é a primeira etapa para a persistência com o NHibernate é onde tudo começa, na Código Fonte 1, temos um exemplo de cabeçalho estável para uso com o NHibernate. Por motivos de compilação, o NHibernate solicita que os arquivos para mapeamento contenham também a extensão .hbm como forma de ser reconhecido pelo assembly do ORM. Estes arquivos precisam ter sua propriedade Build Action setados como Embedded Resource, posto que no momento da compilação do código, o arquivo seja reconhecido e convertido para um hierarquia de classes utilizando ponto, por exemplo: temos que mapear a Classe Pessoa para persistência, então criamos o arquivo pessoa.hbm.xml e nas suas propriedades, colocamos o atributo Build Action como Embedded Resource, como mostrado na Imagem 3.

Código Fonte 1. Cabeçalho de XML para mapeamento

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="DAL"
                   namespace="DAL.Entidade">
...
...
...
....
...
</hibernate-mapping>

Como podemos ver na Código Fonte 1, temos 2 atributos na tag hibernate-mapping que são assembly e namespace.
Assembly informa em qual Projeto estão localizadas as Classes a serem buscadas pelo NHibernate no qual está sendo apontada neste arquivo XML.
Namespace é o caminho completo de onde tais classes estão dentro de um Projeto. Lembrando que quanto mais informação neste sentido é menos tempo em que o compilador perde buscando as Classes para Mapeamento em memória.

Imagem 4. Arquivo XML configuração e nomenclatura padrão NHibernate

Neste ponto, já podemos mapear as nossas Classes de Persistência. Não é obrigatório criar um arquivo para cada Classe, podemos em um arquivo só inserir todas, mas, como melhor prática, é bom que seja criado um arquivo para cada Classe, desta forma, o entendimento do Sistema fica melhor e separa bem as responsabilidades. Na Código Fonte 2, temos um exemplo de Entidade na qual vamos mapear via XML.

Código Fonte 2. Classe Carro

public class Carro
    {
        #region atributos

        private Int32 id;
        private String modelo;
        private String motor;

        #endregion

        #region Propriedades

        public virtual Int32 Id
        {
            get { return this.id; }
            set { this.id = value; }
        }

        public virtual String Modelo
        {
            get { return this.modelo; }
            set { this.modelo = value; }
        }

        public virtual String Motor
        {
            get { return this.motor; }
            set { this.motor = value; }
        }

        #endregion

        #region Construtores

        public Carro()
        {

        }

        public Carro(String modelo, String motor)
        {
            this.Modelo = modelo;
            this.Motor = motor;
        }
        #endregion

        #region Sobrescritas
        public override string ToString()
        {
            return this.id + ", " + this.modelo + ", " + this.motor;
        }
        #endregion
    }
}

Para o correto mapeamento da Entidade, mapeamos apenas as Propriedades para o arquivo XML, como descrito na Código Fonte 3.

Código Fonte 3. Arquivo XML Carro.hbm.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="DAL"
                   namespace="DAL.Entidade">

  <class name="Carro" table="Carro">
    <id name="Id" column="id">
      <generator class="identity" />
    </id>

    <property name="Modelo" column="modelo" />
    <property name="Motor" column="motor" />
   
  </class>
 
</hibernate-mapping>

Na Código Fonte 3, temos algumas informações importantes, a tag id significa que estamos mapeando a propriedade de identificação única da Entidade, ou seja, valor exclusivo que identifica os dados gravados na Classe. Dentro desta tag, temos uma tag generator que como no Banco de Dados ela é um tipo de auto incremento, utilizamos o valor de atributo identity. Os valores possíveis e permitidos pela tag generator dentro do atributo class são:

increment - Gera identificadores de qualquer tipo desde que sejam únicos e que nenhum outro processo esteja inserindo dados na mesma tabela. Não use este valor com um Cluster.

identity - Suporta campos do tipo identity, ou seja, auto incremento nos Bancos de Dados DB2, MySQL, MS SQL Server e Sybase. O identificador que é devolvido pelo Banco de Dados é convertido para o tipo da propriedade usando Convert.ChangeType. Qualquer propriedade inteira é permitida.

sequence - Usa uma Sequence criada em DB2, PostgreSQL, Oracle ou um generator do Firebird. O identificador retornado pelo Banco de Dados é convertido para o tipo da propriedade usando Convert.ChangeType. Qualquer propriedade inteira é permitida.

hilo - Usa um algoritmo de hi/lo para gerar de forma bem eficiente qualquer tipo inteiro de qualquer Tabela ou campo (por padrão, hibernate_unique_key e next_hi respectivamente) como uma fonte de valores hi. O Algoritmo de hi/lo gera identificadores que são únicos apenas para um Banco de Dados em específico. Não use este hilo com uma conexão gerenciada pelo usuário, ou seja, quando as threads não são as mesmas.
Você pode usar o parâmetro "where" para especificar um registro usado em uma tabela. Isto é muito útil se você quer usar uma tabela única para seus identificadores, com registros diferentes de cada tabela.

seqhilo - Usa um algoritmo de hi/lo para gerar de forma bem eficiente qualquer tipo inteiro, dada uma SEQUENCE criada no Banco de Dados.

uuid.hex - Usa System.Guid e seu método ToString para gerar identificadores do tipo String. O tamanho da String depende do formato selecionado.

uuid.string - Usa um novo System.Guid para criar um tipo byte[] que é convertido para String.

guid - Usa um novo System.Guid como identificador.

guid.comb - Usa o algoritmo para gerar um novo System.Guid.

native - captura tipos identity, sequence ou hilo dependendo das capacidade existentes no Banco de Dados.

assigned - Deixa a aplicação decidir por um identificador para o objeto antes de Save() ser chamado.

foreign - Usa o identificador de outro objeto associado. Normalmente usado em conjunção com uma associação com chave primária com a tag <one-to-one>

Para a Tag property, não é necessária muita informação, são as propriedades da Classe Carro que refletem os campos da Tabela.

Mapeamento por Anotação/Atributo

Todos nós já sabemos que o NHibernate precisa de mapeamentos efetuados através de arquivos XML para que possa colocar em memória o ORM para a persistência. Para facilitar este trabalho foi criado um Projeto desenvolvido inicialmente por John Morris e que depois passou às mãos de Pierre Henri Kuaté, mais conhecido como KPixel. Este projeto decora as Classes com atributos o que torna o arquivo XML desnecessário posto que o Projeto gera um Stream para a memória como o XML faria, este projeto se chamado NHibernate Attributes que utiliza o assmbly NHibernate.Mapping.Attribute. Um exemplo de Classe mapeada com o assembly NHibernate.Mapping.Attributes na Código Fonte 4.

Código Fonte 4. Classe “decorada” com atributos NHibernate

    [Serializable]
    [Class(Schema = "RevistaArtigo02", Table = "Carro")]
    public class Carro
   
    {
        #region atributos
       
        private Int32 id;
        private String modelo;
        private String motor;

        #endregion

        #region Propriedades
        [Id(Name="Id",Column="id"),Generator(1,Class="identity")]
        public virtual Int32 Id
        {
            get { return this.id; }
            set { this.id = value; }
        }

        [Property(Column="modelo")]
        public virtual String Modelo
        {
            get { return this.modelo; }
            set { this.modelo = value; }
        }

        [Property(Column="motor")]
        public virtual String Motor
        {
            get { return this.motor; }
            set { this.motor = value; }
        }

        #endregion

        #region Construtores

        public Carro()
        {

        }

        public Carro(String modelo, String motor)
        {
            this.Modelo = modelo;
            this.Motor = motor;
        }
        #endregion

        #region Sobrescritas
        public override string ToString()
        {
            return this.id + ", " + this.modelo + ", " + this.motor;
        }
        #endregion
    }
}

Arquivo de Configuração do NHibernate

O Nhibernate é um framework bastante versátil no qual permite que o configuremos via Código ou via arquivo XML, neste artigo vamos abordar o mapeamento via XML, para maiores informações sobre a inicialização do NHibernate via código,e só acessar o site http://nhforge.org/doc/nh/en/index.html#session-configuration. O Nhibernate precisa ser inicializado através da interface ISessionFactory, com ela, todas as Entidades são compiladas e colocadas na memória, assim como os comandos deste arquivo XML são aceitos e colocados em memória aguardando sua execução. Como padrão, o NHibernate aceita como arquivo de configuração contendo a extensão .cfg.xml, normalmente cria-se um arquivo na raiz do Projeto chamada hibernate.cfg.xml. Neste arquivo, registramos inclusive a string de conexão, dialeto envolvido e outras configurações de ambiente. Na Código Fonte 5, vemos um exemplo deste arquivo.

Código Fonte 5. Arquivo de configuração hibernate.cfg.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
      <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
   
      <!-- Aqui você deve coloca o seu Connectio String -->
      <property name="connection.connection_string">
        Data Source=ALLSPARK\SQLEXPRESS;Initial Catalog=RevistaArtigo02;Integrated Security=True
      </property>
   
      <property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
    <property name="show_sql">true</property>
    <property name="current_session_context_class">thread</property>
  </session-factory>
</hibernate-configuration>

Diante desta informação, já podemos instanciar a nossa ISessionFactory, que funciona como uma fachada. O mais importante é que devemos sempre prezar pela performance, é necessário que criemos uma Classe que gere um Singleton para que o NHibernate possa ser carregado e controlado de forma independente e desacoplada do código, na Código Fonte 6, temos um exemplo de Classe que contém este padrão de Projeto. Esta Classe acessa o arquivo de configuração e faz com que toda a “mágica” do que fizemos até agora aconteça e que faça a conexão com o Banco de Dados

Código Fonte 6. Classe NHibernateUtil

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using NHibernate;
using NHibernate.Cfg;

namespace DAL.Reuso
{
    public sealed class NHibernateUtil
    {
        #region Atributos

        private static readonly ISessionFactory fabricaDeSessao;
        private const String CodSessaoAtual = "nhibernate.current_session";

        #endregion

        #region Construtor

        static NHibernateUtil()
        {
            try
            {
                ISessionFactory fabrica = new Configuration().Configure().AddAssembly("DAL").BuildSessionFactory();
               
            }
            catch (Exception)
            {
               
                throw;
            }
        }

        #endregion

        #region Métodos de Controle

        public static ISession PegaSessaoEmUso()
        {
            ISession sessao = fabricaDeSessao.GetCurrentSession();

            if (sessao == null)
            {
                sessao = fabricaDeSessao.OpenSession();
            }

            return sessao; 
        }

        public static void FecharSessao()
        {
            ISession sessao = fabricaDeSessao.GetCurrentSession();

            if (sessao != null)
            {
                sessao.Close();
            }
        }

        public static void FecharFabricaDeSessao()
        {
            if (fabricaDeSessao != null || !fabricaDeSessao.IsClosed){
                fabricaDeSessao.Close();
            }
        }

        #endregion

    }
}

Esta Classe, o leitor pode já utilizá-la como está em seus projetos e até aprimorá-la mais para que fique mais genérica a seu uso, assim como em futuros artigos que faremos de forma mais prática demonstrando o uso de Generics, Fachadas e outros padrões de projeto que facilitem a implementação nos projetos de nossos leitores. Já criamos uma Classe que irá e muito facilitar o nosso trabalho de acesso a base de dados, diante disto, vamos mostrar a melhor forma de utilizá-la.

Acessando a Base de Dados através do NHibernate

Criamos na Código Fonte 6 uma Classe para acesso a Base de Dados, agora, veremos como que NHibernate se comunica com a Base de Dados para permitir que a persistência seja efetuada.
Inicialmente, como uma melhor prática, o NHibernate trabalha com transações, esta é uma forma bem segura de trabalho, posto que caso algo dê errado, um Rollback pode ser dado, caso contrário, um commit grava as alterações no Banco de Dados e a conexão é finalizada, salvo para operações de busca, onde a sessão continua em aberto. Devemos ter isso me mente até mesmo quando o projeto solicitar que utilizemos mais de uma Classe em uma transação. O Nhibernate abre uma transação, efetua o trabalho que precisa fazer, trata este trabalho, caso execute com sucesso, executa um commit, caso não executa um Rollback e posterimente fecha a sessão. Uma Sessão é composta de Transação, execução e Fechamento, o fechamento pode ser um finally com um comado de fechamento ou simplesmente uma execução de operações, neste caso, por exemplo, seria um INSERT, UPDATE e DELETE suficientes para fechar a Sessão o que também não seria necessário que a fechássemos, um fragmento deste trabalho, pode ser visto na Código Fonte 7 já com o uso de nossa Classe NHibernateUtil.

Código Fonte 7.NHibernate interagindo com o Banco de Dados

        public void Gravar(Carro carro)
        {
            ISession sessao = NHibernateUtil.PegaSessaoEmUso();
            ITransaction transacao = sessao.BeginTransaction();

            sessao.Save(carro);
            transacao.Commit();

            NHibernateUtil.FecharSessao();
        }

    }

Como sabemos, o Banco de Dados isola as operações através das transações, diante disso, temos um singleton abrindo e fechando a sessão de forma protegida.
Agora, é só criar um Projeto e implementar a solução. E isso é assunto para um outro artigo.

Conclusão

O NHibernate é mais uma opção frente aos outros frameworks ORM existentes no mercado, ele não perde em nada com relação ao Microsoft ADO.NET Entity Framework e outros. Vimos neste artigo o poder deste framework que já faz bastante sucesso no meio Java e que pode também fazer bastante sucesso no mundo .NET. Vimos apenas 20% de todo o framework e com esta informação, já podemos trabalhar em um Projeto de médio porte. Em artigos próximos, vamos falar de outras partes do NHibernate. Este por ser um framework um tanto extenso se fizéssemos aqui a cobertura deste, com certeza ficaria cansativo ao leitor.

Fortaleça sempre o trabalho em equipe porque sozinho nada se consegue neste mundo, é um prazer tê-lo como leitor.

Forte Abraço

VB.NET - Module

noreply@blogger.com (Gabriel Sima) — Fri, 16 Aug 2013 21:11:00 +0000

Em nosso primeiro artigo sobre VB, vamos falar sobre seus conceitos básicos, diante disso, vamos começar por Module, por ser o trecho de código mais elementar no VB.NET, mais adiante veremos outras formas de codificação como Classes, tipos e afins.

A palavra chave Module define um tipo de classe, com algumas exceções. Primeiro de tudo, qualquer função pública, subrotina, propriedade ou variável de instância ou membro definido dentro do escopo de um Module é definido como um membro compartilhado, ou seja, pode ser utilizado globalmente em sua aplicação, este tipo de membro definido permite ao desenvolvedor simular um escopo global dentro de sua aplicação. Abaixo, vemos a estrutura principal e padrão de um módulo, este é o Módulo principal de uma Console Application gerada pelo Visual Studio:

Module Module1 
 Sub Main()
 End Sub 
End Module

Vamos então, utilizar um projeto com o Module, em seu Visual Studio, crie na sua Solution um Projeto Console Application no VB com o nome DivertindoSeComModule e digite o código como no Trecho de Código abaixo:

Module Module1

    Sub Main()
        'Executa a subrotina MostraBanner
        MostraBanner()

        'Pega o nome do usuário e diz "Olá"
        ApresentaUsuario()

        Console.ReadKey()
    End Sub

    Sub MostraBanner()
        Dim currColor As ConsoleColor = Console.ForegroundColor

        'Muda a cor do texto para amarela
        Console.ForegroundColor = ConsoleColor.Yellow

        Console.WriteLine("*** Bem vindo ao nosso primeiro projeto em VB ***")
        Console.WriteLine(" Este programinha simples, ilustra o papel ")
        Console.WriteLine("do Tipo Module")
        Console.WriteLine("*************************************************")

        'Devolve a cor original
        Console.ForegroundColor = currColor
    End Sub

    Sub ApresentaUsuario()
        Dim userName As String
        Console.Write("Entre com o seu nome: ")
        userName = Console.ReadLine()
        Console.WriteLine("Olá {0}. É um prazer tê-lo conosco.", userName)
    End Sub

End Module

Este programa ao ser executado, pressionando F5, retornará a seguinte saída:

 "*** Bem vindo ao nosso primeiro projeto em VB ***

Este programinha simples, ilustra o papel

do Tipo Module

*************************************************

Entre com o seu nome: Luis Gabriel N. Simas

Olá Luis Gabriel N. Simas. É um prazer tê-lo conosco."

Projetos com Multiplos Modules

Em nosso exemplo atual, mostramos que o método Main() pode acessar diretamente os métodos MostraBanner e ApresentaUsuario. Porque estes métodos estão definidos dentro do mesmo Module junto com Main(), não é necessário que coloquemos como prefixo destes métodos o nome de Module1. Porém, caso precise fazê-lo, precisamos refatorar Main() como segue:

Sub Main()
        'Executa a subrotina MostraBanner
        Module1.MostraBanner()

        'Pega o nome do usuário e diz "Olá"
        Module1.ApresentaUsuario()

        Console.ReadKey()
    End Sub

No trecho acima, é completamente opcional esta sintaxe (não influencia nem mesmo na performance). Mas, digamos que vamos precisar criar um novo Módulo em nosso Projeto - chamado MeuModulo - dentro do mesmo arquivo .vb que cria um método parecido com o ApresentaUsuario de Module que contém a Main():

Module MeuModulo
 Public Sub ApresentaUsuario()
  Console.WriteLine("Olá Usuário Maroto...")
 End Sub
End Module

Agora, se você quiser chamar ApresentaUsuario de MeuModulo de dentro da Main(), aí sim você vai precisar colocar como prefixo explicitamente o nome do Módulo. Caso isso não aconteça, o método Main irá procurar por Module.ApresentaUsuario, se este método existir o compilador não retornará erro, mas caso não exista, teremos problemas. Vejamos abaixo a forma de chamada correta do método Main():

Sub Main()
        'Executa a subrotina MostraBanner
        MostraBanner()

        'Pega o nome do usuário e diz "Olá"
        MeuModulo.ApresentaUsuario()

        Console.ReadKey()
    End Sub

Novamente, para fixar: que um único projeto que define muitos Modulos não é necessário que se use o nome do Módulo como prefixo dos métodos que serão utilizados a não ser que os nomes sejam ambíguos assim como no caso do método ApresentaUsuario que existe em Module1 e MeuModulo, neste caso sim, precisamos informar ao compilador qual é o correto do contrário, Main() pegará de seu Module1.
Então, vamos criar mais um Módulo neste nosso projeto atual, chamado ModuloMatematico, como segue:

Module ModuloMatematico
    Function Soma(ByVal x As Integer, ByVal y As Integer)
        Return x + y
    End Function

    Function Subtracao(ByVal x As Integer, ByVal y As Integer)
        Return x - y
    End Function

End Module

Como estamos no mesmo Projeto, basta colocar o nome Soma no metodo Main() de Module1 que ele irá funcionar corretamente:

Sub Main()
        ...
 ...
 'Soma dois numeros
 Console.WriteLine("O resultado da soma é {0}.",Soma(2,2))
 
 'Subtrai dois Números
 'Colocar o nome do módulo como prefixo neste caso, é opcional 
 'É apenas uma demonstração de generalidade
 Console.WriteLine("O resultado da subtração é {0}", ModuloMatematico.Subtracao(2,2))
        Console.ReadKey()
    End Sub

Não se preocupe com relação a explicação de o que é uma Function e o que significa o ByVal, posto que mais adiante, estarei escrevendo um artigo sobre Funções e Subrotinas com VB.NET.

Módulos não são "instanciáveis"

Outra regra do tipo Module é que ele não pode ser diretamente criado usando a palavra new - qualquer tentativa de fazê-lo irá retornar em erro de compilação. Como o trecho abaixo irá retornar em erro:

'Isto não existe no .NET Framework 4.0
Dim m as New Module1()

Uma melhor explicação é que um Módulo apenas expõe membros compartilhados.

Membros dos Módulos

Para incrementar nosso estudo sobre Tipos de Módulos, saiba que módulos podem ter membros adicionais além de apenas subrotinas e funções. Se o leitor amigo quiser definir campos tais como propriedades ou eventos, você é livre para fazê-lo. Por exemplo, você precisa atualizar MeuModulo para receber uma única parte de um dado contendo uma String publica. Veja que o método ApresentaUsuario() agora irá imprimir este valor quando solicitado:

Module MeuModulo
 Public ContaUsuario As String
 Public Sub ApresentaUsuario()
  Console.WriteLine("Olá {0}",ContaUsuario)
 End Sub
End Module

Agora, vamos implementar o método refatorado:

Sub Main() 
 ... 
 'Grava o nome do usuário e chama ApresentaUsuario
 ContaUsuario = "Fred" 
 MeuModulo.ApresentaUsuario() 
 ... 
End Sub

Este foi o nosso primeiro artigo sobre VB.NET como prometido para os nossos leitores que precisam aprender e dominar tal linguagem, primeiramente, vamos explicar e detalhar o básico da linguagem sem muita firula, porque muito material sobre programação fala do be-á-bá que chega a ser cansativo, tentei ser o mais sucinto possível e sempre usando um Projeto por artigo.

Valorize sempre o trabalho em equipe porque não se consegue atingir nenhum resultado sozinho.

Obrigado por visitar o Blog, é um prazer tê-lo como leitor e até o próximo artigo.

Uma idéia para um Sistema de Vendas online

noreply@blogger.com (Gabriel Sima) — Fri, 16 Aug 2013 02:28:00 +0000

Como o Blog é jovem e a minha idéia é fazê-lo bem democrático, mas também muito polêmico, posto que de que adianta ficar colocando artigos "água com açúcar" por aqui, artigos mais simples vão servir apenas para os leitores que precisam de algo rápido e bem organizado para resolver os seus problemas do dia a dia, isso acontece muito comigo também e foi pensando nisso e também para que este Blog seja sempre visitado e encontrado por todos os leitores que são entusiastas, profissionais, curiosos, loucos e afins, enfim, toda a gama de leitor que goste ou que queira aprender a programar utilizando como exemplos os projetos do mundo real posto que se fosse de outra forma, qual a graça teria em se criar um Weblog sobre desenvolvimento? pois é, nenhuma.
O título desta postagem ficou bastante vago, ele ficou vago principalmente porque a primeira situação é que não vou usar apenas uma linguagem de programação, mas sim Java, C# e VB.NET e cada uma delas têm as suas peculiaridades, não é mesmo? inicialmente, vamos fazer uma listagem do quê vamos usar, ou seja, a arquitetura, mas de antemão já informo a vocês que vou usar o Oracle como Banco de Dados até para sair um pouco do padrão do MySQL no Java, que agora está sendo substituído pelo MariaDB - os criadores do My depois que o venderam para a Oracle, estão criando outro produto de sucesso, vamos ver para quem vão vender e por quanto -, no .NET (seja C# ou VB) o uso do SQL Server é o padrão.
Mas, para deixar o pessoal mais à vontade, eu vou usar Triggers, Stored Procedures, Functions, Sequences e outros objetos com o Oracle e posso fazer o mesmo utilizando o Microsoft SQL Server 2008 R2 como uma forma de treinar o Leitor para aplicar as Regras de Negócio também no Banco de Dados e acioná-los via Regra de Negócio do Sistema.

O que é necessário para um Sistema de Vendas online?
Bem, de acordo com uma necessidade, um Sistema de Vendas online é dividido em duas partes: a Frente de Loja e a Retaguarda.
Na Frente de Loja, ocorre toda a interação com o cliente, ou seja, a home onde o cliente escolhe o produto, lista o produto, faz a compra, faz o pagamento e etc. A parte de interação com o cliente.
Já a Retaguarda é a parte mais importante para o setor administrativo, é nele que são calculados o lucro, o estoque, as comissões e a geração dos relatórios em tempo real.
No levantamento de Requisitos, temos as seguintes funções da Frente de Loja:

Venda de Produto;
Busca de Produto;
Emissão de Pedido;
Integração com gateway de pagamento;
Cadastro de cliente;

Temos na Retaguarda, as seguintes funções, iniciais claro, podemos adicionar algo durante o desenvolvimento:

Controle de Estoque;
Controle de Pedidos;
Controle de Vendas;
Controle de Entrega de Produtos;
Controle Logístico;
Controle de Comissão para Vendedores;
Relatórios Diversos;

Inclusive, a Frente de Loja, em algumas funcionalidades, faz acesso à Retaguarda, como podemos ver no caso da Venda de Produto e o Controle de Estoque que estão ligadas.

Cada uma destas funcionalidades será melhor abstraída com o intuito de se criar um Diagrama de Casos de Uso ou uma seleção de Estórias de Usuário para criar um Backlog de Produto caso usemos Scrum para controle de nosso cronograma.

No levantamento dos requisitos, já temos um noção do que vamos precisar na Arquitetura.

Vamos precisar criar uma Camada intermediária para controlar a Frente de Loja e a Retaguarda e eu vou chamar esta Camada de Centro de Comando e Controle da Aplicação, nela poderemos fazer a interligação entre a Camada de Frente de Loja e a Camada de Retaguarda.

Já temos uma noção de como vamos começar a separar as partes importantes do Sistema, agora vamos verificar as permissões de segurança.

Permissões e Segurança

Os atores desta nossa trama e dos nossos Casos de Uso e Estórias de Usuário são: o Cliente, o Administrador e o Funcionário.

O Cliente é o responsável por fazer as compras e interagir com a Frente de Loja.

O Administrador é o responsável pelos cadastros dos produtos que são efetuados na retaguarda.

O Funcionário é o responsável pela extração dos Relatórios, Controle de Entrega de Produtos, Controle Logístico, Controle de Comissão dos Vendedores ou Afiliados.

Arquitetura para o Java

Cenário 1:

Para Persistência, vamos usar o Hibernate 3, até para que possamos fazer um Projeto de Migração para Hibernate 4.
Para Mapeamento das Entidades vamos utilizar o JPA 2 com NamedQuery e Anotações.

EJB 3.1 para Injeção de Dependências e componentização, vamos criar os módulos de Frente de Loja e Retaguarda

Para a Camada de Apresentação vamos utilizar a Web com o Primefaces com JSF 2

Para a Camada de Segurança e Controle de Acesso, podemos utilizar o Spring Security.

O Container que iremos utilizar será o GlassFish.

O Spring será usado apenas seu Módulo de Segurança, posto que o EJB já faz o trabalho de Injeção de Dependências.

Cenário 2:

Persistência: Hibernate 3
Mapeamento das entidades será feita com JPA 2 com NamedQuery e Anotações.

Arquitetura MVC utilizando ManageBean

Camada de Apresentação: JSF com PrimeFaces

Bonus:

WebServices para consumo e acesso de Dispositivos Móveis.

Restful Services para consumo de dispostivios Móveis.

Aplicativo para iPad compatível com a Loja.

Aplicativo para Android compatível com a Loja.

Barramento utilizando o Mule que é um Enterprise Service Bus gratuito.

Todos os cenários serão forçosamente utilizados os padrões de Fachada, Service Locator, Business Delegate e principalmente o uso dos tipos Genéricos com o Java. Deixando bem claro que tais padrões são obrigatórios dentro do EJB, caso não sejam utilizados, o modelo não será certificado. Vamos abusar do Ajax.

Arquitetura para o .NET

- Persistência com NHibernate (projeto de atributos como annotations no Java)

- Container de IoC com Spring.NET

- Na Camada de Apresentação vamos utilizar o ASP.NET MVC 4 com o Razor.
- Desenvolvimento será efetuado em 3 camadas: DAL (Camada de Dados), BLL (Camada de Regra de negócios) e Apresentação.

Bonus:

Integração com dispositivos Móveis

Consumo de WebServices de todas as funcionalidades do Sistema.

É desnecessário dizer que usaremos o HTML5 e o CSS3 tanto no Java, que será implementado via primefaces e no MVC 4 utilizando.

Arquitetura para o PHP
A minha idéia é criar um página do zero utilizando o PHP, ou seja, vou fazê-lo todo orientado a objetos, diante disso, vai demorar um pouco mais até porque é necessário que eu faça uma reestudo sobre a nova versão do PHP e ver o que mudou com relação a versão anterior. Porém, estou com certa dúvida se utilizo ou não frameworks, o framework que eu utilizaria seria o cakePHP que é um framework MVC e de fácil compreensão e utilização.

- Camada de Apresentação: HTML5 + CSS3 + jQuery + jQueryUI
- Controle de Sessão e Camada de Segurança.

Os Rumos dos Artigos

Sei que muitos leitores estão querendo saber como que faremos os artigos subsequentes para que tornemos este Projeto uma realidade. Bem, eu posso atender a todos os gostos e como eu disse, este blog é bastante cosmopolita. Para aqueles que já tem um bom conhecimento e que não precisa conhecer os conceitos básicos das linguagens já iniciarei com o primeiro artigo do Sistema. Mas, caso o leitor não se sinta confortável com os códigos que está vendo e necessite de um apoio mais básico ou intermediário, então, também farei, em paralelo com os artigos do Sistema, artigos comentando o básico de todas as linguagens empregadas neste blog, é uma forma de ajudar a todos e que consigam andar e acompanhar o "ritmo".

Então, o primeiro artigo que faremos será a Modelagem do Sistema contendo a abstração principal, Formulários de Caso de Uso, Diagramas de Casos de Uso e etc. O primeiro artigo de codificação do Sistema será feito em Java e vamos utilizar o primeiro cenário: EJB. O que isso significa: que farei primeiramente um artigo sobre EJB para dar uma base ao leitor e logo em seguida, vamos fazer as codificações de dentro do Sistema. Não se preocupe em baixar os códigos, posto que em cada artigo informaremos o que deve ser baixado e como ser instalado. Já para os leitores que conhecem um pouco menos do Java, vamos começar com Orientação a Objetos baseado no Java, Orientação a Objetos baseado no C# e Orientação a objetos baseado no VB.NET.

Então, até o próximo artigo e lembre-se sempre de fortalecer o trabalho em equipe porque não se consegue nada e nenhuma vitória sozinho.

É um prazer tê-lo - ou tê-la - como leitor - ou leitora.

Forte Abraço a todos.

Utilizando o padrão Java Bean \ POJO em suas Classes Java

noreply@blogger.com (Gabriel Sima) — Thu, 15 Aug 2013 02:46:00 +0000

Classe JavaBean

Uma Classe Java Bean é um POJO significa Plain Old Java Object, ou seja, o bom e velho objeto escrito em Java puro, mais ou menos é este o significado.

Por que utilizar um Java Bean?

Tal Classe segue o padrão da Oracle para Classes Java e que pode ser utilizada como entidades e que são mundialmente aceitas e permitidas em qualquer projeto. Caso você, nobre e caríssimo leitor, chegar em uma entrevista ou mesmo em uma prova destas de RH, um processo seletivo, e criar tal classe de forma correta, pode ser que o emprego não seja seu, mas pelo menos você estará sendo visto com outros olhos pelo técnico que irá fazer a entrevista com você.

Como é estruturado um Java Bean?

Um Java Bean precisa ser Serializado. Em caso de transferência da Entidade em um ambiente de cliente/servidor, ele possa ser transferido e resgatado com facilidade sem problemas em suas threads, onde ele possa ser sincronizado.

Um Java Bean precisa conter atributos privados. Estas Classes precisam respeitar o encapsulamento protegendo seus atributos e se comunicando com o mundo exterior através de mensagens, ou seja, através de métodos de leitura e escrita nestes atributos, os chamados Getters/Setters.

Um Java Bean precisa conter um construtor vazio. Como padrão, tal Classe precisa de um construtor padrão criado para que seja criada. Esta é a forma mais primária para se inicializar tal classe, muitos frameworks, tais como Hibernate, nos obriga a ter pelo menos um construtor Default em nossa Entidade, se suas Classes sempre forem Java Beans, isso não será problema, por isso que devemos sempre utilizar este padrão.

Um Java Bean precisa conter um construtor com parâmetros. Para receber todos os valores dos atributos dentro do domínio da Classe, não é preciso colocar os relacionamentos, apenas os atributos padrão. Este construtor serve para que quando instanciamos a Classe já possamos passar todos os valores diretamente para ela sem a necessidade de usar os métodos para passar as mensagens.

Um Java Bean precisa conter métodos publicos Getters\Setters. Estes métodos servem de entrada\saída para acesso aos atributos pelas classes externas ao pacote.

Um Java Bean precisa sobrescrever o método ToString(). Este método deve imprimir o conteúdo do objeto, a forma correta é o método retornar todos os valores dos atributos, no modo padrão, quando o objeto é impresso, ele apenas mostra o caminho do objeto e não o seu conteúdo. Tal método é oriundo da Super Classe java.lang.Object.

Um Java Bean precisa sobrescrever o método HashCode(). Este método serve para controlar as instâncias em memória, com ela é possível verificar quais são e quando equals() é acionado, HashCode ajuda na diferenciação dos objetos. Tal método é oriundo da Super Classe java.lang.Object.

Um Java Bean precisa sobrescrever o método Equals(). Este método verifica se objetos são idênticos, o padrão é uma forma muito pobre de verificação e um tanto fraca, também é importante a sobrescrita deste método.

Um Java Bean precisa conter uma identificação única. Este atributo é opcional, mas ter um id é muito importante para controlar a ocorrência de tais entidades e objetos.

Tal método é oriundo da Super Classe java.lang.Object.
Abaixo, vemos na prática uma Classe JavaBean POJO.

package com.blogger.peripeciasdesenvolvedor.entidade;

import java.io.Serializable;

public class JavaBeanPadrao implements Serializable{

private static final long serialVersionUID = 8982198782797245834L;

 //Atributos 
 private Integer id;
 private String nome;
 private String sobrenome;
 private String email;
  
 //Construtor Padrão
 public JavaBeanPadrao() {
  
 }

 //Construtor com Parâmetros
 public JavaBeanPadrao(Integer id, String nome, String sobrenome,
   String email) {
  super();
  this.id = id;
  this.nome = nome;
  this.sobrenome = sobrenome;
  this.email = email;
 }

 //Getters e Setters
 public Integer getId() {
  return id;
 }

 public void setId(Integer id) {
  this.id = id;
 }

 public String getNome() {
  return nome;
 }

 public void setNome(String nome) {
  this.nome = nome;
 }

 public String getSobrenome() {
  return sobrenome;
 }

 public void setSobrenome(String sobrenome) {
  this.sobrenome = sobrenome;
 }

 public String getEmail() {
  return email;
 }

 public void setEmail(String email) {
  this.email = email;
 }
 
 //Sobrescritas de java.lang.Object
 @Override
 public boolean equals(Object obj) {
  
  if (obj instanceof JavaBeanPadrao){
   JavaBeanPadrao pojo = (JavaBeanPadrao) obj;
   
   if (pojo.id != null && this.id != null){
    return pojo.getId().equals(id);
   }
  }
  
  return false;
 }

 @Override
 public int hashCode() {
  
  return this.id != null ? this.id.hashCode():0;
 }

 @Override
 public String toString() {
  
  return this.id + ", " + this.nome + ", " + this.sobrenome + ", " + this.email;
 }

}

Vamos agora para a implementação deste nosso Java Bean.
O exemplo abaixo,ilustra o uso do construtor padrão, setters e impressão com ToString().

package com.blogger.peripeciasdesenvolvedor.principal;

import com.blogger.peripeciasdesenvolvedor.entidade.JavaBeanPadrao;

public class Principal {

 public static void main(String[] args) {
  
  //Instancia do POJO construtor padrão
  JavaBeanPadrao pojo = new JavaBeanPadrao();
  
  //Populando os atributos através do encapsulamento
  pojo.setId(1);
  pojo.setNome("Gabriel");
  pojo.setSobrenome("Simas");
  pojo.setEmail("gabrielsimas@gmail.com");
  
  //Imprimindo via ToString()
  System.out.println(pojo);
  
 }

}

A saída do exemplo acima é:


1, Gabriel, Simas, gabrielsimas@gmail.com

Como podemos notar no código anterior, a saída e justamente o nosso método ToString() modificado corretamente, veja que existe uma diferença, posto que o resultado está totalmente transparente e também demonstra como o nosso setter é eficiente de forma que passou os valores para os atributos corretamente, sem a necessidade de acessá-los diretamente. O próximo trecho de código ilustra o uso do construtor com parâmetros e sua posterior Impressão.

package com.blogger.peripeciasdesenvolvedor.principal;

import com.blogger.peripeciasdesenvolvedor.entidade.JavaBeanPadrao;

public class Principal {

 public static void main(String[] args) {
  
  //Instancia do POJO com construtor com parametros
  JavaBeanPadrao pojo = new JavaBeanPadrao(1, "Gabriel", "Simas", "gabrielsimas@gmail.com");
  
  //Imprimindo via ToString()
  System.out.println(pojo);
  
 }

}

O resultado deste código será
1, Gabriel, Simas, gabrielsimas@gmail.com
O resultado é o mesmo, sendo que escrevemos bem menos para atingir o mesmo resultado, este tipo de modificação se chama refatoração ou refactoring, onde executamo as mesmas tarefas de forma otimizada.
Neste artigo vimos como se constrói um Java Bean simples e funcional, o que nos dará uma boa base para os próximos artigos, lembre-se que neste Blog, a informação é sempre sequencial, ou seja, um artigo complementa o artigo anterior de forma a sempre utilizar o que já fora mostrado aqui. Lembre-se sempre de fortalecer o trabalho em equipe, afinal de contas, não se vence sozinho. Forte Abraço, muito obrigado por sua visita e até a próxima.

O que serão as peripécias

noreply@blogger.com (Gabriel Sima) — Wed, 14 Aug 2013 21:22:00 +0000

Neste primeiro post do Blog, não vou falar sobre códigos, nem de bits e muito menos de bytes. Vou apenas falar um pouco da minha experiência de programador e como eu comecei neste ramo que até hoje me deixa muito feliz.

Tudo começou no ano de 1996, no mês de Outubro, eu tinha 14 anos naquela época e já tinha estudado um pouco sobre Eletrônica e estava disposto a cair dentro dos Circuitos Integrados já bastante empolgado, estava querendo entrar na Escola Técnica Rezende-Hamel... não me lembro se o Hamel é com "H", pois bem... meu pai tinha uma coleção do Jornal O Globo do final da década de 80 do século XX, se chamava Curso Globo de Microinformática, nele eu vi fotos do Bill Gates nem novo dizendo que a "Microsoft ainda seria uma grande empresa" dada a antiguidade da coleção.
Dentro dela, aprendi sobre algoritmos, estruturas de dados e sobre a Análise Estruturada moderna, o que hoje em dia se ensina em todas as universidades e a linguagem era o BASIC, porém, o BASIC na década de 80 era utilizado por cada fabricante a seu bel prazer, por exemplo, a Apple detinha um BASIC que ser magnífico para a criação de jogos... pois tinha uma função chamada "scroll" que fazia o trabalho de colocar os bits em uma nova linha em uma matriz e fazia um efeito de se movimentar pela tela como os jogos do tipo Scroll hoje em dia. Bem, eu comecei a usar o chinês e a fazer programar e algoritmos em uma folha de papel, na época eu estudava no CEMADE - Complexo Educacional Avenida dos Desfiles, era uma escola municipal que funcionava dentro da Passarela do Samba, aqui no Rio de Janeiro, uma Cidade Maravilhosa. Confesso que era um bom aluno e lá já detinha alguns amores de adolescente, alguns correspondidos outros não, mas que não sinto saudades daquela época, a única saudade mesmo é que eu apenas estudava: como eu era feliz e não sabia!
Diante deste cenário, meu pai, que não tinha muitas posses comprou um IBM 486 DX2 comprado na Loja Garson, atualmente seria uma Insinuante ou Ricardo Eletro se fôssemos seguir de fusão em fusão.
A priori eu vi naquela máquina algo inusitado, vi que o teclado começava com QWERTY e não com ABCDE... achei-o totalmente complicado.
A Plataforma era o Windows 3.11 for Workgroups e logo em um mês já o estava dominando graças ao Manual do Windows que antigamente era do peso e tamanho de uma Bíblia e muito bem escrito... hoje em dia algo do gênero só comprando livros do Minasi.
Aprendi a usar o mouse, no início foi meio estranho, mas depois passei a me acostumar com o dispositivo e fí-lo uma extensão de minha mão.
Encontrei o QBASIC dentro do Windows, o QBASIC tinha muitas limitações, mas dava para criar os programas que eu tinha escrito em papel e fazer funcionar tudo o que eu precisava, principalmente o meu primeiro programinha: um solucionador de Equações de primeiro grau e segundo grau... A programação, principalmente o BASIC, começou a me ajudar e fazer com que o PC agregasse valor na minha vida e eu iniciava a minha vida profissionall. Após isso, estava ávido por um Windows 95 e como todo adolescente eu tinha vontade de jogar. Eu comprava, naquela época, a Revista do CD-ROM que hoje se chama WWW.COM.BR se não me falha a memória e lá tinham jogos que rodavam sempre em MS-DOS 6.22 e era justamente o Sistema Operacional existente na minha máquina. E me lembro de que também veio um Guia do Usuário do MS-DOS 6.22 e este guia ia do básico ao avançado e eu comecei a aprender a controlar a memória RAM via autoexec.bat e config.sys para que eu pudesse melhorar a memória usei a memória EMS... colocava buffers e por aí eu ia e conseguia rodar jogos como Top Gun: Fire at Will e Quake I dentro da máquina, ficavam meio lentos, mas eu conseguia jogá-los e com isso comecei a me interessar em aprender o que fazia tudo aquilo funcionar.
Hoje em dia eu crio Sistemas Profissionais Web utilizando .NET com C# e Java EE e colocarei aqui neste Blog a minha próxima aventura que é aprender e dominar a programar em VB.NET posto que estou precisando levantar alguns projetos neste CLR. Não vou deixar de publicar artigos em C# e Java.

Espero que gostem dele.

Forte Abraço a todos.