Veja como se dar bem na onda da arquitetura orientada a serviços

Venho percebendo o quanto SOA está crescendo no mercado atualmente. Por este motivo começarei a postar aqui alguns artigos sobre esse assunto, segue o primeiro deles publicado na Info:

Pronto para o SOA?

Débora Fortes, da INFO 25 de setembro de 2008

A cena se repete na maior parte das empresas. São dezenas de sistemas independentes operando ao mesmo tempo, e fica difícil fazer tudo conversar. É aí que entra o SOA (Service Oriented Architecture, conceito voltado para a integração), a arquitetura orientada a serviços. A idéia é integrar as tecnologias, num conceito análogo a peças de um jogo de Lego. Uma pesquisa do IDC aponta que 58% das empresas no mundo estão estudando o SOA, 18% colocaram o conceito em produção e 13% têm um projeto piloto. Somente 11% declararam que não estão fazendo nada a respeito.
Para que o SOA entre em prática, começa a surgir uma demanda por profissionais de TI. “Vários de nossos clientes têm nos pedido indicações nessa área”, afirma Fernando Lemos, diretor de consultoria e serviços profissionais da BEA Systems. “O salário desse profissional pode chegar ao patamar do de um gerente de tecnologia ou de projeto, algo entre 8 a 12 mil reais”, diz.
A GVT é uma das empresas que embarcaram no SOA, com um grupo de 16 profissionais. “Em telecom, precisamos de produtos cada vez mais inovadores e isso tem muito impacto nos sistemas. O SOA é uma maneira inteligente de controlar processos e reutilizar as coisas”, diz Alessandra Bomura, 36 anos, gerente de arquitetura e tecnologia da GVT. Na operadora desde a sua criação, há seis anos, Alessandra é graduada em Ciência da Computação pela Unesp e fez MBA de Gestão Empresarial pela FGV. Antes de aderir ao SOA, trabalhava com BI e sistemas de engenharia.

Alessandra espelha o perfil do profissional que tem se dado bem na área, aliando o conhecimento técnico e a formação de negócios. Além disso, em boa parte das empresas as equipes de SOA estão sendo formadas por pessoas que, como ela, trabalham na companhia há algum tempo. “É fundamental ter profissionais que conheçam bem os processos da empresa”, afirma Márcio Butuem, gerente sênior de consultoria de vendas da Oracle.

Outro exemplo é o engenheiro químico Marcelo Jaccoud Amaral, 43 anos, na Petrobras desde 1987. Há dois anos ele é um dos arquitetos tecnológicos da companhia, parte de um grupo de 30 profissionais. Além do conhecimento do negócio, trazia na bagagem o mestrado de Engenharia de Software pela PUC-Rio. “Fui me envolvendo com tecnologias de web e XML”, diz.

Como não há uma formação específica para atuar em SOA, o que conta é a combinação da experiência do profissional, a habilidade técnica e a visão do negócio. “Você tem de conhecer um pedacinho de cada sistema que está integrando, ser multidisciplinar”, diz Marcelo Galvão, gerente de plataforma de integração de negócio da TIM Brasil. Ele é formado em Engenharia da Computação pela Unicamp, com mestrado em Sistemas Distribuídos pela Universidade de Lyon. O grupo de SOA da TIM tem 35 pessoas. Já no Deutsche Bank, são oito analistas. “Investimos na nossa equipe, que já era próxima das áreas de negócio”, diz Keiji Sakai, CIO do Deutsche.

Qualificação técnica

J2EE, Java, XML, .Net, Ajax, PHP e Python estão entre os termos que são bem-vindos no currículo do candidato a arquiteto SOA. Mas há uma safra de siglas em alta sintonia com a área de negócios. BPM (Business Process Management), ESB (Enterprise Service Bus), BRE (Business Rules Engine), Itil (Information Technology Infrastructure Library) são alguns exemplos.

