Modeling Templates (Call 4 Patterns)

Objective

Taking example from the range and maturity of design patterns, the objective is to build a repository of patterns dealing with systems functionalities and therefore positioned somewhere between analysis and design:

• They should focus on the interface between business processes and supporting system functionalities.
• They should make a clear distinction between patterns targeting individual objects and activities on one hand, architectural templates on the other hand.
• As a corollary, individual patterns should distinguish between objects’ identity and structure on one hand, aspects, roles, or functions on the other hand.
• Finally, corresponding artifacts should be directly, fully and unambiguously usable by UML tools.

Contributions are also be discussed in the LinkedIn Caminao group.

Where to start: Business Processes and Symbolic Representations

One of the main pitfall in system modeling is the confusion between targets: while languages like UML can be used to describe business as well as systems objects and behaviors, that has to be done explicitly because the semantics differ. Hence the benefit of a clear modeling distinction between business processes as seen from enterprise perspective on one hand, the symbolic objects managed by supporting systems on the other hand.

It must be noted that those two descriptions should not be seen in terms of abstraction levels but as the complementary descriptions of actual and symbolic objects whose mapping is to provide the backbone of functional patterns.

Individual vs Architecture Patterns

Patterns of representation can be defined along individual or architectural dimensions. Individual patterns are meant to deal with the structure and features of objects or activities independently of their modeling environment; architectural patterns deal with the relationships between them. That makes for six types of individual patterns (actual objects, events, roles, business logic, process control, and business objects) to be combined into four architectural blueprints (physical contexts, information, activities, and processes execution).

It must be noted that while architectures can be described at process (a) and functional (b) levels, the catch between individual and architecture perspectives can only be described in terms of symbolic representations (c).

Objects & Aspects

Contrary to design patterns, which are fully set within the computing world, functional patterns seat uncomfortably between business and system concerns. Hence the difficulty of finding reusable artifacts that could be fitted both with the heterogeneity of business requirements and the homogeneity of systems ones. That difficulty can be significantly reduced if it is dealt with separately for structures and aspects, the former used to anchor business requirements and system functionalities, the latter used to combine individual and architectural descriptions.

Enforcing that distinction is critical for the reusability of patterns, in particular when sub-types and inheritance are considered.

Features

Features are types used to describe the format of attributes or operations. As such, and contrary to aspects, they cannot be instantiated on their own but can only be valued within instances of symbolic representations. Their syntax and semantics can be defined at object or domain level.

Language Constructs

Structures and aspects are to be described with a subset of UML with unambiguous and consolidated definitions to be applied uniformly:

• Objects or activities: persistent or transient representations identified on their own or as parts of a whole.
• Power-types describing variants of objects (classifications) and activities (extension points).
• Features (attributes or operation).
• Strong and weak structural connectors between instances (composition or aggregation) and types (inheritance)
• Functional connectors between physical objects (channels), symbolic objects (references), activities (flows), and execution states (transitions).

Standard operators can also be applied to connectors:

Further Reading

• Building a Bridge
• UML# Manifesto
• Objects with Attitudes
• The Cases for Reuse
• Economics of Reuse

External Links

• Database Answers: Data Models
• Hillside Patterns Catalog