JPH01116729A - Editor for specification description - Google Patents

Abstract

PURPOSE:To support the control of multidimensional hierarchical relations in a natural form for human beings by controlling multidimensional hierarchical structure among modules in a specification description as a space model, using a multiwindow and a bit map display and displaying it visually. CONSTITUTION:In the space model installed to deal with four hierarchical relations whose dimensions are different, a three-dimensional space showing the relation among modules of a specification in one version by a three- dimensional rectangular coordinate system is a basis. Coordinates axes z, x and y are respectively a detailing axis, a hiding axis and a class hierarchy axis. The revision of the version is regarded as the progress of time, a time axis to show the relation is installed and it is showed by a four-dimensional space as a whole. Thus, four relations among modules or module sets are visually made into the model and they can be operated directly along the model on the screen of an editor.

Description

[Detailed description of the invention] [Table of contents] Overview Industrial field of application Conventional technology Problems to be solved by the invention Means for solving the problems, Figure 1 Effect, Figures 1 to 6 Module definition Window, Fig. 1, Fig. 2 Module hierarchy window, Fig. 1, Fig. 3 Example, Fig. 7-1
Figure 2 Detailing window, Figure 7, Figure 12 Class hierarchy window, Figure 8 Class hiding window, Figure 8 Effect of the invention [Summary] The multidimensional hierarchical structure between modules in specification description is used as a spatial model. The ability to manage and display/manipulate the model visually using a multi-window and bitmap display is realized.

[Industrial application field]

The present invention relates to an editor that enables multidimensional creation of specification descriptions.

In recent years, research has been conducted on various development support tools in order to improve the productivity and quality of software. Among these, the role played by editors that supports specification and program creation is important.

Regarding program creation, results have been achieved in structured editors that support the creation of program text that reflects the syntactic structure input and editing operations specific to the programming language, and tools that support the gradual elaboration of programs. Ru.

Regarding specification creation, similar structured editors have been developed for creating specification texts, but there are not many examples of editors that support specification creation assumptions themselves. In the case of programming languages, it is practical enough to handle only a single relation such as a refinement relation such as a procedure call, whereas in the case of specification descriptions, various relations are introduced. This is because it is necessary to manage these multidimensional hierarchical structures. For example, in addition to elaboration relationships, it is necessary to manage invisible operations that are invisible to external modules, such as VISIBLE-INVISIBLH (D relationships) in abstract data types, and hierarchical relationships between class modules in object-oriented models such as RML. These are concepts that are orthogonal to each other.Of course, not all of these hierarchical relationships are reflected in individual specification languages, but for complete specification it is necessary to combine user requirements into a single It is not enough to organize only according to hierarchical relationships, and it is effective to perform specifications by combining these various relationships.

Therefore, it is important to support the management of these multidimensional hierarchical relationships in a way that is natural to humans.

In particular, visual management/support is desirable in terms of improving human understanding of the specification description content and description process.

(Prior Art) Regarding methodologies for specifying requirements from users, many methods have been studied at each level from the requirements specification stage to the detailed design specification stage. What is important in this is the module division method, which divides the software into parts that are cohesive based on a certain view.Originally, the relationship between the divided modules is based on each specification design. Although it depends on the method, there are some common concepts, and these concepts are important for specification. If we narrow down the hierarchical relationships (too many are difficult to handle), they are as follows.

■Refinement: This is the relationship between a module that includes an abstract description and a module that describes that abstract description in more detail. This abstract description is decomposed into logically equivalent, more detailed modules. Its purpose is to understand complex systems by breaking them down into simpler components.

There are functional decomposition methods, data flow design methods, etc. depending on the perspective from which the decomposition is taken.

