Tuesday, July 15, 2008

Make it adaptive, but avoid the complexity

That’s where the ROAD heading
One of the major challenges to be faced in designing adaptive software systems is the how to avoid the complexity. A complex design is always hard to develop and then very hard to maintain.
The complexity of such a system arises due to following reasons, which are in turn challenges to be faced by software architects.

  1. How to represent changing requirements at runtime?
  2. How to account for computational and network contexts at runtime?
  3. How to manage the system in a distributed architecture


Changing requirements

As we studied in our Software Engineering lectures, it is better to separate the user requirements from the design itself, to make it more maintainable. The design itself shows very little evidence about the exact requirements and most of the time is developed using set of interfaces and abstract functions. Requirements or the awareness of the run time environment is kept separate.
But the problem with this approach when it comes to adaptive systems is that it is necessary to know these requirements and make it available within the software itself. Java like languages tries to make the implementation to be separated by the specification using interfaces. But there are limitations in this approach too

  1. No mechanism to update interfaces at runtime
  2. Only functional requirements can be met
  3. Requirements are related to entity. Not the context in which they are applied to


Computational and network contexts at runtime
At the end the designed software executes on a physical computers or a network. The challenge posed by adaptive systems is how to identify the computational context in which operates on. This is further complicated by the fact that these contexts need to be account both for entities and for the composite as a whole.

Distributed/Open architecture
Though there are many attempts to go for a common middle ware standard, there is still no such. So the system needs to work with heterogeneous components in a distributed architecture.
So the question is how to find answers to these inherent challenges at the same time avoiding the complexity?

ROAD Framework
Role Oriented Adaptive Design is or ROAD in short is an attempt to answer the questions mentioned above. ROAD framework is based on the view that adapting the relationships among entities rather than entities it self. To put in another way adaptation is a property of the relationship rather than a property of an entity.

Key concepts

  1. Role: Description of the behavior of a functional entity
  2. Functional Entity : Role players such as services, objects and components
  3. Contracts: Connectors between roles.
  4. Organizer: A role that create/destroy roles.
  5. Self Managed Composite: A set of roles and contracts manages internally by an organizer.
  6. Management Interface: The interface of the SMC (Self Managed Composite) to the external world.


In my view the power behind the RODE framework is the separation of roles from its role player and the concept of self managed composites. All contracts are internal to the SMC, avoiding the complexity of the design.
Note that such a composite system can again be an entity which plays a role of another global SMC.

Let’s see how above challenges are met in ROAD framework

Facing Challenge #1:
The organizer manages the contracts rather than functional entities. Functional entities are bound to play the roles which can be reconfigured at run time depending on the changing requirements. New roles and contract may create depending on the requirements. Also the Manager binds the functional role players to its roles.

Facing Challenge #2:
As the runtime environment changes, the framework allows to add/drop roles or assign/replace/remove role players. The contract oriented nature facilitates such, without actually damaging the initial design.

Facing Challenge #3:
ROAD doesn’t require the knowledge of entities. Thus entities in heterogeneous technologies can interact and be managed.

More details can be found in this paper

2 comments:

Mahak said...

Dear Kau,
May I ask you what SMC in this note stands for?

mahboobeh@gmail.com

Malinda Kaushalye Kapuruge said...

Oops. I should've said it clearly.
SMC= Self Managed Composite.
Meaning a composition that manage itself to face environmental disturbances.