JPH08194610A - Software designing method and program structure - Google Patents

Abstract

PURPOSE: To easily design a software while keeping the validity of object orientation by deciding the behaviors of respective objects after a message between a decided input waiting control object and the respective objects is decided. CONSTITUTION: When the specification of an object to be provided for the software and the hierarchical relation of objects are decided based on a rough specification, the input waiting control object for controlling all the input waiting states from an operator included in this rough specification is decided. Next, the message to be transmitted from the input waiting control object to the respective objects is decided and the message to be transmitted after this message is received by each object is decided by referring to the specification of respective objects. When all the messages are decided by these two stages of message deciding work, while referring to the specification of respective objects, the behaviors of respective objects after the reception of the message are decided.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an object-oriented software design method and a program structure for effectively designing software.

[0002]

2. Description of the Related Art In recent years, in designing software, a design method (object-oriented design method) for designing software with higher efficiency by designing software components as objects has been attracting attention. An object is a w that says "what to do"
It is a component of software that behaves only by a hat-to-do operation instruction. The software system composed of such objects has extremely high modularity and also has reusability. The above-mentioned what-to-do operation instruction “what to do” is called a message. Also, the behavior of each object when an operation instruction by message is given,
Also called a “method”.

Details of the object orientation are described in the following documents. Rumbaugh, J. et al. Blaha, M .; , Prem
erlani, W .; , Eddy, F .; and Loren
sen, W.S. By "Object-Orient"
edModelingandDesign, Prent
ice-Hall "(published Prentice-Hal
l) "Translated by Hanyuda: Object-Oriented Methodology (OMT)"
(Toppan Publishing Japanese translation of the above book) Since interactive editing systems such as word processors and graphic editors, which have been actively used in recent years, are frequently subject to specification changes and maintenance after shipment, the above object-oriented design is desirable. Be done. How each object of the object-oriented interactive editing system operates will be briefly described by taking a copying function of a word processor as an example. FIG. 18 is an event trace diagram showing how each object sends and receives a message in the copy function.

In the figure, "cursor object"
A vertical broken line with a character string such as "menu object" indicates an object. Further, a dashed arrow with a character string such as "event loop waiting for function key input" indicates an event loop waiting for input. The input-waiting event loop refers to the processing of each object to wait for the event that the operator inputs a key. Further, the "copy" key is input. An arrow of a one-dot chain line with a character string such as “” indicates an input event. The input in the present specification indicates a key input made by the operator to the word processor, and the input event indicates an event (event) that the operator makes a key input.

Further, "The cursor movement event loop is started. A solid arrow with a character string such as “” indicates a message. When the arrows in this figure are followed in order from the top, "copy key is input" after the event loop b4 of "event loop waiting for function key input" is performed.
It can be seen that the input event of When an input event occurs in this way, the menu object displays a message "b7: start cursor movement event loop",
A message b10 “starting an event loop for designating a starting point position” is transmitted. When the message transmitted in this way is received, the cursor object executes an "event loop waiting for cursor movement key input" event loop b1, and the character string type area object executes an "event loop waiting for execution key input" event loop b5. . When the operator moves the cursor during execution of this loop processing and also inputs the "execute" key, the cursor object "moves the cursor." The input event b12 of “” is received, and the “execute” key is input to the character string type area object. Of the input event b13 ”. "Enter" key is entered. Input event b13
Upon receiving the message, the character string type area object causes the message "b8" to continue the event loop of cursor movement.
Is sent to the cursor object, and the cursor object is caused to continue the “event loop waiting for cursor movement key input” event loop b2. Further, the character string type area object itself also continues the "event loop waiting for execution key input" event loop b3.

From the above description, it can be seen that each object behaves by being instructed in the "what to do" portion of the "how to do" portion without being instructed in the "how" portion. The modularity of the software system is enhanced by the fact that each object behaves without being instructed on the "how" part.

[0007]

However, when designing an interactive editing system by object orientation, it is difficult to decide which object and what input waiting process is to be assigned, and it is necessary to consider an optimal assignment. However, there was a problem that the design took time.

Further, since it is necessary to control the input waiting process by sending a message, it is necessary to design what kind of message is to be given to which object, and various kinds of control messages are required. It was necessary to define it at the decision stage, and this definition made the system design very difficult.

In FIG. 18, there are an "event loop waiting for cursor movement key input" event loops b1, b2, b3 performed by the cursor object and an "event loop waiting for function key input" event loop b4 performed by the menu object. , "Event loop waiting for" execution "key input" performed by the character string area object b5 and "event loop waiting for" execution "key input performed by the document buffer object" event loop b "
There is an event loop such as 6.