■Information Hiding 2 It is important to hide detailed definitions, such as the definitions of abstract data type operations, and to expose only the information necessary for module users to the outside. Information concealment refers to not displaying unnecessary information to the user. For example, local variables and local procedures in ordinary programming languages, and visible parts in Ada package specifications.
The concept of whether another module or a part thereof can be referenced from a certain module in the description of private part is also based on this idea. It is important to manage modules that can refer to each other as a unit.

■Class hierarchy: -1 for objects with common properties
The class concept of grouping and understanding is also important. Relationships between various classes, such as super/subclass relationships where one class is included in another class,
A relationship such as a direct product or direct sum of multiple other classes is a hierarchical relationship between modules representing a class.

Version 0 (version): The specification may need to be revised due to changes in user requirements or changes in the implementation environment. Storing and managing the original version is important to support specification revision work. . Since the original version and the revised version may have different module structures, the relationship between versions is a relationship between sets of modules.

These four relationships are orthogonal to each other.

[Problem that the invention seeks to solve]

To date, no editor has been proposed that displays the complex relationships between modules in an easy-to-understand manner on the screen, and that allows the user to easily change what is displayed. The four relationships between module sets are visually modeled, and operations can be performed directly on the editor screen according to the model.

[Means for solving problems]

FIG. 1 is an explanatory diagram of the principle of the present invention, which is a spatial model introduced to visually handle different hierarchical relationships in four dimensions. This space model is based on a three-dimensional space in which the relationship between modules of a specification within one version is expressed in a three-dimensional orthogonal coordinate system. The coordinate axes z, x, and y are each
We regard the revisions of the 0 version of the ``inement'' axis, ``Hiding'' axis, and ``Class Hierarchy'' (C1ass Hierarchy) axis as the progression of time, and introduce the 0 time axis that represents the relationship between them, creating a four-dimensional space as a whole. Expressed as

[Effect]

FIG. 1(a) shows the other three hierarchical relationships at one time (that is, one version).

In this three-dimensional space, the hierarchical relationship between modules is expressed as a tree structure that can be traced in the three axes directions of x, y, and z. A node in the tree represents one module. The tree structure representing the detailed structure of the module is expressed on the yz plane, the tree of concealment relationships is expressed on the xy plane, and the class hierarchy relationship is expressed on a plane parallel to the 2nd plane.

To trace from a lower module to a higher module in a hierarchical structure, or vice versa, a three-dimensional tree is traced along the corresponding axis. For example, module B is a detailed version of module A in FIG.

E can be reached by moving down in the z-axis direction, that is, by moving in the negative direction of the two axes. Modules H and I hidden in module E can be reached by descending in the X-axis direction. A module G is a superclass of a module E representing a class.

To reach F, you can go up in the y-axis direction and use subclasses, or you can reach M by going down.

Generally, there are a plurality of modules that have a hierarchical relationship with a certain module, so when tracing along the x, y, and z axes in order to shift the viewpoint to a target module, a module selection operation is also necessary. In particular, in the class hierarchy, there may be multiple upper and lower WI layers. Climb up the tree while selecting modules (move in the positive direction of the axis)
Move the viewpoint to the desired module by moving up and down (
moving in the negative direction) is called dosvn.

It is considered that this one three-dimensional tree corresponds to each version of the specifications for different versions. The structure of the editions also has a hierarchical structure such as the 1st edition, 2nd edition, 2.1 edition, etc., but here it is assumed that these editions are arranged in a straight line on the time axis according to the time when they were created. Therefore, in order to call up a specification of a certain version, we must trace the times one by one along the time axis.In other words, to shift our viewpoint to the specifications of an older version, we must create dosJ according to the order of the times, and vice versa. To move to a new version, create an upi.

Since normal terminal screens are two-dimensional, it is not possible to visualize the spatial model in Figure 1 as is.

Therefore, in the present invention, display input editing is performed using a multi-window method using a large-screen, high-resolution bitmap display. Then, a plurality of windows are simultaneously displayed on the screen of the bitmap display, and the specification text (including figures) displayed in any one of the windows is input and edited.

