JP3442421B2 - Object-oriented software design support method and method for verifying specifications between different types of software design documents and programs - Google Patents

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 support method, and in particular, different aspects of software are represented by different figures and character strings such as state transition diagrams, sequence charts and message flow diagrams. Object-oriented software design support that facilitates software design by making it possible to verify the consistency between software design documents or between these and software that is expressed only by language such as programs. The present invention relates to a method and a method for verifying specifications between different types of software and programs.

[0002]

2. Description of the Related Art Generally, in software design, a spiral type software that first creates a prototype, obtains a specific improvement request through trial and operation of this prototype, and changes specifications and improves based on the improvement request. The design is being done.

In this spiral type software design, the deviation between the specifications (various software design documents) and the program has been a problem since the specifications are repeatedly changed. Conventionally, there has been a demand for a method that can easily verify the deviation between this specification and the program.

On the other hand, a specification description system has been proposed in which the description of the program and the specification is strictly defined by a certain rule. As a specification description method with high verifiability, there are algebraic specifications and a communication protocol called LOTOS. According to the algebraic specification and the communication protocol LOTOS, there is a possibility that the consistency between the specification and the program can be verified, and there is an advantage that the inconsistency of the description can be automatically determined.

[0005]

However, in order to directly describe the above algebraic specifications or LOTOS, generally high level knowledge and skill are required, and it is difficult to verify the conformity of the program with the requirements of the described specifications. There was a problem that required sufficient education for designers.

On the other hand, since it is necessary for the software design document to be easy for the user to understand, a software design document that uses a diagram or the like and is easier to understand is generally used.

However, since the software design document using this chart describes each side of the function, structure, and behavior of the software, the meaning of pixels such as figures and arrows in each drawing is different, It could not be verified by mechanically comparing drawings or drawings and programs.

Therefore, in the conventional software design,
For changes in specifications during design, designers proceeded with program coding while checking various software design documents.

However, in large-scale software design,
The number of software design documents is large, and it is often the case that problems that affect design document changes are found, especially in the stage of coding source code. In such cases, it is difficult to change all design documents related to specification changes. Met. For this reason,
The consistency between the software was low, and ultimately the brain of the person who directly made the software was used to make adjustments in the program.

Such software design is not only difficult to work, but also difficult for a third party to objectively check the program specifications.

Therefore, an object of the present invention is to mechanically verify the consistency between different types of software design documents that represent different aspects of software using figures and the like, or the consistency between these software design documents and the program itself. An object is to provide an object-oriented software design support method that facilitates design / development, and a method of verifying specifications between different software design documents and programs.

[0012]

In order to achieve the above object, an object type software design support method according to the present invention comprises software composed of a plurality of objects, and a communication path between the objects and a message transmitted and received on the communication path. A message flow diagram showing the above, a state transition diagram showing the state of each of the objects and state transitions due to the sending and receiving of messages, and a sequence chart showing the sending and receiving of messages between the objects over time. Input of pixels and character strings in object-oriented software design that creates a software design document and creates a program that describes the message of each object and the procedure of message transmission and reception in a predetermined language based on these software design documents By the editor unit to support A software design document is created, a program is created while referencing the software design document on a computer screen, and then the software design document and program information are separated and extracted into graphic information and specification information by an interpreter unit. The software design document, the graphic information and the specification information of the program are extracted and stored in the storage unit, and then the verification unit combines the software design document of a predetermined type or the specification information of the program to set the verification target as communication between processes. It is characterized by normalizing this and verifying the consistency between processes, and then feeding back the verification result to the program designer by the verification result display section.

[0013]

According to the object type software design support method of the present invention, various software design documents can be easily created on the computer screen by the editor section, and the program can be created by referring to the created software design document on the computer screen. Can be created. This can facilitate the initial stage of software creation.

Next, the interpreter unit separates and extracts the information of the software design document containing the graphics into the information unique to the drawing (graphic information) and the information about the specifications (specification information). The graphic information has a data structure called Representation, and the specification information has a data structure called Semantics and is stored in the storage unit.