Further, in this figure, a message "b7 to start an event loop of cursor movement", a message "b8 to continue an event loop of cursor movement" b8, and an event loop for designating a starting point position are started. Message b9, "start an event loop for specifying the copy destination." ] There is a message such as the message b10 for causing another object to perform an event loop.

It is a burden on the designer to entrust the designer with which object is to be responsible for the above-mentioned various kinds of event loops and messages for controlling the event loop, which in turn increases the software development efficiency. Will result in dropping. In view of the above problems, the present invention provides a design method that can more easily design object-oriented software while maintaining the usefulness of object-oriented software, and an object-oriented program structure that can be designed more easily. The purpose is to

[0012]

In order to achieve the above object, a software designing method according to a first aspect of the present invention is based on a general specification enumerating transitions of operating states of an interactive editing system.
A software design method for designing objects, messages, and behaviors of objects that the software installed in the system should have, wherein the specifications of the objects that the software should have, based on general specifications,
An object deciding step for deciding a hierarchical relationship between the objects, an input waiting control object deciding step for deciding an input waiting control object for controlling all input waiting states from an operator included in the general specification, The waiting control object determines a message to be transmitted to each object determined in the object determining step by referring to the specification of each object, and the first message determining step and each object determined in the object determining step are Second message determining step of determining the message to be transmitted after receiving the message determined in the message determining step of step 1 and receiving the message determined in the first message determining step Each object after Is characterized by comprising a behavior decision step of bets behavior is determined with reference to the specifications of each object, the.

In the second aspect, the object determining step has a tree structure drawing sub-step for drawing a tree structure diagram representing the inheritance relationship of each object, and the input waiting control object determining step is the tree structure It is characterized in that the input waiting control object is arranged at a position where there is no inheritance relation of any object in the tree structure diagram drawn by the drawing sub-step.

Further, in claim 3, the first message determining step has a trace drawing step for drawing a trace drawing showing the transmission and reception of messages between objects, and the trace drawing step comprises the input waiting control object. An object placement sub-step in which the input waiting control object determined in the determination step is arranged, and the objects determined in the object determination step are arranged in hierarchical order from the position next to the position of the input waiting control object, and the input waiting control object. A message placement substep for placing a message to be sent to each object between the objects placed in the object placement substep, and the second message decision step is for each object decided in the object decision step. The message to send a message arranged in a message placed substep after receiving, it is characterized in that it comprises placing the trace view after drawing the trace diagram plotting step.

Further, in claim 4, in the input waiting state in the general specification, there is one in which a condition is input by the operator, and the second message determining step is in the input waiting state in which the condition is input. The feature is that messages corresponding to individual conditions are collectively arranged. The software design method according to claim 3.

Further, in claim 5, the respective messages collectively arranged in the message arrangement sub-step are characterized in that the respective objects of the hierarchy having an inheritance relationship with the upper hierarchy are the transmission destinations. Further, in claim 6, in the behavior determining step, the behavior of each object determined in the object determining step after receiving the message determined in the first message determining step is plotted in the trace drawing step. It is characterized in that it is placed at a position corresponding to the time of receiving a message in the trace diagram.

According to a seventh aspect of the present invention, in the object-oriented program structure, one of the plurality of objects is an input waiting management object that manages all input waiting events of the operator. Is characterized by being an object that behaves based on the message of the input waiting management object.

[0018]

According to the first aspect of the invention, the specifications of the objects that the software should have and the hierarchical relationship between the objects are determined by the object determining step based on the general specifications. When the specifications and hierarchical relationships are determined in this way, the input waiting control object determining step for determining all input waiting states from the operator included in the general specifications is determined in the input waiting control object determining step. Since this input waiting control object receives all input from the operator, the designer does not have to determine which object is to be assigned what input waiting process.

The message that the input waiting control object should send to each object is determined by the first message determination step. After the determination, the message to be transmitted after each object receives the message is determined by the second message determination step by referring to the specification of each object. Since the determination of the message is performed by these operations, the design of what message is given to which object is greatly simplified.

When all the messages have been decided in the above two-step message decision work, the behavior decision step decides the behavior of each object after receiving the message by referring to the specification of each object. .
According to the second aspect, the tree structure diagram representing the inheritance relationship of each object is constructed by the tree structure diagram constructing sub-step. In the input waiting control object determining step, the input waiting control object is arranged at a position where there is no inheritance relationship of any object in the tree structure drawing constructed by the tree structure drawing substep. If the input waiting control object is arranged in such a position, the input waiting control object can be defined so as not to impair the inheritance relationship in object orientation.

