JPH11102291A - Specification consistency certification system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To certify the consistency of mutual detailed design specifications described by different logic models. SOLUTION: A consistency check function 105 for specifications traces the detailed correspondence of specifications between Views at an upstream level so as to map it onto the specification between Views at a downstream level. The pair of specifications made correspondent like this is checked in consistency based on the rules of consistency between Views stored in View relation information 102.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system for verifying the correctness of control software and man-machine software such as an FA system, a thermal power plant, a nuclear power plant, and a network information control system, and more particularly to the verification of the mutual compatibility of specifications. .

[0002]

2. Description of the Related Art As a conventional technique, specification information is extracted from a program and a module specification and stored in an integrated DB, and when one is changed, information on a change result is extracted and stored in the other. There is a technique for maintaining the consistency of specifications by reverse generation using the integrated DB that has been made (software development system: Japanese Patent No. 2606356). Also, a technique for determining whether the state transition relationship is correctly detailed between an upstream specification and a downstream specification (specification verification method:
Japanese Patent Application Laid-Open No. Hei 6-282423) and a technique for checking the consistency with an actual program by storing design information by focusing on an interface for calling a program (Interface inspection apparatus: Japanese Patent No. 2560545).

[0003]

In the above-mentioned prior art, it is possible to check the consistency between the specifications of upstream and downstream on a single logical model, such as a state transition relationship, or to provide the same level of detail. It was possible to match the contents when the specifications of the same content in were scattered in the design document, but when the specifications of the same content were sequentially detailed on different logical models, Efficiently verify the reconciliation of refined specifications, or maintain the consistency of a specification modification at a certain level of a logical model between different logical models Was difficult.

[0004]

SUMMARY OF THE INVENTION An object of the present invention is to store a view refinement rule for judging, for each view, whether or not a plurality of views, which are a logical framework for describing specifications, have been correctly refined. Refinement rule D
B, a View related information DB that stores the view related information that defines the relationship between the views and the view, and a view definition support mechanism that supports the definition of these data, according to the defined logical framework of each view. The system comprises a specification input support mechanism for supporting the input of specifications, a specification storage DB for storing the input specifications, and a consistency check mechanism for checking the consistency of the generated specifications.

[0005]

BEST MODE FOR CARRYING OUT THE INVENTION
Used to define the logical model and refinement rules for iew. The specification input support function uses the logical model of a plurality of views and the relation information of the views to specify the specification and the V
It is used to support input of the correspondence of specifications between iew. Once the specification mapping between views is defined in the upstream specification, for each view, the consistency check function refers to the detail rules for each view, and is the detail refinement performed correctly? While checking, the specification is defined by the specification input support function and stored in the specification storage DB.

[0006] The specification consistency check mechanism compares the specifications between the views at the upstream level with each VIE.
By mapping the detailing within the iew, mapping is performed to the correspondence of specifications between the downstream views. The set of specifications associated in this manner is checked for consistency by the consistency rules between views contained in the view related information. As a result, it is possible to easily check the consistency of the specifications between the downstream views only by associating the specifications between the upstream views.

An embodiment of the present invention will be described below with reference to FIG. The specification input and verification system is composed of three DBs: a view detailing rule DB, a view related information DB, and a specification storage DB, and three functions: a view definition support function, a consistency check function, and a specification input support function. The following describes how specifications are defined by this specification input and verification system and checks for inconsistencies between specifications are performed, taking as an example the design of clock matching processing in a large-scale / distributed system. FIG. 6 shows a hardware configuration of the system to be designed.

This system is a system for controlling and monitoring semi-automatic operation such as an FA system, which is a general management system for managing the entire system, a driving support system for supporting the operation of individual devices in the FA system, and a state of the entire system. The system consists of a monitoring device and a standard clock of the system. In this system, each device is physically dispersed, and each realizes the function of the system with its own clock. In such a system, it is necessary to synchronize the clocks of the respective devices at the time of startup and periodically.

