Beyond Patterns

Software Engineering patterns are valuable, but ultimately limited by their non-symbolic, human brain based nature. What formal way of describing problem->context->solution sets exist beyond patterns?

SoftwareEngineering is still an immature field. In ComputerScience, it is possible to deal in absolutes, falling back on math & binary logic when necessary, but no such luxury exists for software engineering. Methodologies have been distilled to semi-formalize reusable approaches to development, but it has become obvious that choosing the proper approach is based on context. Most formalized methodologies are considered heavyweight, but most developers prefer lightweight methodologies. Some even argue XpIsHeavyWeight.

Patterns serve as a guide and represent forms that have evolved over years, having the same dependency on context that methodologies do. Patterns exist as mental abstractions, usually described as a problem, context and solution in CanonicalForm. There is some taxonomy to patterns, however most patterns are abstract entities difficult to find or remember unless used often.

If one considers patterns as the low-level aspect of development, and methodologies the high-level aspect, it follows that proper analysis of context naturally leads to choosing the proper methodology and then patterns.

The importance of context to methodologies and patterns cannot be understated. Although a symbolic language for pattern & methodology context would be useful, it is most likely impossible due to their abstract nature. Patterns are only human readable, as humans are not advanced enough to automate creating software with the QualityWithoutaName. It is assumed that a human developer is needed, which is why patterns are often described in human-readable forms such as KoansMetaphorsAndParables.

The human constraints of patterns & methodologies have stalled progress in software engineering. Minor advances continue, but there is still no sign of a SilverBullet. Some advocate using UML and Case tools to automate design & generation of software using patterns, but to my knowledge no large scale software has been written that way. The problem of context still persists, and diagrams are not a replacement for a formal language to describe context.

A symbolic language for software engineering would be of obvious benefit, but is hindered by certain problems:

• Many important design issues exist entirely outside of the code, so code-specific languages are insufficient. OOP and AOP do not help here.
• A symbolic language is an abstraction. There is no guarantee of self-consistency. The same is truth of mathematics, but mathematics is still a usable system.

Methodologies & Patterns cannot be converted into a symbolic language naively. What is needed is more formal and less philosophical than patterns. What is needed is a consistent human and machine-readable symbolic language for describing context->solution pairs in an architecture->problem model. Patterns of that nature could be called FormalPatterns?.

It is a ChickenAndEggProblem, the lack of formal descriptions for architecture/problems means there can be no FormalPatterns?. Without FormalPatterns? there is no benefit to formal descriptions.

The tale in KoansMetaphorsAndParables show why it is unwise to try to automate patterns. However luddite clinging to the notion that high level aspects should not be automated is not beneficial here(ref: GraceHopper). Balance is always key, and if a formal way to abstract something similar to patterns is needed, it seems logical to explore the possibilities.

---

There is program called LePUS - http://www.eden-study.org/articles/2002/idpt02-with-corrections.pdf that uses a visual formalism for patterns/architecture.

It seems obvious that a FormalPattern? approach would lead to graph theory, as hierarchies & networks are intrinsic to software design. Graph theory integrated with symbolic notation would seem to be the logical choice.

Exactly! For an approach to patterns involving "hierarchies and networks", plus reusable components, see my recent paper, called "Patterns in Flow-Based Programming" at http://www.jpaulmorrison.com/fbp/morrison_2005.htm. --PaulMorrison

_-----------------------

I never understood the hard-on some programmers get about patterns. I should preface this by saying Im, relatively, an idiot, and I get it. There are patterns. It is true. But this fascination, this study, what the hell is this?!?

My first encounter with this phenomenon was back in the mid-nineties when I stumbled upon a seemingly intelligent group and suddenly they began to speak of patterns, and suddenly the entire group was caught, like deer in the headlights, Jim Jones and kool-aid, feed me feed me vibe. I could have said anything stupid about patterns and I would have been put on a pedastal and given all their women and booze.

I lost all respect for a whole room of people withi minutes. And it was shocking and sad. So, this humble piece of advice, I put forth.

First, DUH!!!! Second, STOP IT!!!!