MXPA98004495A - A system platform for a communication system - Google Patents

Abstract

An object-oriented system platform for a telecommunication system providing services to the subscriber includes a top layer containing requests in the form of basic and supplementary functions providing basic or supplementary services. This layer is implemented with base object (202) and extension or extension objects (204, 206, 208). The base objects are object types that implement the functions that may need extension in the future, each type of object being designed for a specific task that can be carried out with a minimum of coordination with the other base objects. Extension objects are object types that implement the extension functions that form extensions or extensions for the base functions that make it possible to add new services and modify and extend the existing services without changing the software of a system that has already been implemented and supplies

Description

"A SYSTEM PLATFORM FOR A COMMUNICATION SYSTEM" TECHNICAL FIELD OF THE INVENTION The present invention is generally related to an object-oriented system platform for a telecommunication system that provides services to the subscriber. This platform can generally be described as including a functioning system in a lower layer, a request platform placed therein and containing appropriate telecommunication abstractions in the form of resource objects and then, a top layer containing desired requests in the form of basic and supplementary functions that provide basic and supplementary services. Subscriber services that are provided through a communication system may include base services and supplementary services that are provided by basic functions and supplementary functions, respectively of the system. The supplementary functions of a system are optional, depending on the market and can be supplied to a client after the system that provides and the basic services have been supplied. The latter is frequently the case for subscriber services such as Call Waiting and Calling on Busy Line.

DESCRIPTION OF THE RELATED TECHNIQUE Supplementary services are often introduced when a system that provides the basic service has already been developed and delivered. The traditional way to update the system is then to edit and compile the existing implementation to have it to also support the new supplementary function and have it to be aware of the coordination between the new and existing expansion functions. In U.S. Patent Nos. 5,057,996 and 5,136,712, an object-oriented operating system is described which includes hardware layers, layers with functions of the operating system and software layers. Access to specific objects is required to use the corresponding resources in the system. The objects have a consistent data structure and a consistent method to define the operations for each type of object. The system supports routines to generate new types of objects without modifying the core of the operating system.

US Patent Number 5,421,015 discloses an object-oriented data processing system comprising an expandable set of object types and a corresponding set of object managers.

COMPENDIUM A general principal object of the invention is to make more efficient, in a communication system, the administration of the supplementary functions of a system, that is, the parts of the system that are optional, depend on the market and are supplied to a client after that the system that provides the basic services has been provided. A more determined object is to achieve this efficiency by allowing the modification and expansion of the services that are provided through a system, without the need to change the software of the functions that have already been implemented and supplied. These and other objects that will appear below have been achieved by the characterization features stated in the patent claims. In a system platform of the class defined through the introduction, the top layer is implemented with base objects and extension objects. Base objects are object types that implement, with one or more methods included in them, base functions that may need to be extended in the future, and extension objects are object types that, with one or more methods included in it, they allow the implementation of expansion functions that are extensions for the base functions. Each type of base object is designed for a specific task that can be carried out at a minimum of coordination with other base objects. The extension objects are designed to support the addition of new services and the modification and extension of existing services without changing the software of the services that have already been implemented and supplied. Extension objects can also include object types that implement the extension functions that form extensions for the extension functions and also object types that implement the interaction management extension functions, that handle the interaction between the supplemental services. Extension objects allow the introduction of extensions in a running system that are dynamically linked to the base objects will be modified.

The extensions are configurable, that is, they allow to add and remove system modifications in the operating time in a generic way without the designer himself needing to design a code for the appropriate activation / deactivation of the extension, which is managed through the platform. The behavior of the included object types is defined by describing the behavior of each method in it as a defined state machine. This state machine consists of a finite number of states and transitions between these states where the code that defines the method is carried out. The extensions are added in the states, where they are then in charge of the control of the execution and return it after having finished their own expansion towards another or the same extension point. The base and extension types support an expansion concept that allows the modification and expansion of the system without it being necessary to change the existing implementation of the system. More particularly, this is achieved by loading only the definitions of the extensions in the system, which indirectly modify the behavior of the system, taking charge of the execution control in specific predetermined extension points.

