JPWO2015019422A1 - Document creation method and document creation apparatus for embedded software - Google Patents

Abstract

The CPU displays a plurality of document creation screens for embedded software development of the embedded device, and the first setting contents of the specification set by using the specification edit screen (1901) are displayed on the design document edit screen (1911). It is set as the second setting content corresponding to the first setting content in the design document. The specification document edit screen (1901) graphically displays the arrangement and operation specifications of the components to be arranged on the display screen of the embedded device as the first setting contents, and the design document edit screen (1911) displays the information of the embedded device as the second setting contents. With respect to the control specifications of the components arranged on the display screen, the control processing contents of the components are displayed using a predetermined rule diagram indicated by a plurality of figures. The specification document editing screen (1901) and the design document editing screen (1911) are displayed on top of each other on the basis of display switching or component arrangement.

Description

  The present invention relates to a document creation method and document creation device for embedded software to be incorporated in an embedded device.

  In general-purpose software development, various documents such as specifications, manuals, software designs, source codes, test specifications, etc. are created. In the development process (flow), after creating specifications (test specifications, manuals), creating software design documents, creating source code, compiling in the actual environment, It is supposed to work, verify, and fix bugs.

  In creating the above-mentioned various documents, there has been proposed a specification management device that creates an accurate document by managing data of each process such as determination, registration, and update of system and software specifications using a database. . This specification management device classifies the relationship between deliverables and deliverables created in each process into four types: model elements, relationships between model elements, documents and their configurations, and relationships between model elements and document elements. By defining and registering, the document is automatically generated based on the input model element information and the predefined document information (for example, see Patent Document 1 below).

JP 2006-106893 A

  However, conventionally, in each process of development, since different workers share the work, the cooperation between the different processes cannot be smoothly performed. In addition, the accuracy of each document is affected by the level of proficiency of the workers in each process, and there is a problem that low-accuracy documents created by unskilled workers affect other processes (overall). . For example, the programming of the linkage portion between software requires work by a programmer having a certain knowledge, and this programmer is not familiar with the work of other processes.

  For this reason, between workers in different processes, it is not possible to quickly respond to design, change, etc., and the number of man-hours for cooperation increases, and the total man-hours and costs increase easily. For example, GUI development and control development are performed in separate processes, and the cooperation between the components on the GUI screen and the control processing is manually associated one by one. For this reason, it takes much time and effort to link the components on the GUI screen with the control processing.

  The technique of Patent Document 1 cannot flexibly cope with design, change, and the like because the work state in a certain process cannot be output in an easy-to-understand manner when viewed from an operator in another process. As a result, the workers in each process cannot grasp the overall development state and the cooperation state between the processes, and thus cannot smoothly develop the process in charge.

  In recent years, in addition to general-purpose applications such as PCs, embedded software that operates specific applications has emerged. In such embedded software, the interface between the software has been programmed by a skilled programmer to prepare API functions and call each other between the software.

  The embedded software is a specific simple function such as a remote controller, digital camera, IC recorder, etc., and it is desired that the software can be developed more efficiently without being limited to a skilled programmer.

  If you can develop embedded software even if you are not proficient in programming, and you can create a document that can link each process, you can develop embedded software more efficiently.

  In view of the above problems, an object of the present invention is to efficiently develop embedded software.

  In order to achieve the above object, according to the embedded software document creation method of the present invention, the computer displays a plurality of document creation screens in the embedded software development of the embedded device, and the first document is set by using the first screen. The first setting content is set as the second setting content corresponding to the first setting content in the second document on the second screen.

  In addition, the first document graphically displays on the first screen the arrangement and operation specifications of components to be arranged on the display screen of the embedded device as the first setting content, and the second document has the second setting content. With respect to the control specifications of the component arranged on the display screen of the embedded device, the control processing content of the component is displayed on a second screen using a predetermined rule diagram indicated by a plurality of figures, and the first screen and the first The two screens are characterized by display switching or overlapping each other based on the arrangement of the components.

  In addition, when the arrangement of the parts of the first document or the contents of the operation specifications are changed, the contents of the control specifications of the parts of the corresponding second document are changed.

  In addition, when the first screen and the second screen are superimposed and displayed, one of the documents superimposed on the upper side is displayed translucently.

  Further, the rule diagram of the second document is characterized in that a condition and an action of the control processing content of the part are connected and displayed with a line segment starting from the part arranged by the first document.

  A function name of a corresponding program is set in the condition and the action of the control processing content of the second document.

  The component of the first document is an operation button arranged on a display screen of the embedded device.

  The embedded software document creation apparatus of the present invention displays a plurality of document creation screens in embedded software development of an embedded device, and displays the first setting contents of the first document that is set to operate using the first screen. A control unit is provided for setting as a second setting content corresponding to the first setting content in the second document of two screens.

  According to the above configuration, each document necessary for development is centrally managed, and when any one of the documents is corrected, a corresponding portion of another related document is corrected. As a result, a plurality of developers involved in software development can always develop while grasping the development situation including correction of other documents, and software development can be performed smoothly and efficiently.

  According to the present invention, it is possible to efficiently develop embedded software.