Para quem quer investir na área um dos caminhos são as certificações e eventos promovidos pelos fornecedores de soluções. “Estamos fazendo parcerias com universidades para desenvolvermos cursos na área, como extensões e MBAs”, afirma Marco Bravo, diretor de software da IBM.

O SOA também abre frentes de trabalho entre os fornecedores de TI. É o caso da IBM. Um de seus especialistas é o arquiteto de TI Mauro Ceccini, de 43 anos. Formado em Engenharia Eletrônica pela Poli/USP, ele presta consultoria a clientes da IBM na área de SOA, dentro de uma equipe de 12 profissionais.

Fonte: http://info.abril.com.br/professional/desenvolvimento/pronto-para-o-soa.shtml

Criatividade & Produtividade, cada caso tem sua hora

Ao se deparar com um problema no desenvolvimento de um sistema, qual a melhor e mais sustentável maneira para se encontrar uma solução? Buscar na literatura ou colocar os miolos para funcionar e desenvolver sua própria solução?


Olha só o que diz Leonardo Kenji:


Criatividade e Design Patterns September 15, 2008 1:16 pm

Ninguém pode negar que os Design Patterns, ou “padrões de projeto” ou “padrões de desenho”, formalizados no famoso livro do GoF (gang of four - a turma dos quatro, ou Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) foi uma mudança muito significativa em toda a indústria de software. A proposta era simples: uma vez estudadas diversas práticas de programação de “bons programadores”, eram identificadas algumas técnicas de design inteligentes que sempre apareciam mais ou menos de forma parecida para resolver problemas parecidos. Cada padrão era estudado e, voilá, junte vários destes e classifique-os e você tem um manual de “boas maneiras” para o desenvolvimento de software.

O benefício imediato, óbvio, é que ao se deparar com um problema de design, o desenvolvedor não precisa pensar numa solução do zero. Basta ir no compêndio de design patterns e procurar qual design resolve que tipo de problema.
Outro benefício indireto, mas igualmente importante, é trazer uma série de nomes para determinadas estruturas mentais, que facilitam a comunicação entre desenvolvedores. Ninguém precisa ficar explicando o que é um singleton se todo mundo já sabe o que é. Ganha-se tempo e leva-se a discussão um nível acima. E daí você pode ter ferramentas que automatizam a geração destes códigos, discussões acerca das vantagens e desvantagens de cada pattern, e etc.

Hoje em dia, existem patterns para praticamente todas as áreas específicas do desenvolvimento de software. É uma forma de reuso do conhecimento. Mas como tudo na vida, nem tudo é perfeito. Alguns anos atrás, eu estava conversando com um economista e falando dessa coisa de design patterns, e o cara mostrou uma cara de espanto, e falou: “que engraçado… em algumas situações na economia, pedimos para o aluno nunca procurar as soluções prontas, mas sempre tentar encontrar a solução por ele mesmo primeiro, para só depois recorrer à literatura… assim incentivamos a criatividade dos alunos e forçamos eles a pensarem…” Pode parecer improdutivo, e de fato, na engenharia de software, é uma bela vantagem ter na manga uma série de soluções prontas que “funcionam comprovadamente” e não perder tempo reinventando a roda.
Mas do ponto de vista criativo, assumir que os design patterns estão sempre certos, ou que são sempre a solução, também é uma faca de dois legumes. A postura do inovador deve ser sempre questionadora.
Haveria maneira melhor de resolver este problema? Este design pattern é realmente o mais adequado para a minha demanda? Quais são os fatores que poderiam levar este design a uma possível desvantagem? Quais tipos de problema poderiam advir do uso desta solução?
Se seu negócio é prazo, ficar pensando demais é perder tempo. Mas se seu negócio é inovar e criar soluções que sejam vantajosas diante do que é praticado em toda a indústria, nem sempre seguir o que existe pode ser a vantagem. E no fim das contas, espírito crítico nunca faz mal a ninguém.

--

Desenvolvimento de softwares não tem nada a ver com projetos de construção civil

Li este artigo do Guilherme Chapiewski e achei interessantíssimo.
Como meu propósito aqui neste blog é publicar os artigos que achei interessante, aí vai mais um:

