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.
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
- Where do you begin modelling the customers problem domain? This strategy makes this simpler: begin with the goals the business wants to accomplish.
- 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:
Leave a Reply