FIG. 1 is a diagram for explaining the interface specifications of the embedded software according to the first embodiment. FIG. 2 is a diagram of memory contents of the virtual memory interface according to the first embodiment. FIG. 3 is a flowchart of the contents of data transmission / reception processing using the virtual memory interface according to the first embodiment. FIG. 4 is a diagram illustrating a cooperation example of programs according to the first embodiment. FIG. 5 is a diagram for explaining a method of executing mutual program processing by data change due to polling according to the first embodiment. FIG. 6 is a diagram for explaining a method of executing mutual program processing by event processing according to the first embodiment. FIG. 7 is a diagram for explaining a method for executing mutual program processing via the hardware according to the first embodiment. FIG. 8 is a block diagram of a hardware configuration example of a programming device used for embedded software development according to the first embodiment. FIG. 9 is a diagram illustrating an example of mounting on an embedded device according to the first embodiment. FIG. 10 is a diagram for explaining control development according to the second embodiment. FIG. 11 is a diagram illustrating a design screen for control processing according to the second embodiment. FIG. 12 is a diagram for explaining GUI screen design according to the second embodiment. FIG. 13 is a diagram for explaining a superimposed display of a control process design diagram and a screen design diagram according to the second embodiment. FIG. 14 is a diagram illustrating a display state in which the control process design diagram and the screen design diagram according to the second embodiment are superimposed and one of them is translucent. FIG. 15 is a diagram for explaining a state when the layout of the superimposed display of the control process design diagram and the screen design diagram according to the second embodiment is changed. FIG. 16 is a flowchart of a process of associating a control process and a GUI component according to the second embodiment. FIG. 17 is a diagram for explaining replacement of the control process design diagram and the screen design diagram according to the second embodiment. FIG. 18 is a diagram for explaining association between a plurality of design drawings according to the second embodiment. FIG. 19 is a diagram illustrating a specific example of cooperation between a specification and a design document according to the second embodiment. FIG. 20 is a diagram illustrating a data relationship between the specification information and the design information according to the second embodiment. FIG. 21 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 1) FIG. 22 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 2) FIG. 23 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 3) FIG. 24 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 4) FIG. 25 is a diagram for explaining processing when a component is added according to the second embodiment. (Part 5) FIG. 26 is a diagram for explaining source code generation of processing (function) corresponding to the added component according to the second embodiment. FIG. 27 is a diagram for explaining processing at the time of changing specifications of a plurality of created documents or programs according to the second embodiment.

(Embodiment)
Exemplary embodiments of a document creation method and a document creation apparatus for embedded software according to the present invention will be described below in detail with reference to the accompanying drawings. The embedded software is software embedded in a specific-purpose embedded device whose application (operation) is limited, such as a remote controller, a digital camera, an IC recorder, an in-vehicle device, or a medical device.

(Embodiment 1: Configuration of data transmission / reception using a virtual memory interface)
FIG. 1 is a diagram for explaining the interface specifications of the embedded software according to the first embodiment. In the embodiment, connection between different programs A and B is performed using the virtual memory interface 101. This connection refers to transmission / reception of data exchanged between programs.

  FIG. 2 is a diagram of memory contents of the virtual memory interface according to the first embodiment. For each memory address, data (variables) exchanged between one program (for example, application) A and the other program (for example, OS) B is stored.

  Here, the virtual memory (interface) 101 is used for transmission / reception of the functions of the programs A and B and the function data between the programs A and B. The address written by each function and the address to be read are set in advance.

  In the embedded software, a specific function may be simply executed by order control or the like, and therefore data transmission / reception between the programs A and B is fixed. For example, the data acquired by the function A of the program (application) A by operating the embedded device is set to be written to the address “0000”.

  The function 1 of the program (OS) B is set to read data written at the address “0000” and execute a predetermined process. The function 1 of the program (OS) is set so that a return value of a predetermined process execution result is written to the address “0001”.

  The function A of the program (application) A is set so as to read the data of the address “0001” and execute a predetermined process. The other functions of programs A and B are also set to send and receive data using different addresses.

  FIG. 3 is a flowchart of the contents of data transmission / reception processing using the virtual memory interface according to the first embodiment. In the figure, step S301 shows the contents of the pre-processing performed when the embedded software is developed, and step S304 shows the contents of the execution process after the pre-processing (after incorporating the embedded software into the embedded device).

  As advance preparation of step S301, first, the variable area 1 to be transferred from the function A of the program A to the function 1 of the program B is set (step S302). Next, the variable area 2 of the return value from the function 1 of the program B to the function A of the program A is set (step S303).

  During the execution process after the advance preparation (step S304), the processes of steps S305 to S308 are performed. First, data is written in the variable area 1 by the function A of the program A (step S305). Next, data is read from the variable area 1 by the function 1 of the program B (step S306). Thereafter, the internal calculation is performed by the function 1 of the program B, and the return value of the calculation result is written in the variable area 2 (step S307). Data is read from the variable area 2 by the function A of the program A (step S308).