FIG. 2 describes the uppermost specification of the matching processing in a general data flow model.
In the data flow model, processing is described as a flow of data flowing between devices. The matching process is started periodically when a system initialization request requests initialization of the integrated management device or when the clock of the central management device indicates a certain time. At that time, as shown in FIG. 2, first, the supervisory device transmits a time request to the standard clock. Then, from the standard clock, the matching time is returned to the supervising device. When the centralized management device receives the coincidence time, the time is transmitted to the subordinate device, and the clocks of the entire system are synchronized. However, here, the correction of the time lag due to the communication time is omitted to simplify the description.

By the way, a data flow diagram as shown in FIG. 2 is good for grasping between which hardware data flows, but it is also necessary to grasp in what order and how data flows. Hateful. From that perspective,
To describe the specification, a state transition diagram as shown in FIG. 3 is usually used to supplement the point. The state transition diagram describes how the state of the system changes with the occurrence of an event. The system is characterized by an event that occurs, an event that causes a transition, and a transition destination for each state.

In the example of FIG. 3, during initialization, during acquisition of standard time,
The three states of steady operation are described in a circle.
The transition for each state is indicated by an arrow, and the name of the transition event is described near the arrow. For example, the initializing state is caused by a transition event named “initialization”, and when an event “standard time acquisition request” occurs in the initializing state, the state transits to the standard time acquiring state.

There are various variations in such a state transition diagram, and a state chart (D. Harel, Stat.
echarts: A visual formalism for complex system
s ", Science of Computer Programming", Vol.
8, pp. 231-274, 1987) is also a kind of state transition diagram. These data flow diagrams and state transition diagrams can be considered as logical models each describing one aspect of the specification.

In the following, such a logical model is referred to as Vie
Let's call it w. The specifications are refined on each view to finally complete the design of the system including the software. FIG. 4 is a detailed diagram of the data flow diagram of FIG. 2, and FIG. 5 is a detailed diagram of the state transition diagram of FIG. Techniques for determining whether these refinements have been correctly performed for each view are known in the art. For example, for the state transition view, there is (specification verification method: Japanese Patent Application Laid-Open No. 6-282423).

In general, a detailed state is associated with an event causing a transition, and if the order of occurrence of events as a result of the refinement is the same as the order of occurrence in the corresponding original specification to be refined. Can be considered correctly refined. Also, the view of the data flow is based on Hoare Logic (), which assumes that detailing has been correctly performed when the range of the input is wider than before the detail and the range of the output data is narrower than before the detail. It is common sense to make a judgment.

However, there are various ways to determine the width and narrowness of the data range. Such individual V
The rule for determining whether iew has been correctly refined is stored in advance in the View refinement rule DB of FIG.
FIG. 7 is an example of the detail rules of the data View and the state transition View stored in the detail rule DB. The rules are
It is defined as a condition relating to a block and an input / output relationship which are two elements of the data flow model. For this purpose, the following words are defined as reserved words.

(P1) Spec_DF: A set of specifications described in a data flow diagram.

(P2) Block: In the data flow diagram,
The source or source of the data.

(P3) DataFlow: Data flow in the data flow diagram.

(P4) Output_from: Block-> P (Dat
aFlow). A function that takes a block in the data flow diagram as input and outputs a set of DataFlow with the block as the source. Here, P (DataFlow) indicates a set of subsets of DataFlow, and Block-> P (DataFlow) indicates Blo
Indicates that this is a function from ck to a subset of DataFlow. (P5) Output_from +: P (Block)-> P (DataFlo
w). DataFl with a subset of blocks in the dataflow diagram as input and a subset of that block as source
Function that outputs a set of ow.

(P6) Input_to: Block-> P (DataFl
ow). A function that takes a block in the data flow diagram as input and outputs a set of DataFlow with the block as the destination.

(P7) Input_to +: P (Block)-> P
(DataFlow). DataFl with a subset of blocks in the data flow diagram as input and the block as destination
Function that outputs a set of ow.

