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.:
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