The process of FIG. 3 will be specifically described with reference to FIG.
a. The address “0000” of the virtual memory interface 101 is set as the variable area 1 to be transferred from the function A to the function 1.
b. The address “0001” of the virtual memory interface 101 is set as the variable area 2 of the return value from the function 1 to the function A.

At the time of operation processing after the above preparation, the programs A and B are as follows. ~ 4. Perform the process.
1. The function A writes data to the variable area 1 (address “0000”).
2. Function 1 reads data from variable area 1 (address “0000”).
3. Function 1 performs an internal calculation and writes the return value of the calculation result to variable area 2 (address “0001”).
4). The function A reads data from the variable area 2 (address “0001”).

  As described above, by setting the addresses to be written and read by the programs on the virtual memory interface 101 for the data exchanged between the programs A and B, the programs A and B can be controlled by the virtual memory interface. This data can be read and the program can be executed based on the data write to the corresponding address 101. Each of the programs A and B can establish cooperation between programs only by the memory read / write operation.

Here, each of the programs A and B may be configured (programmed) so as to execute processing when data is written to a preset address. For example, in the above example, 2.4. Can be programmed as follows.
2 '. The function 1 reads this data when data is written to the address “0000”.
4 '. The function A reads this data when the data is written to the address “0001”.

  FIG. 4 is a diagram illustrating a cooperation example of programs according to the first embodiment. The function A of the program A performs a process of writing the value 10 to the address 0 “0000” and a process of reading the value of the address 1 “0001”. The function 1 of the program B processes the value written at the address 0 “0000” (in the example shown, the value square process), and writes the processed value as a return value to the address 1 “0001”.

  According to the example of the program linkage shown in FIG. 4, the programs A and B can send / receive data to / from other programs and request data processing with only the WRITE function and the READ function. The programs A and B can be executed using only two functions of an address for READ and an address and value for WRITE.

  As described above, if the programs A and B only determine the rules for data transmission / reception via the virtual memory interface 101 (the address, the size of the data, and the contents of the processing) in advance, the programs A and B can interact with each other. Data exchange and transmission of processing requests can be realized very easily.

  In addition, programmers can implement (work) only reading and writing at a specific address in virtual memory, so knowledge and experience of functions such as API are not required, and as a result, programming is not necessary even for a non-skilled programmer. It will be possible to build an environment that can.

(Communication between programs for writing and reading using the virtual memory interface)
Next, in order to transmit to the partner program that the writing and reading in the above-mentioned program cooperation has been performed, the following 1. ~ 3. The method is used.
1. 1. Method for executing mutual program processing by data change by polling 2. A method of executing mutual program processing by event processing Method for executing mutual program processing via hardware

FIG. 5 is a diagram for explaining a method of executing mutual program processing by data change due to polling according to the first embodiment. 1. ~ 3. The program processing is executed according to the procedure.
1. Program (application) A rewrites data.
2. The program (application) B reads at polling (fixed intervals) whether or not data at a predetermined address (address “0000”) has been rewritten.
3. Then, the program (application) B reads the data (DATA1) when the data at the predetermined address (address “0000”) has been rewritten (DATA0 → DATA1), and executes predetermined processing.

FIG. 6 is a diagram for explaining a method of executing mutual program processing by event processing according to the first embodiment. 1. ~ 4. The program processing is executed according to the procedure.
1. At the time of initialization, the program (application) B registers to notify the OS 601 when a change occurs in data at a predetermined address “0000”.
2. The program (application) A rewrites the data at the address “0000” (DATA0 → DATA1).
3. The OS 601 notifies the program (application) B of the change of the address “0000”.
4). The program (application) B reads the data at the address “0000” and starts predetermined data processing.
As described above, in the event processing, all data is written and read via the OS 601.

