Este artigo apareceu pela primeira vez na revista IEEE Software e é trazido pela InfoQ e IEEE Computer Society.
Boas receitas prontas de projetos de softwares são difíceis de encontrar. Cada cenário tem sua particularidade. Princípios gerais de design podem ser um guia, mas a realidade nos deixa em conflito com os nossos objetivos: flexibilidade e facilidade de manutenção contra tamanho e complexidade. Da mesma forma, as bibliotecas de código podem ajudar a não ter que reinventar a roda, mas na visão dos desenvolvedores menos habilidosos, o reuso de componentes prontos ainda é ficção.
Padrões de Projeto ajudaram a amenizar estes problemas, documentando soluções bem elaboradas para problemas que ocorrem repetidamente em um contexto. Em vez de apresentar um trecho de código ("copy and paste"), os padrões discutem as forças que impactam no o design da solução. São exemplos de forças o desempenho e a segurança em aplicações web: algoritmos de criptografia e decriptografia melhoram a segurança, mas aumentam a sobrecarga no processamento. Ward Cunningham uma vez descreveu que os padrões são como irmãos mais velhos, eles te ensinam como fazer a coisa certa.[1]
Embora os padrões tenham se tornado populares, o seu impacto como uma técnica de design é mais difícil de quantificar do que o impacto de um produto de software específico (que são as partes analisadas por este artigo). Estas partes destacam a amplitude dos padrões disponíveis 20 anos após as primeiras conferências sobre Patterns Languages of Programming (PLoP) e qual o impacto que alguns padrões tiveram sobre o software de código aberto.
Como tudo começou
O arquiteto de construções e filósofo Cristopher Alexander inspirou Kent Beck e Ward Cunningham a escrever os primeiros padrões em 1987 para desenhar telas Smalltalk. Em 1993, Beck and Grady Booch patrocinaram um encontro no Colorado que provocou a formação da organização sem fins lucrativos Hillside Group para promover uma série de conferências sobre Patterns Languages of Programming (PLoP), que está comemorando 20 anos de sucesso. Estas conferências seguem um estilo altamente colaborativo com foco em "evangelização" através de oficinas, exposições de estudos de caso e feedbacks. Muitos padrões e livros de sucesso sugiram depois deste processo.
Em 1994, Erich Gamma e seus colegas levaram o conceito de padrões de projeto a um publico amplo; no modelo original, o livro já vendeu mais de 500.000 cópias em 13 idiomas.[2] Dois anos depois, Frank Buschmann e seu colega produziram o primeiro volume da série Pattern-Oriented Software Architecture [3] e logo em seguida Martin Flowler lançou Analysis Patterns [4] (recursos para leitura estão disponíveis em outros lugares. [5-9]). O aparente sucesso dos modelos dos padrões de projeto fazia alguns autores adicionarem de forma gratuita aos seus título de publicação a palavra "patterns" - isso era o preço do sucesso. Em 2013, nas estatísticas das pesquisas por livros no site da Amazon, no setor de tecnologia, a palavra "pattern" foi pesquisada 5.500 vezes, por usuários distintos (incluindo um menor número de falsos positivos na detecção de padrões visuais).
A popularidade dos padrões veio cedo, e as pessoas perceberam que os padrões não vieram para substituir as habilidades dos projetistas e nem para resolver todos os problemas. Ainda sim os padrões bem descritos oferecem uma valiosa referência com base em experiências reais. Porque aprender fazendo (aprendendo com os erros), muitas vezes não é uma boa opção para os projetos do mundo real, os padrões podem fornecer uma maneira de aprender com a experiência dos outros (e erros, podem fazer bons antipatterns).
Nenhum sinal de enfraquecimento dos padrões
A ampla diversidade de Padrões dificulta a determinação do número exato de Padrões de Projeto documentados. Linda Rising listou mais de 1000 padrões na publicação The Pattern Almanac 2000. [10] As conferências de PLoP promovidas pelo Grupo de Hillside (www.hillside.net), aceitaram mais de 1.500 padrões documentados. A taxa de submissão de novos padrões a estas conferências tem sido constante, em cerca de 100 documentos por ano. Existe uma estimativa de quatro padrões por documento, mais todos os livros que abrangem desenvolvimento de aplicativos móveis, sistemas adaptativos, arquiteturas sustentáveis, padrões de domínios específicos, meta arquiteturas, workflow, sistemas de tolerância a falha e segurança.
Muitas pessoas aceitam a definição de um padrão como uma solução comprovada para um problema em um contexto. Em The Timeless Way of Building, Christopher Alexander esclarece que "o Padrão é, em resumo, ao mesmo tempo uma coisa e a regra que define como esta coisa é criada." [11] Padrões representam uma solução reutilizável, fornecem informações sobre a sua utilidade, vantagens, desvantagens e documentam as melhores práticas comprovadas.
Por exemplo, muitas arquiteturas de integração incluem o padrão Broker, que atua como um intermediário entre clientes e servidores e lida com o roteamento de mensagens, incluindo serialização e desserialização de conteúdo da mensagem. [2] A estrutura de comunicação Web implementa este padrão; motores de workflow como o YAWL (Yet Another Workflow Language) também têm um implementação rica deste padrão.[12]
Muitos padrões são parte de uma biblioteca de padrões; exemplos incluem https://developer.yahoo.com/ypatterns e www.securitypatterns.org. Muitas empresas, incluindo Amazon, Google, IBM, Lucent, Microsoft, Oracle e Siemens, têm coleções de padrões semelhantes, alguns dos quais estão disponíveis em livros e em sites. Um exemplo de uma coleção é o catálogo de padrões para ebusiness da IBM. Entre muitos projetos recorrentes, podem ser destacadas as implementações do Enterprise Service Bus no contexto dos produtos IBM WebSphere. [13] Inter-relacionando e conectando um conjunto de padrões, pode ser criado um padrão de linguagem que se torna um gerador de soluções para um domínio específico durante o processo de desenvolvimento. [14] Existe até um padrão para a escrita de padrões de projeto.[15]
Padrões de integração corporativo
O sucesso dos padrões nas disciplinas de arquitetura de software e design tem motivado a tentativa de integrá-los em ferramentas de programação para aumentar a produtividade e ampliado a padronização em práticas de design. Infelizmente, a maioria das tentativas tropeçaram porque os padrões são culturalmente associados ao contexto de documentação para a passagem de conhecimento entre as pessoas, e não como uma ferramenta de construção. Ainda assim, alguns padrões foram construídos sob influência direta da construção.
Por volta de 2003, o termo Enterprise Service Bus (ESB) ganhou força para descrever a plataforma de integração para arquiteturas orientadas a serviço. Rotas ESBs, filtros e transformações de mensagens XML entre os serviços, representam a evolução dos produtos de integração de aplicativos corporativos tradicionais, que implementam o padrão Broker. Ironicamente, embora estes produtos tenham como objetivo integrar todo o conjunto de aplicações empresariais que não se comunicavam, não existia um vocabulário comum para descrever as soluções já disponíveis (ausência dos padrões).
Figura 1. Crescimento do código do Apache Camel durante o tempo. O crescimento linear do código Java mostra que o engajamento da comunidade de desenvolvedores (commiters) é estável e sustentável. A quantidade de JavaScript saltou em 2009, porém mais tarde foi reduzida. Provavelmente com a disponibilidade de bibliotecas e frameworks.
Visando superar este lacuna, os desenvolvedores de ESB´s de código aberto, disponibilizaram os Enterprise Integration Patterns (EIPs) que fornecem um vocabulário coerente com 65 padrões,[7] que vão desde estilos de integração, mensagem, roteamento e transformação. Estes padrões descrevem um parcela significativa das soluções ESB. Com a ausência de padrões na indústria de ESB´s, os projetos de código aberto assumiram a EIP como padrões de fato.
ESB´s de código aberto
Desde o surgimento em 2005, a maioria dos ESB´s de código aberto tem incorporado modelos de programação, modelos de soluções e outros modelos baseados no EIP. Os exemplos mais comuns são: Mule, Apache Camel, WSO2 ESB, Spring Integration e OpenESB.
A natureza dos projetos de código aberto faz a análise do tamanho do código ser relativamente fácil. No entanto, a análise do volume de downloads realizados no código é relativamente difícil, porque não existe um registro formal de quem baixa e o número de downloads é mascarado por espelhamento ou caching automáticos. [13] O Apache Camel tem 890 mil linhas de código. Criado por 62 commiters, tem mais de 18.000 commits individuais ao longo de seis anos. É surpreendente o crescimento linear do número de linhas de código (Java), o que sugere o envolvimento estável e consistente de um conjunto de commiters. Adaptações comerciais ao código do Apache Camel, que desenvolveram ferramentas administrativas em tempo de execução, por exemplo pela Red Hat ou Talend, aumentaram significativamente as linhas de código.
O Maven Central têm uma média de 25.000 downloads de snapshots por mês e um pico de mais de 30 mil em julho de 2013. Este volume é maior que do YAWL, que relatou cerca de 1000 downloads por mês em 2010. [13] O Mule relata 3,6 milhões de downloads em sua página, mas não informa se todos os downloads são únicos.
A participação da comunidade fornece outra métrica do sucesso do código aberto. O tráfico de mensagens do Apache Camel cresceu rapidamente após o seu lançamento em 2007 e mantém-se estável com cerca de 2.500 mensagens por mês. Isso indica uma comunidade saudável que colabora para resolver problemas e impulsiona a evolução do produto. Para efeito de comparação, a página da comunidade do Mule conta com mais de 150.000 membros, e seu fórum conta com um total de 26.600 posts.
Padrões como uma ferramenta de design
Após ser integrada nestes produtos de código aberto, a EIP ficou muito popular. Alguns projetos de ESB utilizam a EIP como uma linguagem visual para o design de soluções. Por exemplo, um desenvolvedor pode acessar uma EIP através de um ícone no IDE Red Hat Fuse (ambiente de desenvolvimento integrado) ou Mule Studio. Ao contrário de antes, na qual houve algumas tentativas de "programação visual", o estilo arquitetônico das soluções de mensagens assíncronas tornam a composição visual dos padrões mais natural. A Figura 2 mostra um Camel Rote apontando uma mensagem de entrada para dois possíveis endpoints de saída via Message Router. Desenvolvedores ESB agora podem pensar desenhar, comunicar e implementar suas soluções utilizando EIP, mesmo que estejam utilizando diferentes plataformas de integração.
Figura 2. Criação da solução de mensagens usando a linguagem visual de Enterprise Integration Patterns (EIPs)7 dentro do IDE RedHat Fuse (plataforma de desenvolvimento integrado). As mensagens que chegam a partir de um endpoint baseado em arquivo são encaminhadas por um roteador baseado em conteúdo para um dos dois potenciais endpoints de saída que roteia com base na cidade especificada dentro do conteúdo da mensagem.
Figura 3. A cartas de jogo com base em EIPs. A linguagem padrão visual permite um uso interativo dos padrões. Cada carta apresenta o ícone de um padrão juntamente com a descrição e o nome da solução.
O baralho de cartas apresentado na inauguração da conferência CamelOne é provavelmente a adaptação mais criativa do evento (Figura 3). Cada carta apresenta um padrão, juntamente com a descrição da solução. É gratificante ver os padrões de design, que foram criados para melhorar a comunicação e colaboração, encontrando seu caminho nas mãos de arquitetos e engenheiros de uma maneira acessível e útil.
As estatísticas apresentadas indicam que os Padrões de Projeto tiveram um grande impacto sobre a comunidade de design de software ao longo dos últimos 20 anos. No entanto, muitas questões em torno dos padrões ainda permanecem abertas. Por exemplo, bons padrões não são fáceis de encontrar, o que estimula a organizar e catalogar a grande quantidade de padrões existentes. Também encontramos diversas ferramentas de criação de Padrões de Projeto, que talvez utilizem tecnologia Wiki.
Finalmente, ferramentas de design baseadas em padrões prometem ser mais atraentes para os engenheiros de software e não serão mais meras ferramentas de desenho de componentes e conectores. Será que a comunidade de padrões esta perdendo força? Não pensamos assim: os Padrões de Projeto existentes continuarão a ser implementados, assim como as EIP´s. E ainda existem contextos para os quais os padrões ainda não foram capturados. Por exemplo, alguns tipos de interações entre aplicações e entre as pessoas (por exemplo, através das redes sociais), poderiam ser catalogados como uma forma padrão. O futuro dos Padrões de Projeto é brilhante. Te convidamos a ajudar a moldá-lo, promovendo o desenvolvimento de uma ferramenta ou escrevendo e compartilhando o seu conhecimento em uma forma padrão.
Referências
[1]W. Cunningham, "Tips for Editing Patterns," Dec. 2002.
[2]E. Gamma et al., Design Patterns, AddisonWesley Professional, 1994.
[3]F. Buschmann et al., PatternOriented Software Architecture, Volume 1: A System of Patterns, John Wiley & Sons, 1996.
[4]M. Fowler, Analysis Patterns: Reusable Object Models, AddisonWesley Professional, 1996.
[5]J. Kerievsky, Refactoring to Patterns, AddisonWesley Professional, 2004.
[6]M. Fowler, Patterns of Enterprise Application Architecture, AddisonWesley Professional, 2002.
[7]G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, AddisonWesley Professional, 2004.
[8]E. Evans, Domain Driven Design: Tackling Complexity in the Heart of Software, AddisonWesley Professional, 2003.
[9]V. Vernon, Implementing DomainDriven Design, AddisonWesley Professional, 2013.
[10]L. Rising, The Pattern Almanac 2000, AddisonWesley, 2000.
[11]C. Alexander, The Timeless Way of Building, Oxford Univ. Press, 1979.
[12]M. Adams, A.H.M. ter Hofstede, and M. La Rosa, "Open Source Software for Workflow Management: The Case of YAWL," IEEE Software, vol. 28, no. 3, 2011, pp. 16-19.
[13]M. Keen et al, Patterns: Implementing an SOA Using an Enterprise Service Bus, IBM, 2004.
[14]F. Buschmann, K. Henney, and D. Schmidt, "Past, Present, and Future Trends in Software Patterns," IEEE Software, vol. 24, no. 4, 2007, pp. 31-37.
[15]G. Meszaros and J. Doble, A Pattern Language for Pattern Writing, Hillside Group.
Sobre os autores
Gregor Hohpe é arquiteto corporativo chefe da Allianz SE e membro do Grupo de Hillside. Contacte-o em info@enterpriseintegrationpatterns.com.
Rebecca WirfsBrock é presidente da WirfsBrock Associates e tesoureira do Grupo Hillside. Contacte-a em rebecca@wirfsbrock.com.
Joseph W. Yoder é presidente da The Refactory, Inc., e do Grupo de Hillside. Contacte-o atjoe@refactory.com.
Olaf Zimmermann é professor e sócio do Instituto de Software da Universidade de Ciências Aplicadas da Suíça Oriental, Rapperswil (HSR FHO). Contacte-o em ozimmerm@hsr.ch.