The windows include a module definition window that displays one module definition, and a module hierarchy window that displays the hierarchical structure of modules in a tree structure. Furthermore, there are three types of module hierarchy windows depending on the hierarchical structure of (1) to (4) described above. These windows are
The yz plane, zx plane of the hierarchical structure of specifications as shown in Figure 1,
It is considered that a portion of the projection onto the xy plane is displayed in an easy-to-see format. Therefore, the module definition window corresponds to the tree nodes in FIG. 1, and the module hierarchy window represents the parent-child relationship of the tree nodes. These windows are as follows.

(a) Module definition window: The module definition window is a window for inputting and editing module descriptions, and the specification text of this window is displayed. One module definition is given to one window. Therefore, multiple module definitions are not displayed within one window. The module description in this window logically corresponds to the nodes in the tree structure in Figure 1.
Corresponds to 1. When the same module appears as different nodes, such as modules B and E in the detailed structure tree in Figure 1, each can be associated with one window, and they can be displayed and input edited at the same time. can. This is because a window does not correspond to a module, but to one node on a hierarchical structure tree. If the same module description is edited differently from these multiple windows, all the editing results will be valid. This is because it is more natural to think of operations as being performed on one specification from different windows, as shown in FIG.

(b) Module hierarchy window: Module floor.

The layer window displays a portion of the projection of the wooden barrel structure in the hierarchical relationship onto each coordinate plane in the space of FIG. 1, in parent-child relationships of nodes. Accordingly, module hierarchy windows are classified into three types: detailed windows, hidden windows, and class hierarchy windows, depending on their display contents. 3 in Figure 1
In order to reflect the model of spatial water that can be traversed in directions, these three windows are displayed in the format shown in FIG. 3 to give a combined image as a rectangular parallelepiped according to each coordinate axis direction of the spatial coordinate system.

These windows can be opened one by one in association with the module definition window, and each face represents a module (a set of) each axially related to that module. In the example of FIG. 3, the front side represents the negative direction of refinement, the downward direction represents the negative direction of concealment, and the right direction represents the positive direction of the class hierarchy. It is also possible to make the window appear upward, which indicates a positive direction, instead of downward, and to the left, which indicates a negative direction, instead of the right direction.

FIG. 3 is an example of the definition window of module A in FIG. 1 opened, and its child module names B and E are displayed in the detail window in the front direction. The axis direction corresponding to the window facing toward the front is the current user's viewing direction, and this window is called the current direction window.Each window not only displays the module name in watercolor style as shown in Figure 3. , the module description itself or a part thereof may be displayed so that the relationship between modules (parent module and child module or child modules) can be seen.

The data to be displayed and its format depend on the implemented editor.

Operations that can be performed on this window and display data include (1) up and down operations in the hierarchical structure that calls the module description), (2) changing the viewpoint direction, and (3) changing the hierarchical structure. be. Next, these will be explained.

(1) Calling the module description: As shown in Figure 4, when you select the module name (for example, B) displayed in the current direction window, a new module definition window is opened, and the module description is read ( (displayed elsewhere on the same display screen), or an empty window if no module description exists.

If the direction of the current direction window is the positive direction of the axis, this operation corresponds to the up operation explained in Figure 1,
If it is in the negative direction, it corresponds to dosvnfi creation.

(2) Movement of viewpoint direction: The operation of changing the viewpoint direction is performed by selecting a window to be the current direction window. Figure 5 ta > 佽) shows (
An example is shown in which the rightmost window in a) is selected.

In FIG. 3 shown above, windows appear only at the bottom and right ends, but if you want to change the viewpoint in the opposite directions, first open the windows at the top and left ends.

Movement of the viewpoint is performed by rotating a three-dimensional window on the screen using horizontal/vertical directions as rotation axes. Bring the desired surface to the front and use it as the current direction window. Depending on the direction of rotation, the module name in the positive direction (parent node name in the hierarchical structure) is displayed, or the module name in the negative direction is displayed.