FIG. 7 is a diagram for explaining a method for executing mutual program processing via the hardware according to the first embodiment. In the virtual memory interface 101, in addition to the data area, data read and functions activated by data write are registered. 1. ~ 3. The program processing is executed according to the procedure.
1. The program (application) A rewrites the data at the address “0000” (DATA0 → DATA1).
2. The CPU 701 calls the function (OnWrite0 ()) from the address “0000” written by the program (application) A and the data (DATA1).
3. The program (application) B reads and executes the rewritten data (DATA1).

  FIG. 8 is a block diagram of a hardware configuration example of a programming device used for embedded software development according to the first embodiment. In FIG. 8, the programming device 800 includes a control unit (CPU) 801, a read-only memory (ROM) 802, and a random access memory (RAM) 803. Further, a storage unit 804 such as a semiconductor memory or a disk drive, a display 808, a communication interface (I / F) 809, a keyboard 810, a mouse 811, a scanner 812, and a printer 813 may be provided. These CPU 801 to printer 813 are connected by a bus 814.

  The CPU 801 is an arithmetic processing device that performs overall control when the embedded software is created by the programming device 800. The ROM 802 is a non-volatile memory that stores programs necessary for creating embedded software. A RAM 803 is a volatile memory used as a work area when the CPU 801 executes arithmetic processing.

  A communication interface 809 controls an internal interface with the network 815 and controls input / output of data from an external device. Specifically, the communication interface 809 is connected to a local area network (LAN), a wide area network (WAN), the Internet, or the like serving as the network 815 through a communication line, and is connected to another device via the network 815. For the communication interface 809, for example, a modem or a LAN adapter can be employed.

  The display 808 includes various specifications and design documents for embedded software development, such as GUI (Graphical User Interface) screen design in operation specifications and program design document design screens, including cursors, icons, and tool boxes. This is a device for displaying data such as documents, images, and function information. As the display 808, for example, a Thin Film Transistor (TFT) liquid crystal display, a plasma display, an organic EL display, or the like can be adopted.

  Then, in the development of the programs (applications) A and B described above, the pre-processing S301 shown in FIG. 3 is performed using the programming device 800 shown in FIG. Thereafter, the execution processing step S304 shown in FIG. 3 may be executed in the embedded device.

(Implementation example)
FIG. 9 is a diagram illustrating an example of mounting on an embedded device according to the first embodiment. An embedded device whose use is limited stores programs (applications) A and B in a predetermined memory, and uses the virtual memory interface 101 provided by the OS 901 for data transmission / reception between the programs (applications) A and B. . Although not shown, the embedded device executes operation processing of these programs (applications) A and B, the OS 901, and the virtual memory interface 101.

  In the conventional interface, the program A is called by calling the API of the program B so that the programs are linked. In this case, it is necessary to read the API specification carefully, it must be associated with an appropriate function and factor, and programming by a skilled programmer is required.

  On the other hand, according to the first embodiment, data is transmitted / received between programs via the virtual memory interface. In the embedded software, each program is developed for each function module (for example, for each recording function and display function in the case of a recorder). According to the embodiment, at this time, it is not necessary to perform special programming such as using an API function for cooperation between programs, and it is possible to develop embedded software for which the user is responsible without knowledge of programming. become. In addition, embedded software development can be performed regardless of programming language or language (race) between programmers.

  Thereby, the program quality of embedded software development can be improved, and efficiency and cost can be reduced. Furthermore, embedded software development can be performed without a super programmer who supervises software development, and labor costs can be reduced.

  In addition, data transmission / reception between programs becomes clear at the prototype stage of embedded devices, and trial and error of programming (data transmission / reception) can be performed easily and easily, so that verification work at the prototype stage can be performed efficiently and smoothly.