(P8) Input: DataFlow-> Block. A function that returns the block from which the data flow is output.

(P9) Input +: DataFlow-> P (Bloc
k). Function that returns a subset of the blocks from which the data flow is output.

(P10) Output: DataFlow → Bloc
k. Function that returns the block to which the data flow is input.

(P11) Output +: DataFlow-> P (B
lock). A function that returns a subset of the block into which the data flow is input.

(P12) conn: Block * Block-> bool.
If a block is connected by a flow, tr
ue, a function that returns false if not bound.

(P13) conn +: P (Block) * P (Block)
-> Bool. A function that returns true if a subset of a block and a subset of blocks are combined in a flow, otherwise returns false.

(P14) refine_DF: Spec_DF * Spec
_DF-> bool. Function that returns true if the specification described in the data flow is correctly detailed, and false otherwise. (P15) refine_DF1: P (Block) * Block-> boo
l. A function that returns true if a subset of Block correctly refines Block, false otherwise.

(P16) refine_DF2: Block * Block
-> Bool. T if Block correctly refines Block
rue, a function that returns false otherwise.

(P17) refine_DF3: DataFlow * Da
taflow-> bool. If DataFlow is correctly detailed
A function that returns true, false otherwise.

(P18) in_DF: Block or P (Block)
* Spec. In the specifications described in the data flow diagram,
A relationship that indicates that a block or a subset of blocks is described in its specification.

There are three examples from (DR0) to (DR3) in which the rules for whether or not the detail of the data flow View has been correctly written are described using these reserved words. In order to determine whether or not the detailing has been correctly performed, functions conn and conn + for determining whether or not the detailing blocks are connected to each other are used. The rules for the determination are (C1) and (C2). It is.

(DR1) is that because the specification SpecA described in the view of the data flow correctly refines SpecB, all the blocks of SpecA are B with SpecB.
The lock is detailed, and the set PA of the block with SpecA corresponds to the block of all SpecB, and P
It describes that it is necessary and sufficient for A to refine the set of SpecB.

(DR2) is Blo of the data flow View.
For ckA to correctly refine BlockB, Blo
B where all the inputs to ckA refine the inputs of one BlockB and all the outputs from BlockA
It defines that it is necessary and sufficient to detail the output of lockB.

(DR2) is that the block PA1 of the specification SpecA described in the data flow View correctly details the block B1 with the specification SpecB in order for the input InPA1 to all the PAs to be in detail. If there is an input InB1 of a certain Block B and the output source of InPA1 is a subset PA2 of a certain SpecA, PA2
Is a detail of Block B2, which is a block of SpecB, and the output source of InB1 is Block B2.
B2, and input InP to all PAs
A block B has an input InB1 for A1 and I
When the output source of nPA1 is a subset PA2 of a certain SpecA, PA2 is a block Bblock which is a certain block of SpecB.
B2 is correctly detailed, and the output source of InB1 is BlockB2, and the output OutB1 of BlockB for the output OutPA1 from all PAs
Exists, and when the input destination of OutPA1 is a subset PA2 of a certain SpecA, PA2 is a detail of SpecB2, which is a block of SpecB, and the output destination of OutB1 is BlockB2. Moreover,
BlockB for input InPA1 to all PAs
Is present, and the output source of InPA1 is a subset PA2 of some SpecA, PA2 is
BlockB2, which is a block having a block, is correctly refined, the output source of InB1 is BlockB2, and the input and output are connected as if they were realized in one block inside the refined block. State that it is necessary and sufficient.

Here, the input / output of a subset of blocks means a data flow flowing outside the subset of blocks, and an example is shown in FIG. FIG. 8 shows blocks A11 to A34 as block subsets PA1, PA2, PA3.
It is classified and expressed. At this time, the input flows of the block subset PA1 are F01 and F02, and the output flows are F21, F22, FF12, and FF2.
2, and the internal flows F11, FF11, etc. are neither input flows nor output flows. In addition, the value of the destination or source for F01 or F33 in which the destination or source is not specified is unknown. In the example of FIG. 8, Input (F
01) = output (F33) = unkonwn. FIG.
The rule (FD-1) is a rule for determining whether or not blocks are connected to each other, and the rule (FD-2) is a function for determining whether or not subsets of blocks are connected to each other.

