Time Inversion Pattern

This post is also available in: Nederlands (Dutch)

Inverse Time

Intent

The Time Inversion pattern is used to model dynamic collaborative behaviour between model components. To choose which responsibilities should be endowed upon a component, the modeller considers a goal that should be reached by one or more key components. This goal should be the end-goal. Reasoning backward from this end-goal the modellers searches for other components to delegate behaviour to, but in an inverted time frame: the first modelled object implements the last step in reaching the goal, the second the last step before that, and so on. The choice of candidate objects is from a list of active objects obtained from the Active/Passive pattern.

[toc]

Also Known As

Example

A model that implements a business process that builds and delivers cars would probably contain an active object Car. The main responsibility, as last in the business process steps, could very well be: deliver yourself to the customer. Sometimes a responsibility named “sell yourself” is used.

How can a car deliver itself? Well, we define a method (=responsibility) in the class Car, called Deliver. We dive into the method that should be executed when the car does this. What is the last thing that should be done in order to satisfy the Deliver responsibility? We might decide that this is the fact that the car dealer drives the car to the customer site. So we need a CarDealer, and we create this class/object with the responsibility DriveToCustomer. How can the car dealer drive the car to the customer site? He needs to have the car. The car, in order to be able to exist on the dealers site, needs to build itself: Build. This is a new responsibility, in the case of aggregates largely delegated to the composing elements. Etc.

Context

Problem

  1. Where do you begin modelling the customers problem domain? This strategy makes this simpler: begin with the goals the business wants to accomplish.
  2. How can you know that the way you model things that are done, are not modelled in such a way as to be almost impossible to change?

Modelling a complex business domain often is very hard, and it is even harder to find out where to begin.

Solution

Walking backwards along the process chain, creating active objects along the way, the car would build itself, parts would build themselves and assemble themselves, factories making the parts would pay themselves, etcetera. This is a backward inferencing process, a demand-chain process. In general, the goal objects generate the process to achieve their goals.

Structure

The resulting object graph is able to perform one or more trees of business processes, where the roots of the trees are the final business results. However it is important to remark here that the object graph structure itself is not at all directly conceived from these processes. Instead, various, sometimes incomplete, processes are taken during the modelling phase to “play out” by existing and newly created objects. This leads to an object graph that can be validated to at least be able to perform the defined processes, but usually is able to perform a superset of these input processes.

Variants

Known Uses

The Time Inversion Pattern is one of the two primary patterns used in eXploratory Modelling (xM). Behaviour of objects is realised by thinking about the final goal of an object, and to decide upon the last previous action needed to accomplish this goal. This final or last action is usually delegated to a new object (usually an Active Object), upon which the modeller jumps to this object, and tries to find out the previous action in this object in the same way.

Consequences

By using the demand-chain modelling strategy models gain in flexibility, especially in the case of uncertainty, vague business requirements, processes that are difficult to made concrete or should be highly optimised.

The resulting solution, the model, may lack structural consistency: models can be redundant and impossible to understand on a global level. This is a potential problem, but we argue that in the case of the kind of model we talk about, this is usually not so. We create models that are complex, difficult to overview or comprehend, but because of the high cohesion this actually works in favour of the model instead of against it.

An important pattern to employ in this case of growing models is the Add, don’t Modify pattern.

See Also

This pattern is usually combined with the Active/Passive pattern, because the choice of where to place the previous process step to is determined by selecting an active object that is usually the passive one in the real world.

This pattern is well known and documented in the supply-chain management theory. A good book introducing this is:

Supply Chains: A Manager’s Guide (paperback)

Comments (14)

  • […] Sessions start by exploring the desired end result or goal of a typical use of the system, or preferably of the business that we are building a business model for. An example can be an insurance product: the goal is that this product is purchased by a customer. The first step might be to create an actual, visible instance of InsuranceProduct. The modelling team will see this object on the screen, and it may be adorned with an icon to designate as an insurance product. Also this object will typically stay alive during many modelling sessions, not just this one. It will grow, accumulate all kinds of different objects around it to extend its functionality and to complete the vision of the business about its business domain. This is an application of the Time Inversion Pattern. […]

Geef een reactie

This site uses Akismet to reduce spam. Learn how your comment data is processed.