JP2015162218A - Software development apparatus and software development method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a software development apparatus and software development method capable of managing a model files which are edited and created under graphic language circumstances in a version management system in an easy-to-comprehend manner.SOLUTION: A control logic written using a graphic language is created. A comment is generated corresponding to the respective versions of the control logic. The model file of the control logic written using a binary format for storing the comment in a repository responding to a registration operation for registering the control logic in the repository of the version management system while associating with the respective versions of the model files.

Description

  The present invention relates to version management in software development.

  Graphic languages are used in the development of programs. The graphic language is an expression system for expressing control logic and the like visually in a block diagram format. In the graphic language, for example, the control logic is expressed by a block diagram in which icons (stencils) indicating functional elements (for example, expressing control elements) are connected by lines indicating input / output. A programmer can generate control logic by manipulating a graphic language on a display screen using a GUI (graphical user interface).

  In an embedded system such as an engine controller (ECU), program development using a graphic language is mainstream. In such development, a program is described in a block diagram format using a graphic language programming environment. An implementation code is automatically generated based on the block diagram. By downloading the implementation code to the embedded system of the actual machine, the control target can be actually controlled. Such a program development method is called model-based development. As a graphic language programming environment, for example, Simullink (trademark) of The MathWorks and Scillab (trademark) are known.

  In software development, when performing programming jointly, version management is required to maintain consistency between modules. Even when programming alone, version management is necessary when the development scale is large. It is common to use a software product configuration management tool (version management system) for version management. As file version management tools, for example, Subversion and CVS (Current Versions System) are well known.

  Patent Documents 1 to 5 are examples of techniques for graphic language and software version management.

JP 2002-41313 A JP 2004-535021 A Japanese Patent No. 5120166 JP 2011-34419 A JP 2008-21001A

  Programming in a graphic language programming environment (block diagram format program development tool) using graphic blocks is also called modeling. In modeling, a saved file is called a model file.

  Management of model files edited and created in a graphic language environment is a manual practice. For example, version management (version management) is performed by creating a plurality of folders in the file system and storing model files having different versions in each folder. Alternatively, version management is performed by attaching a file name indicating the version to each version of the model file. However, manual management has problems such as complicated work and human error.

  Model files edited and created in a graphic language environment can be managed by a version control system. The version management system has a repository that is a database that registers created files in a storage area by distinguishing them by version. Each version of the model file can be registered in the repository.

  However, the model file is a binary format file depending on the graphic language environment. Therefore, when the model file is registered in the repository of the version management system, there is a problem that it is difficult to confirm the changed part and compare the differences between versions.

  There is a demand for a technique that enables a model file edited and created in a graphic language environment to be managed in an easy-to-understand form by a version management system.

  In one aspect of the present invention, a software development apparatus includes a graphic language program editing unit that creates control logic described in a graphic language, a comment generation unit that generates a comment corresponding to each version of the control logic, and a control logic. A file writing unit for storing a comment in the repository in association with each version of the model file in response to a registration operation for registering the model file described in the binary format in the repository of the version management system;

  In another aspect of the present invention, a software development method includes a step of creating a control logic described in a graphic language, a step of generating a comment corresponding to each version of the control logic, and a description of the control logic in a binary format. Storing a comment in the repository in association with each version of the model file in response to a registration operation for registering the model file in the repository of the version management system.

  In still another aspect of the present invention, a program causes a computer to execute the software development method according to the present invention.

  A technology is provided that makes it possible to manage model files edited and created in a graphic language environment in an easy-to-understand form with a version control system.

