JPH08286901A - Reutilizing system for software parts - Google Patents

Abstract

PURPOSE: To reutilize components even when the intention of a design information preparing person is different from the purpose of utilization and to efficiently retrieve desired design information and its respective parts by retrieving and extracting parts while confirming a hierarchical state and reutilizing these parts for designing a software. CONSTITUTION: A main body 3 of a device is composed of a design information managing part 4 and a design information constructing part 5. As the component of the information managing part 4, a part storage part 9 stores the various kinds of parts of software design information such as existent software design information or standard parts partially extracted out of that information while considering versatility or reutilizability. These kinds of software design information registered in the storage part 9 are called software parts later to be distinguished from software design information under developing. A software developer selects reutilizable software parts among those software parts through a part retrieval part 6, fetches them into the software design information under developing by using a design part 10 and utilizes them.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software component reuse system for reusing software design and its design information.

[0002]

2. Description of the Related Art When creating software (application software), first, software design information is constructed, and the software is constructed in accordance with this. Conventionally, various innovations have been made by reusing programs (components) that make up this design information, but there are roughly two approaches to this approach. First, there is a form in which a standard reusable component is created in advance and this is used when creating individual software. Next, as a second method, from the design information that was already used when creating the software, select the part that the reuser could reuse, customize it as necessary, and use it. is there.

[0003]

Since the conventional method has been as described above, there have been the following problems. First, in the above-described first embodiment, a standard component called a library is created in advance, but there is a problem that this specification and usage do not match the purpose of use when reusing. In other words, there is always some difference between the specifications at the time of library creation and the purpose of use at the time of reuse, and it is a problem that it takes time to understand the usage and specifications.

When the library prepared in advance is relatively general-purpose for numerical calculation and has a small scale, the above-mentioned problem does not occur much. For example, software design for an application program for a process controller is performed. When it comes to large specialized information such as information, its contents are complicated and difficult to understand. Further, it takes time and effort to customize and use, and there are problems such as unexpected bugs occurring due to customization.

On the other hand, in the second embodiment, when reusing, only the parts that match the purpose of use are selected from the parts constituting the existing design information and used, and the entire original software design information is used. There was a problem that it was not possible to know which part fits the purpose if the role played by each part was unknown. In addition, there is a problem in that it is not possible to know which part of the original software design information has a desired function.

On the other hand, in the first embodiment, when a library prepared in advance is used, an attribute key is assigned to each design information in the library as a search element, and each component constituting the design information is assigned to the design information. Although it was possible to assign a search element and perform a simple one-dimensional search, it was not possible to perform a two-dimensional search of design information and parts.

The present invention has been made in order to solve the above problems, and reuses the intention of the creator of the software design information and the parts that can be used among the constituent parts. The purpose is to enable reuse even if the intended purpose of the intended user is different. It is also an object of the present invention to enable desired design information and each component thereof to be efficiently searched. And
It is an object of the present invention to allow a re-user to easily understand the desired specifications and structure of each component and its operation.

[0008]

In a software component reuse system according to the present invention, first, a design section for designing software design information and a design information storage for storing design information designed by the design section. It has a design information construction unit composed of parts. In addition, a component storage unit that stores components for constructing design information having a hierarchical structure, a component search unit that retrieves and extracts each layer that configures the components stored in the component storage unit, and a component storage unit Further, it has a design information management unit composed of a component registration unit for registering hierarchically structured components. Then, the state of the hierarchical structure of each component stored in the component storage unit is displayed and output, the desired component is selected from this, and the selected component is reused for designing the design information in the design unit. Characterize. Further, it is characterized in that the parts stored in the parts storage section are accompanied by the explanation information of the contents and the relation information with other parts. And
It is characterized by having a component operation simulation execution unit that executes a simulation of a component stored in the component storage unit.

[0009]

[Function] The parts are searched and extracted while confirming the hierarchical state and reused in the software design. Also, information about the parts is obtained. Then, the operating states of the parts can be confirmed.

[0010]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a configuration diagram showing a configuration of a reuse management apparatus for realizing a software component reuse system according to an embodiment of the present invention. In the figure, 1a is C
RT, 1b is a keyboard, 2 is a mouse, 3 is an apparatus body, and the apparatus body 3 is roughly divided into a design information management unit 4 and a design information construction unit 5. The design information management unit 4 includes a component search unit 6, a component operation simulation execution unit 7, a component registration unit 8, and a component storage unit 9. The design information construction unit 5 is composed of a design unit 10 that provides a development environment for developing design information including programs and incidental information such as specifications and instructions, and a design information storage unit 11. .