When verifying the consistency between predetermined types of software design documents or between programs, the verification unit regards the software design documents and the specification information of the programs to be verified as processes, and two processes Is evaluated by replacing the integrity of the communication protocol between the two processes.

By the cooperation of the operations of the interpreter unit, the storage unit, and the verification unit, it is possible to mechanically verify the consistency of different types of software design documents or programs represented by figures or character strings having different meanings. .

Further, since the verification result is fed back to the software designer by the verification result display section, when the specification is changed, the software designer can confirm whether or not the program is correctly created according to the specification change. A program can be created while checking easily, and after the program is created, a third party can objectively and easily check the correctness of the program, and the program design as a whole can be facilitated.

[0018]

Embodiments of the present invention will be described below with reference to the accompanying drawings.

[Object-Oriented Software Design Support Method] FIG. 1 shows the flow of software design by the object-oriented software design support method according to the present invention, and a support system. As shown in FIG. 1, in object-oriented software design, a general object is constructed (step 110) from the purpose of the software (step 100). Next, various software design documents that define the functions, structures, and behaviors of the objects, programs that describe the operations / messages of the objects, request execution examples, etc. are created (step 1).
20).

In the above object-oriented software design, a spiral software design is widely used in which a prototype of a simple work product is first created, and a function is added or modified according to an improvement request for the prototype.

However, according to the spiral type software design, the configuration of the object is increased or decreased (step 110) and each software design document or the program itself is changed (step 120).

In the object type software design support method according to the present invention, the software designer can easily describe the software design document, the requirement execution example, and the program, and when the specification is changed, the software design document, the requirement execution example,
It verifies the consistency between programs and provides the verification results to software designers.

In order to achieve the above object, the software design support method of the present invention has an editor unit 1 as a support system.
An interpreter unit 2, a storage unit 3, a verification unit 4,
It has a verification result display unit 5. The editor unit 1 has various drawing functions and input functions, and facilitates drawing and character input of software design documents, and input of programs and request execution examples (steps 100 to 120). It should be noted that the editor unit 1 can limit the pixels of the graphic that can be input and can determine the meaning of the input pixel according to the shape and position.

The interpreter unit 2 separates and extracts the information included in the drawing of the described software design document into the drawing information and the specification information (step 130). Here, the graphic information is the type and position of the drawn figure, the type of font, or the like. The specification information includes a relationship between classes, a message source and a message destination, a message order, a method, an attribute, and the like. Also, regarding a program, the message expression described in the program and the operation are distinguished and extracted.

The storage unit 3 is a Residentatio.
The graphic information and the specification information are stored in a data structure of n and a data structure of Semantics, respectively (step 140).

The verification unit 4 takes out the specification information of a predetermined type of software design document, or between the software design document and the required execution example or the program, regards each specification information as a process, and confirms the consistency between the two processes. It is evaluated by replacing it with the integrity of the communication protocol between them (steps 140 to 150).

The verification result display unit 5 displays the verification result to the software designer (step 150).

With the above software design support, the software designer can easily create a software design document and a program by the various functions of the editor unit 1 without requiring special education such as formal specification description. In this case, there is a great advantage that the software design document can be coded while referring to the same computer screen displaying the program.

Further, when it becomes necessary to change the specification, the specification is changed in the software design document or the program that makes it easy to grasp the change in the specification, and the verification result display section 5
It is sufficient to detect inconsistencies in each software design document and program and correct it. As a result, the person who creates the software can create the program while referring to the correct software design document, and the creation of the program becomes easy and accurate. Moreover, since the created program is consistent with each software design document, a third party can easily check the validity of the program.

[Specification Verification Method Between Software Design Document and Program] Next, a verification method of the specification consistency between each software design document and program will be described below.

Prior to the description of the specification verification method, a method of extracting each software design document and program and its specification information will be described.

(Message Flow Diagram) FIG. 2 shows an example of a message flow diagram. In Figure 2, message flow Figure 6 shows objects 7 and 8 (represented by a square frame)
And the communication path 9 between the objects 7 and 8 (represented by an arrow)
And a message 10 (represented by a character string) transmitted and received on the communication path 9.