A specification for an extension object defines in which of the extension points in the extension object the extension is assumed to take control and in which of the extension points control can be returned. When the extension object takes over, a predefined extension method begins execution. An operating time system handles the creation of the extension objects and the invocation of their extension methods at the manifest extension points. An extension object has access to the attributes and methods of the base object or the extension object from which the extension takes over control. Attributes and methods can only understand what is declared in a type specification of the object to which it can be accessed. In the object type specification, access sections are also defined for each extension point by defining that only a specific subset of the attributes and methods in the specification are available for extensions taking control at a certain extension point. The object type specification for an extensible object works similar to an interface that delimits the amount of information that is visible and available to extensions of the extensible object. An interface layer that is used in conjunction with the concept of extension is defined by extension views that define a subset of information in the specification in an extendable object that will be able to be accessed there by extensions using the view. For a base object there is a specification that, on the one hand, works as an interface description that shows states, attributes and methods available to the extensions and, on the other hand, defines an interface to the client object that needs to create cases of the base object. The interface is defined by methods of the base object type that decide which parameters can be used when the new case is created. The specification provides a high-level description of the behavior of the base object type while leaving out the implementation details that are unnecessary to achieve an understanding of the function of the object type. An abstraction layer that is created by the underlying object that is used by the base object, and local methods in the base object that comprise the use of the object's logic, contribute to the high level of abstraction. A reasonable level of abstraction in a specification is obtained by showing the waiting state of the base object in the specification and possibly certain selected non-waiting states that are fundamental to the understanding of the function of the base object. The code for execution between the states shown is entered into local methods declared but not necessarily specified in operation in the specification. A judgment of what can be shown in the specification includes considering new pieces of the type of object that may be exposed to extensions in the future. All the states, both the waiting states and the non-waiting states and the explicitly named extension points are shown in the method specification. An action code is used in state transitions in local methods. If certain parts of the behavior do not need to be able to be extended, they are introduced entirely in local methods that are defined in the specification or implementation or a level of implementation. Object type realization is used for pieces of base objects that do not need or can not be extended and that are not required to be displayed in the specification to create a high level description, but where a definition is preferred instead of use the implementation language directly. In the embodiment, definitions of local methods that introduce the action code are introduced. In the embodiment it is provided while countering definitions of behavior included in the specification, a more detailed behavior definition involving a refinement of the specification of the behavior that is provided in the specification. The concept of extension according to the invention has a number of valuable properties. It is a fine-grained way to make modifications, and it is not necessary to exceed the complete methods, which is the mechanism that is available in most of the formalisms oriented towards the object. Instead, overreaching can be carried out at certain points of extension within the methods. The concept of enlargement forms a framework to take care of the complexity caused by introducing many supplementary functions in a system already developed and supplied. This is made possible by describing the modifications caused by each extension separately, after which the extensions in turn can be coordinated when there is need. These coordinations between the supplementary functions can also be expressed as separate extensions, in this case as extensions to the supplementary functions. This makes it possible to handle the optional parts of the system and its dependencies in a modular manner.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will now be described more closely below with reference to the accompanying drawings, in which Figure 1 schematically illustrates a system platform for a telecommunication system that can provide services to the subscriber. Figure 2 is an illustration intended to illustrate the connection between the concepts used in the extension concept according to the invention. Figure 3 illustrates the concept of magnification in a total view. Figures 4 to 6 show examples of a specification, an embodiment and an enlargement view, respectively, of a base object, Figures 7 to 9 show the examples of a specification, an embodiment and an enlargement view, respectively, of the object of enlargement, Figure 10 is a view intended to provide a summary view of the relationships between the concepts of the base object, the extension object and the enlargement view as well as a specification of the type of object, the embodiment of type of object and an implementation of object type. Figures 11 to 14 are views showing examples illustrating the use of the extension mechanism, wherein Figure 11 shows a case of non-conditioned extension, Figure 12 shows a case of conditioned extension, Figure 13 shows a case involving an event extension, and Figure 14 shows a case with several extensions at the same extension point.

DETAILED DESCRIPTION OF THE MODALITIES Referring to Figure 1, a system platform for a telecommunication system contains a number of functions or layers. These layers can generally be described as containing an operating system in a lower layer 102, a request platform 104 placed therein and containing appropriate telecommunication abstractions in the form of resource objects, and in the same a layer 106. which contains desired requests in the form of basic and supplementary functions that provide basic and supplementary services. Therefore, the concept of "category" will be used to define the different types of objects included in layer 106. More particularly, a "category" characterizes an object syntactically, but also characterizes its location and function in the architecture of the system. The object types, described more closely below two categories called BASE and EXTENSION, respectively, are included in an implementation of layer 106. The case of these objects will be referred to as the base object and extension object, respectively, below. In addition, below, there is a concept of "events" that is used to refer to the sending out of asynchronous messages. Objects can request supervision of an "event" and then wait for it. The events are declared in a section of "EVENTS" in the description of an object type. In layer 106 the behavior is driven by the events, that is, the objects react to the receipt of the asynchronous messages.

Events are often generated as the result of a message that arrives in an interprocess communication link to a process, where the object executes it. By means of a process, we want here to imply a program that is being executed. Then also the execution name will be used for an execution path in a process. Each thread has its own stack and program counter, but all threads in the same process share the same process data (heap). Each type of base object is designed to carry out a specific task such as managing the establishment of a call in a telephony system. When this task is being carried out, a case of the base object type is created. This object will then have control through the way in which the task is carried out. The details in the lower levels, such as the way in which resources are manipulated to carry out the task, are handled by the base object that sends method calls to objects of other categories, e.g., of the category " EVENTGENERATOR ". The object types in this category represent resources or basic services that are called and that inform their user generating events.