According to the third aspect of the present invention, the trace diagram showing the transmission / reception of the message between the objects is drawn by the first message determining step. The input-waiting control object determined in the input-waiting control object determining step is placed in the object placement sub-step, and each object determined in the object determining step is placed in hierarchical order from the position next to the input-waiting control object. . The message that the input waiting control object should send to each object is arranged by the message arrangement substep between the objects arranged in the object arrangement substep. The messages arranged in this way form a step in the hierarchical order,
The destination object will change from higher to lower.

According to the fourth aspect, the messages corresponding to the individual conditions in the input waiting state in which the conditions are input are collectively arranged by the second message determining step. By arranging them collectively in this way, it is possible to clarify transitions of a wide variety of events in one event trace diagram without drawing a plurality of event trace diagrams.

According to the fifth aspect of the present invention, the messages placed in the message placement sub-step are sent to the respective objects in the hierarchy that has an inheritance relationship with the upper hierarchy. Messages are arranged so that the inheritance relationship becomes clear by making each object a destination.

According to the sixth aspect, the behavior of each object determined in the object determining step after the message determined in the first message determining step is received is traced in the trace drawing step. It is placed at a position corresponding to the reception of the inside message. In this way, by arranging the methods in the trace diagram, the correspondence between the sending and receiving of messages and the methods becomes clear.

According to the seventh aspect, the input waiting management object manages all input waiting events of the operator. The behavior based on the message of the input waiting management object is performed by other objects.
In this way, all the input waiting events of the operator are integrated into the input waiting management object, so that specification changes and maintenance after shipment regarding the input waiting can be made only by modifying the input waiting management object.

[0026]

Embodiments of the software design method will be described below with reference to the drawings. First, the configuration of a word processor will be described as an example of an interactive editing system.
FIG. 16 is a diagram showing an example of the hardware configuration of the word processor. As shown in FIG. 16, the word processor 10 uses a key punch to input a character code, and
A keyboard 1 for receiving a cursor position instruction, a text buffer 2 for accumulating the character code input by the character code input, a display 3 for displaying the contents of one page of the text buffer, and a display for each character code. Display font RO that stores bitmap patterns
M4, hard disk 5 for storing a group of accumulated character codes as a document, RAM 6 for storing the application program of the word processor, and CP for executing each step of the application program
It consists of U7.

FIG. 17 is a flow chart showing the outline of the above-mentioned application program. In this flowchart, the application program monitors whether the operator has called a document, pressed a key, pressed a cursor key, or selected a copy function (step K).
1, K6, K8, K10). When the document call is designated by the key input of the operator (step K1), the application
The application program displays a list of documents stored in the hard disk (step K2), selects a desired document (steps K3 and K4), and reads the selected document into the text buffer (step K5). When key punching is performed (step K6), the input character code is stored in the text buffer 2 (step K7). When the cursor key is pressed (step K8), the cursor position in the text buffer 2 is changed (step K).
9). When the copy function is selected (step K10), the copy function program is executed to copy the character string (step K11). There are various other types of processing performed by the word processor, but these are not the main subject of the present application, and therefore description thereof is omitted.

<Description of Application Program Development Process> How the above application program is developed will be described. FIG. 1 is a flowchart showing the entire process of software development. Step m1 is an analysis process, which analyzes what kind of performance the application program to be created should have, and determines the general specifications of the application program to be created.

Step m2 is a designing process, in which it is determined what kind of function the application program to be created has, and objects, messages and methods are defined. Step m3 is a manufacturing process,
Coding, compilation, linking, and debugging (single debugging) are performed based on the design result in the design process to create an executable program (execution program).

Step m4 is a test process, in which the manufactured software is operated on the hardware to finally confirm the conformity with the specifications. <Description of Software Design Process> Details of the software design process (step m2) shown in FIG. 1 will be described with reference to the drawings. The flow chart of this design process is shown in FIGS. The software design method according to this embodiment will be described below with reference to these flowcharts. Note that the design target in this embodiment is the above-mentioned copy function program, and this copy function program is applied to the hardware shown in the configuration diagram of FIG. Here, the designer is given the general specifications created in the analysis process (step m1 shown in FIG. 1). A general specification is a list of what kind of events cause the operating state of software to transition.
FIG. 4 shows an explanatory diagram of the outline specifications for realizing the copy function.

