JPH07168708A - Exchange service scenario design support system - Google Patents

Abstract

PURPOSE:To provide a system capable of automatically preparing service definition leaving a designer only successively answering to menu inquiries when designing the additional service of an exchange system. CONSTITUTION:This system is provided with an editor control part 11 for generating skelton data, for which the respective inquiries are linked in a tree structure form, from a menu description file 3 describing inquiry patterns, displaying the inquiry to a designer 6 and constructing the service definition with the information of this inquired result as tree structure data. An editor generating part 12 evaluates the constructed service definition, converts it to a service code and outputs it to a service code file 5. Thus, this system is contributed to facilitate the service design and to considerably improve development efficiency.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an exchange service scenario design support system, and more particularly to an exchange service scenario design support system for generating an additional service scenario of the exchange system by a menu inquiry method in an interactive form with a user.

[0002]

2. Description of the Related Art At present, various types of additional services provided by switching systems such as PBXs, exchanges for offices, and ATM exchanges are diversified, and the amount of software development required to realize the additional services is enormous. The improvement of productivity and quality of additional service software development has become a very important issue.

Under such circumstances, there is a supplementary service control system as a means for significantly improving the development efficiency of supplementary services. ("Supplementary Service Control Method", Shima, Kodama et al., IEICE Technical Report, SSE91
(See -8, 1991.5)

This supplementary service control method (hereinafter referred to as "the present control method") consists of a scenario which is a processing unit of a message, a condition description for starting the scenario from basic call control, and a scenario process. One service is realized by a collection of point descriptions returning to basic call control and data descriptions used in services.
Detachability, independence, descriptiveness, and portability of additional services are considered.

As shown in FIG. 12, in this control method, TCP (trigger check point) is a point at which the activation of a service scenario is checked in basic call control, and PIC is a point at which the service scenario can be restored.
(Point-in-call). The scenario can also be activated by signal generation.

According to this control method, each scenario is made into a simple processing unit, and a service is provided by simply combining control primitive parts, service processing parts, scenario start condition parts, return point specifying parts, data description parts, etc. It is relatively easy to prepare a common library that enables the definition of.

Further, if a conversion system for generating a C language source code having a common library call as the input, which is a service definition which is a set of component combinations, can be prepared, the coding of the additional service can be automated.

However, in such a conventional supplementary service control method, if a common library and conversion system for the service definition can be prepared, the productivity and quality of the supplementary service can be improved, but the degree of abstraction is high. Although the cost is higher, it is necessary to understand the input format of the conversion system to define the service, so that the productivity is slightly improved as compared with the direct coding in the C language.

That is, there is a problem that the designer needs to have an understanding of the programming language used to define the supplementary service in addition to the knowledge of the supplementary service to be designed.

Therefore, according to the present invention, various tools using a GUI (graphic user interface) as a tool that can positively support the service definition work without requiring any knowledge other than the additional service designed by the designer. The purpose is to provide an environment in which additional services can be described while making various menu inquiries, and to further improve the productivity of additional service development.

[0010]

In order to solve the above-mentioned problems, in the exchange service scenario design support system of the present invention, an editor is used by constructing a service definition from prepared processing parts by a menu inquiry method. This is an automated task of describing a service definition according to the input format specified in the description.

The exchange service scenario design support system of the present invention creates a service definition which is an output of a scenario design, and a menu description means for describing an inquiry pattern for the designer, and an individual inquiry from the menu description means. It is characterized by having edit control means for generating skeleton data connected in a structural form, displaying an inquiry to a designer, and constructing a service definition using the information selected by the designer in the inquiry result as tree structure data. .

[0012]

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below with reference to the drawings.

FIG. 1 shows an exchange service scenario design support system (hereinafter referred to as "scenario editor system") according to the present invention.
Is a block diagram showing a system configuration.

In FIG. 1, the scenario editor 1 has an editor control unit 11 and an editor generation unit 12.

The editor control unit 11 has a menu description file 3 defining a query means for the designer executed by the scenario editor system and a basic call SDL.
The inquiry means is called using FIG. 4, and the execution result executed by the designer is saved in the service file 2.

The editor generation unit 12 evaluates the additional service executed and constructed by the designer and saved in the service file 2, and further converts the content of the additional service into a service source code of C language or the like to convert the service code file. Output to 5.

The designer 6 goes to such a scenario editor, edits the service definition while responding to the menu inquiry using display means and input means (not shown), and saves the intermediate result as the service file 2. When the service definition is completed, check the consistency of the service definition and
By starting the conversion system, the service code (for example, C source code) of the service definition is acquired from the service definition.

The scenario editor 1 reads the menu description file 3 and the SDL diagram 4 of the basic call control at the time of starting.

The menu description file 3 describes a query pattern, a service code generation format, etc. at the time of defining a service, and many types of services can be defined by the scenario editor simply by changing the description. .

SDL FIG. 4 is used for auxiliary input when defining a service.

In the scenario editor system of the present invention,
The service is represented by one tree structure as a whole,
A series of menu inquiries will edit the sub-tree structure of the corresponding service.

Since the menu inquiry can proceed by automatically judging the context of the inquiry so far, the designer does not need to be aware of the hierarchical tree structure of the service definition and unnecessary menu selection. It has features.

Next, the menu inquiry method will be described. FIG. 2 is a block diagram showing the functional arrangement of the menu inquiry method in the scenario editor system of this embodiment.

In the figure, the menu description 41 defines the form, context, etc. of the question.

The skeleton data 43 is the menu description 4
1 is data expressing each of the questions defined in 1 in a tree structure form.

The skeleton data construction means 42 produces this skeleton data 43.

The inquiry means 44 refers to the skeleton data 43 and the syntax tree data 45 constructed up to the present,
The question is displayed while being evaluated, and the result selected by the designer is constructed as syntax tree data 45 expressed in a tree structure form.

The structure data constructing means 46 constructs the structure data 47 while referring to the skeleton data 43 and the syntax tree data 45.

Next, each block in FIG. 2 will be described.

The menu description 41 is composed of a set of a plurality of skeleton rules that define a skeleton that is a frame of the menu, and expresses an inquiry hierarchically.

In the menu description 41, in order to simplify the skeleton hierarchy and improve the visibility, the skeleton rule is described in the context freely from the top down, and the context is automatically judged by the resource value.

Each skeleton rule has the following description format.

Skeleton name = skeleton type parameter resource name resource value resource name resource value There are skeletons of the following types depending on the form of inquiry, and each skeleton has different parameters and resource names.

By combining these, various inquiry forms can be realized.

"Field": Make an inquiry to input a character string. It has no parameters and is located at the end of the tree structure.

“OneOf”: A fixed number of child skeletons that can be candidates are used as parameters, one of them is selected, and the selected child skeleton is inquired.

"OneOfList": already constructed "lis
A parameter specifies that the element of "t" is selected, and an inquiry is made to select one of them.

"OneOfMap": Has a fixed number of child skeletons that can be candidates as a parameter, selects from two-dimensional candidates, and inquires about the selected child skeleton.

"Struct": With a fixed number of child skeletons as parameters, the child skeletons are inquired in order.

"RandomStruct": With a fixed number of child skeletons as a parameter, the child skeleton selected by the inquiry is inquired.

"List": An indefinite number of child skeletons indicated by parameters can be held. Provides editing functions such as adding, changing, deleting, cutting, copying, and pasting elements when editing.

"Quote": It has no inquiry and is located at the end of the tree structure. Define a constant value.

The typical resources that each skeleton can have are shown below.

Due to the nature of each resource, the resources that can be held differ depending on the skeleton.

"Format": defines a conversion format to structural data. It is possible to have all skeleton types.

"Message": Defines the text that the skeleton making the inquiry has and that is displayed together with the inquiry item.

"MaxChars": defines the maximum number of characters that can be input. A resource dedicated to the "field" skeleton.

"MenuItem": Defines display text as a selection item. "OneOf", "oneOfList", "oneOfMa
You can have a "p", "randomStruct" skeleton.

"Where": Specifies a candidate condition for a selection item. You can have "oneOf", "oneOfList", "oneOfMap" skeletons.

"Check": The consistency of the constructed syntax tree data is designated by an expression. It is possible to have all skeleton types.

Inside the scenario editor 1, a query is positioned as an editing operation for data called a syntax tree that holds a query result.

The syntax tree is an instance whose class is a skeleton, and the skeleton is an instance whose class is a skeleton type.

The editing operation on the syntax tree is described in the skeleton type traced from the syntax tree through the skeleton,
If the skeleton types are the same, the processing procedure is the same.

The syntax tree is an incomplete tree before editing, and becomes a complete tree when editing is completed normally.

Next, the skeleton data generating means 42 and the skeleton data 43 will be described.

The skeleton data 43 is the menu description 4
This is static data in the form of a tree structure, which is the internal system format of No. 1, and is constructed by the skeleton data generating means 42 when the system is started. Each element of the skeleton data 43 has a procedure pointer of inquiry means, a pointer to resource data, and in the case of a skeleton having a child skeleton, a pointer to a child skeleton.

Next, the inquiry means 44 and the syntax tree data 45 will be described.

The inquiry means 44 exists for each skeleton type and advances the inquiry by tracing the current skeleton data up and down 43, and as a result, constructs while adding and deleting the syntax tree data 45.

Inquiries are not necessarily made for all skeleton types, and some types may not be made.

The inquiry means 44 does not exist for each question, but one for each skeleton type.
If they exist and have the same skeleton type, they can be used universally.

The syntax tree data 45 is dynamic data in the form of a tree structure, and each has a pointer to the parent syntax tree, a pointer to the corresponding skeleton data, a pointer to the child syntax tree, and the like.

Next, the structure data construction means 46 and the structure data 47 will be described.

The structure data constructing means 46 exists for each skeleton type, hierarchically traces each syntax tree from the highest-level syntax tree of the syntax tree data 45, and refers to the "format" resource of the skeleton pointed to by each syntax tree. Then, the target structural data 47 is assembled.

Next, the operation of the present invention will be described using a simple inquiry example.

FIG. 3 is a flow chart of an example inquiry. There are three questions. First, there is a "field" type menu A (menu
-a) is used to make an inquiry and the text is input (ST31). Next, "oneOf" type menu B (menu-
b) is used to make a query and a single item (x or y)
Is selected (ST32). Finally, a single selection is made using the "oneOf" type menu C (menu-c). Note that here, the selection candidates in the menu C are different depending on the selection result of the inquiry of the menu B.

FIG. 4 is a diagram showing an example of the menu description for realizing the inquiry example.

Although there are line numbers in the figure, these are given as a reference for explanation.

In this example, the description is made using the four types of skeletons described above.

The following is a description.

The "inquiry" skeleton description in line 3-5 is a "struct" type skeleton, and inquires of menu A (menu-a), menu B (menu-b), and menu C (menu-c) skeleton in order. It defines things.

The "menu-a" skeleton description on lines 7-10 defines a "field" type skeleton to inquire about text input.

The "menu-b" skeleton description on lines 12-17 is the "oneOf" type skeleton of "item-x", "item-y".
It defines a single selection from the skeleton.

The "office" skeleton description on lines 19-34 is the "oneOf" type skeleton "item-p", "item-".
It defines single selection from "q" and "item-r" skeletons.

There is an expression for the "where" resource on lines 26-34, but it is defined to change the selection candidate depending on the selection result of the already selected "menu-b" skeleton.

Each "quote" type skeleton description on lines 36-48 defines each skeleton located at the end of the "quote" type skeleton.

FIG. 5 is a diagram showing a tree structure of skeleton data constructed by the skeleton data generating means 42 from the menu description file 3 shown in FIG. The skeleton data generation means 42 interprets the skeleton name, parameters, and resources on the menu description and constructs skeleton data with “% inquiry” as the root.

In the skeleton data of FIG. 5, the display text used for the inquiry, the format of the structure data, etc. are also stored as resource data, and all the contexts of the inquiry are expressed.

FIG. 6 is a flow chart of "struct" inquiry means, FIG. 7 is a flow chart of "field" inquiry means, FIG. 8 is a flow chart of "oneOf" inquiry means, and FIG. 9 is "quote".
FIG. 10 is a flowchart of the inquiry means, and FIG. 10 is a diagram showing a tree structure of syntax tree data.

An explanation will be given according to the flow of inquiry using these figures and the above-mentioned figure showing the tree structure of the skeleton data.

(1) The main processing of the inquiry means is the "struct" syntax tree of the first inquiry (101 in FIG. 10)
To create.

0 is initially set to the index information existing in the syntax tree.

In the case of the "struct" syntax tree, subordinate child syntax trees (102, 103, 105 in FIG. 10) are created and connected at the same time.

These syntax tree creating means are included in the inquiring means and exist for each skeleton type.

The main processing of the inquiry means makes the current syntax tree a "struct" syntax tree and calls the "struct" inquiry means which is the skeleton type of the current syntax tree.

(2) The "struct" inquiry means checks whether the inquiry has been completed up to the last child syntax tree (ST61 in FIG. 6).

In this case, since it has not been completed yet, the index is incremented by 1 (ST62 in FIG. 6) to make the current syntax tree a child syntax tree (102 in FIG. 10) of the number indicated by the index (see FIG. 6, ST63), and calls the "field" inquiry means, which is the skeleton type of the current syntax tree (ST64 in FIG. 6).

(3) "field" A menu is displayed in the inquiry means (ST71 in FIG. 7) and the input of text is waited (ST72 in FIG. 7).

The input text is converted into the field syntax tree (see FIG. 1).
0 of 102) (ST73 of FIG. 7), and the next inquiry is searched by tracing the syntax tree data upward (FIG. 7).
ST74).