The base object types are designed to allow their respective tasks to be carried out with a minimum of coordination with each other task that is carried out in the system, that is, with a minimum of coordination among the base objects. This is reflected in the properties of the base and extension categories: each base object is carried out in a semi-parallel execution thread, neither a base object nor an extension object can have any of the methods that are going to be called from the outside and that can not generate any events. These properties will be described more closely below. Another important aspect of the base and of the expansion in its categories is that they support an expansion concept allowing the behavior of a system to be modified and extended without it being necessary to change the existing implementation of the system. Instead of the modification and expansion of the behavior is achieved by loading only the extensions in the system. By means of the concept of extension these will then indirectly modify the behavior of the system, taking charge of the control of execution in certain specific extension points. The base category will be used for object types that implement the base functionality that may need to be extended in the future to so-called base functions. The extension category is used for object types that implement the extensions of these base functions called the extension functions. The behavior of an object type is defined by describing the behavior of each method with a finite state machine using a specific design language for modeling the object. Therefore, it is referred to as "design language". This finite state machine consists of a finite number of states and transitions between these states, where the code is carried out as transitional actions. The most natural points to add extensions, the extension points, therefore are the states. An extension can be designed to take over the execution control at an extension point and return the control to another or the same extension point in the same method. From this point of view the extensions can be considered as additions of new states and state transitions for a state machine. These states and state transitions then modify the existing state transitions of this state machine. All the states in a method can always be used as extension points, it being also possible to explicitly specify an extension point without introducing a new state, a so-called extension point called explicitly. The extension points are classified with respect to whether they allow extensions from the point, termination of extensions in a point or if they can be used for both purposes. For these points the following denominations will be used from now on. Pickup points, SUPERIOR, which are points of extension where the execution control can be transmitted to a method of extending the extension object. Continuation points, COP, which are extension points where the execution control can be retransferred from an extension method. - Take and Continuation Points, TOP COP, which are extension points that can be used both as the point of take and the continuation point. From the beginning (failure) all the states in an object are points of taking and continuation. This however can be changed in the specification of the object type if there is a need to make constraints that all extensions have to resist. The same kind of enlargements can also be done in enlargement views, a concept that will be described more closely below.

The concept of extension also admits definitions of extensions to extensions. In fact, extensions can be defined in an arbitrary number of levels by means of creating chains or layers of extensions. Therefore, it is necessary to define a vocabulary to allow differentiating between v.gr., the "superior" extension in an extension chain and the entire chain of extensions. The concept "base object" is used to indicate the object comprises the original non-extended base function. If there is a risk for a misunderstanding the denomination of "original base object" is used. The extensions are referred to as "extension objects". The concept of immediate base is related to a base object or an object of expansion from where an extension begins, is, an extension takes over its immediate base. The most generic naming base will be used to mean the entire chain of enlargements, which comprises the original base object to which, a certain extension object forms an extension. If there is a risk of incomprehension the denomination "the whole base" is used.

The aforementioned is illustrated in Figure 2 where an object 202, "Base Object", is the original base object. To the base object 202 the extension objects 204 and 206, the "Enlargement Object ^" and the "Enlargement Object", may be joined. The extension object 206 is the immediate basis of an additional extension object 208, "Expansion Object 21". The base object 202 and the extension object 206 form the basis of the extension object 208. A specification for an extension object defines the extension points in the extension object where the extension is assumed to take over the control and where the extension objects can return control. When an extension object contains the control, it is a predefined extension method, EXTENSION METHOD, which starts the execution. The operating time system is responsible for creating extension objects and invoking their extension methods at certain extension points. As it appeared from the above, also the objects of expansion can in turn have extensions. The extension methods are therefore always implicitly called from a base method or from another extension method.

An extension object has access to the attributes and methods of the extended object, that is, the base object or the extension object, from which the extension takes over. However, there are certain ways to restrict this access. First, it is only the attributes and methods that are declared in an object type specification, which can be given access. Attributes and methods declared only in one embodiment are not available for extensions. In the specification it is also possible to define access restrictions for each extension point by defining that only a certain subset of attributes and the methods in the specification are available for the extensions to gain control at a certain extension point. The object type specification for an extensible object therefore works as an interface that limits the amount of information that is visible and available for extensions of this base object. However, there is an extra interface layer that is used in conjunction with the extension concept and this is the interface that is defined by the extension views. An expansion view defines a subset of information in the specification of an extensible object and will be able to be accessed in it by extensions using the view. Figure 3 illustrates the principle of enlargement. In Figure 3 a block 302 represents the specification of a base object and a block 304 specifies an extension object. Specification 302 contains a body method, "BODY", represented by a block 306 wherein a finite state machine 308 has four states indicated. These states include two points sl and s2 of extension. In an enlargement view indicated by a block 310, the extension points sl and s2 are declared as the take point and the continuation point, respectively, which are indicated by "TOP PART sl;" and "COP s2;". A block 312 represents an additional method "Method ml" in the specification of the base object by means of an infinite state machine indicated with five states. The specification 304 of the extension object contains an extension method "EXTENSION METHOD extl", which is a block 314 and is illustrated as containing a finite state machine with three states comprising an initiation state t and a final state s2. In a block 316, an additional method of extension "METHOD ext2" is indicated as containing four states.