FIG. 1 shows a system configuration in an embodiment of the present invention. FIG. 2 shows a V-shaped model of the software development process. FIG. 3 shows a flow of software development using a graphic language. FIG. 4 is a block diagram showing the configuration of the software development apparatus. FIG. 5 is an explanatory diagram of a work workflow in the graphic language programming environment. FIG. 6 shows a model editing screen. FIG. 7 shows the structure of version management data.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. FIG. 1 shows a system configuration in an embodiment of the present invention. The server 1 is connected to the terminals 2-1 to 2-n via the information communication network 5. The server 1 and the terminals 2-1 to 2-n are computers. The server 1 provides the terminals 2-1 to 2-n with the functions of a graphic language programming environment and a version management system.

  FIG. 2 shows a V-shaped model of the software development process. Steps S10 to S13 indicate a development process, and steps S14 to S16 indicate a test process. In step S10, a requirement definition is made, and a requirement definition document is created as a product. In step S11, a basic design specification is determined based on the requirement definition document, and a system specification document is created as a product. In step S12, a detailed design specification is created based on the system specification, and a control logic model is created as a product. In step S13, a program code for mounting the control indicated by the control logic model on the control target is produced. This program code is referred to as modeling code, and is a code of a level described in, for example, C language and mounted on an actual machine.

  In step S14, a unit test is performed at a level corresponding to the control logic model created in step S12 using the modeling code. If the unit test is passed, in step S15, the integration test is performed at a level corresponding to the system specification in step S11. If the integration test is passed, in step S16, a system test is performed at a level corresponding to the requirement definition document in step S10, and the system is completed.

  Software development using the graphic language in the present embodiment particularly relates to steps S12 to S13. FIG. 3 shows a flow of software development using a graphic language.

  The developer accesses the server 1 from the terminals 2-1 to 2-n. The server 1 activates a development environment using a graphic language and provides it to the terminals 2-1 to 2-n (step S20). The developer creates and edits a model (graphic logic) of a development target system in a graphic language. A binary model file is generated from the graphic logic by the graphic language development environment (step S21).

  For each model file, the developer edits meta information indicating the version, a location corrected by development, an annotation, and the like as model file attributes (step S22). When registering the model file in the repository of the version management system, the model file attribute is also associated with the model file and registered in the repository (step S23). The developer ends the graphic language environment (step S24).

  Various kinds of information can be considered as the meta information. As an example, there is information defined by Dublin Core (ISO 15836). In that case, it is desirable that a template for describing meta information is activated when a developer performs a predetermined input operation in the graphic language development environment.

  By such processing, meta information or the like is registered as a model file attribute in the repository of the version management system in association with the model file. The developer can read out the model file attribute from the version management system when the model file is re-edited later or when the model file edited by another developer is re-edited. By reading out the model file attribute, it is possible to know information such as the model file editor and the corrected part of the previous version.

  The registration of the model file attribute as described above will be described in detail below. FIG. 4 is a block diagram showing the configuration of the software development apparatus in this embodiment. The server 1 of FIG. 1 provides the graphic language programming environment 31, the version management system repository 33, and the file system 32 in FIG. The server 1 further provides a version management system (not shown).

  The graphic language programming environment 31 includes a human input / output unit 34, a graphic language program editing unit 35, a file reading / writing processing unit 36, a numerical operation processing unit 37, and a comment generating unit 38.

  The human input / output unit 34 includes an input device and an output device. The input device includes a keyboard, a pointing device, a touch panel, and the like, and generates input information by a developer's input operation. The output device includes a display and a printer, and outputs output information generated by the graphic language programming environment 31 using images and characters.

  The graphic language program editing unit 35, the file reading / writing processing unit 36, the numerical operation processing unit 37, and the comment generation unit 38 are included in a tangible, non-transitory recording medium included in the server 1. It is a functional block that is realized by reading and executing the stored program by the arithmetic and control unit of the server 1.

  The file system 32 is a file system provided by the server 1 or the terminals 2-1 to 2-n, and stores a model file and model file attributes (meta attribute file 40, model report file 41). The version management system repository 33 is a storage area provided for the version management system to store model files and the like.

  The work workflow in the graphic language programming environment will be described with reference to FIG. In FIG. 5, the left column 60 shows the work of the programmer (developer), the central column 61 shows the operation of the graphic language programming environment 31 provided by the server 1, and the right column 62 shows the development environment provided by the version management system. .

  The programmer activates the graphic language environment by performing a predetermined input operation on the human input / output unit 34 (step S63). In response to the input operation, the server 1 activates the graphic language programming environment 31 (step S67). The programmer edits the model program. That is, the programmer executes graphic language programming by creating and editing a model (graphic logic, control logic model) in graphic language (step S64). This operation is executed by the model editing screen provided by the graphic language program editing unit 35 (step S68).

  The programmer creates the meta attribute file 40 by the function of the comment generation unit 38. The programmer further creates a report (model report file 41) regarding the created model by the report creation environment provided in the graphic language programming environment 31 (step S65). Both the meta attribute file 40 and the model report file 41 are treated as model file attributes relating to the created model.

  The programmer performs an operation for saving the model edited in step S64 on the human input / output unit 34 (step S66). The file reading / writing processing unit 36 writes the model in the file system 32 and the version management system repository 33. The file read / write processing unit 36 further associates the model file attributes (meta attribute file 40 and model report file 41) created in step S65 together with the model with the model, the file system 32, and version management. Write to the system repository 33 (step S70).

  The model created in this way can be used for controlling an actual machine to be controlled. The graphic language programming environment 31 has a source code generation function for automatically generating a source code described in C language or the like based on a control logic created in the graphic language. The control object can be controlled by downloading the source code to the controller of the embedded system.

  Next, the model editing screen provided by the graphic language program editing unit 35 in step S68 will be described. FIG. 6 shows an example of the model editing screen 51 displayed by the display device of the human input / output unit 34 in step S67. The model editing screen 51 is realized by using the graphic language programming environment 31, and enables creation and editing of control logic through a GUI.

  A toolbar 52 is displayed at the top of the model editing screen 51. A model block display area 54 is provided on the left side below the toolbar 52, and a model file editing area 55 is provided on the right side. In the model block display area 54, a model block (or stencil) 56 is displayed that shows a functional unit of a control system such as a logical operation element or an arithmetic element such as a numerical operation element by a graphical icon. These model blocks 56 can be selected from a model block library provided by the graphic language programming environment 31 and displayed in the model block display area 54 by performing an input operation such as drag and drop.

  The programmer places the model block 56 at a desired position in the model file editing area 55 using a GUI, and connects them with lines indicating the input / output relationship of signals. Further, a block diagram 57 is created by setting parameters and the like for each model block 56. The block diagram 57 is a model representing the control system to be controlled in the form of a block diagram. Based on this block diagram 57, the numerical arithmetic processing unit 37 can calculate the response characteristic of the output signal with respect to the input signal set by the programmer, and can simulate the control system.

  A meta description block 59 is displayed in the model block display area 54. When the programmer depresses the meta description block 59 with a pointing device, a form for creating a comment (model meta information) is activated on the model editing screen 51. The programmer inputs comments (element block comments) on the model block 56, such as changes to the previous version of the model, notes on editing, and items to be sent to other programmers. A meta description block 59 is also displayed in the model file editing area 55. The programmer can input a comment (block diagram comment) for the block diagram 57 in the same manner as the model block display area 54.

  A comment description block such as the meta description block 59 can be incorporated into the model as a user-defined custom block library. In addition to the meta description block 59 illustrated in FIG. 6, a comment description block for recording user-defined comments such as creator, creation date, modification date, modification content, version information, etc. according to the template is also incorporated into the model. Is desirable. In that case, the meta information is also stored in the version management system repository 33 as the meta attribute file 40.

  The file reading / writing processing unit 36 displays a version management cooperation menu 53 on the toolbar 52 of the model editing screen 51. When the programmer finishes editing the model, the programmer presses the version management cooperation menu 53. Then, a model file 39 representing the model given by the block diagram 57 in binary format is registered in the file system 32. Along with the registration, the model file 39 is registered in the version management system repository 33. The version management system stores the model file 39 together with information for specifying the version of the model file 39. As the information for specifying the version, for example, a version identifier uniquely issued for distinguishing from other versions, a registered date and time, a pre-input programmer identifier, or the like can be used.

  In response to pressing of the version management cooperation menu 53, the meta attribute file 40 is registered in the file system 32 and the version management system repository 33 together with the model file 39. For example, a comment created by pressing the meta description block 59 in FIG. 6 is registered as the meta attribute file 40.

  Such a process adds, for example, a function for simultaneously saving a meta attribute file or the like by a script program in accordance with a file saving function provided by the version management system (pressing the version management cooperation menu 53 in FIG. 6). Can be realized.

  In the present embodiment, in response to an input operation of pressing the version management cooperation menu 53, the model file 39 is registered in the version management system, and is associated with the version of the model file 39 to be edited, in a text format or the like. The meta attribute file 40 created in a format independent of the environment is also registered at the same time. Therefore, registration failure of meta information describing differences between versions can be prevented.

  The programmer reads the model file from the version management system using the file reading / writing processing unit 36 when editing a model edited by the programmer in the past or a model edited by another programmer. At that time, the programmer can read the meta attribute file 40 corresponding to the version of the model. Since the model file 39 is described in a binary format, it is difficult to grasp the differences from other versions. However, the programmer can compare and grasp the difference between the versions of the model file 39 by referring to the meta attribute file 40.

  In this embodiment, version management of a model file in which the graphic language programming environment 31 and the version management system are linked can be realized. This facilitates embedded software development using a version of the model file managed by the team development of multiple people. Furthermore, since it is possible to promote the use of version management systems in development sites where customary version management is used, it is easy to understand the differences between versions of model files. .

  Next, the report created in steps S65 and S69 will be described. The graphic language programming environment 31 automatically extracts model information and outputs a report (model report file 41) in a text format (which may be in HTML (Hypertext Markup Language) format or XML (Extensible Markup Language) format). May have the ability to create.

  For example, a file describing the connection relationship and parameters of each model block 56 in the block diagram 57 in a text format or the like is created as the model report file 41. When the parameters set for each model block 56 are changed from the previous version, the date and time of the change, the identification information for identifying the model block 56, the parameters before the change, and the parameters after the change are displayed in the model report. Registered in the file 41.

  The comment generation unit 38 has a function as a model report generation unit that creates such a model report file 41. The model report file 41 is also registered in the file system 32 and the version management system repository 33 when the version management cooperation menu 53 is pressed. Further, it is desirable that the source code automatically generated from the model described in the graphic language by the graphic language programming environment 31 is also registered in the file system 32 and the version management system repository 33.

  FIG. 7 shows the structure of version management data managed by the version management system repository 33. The version management data can be managed by a file system having a tree structure (directory format), for example. The version management data has a structure in which, for example, the first version V1, the second version V2 in which the version V1 is updated, and the third version V3-1 in which the version V2 is updated are chained in series. Furthermore, it is also possible to manage a branch such as a third version derived version V3-2 derived from the second version V2.

  These versions of files are displayed, for example, on the same display screen by icons with version identifiers and update dates. The programmer can refer to the contents of each version by selecting the version identifier or the like.

  When the programmer selects, for example, the second version V2, a selection screen for selecting the model file 39 of the version V2, the meta attribute file 40 linked to the model file, and the model report file 41 is displayed. The programmer performs an input operation for selecting one of them. When the programmer selects the model file 39, the version V2 model can be edited. The programmer selects the meta attribute file 40 and model report file 41 of the version V2 from the selection screen when he / she wants to know the difference between the previous version V1 and the currently open version V2 or the change intention. The contents of the selected files are displayed on the display screen, and the programmer can refer to those files.

