Inducing Functional Patterns from Design ones: a look in rear view mirror


Assuming patterns are meant to chart the path from problems to solutions, and given the foundational contribution of the Gang of Four (GoF), it may help to look at functional (aka representation) patterns backward  from the perspective of the now well established solutions framework (aka design patterns).

Matching Patterns (M.Kippenberger)

Patterns & Models

Patterns are handrails from stereotyped problems to well known and tested solutions, bringing the benefits of reuse for costs, quality, and traceability. Set within the Model Driven Architecture, patterns can be regrouped depending on their source and target:

  • Functional patterns deal with the representation of business objects and activities by system symbolic surrogates. They stand between computation and platform independent models. Whereas functional patterns are not to be confused with business patterns (used with CIMs), they are also known as analysis patterns when targeting PIMs.
  • Design patterns deal with the implementation of symbolic surrogates as software components.  They stand between platform independent and platform specific models.
MDA layers clearly coincide with reusable assets
Patterns and MDA layers

As it happens, there is a striking contrast between the respective achievements for design and functional (or analysis) patterns, the former, firmly set up by the pivotal work of the GoF, is nowadays widely and consistently applied to software design; the latter, frustrated by the medley of requirements capture, remain fragmented and confined to proprietary applications. Given that discrepancy, it may be worth to look in the rear-view mirror  and consider functional patterns from the perspective of design ones.

Objects, Classes, & Types

Design patterns are part and parcel of the object oriented (OO) approach and built on some of its core tenets, in particular:

  • Favor object composition over class inheritance.
  • Program to an interface, not an implementation.

Whereas the meaning of classes, implementation, and inheritance is specific to OO design, the principles can nonetheless bear upon analysis providing they are made to apply to types and composition, whose semantics have a broader scope. To begin with, if classes describe the software implementation of symbolic objects, and inheritance the relationships between them, types only pertain to their functional capabilities. As a corollary, the semantics of inheritance and composition makes no difference with regard to types, as opposed to classes. The lesson for functional patterns would therefore to favor types whenever possible, i.e when functional capabilities doesn’t depend on identities. Then, “programming to interfaces” would translate (for functional patterns) into describing communications between types. That approach being best represented by aspect oriented analysis. Not by chance, the lessons drawn above appear to be directly supported by the two criteria used by the the GoF to classify design patterns: scope and purpose. With regard to scope, class patterns deal with inheritance relationships between static descriptions fixed at compile-time, while object patterns deal also with relationships between instances which can be changed at run-time. With regard to purpose, creational patterns deal with objects instanciation, structural ones carry on with composition, and behavioral ones with algorithms and responsibilities.

Design Patterns Catalog
Design Patterns Catalog

The corresponding entries can be summarily described as:

  • Class/Creational: for new identified instances.
  • Object/Creational: for new parts of identified instances.
  • Class/Structural: for mixing interfaces using inheritance.
  • Object/Structural: for mixing interfaces using composition.
  • Class/Behavioral: for the definition of algorithms.
  • Object/Behavioral: for the collaboration between instances.

The next step would be to induce a catalog of functional patterns from those entries.

Inducing a Catalog of Functional Patterns

Leveraging the GoF’s design patterns, the objective is to spread the benefits upstream to the whole of the modeling process through a transparent mapping of functional and design patterns. And that could be achieved by inducing a functional catalog from its design equivalent. With regard to scope, the objective would be to factor out the architectural impact of requirements. Hence the distinction between architecture patterns dealing with business entities and processes consistently identified at enterprise and system levels, and aspect patterns dealing with features that can be managed separately. With regard to purpose the same semantics can be applied: creational patterns deal with objects instanciation, structural ones carry on with their composition and features, and behavioral ones with algorithms and responsibilities.

Functional Patterns Catalog: examples
Functional Patterns Catalog: examples
  • Architecture/Creational: for the mapping of business entities to their software surrogates. For instance, customers must be identified as parties (architecture/creational) before being fleshed out with specific features.
  • Aspect/Creational: for the intrinsic components of identified business entities. For instance, once created and identified as a customer, a foreign one is completed with the specific mandatory features of foreigners.
  • Architecture/Structural:  for inherited (i.e intrinsic) features of identified business entities.  For instance, foreign sales inherit specific invoice features.
  • Aspect/Structural:  for associated (intrinsic or otherwise) features of identified business entities. For instance, foreign sales delegate invoicing in foreign currencies.
  • Architecture/Behavioral: for the definition business rules attached to entities and managed by business domains. For instance invoicing rules are specialized for foreign currencies.
  • Aspect/Behavioral: for the definition of collaboration between entities independently of business domains. For instance allocating responsibilities at run-time depending on the invoice.

As can be seen with the MDA diagram above, this catalog is neutral as its entries are congruent with the categories used by the main modeling methodologies : use cases, domains, business rules, services, objects, aspects, etc.

Recommended Reading

Gamma E., Helm R., Johnson R. and Vlissides John M. , “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley (1994).

Further Reading

Business Processes & Use Cases


As can be understood from their theoretical basis (Pi-Calculus, Petri Nets, or State Machines), processes are meant to describe the concurrent execution of activities. Assuming that large enterprises have to keep a level of indirection between operations and business logic, it ensues that activities and business logic should be defined independently of the way they are executed by business processes.

Communication Semantics vs Contexts & Contents (G. Winogrand)

For that purpose two basic modeling approaches are available:  BPM (Business Process Modeling) takes the business perspective, UML (Unified Modeling Language) takes the engineering one. Yet, each falls short with regard to a pivotal conceptual distinctions: BPM lumps together process execution and business logic, and UML makes no difference between business and software process execution. One way out of the difficulty would be to single out communications between agents (humans or systems), and specify interactions independently of their contents and channels.