The points sl and s2 of enlargements are visible from the extension object through the extension view 310. When the method 308 of the base object reaches the state sl, the execution control is connected with the extension method ext., which is indicated by arrow 318. The extl extension method starts executing from its home state t. When the execution finally reaches the state s2 in the enlargement, the control is reconnected according to the arrow 320 with the base, which continues its execution from the state s2. This is carried out by the system of time of operation, that is to say, the designer of the extension does not need to handle this explicitly in his code, except in a declaration in the extension. As mentioned above, the category BASE is the category of object type that is used to model the base functions, functions that can be extended later. The base object has certain specific properties. An important property is that the execution of a base object is always carried out in a semiparallel control thread. This is natural since the object of the base object will carry out a task that can be performed independently of the other tasks that can continue or advance in parallel in the system. During execution the object can enter a wait state which is a state in which the execution is stopped until after and the control is transferred to another thread. Execution resumes when an event that has waited in the waiting state is received. From a user's point of view, this property can be achieved by creating a case of a new base object in the current thread of execution and programming the body method "BODY" of this base object for later execution in a new thread. A wire switch is carried out when the first wire of the current enters a waiting state. In this step, the newly created ice gets a chance to start the execution. However, there may be other threads in the process that are also ready to start execution so that there is no guarantee that a new thread will start execution at exactly this time. The only guarantee is that the execution will begin either earlier or later. In relation to the creation of the new thread a reference to the case of the newly created object is returned. This reference can later be used to synchronize with the termination of the created thread, waiting for the event that always appears when a thread ends. The reference can also be used as an argument or stored as an attribute but will not be used for any other object. Another important property of the base objects is that their attributes and methods are hidden from other objects except their extension objects. For a base object there will be both a specification and a description of the embodiment that contains both compartment descriptions using the design language. The object of the specification is mainly to act as a description of the interface of the base object. There are different classes of clients for a base object from where this specification is related. First, there are extension objects that extend the behavior of the base object. For these the specification acts as an interface description that shows states, attributes and methods that can be obtained towards extensions. In addition, access restrictions can also be entered for extensions using the zoom view they use but there can never be access to more than what is shown in the base object specification. Second, the specification defines the interface to client objects that need to create cases of the base object. This interface is defined by methods of the base object type. They decide which parameters that can be used in the creation of a new case when a new thread of execution will be created according to what is described above. Another object of the specification is to provide a high level description of behavior of the base object type while that the details of implementation that are unnecessary to achieve the understanding of the function of the type of object are omitted. The high level of abstraction is partially provided by an abstraction layer created by the logic of the underlying object that is used by the base object but also through the local methods in the base object and comprises the use of an object logic . A sufficient level of abstraction in a specification can be to show the waiting state of the base object in the specification and possibly certain selected non-waiting states that are fundamental to the understanding of the functions of the base object. The code to execute between the states shown can then be introduced into the local methods that are declared and that are necessarily specified by their behavior in the specification. When it will be decided what will be shown in the specification and what will not, care has to be taken as to which parts of the type of object may be exposed to extensions in the future. The specification tactics most capable of extending is to show all the states, both waiting states and non-waiting states, and all the extension points explicitly named in the BODY method specification and encapsulate only an action code that is used for transitions of state in local methods. If on the other hand it is decided that certain parts of the compartment do not need to be able to be extended, these parts can be fully introduced into the local methods. These local methods can then be defined either in the specification or the implementation or even at the implementation level. If they are called from the specification however, they can be declared in the specification. The object of the object type realizations is that they will be used for the parts of the base objects that do not need or may not be able to extend and that are not necessary to be shown in the specification to create a high level description but in where the definition with a design language is preferred instead of directly using an implementation language. The definitions of the local methods that encapsulate the action code can be placed here. In one embodiment it is also possible to leave out the behavioral definitions included in the specification and provide a more detailed definition. This definition of newly defined behavior must be a refinement of the specification of the behavior that is provided in the specification. It must be emphasized that none of the methods, attributes or states that are defined or declared in an embodiment will be available for extensions of this type of object. It is only the information in the specification of the object type that is visible for the extensions. It is also possible to specify the entire base object using only one specification in the design language and no realization in this language. In this case, the implementation language can be used to define certain action methods called in the specification where this is appropriate. The supervision, "MONITOR" and monitoring of detention, "MONITOR DETENTION", of events, however, must be carried out in the design language either in the specification or in the realization. If the "creation / removal" of objects is carried out in the design language, the corresponding "remove / new" message for the same object must also be carried out in the design language either in the specification or in the execution . If, on the contrary, the creation / removal is carried out in the implementation language, then the corresponding removal / new must be carried out in the implementation language. For the body method BODY of the object it is mandatory to provide a definition of behavior in the design language in the specification even if this definition can be allowed to be quite simple and can be exceeded in the realization. For other methods in the base object as mentioned, the use of the design language is optional. Figures 4 and 5 provide examples of the specification and embodiment, respectively, of a "Base" object of the base object type. In the specification shown in Figure 4 the behavior of the body method "BODY or method" has been defined from line 12. The method "method2" and "method2" and "CONSTRUCTOR" however have only been declared, from the line 7. CONSTRUCTOR is a method that is executed when a case of a type of object is created. In the embodiment shown in Figure 5, the behavior of the methods "CONSTRUCTOR", "methodl" and "method2" is defined from line 2. The body method is stated to be in the specification, line 22. As mentioned above the specification of the base object type serves as a description of the interface for its clients. The enlargement views are also a kind of interface description. They are used to further restrict access to an extensible object for its extensions. The purpose of having an extra interface layer is to achieve some additional supervision through which extensions can be made to a certain object. Different expansion views can be created for different purposes. Yes v.gr., a certain view is designed for use of debit functions and statistics functions may be sufficient to show only a small subset of the states and attributes of the extended object. Another use is to define different views for different parts of a function so that the use of an extension of a certain view implies that only a certain function of the enlarged object is modified. This and similar information can be valuable when investigating which coordinations between the expansion functions that may be necessary to implement when a new extension function is introduced into the system. A base object can therefore have several different extension views. Each extension object, however, is designed for a specific magnification view. Expansion views are used only during the design phase, for different analysis purposes, and do not exist as separate units in an operating time environment. Figure 6 shows an example of an extension view of the object base of the Base object type in Figure 4. An enlargement view is used to create restricted views of extensible object specifications. Extension views can not define any information that is not already available in the base object. They can only add additional restrictions and hide information that is already visible in the base object. In the limitations already specified in the base object can not be counteracted. In an enlargement view, a list of methods and attributes in the base object that can be obtained through extensions of lines 3-6 in Figure 6 is first provided. This list defines a subset of attributes and methods that exist in the base object. Then, the extension points that will be available to the extensions are listed. For each extension point in the view, the following information is specified. The name of the extension point of lines 7, 11, 15 and 18, respectively in Figure 6: STATE OF TOP WAITING, STATE OF TOP COP, STATE UPPER and STATE OF COP, respectively. For extension points that are states, the keywords STATE and STATE OF WAIT, respectively, are provided in the name. For explicitly named extension points this information is not provided. In addition, the denomination contains the type of extension point, that is, the TOP point of intake, the point of continuation COP or the point of intake and continuation TOP COP is manifested. As mentioned above, all the extension points in the base object are of the point of take and continuation type. Here, an extension point can be restricted to allow use only as a point of take or only as a continuation point. If the basic setting is used, the keyword TOP COP should however be provided. - For the take point there is a list of attributes and methods in the base object that will be available for the extension methods that start from the specified point of take, see lines 9, 12-13 and 16 in Figure 6. This list is a subset of attributes and methods listed at the beginning of the enlargement view. A list of allowed COP continuation points is provided for each intake point, see line 8 in Figure 6. This information is used to decide which of the extension points, an extension takes the control at the point of intake current is allowed to continue. The type of expression that is used for branching in the states of the base object is indicated for each tap point. This is related only to the states of no wait. It is not possible to reference the local method variables in the base object an extension view. Since the concept of extension also allows extensions to extensions, enlargement views can be created for base objects as well as for extension objects. For extension objects the same restrictions are valid as for base objects. Its members can not access through any other objects than its extensions. Also for extension objects both a specification and an embodiment can be provided. For the extension method of an extension object it is mandatory to provide a definition of the behavior with the design language in the specification even though this definition is allowed to be quite simple and can not be countered in the realization. For the other methods in extension objects the use of design language is optional. In Figures 7, 8 and 9 are provided examples of a specification of an object of the type of extension, "theExtObj", an embodiment of the same object and an enlargement view of the object in question, respectively. The extensions are encapsulated in objects of the EXTENSION category. The specification of an extension object, for example, Figure 7, defines the view used by the extension object, see line 3, in which the take points of its extension methods take control see line 8, and the priority class for the extension method, see line 7. In different extension objects you can use the same view of a base object. Multiple expansions can still start from the same extension point in the same object. The methods in an extension object always run on the same thread as the base object. All event monitoring carried out in the base object is also valid in the extension method. In other words, the extension method can receive events that have been monitored in the base object, as long as the identity of the event generator has been made available to the extension method through a view. In the states in the specifications for the EXTENSION METHODS can be used as intake points and continuation points, in the same way as states in the specification of the BODY methods of the base objects. The realizations of the extension methods, see Figure 8, can in the same way add several states, see lines 2 and 8, but again they are not available to other extensions. The additional extensions to the extension object theExtObj can be made as indicated in the enlargement view presented in Figure 9 only in the form of a table. Figure 10 provides a summary total view of the relationships between the base object of the concepts, the object of the extension and the expansion view as well as a specification of the object type, implementation and implementation. In Figure 10, a stack block 1002 indicates a specification 1004 and implementation 1006 in a design language, and implementation 1008 in a target language. In the same way, a block 1010 indicates the specification 1012 and the embodiment 1014 in a design language, and the implementation 1016 in a target language.