The "copy" key in the figure is input. ],
"A menu for selecting the area type (character string type, line type, area type) is displayed on the edit screen. ], “Area type is selected. ] Is called a script and indicates the operating state of the copy function. Numerical values such as “1.”, “2.”, and “3.” attached to each script indicate a time-series ranking.

In step S1, the designer extracts all the objects from the general specifications and defines the method of the object. In the general specifications of FIG. 4, since the document is processed, this system requires a document editing object. In addition, in order to edit a document, an object of a document buffer that handles document contents is required.
In addition, "copy" to this document buffer object
Since a function such as "check the copy destination" is required,
Define methods such as << copy >><< check copy destination >>. Since these methods need to handle document contents, attributes such as document contents (attributes correspond to variables and values handled by the method) are defined.

Further, the general specifications include "Display document."
Since there is such a phenomenon, the object of the edit screen for displaying the document is extracted. Since the object of this edit screen needs a function such as "display", a method "display" is defined for the object of the edit screen. Since the method "display" requires an item such as "where to display", an attribute called display position is defined in the object of the edit screen. The above extraction and definition are repeated, and from the schematic specifications of FIG. 4, "document edit", "document buffer",
Objects such as “area”, “character area”, “line area”, “box area”, “edit screen”, “menu”, and “cursor” are extracted.

<Drawing of Object Model Diagram> In step S2, an object model as shown in FIG. 5 is drawn. The object model is a tree structure diagram showing inheritance relationships and aggregation relationships between classes of objects.
To draw the object model, arrange the objects extracted in step S1 in a tree shape, write the character strings indicating the methods and attributes of each object, and arrange the symbols indicating the inheritance relationship and the aggregation relationship between the objects. Done in.

The symbol "▲" in the figure indicates an inheritance relationship. In the figure, it is shown that the objects of the "character type area", the "line type area" and the "box type area" are defined as the objects of the lower class inheriting the "area" object. In other words, the "area" object is defined as a superclass of the "character area", the "row area", and the "box area". In this case, the lower class inherits the attributes and methods belonging to the upper class.

Further, the symbol "⋄" indicates an aggregation relation, and the "document edit" object is constituted by each object of "document buffer" and "edit screen". As a method of describing the relationship between objects, refer to FIG.
The "▲" and "◇" in the above are merely examples, and are not particularly limited as long as the relationship between objects can be defined. Objects surrounded by squares in the figure represent objects. In addition, "[]" in the square,
"<>" And "<<>>" correspond to "object name", "attribute name" and "method name", respectively. For example, the [area] object in the figure encapsulates the attributes <start point><endpoint> and the method <register start point><register end point>.

<Definition of input waiting state control object>
After drawing the object model diagram of FIG. 5, step S
In 3, the designer defines an input waiting state control object in a lower class of the document edit object as shown in FIG. The input waiting state control object is an object for controlling all input waiting states included in the general specifications. Therefore, the designer defines a method such as << input waiting state >> and an attribute such as <input waiting state processing> in the input waiting state control object.
The input waiting state control object is provided in the lower class of the document edit object in order to prevent the input waiting state control object from inheriting any object.

After defining the input waiting state control object, in step S4, the input event and the input waiting state are extracted from the general specifications. FIG. 7 shows the extracted input event and input waiting state. <Dynamic model drawing> In step S5, step S4
The input waiting state extracted in (1) is represented as a character string surrounded by a frame, and the transition between the input waiting states is represented by a dynamic model diagram. The dynamic model diagram is a diagram in which the transition from state to state of each object is represented by an arrow. The dynamic model diagram drawn in step S5 is shown in FIG. Step S5
FIG. 8 shows a dynamic model diagram drawn in FIG.

In the drawing of this dynamic model diagram, the character strings representing the input waiting state are evenly arranged, the arranged character strings are surrounded by a frame with rounded corners, and the enclosed one is a model in the input waiting state. This is done by connecting the models in the input waiting state with an arrow and using this arrow as a model of the input event. In this figure, the arrows labeled (1), (3), (5), (7) and (9) indicate input events. The boxes with (2), (4), (6) and (8) indicate the input waiting state. Characters such as “copy” and “execute” are attached to the arrows in the figure, which indicate what kind of key code is returned to the object by the input event. Further, the branched arrows designated by (3), (5), (7), and (9) indicate that the transition destination of the input waiting state is switched by the input event by the operator.