(Embodiment 2: Cooperation between GUI development and control development)
In the second embodiment, cooperation of a plurality of documents in embedded software development will be described. This cooperation can also be performed using the programming device 800 shown in FIG.

  Conventionally, for example, the GUI screen design in the operation specification and the control processing (program description) in the program design are performed in separate steps, but in the second embodiment, these specifications (for example, GUI development) are performed. And design documents (for example, control development) are linked in an easy-to-understand manner.

  FIG. 10 is a diagram for explaining control development according to the second embodiment. As illustrated, in the embodiment, in the embedded software development, control is designed using a rule diagram without using conventional control processing (program description). The processing contents of the program description are expressed using a rule diagram 1000 composed of a combination of figures.

  In the rule diagram 1000, as shown in FIG. 10, a condition 1001 and an action 1002 are used as control processing components. Then, the action 1002 is executed when the condition 1001 is met. Connecting the condition 1001 in series represents a logical product (AND) condition, and connecting the condition 1001 in parallel represents a logical sum (OR) condition. At the time of control development, the rule diagram 1000 is created by systematically connecting these conditions 1001 and actions 1002 along the control processing procedure.

  FIG. 11 is a diagram illustrating a design screen for control processing according to the second embodiment. A control processing component list 1110 is displayed in the right column of the display screen of the control processing design diagram 1100 using the rule diagram 1000. In the control processing component list 1110, the conditions 1001, the action 1002, and the like shown in FIG.

  Then, an item required at the time of designing the control process is selected from the control process component list 1110 and arranged at an appropriate position on the rule diagram 1000 by an operation (drag and drop). Then, after the placement of the control processing components (condition 1001 and action 1002), the contents of the condition 1001 and action 1002 are set to determine the control operation. In the example of FIG. 11, in the rule diagram 1000, the condition 1001 and the action 1002 are set based on the operation of the embedded device (for example, the operation of the start button 1120 and the stop button 1130).

  FIG. 12 is a diagram for explaining GUI screen design according to the second embodiment. As illustrated, in the embodiment, in embedded software development, a GUI frequently used for an embedded device is designed using a screen design diagram 1200.

  On the screen design diagram 1200, the function of the operation screen of the embedded device is simply shown for convenience. For example, the start (START) button 1201 of the embedded device, the stop (STOP) button 1202, and other function buttons 1203 are displayed. Design and edit layouts.

  For example, a GUI component list 1210 is displayed in the right column of the display screen of the screen design drawing 1200. In the GUI component list 1210, a start (START) button 1201, a stop (STOP) button 1202, other function buttons 1203, and the like are arranged in advance. Then, a button necessary for designing the GUI screen is selected from the GUI component list 1210 and arranged at an appropriate position on the screen design diagram 1200 by an operation (drag and drop). Then, after the GUI component is arranged, the GUI screen is designed by setting the color and wording of the GUI component (for example, the word indicating the color and function for each function).

  When designing the control process, the display screen of the control process design diagram 1100 (rule diagram 1000) shown in FIG. 11 is used, and when the GUI screen is designed, the screen is switched to the display screen of the screen design diagram 1200 shown in FIG. At this time, on the control processing design diagram 1100 (rule diagram 1000) shown in FIG. 11, the start (START) button 1201 and the stop (STOP) button 1202 shown in FIG. 12 are arranged at the same position.

  FIG. 13 is a diagram for explaining a superimposed display of a control process design diagram and a screen design diagram according to the second embodiment. The screen design diagram 1200 shown in FIG. 12 is superimposed on the display screen of the control process design diagram 1100 shown in FIG. For example, the screen design drawing 1200 positioned above the overlay is displayed as a semi-transparent display so that the control processing design drawing 1100 positioned below can be visually recognized. However, the present invention is not limited to this, and the control process design diagram 1100 and the screen design diagram 1200 may be switched to each other or displayed in parallel on the same screen.

  Further, the screen display is not limited to the two control processing design diagrams 1100 and the screen design diagram 1200, and the display screens of three or more documents can be overlapped, switched, or displayed in parallel.

  In any case, the display (coordinates) position of the start (START) button 1201 on the control process design diagram 1100 and the screen design diagram 1200 is the same position. Similarly, the display (coordinates) position of the stop (STOP) button 1202 in the control processing design drawing 1100 and the screen design drawing 1200 is the same position. For the sake of convenience of explanation, only the start and stop of the embedded device have been described as the functions of the operation screen of the embedded device, but other functions that are the starting point of the control process and the GUI screen should be arranged in the same manner. Can do.

  FIG. 14 is a diagram illustrating a display state in which the control process design diagram and the screen design diagram according to the second embodiment are superimposed and one of them is translucent. In the example of FIG. 14, the control processing design diagram 1100 is displayed in a translucent manner (in the drawing, a dotted line for convenience) with respect to the screen design diagram 1200. In this way, by superimposing and displaying the control process design diagram 1100 and the screen design diagram 1200, it becomes possible to intuitively understand the cooperation between the operation on the GUI screen and the control process. In the example of FIG. 14, it is possible to design the GUI screen design diagram 1200 while referring to the control process of the control process design diagram 1100.

  In contrast to FIG. 14, the screen design diagram 1200 is displayed semi-transparently with respect to the control process design diagram 1100, so that the control process of the control process design diagram 1100 can be performed with reference to the GUI screen design diagram 1200. It becomes possible to design.

  FIG. 15 is a diagram for explaining a state when the layout of the superimposed display of the control process design diagram and the screen design diagram according to the second embodiment is changed. 14 shows a state where the layout has been changed by moving the start (START) button 1201 and the stop (STOP) button 1202 to the right on the screen design diagram 1200 shown in FIG. Thus, when the button arrangement on the screen design drawing 1200 is changed, the control processing design drawing 1100 (rule diagram 1000) is also moved to the right in accordance with the change.

  In the example of FIG. 15, the conditions 1001 and the action 1002 starting from the start (START) button 1201 and the conditions 1001 and the action 1002 starting from the stop (STOP) button 1202 do not overlap each other. The layout is changed. When the layout is changed, the rule diagram 1000 can be changed to a flexible form by changing the connection positions of the lines connecting the buttons, conditions, and actions.

  FIG. 16 is a flowchart of a process of associating a control process and a GUI component according to the second embodiment. The control processing shown in the control processing design diagram 1100 and the processing for associating the GUI components shown in the screen design diagram 1200 will be described. This processing is executed by the programming device 800.

  First, the programming device 800 superimposes and displays the screen of the control process design diagram 1100 and the GUI screen design diagram 1200 (step S1601). Thereafter, the corresponding control processing component (condition 1001, action 1002) in the control processing design diagram 1100 and the GUI components (start (START) button 1201, stop (STOP) button 1202) in the screen design diagram 1200 are selected. (Step S1602).

  The programming device 800 stores the screen of the superimposed control processing design diagram 1100, information of the GUI screen design diagram 1200 (including the coordinate position of each component), and information on the associated control processing component and GUI component. The data can be displayed on the display by being read from the storage unit 804 and can be edited later.

  The association process is not limited to the above, and a GUI component in the screen design diagram 1200 may be selected, a control processing component in the control process design diagram 1100 corresponding to this GUI component may be selected, and associated with each other.

  FIG. 17 is a diagram for explaining replacement of the control process design diagram and the screen design diagram according to the second embodiment. FIG. 17 shows a state in which two GUI screen design drawings 1200 a and 1200 b are associated with one control processing design diagram 1100. In this figure, two buttons 1201a and 1202a in one screen design diagram 1200a are examples in which characters are displayed in Japanese, and two buttons 1201b and 1202b in the other screen design diagram 1200b are examples in which characters are displayed in English. .

  As described above, when the screen design drawings 1200a and 1200b are different in character notation, the components for control processing in the control processing design diagram 1100 (in the example shown, only the actions 1002a and 1002b are described in common) are used in common. be able to. In such a case, a plurality of screen design diagrams 1200a and 1200b can be prepared for each language for one control process design diagram 1100. For example, “button A” (1201a) in Japanese of the screen design diagram 1200a and “Button A” (1201b) in English of the screen design diagram 1200b are both in the action 1002a of the common control processing design diagram 1100. Connected.

  The programming device 800 associates the screen design drawings 1200a and 1200b of these two GUIs with one control processing design diagram 1100, and mounts the information on the associated states in the embedded device. In the embedded device, when Japanese notation is selected by a user operation, the screen design diagram 1200a may be validated and the screen design diagram 1200b may be invalidated as illustrated. When English notation is selected, the screen design diagram 1200b is validated and the screen design diagram 1200a is invalidated.

  According to the above configuration, one control process can be set by switching (replacing) a plurality of GUI screens. In the above example, GUI language switching has been described as an example. However, the present invention is not limited to this, and the display of various GUI screens according to the size of GUI components, the size of characters (fonts), the types of characters, and user preferences, The control process can be made common and the GUI screen can be switched.

  Thereby, it is possible to flexibly cope with specification changes, and for example, it is possible to add or change different GUIs later. In addition to the above example, one GUI screen can be set by switching to a plurality of control processes.

  FIG. 18 is a diagram for explaining association between a plurality of design drawings according to the second embodiment. In FIG. 18, in addition to the association between the screen design diagram 1200 and the control processing design diagram 1100 described above, an I / O design drawing and an event (Event) design drawing are also added to associate each other. It is.

  The association between the GUI screen design diagram 1200 and the control process design diagram 1100 of the control process is as described above. In addition to this, a different display screen may be used for each input having different properties such as the physical input / output I / O design diagram 1801 and the event design diagram 1802 of the inter-task signal. In the illustrated example, each I / O condition in the I / O design drawing 1801 and each event in the Event design drawing 1802 are all connected to an action 1002 in the control processing design drawing 1100.