The 1004 specification of the base object is a specification at an appropriately high level of abstraction that can be used to have a full understanding of the function of the object type. The specification contains attribute and method signature statements as well as behavioral specifications of (a subset of) methods. All the states shown in the behavior specification of the BODY method can be used through the extensions. The embodiment 1006 of the base object has a more detailed description of the object type compartment. You can counteract the behavior definitions of the methods in the specification of the object type. The realization can also define the behavior of declared methods but not the behavior specified in the specification. New attributes and local methods can be added in the realization. The information added in the realization is not available for the extensions. A specification may have more than one embodiment. The implementation 1008 of the base object type in the target language is a full implementation of the object type. It consists of a source code generated and optionally, manually written for the white language (C ++). The generated parts ensure that the implementation is prepared for extensions according to the type specification of the object. The implementation code is generated using the specification of the object type and optionally one or more of the embodiments of the object type in the design language. In the extension views 1018 and 1020 of the specification 1004 of the base object type, they are indicated. There are several views of the same specification of the object type, but each view is always designed for exactly one object type specification. New views can be created without affecting the specification of the base object, the realization or the implementation. The 1004 specification of the base object type and its views 1018 and 1020 are used when designing object types and extension. The specification 1012 of the object type of the extension specifies the extension object at the same high abstraction level as the specification of the base object type. Also, embodiment 1014 and implementation 1016 of the extension object type appear in the same manner as for the base object type. Each specification for the type of extension object is always designed using exactly an extension view 1022. By analogy with the case for base object types, one or more extension views can be defined for a type of extension object. With respect to code generation, the following may be mentioned. The code is the target language (C ++) that can be generated for specifications of object type and realizations. All methods, including the CONSTRUCTOR, BODY and extension methods in the specification, must be repeated in the realization. Each embodiment of the type of the base object and each embodiment of the type of extension object must follow the following rules; Each signature of the method (the methodname dom_FormalArguments [RETURNS dom_TÍpo]) that is indicated in the specification must always also exist in the realization. This requirement can be completed in one of the ways that will be described below. With the signature here we want to understand a concept that identifies the element in question, here a method, stating its name, type of argument and type of return value. If only the signature of a method is manifested in the specification, the BODY method can (the dom_BehaviourBody, that is, the BEGIN ... END part) can either be omitted or manifested in the embodiment.