Incidentally, (1) to (10) in this figure correspond to the script numbers in FIGS. 4 and 7. The description method of the dynamic model is not particularly limited as long as it can describe the transition between states. <Drawing of Event Trace Diagram> In step S6, an event trace diagram is drawn based on the dynamic model of FIG. The event trace diagram is a diagram showing the exchange of messages between objects. The event trace diagram drawn in step S6 is shown in FIG.

In the drawing of the event trace diagram, the object names of the respective objects are evenly arranged in the horizontal direction in the hierarchical order, and after the arrangement, a broken line is drawn in the vertical direction from these object names. It is done by arranging messages as arrows connecting the. The arrows in the figure will be followed in order to describe how the designer arranged the messages.

First, the input waiting state control object needs to perform an event loop and wait for the operator to input a key. Therefore, the designer is required to use the event loop e1.
To place. While the event loop e1 is being performed,
When an event such as "copy key is input" occurs, the input waiting state control object needs to display a menu screen for the copy function. Therefore, the designer arranges the message m1 for displaying the menu between the input waiting state control object and the menu object. After sending this message, the input wait state control object needs to know the selection result of the menu screen. In order to know the selection result, the input waiting state control object must wait for an event such as “move cursor” to occur. Therefore, the designer arranges the event loop e2.

When the event "move cursor" occurs, the input-waiting control object must cause the cursor object to look up the current cursor position. Therefore, the designer arranges the message m2 for checking the cursor position between the input waiting state control object and the cursor object. When the cursor is moved by the operator and the execution key is input, it is necessary to register the current cursor position as the start point of the area. Therefore, the designer "registers the cursor position as the start point of the area between the input waiting state control object and the document buffer object. Message m3 such as ". As the designer arranges the messages in the above manner, the event trace diagram as shown in FIG. 9 is created.

After drawing the event trace diagram, in step S7, detailed specifications for each state transition in the dynamic model diagram are written. The detailed specifications will be described with reference to the portion indicated by the broken line frame h2 in FIG. 9 as an example.
While the status transitions from "Waiting for input to specify area end point" to "Waiting for input to specify copy destination," the current cursor position is checked, the character at the end point of the copy source is registered, and copying is not possible. It should have the event of looking up characters. The designer enumerates all such events as shown in FIG.

After transcribing the detailed event, step S8
In the event trace diagram shown in FIG. 9, the message about the detailed specifications above is displayed in the part indicated by the broken line frame h2.
The object to which the message is sent is further arranged. The state transition from "waiting for input for specifying area end point" to "waiting for input for specifying copy destination" corresponds to the portion surrounded by the broken line frame h2 in the event trace diagram. The designer further arranges a message corresponding to the event transcribed in FIG. 10 and an object of the transmission destination of the message in this portion. FIG. 11 shows an enlarged view of the portion related to the broken line frame h2 of FIG. 9 after the additional arrangement of the message and the object.

"Check the cursor position" corresponding to the message m2. After receiving the
"Notify the cursor position to any object. 』
You must send a message such as. Therefore, the designer "informs the cursor position. ] The message m21 is arranged between the cursor object and the document buffer object.

On the other hand, "The cursor position is registered as the end point of the area. After sending the message m5, it is necessary to check the presence or absence of the non-copyable character at the end position, and to notify other objects of the check result. Therefore, the designer "inspects whether there is a non-copyable character in the copy area. ] The message m51 is arranged between the document buffer object and the character string type area object,
Further, a message "m52 notifying whether uncopyable character exists in copy area" for notifying the document buffer object is arranged between the document buffer object and the character string type area object.

