InfoQ: hablando de desarrollo basado en patrones

InfoQ, a través de una entrevista de Dave West a Lee Ackerman y Celso Gonzalez, autores de "Patterns-Based Engineering: Successfully Delivering Solutions via Patterns", trae a foco el uso de patrones. La breve promoción del libro recuerda algunos de los valores más importantes de su uso. De allí quisiera destacar dos elementos comentados:
1, La importancia y posibilidad de reuso de patrones:

InfoQ:  The very first benefit of PBE [Pattern based engineering] in chapter 17 is increased productivity via reuse.  Reuse was the great promise of object-oriented development.  It did not pan out.  Why will pattern-based reuse have a better chance of succeeding?
We struggle with the idea that reuse has not panned out. We’d agree that the idea of reuse was oversold and oversimplified. However, we need to keep in mind the significant amount of reuse that has been achieved by using OO concepts and related ideas (e.g. frameworks, libraries, components, etc).
Patterns not only help us in sharing and consuming best practices, but also take us forward in the next step of coarse-grained solutions. And in taking that next step forward, it’s not that the components are larger in size, but that they provide points of variability that allows us to customize the pattern as we apply it to our situation.

With that in mind, one big difference between patterns and OO reuse is that patterns are reuse of design in contrast to reuse of code. Due to its higher level of abstraction, patterns are often more reusable than code.

And last, but not least, we also need to focus on pattern consumption. Today there are already thousands of patterns available for reuse. However, we struggle to find the right pattern at the moment of need. As we improve our ability to find patterns (according to requirements, relationships, workflow) we will see a subsequent increase in reuse and ROI.

2, Patrones y desarrollo basado en modelos (MDD):

InfoQ:  PBE is an example of Model-driven development (MDD) mostly as a result of using the engineering metaphor as a philosophical base.  Throughout the book you mention the possibility of automating PBE and the use of patterns.  To what extent do you share the core intent of MDD - create a formal model and mathematically transform that model into correct and executing code?
We’d actually start with a simpler definition of MDD, whereby we focus on using model as abstractions – hiding details that are not necessary at a particular moment in time. Automation can be a boon to productivity – but is not a necessity in performing MDD. We could use pen and paper, white-boards, or simple software applications that allow us to model.

When working with PBE we encourage and support the use of both pattern specifications and pattern implementations. Pattern specifications are the formal, written documentation such as what we find in GoF book and many others. A pattern implementation is the codification and automation of a pattern in tooling. There are a number of ways that this can be accomplished and many tools that support the creation of such automations.

Tooling to create and work with pattern implementations is continuing to mature. To date, the most impressive results that we have seen have been through the use of Java Emitter Templates (as found in Eclipse). The tool simplifies the effort that goes into analyzing exemplars – those reference solutions that will serve as the basis for the automation. In analyzing the exemplar, JET simplifies the pattern creation process and makes this capability something that anyone can learn to use. Ease of use, and speed of delivery are some of the important aspects of driving adoption of pattern implementations.

We’d also caution against unreasonable expectations of having a bit of modeling, a few patterns, and then being able to generate 100% of a solution. Such thinking at this point will lead to issues in over investment in pattern development and modeling. Better to look to build out a pattern repository, use compound patterns and recognize a role for seeding the code and incorporating user regions where code can be augmented after generation.

Para quienes usan Plex, como es el caso mío y de parte de los lectores aquí, el uso de patrones es uno de los puntos más fuertes en la obtención de productividad. Plex es una demostración cabal de que el desarrollo de patrones de variado alcance es posible y altamente productivo. Varias de las empresas asociadas a su uso han basado su crecimiento en la construcción de un grupo de patrones de valor crítico en algún área tecnológica. Más aún, se podría decir que Plex difícilmente hubiera sobrevivido sin su capacidad de extensión a través de patrones reusables. (Y la apertura de su Model API, que merece trato aparte).
En estos días, la Wiki de Plex ha extendido su entrada sobre patrones, publicando algunas de las soluciones existentes. No se publican allí, pero merecen artículos separados, dos de los sistemas de patrones que particularmente lo han potenciado en los últimos cinco o seis años: los patrones para desarrollo web de Websydian y Webclient. Doy fe de que funcionan.