The software developer uses the CRT 1a, the keyboard 1b, or the mouse 2 as an intermediary to make the device main body 3
To access. This device body 3 has a design information construction unit 5
Is placed and software development and design is performed using this. The design unit 10 can create new software design information or change and modify existing software design information. The software design information created / changed by the design unit 10 or in the middle of its work can be stored in the design information storage unit 11.

It is also possible to call the software design information stored in the design information storage section 11 to the design section 10 for further editing. Software developers
As described above, it is possible to create new software design information using only the design information construction unit 5,
Considering production efficiency and quality, it is desirable to develop the software with reuse of existing proven software design information.

The design information management unit 4 supports this. The component storage unit 9 which is a component of the design information management unit 4 stores various software such as existing software design information and standard components partially extracted from the existing software design information in consideration of versatility and reusability. It stores the parts of the design information. The software design information registered in the component storage unit 9 is hereinafter referred to as a software component to distinguish it from the software design information under development. The software developer selects available software parts from the software parts through the parts inspecting unit 6 and incorporates them into the software design information under development by the designing unit 10 for use.

Further, before incorporating the software component into the software design information under development, the component operation simulation executing unit for simulating the dynamic characteristics of the software component so that the usage of the software component can be grasped. 7
Is provided. Further, a component registration unit 8 is prepared to register the software design information developed by the design information construction unit 5 as a software component.

In the parts registration unit 8, the design information construction unit 5
It is also possible to register the entire software design information that has been completely developed in. It is also possible to register a part after extracting a part from it, paying attention to its versatility and reusability, and modifying it if necessary. The registered software component is stored in the component storage unit 9 and will be used in the subsequent development of software design information.

In the present embodiment, the design information construction unit 5 and the design information management unit 4 have a stand-alone configuration arranged on the same device, but the present invention is not limited to this. It goes without saying that the design information construction unit 5 is arranged on the client device, and the design information management unit 4 exists on the server device and can be applied to a distributed environment of a client-server system.

First, the software components will be described in detail below. The software component of the present invention has a hierarchical tree structure as its internal structure. Figure 2
FIG. 2 is a configuration diagram showing the types of components of software parts and their configurations in this embodiment. In the figure, 201 is a hierarchical part that is a basic part for forming a hierarchical structure inside the software part, 202 is a program part that is a basic part for forming a program module inside the software part, and 203 is a control of the program part. It is a functional part that is a part that simulates the target (in the instrumentation design, it corresponds to the control unit of the distributed control system or the device of the plant).

Reference numeral 204 is an icon, 205 is a network description sheet that is a framework for describing the detailed structure of the part in network representation, and 206 is a detailed description of the detailed operation of the part in flow representation (flow chart, SFC, etc.). A flow description sheet, which is a framework for doing so, 207 is a framework for describing text information and picture information, and describes functional specifications such as functions and purposes of the hierarchical parts and design information by using graphic representation and natural language. It is a document description sheet used for. Icon 20
4 is a CRT 1a when the part is described on the network description sheet 205, the flow description sheet 206, and the document description sheet 207 of another part (FIG. 1).
The above is the display form or display information thereof. The shape of the icon can be freely changed and shaped according to the usage and preference of the hierarchical parts.

Reference numeral 208 is a framework for storing voice information, and a voice information storage unit for storing information such as functional specifications, design information and comments regarding the hierarchical parts as voice information, and 209 when reusing software parts. , A search attribute storage unit that stores a search key when searching and displaying a part to be reused, 210 is an external variable I / F that stores an external variable, and 211 is for defining the functional operation of the program part. A program description sheet, which is a framework for describing a program in a textual programming language, 212 is a simulation program storage unit that stores a program for simulating the behavior of a controlled object during simulation execution (details will be described later). . The external variable I / F 210 stores external variables such as a plant device to be controlled or a control unit of a distributed control system, which is referred to by a program described on the program description sheet 211 of the part. This is used for realizing the simulation.

By designating the icon 204 displayed on the CRT 1a (FIG. 1) with the mouse 2 (FIG. 1) or the like, the sheet of the corresponding hierarchical part (network description sheet 205, flow description sheet 206 or document) is displayed. The description sheet 207) can be opened and displayed.
Similarly, regarding the relationship between the icon 204 and the voice information storage unit 208, the voice information storage unit 208 is designated by designating the icon 204 corresponding to the sheet of the parent part with the mouse 2 or the like.
The voice can be stored in or can be played back.

