|
Avoiding Feature Interactions in IN
by a Modular Architectural Model |
This page describes the post-doc research project of Dr. Jan Bredereke, to be performed at McMaster University, Software Engineering Research Group (Prof. D. Parnas), Canada, starting from Sept. 1997. The project is supported by the Deutsche Forschungsgemeinschaft (DFG).
Feature interaction problems in Intelligent Networks are an instance of a general software engineering problem: how can software systems be extended that are so large that no single person can understand them entirely? This problem is well known for a long time, and a general approach to it is the modularisation of the software system, obeying the information hiding principle, which allows a divide-and-conquer approach. In the case of Intelligent Networks, the task becomes even more challenging. The inherent concurrency of these software systems often leads to a complexity difficult to manage; usually, even a few simple components running concurrently generate a vast diversity of possible execution scenarios. Furthermore, the distribution aspect limits the amount of information on the current global system state that each component possesses.
The standardized Intelligent Network conceptual model (INCM) describes a basic call state model (BCSM) which models the currently existing telephone switching systems, and it defines an interface (detection points, DPs) which allows to add new features. This interface does not seem to be optimal. On the one hand, it allows (and sometimes forces) the designers of new services to introduce changes in the system that have a global effect, both on the control flow and on data. With this respect, the detection points allow too much, and the interface is too "wide"; there is no separation of concerns. These uncontrolled mutual influences of independently designed features are a major cause for feature interaction problems. On the other hand, the definition of each detection point implied substantial costs for software modifications, and therefore, there are still no detection points at several important places. For this reason, some envisioned features still cannot be realized since the interface does not allow access to certain data and states. With this respect, the interface is still too "narrow".
This leads to the following questions:
The approaches for tackling feature interactions are commonly divided into the three classes of detection, resolution, and avoidance. For detection and resolution, the application of formal methods is promising and already has resulted in some progress. Nevertheless, it is obvious that "after-care" can only push the limit, and can only push it to a certain point. At this point, it will be necessary to redesign the entire system in a fundamental way in order to add a single new class of features. Current feature interaction problems often stem from the fact that many of these features have not been anticipated. This can make it necessary that we not only add a feature, but that we simultaneously need to modify the base system directly or indirectly, which in turn can render implicit assumptions about the base system invalid. As Velthuijsen put it: "One way to deal with non-monotonicity would be to develop a service platform that supports the addition of most if not all features only through monotonic extensions." In the long run, it will be necessary to design a new platform that supports at least all currently known classes of features, and that in addition allows for new room for extensions.
With respect to a new architectural model for telephone switching systems, first work has been performed: Faci et. al. [FL97] investigate which impact (Lotos) specification styles have on the description of a telephone switching system architecture. Van der Linden [vdL94] proposes to use the principles of Open Distributed Processing (ODP). The TINA initiative is also based on ODP and uses its architectural ideas. Cattrall et. al. [CHJB95] present a new model for call processing. They use "roles" and avoid a certain class of feature interactions. Zibman et. al. [ZWO+95] propose an architecture consisting of agents. They stress the importance of separation of concerns and separate, e.g., users/terminals, calls/call legs etc. Their call processing model handles feature interactions separately from features. Instead of an architecture, Zave and Jackson [ZaJa97] describe requirements to telephone switching systems formally. They present five software engineering rules which help to attack complexity in this specific application domain.
In order to devise a new architectural model for telephone switching systems that avoids feature interactions or at least facilitates their detection and resolution, the three questions bulleted above must be answered.
First, the structure of the base system requires reconsideration. Up to now, it is considered as a monolithic block. We expect that its flexibility for extensions can be increased considerably by structuring it into functional components as independent as possible, thus separating concerns. This is similar to the "micro-kernel" approach in the area of operating systems. This approach attempts to remove as much functionality as possible from the operating system kernel and encapsulates it into separate modules. This comprises even the file system and the process scheduling. Analogously, we could encapsulate the preprocessing of dialled digits or the switching of a single call leg.
After the base system has been restructured, and a cleanly defined, narrow interface between its components has been introduced, this needs to be continued for the further features of the system. For each class of features, we require a dedicated access point where no other class has access. Each of these access points should be so narrow that it allows exactly the necessary accesses, but, for example, no arbitrary modification of the control flow or of arbitrary data structures. The entire interface, i.e., the union of these access points, in turn should be so wide that it specifically supports all classes of features considered. The current detection points are oriented strongly towards telephone switching systems that have grown over a long time, and currently many features must be attached to detection points that originally were designed for an entirely different class of features. After the first step of introducing an inner interface into the base system, this second step must render an interface open to the outside.
Such structuring should be of lasting value even when new, unanticipated features need to be added. Due to separation of concerns, modifications should then affect only a few components and maybe some of their connecting links, but not the entirety of the components.
It is methodologically crucial to check for every new feature whether there is already a suitable class of features. If not, a new access point needs to be added. This allows to structure the detection and resolution of feature interactions: in a first step, the interactions among classes are investigated, and in a second step, the interactions inside a single class are investigated. This reduces complexity considerably in comparison to the current check of every feature against every other feature.
During the definition of the access points dedicated to a single class of features, we will investigate another question: is it possible to simplify this dedicated interface further by inserting a second layer of universal access points into the (hitherto) base system? The dedicated external access points could then be based on this universal inner interface only. If the inner interface has at least a partial similarity to the current detection points, the new architectural model would be partially compatible to the current model, which would facilitate its short-term application.
| Univ. of Kaiserslautern | Dept. of Comp. Sce. | Computer Networks Group | Dr. Jan Bredereke | Avoiding FI in IN |