If the BODY method is omitted in the embodiment, only a framework of the method is performed in the reference or blank language. If only the BODY method is shown in the realization, a complete code is generated in the target language. If there is a BODY method already in the specification, the keywords AS THE SPECIFICATION can be used in the embodiment to indicate that the BODY method in the embodiment is exactly the same as in the specification. The full white language code will also be generated in this case. The code will not be available for manual changes or additions. If both the specification and the embodiment define a BODY method for the same method, a complete code of the BODY method manifested in the embodiment is generated. This implies that the behavior defined in the realization always counteracts the behavior manifested in the specification. The attributes stated in the specification will not be repeated in the realization. Due to the fact that the definition of the method manifested in the implementation completely counteracts the corresponding definition in the specification, likewise the local variables - 3, manifested in the specification must be repeated in the realization. Next, some examples, which illustrate the use of the extension mechanism, are described with reference to Figures 11 to 14. An example of a non-conditioned extension is shown in Figure 11. The example begins with the assumption that the specifications of a base object and an extension object, respectively, are manifested as shown in the Figure. In a magnification view not shown, a state that analyzes indicated in 1102, as SUPERIOR, and a calling state indicated in 1104 and 1106, as COP is also shown. Generally all extension objects are checked when the execution reaches a state declared as SUPERIOR. If there is an extension method that starts from a current TOP state, the extension method is called. The operating time system will see that a corresponding extension object has been created some time before the first invocation of the extension method of the extension object. If it is not the first time during the execution of the base, the extension method is called the oldest case of the extension object and can be used again. This object will therefore return to its state between invocations of its extension method during the execution of the same base. In cases of extension object types are created for each base object, that is, an extension object is never shared by two bases. In the example provided in Figure 11 the transition is always carried out, indicated by an arrow 1108 to the extension method in a non-conditioned manner each time the execution of the base reaches the analysis state 1102. There are different ways to give after the execution of an extension method. First, the OUTPUT can be used to terminate the execution of the entire thread. Second, there is a specific possibility called REVERSE (TOWARD THE BASE) that is used to indicate the return from control from an extension to the base where it took control. Third, an ordinary end state can be used, but used in an extension method has a specific semantics. In this case, a COP state must prevail in the base that has the same name as the final state of the extension method. When the execution reaches this final state, the execution in the extension method will be interrupted and the execution will continue in the COP state in the base. The difference between OUTPUT to the state at the base from where the extension was started, and from REVÉS resides in what happens if more than one extension takes control in the same TOP part. When using REVÉS, the next expansion will in turn be executed. Extensions in the highest priority class always run first, and if there is more than one extension in the same priority class, they are normally executed in an arbitrary order. However, if there is an interference extension entity that has a certain execution order among the extensions, they are executed in this order. If the OUTPUT is carried out to the UPPER state in the base from where the execution began, the UPPER state of the base will be executed again with all connected extensions also executed again. An example of a conditioned extension is shown in Figure 12. Expanded upgrades are those that run only if certain conditions are met. This case is specified by means of a CASE expression that is associated with the original state of the extension method. The example starts from the assumption that the specifications of a base object and an extension object, respectively, are indicated as shown in the Figure. In a magnification view not shown, a state that analyzes also manifests as SUPERIOR, a and b are attributes in the base object.