The formation of a hierarchical structure using hierarchical parts will be described below. FIG. 3 is an explanatory view showing a hierarchical structure, in which 301 is one hierarchical part, and inside thereof,
Icon 302, network description sheet 303, flow description sheet 304, and document description sheet 30
There are five. Also, a state is shown in which the hierarchical part 301 of the child-side hierarchy is placed on the sheet 306 of the parent-side hierarchical part. On this sheet 306, any one of a network description sheet 303, a flow description sheet 304 and a document description sheet 305 is placed.

Further, on the sheet 306, an icon 307 of another hierarchical part which is a child is also placed, and the hierarchical part having this icon 307 is said to be in the same level as the hierarchical part 301. On the sheet 306 held by one hierarchical part, the icon 302 of the other hierarchical part 301
Indicates that the former part owns the latter hierarchical part 301. This owner is called a parent or parent hierarchy part, and the owned one is called a child or child hierarchy part.

Next, the internal structure of the above-mentioned software component will be described using the hierarchical parts, program parts, and functional parts described above. FIG. 4 is a configuration diagram showing the configuration of the software component according to the present invention, showing an example of the instrumentation software component. FIG. 1A shows a hierarchical structure showing an image of the internal structure of a software component, and FIG. 1B is a structural view showing a tree structure showing only the hierarchical structure in a simplified form.

First, the image of the internal structure of FIG. 4A will be described. Each software component has a root hierarchical part 401 at the top and forms a hierarchical structure by the parent-child relationship of the hierarchical parts. The software components in the figure are instrumentation software components intended for process control, and form the following hierarchical structure.

The root hierarchy part 401 has one network description sheet 402. The network description sheet 402 describes a “control flow diagram” that describes the relationship between the process device to be controlled and the control device for controlling it. That is, it shows a state in which the process device and the control device are used as nodes and the nodes are connected by links. Several functional parts 406 and three icons 403 to 405 indicating hierarchical parts are arranged here as nodes, which are named "sequence", "interlock", and "ratio", respectively.

The icon 403 indicating "sequence" in the network description sheet 402 has a flow description sheet 407 in which a flow chart of the program of the "sequence" is described in the lower layer. On this flow description sheet 407, two hierarchical parts named a preparation process 408 and a stirring process 409, and icons of program parts named a payout process 410 are placed. Furthermore, this flow description sheet 40
A program description sheet 411 describing this detailed program flow is attached to the lower layer of the payout process 410 of No. 7.

Next, the tree structure described in FIG. 4B will be described. This is expressed in correspondence with the internal structure of the software component of FIG. 4A, and the node 412 corresponds to the root hierarchical part 401. Also, nodes 413, 41 indicating "ratio", "interlock", "sequence", etc. in the lower hierarchical parts indicated by the icons 403, 404, 405 in the network description sheet 402 constituting the root hierarchical part 401.
4,415 correspond. Then, on the flow description sheet 407, which is a lower layer, the “preparation process”, the “stirring process”,
Nodes 416, 417, 4 indicating "payment process" and the like
18 corresponds

When the software component having the hierarchical structure data as described above is to be reused, for example, by selecting the node 415, its child nodes 416, 417, 418, ... Taken out. Nodes 416, 417, 418 are children of node 415 and they are part of a "subtree" rooted at node 415. However, it should be used as a unit to be reused with some hierarchical parts excluded from some "subtrees" of the hierarchical structure, or to be a unit to reuse multiple "subtrees" together. You can also

As described above, in the present invention, it is not a unit of software component registered for the purpose of reuse but a constituent element of the software component (by hierarchical parts).
It can be reused in units of subtrees. Therefore, in software development, in order to find a reusable software part, first a usable software part is searched, and then a hierarchical part or program part (root of a partial tree) that can be used from the software parts. In general, a two-step search for searching for) is required. The “horizontal / vertical browsing function” is to effectively perform such a two-step search instead of exhausting it.

First, the principle will be described with reference to FIG. FIG. 5 shows three software components A501, B502, C.
An example of searching for a root hierarchical part of a subtree available from 503 is shown. In the figure, 504-
Reference numeral 512 denotes software parts A501, B502, C50.
Hierarchical parts 513 forming the subtree 3 are software component management tables. This software component management table 513 is used for each software component A501 to C5.
03 part name and root parts 504 to 506
Is a table that stores pointers to.

In FIG. 5, the hierarchical part 510 of the software part A501, the hierarchical part 511 of the software part B502, and the hierarchical part 512 of the software part C503 are hierarchical parts having the same or similar functions.
In the following, three such software components A501,
This "horizontal / vertical browsing function" will be described by taking the process from B502, C503 to searching for the target hierarchical part 512 as an example.

