Håkon Vestli and Raymond Nilsen
The intelligent network (IN) service life cycle is an abstract description of the structured, methodical development and modification process showing the main stages in producing and maintaining IN services. Starting with the life cycle for ordinary software, a life cycle model for IN services is developed. The description of this life cycle is supported by role models for each stage in the cycle. The role models are simple object oriented models that we synthesise into one composite model. We map this composite model onto a model of the physical entities that constitute a telecommunications network in order to exemplify how we can implement a service environment that supports the IN service life cycle.
In this paper we focus on the life cycle for services in a future intelligent nework (IN). The study of the IN service life cycle will give us models of the environment in which IN services will exist. We intend to show by example how such models can be implemented. The terms intelligent network, service and environment need explanations in order for the reader to fully understand the focus of this paper. It is also necessary to explain some aspects of the modelling technique we will use. In sections 1.1 through 1.3 we will make some scene-setting remarks which will serve as brief introductions to each of the terms mentioned. In section 1.4 we discuss the particular methodology we use in the rest of the paper, and in section 1.5 we give an overview of the paper.
The common understanding of the term intelligent network refers to a telecommunications network that supports features such as fast service provisioning, vendor independence and efficient use of resources. It is currently expected that IN activities will give solutions on service creation, service interaction, pan-European services, modelling of specific services (such as Universal Personal Telecommunications and Virtual Private Networks), etc. This enhancement of requirements indicates that the major task to be performed during the development of an IN is to model all aspects of services including what they are, how they are specified, built, installed, activated, invoked, executed, etc. In this way we are able to uncover the detailed service requirements of a target IN architecture and finally identify a set of steps to evolve from today's networks towards the target architecture.
Most international activities on IN (in CCITT, ETSI, ECMA, etc.) seem to indicate that modelling of services in an IN primarily should specify service functionality. In (1) we follow the idea of complete separation of service related functionality and switching related functionality on the design level. In this context separation implies separate modelling of service related and switching related functionality, bridging the two models with a carefully designed interface. An important consequence of this separation is that it conveniently supports the strive towards network independent services. The aspect of separate modelling has a built-in notion of independence in the sense that when we are modelling one part, we can only see the other part from our side of the interface, i.e. when we are modelling service related functionality, we have no knowledge of switching related functionality except for those functions offered over the interface. See Figure 1.
The proposal allows general service logic to be considered without reference to the actual network supporting the services thereby achieving network independent service specifications. This separation simplifies the problem of modelling services because it allows us to focus on general properties of services rather than switching dependent issues. In fact, the separation represents a practical way of defining subproblems and it allows for easier incorporation of results from work done outside the telecommunications community.
In principle services in an intelligent network can be thought of as applications in a huge distributed computing system. It seems to be fruitful to utilise this analogy as it allows us to reuse much of the results from areas such as software analysis and design, programming techniques, formal description techniques, etc. It provides us with a flexible notion of the concept of a service which simplifies development of methods for fast, secure, and efficient manufacturing of service software.
In this article we will adopt a view of services according to the `black box' principle, i.e. the input and output of the service are the only observable features of the service. In other words, we do not say much about the internal structure and functionality of them - the focus is on the environment they exist in.
We define a service environment as a model of the surrounding functionality that is necessary for a service to proceed through its life cycle. The life cycle of a service will be discussed in detail in section 2. The set of models resulting from the discussion in section 2 will be used as a basis for the specification of a total runtime environment for services. The scope of this paper is to realise some guidelines for how a service runtime environment must behave.
There is no sharp boundary between what can be defined as a service and what can be defined as the service environment. We can, however, introduce one general principle for how we would like to separate between services and the service environment, namely that features that are unique to a service should be defined to be within that service, while features that are common to many services should be defined as parts of the environment. It is also of importance to design the service environment as general as possible in order to be able to support future services.
To support the descriptions of the various life cycle stages, we use parts of an object oriented modelling technique called Object Oriented Role Analysis, Synthesis and Structuring (OORASS), see (4, 5) where the following description primarily is taken from:
In general, an object oriented system may be thought of as a kind of perfect bureaucracy, where each object is like a clerk who is responsible for a certain part of the whole operation (the clerk plays a role in the undertaking of the operation), and where things happen when the clerks pass messages to each other. Object oriented design is then to design the pattern of this interaction and to delegate responsibility to the individual objects in such a way that the total system of objects is as simple as possible while it shows the desired behaviour.
OORASS is a comprehensive method for industrial analysis, design, implementation and configuration of object oriented systems. The OORASS methodology comprises Role Modelling, Object Specification, Class Implementation, Structure Configuration and System Instantiation. In this paper we will only use Role Modelling, which is separated into role analysis and role synthesis.
In this paper, we use role analysis to study the IN service life cycle. Each life cycle stage will be supported by a role model that offers an implementation-independent description of interacting roles. A role is to be understood in a traditional sense as an entity's task or duty in an undertaking - the focus is on behaviour. For each role in a role model we give it a name, describe its responsibility, determine which other roles it needs to know about, and determine the messages it sends to these. If the behaviour of a role is complex, it can be represented by its own role model on a lower level.
When we subdivide the area of concern (the IN service life cycle) into smaller areas (stages), creating role models for each subarea, we reduce the modelling problem to manageable proportions, but create the new problem of integrating the smaller models into a model of the entire area of concern. In OORASS, the solution to the integration problem is called role synthesis: Given a number of role models, we create a set of objects, each of which may play roles from different role models.
For an example of role modelling, see Figure 2. We have simplified and slightly modified the OORASS way of drawing role models in order to support our particular needs.
In section 2 we introduce and discuss our definition of the IN service life cycle. Starting with a description of the life cycle for ordinary software, the IN service life cycle is developed. We describe in detail each stage and support these descriptions with simple role models. In section 3, these role models are synthesised in order to get a composite model. This model is then mapped onto a model of the physical resources that constitute a telecommunications network, in order to exemplify how we can span the gap between high-level modelling to concrete implementation, yielding a service environment that supports the IN service life cycle. In section 4, we give our concluding remarks.
We regard services as software applications to be run in the telecommunications network. Since services are software we can introduce the discussion of the service life cycle by skimming through the life cycle for ordinary software systems.
By common usage a life cycle model is an abstract description of the structured, methodical development and modification process typically showing the main stages in producing and maintaining executable software (3). A typical life cycle model is the following:
1 Analysis: Analysing the user's requirements.
2 Specification: Describing what the system should do, as seen from the user.
3 Design: Describing the system's interfaces, functionality and structure as the designers intend to implement them.
4 Implementation: Producing the programs.
5 Installation: Installing the programs on the target computer system.
6 Use and maintenance: As the software is used, errors and new requirements are usually uncovered. Maintenance is the task of modifying the software so that the errors are eliminated and the new requirements are taken care of.
Iteration between the phases is often necessary, but it should preferably be confined to successive steps.
What is specific about intelligent network services software? First, the target computer system on which the software is to be installed, is a huge distributed telecommunications network. Second, there is a large amount of users, subscribers and of potential services. Third, there are severe constraints regarding response time and availability of the services in the network. These factors are important in the modification of the ordinary software life cycle so that it becomes a service software life cycle. The service life cycle we suggest is shown in Figure 3.
In discussing the actors we will also mention the various roles the actors will be represented by in the role models to follow in sections 2.2 through 2.4.
The User:
The User is the party that wants to use services. That is, the Users constitute the target group for a service. The subscriber himself can be the only user, alternatively the subscriber intends the service to be used by other parties. The User will be represented by the Service Requester role.
The Subscriber:
The Subscriber wants to subscribe to a service. This may require the creation of the service if existing services cannot be used to fulfill the Subscriber's requirements. The Subscriber is represented by the Subscriber role and indirectly by the Service role.
The Service Creator (also called Service Provider):
The Service Creator is a party that has a license for producing telecommunications service software to be installed in the telecommunications network. The Service Creator receives requests for creating a service from a subscriber or can initiate the creation of services himself, in which case the Service Creator also acts as Subscriber. General services can be made intended for being subscribed to by many people. Services can also be tailor-made to one particular subscriber. The service creator can be the network operator, a network equipment vendor or in general an independent software manufacturer. The Service Creator is represented by the Service Creator role, which will need various Handler roles: for Service Descriptions, Service Specifications, Service Designs and Service Implementations.
The Network Operator (also called Network Provider):
The Network Operator is the party that controls the physical resources required for offering a telecommunications network for use by the parties mentioned above. The Network Operator will therefore be represented by a multitude of roles: the Database, the Database Handler, the Installation Manager, the Activation Manager, the Allocator role, the Service Execution Manager, the Switching Domain role and also the roles concerning Communications, Monitoring, Resource Management, Traffic Management and Data Management.
These actors constitute a hierarchy that can be described by client-server relationships:
The early phases of the service life cycle comprise the activities from the service idea is conceived until the service is activated and ready to be invoked, i.e. the analysis, specification, design, implementation, installation, and activation phases.
The main task is here to produce a definition of the characteristics of the service, focusing on how the subscriber wants the users to see it. This implies close cooperation between the service creator and the subscriber in order to bridge the gap between the subscriber's requirements and the service creator's assessment of what is a feasible service. See Figure 4 for the Service Analysis role model.
In this phase, the service is specified according to the subscriber's requirements. The output from the previous phase must determine this specification as unambiguously as possible. The specification should be written in a formal language so that it can be checked for consistency and also so that programs generated later can be verified against it. Another reason for formalising the specification is that it increases the possibility of automation in the design and implementation of the service.
The specification is supposed to be developed under the constraints or restrictions the network as a whole imposes on all services. That is, we cannot in practice allow for arbitrary applications to be installed in the telecommunications network - there has to be a strict control of which applications are allowed as services. Therefore, it must be checked that the specification represents a meaningful telecommunications service, and that the service does not compromise the network, the network operator or other network users.
It is important that the subscriber can confirm that the specification produced satisfies his requirements, i.e. that it represents the service he wants. This is usually called validation. One way to validate a service is to rephrase the specification in a language the subscriber is accustomed to, e.g. natural language.
During this phase, the service creator will find out to what extent existing services can be used. It may be that the service is unprecedented in the network, which means it must be specified, designed, implemented and installed. On the other hand, it may be that the subscriber's requirements are fulfilled by subscribing to an existing service, and the design and implementation phases can therefore be omitted. If that existing service is adequately installed to serve the new subscriber, the service is ready for activation of the new subscription, but if not, then the service goes to the installation phase first.
See Figure 5 for the Service Specification role model.
To facilitate rapid and efficient introduction of new services, we envisage extensive reuse of specifications and software. In the design phase services are designed by assembling reusable software components in a controlled manner. Most of the software components are already designed in detail - the design of the service concerns the problem of putting various software components together according to the specification. This should be a trivial task, supposing there is a well- defined mapping between the specification constructs and the design objects.
We can envisage that such software components are standardised, in order to facilitate international IN services. On the other hand, a service creator must be allowed to produce software not covered by the set of standardised software components, both to support the subscribers' particular needs and also to get a competitive edge in the service market. This means that new software components can be made at the service creator's discretion. This new software has to be designed in detail in this phase, so that the service as a whole is completely designed.
See Figure 6 for the Service Design role model.
The implementation phase concerns the production of complete programs that satisfy the specification of the service. The implementation will ordinarily contain both new software and reused software. Reused software is taken from a software library while the new software has to be implemented now.
When we have the complete source code, we may be able to formally verify that this code satisfies the specification. There can be features required by the subscriber that are not formalisable. Such requirements will lie outside the scope of verification, and to complement the verification activity, testing or simulation of the service should be performed.
See Figure 7 for the Service Implementation role model.
Performance is of utmost importance in the telecommunications network. This concerns the speed with which services are executed and the requirement that all services are available at all times. To cope with this requirement, we need a decentralised solution, where software and data can be distributed in the network instead of residing in a centralised network node. Distribution concerns both how one unit is divided into different parts and how these parts are replicated in the network. Note that when software or data are replicated we get problems concerning the consistency between different copies of the same unit.
The distribution of service software is a typical optimisation problem, where the objective is to minimise the volume of data and the number of messages transmitted across the network during the execution of services. Parameters in this optimisation problem are the locations of users, the frequency of usage, the network topology, database sizes, etc. Ideally, once the service is installed it should be possible to dynamically modify the distribution of software and data as these parameters change.
When the distribution of the software is determined, the source code can be compiled into machine code depending on the hardware of the network, and then this can be installed.
We should have seamless addition of services. That is, the actual installation should be performed without any interruption of the network.
See Figure 8 for the Service Installation role model.
Activation means that the service is made available to the users, that is the service can now be invoked. We refer to the activation of a service in three different cases:
Activation can be limited to a certain set of users, a certain geographical area, etc.
See Figure 9 for the Service Activation role model.
The service is now activated and ready to be invoked. Here we describe in more detail the invocation and execution phases.
A service is invoked when a user sends a request for the execution of the service to the network. The network has to identify the user requesting the service, the service that is requested (possibly demanding user authentication or authorisation), retrieve the information necessary to start the service (including data or program code), and finally initialise it. See Figure 10.
The service has now been invoked and initialised and is now executing. A role model to support the description is shown in Figure 11.
The service to be executed can be a simple service, e.g. a two-party-call. On the other hand, the service can be a service application that on the basis of a dialogue with the end user determines another service that is to be invoked. For example, imagine that the end user has a computer as his terminal equipment. Imagine further that the user is running a window manager on his computer. One of the menu items the user can choose in his root window can be a telecommunications service called, say, TeleMenu. When TeleMenu is invoked, it presents the end user with a menu containing a list of all his telecommunication services, e.g. video conference, remote database access, remote interactive video. When choosing one of these, the service TeleMenu then acts as a service requester, requesting the invocation of the chosen service. The point is that executing services can invoke other services. This is a part of the problem area of service interaction.
Since it is desirable to define services independently of the type of network, the running service software should not have direct access to the interface between the service domain and the switching domain. The service applications should rather use roles in the service domain that know how to talk to applications in the switching domain, i.e. roles in the service domain representing switching functionality. For this purpose a Communications role can be constructed that represents the switching domain's functionality regarding connections in the telecommunications network. For instance, if the service application wants to establish a connection between two parties, it requests the Communications role to do this. The Communications role maps this request onto the protocol between the service domain and the switch-based connection control functions.
Extending this example, a set of roles that together with the Communications role cover the switching domain functionality can be constructed. The Monitoring role offers monitoring of connectivity in the telecommunications network. The Resource Management role offers management of resources in the telecommunications network. The Traffic Management role offers management of telecommunications network traffic. The Data Management role offers management of data in the switching domain. Note that these intermediary roles can be addressed by several services. This allows for one service transferring the control over for example a Communications role to another running service. The design of these roles is inspired by ETSI's Connection Control Model (2).
Sooner or later, the service is getting obsolete. This requires deactivation and deinstallation.
Deactivating a service is making it unavailable to users, that is, it can now not be invoked. The service can be reactivated at a later stage. Deactivation can be performed for a certain set of users, a certain geographical area, etc. We can here use the same role model as for Service Activation, see Figure 9.
Deinstallation occurs when the subscriber wants to quit his subscription, or if the subscriber for some reason or other is not allowed to subscribe to this service. Reusable parts of the specification and program code can be retained, but the service software should be deleted from active network resources unless it is shared by other subscribers. We can here use the same role model as for Service Installation, see Figure 8.
Let us give an example of how we think this life cycle would look like in a concrete case. This is a very simplified example, and it is only meant to illustrate the previous discussion of the service life cycle.
Gary, the boss of a travel agency, has plans for opening a new chain of travel agencies across the country. He is already heavily using IN services, and has now an idea for a tailor-made IN service to be used by his customers in his new travel agency chain. Let us proceed through the IN service life cycle to see how his idea for an IN service is gradually refined into a new service.
Gary makes an appointment with the service consultant Berke at the closest authorised IN service creator, a company called IN Services Ltd. When they meet, Gary comes up with his service idea. His travel agency chain has offices in four cities. Gary wants one phone number to cover the entire chain, he wants his customers to be able to call his offices free of charge, and that the calls are routed to the nearest office. If all extensions at one office are busy or the office is closed at that moment, the caller will be rerouted to another office. When there is a call outside working hours, the caller is to be told when the office opens. Gary and Berke discuss this idea thoroughly, uncover all details Gary has not thought of on his own, and they end up with a document written in natural language that describes the service. They meet a couple of days later to make the last adjustments to this description.
Berke now takes the service description with him to his workstation, where his specification tool is running. He finds no existing specification he can reuse, so he has to go through the service description very thoroughly and transcribe it into a formal language. The specification he produces looks a lot like mathematics, but is in fact rather easy to read. In the specification tool, there are service checkers that go through the specification to find inconsistencies and things that could disrupt the network. After a couple of iterations, Berke is satisfied with the specification. He puts it through a translator, gets a natural language version of the formal specification, and makes an appointment with Gary. At that meeting, Berke goes through both the formal specification and the rephrased version with Gary to get a confirmation that this is really the service Gary wants. It turns out that Gary is very happy with the specification.
Berke now uses his service design tool to transform the specification into a concrete design of the service. This is a rather trivial job, since there is a well-defined mapping between the formal specification language and the object oriented language the design is written in. There are some small enhancements to the design, but Berke is satisfied with the design after a relatively short period of time.
The source code of the software components that were reused in the design, is retrieved from a software library. Berke only has to implement those small enhancements he made to the design in order to get a complete implementation. The resulting piece of software has a well- defined interface to the IN service environment, and is supposed to fit in without problems. Berke is convinced of that after he has churned his code through a verifier to check it against the specification.
The appropriate parts of the software produced are compiled and put in IN nodes in the four cities mentioned above. System software on each node is modified to take account of the new service. Central registers are updated with Gary's new subscription, charging rates are stated, etc.
When all the software is properly installed and all registers are updated, the service can be activated. That means that the service can now be used. At activation time, Gary is extensively running commercials in order to make the market aware of his new travel agency chain and of the IN service the customers can use in order to reach its offices.
Paulina has for a long time been thinking of taking a well-deserved vacation to the Seychelles. But the trip is expensive, and she has not had the time to do it. Now she sees in the paper the commercial for Gary's travel agency chain, which includes a good offer for trips to the Seychelles. She sees the freephone number and runs for the phone.
The software in Paulina's terminal that transfers the digits to the network is playing the Service Requester role. The Allocator role in the network analyses the digits, loads the data concerning the dialled number from the Database Handler role and `understands' that Paulina is requesting Gary's freephone service. The Allocator then puts the service's machine code in memory, and initialises the service to be run.
The Service role analyses Paulina's number and uses the Communications role to set up a connection to the nearest office, which the service supervises by using the Monitoring role. The Service Execution Manager role supervises the running of the service. Paulina gets the connection and ends up with ordering one of the low-price trips to the Seychelles. As she breaks the connection, the Service role sends messages to the Database Handler in order to update Paulina's and the travel agency's billing information, and also some network statistics, and is then finished.
After a lot of invocations and executions of the service all over the country, and during a period of a couple of years, Gary finds out that the service is too expensive for his travel agency chain. He calls Berke and asks him to deactivate his service, so that customers can no longer use the freephone number. Another of Gary's services is modified in order to give the travel agency chain the same phone number as the rest of Gary's travel agencies, so that people can still reach them. However, he wants to have the chance to activate the service later, if the customers' responses should turn out to be too negative.
Some time passes by. Gary's customers have not been too negative to the change, so Gary makes the decision to deinstall the service. He makes a call to Berke, who takes care of the deinstallation.
Having discussed the stages of the life cycle and presented simple models for describing some of their most important characteristics, we will show how these results can be used to derive an implementation of a system that supports such a life cycle. We will show the flexibility of the results with respect to allocating functionality to physical entities.
The procedure for specifying the implementation goes through two steps. The first step is to transform all models in section 2 into one big model in terms of objects and relations, as described in section 3.1. In the second step we map objects onto physical entities thereby finalising the specification necessary to do the implementation of the system. This is described in section 3.2.
In section 2 we have presented one role model for each stage in the life cycle. Although many of these models are still lacking in detail they remain realistic and suitable for further elaboration and development. In this section our aim is to create one model described in terms of objects and their relations from a set of models described in terms of roles and relations between roles. The principles for doing this synthesis have been explained briefly in section 1.4.
Before proceeding with the synthesis we give a short summary of the modelling results of section 2 as we for each role model list the names of the roles that belong to it:
Note that although many roles have the same name in different role models they are not identical. For example, the subscriber role may have a very different behaviour in the analysis phase compared to the specification phase. However, the detailed modelling of behaviour is outside the scope of this paper. Also note that for the sake of convenience we will use the numbers attached to the roles as references in the text rather than their names.
We now identify the objects of our object model and allocate to them the roles they will play in the system. Effectively, we constrain our models by defining which roles must be played by the same object. The message flows between objects are determined by the allocation of roles to objects. If two roles in a role model, being connected by a message flow, are allocated to two different objects in an object model then there will be a message flow between the objects that corresponds to the message flow in the role model. Similarly, synthesis maintains the cardinality of relations between roles. The total message flow between two objects in an object model defines the interface between them.
Let us define an object called Subscriber and have it play roles number 1 and 5. Similarly, let us define an object called Service Creation Manager and have it play roles number 3, 7, 10 and 13. We can continue like this until we have allocated all 35 roles in the list to some object. Our object model is shown in Figure 12.
The synthesised model constitutes a specification for the implementation of the behaviour captured in the object model. Note that such a specification is independent of programming language and does not yet specify any distribution of objects onto physical entities. This distribution will be described in the following section.
This section is concerned with the allocation of objects of an object model onto a set of physical entities. When we talk about physical entities in this context we mean either human beings or some sort of machine capable of processing software. In the case where objects are allocated to human beings, their expected behaviour is specified by the roles that make out the particular objects and they can only interact with other entities (obeying cardinality information) using the messages that are defined between the objects they represent.
On the basis of the object model we are now in a position to create many scenarios for how to map behaviour to physical entities without being unduly constrained by predisposed (and often unnecessary) ad hoc decisions. It allows us to reuse our modelling results in highly differing alternative physical architectures. Figure 13 presents a scenario that is similar to descriptions of realistic initial IN implementations whereas Figure 14 shows how the same behaviour can be introduced into a physical architecture for experimental use like simulations or demonstrations. Excluding the Switches, these implementations will belong to the service domain described in section 1.1 thereby adhering to the principles for achieving network independence.
In Figure 13 we continue the example from section 3.1. We suggest to allocate the Subscriber, User and Service Creator objects to human beings. Note that the object model allows several Subscribers, Users and Service Creators. We choose to allocate the Service Creation Manager to a computer which will be labelled the Service Creation Environment. This machine can be a desktop office machine in the Service Creator's office just as described for Berke in the scenario in section 2.5. A database machine will be responsible for all aspects of data access which in our models include the Database Handler object and the Database object. The Switching Domain object is a representation of all switching and transmission functionality in the telecommunication network including necessary interface functionality to the Switching Domain Manager object and may be assumed to be implemented by modern switching machines and transmission equipment between them. The service control and execution can be done by a separate machine labelled the service management environment and has allocated the Service Manager, Service and the Switching Domain Manager objects.
In Figure 14 we depict an architecture that could be suitable for an IN laboratory activity. The Service Creation Manager, Database Handler, Database, Service Manager, Service and Switching Domain Manager objects have been allocated to the same machine which could be a Sun workstation. The Switching Domain object can here be either a physical switch with controlling software like an ATM based experimental broadband switch or simply the necessary simulation software on a computer.
We have in this paper developed a life cycle for IN services and given examples of what a service environment could look like. We have achieved the mapping from the life cycle model to a set of physical entities constituting a service environment by using a simple object oriented approach.
The life cycle we have developed is more detailed than the generic life cycle in ordinary software. It has been possible to do this because we have a specific context (the IN) in which the software is produced. In particular, the response time and availability requirements for services indicate a separation between activation, invocation and execution. We have added the deactivation and deinstallation phases because these are non-trivial in an IN.
One of the important observations concerning the intelligent network is that it is a service-driven, that is, a customer-driven network. The flexibility we want to achieve by introducing the IN introduces some general problems that the software community has been aware of for a long time. These include the following problems concerning the communication challenge between the one who initiates the creation of the service and the one who produces it:
This paper is an attempt to refine our ideas about the intelligent network, and it will be suitable as input both to the European Institute for Research and Strategic Studies in Telecommunications (EURESCOM) and to our own work on services and service specification. It will also be fruitful in our efforts to initiate an IN laboratory. There are numerous important aspects related to modelling and implementation of IN not included in our discussion. This is mainly because our primary focus for this paper is the service life cycle. Topics such as service creation, connection control, signalling, protocols, terminal aspects, concurrency, distribution, user interfaces, etc. will demand a much higher level of detailing and are therefore topics for future research.
A draft of this paper was used as input to work on a project in EURESCOM on the evolution of the intelligent network. We would like to thank the subtask leader for the work on the IN service life cycle in this project, Beate Uhlemann from Deutsche Bundespost Telekom, for feedback on this draft.
1 Bugge, B et al. Methods and tools for service creation in an intelligent network, initial document. Kjeller, Norwegian Telecom Research, 1991 (Research Doc. No. 34/91).
2 ETSI. Intelligent network: framework. Valbonne, 1990 (ETSI DTR/NA-6001, version 2).
3 McDermid, J, Rook, P. Software development process models. In: McDermid, J (ed.). Software engineer's reference book, Oxford, Butterworth-Heinemann, 1991.
4 Reenskaug, T et al. OORASS: Seamless support for the creation and maintenance of object oriented systems. Oslo, TASKON, 1991.
5 Wirfs-Brock, R J, Johnson, R E. Surveying current research in object- oriented design. Communications of the ACM, 33(9), 104-124, 1990. ˙