This operation is called Rotate, as shown in Figure 5 (C).
(d) is an example.

(3) Change the hierarchical structure: Add/delete/delete module names displayed in the current direction window.
The hierarchical structure can be changed by moving (including between windows). These operations are interdependent between individual hierarchical windows.

All of the operations described above are logical operating procedures; the physical operating procedures (e.g., what command menu appears, what buttons are pressed on the mouse) depend on the language and windowing system. Depends on.

The modules displayed in the module definition window on the bitmap display screen are all components of a specification version. Therefore, the entire display screen can be viewed as a plane on which modules of the same logical version are placed. In other words, as illustrated in FIG. 6, one screen can be considered to be a snapshot of the specifications at a certain time during the revision process. This logical plane is called a version plane. A version plane has a one-to-one correspondence with a specification version.

The user performs input/edit operations on the specification description of the version by placing and displaying the version plane containing the version to be input-edited on the actual display screen. The version plane currently displayed on the screen is called the current version plane. This version plane represents one time on the time axis associated with revision work. 'The version brain is as shown in Figure 6,
The version plane representing the previous version is placed behind the current version plane in the order of version (n, n L n-2, ・
...).

Therefore, to move the viewpoint from the currently focused version, that is, to move from the current version plane to another version plane, perform operations such as ``turning over'' or ``covering'' the current version plane. The former is a shift to an older version, and the latter is a shift to a newer version. The illustrated example is the n edition, with the (n-1) edition turned over to reveal the (n-2) edition.

Through such processing, the complicated relationship between each module can be displayed in an easy-to-understand manner for the operator, and a desired module can be easily extracted and displayed.

〔Example〕

The following is a specification description language (PuX) using diagrams and limited natural language.
An example that is applicable to a structured editor (referred to as :e position L) will be explained. Pure System L employs modeling based on natural language idioms to formalize user requests. = The system is described using natural language (English) and based on natural ideas. In the same way, the meaning explanatory sentences regarding the target-specific words and phrases used in the description are sequentially written.

Considering that these object-specific words correspond to modules that are components of the system, a structured module set is obtained. The divided modules are classified as la>static or dynamic, or (b) data or function, depending on the syntactic category of the word corresponding to the module.

Static elements are represented by adjectives (including past participles) and nouns (including gerunds), and dynamic elements are represented by nouns (those with internal states) and general verbs. A set of data is associated with a common noun, and an i-noun is associated with a common verb, adjective, or a noun other than a set of data. According to the orthogonal classification method of (a) and (b), Pure location L includes function definition (static function), class definition (static data set), operation definition (dynamic function),
There are four word definition formats for dynamic class definitions (dynamic data sets). FIG. 7 shows an embodiment of the present invention.

The example described in Figure 7 is Alternating Bi
This is part of the usage description of a communication protocol called t protocol, which has a simple error correction function against data loss.

In this example, the phrase An protocol n+ach
ine (11), Trans+++1tter
(12), Transn+it (13),
Each is defined using a representation, a combined representation of figures and text, and a text representation. The former two words (11) (12)
is defined by a dynamic class definition and the verb Transm
it (13) is defined by the operational definition. The diagrammatic representation represents the relationships between internal objects that exist within the module, with an ellipse (14) representing an object that is an instance of a dynamic class, and an arrow (15) representing an action performed from an object to an object. represents.

The detailed structure between modules becomes the reference relationship of words in the quantity division process. For example, in the definition of word A, word B
is used (that is, A is word-split into B), B is in a refining relationship with A. In Figure 7, A
Since the common noun Transmitter is used in the definition of B protocol o+achine (11) (Figure TA), Transa+1tter (
12) is AHprotocol macbine (
11) is in a detailed relationship.