After the arrangement, in step S9, the designer collectively arranges the messages corresponding to the individual conditions in the input waiting state in the general specifications, although the conditions are input. Among the input waiting states of the outline specifications shown in FIG. 4, the ones to which the condition is input are “2. area type (character string type,
A menu for selecting the line type or box type is displayed on the edit screen. , "3. Area type is selected." Based on these input conditions, the designer, in addition to the message m51 sent to the character string type area object,
The message m53 sent to the line-type area object,
Message sent to box-type area object m55
Are placed together. After placing these messages, reply messages m52, m5 for these transmissions
4 and m56 are arranged.

A non-copyable character may be designated depending on the area designation in the input waiting state in the general specifications. Depending on the presence or absence of the non-copyable character, the document buffer object should switch between the message with the non-copyable character and the message with the non-copyable character.
If there is no non-copyable character, the copy destination may be designated. Therefore, a message "Display" Please specify the copy destination "menu" message m58 is arranged between the document object and the menu object.

If there are uncopyable characters, it is necessary to again specify the start point of the area. Therefore, the designer
"Display the" Please specify the start point of the area "menu" message m57 is displayed.
Place it between objects. After arranging the messages m57 and 58 as described above, the reply messages m6 and m61 for these messages are arranged between the input waiting state control object and the menu object.

After arranging the message through the above process, in step S10, a branch according to the input condition, the continuity of the event, and symbols indicating the end of the event are written in the figure to clarify how the event transits. I'll do it. (1) in FIG. 12 shows branching according to input conditions, and shows that processing branches depending on whether the area designation method is "character string area", "row area", or "box area". ing. The arrow in (2) indicates the continuity of events, and the events connected by the arrows indicate that they are continuously executed. This indicates that “check cursor position”, “notify cursor position”, and “register cursor position as end point of region” are continuously executed. further,
"3" in (3) indicates the end of consecutive events, and indicates that the processing has ended at that point.

By using the descriptions of (1), (2) and (3), it is possible to clarify transitions of a wide variety of events in one event trace diagram without drawing a plurality of event trace diagrams. Incidentally, the description method of the event trace diagram is not particularly limited as long as it can describe the control flow of the processing such as the conditional branch. In step S11, the designer arranges how each object behaves when receiving a message. This behavior (method)
Is placed by writing necessary methods in the event trace diagram shown in FIG.

In FIG. 12, the cursor object receives the "check cursor position" message,
It is necessary to perform a behavior such as "check the cursor position" until the "notify the cursor position" message is sent. Therefore, the designer arranges the method “check cursor position” method k1 at the position of the cursor object.

In FIG. 12, the character string type area object needs to perform the behavior of "registering the end point" after receiving the message "register the cursor position as the end point of the area". Therefore, the designer arranges the “register end point” method k2 at the position of the character string type area object. In FIG. 12, the character string type area object "checks whether there is an uncopyable character in the area to be copied. Until the message is received and the message "Notify if there are non-copyable characters in the area to be copied" is sent, "Check for non-copyable characters." It is necessary to perform such a behavior. Therefore, the designer arranges the method “check for uncopyable characters” method k3 at the position of the cursor object.

When the above procedure is repeated, the method is arranged in the event trace diagram as shown in FIG. In step S12, the designer expands the dynamic model diagram from the method arranged in the event trace diagram of FIG. 13 and arranges how various states included in the method transit. . FIG. 14 shows a dynamic model diagram in which the state transition is drawn in step S12.

This processing step is represented by the method k shown in FIG.
4 will be described as an example. In order to check the non-copyable character, it is necessary to store in which variable the specified area is from to where. Therefore, the designer defines a pointer variable [range] as a variable that indicates each character in the designated area. After definition, this [r
How the [state] transitions will be clarified by drawing a dynamic model diagram.

In order to check the presence of non-copyable characters, first,
The pointer variable [range] must be made to point to the starting point position of the specified area. Therefore, firstly, the state j1 is arranged. After the arrangement, it is necessary to check whether or not the character designated by [range] in the designated area is a non-copyable character. And if it is not a non-copyable character, [range
It is necessary to advance the pointer variable of e] by one character. Therefore, the states j2 and j3 in FIG. 14 are arranged, and the arrows y1 and y2 indicating the state transition are arranged between these states.

By advancing the pointer variable as described above, [range] reaches a non-copyable character or the end position of the area. Therefore, the designer arranges a state j4 when a non-copyable character is encountered and a state j5 when the character reaches the end position of the area. After placement, state j3
And the states j4 and j5 are connected by an arrow to complete the dynamic model diagram.

Each state in the figure corresponds to each internal process. The arrow label indicates the conditional expression when the state of the pointer variable [range] transits. If there is no label, it means that the state automatically changes. Such a dynamic model is described for all the methods defined in step S11. The description method of the dynamic model is not particularly limited as long as it can describe the transition between states. FIG. 15 shows a dynamic model diagram in which events regarding message transmission are entered after the above arrangement is completed.

The expansion into the dynamic model diagram as described above is repeated for all the events defined in step S11 (steps S13 and S14). Also, in step S15,
By repeating S16, similar to the transition from "waiting for input for designation of area end point" to "waiting for input for designation of copy destination" shown by the broken line h1 in FIG. Design the transition from "Waiting for input" to "Waiting for input to specify area end point", and the transition from "Waiting for input to select area type" to "Waiting input for specifying area start point" ( Steps S8 to S15).

Through the above design process, an application program having an input waiting control object is designed. <Description of Comparison with Conventional Example> Next, the drawing drawn in the above design process and the drawing created by the conventional object-oriented software design method will be compared. FIG. 18, FIG. 19 and FIG. 2 are drawings when the application program is designed by the conventional object-oriented design method.
0 is shown. FIG. 18 is an event trace diagram drawn by the conventional object-oriented design method and corresponds to FIG. 9 described above.

FIG. 19 is an event trace diagram drawn by the conventional object-oriented design method, which is shown in FIG.
Equivalent to 1. Further, FIG. 20 is a dynamic model diagram drawn by the conventional object-oriented design method.
Equivalent to 5. First, the event trace diagram of FIG. 9 and FIG.
Contrast with the event trace diagram of.

Compared with FIG. 18, it can be seen that FIG. 9 is very easy to see because all the event loops extend from the input wait state control object. Further, since the event loop is arranged only in the input waiting state control object, the designer may arrange the event loop only in the input waiting state control object. Therefore, the burden on the designer is significantly reduced.

First, the event trace diagram of FIG. 11 and FIG.
Contrast with the event trace diagram of. Compared with FIG.
It can be seen in FIG. 11 that the message flow is shown very neatly. Also, the message is stepped,
It can be seen that the destination object changes from higher to lower. By drawing an event trace diagram so that the destination objects change in this way, it is possible to define messages from rough design to detailed design according to the design level.

Since the messages are drawn in a very orderly manner and with steps, the messages sent by switching according to the conditional branch and the behavior of each object at the time of receiving the message can be controlled by one. It can be designed using the event trace diagram. First, the event trace diagram of FIG. 15 and the event trace diagram of FIG. 20 will be compared. Compared with FIG. 15, it can be seen that the event loop exists in FIG. In this way, the total amount of coding in the software as a whole changes significantly depending on whether or not each method has an event loop.

From such a comparison, it is understood that the software designed in this embodiment can greatly reduce the burden on the designer. Also, the model diagrams of FIGS.
In the program having the structure shown in the trace diagram, since the input waiting processing is integrated into the input waiting control object, for example, from the simultaneous pressing of "Ctrl + K" to "Ctrl + n".
The key code assignment change such as changing the area designation key can be done by changing the input waiting control object. Since the input waiting process is integrated with the input waiting control object in this way, the program designed by this design method is highly expandable.

[0067]

According to the software designing method of the first aspect, the designer does not have to determine which object is assigned to which input waiting process and what message is assigned to which object. Since the design of whether or not to give it is greatly simplified, it is easy to decide the object and the message, and the design can be performed without considering the optimal sharing. Therefore, the design of the object-oriented software is greatly simplified, and the development efficiency of the interactive editing system can be greatly improved.

According to the software designing method of the second aspect, in addition to the effect of the first aspect, since the input waiting control object is defined so as not to impair the inheritance relationship in the object-oriented, the object-oriented type. You can more easily develop object-oriented software without compromising the usefulness of. According to the software design method of claim 3, in addition to the effect of claim 1,
The messages placed in the trace diagram form a step in the hierarchical order, and the destination object moves from the higher level to the lower level.Therefore, the correspondence between the message transmission and the hierarchical structure of the object is clear. Is obtained. With such a trace diagram, the designer can define the message while confirming the hierarchical structure of the object.

According to the software designing method of the fourth aspect, in addition to the effect of the first aspect, the message corresponding to each condition in the input waiting state in which the condition is inputted is the second message. The decision steps place them together. By arranging them collectively in this way, it is possible to clarify transitions of a wide variety of events in one event trace diagram without drawing a plurality of event trace diagrams.

According to the software designing method of the fifth aspect, in addition to the effect of the first aspect, since the message is arranged so that the inheritance relationship becomes clear, the designer can deal with the hierarchical relationship. You can arrange the messages while checking, and greatly improve the design efficiency. According to the software designing method of claim 6, in addition to the effect of claim 1, by arranging the method in the trace diagram, the correspondence between the sending and receiving of the message and the method becomes clear. While confirming, you can decide the method. Therefore, the design efficiency can be greatly improved.

According to the program structure of claim 7, in addition to the effect of claim 1, the specification change and the maintenance concerning the input waiting after the shipment can be made only by modifying the input waiting management object. Greatly improve efficiency. Also, other objects do not have processing related to input waiting, so they can be easily designed.

[Brief description of drawings]

[Figure 1] Flow chart showing the overall process of software development
It is a chart.

FIG. 2 is a flowchart of the software design process shown in FIG.

FIG. 3 is a flowchart of the software design process shown in FIG.

FIG. 4 is a diagram showing what kind of state transition the outline specifications represent.

5 is an object model drawn in step S2 shown in FIG. 1. FIG.

FIG. 6 is a diagram showing an object model in which an input waiting state control object is defined in a lower class of a document edit object.

FIG. 7 is a diagram showing an input event extracted from a general specification and an input waiting state.

FIG. 8 is a diagram showing a dynamic model diagram drawn in step S5.

FIG. 9 is an event trace diagram drawn in step S6.

FIG. 10 is a diagram showing detailed specifications transcribed for each state transition in the dynamic model diagram in step S7.

11 is an enlarged view of a part related to a broken line frame h2 of the event trace diagram of FIG. 9.

FIG. 12 is an event trace diagram in which a plurality of messages that are switched and transmitted according to an operator's input are additionally arranged.

FIG. 13 is an event trace diagram in which a method is arranged in step S11.

FIG. 14 is a dynamic model diagram depicting state transitions in step S12.

FIG. 15 is a dynamic model diagram in which events regarding message transmission are entered.

FIG. 16 is a configuration diagram showing a hardware configuration of a word processor to be designed.

FIG. 17 is a flowchart showing an outline of an application program of the word processor shown in FIG.

FIG. 18 is an event trace diagram drawn by a conventional object-oriented design method.

FIG. 19 is an event trace diagram drawn by a conventional object-oriented design method.

FIG. 20 is a dynamic model diagram drawn by a conventional object-oriented design method.

[Explanation of symbols]

 m1 analysis process m2 design process m3 manufacturing process m4 test process S2 object model drawing S5 dynamic model drawing S6 event trace drawing drawing 1 keyboard 2 text buffer 3 display 4 display font ROM 5 hard disk 6 RAM 7 CPU 10 word processor

Claims (7)

[Claims] 1. A software design method for designing an object, a message, and a behavior of an object, which software installed in the interactive editing system should have, on the basis of a general specification enumerating transitions of operating states of the interactive editing system. In order to control the specifications of the objects that the software should have based on the general specifications and the object determination step that determines the hierarchical relationship between the objects, and the state of waiting for all input from the operator included in the general specifications. The input waiting control object determining step for determining the input waiting control object of the above, and the first determining the message to be transmitted by the input waiting control object to each object determined in the object determining step with reference to the specifications of each object. Message decision steps and objects A second message determining step in which each object determined in the determining step determines a message to be transmitted after receiving the message determined in the first message determining step, with reference to the specification of each object, A behavior deciding step of deciding a behavior of each object by referring to a specification of each object after receiving the message decided in the first message deciding step, and a software designing method. 2. The object deciding step has a tree structure drawing sub-step for drawing a tree structure drawing representing the inheritance relationship of each object, and the input waiting control object deciding step is performed by the tree structure drawing drawing sub-step. 2. The software designing method according to claim 1, wherein the input waiting control object is arranged at a position where no inheritance relation of any object occurs in the drawn tree structure diagram. 3. The first message determining step has a trace drawing step for drawing a trace drawing showing transmission and reception of messages between objects, and the trace drawing step is determined in the input waiting control object determining step. The input waiting control object is placed, and the object placement sub-step of placing each object determined in the object determination step in the hierarchical order from the position next to the input waiting control object, and the input waiting control object is sent to each object. A message placement sub-step for placing a message to be placed between the objects placed in the object placement sub-step, and the second message decision step is that each object decided in the object decision step is a message placement sub-step. Messages to Send placed message step after the received software design method of claim 1, wherein further comprising a placing trace view after drawing the trace diagram plotting step. 4. The input waiting state in the general specifications includes a condition input by an operator, and the second message determination step corresponds to each condition in the input waiting state in which the condition is input. 4. The software design method according to claim 3, wherein all the messages that have been written are arranged together. 5. The software design according to claim 4, wherein the respective messages collectively arranged in the message arrangement sub-step are destined for respective objects in a hierarchy having an inheritance relationship with an upper hierarchy. Method. 6. The behavior deciding step, after receiving the message decided in the first message deciding step, shows the behavior of each object decided in the object deciding step in a trace drawing drawn in a trace drawing step. 6. The software designing method according to claim 5, wherein the software designing method is arranged at a position corresponding to the reception of the internal message. 7. An object-oriented program structure, wherein one of the plurality of objects is an input waiting management object that manages all input waiting events of the operator, and the other objects are input objects. A program structure that is an object that behaves based on the message of a waiting control object.