(Specific examples of cooperation between specifications and design documents)
FIG. 19 is a diagram illustrating a specific example of cooperation between a specification and a design document according to the second embodiment. In FIG. 19, the screen design diagram 1200 described above is edited by editing the specification editing screen 1901 (display color editing of buttons on the screen), and the control processing design diagram 1100 described above is edited by the design document editing screen 1911. An example is shown.

  A screen setting diagram 1902 and a display / operation list diagram 1903 are arranged on the specification document edit screen 1901, and a display message list 1904 and a screen changeover switch 1905 are provided below the screen setting diagram 1902.

  On the screen setting diagram 1902, desired components (blue button 1906 and red button 1907 in the illustrated example) are set and arranged at desired positions. The display / operation list 1903 describes operation specifications for the arranged components (blue button 1906, red button 1907). For example, as shown in the drawing, the operation 1909 “display blue” when the “blue button is pressed” is described as the condition 1908. The same applies to red.

  A screen setting diagram 1912 and a display / operation list diagram 1913 are arranged on the design document editing screen 1911, and a display message list 1914 and a screen changeover switch 1915 are provided below the screen setting diagram 1912.

  Parts arranged in the screen setting diagram 1912 (blue button “Button_Blue” 1906, red button “Button_Red” 1907) are displayed at the same coordinate position. Display / operation list FIG. 1913 describes a display color as an operation 1917 for the condition (button operation) of the arranged components (blue button 1906, red button 1907). For example, when the “blue button 1906” is operated, a display color “Button_BlueDisplay” and a function for the program are described using a name corresponding to the program implementation.

  The specification editing screen 1901 and the design document editing screen 1911 can be switched between each other by operating the screen switching switches 1905 and 1915. Further, not limited to switching, as described above, they can be displayed on the same screen.

  The contents edited on the specification edit screen 1901 can be converted into an instruction manual (manual) 1921 and a test specification 1922. In addition, the editing contents on the design document editing screen 1911 can be converted into a debug specification 1923. Further, the source code of the program 1924 can be generated based on the editing contents of the design document editing screen 1911.

  FIG. 20 is a diagram illustrating a data relationship between the specification information and the design information according to the second embodiment. The contents edited by the specification editing screen 1901 and the design document editing screen 1911 are sequentially stored in the storage unit 804 of the programming device 800.

  The programming device 800 lists the list of conditions 1908 in the display / operation list diagram 1903 and the operation 1909 corresponding to each condition 1908 as the specification information 2001 by editing the specification edit screen 1901. The association with the operation 1909 is set. Also, for the design document information 2011 by editing the design document editing screen 1911, the operations 1917 corresponding to the conditions 1916 are listed, and the correspondence between the conditions 1916 and the operations 1917 is set.

  The specification information 2001 is stored in the specification database (DB) 2002, and the design information 2011 is stored in the design database (DB) 2012. In addition to the specification DB 2002 and the design data DB 2012, the various specifications shown in FIG. 19 are converted into a database and stored in the storage unit 804 of the programming device 800.

  The programming device 800 also associates the specification information 2001 and the design information 2011. That is, each condition 1908 of the specification document information 2001 is associated with each condition 1916 of the design document information 2011. Further, each operation 1909 of the specification document information 2001 is associated with each condition 1917 of the design document information 2011.