This browsing has the following three functions. First, as the browsing at the software component level, there is a function for confirming what software component is registered and for deciding from which software component to start searching. This refers to the software component management table 513 and determines from which software component the internal structure is searched and displayed.

As an actual internal process, by selecting any of the component names in the software component management table 513, the root hierarchical part of the software component is obtained. At this time, various sheet information such as the network description sheet 205, the flow description sheet 206, and the document description sheet 207 held by the root hierarchical parts as shown in FIG. 2 is displayed and stored in the voice information storage unit 208. These can be used as reference information by outputting a voice message or the like.

Next, as a second function, there is browsing (vertical browsing) based on the internal hierarchical structure of software components. This is the network description sheet 205, the flow description sheet 206, the document description sheet 207, and the voice information shown in FIG. 2, which are held by the hierarchical parts (or program parts) based on the internal hierarchical structure of a specific software component. This is a function of narrowing down subtrees to be reused by moving up and down in the hierarchical structure while referring to information such as voice information stored in the storage unit 208. To be precise, it is a function to search for root hierarchical parts of the subtree.

The search method will be briefly described with reference to FIG. Judging based on the information held by the hierarchical parts,
When it is determined that the software component A501 has a function to be reused, the holding information of each hierarchical part 507 and hierarchical parts 508 below the hierarchical part 504 of the root is sequentially checked. If both the hierarchical part 507 and the hierarchical part 508 are related to the function to be reused, it will be understood that the subtree (or rather the entire tree) having the hierarchical part 504 as the root node may be used.

However, if the hierarchical part 508 has nothing to do with the required function, it is understood that a subtree (or further subtree) having the hierarchical part 507 as a root may be used. By repeating this process sequentially, it is possible to narrow down the minimum necessary subtree having the function to be reused. Assuming that the minimum required subtree is only the lower layer part 510 in this example, the search for the root hierarchical part of the minimum required partial tree is performed using the hierarchical part 50.
4, the hierarchical part 507, and the hierarchical part 509 to reach the hierarchical part 510.

Thirdly, there is horizontal browsing (search for hierarchical parts having the same / similar functions). This is after discovering the hierarchical parts (subtrees) that can be used in a certain software component, and then checking if there is another software component that has the same function as that.
The horizontal browsing function is to take it out, if any, in a potato-like manner.

In order to realize this horizontal browsing,
An attribute key is assigned to each hierarchical part and program part. This may be stored in the search attribute storage unit 209 in FIG. 2, for example. Attribute keys can be set and changed at the stage when software parts are created, and the number of attribute keys assigned to each part is not necessarily one, and multiple attribute keys can be owned. It is possible. Based on the attribute key, this function searches and displays whether or not there is a hierarchical part or program part having the same attribute key in other software parts (or corresponding software parts).

This will be described with reference to FIG. 5. As described above, the hierarchical parts 510, 511 and 512 hold the same attribute key. Therefore, if the hierarchical part 510 has been found by the above-mentioned vertical browsing, the hierarchical part 51 having the same attribute key in the potato-based expression.
1, 512 can be withdrawn. Further, by referring to the holding information of each hierarchical part, the hierarchical parts 510,
Of 511 and 512, it is possible to select a hierarchical part that is closest to the intended function. In the illustrated example, the hierarchical part 512 is selected by tracing the thick line arrow.

In the above description using FIG. 5, the first to third functions are used in order to perform the search, but it is not always necessary to perform the search in this order. For example, if the attribute key held by the hierarchical part (root hierarchical part of the partial tree) that is desired to be reused has a hit in advance, it is possible to start the search from the above-mentioned third horizontal browsing and save time and effort. .

FIG. 6 is a screen view showing a man-machine interface for performing the above-mentioned horizontal / vertical browsing. That is, it shows a screen state displayed in the component search window on the CRT 1a in FIG.
In FIG. 6, 601 is a component selection display unit, 602 is a component internal hierarchy display unit, 603 is a parts holding information display unit, 60
4 is a parts display unit, 605 is a category display unit, 606, 6
07 and 608 are node identifier list display portions, 609 is an upper layer shift button, 610 is a lower layer shift button,
611 is a sheet information display unit, 612 is a document information display unit, 613 is an icon display unit, and 614 is a voice guidance control box.

First, a software component for starting browsing is selected on the component selection display unit 601. Next, the above-mentioned horizontal / vertical browsing is performed on the component internal hierarchy display unit 6.
02. Therefore, when a specific hierarchical part 201 or program part 202 of a software part as shown in FIG. 2 is designated, the following is performed in the part holding information display unit 603. That is, the contents of the network description sheet information 205, the flow description sheet 206, the program description sheet 211, and the document description sheet 207 held by those parts and the voice information storage unit 2
The voice message stored in 08 can be played.

