KR101787847B1

KR101787847B1 - Apparatus of verifying a process using process algebra and geo-temporal logic

Info

Publication number: KR101787847B1
Application number: KR1020150191240A
Authority: KR
Inventors: 최영복; 이문근
Original assignee: 전북대학교산학협력단
Priority date: 2015-12-31
Filing date: 2015-12-31
Publication date: 2017-11-15
Also published as: KR20170080060A

Abstract

The present invention visually expresses a process specified through a shaping technique and simulates the number of executable cases of the process to detect an error that occurs during execution of the process. And a process verification device for verifying requirements of a process through time-space logic. The present invention has the effect of increasing the stability of the process by visualizing the specification of the process, detecting errors occurring in the execution of the process by simulating the number of all cases in which the visualized process is executable. It also has the effect of visually verifying the requirements of the process by verifying the requirements of the process through a verification symbol that can represent requirements such as dependencies between processes in time and space.

Description

PROCESS VERIFYING PROCESS USING PROCESS ALGEBRA AND GEO-TEMPORAL LOGIC USING PROCESS SPECIFICATION AND SPATIAL-

The present invention relates to an apparatus for verifying a process through a process specification and a space-time logic, more particularly, to a method and apparatus for visually expressing a process specified through a formal technique, simulating the number of executable cases of the process, Detecting errors. And a process verification device for verifying requirements of a process through time-space logic.

In most real-time systems, there are numerous interactions between moving processes in geopolitical space. This increase in system size and complexity makes system specification and verification very difficult. Especially the interaction and movement between spatially distributed processes and processes makes the system more difficult to understand. Therefore, there is a great need for a method to visually specify and verify the system in the design phase of such a system.

Korean Patent No. 10-1038849 discloses a recording medium on which a verification method of software and a software verification method capable of verifying non-functional requirements of the software at the development stage of the software are recorded. First, a system composed of hardware and software is modeled as a hierarchical queuing Petri net, the modeled hierarchical queuing Petri net is converted into a Markov chain, and then a reward rate is applied to the converted Markov chain to convert it into a Markov reward model. Compute the availability of software based on the Markov reward model. Therefore, the prior art can verify the non-functional elements of the software at the development stage of the software, thereby increasing the development efficiency of the software.

The preceding document is a device that verifies the function of the software and does not include means for verifying whether the software is running or not. In addition, existing processes are constrained to visually represent time and space requirements in expressing the containment relationships, movement, and interaction of processes. Therefore, a device capable of visually verifying the time and space of a process is required.

Korean Patent No. 10-1038849 (a recording medium on which software verification methods and software verification methods are recorded, registered on May 27, 2011)

The present invention provides a process detection apparatus capable of visualizing a specification of a process to solve the above problems and capable of detecting an error generated when a process is executed by simulating the number of cases in which a visualized process can be executed. .

It is also an object of the present invention to provide a process detection apparatus capable of verifying requirements of a process through a verification symbol capable of expressing requirements such as dependency relations between processes in time and space.

The present invention is characterized in that at least one formal specification is defined in order to specify a process required for a software design, and a specification storage storing a visualized model corresponding to the defined formal specification, a specific formal specification inputted to specify a specific process A specification display unit for visually displaying a specific model corresponding to the specific formal specification in comparison with the stored visualized model, a model display unit for simulating the number of all cases in which the specific process is executable through a specific model visualized by the specific model, An error display unit for visually displaying the number of cases in which the execution of the specific process is stopped through the diagrammed result, an inclusion relation between the processes, a priority of the process The execution order of the process, the period and the phase of the process A signature generation unit for generating a verification symbol for defining a requirement of a process including at least one of the states of a process, a number of mock-up cases based on a time table, And a block identifying unit for identifying a specific verification key corresponding to a requirement of the identified specific process and identifying the specific verification key corresponding to the identified requirement of the specific process, And a specification verifying unit for verifying whether a specific verification symbol displayed on the block meets a requirement defined in the symbol generating unit.

The present invention has the effect of increasing the stability of the process by visualizing the specification of the process, detecting errors occurring in the execution of the process by simulating the number of all cases in which the visualized process is executable.

The present invention also has the effect of visually verifying the requirements of the process by verifying the requirements of the process through a verification symbol that can represent the requirements in time and space, such as dependencies between processes.