1 server 2-1 to 2-n terminal 5 information communication network 31 graphic language programming environment 32 file system 33 repository 34 human input / output unit 35 graphic language program editing unit 36 file reading / writing processing unit 37 numerical operation processing unit 38 comment Generation unit 39 Model file 40 Meta attribute file 41 Model report file 51 Model editing screen 52 Toolbar 53 Version management cooperation menu 54 Model block display area 55 Model file editing area 56 Model block 57 Block diagram 59 Meta description block 60 Left column 61 Center Column 62 Right column V1, V2, V3-1, V3-2 Version

Claims (7)

A graphic language program editor for creating control logic written in a graphic language;
A comment generator for generating a comment corresponding to each version of the control logic;
A file writing unit for storing the comment in the repository in association with each version of the model file in response to a registration operation for registering the model file describing the control logic in a binary format in a repository of a version control system; A software development apparatus comprising: A software development device according to claim 1,
The said comment production | generation part is a software development apparatus which starts the form which receives the input of the said comment by performing predetermined input operation in the screen on which the said control logic was displayed by the said graphic language. A software development device according to claim 1 or 2,
Further, when the control logic is created by the graphic language program editing unit, a model report generation unit that creates a model report file including text data extracted from information included in the control logic,
The file writing unit registers the model report file in the repository in association with each version of the model file in accordance with the registration operation. A software development device according to any one of claims 1 to 3,
The file writing unit further generates a source file generated from the model file according to the registration operation and used to control a control target by the control logic in association with each version of the model file. Software development equipment to register with. A software development device according to any one of claims 1 to 4,
In the graphic language, the control logic is expressed by a block diagram in which a plurality of blocks are connected by lines,
The said comment production | generation part is a software development apparatus which produces | generates the element block comment matched with each of these blocks and the block diagram comment matched with the said block diagram as said comment. Creating a control logic written in a graphical language;
Generating a comment corresponding to each version of the control logic;
Storing the comment in the repository in association with each version of the model file in response to a registration operation for registering the model file describing the control logic in a binary format in a repository of a version control system. To develop software.   A program for causing a computer to execute the software development method according to claim 6.

Images