This message flow is shown in FIG.
However, the editor unit 1 is not a simple figure drawing program, but limits the pixels that can be described to a square frame and an arrow, and further determines what is represented by the described position and figure.

For example, when a square is drawn, it is determined that it represents an object. When a character string is input, if it is written in the square, it represents the name of the object and the arrow If it is described in the vicinity, it is determined to represent the message name.

Message Flow From FIG. 6, it can be taken out as specification information that a communication path 9 exists between objects and a message 10 is transmitted and received by the communication path 9.

The specification information is expressed as follows. Γ using the communication function γ that indicates that there is communication between objects
The expression (m, m ′) = m ″ is generated. In order to indicate which channel the message is on, m _i
^{Rename ι} . This is expressed by the formula (1
It is expressed as in 9).

[Equation 20]

(C ++ Program) FIG. 3 shows a C ++ program as an example of the program. C +
+ The program 11 includes all information related to the execution of the program.

Generally, the function of software is realized by the cooperative operation of a plurality of objects. Each object requests a part of processing to another object to realize its own function. How a class of objects behaves when a message arrives is described in the message function. In that description, a description about what kind of message is sent to the outside,
It includes a description of internal actions that cannot be understood from the outside. Which part of the program description represents message transmission can be specified using conventional parsing techniques. The process of a C ++ program is basically obtained in the form of a list of message names obtained by parsing.

What is important here is that the program has a structure which is in the form of execution control such as sequential execution (connection) of programs, conditional branching (selection), and repetition.

To extract the specification information from the program,
Considering the structure of the program, the process operation formula is performed in the following format (Formula 9). Here, p, p ', and p "are process operation expressions, and _mi is a message expression.

[Equation 21]

(State Transition Diagram) FIG. 4 shows an example of the state transition diagram. The state transition diagram 12 shows an initial state 13 of an object (represented by a double circle), a transitioned state 14 (represented by a single circle), and a state transition 16 by transmitting and receiving a message 15 (represented by a character string) (represented by an arrow). ) Is shown. This state transition diagram 12 is also described via the editor unit 1, and the pixels are discriminated as described above.

Focusing on the transitioned state in the state transition diagram, the transition to the transition is limited to the case where a predetermined message is received in a predetermined state. For example, in FIG.
In order to be in the operating state 14, the message 15 called Grasp arrives in the initial state 13 or the Manipu in the operating state 14.
Only when the message "lating" arrives.

That is, in order to extract the specification information from the state transition diagram, s _i can be represented by the state and m ′ _ij can be expressed by the following determinant (2).

[Equation 22]

When there is no transition relation between states, it is represented by δ, and there are cases where transition to the same state is made by a plurality of messages. Therefore, t is represented by the following equation (20).

[Equation 23]

Expression (20) is created for each state transition diagram. Since multiple state transition diagrams are drawn for one object, the following equations (3) to (3) obtained from all state transition diagrams for one object
Is configured.

[Equation 24]

(Sequence Chart) FIGS. 5 and 6 show an example of a sequence chart. The sequence chart describes the messages exchanged between programs at a certain stage of program execution along the time axis. The sequence chart 17 has an object 18
a, 18b, 18c and objects 18a, 18b, 1
The message 19 transmitted and received between 8c is described. The message 19 is generated in the order of occurrence and the time axis 20
It is described along with.

Sequence chart 17 is object 1
Since it only shows the exchange of the message 19 between the eight, the description does not include control structures such as conditional branching and repetition. That is, the sequence chart 17 shows only in what order the objects 18 must have a structure capable of transmitting and receiving messages.

FIG. 5 focuses on the message reception of the object 18b. In order to express the messages e _i received by the object 18b as a series of processes e, the received messages e _i of the object 18b are listed in the order of reception to obtain Expression (1).

[Equation 25]

FIG. 6 focuses on the message transmission of the object 18a. Similar to the case of reception, the specification information of the sequence chart can be extracted by the expression in which the transmission messages are listed in the transmission order.

Next, a method of verifying specifications between various software design documents and between programs will be described.

(Specification Verification Method of Sequence Chart and State Transition Diagram) FIG. 7 shows a specification verification method of the sequence chart and state transition diagram. In FIG. 7, the formula (1) is obtained as the specification information of the sequence chart and stored in the sequence chart formula storage unit of the storage unit 3 (step 20).
0).