The premise of this detailing rule is that each block is associated with a subset of the corresponding block, and for a data flow, which data flow corresponds to the original data flow. That is, the correspondence has already been made in the detailed specification. That is, the conditions for the determination in (DR1) and the subset of blocks to be selected in DR2 are defined. However, this rule of refinement is only an example, and it checks whether the refinement of the data flow has been performed correctly. It is not completely guaranteed. For these verifications, a model that describes the format and contents of data may be added to the data flow model, and a refinement rule may be added.

On the other hand, many methods have been proposed for judging whether the detail of the state transition view has been correctly performed. Here, the same format as the validity verification rule of the detail of the view of the data flow is used. The following reserved words are defined to describe the rules.

(P1) Spec_ST: a set of specifications described in the state transition diagram.

(P2) State: The state of the system in the state transition diagram.

(P3) Transaction: Transition relation between States in the state transition diagram.

(P4) comefrom: State-> P (Transiti
on). The state in the state transition diagram is input and its Sta.
Function that outputs a set of transitions from te.

(P5) comefrom +: P (State)-> P (Da
taFlow). A function that receives a set of states in the state transition diagram as input and outputs a set of transitions from the states.

(P6) into: State-> P (Transitio
n). Inputs State in the state transition diagram,
A function that outputs a set of Transactions whose transition destination is e.

(P7) into +: P (State)-> P (Transi
tion). The set of State in the state transition diagram is input and
A function that outputs a set of Transactions whose transition destination is the State.

(P8) Transactions: Transition-> Bloc
k. A function that returns the state of the transition source for a transaction.

(P9) Transfrom +: Transaction-> P
(Block). For the Transition, the State of the transition source
A function that returns a set of

(P10) transto: Transition → Stat
e. A function that returns the State of the transition destination for a Transaction.

(P11) transto +: Transaction-> P
(State). For the Transition, the State of the transition destination
A function that returns a set of

(P12) reachable: State * State-> b
ool. A function that returns true if a State is reachable from a State by a transition, false otherwise.

(P13) reachable +: P (State) * P (S
tate)-> bool. A function that returns true if a subset of State is reachable by a Transaction from a subset of State, and false otherwise.

(P14) refine_ST: Spec_ST * Spec
_ST-> bool. A function that returns true if the specification described in the state transition diagram is correctly detailed, and returns false otherwise.

(P15) refine_ST1: P (State) * St
ate-> bool. A function that returns true if the set of States correctly refines State, otherwise returns false.

(P16) refine_ST2: State * State
-> Bool. T if the State correctly refines the State
rue, a function that returns false otherwise.

(P17) refine_ST3: Transaction * T
ransition-> bool. A function that returns true if the Transaction is correctly refined, false otherwise.

(P18) in_ST: State or P (State)
* Spec. In the specifications described in the data flow diagram,
A relationship that indicates that a block or a subset of blocks is described in its specification.

FIG. 9 shows rules for verifying the validity of the detailed relation of the state transition diagram using these reserved words. These relationships are basically isomorphic in some sense to the rules for verifying the validity of data flow diagrams. That is, the rules from DF1 to DF3 in FIG.
The rules up to T3 can be regarded as the same as associating Block in the data flow diagram with State in the state transition diagram, and associating the data flow in the data flow diagram with Transaction in the state transition diagram. However, while the data flow diagram defines the correctness of the detailing by characterizing the interlocking of the data with conn in SR0 and SR1 in FIG. 7 from the viewpoint of the reciprocity of data, the state transition diagram , State to State
Is defined from C1 and C2 in FIG. 9 and used as a criterion for the correctness of the refinement.