Cuidando para que o software não apodreça

Infeliz o sujeito que teve a idéia de comparar desenvolvimento de software a construção de prédios. Até hoje, em pleno século 21, algumas pessoas ainda acreditam que para fazer software você deve fazer exatamente como na construção civil: você deve ter “engenheiros” que fazem um grande projeto especificando exatamente como tudo vai ser, depois os pedreiros constroem e no final está tudo pronto e funcionando conforme a especificação.

Desenvolvimento de software não tem absolutamente nada a ver com construção!

No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt fazem uma analogia muito mais apropriada: fazer software não é como constriur prédios mas sim como jardinagem. É muito mais “orgânico” do que “concreto”. Inicialmente você planeja muitas coisas para o seu jardim de acordo com as condições atuais de terra, clima, etc. Você precisa plantar as sementes, regar todo dia e cuidar para que as pragas não acabem com tudo. Você pode com o passar do tempo mover suas plantas de lugar para tirar vantagem de fatores como exposição ao sol, sombra ou até mesmo para fazer a rotatividade da terra. Você poda suas plantas constantemente e move alguns tipos de flores de um lugar para o outro para que o jardim fique melhor esteticamente. Se alguma planta cresce demais, pode ser que o espaço que você planejou para ela tenha ficado pequeno, e então é necessário movê-la de lugar. Enfim, não é uma coisa que você planeja, mas sim uma coisa que você tem uma idéia inicial e trabalha ao longo do tempo para fazer o melhor possível dentro daquela idéia.

Assim como o jardim, se o software não receber todos os cuidados necessários ele apodrece. Quando um software apodrece, é impossível implementar qualquer funcionalidade num tempo aceitável, é impossível colocar em produção sem que alguém tenha que ficar de babá, enfim, tudo passa a ser imprevisível. Nos piores casos passa a ser até impossível “tocar” no software, e esses monstros viram aqueles softwares que “se o servidor desligar ele não liga nunca mais”. E o pior é que isso acontece toda hora. Quantas vezes você já não pegou um projeto tão ruim, mas tão ruim que seria mais fácil fazer do zero do que consertá-lo? Isso é um sinal claro de software podre.

Para evitar que isso aconteça, o que se deve fazer é reavaliar a situação do software a cada história/funcionalidade implementada. Um bom desenvolvedor sempre avaliará se não é hora de mover algumas coisas de lugar, generalizar algumas funcionalidades, reescrever algumas porções de código e etc. - assim como faria um bom jardineiro. Isso deveria ser uma lei, não uma opção.

Os times ágeis trabalham com um conceito que é a “definição de pronto” (DOD - definition of done). A definição de pronto diz quando é que uma funcionalidade pode ser considerada pronta ou finalizada. Na minha opinião, para se considerar uma funcionalidade “pronta” é necessário no mínimo:

• Desenvolver a funcionalidade
• Testar unitariamente (melhor ainda se for fazendo TDD)
• Testar a integração com outros componentes (quando for o caso)
• Verificar se o build do projeto funciona sem erros e fazer o deploy em uma ambiente de produção simulado
• Testar segundo os critérios de aceitação estabelecidos pelo cliente
• Depois dos testes desenvolvidos e a nova funcionalidade passando em todos eles, avaliar a necessidade de fazer refactoring no novo código
• Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refactoring em algum módulo do sistema
• Atualizar a documentação (quando necessário)

Pode parecer um exagero ou muito trabalho, mas não é. A questão é que você não pode deixar para fazer nenhum desses itens depois de 2 meses de desenvolvimento, você precisa fazer isso desde o primeiro dia! Quando você deixa para depois, você acaba acumulando o famoso débito técnico, e depois poderá ter que pagá-lo com juros, que poderão ser muito altos. O melhor é fazer aos poucos, a cada passo dado, porque desta forma o trabalho sempre será muito menor e não irá onerar o projeto. Mais uma vez fazendo analogias, é como câncer: você pode se previnir e tentar evitar que ele aconteça, ou você pode esperar ficar doente para depois ter que fazer uma arriscada cirurgia invasiva (e mesmo assim pode não dar certo, e aí perde-se o paciente).

