ANISE (Architectural Notions In Service Engineering)
Introduction
This project is being undertaken by Ken Turner. The initial work was sponsored by British Telecom during a short-term fellowship at the BT Labs.
The author's belief is that weaknesses in service architecture are an important cause of feature interactions. Of course this is not true of all feature interactions, but it is believed that an improved understanding of service architecture is an important step towards identifying interactions. The author has laid the foundation for service architecture description, and has extended this to describe services typical of the Intelligent Network (IN).
The major advantage of the approach is architectural consistency, since all the elements of a service have the same status and are described in the same kind of way. Also because the approach is compositional, there is a rigorous foundation on which higher level services can be built. This permits systematic definition, formal description, rapid prototyping and methodical analysis. The architecture is user-oriented in the sense that it concentrates solely on the interactions a user has with services.
A different approach by the author to service creation is that of CRESS (Communication Representation Employing Systematic Specification).
The author previously worked on the definition of services in OSI (Open Systems Interconnection). This led to the language and tools called SAGE (Service Attribute Generator). However, since OSI services are much more regular than IN services, SAGE was not immediately applicable to telecommunications. The author therefore adapted the conceptual approach of SAGE. The result is ANISE (Architectural Notions In Service Engineering) - a language for rigorous definition of IN and telecommunications services. The emphasis in ANISE is on behaviour as it is perceived by a user. ANISE uses well-defined patterns of behaviour, allows flexible definition and modification of services, and supports rigorous definition and analysis of services.
The ANISE approach is bottom-up, but from a user's perspective rather than an engineering viewpoint. The idea is to construct features and services as combinations of the signals exchanged between a telephone user and the network (going off-hook, dialling a number, etc.). A feature is characterised by the rules for exchanging these signals. Since higher-level features are built from lower-level ones in a consistent way, everything is just a feature in ANISE. Features in the IN are generally at a high level and are relatively close to services. Features in the ANISE sense start out being rather elementary but grow towards the level of the IN.
It is interesting that the ANISE and IN philosophies are almost diametrically opposed. ANISE focuses on user behaviour and so is implementation-independent. ANISE emphasises high-level architectural issues and intentionally ignores the details of actually building telecommunications networks. ANISE is intended for describing and analysing services without consideration of engineering issues. ANISE is not required to create specifications that are somehow refined into an implementation (though this is a possibility). By way of contrast, the IN focuses on engineering detail and so is rather concrete. Although the IN defines planes of abstraction and purports to show a relationship between these, in practice everything is driven bottom-up by engineering concerns. As a result, the IN service architecture is rather unsatisfying in the author's opinion. ANISE and the IN approach are thus complementary.
Initial work on ANISE concentrated on architectural and language issues. However it is the foundation for describing realistic IN-type services and contributing to the detection of feature interactions. The key idea is that new services are generally modifications of the basic call (or of existing services). Changes in basic call behaviour are possible causes of feature interaction and so are spotlighted for investigation.
ANISE allows potential areas for feature interaction to be detected statically. A service is defined by its `deltas' - the textual changes it causes to the basic call description in ANISE. This allows services to be described compactly in terms of their changes to the basic call. More importantly when the `deltas' of different services are compared, the approach highlights where services overlap statically. If services modify the same parts of an ANISE description, this is an indication of interdependence and hence of potential feature interaction. The modifications could conceivably be combined compatibly, but the specifier should look carefully at how such integration could be achieved - if at all.
ANISE also allows feature interactions to be detected dynamically. A scenario language allows service validation tests to be formulated and applied rigorously. This permits services to be checked in isolation and also in combination. It is in this latter case that dynamic interactions among features may appear. Tests are applied automatically, and any failures or inconclusive results are also diagnosed automatically.
ANISE contributes towards the detection of feature interactions at an early stage in specification. The principle has been to develop a rigorous, user-oriented, architectural method for describing services. It is believed that a sounder understanding of how to construct services will lead to a more structured approach, thus making the detection of interactions easier.
The technical basis of ANISE is principally contained in the following published papers:
In addition, the following papers are relevant:
ANISE has automated tool support for the translation of descriptions and tests to LOTOS, and for the automatic application and analysis of these tests. The prototype toolset is available for downloading. The tool architecture is as follows:
Up one level to Ken
Turner - Research Projects