[Equation 26]

On the other hand, the formula (3) is obtained from the state transition diagram as the specification information of the state transition diagram and stored in the state transition diagram formula storage unit of the storage unit 3 (step 210).

[Equation 27]

Next, the above equations (1) and (3) are called to the communication path setting unit (step 220), the verification target is considered to be the communication from the process e to the process S, and this communication is expressed by the formula (4) and the formula (4). This is represented by equation (5) and equation (6).

[Equation 28]

[0054]

[Equation 29]

[0055]

[Equation 30]

Next, the expression (6) representing the communication is transformed into an expression of the behavior of a single process, that is, an expression not including the communication (step 230). In this case, it is obvious that the elimination theorem can be used to transform the equation (6) into the following equation (7) which does not include parallelism and communication by using an axiom.

[Equation 31]

The term (a) in the equation (7) indicates that the input specifications correctly satisfy the example, the term (b) corresponds to the state transition that does not return to the initial state, and the term (c) fails on the way. Represents the state transition to be performed.

As a result, when the item (a) is present, the example satisfies the specifications, and when there are only the items (b) and (c), the description of the example is incomplete, and only the item (c) is obtained. In some cases, the verification result that the specification does not satisfy the example is obtained (step 2
40).

The verification result is displayed by the verification result display section 5 to the person who manufactures the software (step 25).
0).

(Sequence Chart and Program Specification Verification Method) FIG. 8 shows a sequence chart and program specification verification method. Focusing on the message reception of one object in the sequence chart, the following expression (8) is obtained and stored in the expression storage unit for sequence chart (step 300).

[Equation 32]

On the other hand, the process operation expression (9) is obtained from the program by the method described above and stored in the program code expression storage section (step 310).

[Expression 33]

Next, the expressions (8) and (9) are called to the verification target setting unit (step 320), and the verification target is considered to be the communication from the process e'to the process p. 10), equation (11), and equation (12).

[Equation 34]

[0063]

[Equation 35]

[0064]

[Equation 36]

Next, the expression (12) representing the communication is transformed into the expression of the behavior of the single process, that is, the expression not including the communication (step 330). The transformation result is as in the following equation (13).

[Equation 37]

The terms (a) and (a ') of the equation (13) indicate that the operation specifications correctly satisfy the example, and (b)
The term represents an operation that fails on the way.

As a result, a verification result is obtained that the specification satisfies the example when there are the terms (a) and (a ′), and does not satisfy the example when there is only the term (b) (step 340). .

The verification result is shown to the person who manufactures the software by the verification result display section 5 (step 350).

(Specification Verification Method of State Transition Diagram, Program and Message Flow Diagram) FIG. 9 shows a specification and program verification method including the state transition diagram, program and message flow diagram.

In this specification verification method, first, the equation (3) obtained from the transition state diagram and the equation (9) obtained from the program are combined to create the action equation of the object (step 42).
0). In the method of composition, first, the received message and the method of the program are composed, then the state transition and the method are composed, and then the behavioral expression of the object is composed.

[0071] To synthesize the received message and methods, objects Considering that cause method p _i of Equation (9) receives a message m _'i, following the relationship activation of the message received and Methods It is expressed as in Expression (14).

[Equation 38]

Next, to synthesize the state transition and the method,
Considering that each s _i of the equation (3) obtained from the state transition diagram includes a plurality of m ′ _i in the equation, each m ′ _i appearing in the equation of s _i is represented by m ′ _i · p _i. Replace with. Let the replaced new expression be s'.

Next, to synthesize the object action expression,
Considering that each s _i is a subset of the set of messages that one object can receive, the received messages that the object can receive and are not included in any s _i are {m ′ _k , ..., M ′. _m }, the motion of the object can be expressed by the following equation (15).

[Formula 39]

By the method of extracting the specification information from the message flow diagram described above, a set of objects obj ₁ , ..., Obj _ι related to communication and functions γ and ρ can be obtained. First, the message name of obj _i is changed as follows using the function ρ. Expression (1 representing the operation of each obj _i
In 5), replace each m _i with ρ _obji (m _i ).