1 is a block diagram for explaining a process verification apparatus according to the present invention.
Figure 2 is one embodiment of a visually represented process in accordance with the present invention.
Figure 3 is one embodiment that visually shows the number of all possible cases where the process according to the present invention is executable.
4 is a table showing verification symbols according to the present invention.
5 is a view for explaining the display of verification symbols according to the present invention.
6 is an embodiment for explaining the requirement verification of a process through a verification symbol according to the present invention.
7 is yet another embodiment for explaining the requirement verification of a process through a verification symbol according to the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail.

1 is a block diagram for explaining a process verification apparatus according to the present invention. The process verification apparatus includes a specification storage unit 100, a specification display unit 200, a simulation calculation unit 300, an error display unit 400, a symbol generation unit 500, a block generation unit 600, a symbol identification unit 700, A symbol display unit 800, and a specification verification unit 900. [

[Process visualization]

The specification storage unit 100 defines at least one formal specification for specifying a process to be executed in the software prior to developing the software. A formal specification defines a user's requirements and is a documented list in a language for specifying system requirements. A formal specification can be defined as a technique that uses mathematical notation to describe the characteristics and functions of the system in which the software or hardware is included, and to prove proofs. (See: Techniques for Improving Software Reliability, Sungshin Women's University)

Thus, a formal specification is a formal language that is defined to design the fields of use, characteristics, and functions for which the software will be used. The formal specification allows specification of communication among processes, data movement, priority order of processes, and the order in which processes are executed.

The specification storage unit 100 stores the defined formal specification as a visualized model. A visualized model can include a system formal specification to represent the entire system and a process formal specification to represent the processes running in the system. Through the system formal specification, it is possible to express the process, the channel of the process, the movement of the process, etc. Through the process formal specification, it is possible to express the start, end, move request, transfer permission, and process generation of the process.

The specification display unit 200 is a device that compares at least one specific formal specification inputted to specify a specific process with the stored visualized model and displays the specific model corresponding to the specified formal specification in order of movement. The specification display unit 200 expresses the interaction between processes as one system, and expresses at least one of execution, communication, and movement of each process in a visualized model.

2 is an embodiment of a process in which the specification display unit 200 is visually represented. Referring to FIG. 2, five processes P, B, C, R1, and R2 in the inputted formal specification are visualized. For example, in the case of R1, the formal specification of Pput.Bget.Bput.Cget.exit is input. Thus, the first model of R1 is a formal specification that implies a request to move P. The second model is a formal specification that allows B's to be moved. As described above, the model corresponding to each formal specification is stored in the specification storage unit 100, and the specification display unit 200 displays the specific model corresponding to the inputted specification in moving order.

[Process simulation calculation and error detection]

