Preamble
Whereas modeling languages like UML are just tools to be used to describe artifacts, the means often take precedence over the ends, as if the language telescope was used in reverse, looking at itself instead of targets. Representation patterns are an attempt to correct this bias by picking out features relevant to business requirements and system analysis before selecting language constructs to describe them.
Modeling patterns are reusable descriptions, i.e generic forms that can be used in different contexts. What is usually known as analysis patterns (business patterns may be more accurate) describe basic objects (customer, portfolio, …) or processes (take order, ship, invoice, …) independently of the way systems may support them. Design patterns describe system components independently of their business meanings.
Thanks to the Gang of Four, design patterns are widely accepted and consistently implemented across platforms. Yet, nothing equivalent has happened for analysis patterns, which remain confined to specific domains and organizations. That should have been expected considering that specificity and versatility are critical factors for business success: business models are not to be shared but are meant to change as fast as market opportunities. Hence, there is some gap between business and design patterns, namely, there is a need for representation (aka analysis, aka functional) patterns, i.e generic descriptions of system functionalities independently of both their business meaning and system counterpart.
Beyond lexical controversies, that could be achieved with models and architectures defined along two parallel scales:
- Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
- Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).
Interactions could be also symbolized with the “M” of model:
The rationale for representation patterns is double:
- Since systems are defined as combinations of actual objects and processes on one hand, and their symbolic representations on the other hand, patterns of representations are clearly in need.
- If models (and engineering) are to be driven by architecture, that must be supported by sound foundations, more precisely, it is necessary to map business requirements into functional archetypes.
Organization
Whereas some representation patterns are sometimes described as analysis patterns, the terminology may introduce some confusion with business patterns. Following the rationale above, core patterns may be organized along two perspectives: representation and persistency.
Along the representation perspective, patterns must characterize how actual objects and processes are associated to their symbolic counterpart.
Along the persistency perspective, patterns must characterize how execution units (i.e activities) are coupled to persistent ones. Depending on domains or architecture, patterns may describe processes synchronization or time dependencies between persistent representations.