At this time, communication between objects is expressed by the following equation (step 440).

[Formula 40]

Expression (16) is transformed into an expression of behavior of a single process (expression not including communication) (step 450).
The result of the deformation has the form of the following expression (17).

[Formula 41]

Where t _ij and u _k (1 = <i, j, k = <
n) is a formula shown in the following formula (18).

[0078]

[Equation 42] In the equation (18), when all t _ij and u _k are in the form of the equation (a) or the equation (c), it indicates that the communication is performed correctly. Some t _ij , u _k include the form of the equation (b), and m ″ _i ^* ...
When a sequence of the form δ appears, it indicates that the description of the communication path is incomplete. . Any other case indicates that there is an error in communication (step 460).

The verification result is shown by the verification result display section 5 to the person who manufactures the software (step 470).

[0080]

As is apparent from the above description, according to the object-oriented software design support method and the specification verification method between different kinds of design documents / programs of the present invention, specification information of different kinds of software design documents / programs is extracted. However, by considering each software design document / program as a series of processes, considering the verification target as the communication between these processes, and transforming the expression expressing this communication into the expression of the behavior of a single process, -The integrity of the program can be verified.

By thus verifying the consistency of specifications between different types of software design documents and programs, by displaying the verification results obtained by the above verification method to the program creator during program creation, the program creation can be performed accurately. Can be easy. In addition, since the software design document and the program match, a third party can easily check the legitimacy of the program after the program is created.

[Brief description of drawings]

FIG. 1 is a diagram showing a configuration of an object-oriented software design support method according to the present invention and a flow of software creation.

FIG. 2 is a diagram exemplifying a message flow.

FIG. 3 is a diagram illustrating a program.

FIG. 4 is a diagram illustrating a state transition diagram.

FIG. 5 is a diagram illustrating a sequence chart.

FIG. 6 is a diagram illustrating a sequence chart.

FIG. 7 is a diagram illustrating a specification verification method for verifying the consistency between a sequence chart and a state transition diagram.

FIG. 8 is a diagram illustrating a specification verification method for verifying the consistency between a sequence chart and a program.

FIG. 9 is a diagram illustrating a specification verification method for verifying the consistency of a state transition diagram, a message flow diagram, and a program.

[Explanation of symbols]

1 editor section 2 interpreter section 3 storage unit 3 4 Verification Department 5 Verification result display section 6 Message flow diagram 11 programs 12 State transition diagram 17 Sequence chart

Front page continued (72) Inventor Eiji Fukazawa 1-22-4 Miwa Midoriyama, Machida City, Tokyo (72) Inventor Hiroyuki Nakamura 5-9-17 Higashiterao, Tsurumi-ku, Yokohama-shi, Kanagawa (72) Invention Ryosuke Kiyono 122-1 Iwaii, Hodogaya-ku, Yokohama-shi, Kanagawa 2-1 Queen Heights Hodogaya 803 (72) Inventor Takashi Hasegawa 2-24-9 Mohridai, Atsugi-shi, Kanagawa Ken 72 Shinohara Ken Machida-shi, Tokyo Miwa Midoriyama 3-6-6 (56) Reference JP 4-160432 (JP, A) JP 4-333978 (JP, A) JP 3-90934 (JP, A) JP 4- 75133 (JP, A) JP 4-75136 (JP, A) JP 6-274335 (JP, A) (58) Fields investigated (Int. Cl. ⁷ , DB name) G06F 9/44

Claims (4)