Class definition and dynamic class definition (hereinafter simply referred to as class definition) are formats for defining objects with common properties as a class. Define words that refer to and operate on objects that are instances of the defined class using function definitions and behavior definitions. Therefore, the module hiding relationship is the relationship between class definitions and these function definitions and operation definitions, and the class hierarchy relationship is the relationship between class definitions. In Figure 7, the dynamic class definition Transmitter (12)
The verb Trans+wit as an operation for (13)
is defined.

The TA function that supports the module hierarchical structure of the Pure Placement L Structured Editor is designed based on the above-mentioned model.The description by the Pure Placement L is concise, and the words that appear in the description are directly associated with lower modules in the hierarchy. represents the name. Therefore, in the module hierarchy window, the names of upper and lower modules are displayed in text format as shown in FIG. 7, and text can be input and edited directly in the module hierarchy window. As a result, all specification text is displayed within the module hierarchy window, so there is no need to create a module definition window. The following describes the text displayed in each window and the operations that can be performed on it.

■Detailing window: Pure Detailing using L is a method called word division. Therefore, this window displays how the meaning definition of a word is divided into words, and as a result, the specification text of all 1 module is displayed, excluding the subclass declaration part.
Subject to input editing.

One window displays diagrams and natural language expressionsaii
It consists of two parts: a window that displays additional information about the word definition assigned to that window (such as attributes and parent word definition name). The specification writer inputs and edits text within this window. A down operation to shift the viewpoint in the detailed structure is performed by selecting a word name in the text and clicking the mouse (by the zoos-in command shown below). A new hierarchical structure window will open and the specified word definition will be loaded into it. In this window, the details window is the current direction window. Figure 7 shows zooIl-in for the verb Transmit.
In the example of executing the command, the detailed definition of Transmit is displayed. Up operation is zooIII-o
Executed by the ut command.

■Class Hierarchy Window 2 The Class Hierarchy Window displays the superclass/subclass of the target class, and the names of classes in class composition relationships such as direct sum and product. This window can be opened independently in both the positive and negative directions.

When you select a lower class name displayed in a window in the negative direction created by dowJ, a window with the current direction window as the class hierarchy window is opened and the class definition is read. If the class name itself for the window is selected, the cursor is moved in the opposite direction, that is, in the negative direction window, the cursor is moved to the positive direction window, and upff1 is created. The same applies to the window in the forward direction.

The hierarchical structure is changed by moving/deleting/copying words displayed in the window. For example, to make a subclass a superclass, move the class name displayed in the negative direction to the window in the positive direction.

■Class Hidden Window: The class hidden window is
Display the name of the phrase encapsulated within the class definition. Only when the word is a noun (class), there are words (operations) at a lower level. down/up
The i creation is similar to the class l1ijii window. Some hidden words and phrases can be referenced from the outside (vis
ible) words and phrases that are not (1nvisible)
) words and phrases, and the specifications of those words can be displayed. Further, the specification can be changed using a command. Furthermore, there are words and phrases that can be referred to, and words and phrases that expose the operation of the superclass to the outside as an operation of the relevant class, and words that do not, and the assignment of these words and phrases can also be changed by changing the concealment relationship.

Typical examples of commands that can be performed within each window are listed below.

■Details window zoom-in (up), zooIl-out
(down) ・”・Moving the viewpoint Editing input in units of characters, words, sentences, blocks...
Text input/edit ■Class hierarchy window 5 select (up, down) -・----Move viewpoint &W collection in units of words...Changing class hierarchy ■Class hiding window 5 select (up, down) ・-・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] has been done. The upper left corner of the screen is a roll down area for "flipping" the current version plane.
The lower right corner is a roll-a-knob for “hiding”.
up) area. If no older version exists, the roll amp area will not be displayed.