(Processing when adding a part: Example of adding a button)
Next, processing contents when adding a component (function) will be described using an example in which a button is newly added and a display color is set. Processing contents performed by the programming device 800 will be described.

  FIGS. 21 to 25 are diagrams for explaining processing when a component is added according to the second embodiment. An example in which another component (yellow button 2101) is newly added in addition to the components (blue button 1906, red button 1907) shown in FIG. 19 will be described.

  As shown in FIG. 21, when the yellow button 2101 is added, first, (1) the component (yellow button) 2101 is arranged at a predetermined position on the screen setting diagram 1902 of the specification edit screen 1901. Corresponding to this arrangement, the programming device 800 automatically arranges the component (yellow button) 2101 at the same position on the screen setting diagram 1912 of the design document edit screen 1911.

  (2) On the specification editing screen 1901, the programming device 800 corresponds to the yellow button 2101 arranged on the screen setting diagram 1902, and the specification for the yellow button 2101 arranged in the display / operation list diagram 1903. An explanation (operation) area 2102 is automatically created. At this time, the content of the specification explanation (operation) area 2102 is left blank.

  (3) Next, the programming device 800 displays the display / operation list 1913 on the design document edit screen 1911 corresponding to the specification explanation (operation) area 2102 created in the display / operation list diagram 1903 on the specification edit screen 1901. A specification explanation (operation) area 2103 is automatically created. At this time, the content of the specification explanation (operation) area 2103 is blank.

  Thereafter, as shown in FIG. 22, specifications are described in a specification explanation (operation) area 2102 of the specification document editing screen 1901 and a specification explanation (operation) area 2103 of the design document editing screen 1911, respectively. More specifically, (4) specification description (operation) area 2102 describes the operation “display yellow” when the condition “yellow button is pressed” as the specification of the yellow button 2101. Also, (5) Specification Description (Operation) area 2103 describes “Button_YellowDisplay” as a processing function. At this time, if there is a specification / function database (DB) 2201 in the programming device 800, processing (function) for the yellow button 2101 can be automatically set by referring to this. Finally, (6) the name “Button_Yellow” of the yellow button is described in the part (yellow button) 2101 arranged on the screen setting diagram 1912 of the design document editing screen 1911.

  In association with the processing shown in FIG. 21, the programming device 800 associates and stores the specification information and the design information as shown in FIG. The contents of additional information for FIG. 20 will be described with reference to FIG. (4) In the specification information 2001, “Yellow button pressed” is added to the condition list 1908 as the condition 2301, and “display yellow” is added to the action list 1909 corresponding to the condition list 1908 as the action 2302. .

  Also, (5) “Button_YellowDisplay” is added to the operation list 1917 as the process (function) 2303 in the design document information 2011. Finally, (6) “Button_Yellow :: OnClick” indicating the operation of the yellow button is added as a condition 2304 to the condition list 1916.

  After the processing of FIG. 22, as shown in FIG. 24, (7) In the design document editing screen 1911, the component (yellow button) 2101 and the corresponding processing (function) 2103 are used using the mouse of the programming device 800 or the like. Are connected to each other (line 2401 in the figure).

  24, for the design document information 2011 shown in FIG. 25, the programming device 800 (8) condition 1916 “Button_Yellow :: OnClick” and processing (function) 1917 “Button_YellowDisplay” corresponding to the condition 1916. ”(Line 2501 in the figure). Further, the condition 1908 “Yellow button pressed” of the specification document information 2001 is associated with the condition 1916 “Button_Yellow :: OnClick” of the design document information 2011 (line 2502 in the figure).

