Behaviour Oriented Modelling

2010-01-12T12:40:00.000-08:00

According to laws of classical physics, the future state of a system can be determined solely from its present state. This means that behaviour of a system is the outcome of its state or structure. This is fundamental assumption underlying most engineering disciplines.

Most of the things we use like mobile or car are desired for their behaviour. We also understand that their behaviour is derived from their structure. So when we want to construct these things, we define their structure in detail and rather than their behaviour.

This process of defining the structure from the specified desired behaviour is not science. It is a creative process and we call it design.

We use this structural designing techniques for modelling buildings, bridges, aeroplane, car or pen and everything else in real world. If we get the structure right, the behaviour will automatically be as expected. This is underlying assumption in all our engineering methods. The efforts and cost of production depends entirely on the structure of entity we want to produce and not directly dependant on the details of its behaviour.

Software is different. In software, the behaviour can not be uniquely defined by its structure. So our approach for building software should be different, unfortunately it is not. We use the same engineering parallels even when the basic assumptions are not valid.

The design of real world object is constrained by physic. The nature of material, forces of physics provide a framework of constraints in which designer produce their designs.

Such structural constraints on software are non-existent. All the constraints are behavioural and provided in the form of Requirements. Therefore the constraints do vary dramatically from one software to another.

So I think we should focus on modelling the behaviour not the information or structure of software system. This means, we should be dealing with the units and entities of behaviour. We should use the language that expresses behaviour. I call this as behavioural modelling.

Below is my attempt to provide behaviour oriented modelling paradigm. Like class, Object, attributes and method in OO, behavioural models can have entities like Actor, activity, Task, Event etc.

Actor:

The analogy is taken from human or organisational worker. Actor can be completely specified by its behaviour- called activities. Actors have independent existence and lifecycle. They typically have long life span that is controlled or scheduled manually. i.e. they can be started or stopped manually. Actors can be hosted on separate computing device but can not be split onto multiple computing devices. They can be cloned and started on multiple devices simultaneously. A separate load balancing mechanism must be provided to balance the traffic among them. Actor can be available or unavailable for perfuming activities. Actor’s availability can be specified upfront in the form of schedule. It can be aware or unaware of surrounding actors.
Actors can have different types
e.g. Functional or control actors like Card functionality module
non-functional or intercepting actors like performance monitoring or security
interface or boundary actors like Presentation or DataBase interaction

Activity:
Activity is defined as actor’s behaviour. Activity can be a process or action. A process breaks the behaviour into multiple sub-activities by means of tasks. Task results into activities on self or other actors. Action does not break activity further.
Activity can be synchronous or asynchronous. Synchronous activity results into response.

Task & Event:
Task and Events contain information and instructions. Tasks or Events are used to trigger activity on another actor. Task is created during a performance of Process and Event is generated independently. Usually Event is a result of an external activity outside the scope of software.

Some principals of behavioural Oriented Model
• Software system can be divided into multiple actors without impacting overall behaviour such that these actors can be completely unaware of each other.
• Actors can be hosted separately on separate computing devices and therefore should have independent existence and lifecycle.
• Actors can communicate with each other and can have conversations. Conversations are carried out using tasks and events.
• Actors can form organisations just like humans do. Organisations can have formal structure.
• Actors can follow “division of labour” pattern just like real world organisation.
• Interface component module represent set of external entities having common behaviour (worker, databases) and can generate events on their behalf or perform tasks on their behalf.
• Functional component module represents functional behaviour of system such as business organisation. It contains processes and consumes events generated by interface modules to perform business processes.

Choreography and Orchestration : A software perspective

2009-11-30T11:24:00.000-08:00

While thinking about the complexity resulting from conventional object oriented techniques in building enterprise software, I realised that such complexity is in the nature of such OO-like systems as they grow really large.

What do I mean by OO-like systems? I mean the systems containing group of entities interacting with each other in a manner that is not very structured. The visible behaviour they produce is the effect of their co-ordinated efforts; and no single entity takes the responsibility for the total behaviour of the system.

There are many real life examples of such systems from human society, physical world or our own body that is made up of large number of cells.

I consider the behaviour of such system as a result of choreography. As in dance choreography- all the performers produce the desired effect together. They all must act synchronously in order to achieve the outcome and there is no central conductor involved to direct them at any given moment. The overall design or plan is distributed among performers with each one taking responsibility for his own steps.

Thus we can define choreography as – behaviour resulting from a group of interacting individual entities with no central authority.

What about orchestration then?

Orchestration is the other extreme when the behaviour is a result of centrally controlled authority. E.g we can consider human behaviour as result of brain, a central conductor controlling various organs, each one responsible for performing tasks independently.

This approach is similar to musical orchestra in which - a central conductor controls a group of performers independently performing their own instruments. There is no direct interaction between performers.

Thus orchestration can be defined as – behaviour resulting from a central conductor co-ordinating the behaviours of individual entities performing tasks independent of each other.

These two approaches are quite distinct but could be useful in producing intended behaviour such as in software systems. And I don’t think that these approaches are a matter of perspective only. They are useful techniques that we can employ to address complexity. Also they represent opposit ends of a spectrum and most systems fall somewhere in between.

As in real organisation, we employ both these techniques – orchestration by means of formal hierarchy and choreography within small teams for effective team work. Using both these techniques, real organisations can achieve their goal.

I expect, software too, should make clever use of orchestration and choreography to achieve intended behaviour. The present techniques have too much reliance on choreography – OO for example. BPEL does offer orchestration of services but I don’t think that’s enough to address the complexity we are facing at enterprise level.

Summary

Orchestration and choreography can be considered as separate approaches in software with properties as expressed below

Orchestration
• Has a central conductor
• Each performer performs tasks independently
• Tasks produce real world effect
• Performer is not aware of the orchestrating conductor(s) using it

Choreography
• Entities interact with each other to produce real world effect
• No central conductor, no overall responsibility
• Each entity carry part of responsibility

Employing Orchestration to model core organisation behaviour can simplify IT systems.

Architecture

Behaviour Oriented Modelling

Choreography and Orchestration : A software perspective