 |
Description  |
|
|
BACKGROUND OF THE INVENTION
A portion of the disclosure of this patent document contains material which
is subject to copyright protection. The copyright owner has no objection
to the facsimile reproduction by any one of the patent documents or the
patent disclosure, as it appears in the patent and trademark office,
patent file or records, but otherwise reserves all copyrights whatsoever.
1. Field of the Invention
The invention relates to telecommunications switching systems and, more
particularly, the development and structure of process control software
for telecommunications switching systems.
2. Description of Related Art
The development of software architectural structures and application
programs for stored program controlled telecommunications switching
systems has historically been a complex and time-consuming task. The
process requires many steps ranging from the development of functional
specifications defining the operation and interaction of the services to
be provided to the testing of the actual real-time code in the hardware
within which the system is to run. Development of such software
architectures has also required the interaction of a number of different
developers each working in different aspects of the development and
requiring the coordination of multiple activities at each step along the
way in the development process. Thus, bringing to market new software
systems for implementing user demand driven functions and features has
been very expensive and such an arduous and time-consuming process that by
the time systems are designed, developed, tested and commercially
implemented in the marketplace, the user demand has often changed to still
newer requirements.
One of the principal considerations in the development of any software
system is a selection of the method of programming to be employed in
constructing the system. Well known prior art methods of programming
include: process -oriented programming with languages such as "ADA" or
"PASCAL"; object-oriented programming with languages such as "C++" or
"SMALLTALK"; and declarative programming with languages such as "PROLOG"
or "LISP". None of these languages contains the full set of features
desirable for developing telecommunications switch software. For example,
the process-oriented programming language concept provides a good
understanding and a good definition of the subject to be programmed, but,
it gives very limited support for structuring and defining actions or
predicates within the process. When programming the actions within a
process, the designer is required to supply a great number of individual
details within the application software. Similarly, while the PASCAL/ADA
generation of programming languages gives some support to defining and
handling of data, the programmer is still required to do a great deal of
work on a detail level which has very little to do with the actual
application being produced.
Even the latest object-oriented programming methods have their limitations.
Such object-oriented methods of programming have concentrated on various
techniques to define and inherit objects and on how to document objects.
Although these techniques make a significant contribution in the case of
developing programs that contain a large number of objects to be defined
and handled, many problems related to clarity and structure occur when a
program is itself defined as an object.
In process control programs such as those for telecommunications systems,
however, the program entity is always the subject which acts and directs
the activities within the system. The objects in a telecommunications
process program system are basically of two types:
(1) All such program systems have internal objects defined in terms of data
upon which the programs operate. These objects are the software systems'
reality and the data is the static picture of the real world which the
programs manipulate.
(2) All real time and process control systems, however, also operate on
dynamic objects outside the program systems. Examples of such dynamic
objects are images on a display screen or telephones and trunks in a
telecommunication system. These program systems will also include the
dynamic objects as being represented by data objects.
The object-oriented programming technique of encapsulating actions together
with data and defining all of it as an object is a distinct advantage if
the program is a routine which is closely related to its objects. Examples
of such routines are found in display screen presentation systems as well
as in the line interface parts of a telecommunications system. If,
however, the control programs in such a process control software system
are all defined as objects, certain negative effects are also produced.
First, the control programs become fragmented and very complex
interactions and relationships become necessary between the objects. Such
a result requires an overlay control structure and in known object-based
telecommunication systems, complex C.C.I.T.T. specification design
language (SDL) flow charts have been required to describe such control
structures. Moreover, the dynamic relationships between the objects are
still very difficult to describe and to understand even with the use of
such flow charts. Second, when no entities in the control software system
are defined as a subject, any explanatory model becomes inherently
defective. The program actions, that is, its predicates, become bundled
together with the objects, thus rendering both the objects and the actions
very difficult to locate. This makes almost impossible the organization of
actions within process control systems into logical groups. Further,
designers are unable to structure applications in a natural way that would
be both highly understandable to anyone viewing the organization and easy
for designers to work with.
The latest generation of declarative programming languages such as PROLOG
and LISP are very efficient and reduce the work of software design and
programming because: (a) all programming can be done in symbolic form; and
(b) the concept of predicates and a whole new set of powerful instructions
have been included within those languages. The use of such languages
dramatically reduces both the number of details a programmer needs to be
concerned with and the importance of program encapsulation. The real
disadvantage of utilizing declarative languages in process control and
real time systems such as stored programmed control telecommunications
switching systems, is their insufficient real time performance and their
inability to handle parallelism.
Many of the newer declarative or object oriented programming languages have
been used to allow programmers to perform rapid prototyping of functions
or programs. Rapid prototyping techniques have a number of recognized
advantages that flow from the ability to incrementally design and develop
an application or a system. Potentially costly design errors can be
detected and corrected earlier in the development process; individual
aspects of a system can be implemented and tested very quickly; lengthy
test and/or implementation phases can be avoided; and fast prototype
development allows designers to explore a number of options with respect
to an application or function. Many other advantages to prototyping exist
as well.
Rapid prototyping techniques have benefits in the context of
telecommunications systems as well. Until now, however, the techniques
have had several drawbacks due to the real-time nature of the processing
activities that occur in telecommunications systems and the parallel
nature of these operations. The system of the present invention includes
certain aspects that extend previously known prototyping methods and
capabilities so that rapid prototyping can effectively be used in
connection with telecommunications systems. Experiments in the use of
prototyping techniques in connection with telecommunications systems are
described in "Using Prolog for Rapid Prototyping of Telecommunication
Systems," J. L. Armstrong and M. C. Williams, Seventh International
Conference on Software Engineering for Telecommunication Switching
Systems, Jul. 3-6, 1989, Bournemouth, and in "Experiments with Programming
Languages and Techniques for Telecommunications Applications," B. Dacker,
N. Elshiewg, P. Hedeland, C. W. Welin, M. Williams, Sixth Int'l Conference
on Software Engineering for Telecommunication Switching Systems, Apr.
14-18, 1986, Eindhoven, which are hereby incorporated herein by reference.
The development of the declarative language ERLANG has essentially solved
these two problems allowing the introduction of process control concept
into the world of declarative languages. The basic concepts of the ERLANG
language are described in the article "ERLANG: An Experimental Telephony
Programming Language," Proceedings, XIII International Switching
Symposium, Vol. III, pp. 48 (1990), which is hereby incorporated herein by
reference. A more detailed treatment is found in the "Erlang User's Guide
& Reference Manual" and the "Erlang BIF Guide" which are incorporated
herein as Attachment A. The use of such a language enables the
construction of real time process control software systems in accordance
with the system of the present invention.
SUMMARY OF THE INVENTION
In one aspect, the system of the present invention includes a declarative
language construct for use in programming process control systems such as
telecommunications switching systems. The language construct includes
natural language elements comprising a subject, represented by the process
of actions, a predicate, represented by predicates of the declarative
language defined as program procedures, and an object, represented by data
and real world entities defined in symbolic form and included in object
processes.
In another aspect, the system of the present invention includes a method
for constructing prototype software for telecommunications switching
systems including the procedures for preparing functional specifications
and subsequently mapping those functional specifications directly onto the
users and the network functional entities employing the declarative
language construct of the present invention.
In still another aspect, the present invention includes a software
architecture for use within a process control system such as a
telecommunications switching system. In this aspect, the system includes a
layered architecture comprising an application layer, an application
operating system layer, and a basic operating system layer each
cooperating with one another to provide an enhanced level of
functionality.
In a further aspect, the invention includes a method for constructing a
prototype software system for a telecommunications switching system in
which the overall description of the service aspects of the software
system is first defined from the user's point of view. The origination and
termination of user sequences forming the actual subjects within a user is
identified. Next, the functional entities and information flows within the
system are identified and the functional entities and identifications of
unique and common predicates are mapped. Finally, the real world entities
are represented as objects within the system.
In yet another aspect, the invention includes a multi-layer software
architecture for use within a telecommunications switching system which
includes an application layer for implementing telecommunications features
within the switching system and which is constructed with a direct
correspondence to the telecommunications application being specified. An
application operating system layer is provided for support functions to
the application layer and for hiding and isolating the implementation
details of the telecommunications application. A basic operating system
layer includes the primitives and functions needed for implementation of
telecommunications functions as well as standard primitives and run-time
executives for a time sharing computer system. One embodiment of this
aspect includes an application layer having task modules for defining
particular tasks within a telecommunications function or application being
implemented, including the signaling protocols to be employed therein. In
some cases, if the implementation of a feature requires no specialized
management functions to be directly associated with it, a task may
comprise only one or more feature modules. Similarly, there may be
instances in which a task may only comprise one or more management
modules, with no feature modules included. Finally, a task module may
comprise both one or more feature modules along with one or more
management modules.
In yet still another aspect, the invention includes a system for managing
data within the architecture of a telecommunications switching system
which includes at least one feature module and at least one management
module within an application layer and a data base within a basic
operation system layer. Feature-unique data fields are created within the
data base and assigned formats, limits and default values by means of an
initiation part of the feature module. An initiation portion of the
management module creates commands and parameters referring to the data
fields within the data base and stores the commands and parameters in the
data base. Each command is analyzed in response to its reception and is
checked for the authority of its use and whether its parameters are within
preselected value limits. The appropriate individuals are accessed by a
management feature in response to the acceptance of the command and the
appropriate feature unique data field is operated upon to modify the field
in response to the command.
As will readily be appreciated by those of ordinary skill in this
particular art, the principles and aspects of this invention could be used
to advantage in other software systems and in a variety of other computer
and process control applications in addition to telecommunications
switching systems.
BRIEF DESCRIPTION OF THE DRAWINGS
For an understanding of the present invention and for further objects and
advantages thereof, reference may now be had to the following description,
taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram illustrating the application of the system of an
embodiment of the present invention to the development of prototype
software for the control of telecommunications switching machines;
FIG. 2 is a block diagram of the steps employed in the development of
prototype software;
FIG. 3 is a flow chart illustrating software development in accordance with
an embodiment of the system of the present invention;
FIG. 4 is a flow chart illustrating the steps of specifying the service
aspects of telecommunications software development in accordance with an
embodiment of the invention;
FIG. 5 is a flow chart illustrating the specification of the functional
network aspects of the development of telecommunications software in
accordance with an embodiment of the invention;
FIG. 6 is a block diagram illustrating the mapping of functional entities
from a functional specification onto the software system structure in
accordance with an embodiment of the present invention;
FIG. 7 is a block diagram illustrating the mapping of functional entities
in the case of a network from the specification to the software system in
accordance with an embodiment of the present invention;
FIG. 8 is a block diagram illustrating the overall architecture of software
for a telecommunications switching system constructed in accordance with
an embodiment of the present invention;
FIG. 9 is a block diagram illustrating the telecommunications software
system architecture of an embodiment of the present invention;
FIG. 10 is a block diagram illustrating the manner in which the traffic
portion of a user module is hierarchically built in an embodiment of the
present invention;
FIG. 11 is a block diagram alternatively illustrating a data handling
operation within the architecture of the software system of the present
invention;
FIG. 12 is a block diagram illustrating the call side separation aspect of
an embodiment of the present system;
FIG. 13 is a diagram illustrating the interaction of the call sides in an
embodiment of the present system;
FIGS. 14-16 are diagrams illustrating various aspects of the implementation
of functional features within an embodiment of the present system;
FIG. 17 is a block diagram showing an overall development environment
within an embodiment of which the present system for prototyping may
function; and
FIG. 18 is a block diagram illustrating certain differences between the
system of the present invention and certain other known systems.
DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENT
The preferred exemplary system of the present invention consists of several
different related aspects including a programming language structure
especially adapted for use in software of real time process control
systems such as telecommunications systems; a methodology used for the
preparation of prototype software used in telecommunications switches; and
a software architecture and program construction tool for
telecommunications switching systems. Each of these different aspects of
the present invention and their interrelationships with one another will
be discussed below both with regard to their theoretical and technological
underpinnings as well as their use in a practical, operating software
system.
Software Construction Methodology
As discussed above, each of the well known programming methods of
process-oriented programming, object-oriented programming, and declarative
language programming includes certain inherent disadvantages when applied
to real time process control environments such as that present in
telecommunications switching systems. The programming construction methods
for such real time processes used in the system of the present invention
incorporate capabilities to handle real time processing and performance as
well as parallelism of operations, by employing a robust declarative
language with a novel language construction technique to produce clear and
easy to understand application-oriented software architectures.
The language construction technique of the system of the exemplary
embodiment is characterized by the usage of the three natural language
elements of subject, predicate, and object. The subject is represented by
the process of actions, while the predicate is represented by predicates
of the declarative language defined as program procedures. The object is
represented by data and real world entities such as telecommunications
trunks and telephones, all of which are defined in symbolic form and
included in an object process. The present technique not only makes it
possible for a software designer to concentrate on defining the different
entities in the application structure being constructed, but it strongly
encourages it. Usage of the three basic elements of human language allows
a model to be created that is not only powerful but also clear and easy to
understand. Moreover, the present language construction may also be viewed
as a paradigm of active subjects ("PACS").
In the present exemplary system, a subject is defined as a sequence or a
number of sequences of predicates and is characterized by the actions that
it is able to perform. This provides a powerful mechanism for structuring
all functions into groups in order to form natural and easy to understand
entities within the software. The use of the process concept solves a
great number of real time problems, and, in addition, it supports the
introduction of the language element of "subject" into the construction of
computer programming languages. In the present system, a subject process
is named and specified as to its content of action in a manner similar to
the way in which individuals such as masons, mechanics or carpenters are
named and defined in the real world. This enables the natural
specification of relations between actions. For example, in a PBX software
system, this aspect is known as service interaction, which in the
employment of the present methodology, becomes a natural part of the
subject specification. A thorough knowledge of the actual application is
required, however, in order to define the proper subjects for an
application or service. The subject concept also supports the effort to
move the focus of software development from low-level implementation
details toward overall applications and solutions to user-defined
problems.
Subjects can be defined, in the present exemplary system, at any, except
the lowest, level of abstraction within the designer's conceptualization
of the system or application being developed. At the highest level of
abstraction, there is a subject that defines and breaks down the entire
functionality of the system. The highest level subject that provides the
overall control sequence and flow for the system is akin to a main program
or routine utilized in traditional programming languages. In this aspect
of the system of the present invention, subjects comprise a sequence of
subject, predicate and object processes or a sequence of only predicate
and object processes to define the full set of activities that form a part
of that subject.
Examples of functions or activities that might be defined as subjects
within the present system include, but are not limited to: (a) activation
of a telecommunications switching system; and (b) interrogation of a
telecommunications system as to what services are available within the
system. It should be understood that a subject which is defined as a
sequence or a number of sequences of predicates could be interpreted as
activities, or control flows, within the user part of the feature module
that handles a particular aspect of a feature, as described below in the
sections related to the "Improved Prototyping Technology" and "Software
Architecture and Technology" aspects of the present invention. What
follows immediately is a sample set of "pseudo-code" that could be used
within the system of the present invention to define a subject.
______________________________________
<Subject Definition>
<Export/Import Predicate Declarations>
<Description of the Interface>
<Initiation Part>
<Initiation of default data, user procedures, test procedures,
used user suffixes and timers, e.g.>
<User sequences, PACS step 1 > ACTIVATION, DEACTIVATION
and REGISTRATION>
activate(FromUser,UserState,UsersParticipated,UserData)->
<activate predicate 1>
<common predicate x>
.
.
<activate predicate N>
<deactivate(FromUser,UserState,UsersParticipated, UserData) ->
<common predicate y>
<deactive predicate x>
.
.
<common predicate N>
register(FromUser,UserState,UsersParticipated,UserData) ->
<register predicate 1>
<common predicate z>
.
.
<register predicate N>
<User sequences, PACS step 1 > INTERROGATION
interrogate(FromUser,UserState,UsersParticipated,UserData) ->
<interrogate predicate 1>
<common predicate z>
.
.
<interrogate predicate N>
<User sequences, PACS step 1 > INVOCATION
userInvocation(UserState,InteractingState,UsersParticipated,
UserData) ->
<continue in user 1 operation>
interactingInvocation1(UserState,InteractingState,
UsersParticipated,UserData) ->
<continue in user 2 operation>
interactingInvocation2(UserState,InteractingState,
UsersParticipated,UserData) ->
<continue in user 3 operation>
<User sequences, PACS step 1> OPERATION
<USER 1, PACS step 2>
user1(UserState,InteractingState,UsersParticipated,UserData)->
<user 1 predicate 1>
<common predicate x>
.
.
<user 1 predicate N>
<USER 2, PACS step 2>
user2(UserState,InteractingState,UsersParticipated,UserData)->
<user 1 predicate 1>
<common predicate x>
.
.
<user 1 predicate N>
<USER 3, PACS step 2>
user2(UserSTate,InteractingState,UsersParticipated,UserData)->
<user 1 predicate 1>
<common predicate x>
.
.
<user 1 predicate N>
<User sequences, PACS step 1 > EXCEPTIONS
activationException(UserState,InteractingState,
UsersParticipated,UserData) ->
<activationException predicate 1>
<common predicate x>
.
.
<activationException predicate N>
deactivationException(UserState,InteractingState,
UsersParticipated,UserData) ->
<deactivationException predicate 1>
<common predicate y>
.
.
<deactivationException predicate N>
______________________________________
.COPYRGT. 1991 Telefonaktiebolaget L M Ericsson
The predicates used by the subjects are defined in the exemplary system of
the present invention by either basic instructions or by the formation of
new predicates by defining program routines referred to as procedures.
Each procedure can be specialized and unique for one particular subject or
it may be generalized and used by many different subjects. Each procedure
is also characterized by its action. The use of procedures in a layered
architecture as predicates in the declarative language introduces a
virtually unlimited possibility for raising the abstraction level and
increasing the power of the top level language. One basic rule that should
be employed in designing this type of system should be to keep the number
of procedures small enough so as to keep the system easy to understand and
maintain. A predicate should be viewed as a discrete procedure such as,
for example, number analysis. Although the predicate could perform a
complex task, it must always be very clear. At the lowest level, a
predicate could consist of nothing more than a single declarative language
statement. It should also be understood that the predicates used in the
language construction aspect of the invention are represented as
predicates in a declarative language and defined as program procedures
within the application operating system (AOS) as described below in the
section related to the "Software Architecture and Technology" aspect of
the invention.
The present exemplary method can be compared to the known C++ manner of
providing for the inheritance of all or part of a program. In that case,
how | | |