By displaying the holding information of the hierarchical parts (or program parts) thus designated, it becomes possible to strongly support the horizontal / vertical browsing. Further, when the root hierarchical part of the partial tree to be reused can be selected in the parts internal hierarchical display unit 602, the hierarchical part display is dragged and dropped by moving the pointer on the screen, and the hierarchy is displayed. It is also possible to import a subtree rooted at a part into a window where other work such as design is being performed. This design work is performed by the design unit 10 (FIG. 1).

On the other hand, the component internal layer display section 602 is composed of a category display section 605, n node identifier list display sections 606 to 608, an upper layer shift button 609, and a lower layer shift button 610. In each of the node identifier list display units 606 to 608, hierarchical parts and program parts belonging to the same hierarchy in the hierarchical structure inside the software component are collected, and names, ID numbers, etc.
An identifier that is an attribute that can identify the part is displayed in a list format. In addition, each node identifier list display unit 60
A parent-child relationship is defined between 6 and 608.

When one of the hierarchical parts displayed in the parent node identifier list display section is selected, the child node is identified and the child hierarchical part identifier of the corresponding part is displayed on the list display section in conjunction with the selection. Display in list format.
By the way, the highest hierarchy is displayed in the node identifier list display portion 606 indicated by “NODE (1)”, and the next child hierarchy is displayed in the node identifier list display portion 607 indicated by “NODE (2)”. It Similarly, the grandchild, the great-grandchild, and the like, the nth layer is displayed in the node identifier list display unit 608 indicated by “NODE (n)”.

As described above, the subtree rooted at the hierarchical part selected by the node identifier list display portion 606 can be displayed up to the maximum depth n layers.
Further, the node identifier list display units 606 to 608 can simultaneously display only subtrees of up to n layers.
In order to display higher or lower nodes, an upper layer shift button 609 and a lower layer shift button 61 are displayed.
0 is prepared. By pressing these buttons, the information that has been displayed up to that point can be sequentially shifted to the node identifier list display area on the right or left, and the nodes one level up or one level down can be displayed. .

The above usage will be described in detail with reference to FIG. 7 in which the number of the node identifier list display portions is limited to three. In the figure, 701 is a component selection display unit, 702 is a component internal hierarchy display unit, 703 is a component display unit, 704 is a category display unit, 705 to 707 are node identifier list display units, 708 is an upper hierarchy shift button, and 709 is It is a lower layer shift button. Further, 710 is a software component A indicating a part of a database (data structure) of software components having a hierarchical structure, and 711 is a software component B similarly.

Here, the software parts A710, B7
Reference numeral 11 has a hierarchical structure of hierarchical parts to which an identifier and an attribute key are attached. For example, software component A71
The root hierarchical part of 0 has "part 1" as an identifier and "CAT_A" as an attribute key. “Software component A” and “software component B” are displayed on the component display unit 703, and the category display unit 7 is displayed.
At 04, an attribute key is displayed. Then, among the identifiers, hierarchical parts up to the grandchild with the root hierarchical part as a parent are displayed in the parts internal hierarchy display unit 702. Here, the node identifier list is displayed on the three node identifier list display units 705 to 707.

Then, by selecting "software component B" in the component display portion 703 and selecting "CAT_B" in the category display portion 704, the root hierarchical part in the software component B711 is selected. Is selected, the display state is changed to the reverse display state. By this,
The identifier “component 2” is displayed on the node identifier list display unit 705, and the following node identifier list display unit 70 is displayed.
6 is displayed as “component 22”, and the node identifier list display portion 706 is displayed as “component 23”.

Further, "part 21" having "part 2" as a parent
"Part 22" of a child other than the node identifier list display unit 7
It is displayed in the second row of 06, and grandchildren “component 24” other than “component 23” are displayed in the second row of the node identifier list display portion 707. Here, by selecting "component 2", "component 21", and "component 23" as desired hierarchical parts,
These display states are also changed, for example, highlighted.

By the way, in the component internal hierarchy display portion 702, the node identifiers of the parent, child, and grandchildren are displayed at once. Therefore, for example, in the state shown in FIG. 7, the hierarchical parts below the hierarchical part indicated by “component 23” displayed at the top of the node identifier list display portion 707 are unknown. Here, if the area of the identifier displayed on the component internal hierarchy display unit 702 is changed by selecting the lower layer shift button 709, for example, "component 21" is displayed on the node identifier list display unit 705, and " It is also possible that the "component 23" is displayed on the node identifier list display unit 806 and the "component 25" is displayed on the node identifier list display unit 707 (not shown).