Fonte: http://gc.blog.br/2008/07/20/cuidando-para-que-o-software-nao-apodreca/

Programação O-O: Evitando VOs (Classes de dados) e BOs (classes de negocio)

Recentemente li sobre este assunto no link:
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Resumo do meu entendimento sobre este artigo

Muitos programadores, por terem aprendido de forma errada o paradgma de programação Orientada a Objetos, passaram a utilizá-la como se esta fosse apenas mais uma ferramenta de desenvolvimento. É o caso, por exemplo, de quem programava em Pascal e passou a programar em Delphi, o qual, por sua vez, nada mais é do que Pascal Orientado a Objeto. O mesmo caso também para quem programava em C e passou a programar em Java.
Uma das causas desse problema foi a criação do conceito de Enterprise Java Beans (EJB), que segundo o artigo, são os "componentes distribuídos que talvez tenham no curriculum o maior número de enganos históricos da indústria" com relação ao uso de Orientação a Objetos. Muitos programadores que desenvolvem em Java EE, não conseguiram assimilar corretamente este novo conceito e passaram a utilizar o paradgma O-O de forma errada, gerando com isso, um consenso equivocado entre eles.
Para tentar minimizar este problema a SUN lançou um catálogo de padrões chamado de Core J2EE Patterns". A maior parte deste catálogo se destina a lidar com problemas que EJBs causam, mas o nome “core” ajudou a difundir o mito de que Java EE era sinônimo de EJBs ", causando, em parte, um efeito contrário, ao gerar ainda mais confusão na cabeça de alguns desenvolvedores.
Um dos padrões do catálogo da SUN, que se chamava VO (Value Object), passou a se chamar TO (Transfer object). Um TO, que nada mais é do que a classe que possui os métodos GETs e SETs, seria um objeto cuja função é transportar dados entre classes. Toda vez que a TO precisar buscar dados no servidor para serem manipulados pela aplicação, deverá fazer uma conexão na rede com o banco de dados, esse procedimento gera várias conexões com o banco e conexões consomem recursos, diminuindo assim o desempenho da aplicação, além de aumentar o tráfego na rede.
No caso de aplicações que não precisam fazer constantes acessos a banco, o uso de TOs se torna dispensável.
Assim o artigo diz que "Eventualmente a comunidade de desenvolvedores percebeu que EJBs não são a solução para qualquer problema - na verdade são uma possível solução para uns poucos problemas".

Por definição do catálogo da SUN, ao modelarmos um sistema devemos criar as classes TOs e as BOs. As TOs são as classes de dados e as BOs as classes lógicas. As TOs transferem dados para as BOs manipulá-los, dessa forma temo a classe de dados separada da classe de lógica.
Uma das maiores vantagens da programação Orientado a Objeto é possibilitar traduzir o mundo real para um software da maneira mais próxima possível. Ao utilizar classes de dados (TOs) separadas das classes de lógica (BOs), segundo o artigo, "esta vantagem é simplesmente jogada fora" e que "No mundo real não existe lógica de um lado e dados de outro, ambos combinados forma um único conceito".
"Também a manutenção de um sistema construído desta maneira é problemática". Devido à classe BO ficar muito dependente da classe TO, a "alteração em uma afeta drasticamente a outra", o que dificulta então a manutenção de uma sistema desenvolvido dessa maneira.
"A coesão das classes de lógica (BOs) tende a ser baixa, visto que agrega diversas funções relativas não só à sua própria estrutura de dados mas também a outras classes TO.
Se uma BO pode estar ligada a diversos TOs, ao fazer uma alteração na BO deve-se verificar quais serão as TOs que sofreram o impacto dessa alteração, vindo então a dificultar a manutenção do sistema. Conforme está no artigo, "dificilmente um TO vai ser utilizado apenas por um BO (e se o for temos um problema grande de reusabilidade) ".
Tendo em vista que o BO tem acesso ao TO, fica claro então que o BO pode alterar os valores do TO, isso torna o sistema inconsistente, pois o TO deveria apenas ter a função de transferir dados e não de permitir alterações nos dados já capturados do banco.
O artigo conclui este assunto dizendo que pelo fato de muitos programadores estarem utilizando o paradgma da programação O-O apenas como ferramenta, "a grande maioria das aplicações O-O, na verdade estão sendo construídas de maneira procedural por pura ignorância ou indução da documentação existente." E sua frase final é a seguinte:
"Desenvolver sistemas envolve, antes de mais nada, conhecer a tecnologia utilizada. Não se pode tirar proveito de Orientação a Objetos se não se distingue o que é OO e o que é procedural ".