In this case, when tracing upward, there is a "struct" syntax tree (101 in FIG. 10), so the current syntax tree is "st".
ruct ”syntax tree (101 in FIG. 10) (ST7 in FIG. 7)
6), "struc" which is the skeleton type of the current syntax tree
t ”inquiring means is called (ST77 in FIG. 7).

(4) The "struct" inquiry means checks whether the inquiry has been completed up to the last child syntax tree (ST61 in FIG. 6).

In this case, since it has not been completed yet, the index is incremented by 1 (ST62 in FIG. 6) to make the current syntax tree a child syntax tree (103 in FIG. 10) of the number indicated in the index (see FIG. 6 (ST63), the "oneOf" inquiry means, which is the skeleton type of the current syntax tree, is called (ST64 in FIG. 6).

(5) "oneOf" In the inquiry means, "% item-x" (54 in FIG. 5) and "% item-y" (5 in FIG. 5)
Display the menu with 5) as the selection candidate (ST of FIG.
81), and waits until an item is selected (ST8 in FIG. 8)
2).

Assuming that the selected item is the second item, a "quote" syntax tree (104 in FIG. 10) corresponding to the skeleton "item-y" (55 in FIG. 5) is created, and "oneO
f ”is connected as a child syntax tree of the syntax tree (103 in FIG. 10) (ST83, ST84 in FIG. 8).

