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.
Representation (aka functional, aka analysis) patterns are archetypes of system functionalities; they should not be confused with business patterns, which are archetypes of business activities, nor with conceptual ones, which are archetypes of thought disconnected from specific considerations. Whereas representation patterns can overlap with both, their purposes are essentially different as, contrary to the former they target system functional architectures, and, contrary to the latter they must stay anchored to the business under consideration (cf abstraction layers).
Since the objective is to fence off architectural features, the focus is to be on the symbolic and actual dependencies of objects and activities:
- Persistency patterns describe archetypes of dependencies between persistency units depending on synchronization constraints and responsibilities.
- Responsibilities patterns describe how active objects are “decorated” with interfaces or roles.
- Workflow patterns describe archetypes of dependencies between execution units depending on synchronization constraints, execution flows, locations, and access authorizations.
- Strategies describe patterns of activities independently of time constraints; transformation patterns describe data flows processing.
- Context and entry points patterns deal with boundaries between systems and contexts. They are the actual complement of user patterns, which deal with symbolic accesses. State patterns deal with the behavior of active objects as processed by workflows.
- Use case patterns deal with functional requirements from an architecture driven perspective.
- Finally, power-type patterns deal with archetypes of partitions as applied to objects (ontologies) and activities (controls).
Representation patterns may be especially adapted to services oriented architectures since they don’t make use of abstractions but are nonetheless meant to map business processes into functional architectures built from services.
If representation patterns are to be of any use they must be associated with architectural features with unambiguous functional semantics. For that purpose a structured set of stereotypes can be built from a cross of requirements archetypes:
- Physical objects: passive, actual documents, agents, I/O devices, information systems, control systems.
- Symbolic representations (aka surrogates) for: physical objects, documents, roles, events, business logic, processes’ states.
- Roles/Actors to be played by: passive objects, storage, users, external I/O devices, services, processes.
- Events: changes to physical or symbolic objects, requests, signals, messages, changes to processes’ states.
- Actions performed on: physical or symbolic objects, interactions with users, devices, computations, processes execution.
- States of: physical or symbolic objects, interactions, devices, computations, processes.
The same rationale is applied to connectors, stereotyped regarding the associated coupling constraints:
- References between symbolic objects may be neutral regarding object states, or may entail synchronized updates.
- Flows between functional units may be neutral regarding execution (data), or may be associated with requests (control).
- Transitions between execution units may be neutral regarding their respective states (asynchronous) or may require synchronization.
- Communication channels between active objects may be neutral regarding objects connection (simplex), or may require synchronization.
Eventually, all business-relevant items are meant to be represented by their symbolic system counterpart:
- Physical objects: state of relevant business features.
- Roles: record of agent activities.
- Event records.
- Activities description.
- Record of process execution states.
Contrary to symbolic objects which are anchored to identified business elements, persistent or transient, features cannot be identified on their own and their business semantics is set by supporting objects. Yet, they may be characterized depending on their processing:
- Literal are symbolic features which can be interpreted directly.
- References are symbolic features whose interpretation require access to other objects.
- Numeric values are non symbolic features whose interpretation require access to other objects.
- Binary objects are non symbolic features which can be interpreted directly.
The same principles may be applied to operations, set along their scope (local or system) and their side effect regarding the status of symbolic representations vis-à-vis actual counterparts:
- External I/O are local operations, whose execution modify the status of symbolic representations vis-à-vis context counterparts.
- Computations are local operations whose execution doesn’t modify the status of symbolic representations vis-à-vis context counterparts.
- Transactions are symbolic operations performed globally, whose execution modify the status of symbolic representations vis-à-vis context counterparts.
- Searches are symbolic operations performed globally whose execution doesn’t modify the status of symbolic representations vis-à-vis context counterparts.
It must be noted that this approach follows the Command-Query Separation introduced by Bertrand Meyer; moreover, by combining change with scope, it provides a sound basis to the Command-Query-Responsibility-Segregation (CQRS) design pattern used by domain-driven methods.
One step further, attributes and operations may also be stereotyped in terms of their functional semantics.