Quais as vantagens da APF sobre os Pontos por Caso de Uso (PCU)?

Texto publicado pela FATTO Consultoria, muito interessante para quem é da área de Engenharia de Software.
Vale à pena um debate sobre o assunto.

P:. Quais as vantagens da APF sobre os Pontos por Caso de Uso (PCU)?

R:. Em primeiro lugar é preciso desmistificar que somente a técnica do PCU é adequada para medir sistemas cujos requisitos foram expressos através de casos de usos. A APF pode ser utilizada normalmente para estes situações como também para medir sistemas cujos requisitos foram documentados utilizando outra metodologia.

A seguir são listados algumas vantagens da APF sobre o PCU.

1. O PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa por casos de uso. A medição da APF independe da forma como os requisitos do software foram expressos. Esta vantagem da APF foi citada pelo próprio Gustav Karner em seu trabalho original "Resource Estimation for Objectory Projects" (1993).

2. Não é possível aplicar o PCU na medição de aplicações existentes cuja documentação esteja desatualizada ou sequer exista. A alternativa seria escrever os casos de uso destas aplicações para só então medí-las! Porém isto tornaria a medição inviável numa análise de custo x benefício. Com a APF é possível realizar a medição analisando-se a própria aplicação em uso.

3. Não existe um padrão único para a escrita do caso de uso. Diferentes estilos na escrita dos caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU. A medição pela APF dos casos de uso de um sistema sempre chegará ao mesmo resultado independente do estilo de escrita dos casos de uso ou de sua granularidade pois a APF "quebra" o requisito no nível adequado para a medição usando o conceito de Processo Elementar.

4. Devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes há a necessidade de se obter uma estimativa antes da finalização desta etapa. O processo de medição da APF também só pode ser empregado após o levantamento dos requisitos do projeto. Porém existem técnicas estimativas de tamanho em pontos de função que podem ser aplicadas com sucesso antes da análise de requisitos ser concluída. Um exemplo são as contagens indicativa e estimativa propostas pela NESMA.

5. O método do PCU não contempla a medição de projetos de melhoria (manutenção) de software, somente projetos de desenvolvimento. A APF contempla a medição de projetos de desenvolvimento, projetos de melhoria e aplicações. Estes outros tipos de medição cumprem um importante papel em programas de métricas e na contratação do desenvolvimento de software.

6. Não existe um grupo de usuários ou organização responsável pela padronização ou evolução do método PCU; e a bibliografia sobre o assunto é escassa. Para a APF existe o IFPUG que é o responsável por manter o Manual de Práticas de Contagem - o padrão da técnica, que é evoluído continuamente. E também há diversos fóruns de discussão sobre APF para a troca de experiências.

7. O método PCU não é aderente à norma ISO/IEC 14143 que define um modelo para a medição funcional de software. A APF, conforme o manual do IFPUG, está padronizada sob a norma ISO/IEC 20926 como um método de medição funcional aderente à ISO/IEC 14.143.

8. Não existe um programa de certificação de profissionais que conheçam a técnica do PCU e saibam aplicá-la de forma adequada. O IFPUG possui o programa de certificação CFPS para a APF.