The "turn over" operation is performed by dragging the roll-down area with the mouse cursor. As you drag the mouse, the current version plane (the next older version of the plane) will be displayed. If you move the mouse cursor to the roll-up area, the completely older version will appear and become the current version plane. The old version is only for reference and cannot be modified.
Moving word definitions across yields is only permitted by copying the word definition from an old version into the version plane of the version currently being created. The ``ka'' operation is performed by dragging the mouse cursor in the opposite direction.

The rollup area is always displayed, and if there is no new version of the specification, that is, the version listed in the current version brain is the latest, and you perform a complete rollup, that specification will be registered as the specification of that version, and an empty current A version brain emerges to create a new version of the specification.

FIG. 9 is a block diagram of the editor of the present invention, in which processing block 2
It is roughly divided into 1 to 26. 21 is a process of waiting for an operation from the mouse, and if any operation is detected here, the type is determined in process 22. The main processes as an editor are window shape related 23, current direction window related 24, and version plane related 25, and other processes 26 include file operations and the like.

The version is stored in a file for each purge controller, with global information indicating the relationship between the modules added to the set of modules. The module has a tree-structured text body, as shown in FIG. 10, to which various information is attached.

The detailed information indicates a many-to-many relationship, and the class hierarchy information indicates a many-to-many relationship and a relationship name. Encapsulation information indicates a one-to-many relationship regarding concealment.

The current version plane is specified by boundary information and a version number. The shape of each window is indicated by four pieces of information as shown in FIG. Window shape-related operations include zooming in/out and moving by dragging a mask, as well as deletion and rotation. rota te
There are two types: inversion and axis change, and the differences are shown in Figure 12.

Clipping is performed after each operation is completed.

In FIG. 12, when the detailed window (R) is facing forward (2), up/down operations and editing are possible, and the editing in this case is editing using a text template and changing detailed information. Up/down operations and editing are possible even when the class hierarchy window (, C) is facing the front.
Editing in this case involves inputting the hierarchy name at the time of add and changing the class hierarchy information. Encapsulation window (H
) is facing the front, you can also perform up/down operations, edit, and visib by specifying the module name with the mouse.
le/1 nvisible operation is possible. Editing in this case involves changing encapsulation information.

In either case, the up/dohn operation refers to specifying a module with the mouse and opening a window for the module that is not displayed. Also, when editing, move,
The following operations can be performed: erase, copy+add (only within the window), yank, and put (read and write to the global area).

〔Effect of the invention〕

As described above, according to the present invention, the multidimensional hierarchical structure between modules in a specification description can be managed as a spatial model, and it can be visually displayed and manipulated using a multi-window and bitmap display. , it has the advantage that it can be used as a powerful support means when creating specifications.

[Brief explanation of the drawing]

Fig. 1 is an explanatory diagram of the principle of the present invention, Fig. 2 is an explanatory diagram of operations from different windows, Fig. 3 is an explanatory diagram of the module hierarchy window, Fig. 4 is an explanatory diagram of module description calling, and Fig. 5 is an explanatory diagram of the module description call. FIG. 6 is an explanatory diagram of the version plane; FIG. 7 is an explanatory diagram showing an embodiment of the present invention; FIG. 8 is an explanatory diagram of roll-up/down; FIG. 9 is an explanatory diagram of the embodiment of the present invention. FIG. 10 is a diagram of the configuration of the editor, FIG. 10 is a diagram of the module configuration, FIG. 11 is an explanatory diagram of window shape information, and FIG. 12 is an explanatory diagram of window operation (rotate).

Claims (3)

[Claims] (1) Manage the multidimensional hierarchical structure between modules, which is the unit of specification description, as a spatial model, display it visually using a multi-window bitmap display, and change the display module. An editor for specification description. (2) The editor for specification description according to claim 1, wherein the spatial model is a model that has three axes: elaboration, information hiding, and class hierarchy for each version. (3) The window includes a module definition window that displays the definition of one module, and a module hierarchy window that displays the hierarchical structure of modules in a tree structure. An editor for specification description according to claim 1, characterized in that the editor includes a window.