By the above-mentioned operations, it is possible to search for hierarchical parts forming the internal hierarchical structure of software parts without exception. In FIG. 7, the component internal hierarchy display portion 702
Is composed of three node identifier list display sections 705 to 707, but the invention is not limited to this. The node identifier list display section may have a plurality of four or more,
Needless to say.

In the above description, the software component is selected from the component display section 703 of the component selection display section 701, but the invention is not limited to this. It is also possible to use the category display unit 704 to select software parts according to the category. For example, when "CAT_D" is selected in the category display portion 704, the one having this attribute key has the identifier "part 21" in the software part B711 as shown in FIG. 7B. And "part 26", the node identifier list display unit 7
“Part 21” is displayed at the top of 05.

Then, the node identifier list display section 706.
“Component 23” is displayed in the uppermost row of the node identifier list display unit 707, “Component 25” is displayed in the uppermost row of the node identifier list display unit 707, and the second component of the node identifier list display unit 706 is
"Part 24" which is another child of "part 21" is displayed. On the other hand, in the second row of the node identifier list display area 705, "part 26" whose attribute key is "CAT_D" is displayed.
Is displayed.

By the way, as described above, the retrieval of hierarchical parts is performed by the attribute key held by each hierarchical part. Since each hierarchical part can have a plurality of attribute keys at the same time, a plurality of search keys can be combined at the time of search to narrow down the search target. Furthermore, by hierarchically defining the attribute keys, the search range can be expanded and contracted efficiently.

Hierarchical attribute keys mean that a parent-child relationship is defined between attribute keys (range to be searched by the parent attribute key).
It means that a relation of = (hierarchical part having parent attribute key) + Σ (search target range by child attribute key) is established. For example, taking FIG. 8 as an example, an attribute key tree structure is defined on the left side of the figure (in fact, such a data structure can be easily realized by using a general algorithm such as a binary tree).

When such a hierarchical structure of attribute keys is formed, when a search is performed using the attribute key "CAT_A", it is found that the child attribute keys "CAT_D" and "CAT_X" other than the hierarchical parts having "CAT_A". Hierarchical parts having "" will also be searched, and "part 1", "part 13", "part 16", "part 21",
"Part 26" is obtained as the search result.

Although the above description is made assuming that the attribute key is static, an abstract attribute that dynamically creates an attribute key or does not actually hold any hierarchical parts. It is also possible to define a key, which increases the degree of freedom in narrowing down the search target range. For example, in FIG. 8, there is an attribute key tree whose roots are "CAT_A" and "CAT_B", but "CAT_B" and "CA"
By defining an attribute key "CAT_Z" having "T_A" as a child, an attribute key tree can be constructed by merging two attribute key trees.

"CAT_Z" is an attribute key that is not registered in the actual hierarchy (or program part) and is called an abstract attribute key. The search range of "CAT_Z" is
This is the sum of the search ranges of "CAT_A" and "CAT_B", and the search range can be expanded. Although the hierarchical parts corresponding to the root node are synthesized here, an abstract attribute key having “CAT_C” and “CAT_X” as children can be defined in addition to the above.

By layering the attribute keys in this way,
First, the abstract attribute key can be dynamically set at the time of executing the search, and the user can appropriately set the narrowing down of the search range to increase flexibility. Also, the amount of data held in the attribute key of each hierarchical part can be small. In other words, having a more detailed attribute key has the same effect as having a more global attribute key that is higher than the attribute key at the same time. For example, "CAT_
B ”,“ CAT_C ”,“ CAT_Y ”and“ CAT_
Even if "E" is not included as an attribute key, similar search can be performed as long as "CAT_Y" and "CAT_E" are included.

Here, as described above, when an attempt is made to select a hierarchical part or a program part from the software parts by using the part search unit 6 (FIG. 1), the part is actually operated to try to select the part. The dynamic characteristics of can be grasped, and it can be accurately judged whether it suits the purpose of the user. In the reuse management apparatus according to the present invention shown in FIG. 1, by using the component operation simulation execution unit 7 for the software component selected from the component storage unit 9 using the component search unit 6, the software component is executed. The simulation of can be executed.

The simulation execution unit is not a software component unit, but a simulation can be performed in units of sub-trees having a certain hierarchical part as a root, which is an internal component thereof, or program parts. Further, not only the software parts of the control programs such as the hierarchical parts 201 and the program parts 202, but also the operations of the functional parts 203 representing the control unit of the distributed control system and the plant equipment, which are the control targets of these programs, are simulated. It is possible.