Business Process: Communication + Business Logic

That could be achieved if communication semantics were defined independently of domain-specific languages (for information contents) and technical architecture (for communication channels). As it happens, and not by chance, the outcome would neatly coincide with use cases.

Linguistics & Computers Parlance

Business and functional requirements (see Requirements taxonomy) can be expressed with formal or natural languages. Requirements expressed with formal languages, domain-specific or generic, can be directly translated into some executable specifications. But when natural languages are used to describe what business expects from systems, requirements often require some elicitation.

When that challenge is put into a linguistic perspective, two school of thought can be considered, computational or functional.

The former approach is epitomized by Chomsky’s Generative Grammar and its claim that all languages, natural or otherwise, share an innate universal grammar (UG) supporting syntactic processing independently of their meanings. Nowadays, and notwithstanding its initial favor, that “computer friendly” paradigm hasn’t kept much track in general linguistics.

Alternatively, the functionalist school of thought considers linguistics as a general cognitive capability deprived of any autonomy. Along that reasoning there is no way to separate domain-specific semantics from linguistic constructs, which means that requirements complexities, linguistic or business specific, have to be dealt with as a lump, with or without the help of knowledgeable machines.

In between, a third approach has emerged that considers language as a functional system uniquely dedicated to communication and the mapping of meanings to symbolic representations. On that basis it should be possible to separate the communication apparatus (functional semantics) from the complexities of business (knowledge representation).

Processes Execution & Action Languages

Assuming the primary objective of business processes is to manage the concurrent execution of activities, their modeling should be driven by events and their consequences for interactions between business and systems. Unfortunately, that approach is not explicitly supported by BPM or UML.

Contrary to the “simplex” mapping of business information into corresponding data models (e.g using Relational Theory), models of business and systems processes (e.g Petri Nets or State Machines) have to be set in a “duplex” configuration as they are meant to operate simultaneously. Neither BPM nor UML are well equipped to deal with the task:

  • The BPM perspective is governed by business logic independently of interactions with systems.
  • Executable UML approaches are centered on software processes execution, and their extensions to action semantics deal essentially on class instances, features value, and objects states.

Such shortcomings are of no serious consequences for stand-alone applications, i.e when what happens at architecture level can be ignored; but overlooking the distinction between the respective semantics of business and software processes execution may critically hamper the usefulness, and even the validity, of models pertaining to represent distributed interactions between users and systems. Communication semantics may help to deal with the difficulty by providing relevant stereotypes and patterns.

Business Process Models

While business process models can (and should) also be used to feed software engineering processes, their primary purpose is to define how concurrent business operations are to be executed. As far as systems engineering is concerned, that will tally with three basic steps:

  1. Dock process interactions (aka sessions) to their business context: references to agents, business objects and time-frames.
  2. Specify interactions: references to context, roles, events, messages, and time related constraints.
  3. Specify information: structures, features, and rules.

Communication with systems: dock to context (1), interactions (2), information (3).
Communication with systems: dock to context (1), interactions (2), information (3).

Although modeling languages and tools usually support those tasks, the distinctions remain implicit, leaving users with the choice of semantics. In the absence of explicit guidelines confusion may ensue, e.g between business rules and their use by applications (BPM), or between business and system events (UML). Hence the benefits of introducing functional primitives dedicated to the description of interactions.

Such functional semantics can be illustrated by the well known CRUD primitives for the creation, reading, updating and deletion of objects, a similar approach being also applied to the design of domain specific patterns or primitives supported by functional frameworks. While thick on the ground, most of the corresponding communication frameworks deal with specific domains or technical protocols without factoring out what pertains to communication semantics independently of information contents or technical channels.

Communication semantics should be independent of business specific contents and systems architectures.
Communication semantics should be independent of business specific contents and systems architectures.

But that distinction could be especially productive when applied to business processes as it would be possible to fully separate the semantics of communications between agents and supporting systems on one hand, and the business logic used to process business flows on the other hand.

 Communication vs Action Semantics

Languages have developed to serve two different purposes: first as a means to communicate (a capability shared between humans and many primates), and then as a means to represent and process information (a capability specific to humans). Taking a leaf from functional approaches to linguistics, it may be possible to characterize messages with regard to action semantics, more precisely associated activity and attendant changes:

  • No change: messages relating to passive (objects) or active  (performed activity) states.
  • Change: messages relating to achievement (no activity) or accomplishment (attendant on performed activity).

Basic action semantics for interactions between users (BPM) and systems (UML)

Communication semantics can then be fully rounded off by adding changes in agents’ expectations to the ones in the states of objects and activities, all neatly modeled with state machines.

Communication semantics: changes in expectations, objects, and activities.

It must also be noted that factoring out the modeling of agents’ expectations with regard to communications is in line with the principles of service oriented architectures (SOA).

Additionally, transitions would have to be characterized by:

  • Time-frame: single or different.
  • Address space : single or different.
  • Mode: information, request for information, or request for action.

Organizing business processes along those principles, would enable the alignment of BPMs with their UML counterpart.

Use Cases as Bridges between BPM & UML

Use cases can be seen as the default entry point for UML modeling, and as such they should provide a bridge from business process models. That can be achieved by if use cases are understood as a combination of interactions and activities, the former obtained from communications as defined above, the latter from business logic.

Use Cases are best understood as a combination of interactions and business logic
Use Cases are best understood as a combination of interactions and business logic

One step further, the distinction between communication semantics and business contents could be used to align models respectively to systems and software architectures:

Last but not least, the consolidation of models contents at architecture level would be congruent with modeling languages, BPM and UML.

Further Reading

External Links