Next, the current syntax tree is made a child syntax tree (104 in FIG. 10) (ST85 in FIG. 8), and the "quote" inquiry means which is the skeleton type of the current syntax tree is called (ST86 in FIG. 8).

(6) "quote" Since the inquiry means does not make an inquiry but is located at the end of the tree structure, it searches the syntax tree data for the next inquiry in the upward direction (ST91 in FIG. 9).

In this case, when tracing upward, there is a "struct" syntax tree (101 in FIG. 10), so the current syntax tree is "st".
ruct ”syntax tree (101 in FIG. 10) (ST9 in FIG. 9)
3), "struc" which is the skeleton type of the current syntax tree
t ”inquiring means is called (ST94 in FIG. 9).

(7) The "struct" inquiry means checks whether the inquiry has been completed up to the last child syntax tree (ST61 in FIG. 6).

In this case, since it has not been completed yet, the index is incremented by 1 (ST62 in FIG. 6) to make the current syntax tree a child syntax tree (105 in FIG. 10) of the number indicated in the index (see FIG. 6 (ST63), the "oneOf" inquiry means, which is the skeleton type of the current syntax tree, is called (ST64 in FIG. 6).

(8) "oneOf" The inquiry means displays a menu (ST81 in FIG. 8) and waits for an item to be selected (ST82 in FIG. 8).

The items displayed in the menu in this case are
"OneO" that can be traced from the syntax tree (105 in FIG. 10) "oneO"
Since there is a "where" resource in the "f" skeleton (56 in Fig. 5), the selection candidates are "% item-p" (57 in Fig. 5), "% i".
tem-q ”(58 in FIG. 5).

Assuming that the selected item is the first item, a "quote" syntax tree (106 in Fig. 10) corresponding to the skeleton "57" in Fig. 5 is created, and "oneO
f ”is connected as a child syntax tree of the syntax tree (105 in FIG. 10) (ST83, ST84 in FIG. 8).

Next, the current syntax tree is made a child syntax tree (106 in FIG. 10) (ST85 in FIG. 8), and the "quote" inquiry means which is the skeleton type of the current syntax tree is called (ST86 in FIG. 8).

(9) "quote" The inquiry means does not make an inquiry, but searches the syntax tree data for the next inquiry in the upward direction (ST91 in FIG. 9).

In this case, when tracing upward, there is a "struct" syntax tree (101 in FIG. 10), so the current syntax tree is "st".
ruct ”syntax tree (101 in FIG. 10) (ST9 in FIG. 9)
3), "struc" which is the skeleton type of the current syntax tree
t ”inquiring means is called (ST94 in FIG. 9).

