Comments

  1. Great pattern, thanks, Rob
    Very usefull technique to avoid risk of missing details.
    Human concentrates on details during implementation, unfortunatelly if implemetation hard – more and more details are missed. Starting from end – there are more chances to focus on all goals (functional, performance, non-functional, etc…).
     
    We talking about algorythm where efficient solution need to be issued – and there should not be a lot of iterations. But in case of many iterations – maybe it is a signal to split problem into few phases…

  2. @Dmytro nice addition to the advantages of the pattern, Dmytro: that it helps in getting lost in details.
    Regarding your problem of algorithm: is that a problem you are attempting to apply this pattern to? It sounds that maybe the Blackboard architecture pattern might be applicable as well? You will find it documented in the Buschmann books on Pattern-Oriented Software Architecture, and for example here: http://www.openloop.com/softwareEngineering/patterns/architecturePattern/arch_Blackboard.htm

    • Rob, you are right, today I’m trying to solve something similar to problem described in Blackboard architecture. But I’m focused on following problem context:
      … the same functionality could be called from different places – being differently initialized by caller. At this point – it is not trivial to implement component in imperative style. And without intelligent solution – the things are going like:
      – developer implements typical case
      – developer improves performance for typical case
      – being called from another context (another set of goals) – functionality is executed with performance overhead because:
      — there is unnecessary processing for excess goals
      — there is a lack of optimization for new goals
      Of course – somebody might decide to implement any case independently, but I’m afraid – this is not a good ballance for really dynamic (truly rich) systems.
      I hope there will be separate thread about Blackboard, and this is very important – because we will see how technology aspects could be separated from goals. This is a novice style of separation, the basis over Goal-Technology axis, which will eliminate inline calls/declarations from the flow of business events.

Leave a Reply

Your email address will not be published. Required fields are marked *

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

Trackbacks

  1. […] 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. […]

  2. […] 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. […]