FIG. 9 is a block diagram showing the internal structure of the component operation simulation executing unit 7 shown in FIG. 1. 901 is a schedule managing means, 902 is an interpreter realizing means, 903 is a simulation program executing means, 9
Reference numeral 04 is a simulation execution target management table.
Control objects such as program nodes to be simulated and control units of the distributed control system are registered in the simulation execution object management table 904.

By designating a desired program part to be simulated with the mouse 2 or the like in the screen state shown in FIGS. 6 and 7 displayed on the CRT 1a (FIG. 1), the program part is a simulation execution target. It is registered in the management table 904. When a hierarchical part is specified, all program parts included in the subtree whose root is the hierarchical part are registered. Further, from the external variable I / F 210 of the program part 202 (FIG. 2) registered as the simulation target, a functional part 203 (which simulates the control target of the program such as the control unit of the distributed control system accessed by the program part ( 2) is also registered in the simulation execution target management table 904.

The schedule management means 901 refers to the simulation execution target parts management table 904,
Performs schedule management for sequentially executing simulations for each program part and functional part to be executed. In the scheduling algorithm, the program parts registered in the simulation execution target management table 904 are sequentially fetched and the interpreter realization means 902 is instructed to execute them. When the end notice is received from the interpreter realizing unit 902, the next program part is taken out and the interpreter realizing unit 902 is instructed to execute the same as before.

When the last program part has been executed, the next step is to execute the functional part. Also in this case, the functional parts to be executed are sequentially taken out from the simulation execution target management table 904, and the simulation program execution means 903 is instructed to execute them.
When the end notification is received from the simulation program executing means 903, the next functional part is taken out and the interpreter realizing means 902 is instructed to execute it again. Similarly, when the last functional part has been executed, the program part is executed again. Scheduling is performed by such a cycle.

When the interpreter implementing means 902 is instructed by the schedule managing means 901 to execute a specific program part, one instruction sequence of the program described in the program description sheet of the program part 202 (FIG. 2) is interpreted. Execute and schedule management means 90
The execution end is returned to 1. When instructed to execute the same program part, the statement next to the previously executed statement is executed. In this way, the program parts are executed for each instruction string.

On the other hand, the simulation program execution means 903 executes the program stored in the simulation program storage section 212 of the functional part 203 (FIG. 2) when instructed by the schedule management means 901 to execute the specific functional part. When execution is completed to the end of the program, execution completion is returned to the schedule management means 901. As described above, the execution of the functional parts is different from the execution of the program parts, and the whole program is executed at once. The execution result of this program is a CRT1a (Fig. 1) in a display state by network representation.
The output is displayed near the top of each functional part.

By adopting the above-mentioned structure, it is possible to realize a simulation in which the program held by the program parts is executed in an interpretive manner and the state of the controlled object of the program can be displayed in real time. Execution of program parts is interpretive, and when displaying the execution to the user, there are a trace mode in which execution is stopped for each instruction sequence and a command is waited for by the user, and a mode in which execution is completed without stopping. realizable.

FIG. 10 is a block diagram showing a screen state on the CRT 1a (FIG. 1) when performing a simulation.
In the figure, 101 is a network description display unit, 10
2 is a part icon indicating a program part, 103 is a program description sheet display section in which the program of the part icon 102 is displayed, 104 is a part icon indicating a reaction container, 105a is a part icon indicating tank A,
105b is a parts icon showing tank B, 106a,
b, c, d are part icons indicating valves, 107a,
b, c, d, and e are part icons indicating sensors.

Further, 108a, b, c, d, e, f, g
Is the sequence indicated by the parts icon 102, that is,
A parts icon indicating a controller that controls according to the contents described in the program description sheet display unit 103, and a parts icon 109a indicating a control unit that performs distributed control of the valve indicated by the parts icon 106d independently of the sequence. , 109b are part icons indicating a control unit for controlling the stirring operation in the reaction container indicated by the part icon 104 independently of the sequence, and 109c.
Is a part icon indicating a control unit that performs feedback control by detecting a signal from the sensor indicated by the part icon 107e.

FIG. 10 shows the network description display section 1
The hierarchical part of the network description displayed in 01 is set as a root, the part indicated by each part icon is set as a subtree, and the simulation is performed in these units. In the hierarchical structure shown by the subtree, there is a program part named "sequence" shown by the part icon 102 and a controller shown by the part icon 108a-g that is the control target of the program part. Then, the dynamic characteristics of the program shown in the program description sheet display section 103 are simulated.

In order to make it possible to change the parameters of the control units indicated by the part icons 109a to 109c in order to perform this simulation, as shown in FIG. 10B, the setting value change windows 110a, 110a, b and c are provided. The setting value change windows 110a, 110b, 110c are used for the mouse 2
Although it can be displayed by a new input instruction such as (FIG. 1), it is automatically added to all functional parts registered in the simulation execution target management table 904 and displayed. You can also

These set values are irrelevant to the execution of the program displayed on the program description sheet display section 103, and the values of each external variable (actually, the control section forms a structure, Each member variable of the body) can be set. Therefore, before executing the simulation, an initial value in the distributed control of the control unit indicated by the part icons 109a to 109c is set through the setting value change windows 110a to 110c.

Next, the program description sheet display section 103
The program displayed in is executed, but this is executed one instruction sequence interpretively. A mode can be specified for this execution, and a trace mode in which one instruction sequence is executed and stopped, and a command input from the user is waited for, and a continuous execution mode can be selected. You can also set breakpoints. Each time one instruction sequence is executed, the result is reflected in each control unit (functional part) that is a control target and can be referred to through the setting value change windows 110a to 110c.

As described above, by simultaneously simulating the dynamic characteristics of the program and the external variables such as the control unit of the distributed control system to be controlled, the dynamic characteristics of the program can be easily understood. Therefore, when you try to cut out a certain subtree inside a software component and reuse it, you can quickly see if it matches the purpose of use,
Software reuse can be promoted.

[0077]

As described above, according to the present invention, first, the structure of parts (software parts) for constructing design information composed of a plurality of parts is made into a hierarchical structure,
This is displayed and output for retrieval and extraction, and simulation is performed for each of these parts. In addition, the explanation information of the contents and the relation information with others are attached to each part. Therefore, even if the intention of the creator of the software design information is different from the purpose of the user who intends to reuse the component that can be used, the component can be reused. There is. Also,
The effect is that the desired component can be efficiently searched. Then, there is an effect that the user can easily understand the desired specifications and structure of each component and the operation thereof.

[Brief description of drawings]

FIG. 1 is a configuration diagram showing a configuration of a reuse management apparatus for realizing a software component reuse system according to an embodiment of the present invention.

FIG. 2 is a configuration diagram showing the types of components of a software component and their configurations in this embodiment.

FIG. 3 is an explanatory diagram showing a hierarchical structure.

FIG. 4 is a configuration diagram showing a configuration of software components in the present invention.

FIG. 5 is a configuration diagram showing an example of searching a root hierarchical part of a subtree.

FIG. 6 is a screen view showing a man-machine interface for performing horizontal / vertical browsing.

FIG. 7 is a screen view showing a man-machine interface for performing horizontal / vertical browsing.

FIG. 8 is a configuration diagram showing a hierarchical structure of software parts.

9 is a configuration diagram showing an internal structure of a component operation simulation executing unit 7 shown in FIG.

FIG. 10 is a CRT 1a when performing a simulation.
(Fig. 1) Fig. 1 is a configuration diagram showing a state of an upper screen.

[Explanation of symbols]

1a ... CRT, 1b ... keyboard, 2 ... mouse, 3 ... device body, 4 ... design information management section, 5 ... design information construction section, 6
... Parts search unit, 7 ... Parts operation simulation execution unit,
8 ... Component registration unit, 9 ... Component storage unit, 10 ... Design unit, 11
... design information storage unit.

 ─────────────────────────────────────────────────── ─── Continuation of front page (72) Inventor Satoshi Kumagai 134 YBP West Tower, 12th floor, Kobe-cho, Hodogaya-ku, Yokohama-shi, Kanagawa Yamatake Honeywell Co., Ltd. Advanced Technology Center (72) Inventor, Masatomo Hodogaya-ku, Yokohama, Kanagawa Kobe Town 134 YBP West Tower 12F Yamatake Honeywell Co., Ltd. Advanced Technology Center

Claims (3)

[Claims] 1. A design unit for designing software design information, a design information construction unit having a design information storage unit for storing design information designed by the design unit, and the design information having a hierarchical structure. A component storage unit that stores components for building, a component search unit that retrieves and extracts each layer that constitutes the components stored in the component storage unit,
And a design information management unit having a component registration unit for registering a component having a hierarchical structure in the component storage unit. The state of the hierarchical structure of each component stored in the component storage unit is displayed and output. A software component reuse system characterized in that a desired component is selected and the selected component is reused for designing design information in the design unit. 2. The software component reuse system according to claim 1, wherein the component stored in the component storage section is provided with descriptive information of its content and related information to other components. Reuse system for software parts. 3. The software component reuse system according to claim 1, further comprising a component operation simulation execution unit that executes a simulation of the component stored in the component storage unit. Parts reuse system.