(Processing when adding parts: Generating source code)
FIG. 26 is a diagram for explaining source code generation of processing (function) corresponding to the added component according to the second embodiment. After the processing at the time of component addition shown in FIGS. 21 to 25, the programming device 800 additionally generates (9) source code of processing (function) corresponding to the added component (yellow button) 2101, and other buttons. A program 1924 composed of source code including the above process is generated. At this time, the processing 2601 “SetPanel (“ Yellow ”);” is manually written in the source code “Button_YellowDisplay” of the program 1924 (10).

  FIG. 27 is a diagram for explaining processing at the time of changing specifications of a plurality of created documents or programs according to the second embodiment. The programming device 800 associates a specification editing screen 1901, a design document editing screen 1911, and a program 1924 with each other. Therefore, when any of the specification editing screen 1901, the design document editing screen 1911, and the program 1924 is changed to any screen, any code, or any part, the programming device 800 displays other screens, The change is automatically reflected in the part corresponding to the code.

  In general, software development involves: (1) Specification creation (test specification creation, manual creation), (2) Software design creation, (3) Source code creation, (4) Compilation in actual machine environment, (5) It is performed in the order of actual machine operation. The development involves specification designers, software designers, programmers, manual developers, and test designers.

  The programming device 800 according to the second embodiment centrally manages each document necessary for development, and when any document correction is performed, the corresponding part of another related document is corrected. As a result, a plurality of developers involved in software development can always develop while grasping the development situation including correction of other documents, and software development can be performed smoothly and efficiently.

  In the above description, the buttons are arranged as components, and the operation conditions and operation setting examples have been described. can do. Further, not only the setting of screen design (GUI) components but also a plurality of documents related to the setting of UI can be similarly associated.

  According to the second embodiment, in software development, GUI development and control development can be linked, and a document created in one development can be reflected (created) in the other development. As a result, it is possible to reduce the time and effort required to create individual documents for GUI development and control development, and development is possible even if the development procedures described above are different (changed). This makes it possible to reduce software development man-hours and costs.

  The second embodiment is suitable for linking documents of each development process in embedded software development of an embedded device for a specific application. As a result, it is possible to omit processing related to document creation that has been performed in GUI development and control development, and to perform embedded software development smoothly and efficiently.

  As described above, the present invention is useful for embedded software and the development thereof, and particularly useful for the embedded software incorporated in a specific-use embedded device whose use is limited and the development thereof.

DESCRIPTION OF SYMBOLS 101 Virtual memory interface 800 Programming apparatus 804 Memory | storage part 808 Display 809 Communication interface 810 Keyboard 811 Mouse 812 Scanner 813 Printer 814 Bus 815 Network 1001 Condition 1002 Action 1901 Specification edit screen 1911 Design document edit screen A, B Program

Claims (8)

Computer
Display multiple document creation screens for embedded software development of embedded devices,
Setting the first setting contents of the first document set for operation using the first screen as the second setting contents corresponding to the first setting contents of the second document on the second screen;
A method for creating a document of embedded software, characterized by executing processing. The first document graphically displays on the first screen the arrangement of components and operation specifications to be arranged on the display screen of the embedded device as the first setting content.
The second document relates to a control specification of the component arranged on the display screen of the embedded device as the second setting content, and uses a predetermined rule diagram showing the control processing content of the component by a plurality of figures. Displayed on the
The first screen and the second screen are displayed on top of each other based on display switching or the arrangement of the components.
The embedded software document creation method according to claim 1.   3. The document creation of embedded software according to claim 2, wherein the content of the control specification of the part of the corresponding second document is changed when the arrangement of the part of the first document or the content of the operation specification is changed. Method. When displaying the first screen and the second screen in a superimposed manner, one of the documents superimposed on the upper side is displayed in a translucent manner.
The embedded software document creation method according to claim 2 or 3. The rule diagram of the second document is displayed by connecting the condition and action of the control processing content of the part with line segments starting from the part arranged by the first document.
The embedded software document creation method according to any one of claims 2 to 4. A function name of a corresponding program is set in the condition and the action of the control processing content of the second document;
The embedded software document creation method according to claim 5.   7. The embedded software document creation method according to claim 1, wherein the component of the first document is an operation button arranged on a display screen of the embedded device.   A plurality of document creation screens in the embedded software development of the embedded device are displayed, and the first setting contents of the first document set for operation using the first screen are the first setting contents of the second document on the second screen. A document creation apparatus for embedded software, characterized in that it includes a control unit that sets the second setting content corresponding to the.

Images