The simulation calculation unit 300 simulates the number of all cases in which the specific process is executable through a specific model visually displayed on the specification display unit 200. [ In addition, the number of simulated cases is displayed and displayed. Figure 3 shows the number of cases for the particular model shown in Figure 2 visually. Referring to FIG. 3, it can be seen that the total number of 18 cases from S1 to S18 is schematized.

The error display unit 400 visually displays the number of cases in which the execution of the specific process is stopped through the schematicized result. In the case of FIG. 3, it can be confirmed that an error occurs in the case of S9 and S10, as the number of cases in which a total of six processes are executed. As described above, by detecting the case where the error display unit 400 can be generated when the process is executed, it is possible to eliminate an error generated in the software.

[Generate verification symbol]

The symbol generator 500 generates a verification symbol for defining the requirements of the process including the inter-process inclusion relation, the priority of the process, the execution order of the process, the interval of the process, and the state of the process.

Figure 4 shows a verification symbol according to the invention.

Referring to FIG. 4, 1-1 in relation to the Geo-graphical Requirements means that Processes A and B can include each other. Hereinafter, the process A is abbreviated as 'A' and the process B is simply referred to as 'B'. 1-2 can move A into B, but B can not move to A. 1-3, A can not move to B, but B can move to A. 1-4, A and B can not move inside each other. 1-5, B is always inside A. 1-6, A is always inside B.

In relation to the Temporal Requirements, 2-1 a action always occurs before b action. 2-2 is a b action after a action. 2-3, a and b always operate in parallel. 2-4 should not cause the execution of a and b to occur simultaneously in the same time and space.

In relation to the interval, 3-1 specifies the interval for the action, and it can be set as to whether the contained actions in the specification process satisfy certain restrictions in the process of execution. 3-2 is a time and space target, and means that the section is fixed and not moved.

In relation to Condition, 4 can specify constraints for a specific process or interval, and various detailed conditions can be specified.

[Process verification]

The block generator 600 blocks and lists each of the numbers of mock computed based on the time table as an action related to communication, movement, execution, and interaction of a specific process. The symbol identification unit 700 identifies the requirements of a specific process and identifies specific verification symbols corresponding to the requirements of the identified specific process. The requirements of the process are entered by the creator designing the process. For example, a requirement for space such as 'Process A is in Process B' can be entered, as well as a time requirement such as 'All actions in Process C and D run simultaneously'. The symbol display unit (800) displays the identified specific verification symbols on the blocks listed. Each requirement entered by the producer is represented by a correlation between the blocks. Therefore, the symbol display unit 800 displays a verification symbol corresponding to the requirement on the blocks listed according to the requirements expressed by the relationship between the blocks.

5 is a view for explaining the display of verification symbols according to the present invention. Referring to FIG. 5, one of the numbers in the case of mock calculations based on a time table of 0 to 250 is listed in block form. The time is set by the manufacturer, such as seconds, minutes, and times defined in the software.

Referring to FIG. 5, there are four processes A, B, C, and D, and B1, C1, C2, D1, D2, and D3 block the actions related to communication, movement, execution, . Process B is included in Process A.

On the other hand, the requirements of the process input by the manufacturer are as follows. R1 is in process B space in all time intervals. R2 is preceded by c1 in Process C, and b1 in Process B precedes c1 in Process C. R3 executes all actions of In2 and all actions of In3 of D concurrently. The sum of execution times for all actions of In4 present in D must be less than 100. R5 can not move into A within the In1 interval of A. R6 must complete all actions of D within 600.

The symbol identification unit 700 identifies the verification symbols of the requirements R1 to R6 of the input process, and the symbol display unit 800 displays the identified verification symbols according to the correlation between the blocks.

The specification verification unit 900 confirms whether the specific verification symbol displayed on the block satisfies the requirement defined in the symbol generation unit 500. [ Figs. 6 to 7 are diagrams for explaining requirements satisfaction.

Referring to FIG. 6, the processes A, B, C, and D are visually represented, and the interactions of the processes a 1 to a 5 are represented. Requirement R1 of the process must always occur before the action of B2. R2 can not be moved to process D, and process D can not be moved to process A. In addition, it can be confirmed that the action of D1 is always generated earlier than B2, and the processes D and A are not included in each other. Therefore, the specification verification unit 900 determines that the specific symbols R1 and R2 displayed on the block satisfy the requirements 2-1 and 1-4 defined in the symbol generation unit 500.

On the other hand, referring to FIG. 7, it can be confirmed that although the action of D1 is generated before B2, the action of D1 is not always generated first. Therefore, the specification verification unit 900 determines that the specific symbol R1 displayed on the block is different from the defined requirement 2-1. In addition, the specification verification unit 900 visually expresses a verification symbol different from the requirement defined in the symbol generation unit 500 so that it can be identified. For example, a normal verification symbol may be represented as blue, and a different verification symbol may be represented as red.

100: specification storage unit 200: specification display unit
300: simulation calculation unit 400: error display unit
500: symbol generator 600: block generator
700: Symbol identification part 800: Symbol display part
900: Specification verification unit

Claims

A specification storage unit in which at least one formal specification is defined to specify a process required for software design, and a visualized model corresponding to the defined formal specification is stored;
A specification display unit for visually displaying a specific model corresponding to the specific formal specification by comparing the inputted specific formal specification with the stored visualized model to specify a specific process;
A simulator for simulating the number of cases in which the specific process is executable through a specific model visualized by the specific model, and for simulating the number of simulated cases;
A block generation unit which blocks each of the numbers of the simulated cases on the basis of a time table by an action related to communication, movement, execution and interaction of the specific process;
A symbol identification unit for identifying a requirement of the specific process and identifying a specific verification symbol corresponding to the requirement of the identified specific process;
A symbol display unit for displaying the identified specific verification symbols on the listed blocks; And
And a specification verification unit that verifies whether a specific verification symbol displayed on the block satisfies a requirement defined in the symbol generation unit.

The method according to claim 1,
And an error display unit for visually displaying the number of cases in which the execution of the specific process is stopped through the schematic result.

The method according to claim 1,
A symbol generator for generating a verification symbol for defining a requirement of a process including at least one of an inclusion relation among the processes, a priority of the process, an execution order of the process, a duration of the process, And a process verification device using time-space logic.

delete