9. O fator ambiental inserido no PCU dificulta sua aplicação em programas de métricas de software e benchmarking entre organizações, pois torna o tamanho de um projeto variável; sem que sua funcionalidade sequer mude. Se um mesmo projeto for entregue a duas equipes distintas a contagem dos pontos por caso de uso deste projeto será também diferente em cada situação. Ou seja, o mesmo projeto tem dois tamanhos!

10. A determinação dos fatores técnico e ambiental do PCU está sujeita a um certo grau de subjetividade que dificulta a consistência da aplicação do método em diferentes organizações. O fator de ajuste da APF também possui o mesmo problema, embora o IFPUG possua diretrizes específicas que ajudam a minimizar este impacto. No entanto o uso do fator de ajuste na APF é opcional e a contagem dos pontos de função não ajustados atualmente é um processo bem objetivo.

Dentre as desvantagens citadas do PCU em relação à APF, algumas poderiam ser superadas com alguns ajustes simples.No entanto não há benefício adicional do PCU sobre a APF. Usar ambos os métodos também não compensaria o custo adicional de medição.

Embora a APF não seja uma técnica perfeita, há uma maturidade grande no mercado com relação ao seu uso e o IFPUG trabalha contínuamente para sua evolução.

______________________________

________________________________________
SOBRE O BOLETIM INFORMATIVO FATTO

Este informativo pode ser lido também através do
link http://www.fattocs.com.br/bif2008-04.asp

Onde colocar as regras de negócio de um sistema?

Olá pessoal,
Programo em PHP desde 2003, no entanto ainda não sou um exímio programador. Muitas coisas tenho aprendido por minha própria conta, pesquisando na internet, lendo livros, consultando amigos, fóruns, listas de discussões e etc.
Um dos motivos deste Blog é registrar o que venho aprendendo como programador. O tema a ser tratado neste primeiro texto é, onde devemos colocar as regras de negócio do nosso sistema.

Este assunto foi muito discutido na lista "PHP-Brasília" e o melhor esclarecimento foi colocado pelo nosso amigo Pablo Sánchez, vou descrever aqui meu entendimento sobre a explicação dele.

As Regras de Negócio estão presente em todo o fluxo de uma aplicação, desde os formulários de entrada de dados até a estrutura do banco de dados. Elas não podem estar em um único lugar da nossa aplicação, pois não há como centralizar em um único local, todas elas. Ao ler todo o artigo voce entenderá.
Nos formulários, temos por exemplo, as validações de preenchimento dos seus campos. Estas validações fazem parte das Regras de Negócio e são implementadas no código de tratamento dos dados recebidos destes formulários.
Nesta validação pode-se utilizar JavaScript, no intuito apenas de minimizar o trabalho de verificação dos dados fornecidos pelo usuário, sendo útil como uma pré-validação. Nunca deixe a validação de dados totalmente por conta do JavaScript, pois o usuário pode desabilitar este recurso pelo próprio browser, causando assim erros e inconsistências em todo o sistema.
Se estamos trabalhando com MVC, deveremos ter na camada de controle apenas as regras de negócio que validam informações contextualizadas, por exemplo existem casos em que o preenchimento de alguns campos só serão obrigatórios em determinadas situações (eu mesmo já implementei regras em que se o cadastro fosse preenchido por um usuário externo, todos os campos obrigatórios deveriam serem preenchidos, se fosse um usuário interno, não seria necessário validar todos).
Na camada de Modelo é que se faz a validação de preenchimento correto dos campos, como verificação de número de CPF, de E-mail (todo endereço de e-mail deve ter um @) , assim como validação de relacionamento entre tabelas e etc.
As regras de negócio também estão presentes na estrutura do nosso banco de dados, quando na definição dos relacionamentos e especificações dos campos, representando o domínio do sistema.
Assim, respondo-lhe à pergunta: onde colocar as regras de negócio.
Conforme nosso amigo Pablo Sánchez, elas deverão estar presente em toda a aplicação a ser desenvolvida.