(57) [Claims] 1. A message flow diagram showing a communication path between the objects and messages transmitted and received on the communication path, and a state of each object and a state transition due to transmission and reception of the message. A software design document including a state transition diagram shown and a sequence chart showing transmission and reception of messages between the objects is created, and messages of each object and transmission and reception of messages based on the software design documents are created. In an object-oriented software design that creates a program that describes the procedure in a prescribed language, each software design document is created by an editor unit that supports input of pixels and character strings, and the software design document is created by a computer. While referring to it on the screen Program and then the software design document and program information are separated and extracted into graphic information and specification information by an interpreter unit, which extracts the software design document and program graphic information and specification information and stores them in a storage unit. Then, the verification unit combines the software design documents of a predetermined type or program specification information to set the verification target as communication between processes, normalizes this and verifies the consistency between processes, and then displays the verification result. An object-oriented software design support method characterized in that a verification result is fed back to a program designer by a department. 2. A software comprising a plurality of objects, the state transition diagram showing the state of each of the objects and the state transition by sending and receiving messages, and showing the sending and receiving of messages between the objects over time. In the object-oriented software design, which creates a software design document including a sequence chart and a program that describes the message of each object and the procedure of message transmission and reception in a predetermined language based on these software design documents, From the sequence chart, let a process e be a series of messages transmitted or received by one object, and let M be a set of all messages. From the above state transition diagram, a set of a message necessary for an object to transition to a predetermined state and a state before transition is defined as a process S, and The verification target is regarded as the communication from the process e to the process S, and the communication is represented by a set H of hidden processes, a communication function γ, and a hidden operator ΦH, and [Equation 4] [Equation 5] Э _H (e‖S) indicating communication is transformed into the expression Э'H (e‖S) of the behavior of a single process that does not include communication, and A specification verification method that verifies the consistency of the specifications of the sequence chart and the state transition diagram by examining the terms of the behavior formula Э ' _H (e | S). 3. Software comprising a plurality of objects, and a software design document including a sequence chart showing transmission / reception of messages between the objects over time is created, and each software design document is created based on the software design document. In an object-oriented software design that creates a program in which a message of an object and a procedure for sending and receiving the message are written in a predetermined language, a series of messages received by one object from the sequence chart are processed by a process e ′ and all messages. Let M ′ be the set, and A transmission message is extracted by parsing the program, and the transmission message is converted into a process operation expression p consisting of a message, selection, connection, and repetition according to the processing structure of the program. The verification target is regarded as the communication from the process e ′ to the process operation expression p, and the set H of hidden processes and the communication function γ
And the concealment operator Э _H represent communication, and [Equation 10] [Equation 11] Э _H (e′‖p) indicating communication is transformed into the expression Э ′ _H (e′‖p) of the behavior of a single process that does not include communication, and A specification verification method that verifies the consistency of the specifications of the sequence chart and the program by examining the terms of the behavioral formula Э ' _H (e'‖p). 4. Software comprising a plurality of objects, a message flow diagram showing a communication path between the objects and a message sent and received on the communication path, and a state of each object and a state transition by sending and receiving a message. A software design document including a state transition diagram shown and a sequence chart showing transmission and reception of messages between the objects is created, and messages of each object and transmission and reception of messages based on the software design documents are created. In an object-oriented software design that creates a program that describes the procedure in a predetermined language, from the state transition diagram, process a set of messages required for the object to transition to a predetermined state and the state before the transition. Let S be A transmission message is extracted by parsing the program, and the transmission message is converted into a process operation expression p consisting of a message, selection, connection and repetition according to the processing structure of the program, 'If you take action p in response to the _i, the relationship between the message and the operation m' object message m _i · p
_i , each component s of the process S is represented by m ′ _i · p
_i is replaced by _i to be s', and the received message that can be received by the object and does not belong to any s is set as { _m'k , ..., _m'm }, and the action expression obj of the object is generated. Number 15] Next, in the message flow diagram, a set of objects obj ₁ , ..., Obj _ι and a communication function γ (m, m ′) = m indicating that a communication path exists between the objects and a message m is transmitted and received. ″ And a function ρ indicating which channel the message m _i is a message of, and _Replacing each m ′ _i of the equation (15) with the function ρ _obji (m _i ) to obtain obj ′, the communication ΦH between objects is represented by the following equation, and Next, communication Э _H (obj ' ₁ ‖obj' ₂ ‖… ‖obj '
_ι ) is transformed into the following equation that shows the behavior of a single process that does not include communication, and Each component t _ij , u _k (1 = <i, j, k of the above equation (17)
= <N) is expressed as follows, A specification verification method for verifying the consistency of the state transition diagram, the message flow diagram, and the program specifications by examining the forms of t _ij and u _k .