Adaptive software systems and their challenges - Part II

In my previous blog, I categorized what are the challenges faced by different software systems at runtime. This time I’m going to talk about how to face those challenges.

From a reason to a challenge
The uncertainties I talked earlier are common in designing any kind of system. In early days it was considered a failure of a system as a result of such an uncertainty is OK. Many software systems gave above issues as excuses for the failure of software. For example a failure of a proper functioning of a particular networked application, due to limited bandwidth was considered to be normal. And users were too accepted such a failure. And usually seek the help of some expertise. The Geek who’s sitting in the dark room. But as the time passes software architects wanted to find solutions for such issues and minimize failures in fluctuating environments.

From challenge to solutions
On one hand there is a continuous improvement of resources such as more memory, more processing power and more bandwidth. But at the same phase, the software systems too evolved into digesting more resources.
On the other hand software designs too shoved some kind of adaptability. For example a failure in a transaction resulted in rollback of the transaction. Basically the software started to sense the environmental context it is operated in. Thereby adjust its internal properties to suit the context, to support continues availability of the software.
Parallel to these developments, different kind of programming languages too supported such adaptability. The awareness of the platform they are operated in is inbuilt to the language and reflected in the API.
Different tools were also developed to support the adaptability. As an example GPS sensor in mobile devices gives the developers the capability of sensing the geographical location of the device operated in.

Architecture based solutions
The approach taken by the ROAD framework described in details in the thesis, is an architectural approach to adaptive software applications rather than introducing strategies or mechanisms. The thesis introduces three kind of adaptation. (Section 2.1)
1.Evolutionary adaptation : Reproduces instances with variations
2.Ontogenic adaptation : Change the internal structure
3.Environmental manipulation: Change the environment

The approach taken in the ROAD framework is based on the ontogenic adaptation, where the system itself regulates its internal structure based on the fluctuations in the environment. The system changes can be seen in two ways.

1.Indirection of instantiation: Changes to the elements, which the system is built upon. This includes replacements, modifications to the elements.
2.Indirection of association: Changes to the relationships of the elements within the system.

The ROAD framework considers such a system as an organisation, which consists of different roles with different responsibilities. Roles are assigned by role players and changed according to the environment they are operated on. Also new roles can be introduced and old roles can be discarded as well.
In my opinion the approach is a success due to following reasons.

1.Loosely coupled roles and role-players allow more freedom in instantiation, thereby allowing easier adaptation. Different players can be allocated to different to a particular role of the system depending on the environment change.
2.The recursive structure makes the design very simple and thus can be applied in very complex software requirements. In ROAD a system is consist of element which are intern similar systems. Just like in OOP where properties of an object or a class instance can also be another object.
3.A system is self-managed so as its elements are.