(10) The "struct" inquiry means checks whether the inquiry has been completed up to the last child syntax tree (ST61 in FIG. 6).

In this case, since the index is 3 and it can be seen that the inquiry has been completed for all child syntax trees, the next inquiry is searched by tracing the syntax tree data upward (ST65 in FIG. 6). Since the self-syntax tree is the root and there is no other inquiry, the inquiry is terminated (68 in FIG. 6).

As described above, the syntax tree data of FIG. 10 reflecting the result of the inquiry is constructed.

Finally, the target structure data is completed as follows according to the format in the resource data of the skeleton pointed from each syntax tree by the structure data conversion means.

Answer (abcdef, YYY, PPP) Here, "answer" is the "format" resource of "% inquiry", "abcdef" is the text entered by "% menu-a",
"YYY" is "for%" of "% item-y" selected in "% menu-b".
"mat" resource, "PPP" is "% menu-c" selected "%"
It is a "format" resource for "item-p".

FIG. 11 shows the concept of the skeleton structure that realizes the service definition generated in this embodiment in the menu inquiry method described above.

[0111]

As described above, according to the present invention,
Even if the designer does not have knowledge other than the supplementary service designed by him / herself, simply by responding to various inquiries by the menu inquiry method, the supplementary service design intended for the exchange system according to the input format is automatically Can be described in.