When the base object reaches the state of analysis in 1202, it will be seen that there is an extension that starts from this TOP point. The extension method will then begin its execution by a CASE expression associated with the initial state of the extension method indicated at 1204. The value of this expression is used to branch the flow. In this case, it is the question of a simple RESULT reference to the value of the CASE expression in the base that is indicated in 1206. The expression (a + b) is caculated. If its value is 3 the branch indicated by the value of 3 is selected indicating 1208, and the execution is continued in the extension. Otherwise, the FAULT branch indicated in 1210 is selected, and the execution control is returned to the base. The base should then re-evaluate the CASE expression and then continue with the appropriate branch. In the example provided above, the CASE expression associated with the original state of the extension method was very simple. But it could be an arbitrary expression of a scalar type. RESULT is a keyword used to allow an extension to refer to the result of a CASE expression in a non-wait state in the database. The result can be used in each expression but its value can not be changed during the execution of the entire extension method. If there is no proper branch or a branch of FAIL, there is an error. If the extension method has a branch with the same value as the base, the extension method counteracts the base. If the extension starts from a standby state in the base, the original state of the extension method must also be in a wait state that specifies the additional events for which it was expected. In a wait state all the expected states for the extension methods are collected at this point in a WAIT FOR THE SIMPLE EVENT. Figure 13 provides an example of an event extension and begins with the assumption that the specifications of a base object and an extension object are in the Figure. In addition, a Ring_B that is a state is specified as SUPERIOR in an enlargement view not shown. When the base object reaches the state Ring_B, indicated at 1302, it is found that there is an extension starting from this TOP point. The operating time system must then collect the 'information of the extension object with respect to which the events that are monitored place this information together with the information of the waiting status in the base object. In this way a composite waiting state is created and entered. Depending on the events that appear then, either the extension or the base will be executed. If Block_Ev, which is indicated at 1304, is specified in the extension, the extension method is executed. The base is executed if 1306, which is specified in the base and indicated in 1306, and received. Two extensions can wait for the same event, also the same events as the base. The extension with the highest priority will then be executed. Expansions and waiting states can not execute AGAIN (TOWARD THE BASE), they must continue to a COP state in the base or OUTPUT. If the execution of an extension method leads back to the original state of the extension method (eg, Start in the previous example), the extension method is carried out again, but this time only the events specified in The method of extension are expected. If the entire waiting state is entered again, the waiting status has to be defined as the TOP COP point in the base and "continue up to" the TOP COP status that must be manifested in the extension method. It is also possible that there are more extensions up to one and the same TOP point in the base object. In this case, all extension objects must be organized in a specific order of priority and the execution is carried out in accordance with this order of priority, that is, the extension objects with the highest priority are executed first. If this extension returns its execution control to the base, the extension object with the next highest priority is executed. If all extensions return the execution control, the base will also be executed. If a method of extension continues to a continuation point in the base, no further expansion methods will be handled. The execution continues quite simply in the base. The state "will continue until" can of course have extensions. If this is the case everything starts again. Figure 14 provides an example with three enlargement methods m2, m3 and m4 indicated at 1402, 1404 and 1406, respectively, and a base, indicated at 1408, with an extension point R indicated at 1410 which is declared as the COP SUPERIOR, which is indicated in 1412. The first expansion carries out a COP TOP of "continue up" in the base indicated by arrow 1414. The two other expansion flows take the case from state 1410 of TOP COP indicated in 1416 and 1418 respectively. The m3 extension method returns the execution control to the base using NEW.

If m3 has a higher priority than m4, m3 is executed first, followed by m4, under the condition that m3 returns the execution control, indicated at 1420. If m4 has a higher priority than m.3, only m4 is execute In this case, m3 never has the possibility of executing due to the fact that m4 never returns to the base. There are also object types that implement the interaction management extension functions that handle the interaction between the supplementary functions. The use of supplementary interaction functions is described, v.gr, in the above Swedish patent applications Nos. 93 02024-6 and 94 00209-4. The measures described in the last application with reference to Figures 15a / 15b included therein as being carried out by a base function, could therefore be carried out by means of an interaction management extension object. In this regard, the concept described above with reference to Figure 14 regarding the connection of further enlargements with one and the same TOP point is a base object that e.g. may be used. An interaction handling extension object in this manner could be connected to the same TOP point in a base object as two extension objects that represent each of the interaction extension functions. For further information, with respect to solving the interaction problem, reference may be made to the Swedish patent applications already mentioned.

