JPS61150592A - Exchange service specification checking processing system - Google Patents

Abstract

PURPOSE:To decrease the number of rules for checking by using a rule for checking in the general-use and diverting the same rule between different types of terminals. CONSTITUTION:The meaning extracting part 6 of a specification checking part 5 retrieves a meaning network memory part 3 by a shown processing 22 and extracts all higher level concepts of the condition expressed by a condition descriptor 20. In the same manner, the higher level concept concerning an even descriptor 21 is also extracted from a meaning network memory part 3. Next, by the processing by a rule retrieving part 7, a rule memory part 4 for checking is retrieved, and the rule is searched for the noticed condition, namely, including any element of 'off-hook', 'signal phase', 'figure input possible', and 'TONE(DT)'. By the decision, when it is confirmed that the retrieval of the rule is wholly completed, the relation of the condition descriptor 20 with the even descriptor 21 is handled as it is right, for example, by an as-shown call a processing program generating part 11, converted to a program language.

Description

[Detailed description of the invention] [Industrial application field] The present invention is an exchange service specification check processing method.

In particular, it is a method for detecting design mistakes regarding the functional specifications of an exchange system expressed in a state transition diagram.

The present invention relates to an exchange service specification check processing method that makes it possible to reduce the large number of checking rules required for an exchange system that accommodates a wide variety of terminals.

[Conventional technology and problems]

For example, in building an electronic switching system.

Through state transition diagrams based on the state of the terminal and events caused by human operations that change the state of the terminal.

The specification of exchange services is being written. Based on this state transition diagram, automatic programming of call processing programs and the like is being considered.

Figure 4 is an example of a state transition diagram that defines an exchange service;
The figure shows a diagram for explaining checking rules regarding functional specifications.

A state transition diagram 1, for example, as shown in FIG. 4, is represented by state descriptors Sl, S2 and event descriptors El, E2. The state descriptor S1 indicates that the terminal is in a busy state with terminal B. Event descriptor E1 indicates that there was a so-called flush operation. Due to this event, the state is.

A transition is made to the state indicated by state descriptor S2, terminal B is placed on hold, and the second dial tone is transmitted.

Event descriptor E2 indicates dial input.

When such a state transition diagram is input and an exchange service is designed, since the events that can and cannot occur in a certain state are usually determined in advance, the relationship between that state and events is This is done by storing rules as rules and automatically detecting errors when an unacceptable event is specified in a certain state to prevent design mistakes.

The general form of this checking rule is expressed as 2, for example, ``When condition GX, event Y is not allowed to occur.'' FIG. 5 is an example of a check rule, and in state Xi,
Event Yl, Y2. Y3... is not allowed and state X2
When , Ihen I-Y2, Y4. This indicates that Y5... is not allowed.

A method for verifying the validity of functional specifications using such checking rules is better than a verification method using an analytical method such as inter-process synchronization analysis.

It has the advantage of allowing detailed checks and making it easy to handle large-volume specifications. However, there is a problem in that a large number of checking rules are required, and in particular, as the number of checking rules increases with the diversification of accommodated terminals, it is difficult to manage and create them.

[Means for solving problems]

In order to solve the above-mentioned problems, the present invention provides a means for reducing the number of checking rules by making checking rules more general so that the same rules can be used between different types of terminals. In other words, the exchange service specification check processing method of the present invention inputs information expressed by events related to the operating procedures of the terminals and the states of the terminals that change due to the events, for exchange services that accommodate 41 different types of terminals. , an exchange system design processing system for designing an exchange system, comprising: a semantic network storage unit that stores conceptual information based on the meaning of the terminal state and the meaning of the event in a hierarchical manner; and at least rules for checking regarding the conceptual information. A check rule storage unit that stores rules including rules, and a rule that extracts the meaning of the input terminal state and the input event by referring to the semantic network storage unit and stores the rules stored in the check rule storage unit. The present invention is characterized by comprising a specification checking section that checks the validity of the relationship between the terminal state and the event according to the above.

[Effect]

The present invention replaces the 4JJ3 lost child and event descriptor that make up the check rule with general-purpose semantic elements that do not depend on the terminal type, and by layering these general-purpose semantic elements, the rule can be made general-purpose. It is designed to be more flexible and easier to manage. In other words, check rules should be defined as much as possible at the superordinate level of the meanings of states and events.2 For example, when a new terminal is added, state descriptors and event descriptors specific to that terminal should be defined. , by making it possible to treat the rules in the same way as those related to existing terminals that belong to the concept, it is possible to reduce the number of rules through generalization.The following 1
An embodiment will be described with reference to the drawings.

〔Example〕

FIG. 1 is a block diagram illustrating the configuration of an embodiment of the present invention, FIG. 2 is a diagram illustrating a semantic network according to the present invention, and FIG. 3 is a diagram illustrating processing according to an embodiment of the present invention.

In the figure, reference numeral 1 indicates an input section for manually inputting a state transition diagram using state descriptors and event descriptors, and reference numeral 2 indicates information on the state transition diagram input by the manual section 1. 3 is a semantic network storage section that stores the knowledge data of the semantic network; 4 is the check rule storage section that stores the knowledge data of the check rules; and 5 is the storage section that stores the input exchange service specifications. 6 is a meaning extraction unit that extracts concepts related to state descriptors and event descriptors from the semantic network; 7 is a specification checking unit that verifies validity; 7 is a semantic extraction unit that searches for checking rules and checks whether the specified event is allowed to occur. 8 is an error output section that outputs error information when there is an error in the specifications, 9 is a display, IO is a line printer, and 11 is when the input specifications are correct.