As a result, there is an effect that it is possible to contribute to facilitating the design of supplementary services of the exchange system which requires a huge amount of development and to greatly improve the efficiency of developing supplementary services, because of the wide variety of uses.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of an exchange service scenario design support system according to the present invention.

FIG. 2 is a block diagram showing a functional configuration of a menu inquiry method in the system.

FIG. 3 is a flowchart showing an example of an inquiry for explaining an operation in the system.

FIG. 4 is a diagram showing a menu description example for realizing an inquiry example for explaining an operation in the system.

FIG. 5 is a diagram showing a configuration of skeleton data generated from a menu description example for explaining an operation in the system.

FIG. 6 is a flow chart of “struct” inquiry means for explaining the operation in the above system.

FIG. 7 is a flow chart of “field” inquiry means for explaining the operation in the above system.

FIG. 8 is a flow chart of “oneOf” inquiry means for explaining the operation in the above system.

FIG. 9 is a flow chart of “quote” inquiry means for explaining the operation in the above system.

FIG. 10 is a diagram showing a structure of syntax tree data for explaining an operation in the system.

FIG. 11 is a conceptual diagram showing a concept of a skeleton structure that realizes a service definition generated in the system.

FIG. 12 is a conceptual diagram illustrating a supplementary service control method.

[Explanation of symbols]

 1 scenario editor 11 editor control unit 12 editor generation unit 2 service file 3 menu description file 4 basic call SDL diagram 5 service code file

Claims (1)

[Claims] 1. In a scenario design support system for an exchange service for designing a scenario by inquiring a menu, in creating a service definition for the scenario design, a menu description unit describing an inquiry pattern and an individual inquiry from the menu description unit are issued. An exchange service scenario design support system comprising: edit control means for generating skeleton data connected in a tree structure form, displaying an inquiry, and constructing a service definition using the information of the inquiry result as tree structure data.