It is a conventional technique to determine whether or not the refinement has been correctly performed on each of these models. However, it is an object of the present invention to ensure mutual consistency when refinement is performed with different models, such as a data flow view and a state transition view. Means for realizing this in accordance with the present invention will be described sequentially for a case where specifications are described by a data flow and a view of state transition according to a design procedure.

First, when a specification is described by a data flow and a state transition, a rule for obtaining consistency between the two models is described in the View related information DB. Some related information includes
(1) Description items and (2) correspondence are described.
(1) A description item defines an item for defining a specification for each view. For example, what is described as information accompanying a transition in the same state transition model depends on a target problem. . In this example, data contents, event types, and transition conditions are added as accompanying information. Then, the content of the data is classified into a time and a request signal. On the other hand, in the data flow model, at the initial stage of data design, data contents are described as information accompanying the data flow.

According to the description of FIG. 11, the data flow is:
It consists of a name and data contents (here, +
The data content indicates a time or a request. Since the data contents are common even between two different models, the information related to the data contents and the data flow V
In this way, it can be managed that the information on the contents of data accompanying the data flow in iew is of the same type.

FIGS. 2 and 3 show such a view.
This is an example in which the upstream specifications are described in accordance with the description items defined in the related information. In addition, the common data contents described in the two views are designated, and the specification input support function of FIG. It is stored in the View related information DB. For example, FIG. 11 shows the contents of data accompanying the transition from the state during acquisition of the standard time in the Spec_ST1 of FIG. 3 to the state of the steady operation from the supervising device in the specification described in the data flow format in FIG. Defines that it matches the data content of the data flow to the subordinate device.

Design refinement is performed by refining each view. Spec_DF2 described in FIG. 4 is a detail of the view of the data flow. By setting which block has been refined which block and which data flow has refined which data flow at the time of refinement, the data flow is correctly refined using the refinement rule defined in FIG. Can be determined. Such a definition can be executed using the graphic I / F of the specification input support function. FIG. 11 illustrates such an association, in which the subordinate device of Spec_DF1 is Spec_DF1.
In FIG. 2, the details are divided into three: a driving support device, a monitoring device, and an information control device, and correspondingly, the data flow entering and exiting from the subordinate device of Spec_DF1 is detailed. This association is performed by the refinement rule DR1 in FIG.
10 is set in the View related information DB.
Is stored as follows. In addition, driving support equipment, monitoring equipment,
Since it is defined that three of the information control devices refine the subordinate devices, Check {driving support device, monitoring device, and information control device are stored in the View related information DB as data to be subjected to DR2 determination in FIG. $ Refine_DF1 subordinate device is stored.

When this content is verified by the refinement rule shown in FIG. 7, it is found that there is no flow returning from the driving support device, the monitoring device, and the information control device to the supervising device in the higher-level Spec_DF1. Therefore, in this case, on the contrary, the upper specification Spe
c_DF1 will be changed to Spec_DF1 'in FIG. As a result of this change, the refinement is verified by the refinement rule in FIG.

On the other hand, on the state transition diagram, Spec__ in FIG.
When ST1 details to Spec_ST2, the correspondence is made as shown in FIG. Here, the steady operation is a driving support device,
As shown in FIG. 10, the correspondence between the monitoring device, the standard time setting, and the steady operation is described in the View related information DB. Medium, steady operation｝ refine_
ST1 Stored as normal operation. Stored specifications Spec_
Whether or not ST2 correctly refines SpecST1 can be checked and confirmed according to the rules of FIG.

As described above, verifying that the specifications described on a single logical model such as a data flow and a state transition are correctly detailed is performed by using the view shown in FIG.
This is possible even without the mutual related information, especially the information of the corresponding contents of (2) in FIG. A feature of the present invention is that a rule for confirming the validity of the refinement in each logical model (the refinement rule in FIGS. 7 and 9) is associated with a specification in each logical model (( In addition to the information of (3), the correspondence between specifications described in another model described in (2) of FIG. 10 and the consistency of specifications between different models shown in FIG. The detailing correspondence within the view (in the same logical model) described in (3) of FIG. 10 and the rules for checking the correspondence between the views described in (2) of FIG. It is to verify using.

In the rule of FIG. 14, a certain description item (for example, data content) in a component of Spec1 (for example, DataFlow from the general control device to a subordinate device in the data flow diagram in FIG. 2) is replaced by a component of Spec2 (for example, data content). For example, FIG.
In the state transition diagram in FIG. 10, if a certain description item (for example, data content) in the transition from the acquisition of the standard time to the steady operation state matches, it is described in “(2) Corresponding content” of the view related information in FIG. 10. The detailed description of each of the constituent elements also indicates that they need to match from the viewpoint of the equivalence of the description items (for example, the equivalence of data contents). Here, the refine is defined as refine_ST1, refine_DF1, refine_
It is a relation of detailing including everything such as DF2.
ST and in_DF are included.

The equivalence is defined for each description item. For example, the equivalence of the data contents is defined as that the contained data contents match. With these newly added data and refinement rules,
For example, the data flow diagram and the state transition diagram are correctly detailed in each view as shown in FIGS. 12 (Spec_DF1 ') and 3 (Spec_ST1), FIG. 15 (Spec_DF3) and FIG. 5 (Spec_ST2). Even if it is
It can be found that the relationship is not correctly detailed. Spec_DF3 (FIG. 15) and Spec
The difference between DF2 (Fig. 4) is that, from the central management device to the monitoring device,
By sending the allowable range of the time error, it is intended to judge a failure based on this.

As shown in FIG. 16, the correspondence between the specification and the original specification is almost the same as that in FIG. Also, because the new data flow name and the matching time 'have been added to the specification, the view-related information is almost the same as that described in FIG. 10, and Spec_DF1 in (2) corresponding contents in FIG.
It only changes to pec_DF1 '. The fact that each is correctly refined and determined in accordance with the detailing rule in each view can be explained in the same manner as described above. On the other hand, when the consistency check function of FIG. 1 performs a check in accordance with the rule of FIG. 14, it is described in the View related information DB that the transition from the acquisition of the standard time of the Spec_ST1 to the normal operation is detailed.
During the acquisition of standard time during T2, ① driving support equipment, monitoring equipment,
The data content of the transition of each transition 3ts during the standard time setting of the information control device must match the data content of the data flow of the Spec_DT3 from the supervisory device to the {operation support, monitoring, and information control} devices. is there. However, while the data content of Spec_ST2 consists only of time,
The data content of c_ST3 does not match because it is composed of the time and the allowable error range.

Such inconsistency in specifications can cause an accident at the time of later programming or system modification. Therefore, for example, an inconsistency between two specifications and an ID of an unsatisfied condition in the View related information DB (T1 in this case) are displayed on a display screen as shown in FIG. Eventually, consistency can be obtained by adding an error tolerance to the data content of the additional information of transition from during acquisition of Spec_ST2 to standard time to the monitoring device.

Further, in the present embodiment, the description has been made in accordance with the design process in which the specifications are gradually refined from the upstream. However, even when a part of the existing specifications is changed, FIG.
It is obvious that the consistency of the specifications of different models can be checked by the same method only by re-associating the view refinement rule and the refinement with each other. Also, in associating the details of the specification,
The corresponding specification part and the corresponding part are selected and corresponded to the graphical editing method of the specification on the computer screen, which exists as a conventional technique as shown in FIG. By using the specification input support with the function of storing in the View related information DB of FIG. 1, data for verifying specification consistency can be input even more easily. In order to input information for defining the relevance of specifications between different views, such as the description items (1) in FIG. 10 and the corresponding contents in (2) in FIG. If the input is supported by a view definition support function to which the prior art is applied, such as a question answer with a given keyword, the view can be more easily defined. FIG. 18 shows an example of such a view, the names of the views, the objects constituting the views, the names of the relations defining the relationships between the objects, and the views corresponding to FIGS. 7 and 9.
According to the menu, a relational expression of detailing for each item and information related to another view corresponding to the corresponding content of (2) in FIG. 10 are input.

[0071]

As described above, according to the present invention, it is possible to provide a water supply control system in which a change in the configuration of the water supply system does not affect the water level fluctuation.

[Brief description of the drawings]

FIG. 1 is a system configuration diagram showing an embodiment of the present invention.

FIG. 2 is a diagram showing an example of an upstream specification described in a data flow.

FIG. 3 is a diagram showing an example of an upstream specification described in a state transition diagram.

FIG. 4 is a diagram showing an example of a detailed specification described in a data flow.

FIG. 5 is a diagram showing an example of a detailed specification described in a state transition diagram.

FIG. 6 is a diagram showing an example of a system configuration to be designed.

FIG. 7 is a diagram showing an example of a data flow detailing rule.

FIG. 8 is an explanatory diagram of a method of handling a group of blocks in a data flow.

FIG. 9 is a diagram showing an example of a state transition detailing rule.

FIG. 10 is a diagram showing an example of View related information indicating one embodiment of the present invention.

FIG. 11 is a correspondence diagram of detailing in a data flow diagram showing an embodiment of the present invention.

FIG. 12 is a diagram showing an example of an upstream specification described in a data flow modified by a conventional method.

FIG. 13 is a correspondence diagram of detailing in a state transition diagram showing an embodiment of the present invention.

FIG. 14 is a diagram showing an example of a rule for verifying consistency between views according to an embodiment of the present invention.

FIG. 15 is an example of a detailed data flow diagram illustrating one embodiment of the present invention.

FIG. 16 is a correspondence diagram of a detailed data flow diagram showing an embodiment of the present invention.

FIG. 17 is a diagram illustrating an example of a display screen that displays specification inconsistency according to an embodiment of the present invention.

FIG. 18 is a diagram illustrating an example of a display screen of a view definition support function according to an embodiment of the present invention.

[Explanation of symbols]

101: View detail rule DB, 102: View related information DB, 103: Specification storage DB, 104: View definition support function, 105: Consistency check function, 106: Specification input support function.

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Toshihiko Nakano 5-2-1 Omikacho, Hitachi City, Ibaraki Prefecture Inside the Omika Plant of Hitachi, Ltd. (72) Inventor Toshiaki Higashihara 5-chome Omikacho, Hitachi City, Ibaraki Prefecture No. 1 Inside the Omika Plant of Hitachi, Ltd.

Claims (4)

[Claims] In a specification description system in which specifications are described by a plurality of logical models such as a data flow model, a process model, and a hardware connection model, an association between logical models is defined by defining each logical model. A specification consistency verification system that verifies the compatibility of specifications described on a model. 2. A specification for describing specifications by a plurality of logical models such as a data flow model, a process model, and a model of a hardware connection relation, and checking the validity of the refinement defined by each logical model. In a specification description system that proceeds with the design while checking that the specification has been correctly refined using conditions, by defining the association between the logical models, the specification Specification integrity verification system that verifies the integrity of a specification. 3. A specification for describing a specification by a plurality of logical models such as a data flow model, a process model, and a model of a hardware connection relationship, and checking the validity of the refinement defined by each logical model. In a specification description system that has a function to check that specification refinement has been performed correctly using conditions, design of each logical model at any level of refinement by defining the association between logical models A specification consistency verification system characterized by presenting the parts of the specification that may need to be changed in response to the change, and indicating that if the specifications cannot be maintained if they are left untouched, this fact is indicated. . 4. A specification for describing specifications by a plurality of logical models such as a data flow model, a process model, and a model of a hardware connection relationship, and checking the validity of the refinement defined by each logical model. In a specification description system that proceeds with the design while checking that the specification has been correctly refined using conditions, by defining the association between the logical models, the specification A specification consistency verification system that verifies the consistency of specifications using two correspondences: a partial correspondence between specifications on the same logical model at the time of detailing, and a correspondence between logical models.