A call processing program generation unit 12 automatically generates a call processing program based on the specifications, and 12 represents a program file in which the generated call processing program is stored.

A case in which the functional specifications of an exchange system, that is, the exchange service specifications, are expressed in terms of operating procedures for the terminals it accommodates.

For example, state descriptors and event descriptors as shown in FIG. 4 are used, but these state descriptors and event descriptors generally differ depending on the type of terminal.

For example, in the case of a normal PB/DP telephone, the state in which a dial tone is heard is represented by the state descriptor "rTONE (DT)." Also, when using a computer with a display as a communication terminal, the message prompting you to enter the other party's phone number may be displayed on the ro+
It is represented by the state descriptor sp (INPUT-MSG)J. but.

Although these states are represented by different state descriptors, they have substantially the same meaning from the system's perspective in terms of exchange processing.

According to the conventional method, checking rules are created using state descriptors and event descriptors that depend on the terminal type. Therefore, the number of rules becomes enormous. In the case of the present invention, by associating descriptors whose expressions differ depending on the terminal with general-purpose semantic elements, a logical meaning is given to each descriptor when viewed from the system. Then, a check rule is created using the concept that is the semantic element.

FIG. 2 shows an example of a semantic network in which state descriptors and event descriptors are made to correspond to general-purpose semantic elements, and these are hierarchically arranged in a tree shape. The properties of a superordinate concept are inherited by its subordinate concepts.

For example, the state represented by rTONE (DT)J is interpreted as "a signal phase state in an off-hook state, in which numeric input is possible." and "off footer", "signal phase".

Checking rules that include any of the semantic elements of "number input allowed" are also used to check the state expressed in rTONE (DT)J. The same holds true for the concept of event.

Therefore, checking rules written using the semantic elements of the concept part can be used for the functional specifications of different terminals, and can also be used to check multiple states that include the same concept. It is possible to significantly reduce the amount.

Next, regarding the processing of the embodiment shown in FIG.

This will be explained according to FIG.

When the input unit 1 inputs a state transition diagram into the state transition diagram storage unit 2 using state descriptors and event descriptors, the specification checking unit 5 is activated. This state H transition diagram has 9 state descriptors 20, for example, as shown in the illustrated state transition diagram storage unit 2 in FIG. Assume that the event descriptor 21 etc. is used.

The meaning extraction unit 6 of the specification checking unit 5 first searches the semantic network storage unit 3 in the illustrated process 22 in FIG. 3 to extract all the superordinate concepts of the state expressed by the state descriptor 20. Similarly, the superordinate concepts regarding the item descriptor 21 are also extracted from the semantic network storage unit 3.

Next, by the process 24 by the rule search unit 7.

The checking rule storage unit 4 is searched to find the states of interest, ie, "off-hook" and "signal phase."

``Search for rules that include either the elements ``Number input allowed J'' or rTONE (DT)
The relationship between the state descriptor 20 and the event descriptor 21 is treated as correct 9, for example, by the illustrated call processing program generation unit 11 in FIG.

Convert to programming language.

In the search in process 24, if a corresponding check rule is obtained, the semantic elements of the event, such as "mode switching", "exchange start", "operation start J, rPIcKUP
Check whether all of J is prohibited. If it is determined in process 27 that the rule is valid, the process returns to process 24 to search for the ninth rule and repeat the process in the same manner.

In this example, the rule ``It is not possible to start an exchange when in an off-hook state'' is registered.

The superordinate concept of rTONE (DT)J is "off hook", and the superordinate concept of rP I CKUPJ is "start exchange".
Therefore, it can be seen that the event expressed by the event descriptor 21 is not allowed to occur in the state of the state descriptor 20, and this is considered a specification error. If an error is detected, the error output unit 8 shown in FIG. 1 outputs the error information to the display 9, line printer 10, or the like.

In the above example, the check rule is expressed in the form ``Event Y is not allowed to occur when state ” may be used. Further, even if the condition is a state that can be transitioned or a state that cannot be transitioned in response to a certain event, it can be processed in the same way.

〔Effect of the invention〕

As explained above, according to the present invention, checking rules for multiple states and events can be integrated, and the rules can be applied to different types of terminals.

It becomes possible to significantly reduce the number of checking rules. For example, when supporting an exchange service for a new terminal, by simply registering it in the meaningless 1-work, there is often no need to additionally register check rules, which can reduce development costs, and Since rules whose validity has been confirmed as check rules can be used on existing terminals, debugging regarding rules becomes easier.

[Brief explanation of drawings]

FIG. 1 is a block diagram of the configuration of an embodiment of the present invention, FIG. 2 is a diagram illustrating a semantic network according to the present invention, and FIG. 3 is a diagram illustrating processing according to an embodiment of the present invention. FIG. 4 is an example of a state transition diagram that defines an exchange service. FIG. 5 shows a diagram for explaining checking rules regarding functional specifications. In the figure, 2 represents a state transition diagram storage unit, 3 a semantic network storage unit, 4 a checking rule storage unit, 5 a specification check unit, 6 a meaning extraction unit, and 7 a rule search unit.

Claims (1)

[Claims] In an exchange system design processing system that designs an exchange system by inputting information expressed by events related to terminal operation procedures and terminal states that change due to the events, for exchange services that accommodate many types of terminals, a semantic network storage unit that stores hierarchically conceptual information based on the meaning of the terminal state and the meaning of the event; a checking rule storage unit that stores rules including at least checking rules regarding the conceptual information; The meaning of the terminal state and the meaning of the input event are extracted by referring to the semantic network storage section, and the validity of the relationship between the terminal state and the event is determined according to the rules stored in the checking rule storage section. An exchange service specification check processing method characterized by comprising a specification check section for checking.