Claims (22)

CLAIMS:

1. In a telecommunication system providing services to the subscriber and having an object-oriented system platform containing a number of function layers, a layer (102) with functions of an operating system, an application platform (104) placed therein and contains telecommunication abstractions in the form of resource objects, and then an upper layer (106) containing the desired requests in the form of basic and supplementary functions that provide basic and supplementary services, a method for modifying and extending the services of the subscriber comprising the steps of providing in the upper layer base objects which are object types that implement the basic functions that are needed to be extended in the future, and which is designed for a specific task that can be carried out with a minimum of coordination with other base objects, and extension objects being object types that implement the extension functions that provide extensions in the base functions and that allow the addition of new services and modification and expansion of existing services without changing the software of a system that has already been implemented and delivered, while e design expansion objects to allow the introduction of extensions in a functioning system that are dynamically linked to a base object that is to be modified, and the addition and removal, in the operating time of the system modifications in a way generic without programming a specific support to activate / deactivate each extension, define the behavior of base types and extension object including describing the behavior of each method included as a finite state machine consisting of a finite number of states and transitions between these states, execute in the transitions of the code as transition actions, and add the extensions in the states to acquire the execution control in an extension point and return the control to another, or the same extension point in the same method.

A method according to claim 1, comprising the step of implementing also the extension objects that are object types that implement extension functions (208), which form extensions for the extension functions.

3. A method according to claim 1 or 2, comprising the step of implementing also the extension objects that are object types that implement the interaction management extension functions that handle the interaction between the supplementary services.

4. A method according to any of claims 1 to 3, comprising the step of loading only definitions of the extensions in the system, which indirectly modify the behavior of the system taking the execution control at specific predetermined extension points.

A method according to any one of claims 1 to 4, comprising the steps of defining, in a specification for an extension object, at whose extension points in the extension object, the extension is assumed to take control and at whose enlargement points control can return.

6. A method according to claim 5, comprising the step of starting the execution by means of a predefined extension method when the extension object takes control of it.

7. A method according to claim 5 or 6, comprising the step of managing by means of a creation of the operating time system of extension objects and invocation of its extension methods at the manifested extension points.

A method according to any one of claims 1 to 7, comprising the step of providing access of an extension object to attributes and methods of the base object or the extension object from which the extension takes control.

9. A method according to claim 8, which comprises the step of having all attributes and methods declared in an accessible object type specification.

10. A method according to any of claims 5 to 9, comprising the step of also defining in the object type specification, the access restrictions for each extension point by defining that only a specific subset of the attributes and Methods in the specification are available for extensions that take control at a certain point of extension.

11. A method according to any of claims 4 to 10, comprising the step of providing the object type specification for an extendable object such as one that works similar to an interface that delimits the amount of information visible and available to the user. Extensions of the extensible object.

12. A method according to claim 11, comprising the step of implementing an interface layer defined by extension views that each define a subset of information in the specification of an extendable object that is capable of being accessed by extensions using the view 13.

A method according to any of claims 1 to 12, comprising the step of providing a base object with a specification that works as an interface description showing states, attributes and methods available to the extensions and defining a interface to a client object that needs to create cases the base object, the interface is defined by methods of the same type of base object that decide the parameters that will be used when new cases are created.

A method according to claim 13, comprising the step of implementing the specification to provide a high level description of behavior of the base object type while leaving unnecessary implementation details out to achieve an understanding of the operation of the type of object.

15. A method according to claim 14, comprising the step of creating an abstraction layer by means of a logic of the object used by the base object and local methods in the base object comprising the use of the logic of the object.

16. A method according to claim 15, comprising the steps of displaying in a specification the waiting state of the base object and selected non-waiting states, if any, which are fundamental for understanding the operation of the object of base, and enter the code for the execution between the states in the local methods declared in the specification.

17. A method according to claim 16, comprising the step of deciding the content of the specification while taking into account the type parts of the object that are apt to be exposed to extensions in the future.

18. A method according to claim 17, comprising the step of showing in the method specification all states, waiting states as well as non-waiting states, and all extension points explicitly named and using an action code in state transitions in local methods.

19. A method according to claim 18, comprising the steps of recognizing the parts of the behavior that do not need to be extensible and introducing these parts in their entirety into local methods defined in the specification or embodiment, or at an implementation level.

20. A method according to claim 19, comprising the step of using the object type embodiment for parts of base objects that do not need or can not be extensible and that are not required to be shown in the specification to create a high level description, but where a definition is preferred instead of using the implementation language directly.

21. A method according to claim 20, comprising the step of including in the implementation definitions of the local methods that introduce the action code.

22. A method according to claim 20 or 21, and comprising the step of including in the embodiment, while counteracting the behavioral definitions included in the specification, a detailed behavior definition involving a refinement of the behavior specified in the specification.