KR102696519B1 - Automatic programming system and method using programming model - Google Patents

Abstract

A programming system using a requirements model that does not require user intervention for a defined automated task (programming) is disclosed. The programming system is characterized by including an input unit that receives input information for defining the structure and configuring the contents of a plurality of requirements models, a calculation unit that identifies whether there are inconsistent elements among the plurality of requirements models, and if there are no inconsistent elements, integrates the plurality of requirements models to generate an integrated model and generates code information for the integrated model, and a display unit that outputs information on the plurality of requirements models corresponding to the inconsistent elements under the control of the calculation unit.

Description

{Automatic programming system and method using programming model}

The present invention relates to an automatic programming execution technology, and more specifically, to an automatic programming system and method for automating the process of developing a program by introducing a programming model including expressions of all programming languages.

Existing methods for performing automatic programming include methods using mathematical specifications (program synthesis) and methods that combine pieces of programs organized from a specific perspective that are valid in a specific domain but not generalizable (domain specific programming). These methods are difficult to regard as complete automation.

The former required user intervention in the process of programming using the requirements specification provided by the user, while the latter allowed partial automation only for specific predefined functions.

There are methods that utilize artificial intelligence to compensate for these shortcomings, but these methods are also probabilistic approaches based on empirical data. Therefore, user intervention is still necessary. This is because, even if the probability of user intervention is low in a probabilistic approach, the probability exists.

1. Korean Publication Patent No. 10-2019-0025261

The present invention has been proposed to solve the problems according to the above background technology, and its purpose is to provide a programming system and method that can automatically complete a program by only defining requirements by a user using a programming model.

The present invention provides a programming system using a requirements model, which automatically performs programming by allowing a user to define a requirements model using a programming model to achieve the task presented above. The programming model above refers to a model that can mathematically express the control structure of a program.

Here, the control structure is a logic consisting of sequence, selection, and loop. The execution of the program is to assign a new value to the defined data through some action in the context of the control structure.

That is, a program is a structure that uses control structures to structure behavior. Here, an action can be composed of a single sentence, such as a program execution command, or can be composed of a program fragment. Therefore, a program places an action in an intended location among all the control structures that compose the program. A programming model is a model that expresses the control structures that compose the program as a mathematical model and structures data and actions as mathematical expressions.

The above requirements model means that the user's requirements are expressed using a programming model. The present invention provides a programming system that automatically integrates the above requirements models when the user configures them to configure an integrated model, automatically verifies the requirements model and the integrated model, and generates code corresponding to the integrated model.

The above programming system,

Input section for receiving input information for defining the structure and configuring the contents of multiple requirements models;

A computation unit that identifies whether there are inconsistent elements among a plurality of the above requirement models, and if there are no inconsistent elements, integrates the plurality of the above requirement models to generate an integrated model and generates code information of the integrated model; and

It is characterized by including a display unit that outputs component information of a plurality of the requirement models corresponding to the mismatched components according to the control of the operation unit.

At this time, the operation unit is characterized by including a model structure definition module that performs structural definition of a plurality of the requirement models; a configuration module that performs content configuration of a plurality of the requirement models using a piece of code or a single sentence; a structure integration module that integrates a plurality of the requirement models; an inconsistent element identification module that identifies whether there is an inconsistent element between the plurality of the requirement models; and a code generation module that generates the code information if there is no inconsistent element.

In addition, the structure of the above requirements model is

Repeat (proposition) { }

Choice (proposition) { }

A sequence { } (where repetition, selection, and sequence are logical operators, and parentheses and curly brackets express propositions and blocks) , wherein the fragment code and single statement are characterized in that they are within the curly brackets at the bottom of the requirements model structure consisting of the logical operators.

Additionally, the lowermost curly bracket is characterized by being a curly bracket with no further curly brackets within the curly bracket.

In addition, the above-described inconsistent element identification module is characterized by generating guidance information indicating that inconsistent elements should be modified when there are inconsistent elements among the above-described multiple requirement models.

In addition, the above structural definition is characterized in that it is defined using logical operators.

In addition, the above structural definition is characterized by including setting the position of each component, setting the name of each component, setting the logical operator of each component, and setting the data of each component. Here, the position, name, logical operator, and data for various purposes of each component become members of each component.

In addition, the members of each of the above components and the codes corresponding to the members are characterized by being configured in advance as a lookup table.

In addition, each of the above components distinguishes the hierarchical relationship between the components by including the lowest component of the lowest layer, the next higher component located adjacent to the above component, the upper component located above including the next higher component, the next lower component located adjacent to any component, the lower component located below including the next lower component, the top component located above each of the above components, and the lowest component located below each of the above components.

In addition, the above components are characterized in that the order between the components positioned under the same upper-level component is distinguished by a sequential relationship.

In addition, the member name of each of the above components is characterized by being used as a unique identifier to distinguish the components during the automatic programming process.

In addition, each of the above components is characterized by including data related to the proposition and the component.

In addition, the integration is centered on components with the same name, and the members of each component including the logical operator, the proposition, and the data are integrated only for components with the same name, and components that do not have the same name are maintained as is.

In addition, each of the above components is characterized by being expressed as a mathematical model.

On the other hand, another embodiment of the present invention provides an automatic programming method including: (a) a step in which an input unit receives input information for defining the structure and configuring the contents of a plurality of requirement models; (b) a step in which a calculation unit identifies whether there is an inconsistent element among the plurality of requirement models, and if there is no inconsistent element, integrates the plurality of requirement models to generate an integrated model and generates code information of the integrated model; and (c) a step in which a display unit outputs component information of the requirement models for the plurality of requirement models corresponding to the inconsistent elements under the control of the calculation unit.

At this time, the step (b) is characterized by including a step in which a model structure definition module performs a structural definition of a plurality of the requirement models; a step in which a configuration module performs a content configuration of a plurality of the requirement models using a piece of code or a single sentence; a step in which a structure integration module integrates a plurality of the requirement models; a step in which a mismatch element identification module identifies whether there are mismatch elements between a plurality of the requirement models; and a step in which a code generation module generates the code information if there are no mismatch elements.

Additionally, many of the above requirements models are characterized by being classified and managed based on the members of each component.

On the other hand, another embodiment of the present invention provides a computer-readable storage medium storing a program for executing a programming method using a requirements model.

According to the present invention, all structures and contents of code can be mathematically expressed and related, and through this, a machine can integrate individual requirement models, detect grammatical and integrated errors, and automatically generate code.

In addition, another effect of the present invention is that it is possible to add a description composed in natural language as a member of a component in the same way as the method of composing the contents described above for each component, which means that the description can be structured in a mathematical logic-structured form, and that all outputs related to software development can be managed as a mathematically systematized system.

In addition, another effect of the present invention is that it can support the function of completing a program by introducing and combining a requirements model, a structure of a requirements model, and the contents of a requirements model created by another person.

In addition, another effect of the present invention is that it is possible to individually trade requirements models, the structure of requirements models, and the contents of requirements models, and to operate an online/offline platform that performs such trading.

The effect of this invention is possible because the programming model used to construct the requirements model can completely replace the programming language with a mathematical model. Since the programming language is similar to the use of a general language, it is difficult to accurately express the relationship between sentences even if it is clearly described. It is difficult to explain in detail which parts are in contact with each other and which parts are the same information, and it is impossible to express it in a structural form. The advantage of the mathematical expression is that it is possible to clearly identify which symbols are the same symbols and what relationships are established between symbols.

All meaning of a program is physically expressed in a circuit. The circuit performs meaningful actions by changing the data state of 0 and 1 through statements. These statements are structured using logical operators called AND, OR, NOT, and GOTO to become a program. In the concept of structured programming, logical operators on the circuit structure the program statements into control structures called sequence, selection, and loop.

By combining each control structure, it can be expressed equivalently to the structure of a program using logical operators such as AND, OR, NOT, and GOTO. Therefore, if the relationship between control structures of structural programming is expressed mathematically, it is the same as being able to express all logical structures on a circuit.

Since the present invention introduces a model that mathematically expresses the relationship between such control structures, it is possible to mathematically express the control structures of all programming languages.

In addition, if the programming model embraces the differences in statements and data that each programming language has, the programming model can become an expression that integrates the characteristics of all programming languages. Ultimately, all the methods described in the present invention were derived by introducing a mathematical model that expresses the relationships between control structures of programming languages.

The reason why this could not be achieved through existing mathematical modeling is because the relationship between control structures could not be expressed mathematically. The most extensive and widely used mathematical representation known to date is the Turing Machine.

A Turing machine is a method of modeling by assuming that there is an arbitrary program, giving an initial value, and executing the program to obtain the resulting data. In other words, it models the transition relationship of data due to the execution of the program.

This modeling method cannot distinguish the difference in control structures between programs that produce the same results even though the control structures are different. In other words, it has non-determinism for the control structures. This means that the relationship between the control structures cannot be clearly defined, which ultimately makes the correspondence between the model and the code ambiguous. Therefore, the integration (program synthesis) using the mathematical specification based on this modeling concept has not been able to realize automatic programming.

Figure 1 is a block diagram of a programming system according to one embodiment of the present invention.
Figure 2 is a detailed block diagram of the operation unit illustrated in Figure 1.
Figure 3 is a programming concept diagram using a requirements model according to one embodiment of the present invention.
Figure 4 is a flowchart showing a programming process using a requirements model according to one embodiment of the present invention.
Figure 5 is an example of code according to one embodiment of the present invention.
FIG. 6 is an example expressing the positional relationship between components with logical operators omitted according to one embodiment of the present invention.
Figure 7 is an example of a requirements model expressed only in terms of names and positional relationships of components according to one embodiment of the present invention.
Figure 8 is an example of a requirements model to explain the concepts of definition and integration of requirements models together with Figure 7.

The present invention can have various modifications and various embodiments, and specific embodiments are illustrated in the drawings and specifically described in the detailed description. However, this is not intended to limit the present invention to specific embodiments, but should be understood to include all modifications, equivalents, or substitutes included in the spirit and technical scope of the present invention.

In describing each drawing, similar reference numerals are used for similar components. The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only to distinguish one component from another.

For example, without departing from the scope of the present invention, the first component could be referred to as the second component, and similarly, the second component could also be referred to as the first component. The term "and/or" includes any combination of a plurality of related listed items or any item among a plurality of related listed items.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art, and should not be interpreted in an idealized or overly formal sense, unless expressly defined in this application.

Hereinafter, an automatic programming system and method using a requirements model according to an embodiment of the present invention will be described in detail with reference to the attached drawings.

Automatic programming according to one embodiment of the present invention has the following characteristics.

① Provides a method to automatically integrate the user’s requirements model.

② Identifies inconsistent components with the user’s requirements model.

③ Match the structure and content of the requirements model with the code (when model integration is complete, you get the integrated code)

④ The structure and content of the requirements model are expressed mathematically (integration and verification algorithms exist)

How freely a program can be implemented depends on how much knowledge the user has about composing the program. If the user knows only the purpose of the program he needs, he can select a completed program. If the user has the knowledge to modify the structure of the program, he can borrow the completed module according to the purpose of use and change the structure of the program. If the user has all the knowledge about composing the program, he can reconstruct the program from beginning to end.

One embodiment of the present invention provides the utility of mechanical automation for integrating and verifying logical fragments by allowing all such users to use a method of organizing their knowledge of the program into a defined logical formula, a requirements model. If the user does not know much about the program, he cannot know whether the functions configured in the program are the functions that the user wants. Therefore, as explained above, the user can select, configure only part of, or configure all of the program based on his knowledge. It is a misconception about automation that the programming machine automatically implements functions that the user does not know, as in science fiction movies. This situation only means that the user is satisfied with the functions provided by the programming machine.

Therefore, the concept of automatic programming starts from the definition of requirements and the definition of programming. The main concept of the present invention is how the requirements model that a user must provide to a programming machine is structured and what role the programming machine must automatically perform.

FIG. 1 is a block diagram of a programming (i.e., computing) system (100) according to an embodiment of the present invention. Referring to FIG. 1, the programming system (100) may be configured to include an input unit (110) that receives input information for defining the structure and configuring the contents of a plurality of requirement models, a calculation unit (120) that identifies whether there is an inconsistent element between requirement models and, if there is no inconsistent element, integrates the plurality of requirement models to generate code, a display unit (130) that outputs inconsistency information for the plurality of requirement models corresponding to the inconsistent element under the control of the calculation unit (120), and a storage unit (140) that stores information related to the requirement models.

The input unit (110) performs the function of receiving a user's command. Of course, the input information received can be converted into digital information. The input information can be text, but is not limited thereto, and can be voice or action. For this purpose, the input unit (110) can be configured to include a keyboard, a microphone, a touch screen, a camera, a DSP (Digital Signal Processor), etc.

The operation unit (120) identifies whether there are inconsistent elements among the plurality of requirement models, and if there are no inconsistent elements, integrates the plurality of requirement models to generate code. In other words, when the user logicalizes the requirement models in the order of structure definition and content composition, the operation unit (120) integrates the structure of the requirement models, and if there are inconsistent elements among the requirement models, identifies them and informs the user through the display unit (130).

Accordingly, the user modifies the requirements model using the input unit (110). By repeating this process, if the user no longer configures the requirements model and the programming machine does not identify any inconsistent elements, the operation unit (120) integrates the currently configured requirements models to generate code information. Accordingly, the user obtains code in which all requirements models are correctly reflected.

Code is primarily used in the process of creating executable programs, and can be a text file that describes a computer program in a human-readable programming language.

The display unit (130) performs a function of outputting requirement information for a requirement model corresponding to a non-conformance element under the control of the operation unit (120). Of course, a screen for inputting input information to the user, a guidance screen for guiding the input, an execution screen for execution, etc. can be provided. The display unit (130) can be an LCD (Liquid Crystal Display), an LED (Light Emitting Diode) display, an OLED (Organic LED) display, a touch screen, a flexible display, etc. In the case of a touch screen, it can also be used as an input means.

The storage (140) performs a function of storing a requirements model, code information, etc. Of course, it includes a program, software, data, etc. that implements an algorithm that integrates the requirements model. Accordingly, the storage (140) may include a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (for example, an SD (Secure Digital) or XD (eXtreme Digital) memory, etc.), a RAM (Random Access Memory), a SRAM (Static Random Access Memory), a ROM (Read Only Memory, ROM), an EEPROM (Electrically Erasable Programmable Read Only Memory), a PROM (Programmable Read Only Memory), a magnetic memory, a magnetic disk, an optical disk, etc. In addition, it may operate in relation to a web storage that performs a storage function on the Internet, or a cloud server.

Figure 2 is a detailed configuration block diagram of the operation unit (120) illustrated in Figure 1. Referring to Figure 2, the operation unit (120) may be configured to include a model structure definition module (210), a configuration module (220), a structure integration module (230), a mismatch element identification module (240), a code generation module (250), etc.

The model structure definition module (210) receives input information for defining the structure of a requirement model from the input unit (110) and performs the function of defining the structure of the requirement model. In detail, this may include setting the location of each component, setting the name of each component, setting the logical operator of each component, and setting the data of each component.

The configuration module (220) is responsible for configuring the contents of a single requirements model. In other words, the contents may correspond to a single sentence or a piece of code. A piece of code refers to a collection of codes that a user sets in advance for reuse.

The structural integration module (230) performs the function of integrating between requirement models. In other words, integration is performed using the name and location of the component, and for components with the same name, integration is performed between all members of the component.

The inconsistent element identification module (240) performs the function of identifying whether there are inconsistent elements between requirement models. In detail, the inconsistent element identification is performed by dividing into the identification of grammatical errors for individual components, the identification of inconsistencies between components for one requirement model, and the identification of inconsistencies between requirement models.

The code generation module (250) performs the function of generating code information for the integrated requirements model.

The term "~ module" described in the drawings means a unit that processes at least one function or operation, which may be implemented in software and/or hardware. In the hardware implementation, it may be implemented as an ASIC (application specific integrated circuit), a DSP (digital signal processing), a PLD (programmable logic device), an FPGA (field programmable gate array), a processor, a microprocessor, other electronic units, or a combination thereof designed to perform the above-described function. In the software implementation, it may include software configuration components (elements), object-oriented software configuration components, class configuration components and task configuration components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, data, databases, data structures, tables, arrays, and variables, etc. The software, data, etc. may be stored in a storage device and executed by a processor. The storage device or processor may employ various means well known to those skilled in the art.

Figure 3 is a programming concept diagram using a requirements model according to one embodiment of the present invention. Referring to Figure 3, the programming concept diagram can be divided into a user function (310) and a programming machine function (320).

Before explaining Figure 3, let us first explain the concept of automatic programming.

In order to conceptualize the automatic execution of programming, we must distinguish where the user-provided requirements begin and end, and where the machine-performed programming ends. To do this, we must first examine the characteristics of a general program (imperative program). Here, we will explain C code as an example, but other types of programming languages also have the same characteristics in terms of the structure and content of the code.

In any C code, putting curly brackets before and after all sentences except those containing logical operators does not change the meaning of the code at all. These curly brackets clearly distinguish the relationship between sentences and the scope of data usage. The code is actually executed based on this relationship expression, but in text-based programming, this logical structure is omitted for the convenience of programmers. In addition, this is only a method of introducing a mathematical model to algorithmize the structure of the code, and has no effect on the meaning of the existing code. It should be noted that the sentence that assigns a value while declaring a variable should be divided into a variable declaration sentence and a value assignment sentence. In text-based programming, this function is provided for the convenience of the user, but in the concept of automating the structure and content of the code by separating them, this convenience function is a factor that hinders the algorithmization of programming. Since the result of the code composed through automatic programming does not have a limited scope of expression even if it does not use a specific convenience function in coding, this assumption can be generalized.

When curly brackets are added to the existing code as above, the block expressed in the curly brackets is composed of sequential, selection, and repetition logic, and is expressed as a proposition combined with a logical operator. For example, as follows.

while (x==1) { }

Here, while is a logical operator, "x==1" is a proposition, and { } is a block. There are several operators that express the above logic in C code, but only one representative logical operator is used to construct mathematical logic. This is because there is no problem expressing the structure of the code, and redundant expressions should be avoided in mathematical expressions.

Therefore, in one embodiment of the present invention, While, If, and None are used as logical operators for repetition, selection, and sequence. Here, "None" means that there is no operator before the curly brackets. The purpose of structuring the C code in this way is to explain that all codes are divided into structure and content. All codes other than the logical operator blocks defined below are divided into content, and the logical operators below are named as structures.

while (proposition) { }

if (proposition) { }

{ }

In the general code with the curly brackets added as described above, the content exists within the curly brackets configured at the bottom. In the above code, there is a single sentence within the curly brackets located before and after every single sentence, and since there are no more curly brackets inside that sentence, the single sentence is within the curly brackets at the bottom. In other words, the code is divided into the structure of logic and the content at the bottom. This means that a general program (imperative code) is something that is programmed to be implemented by relating single sentences through the structure. This is a characteristic that is commonly applied to all general programs (imperative programs). Therefore, programming means structuring the composition of logic into the structure described above and filling in the appropriate content (single sentence or piece of code) (313) at the bottom.

More specifically, using Figures 5, 7, and 8, the following explanation is provided. When programming, the user first conceptualizes the relationship between macroscopic functions and then concretizes it. Figure 7 shows two modes (Repair Mode, Normal Mode) considered when configuring the Seamark program. At this time, the user can visualize the relationship between the two modes and consider the conditions for the two modes to be executed. Of course, the data to be used can also be configured at this time.

However, there is no need to think about the specific content to be performed in each mode. It is not yet time to consider that. Figure 8 is a form that concretizes the configuration of functions in Normal Mode a little more. There can be four more modes under Normal Mode. At this time, there is no need to consider the two modes (Repair Mode, Normal Mode) above. It is sufficient to consider only the relationship between the four modes under Normal Mode above. At this time, the things to consider would be the location of each component, the name, the logical operator, the proposition combined with the logical operator, the use of data, etc.

Position, name, logical operator, and proposition combined with logical operator are used to visualize the relationship between components. It is to consider how the Seamark program should be structured. After that, the data required for these components to perform the defined function are organized. Through this, the use of control structures and data, which are the basic components of programming, can be completed. In this way, the user can sequentially organize the structure of the requirements model one by one.

And these requirement models can be integrated around the same component, Normal Mode. This is the same as the conventional method of integrating code. Naturally, Repair Mode and Normal Mode are located under the Seamark component, and the above four modes are sequentially configured under Normal Mode. In order to algorithmize this relationship, the superior, sub-superior, sub-inferior, and sequential relationships between the components are described above. When the two requirement models above are integrated, the relationship between the components from each requirement model perspective can be expressed in the form of integrated code, as shown in Fig. 5. The user can gradually configure requirement models from each functional perspective, and the programming machine automatically integrates these requirement models.

As you compose the components of each requirements model in this way, there are components below it that cannot be further divided or that do not need to be divided any further. You can place reusable code fragments or single sentences below them. This defines the members of all requirements model components. This is how to compose requirements models, and when this requirements model composition is completed, the programming machine integrates and verifies all requirements models and automatically generates code.

The requirements model is logicalized in the order of structure definition (311) and content composition (312). The structure definition (311) is composed of structure definitions (311-1 to 311-n) for each requirements model. The structure definitions (311-1 to 311-n) can be composed including setting the location of each component, setting the name of each component, setting the logical operator of each component, and setting the data of each component.

In one embodiment of the present invention, the requirements model has the following characteristics.

1) Each component identified by name is used to construct a single fragmentary requirements model using logical operators and hierarchical sequential positional relationships.

2) Content can be organized at the bottom of a requirements model.

3) The structure and content of the requirements model are expressed mathematically and correspond to code.

The content composition (312) is also composed of each content composition (312-1 to 312-n) for each requirement model according to each requirement model. Each content composition (312-1 to 312-n) is composed of one content (313) for one component. The content (313) is composed of a single sentence or a piece of code.

When the user logicalizes the structural definition (311) and content composition (312) of the requirements model in that order, the operation unit (120) performs structural integration (321) of the requirements model.

In the process of integrating the structure, the operation unit (120) performs identification (322) of inconsistent components between requirement models using a programming machine. In detail, when identification (322) of inconsistent components occurs, the operation unit (120) displays this on the display unit (130) to inform the user that there is currently an inconsistent component identified as guidance information. Here, the programming machine is software having an algorithm for integrating requirement models so that the meaning of all requirement models is maintained.

In addition, the programming machine can identify inconsistent components between requirement models. In addition, the programming machine can verify grammatical errors in the structure and content of the requirement model.

Additionally, the programming machine can map a unified requirements model to code.

Continuing with reference to Figure 3, the user modifies the requirements model by modifying the corresponding component. By repeating this process, if the user no longer constructs the requirements model and the programming machine does not identify any inconsistent elements, the user obtains from the programming machine an integrated model that integrates the currently constructed requirements models and corresponding code information (330).

The program completion through the method of configuring the requirements model is explained as follows.

The process of configuring, integrating, and verifying a requirements model is performed repeatedly from sketching the requirements model in a macroscopic manner until the detailed configuration is completed. This is similar to the method of configuring a general program. However, in one embodiment of the present invention, it is distinguished in that when a user configures a requirements model based on fragmentary logic, a programming machine performs integration, verification, and code generation.

In this way, when the user repeatedly executes the requirements model with an automatic programming machine to complete the structure of the code, the remaining task is to insert content into the lowest component. The content is included in the members of the requirements model. Since the purpose of the requirements model desired by the user may change depending on the composition of the content, the content corresponds to the requirements provided by the user. The way to mathematically compose the content is to compose it as an additional member of the mathematical model of the requirements model (the mathematical model of the requirements model is defined later). Since the mathematical model is composed of a set, it is possible to add content as the last member of the component. The content can be composed of a single sentence type and various code expressions or data values, as in the example below. For example,

printf("Hello world! ")

The above single sentence can be expressed mathematically as follows.

(kind of statement, String)

Here, kind of statement ∈ K = { x | x is the kind of sentence in C code}, String = { x | x is a combination of words}

In the above way, each single sentence can be mathematically expressed by type. For example, data assignment is (data name, value), insertion of value by variable in printf statement is (data name, position where value should be expressed), etc.

If this is text-based programming, it can be very cumbersome, but in a graphical environment, selecting the type where the content will be added and entering the value may not be so cumbersome. The same applies to using voice. And, if the content is not a single sentence but consists of a piece of code that you want to reuse, you can express it mathematically by naming the piece of code and configuring (piece code format, name) as a member. When generating code through the integration of the requirements model, you can insert the piece of code in the position of the name.

Through this, the code for the content in one embodiment of the present invention can be mathematically expressed.

Figure 4 is a flow chart showing a programming process using a requirements model according to one embodiment of the present invention. Referring to Figure 4, first, a command created by a user for the structure of a requirements model is converted into input information in an input unit (110), and the structure definition and content composition of the requirements model are performed according to this input information (steps S410 and S420).

Thereafter, the operation unit (120) integrates the structure of requirement models and identifies components between requirement models to check whether there are any inconsistent components (steps S440 and S450).

In step S450, if there is a mismatched component as a result of the verification, the operation unit (120) displays the mismatched component as guidance information on the display unit (130) (step S451).

As the guidance information is displayed, the user modifies the corresponding component through the input unit (110) to modify the structure of the requirements model (step S453). Thereafter, steps S420 to S450 are performed.

In contrast, in step S450, if the verification result shows that there are no inconsistent components, the operation unit (120) integrates the structure of the requirement models to generate code information (step S460). That is, automatic programming is performed.

FIG. 5 is an example of code according to an embodiment of the present invention. In particular, FIG. 5 is an example of code written in the C language, and FIG. 5 shows various modes of a program called "Seamark." Referring to FIG. 5, the relationship between each mode (Repair Mode, Normal Mode, Tactical Mode, Part Training Mode, All Training Mode, Replay Mode, etc.) is logically structured by structure. The content to be performed in the mode can be composed of a single sentence or a piece of code and is located in the curly brackets at the bottom. Of course, the structure for each mode can be configured in detail by additionally configuring a requirements model.

Here, the curly bracket at the bottom means a curly bracket that has no more curly brackets inside it. If there is a single sentence in the middle of the requirements model structure, that is, in a position other than the lowest component, the curly brackets for the mathematical logic structure described above can be added before and after the single sentence. This means that a sequential logic component is additionally configured at that position, that is, a logic composed only of curly brackets is configured, and a single sentence is located inside it. This also has the same meaning as a single sentence being located at the lowest position. Therefore, it can be said that it is a general programming characteristic that the content (single sentences or code fragments) other than the structure of the requirements model is always located in the lowest component.

As shown in Figure 5, which is the code for the above structure, propositions are needed along with logical operators to express the structure. Since propositions are composed of data, the use of data in the code must also be included in the category of structure. The value of the data is unnecessary here. This is because the value of the data is not used since it is structuring logic.

From the perspective of structuring code, the declaration statement of data is precisely the structure, and assigning values to data is distinguished as the content. The declaration statement is char OperatorRole, RNMode, char ActiveMode, SecurityValidity, etc., where char represents a string. In Fig. 5, OperatorRole==0, OperatorRole==2, etc. are propositions that determine right or wrong, not assignments of values.

Programming is the logical expression of the content of the purpose to be performed and expressed in code. In other words, the purpose is composed of several requirement models, and programming is the logical structure and integration of these requirement models. Based on what has been explained above, performing programming means structuring the content related to a specific purpose into the logical structure explained above, and filling it with meaning that cannot be divided any further.

The concept of automatic programming starts from the definition of requirements and the definition of programming. The main concept of the present invention is how the requirements that a user must provide to a programming machine are structured and what role the programming machine must automatically perform.

Since requirements are very vague when composed in natural language, if we structure the contents and compose fragmentary requirements using the logic of sequence, selection, and repetition used above, the role of the programming machine is to correctly integrate these pieces of requirements and produce code, and in this process, the role of the programming machine is to detect inconsistencies between requirement models and grammatical errors in the code.

Machines cannot judge whether requirements are right or wrong, because that is what users define. However, they can detect errors caused by inconsistencies between requirements defined by users. However, machines cannot judge which of these requirements is right.

This is also because it is judged by the user's definition. Therefore, correcting errors is the same as defining requirements. Therefore, in one embodiment of the present invention, a programming machine that automatically performs programming integrates a requirements model, produces integrated code for the integrated requirements model, and performs the function of detecting errors in the integrated code and inconsistencies between requirements.

The user constructs requirements and corrects them if grammatical errors or inconsistencies between requirements are found. In other words, the role of the user is to construct correct requirements. And the requirements defined by the user are expressed in mathematical logic, which will be defined in more detail later.

FIG. 6 is an example of expressing the positional relationship between blocks in a state where logical operators are omitted according to an embodiment of the present invention. Referring to FIG. 6, in order to logically algorithmize the structure of a program, the relationship between the components constituting the structure must be established. In order to express this relationship, the sequential and hierarchical relationship between the components is expressed using a nested ordered pair. However, parentheses are omitted in this expression. This is because when expressing multiple components, the number of parentheses becomes too large, which reduces the visibility of the expression.

Referring to FIG. 6, the left side is an example of code information (610), and the right side is an example of a hierarchical sequential positional relationship (620) corresponding to the example of code information (610) expressed on the left side. The top-level component (623) is (1), the bottom-level component (621) is (1,2,2), and the next-level component (622) of the bottom-level component (621) is (1,2). Both (1) and (1,2) are upper-level components of (1,2,2). (1,2,1) is sequentially ahead of (1,2,2), and the next-level component (1,2) is the same. The sequential positional relationship is below the same next-level component. Therefore, (1,1,1) and (1,2,1) are not sequential positional relationships.

In detail, each component is divided into a lowest component of the lowest hierarchy, a sub-higher component located adjacent to the component, a higher component located above including the sub-higher component, a sub-lower component located adjacent to any component, a lower component located below including the sub-lower component, a top component located above each of the components, and a lowest component located below each of the components, thereby distinguishing the hierarchical relationship between the components.

Fig. 7 is an example of a requirements model in which each component is given a unique name using the names and positional relationships of the components according to one embodiment of the present invention. In other words, a requirements model can be expressed using only the names and positional relationships. All requirements models can be constructed piecemeal as long as they are correct. This is because there is an algorithm for integrating requirements models. Therefore, a user can construct and manage requirements models from various perspectives. Referring to Fig. 7, the "Seamark" (720) program consists of Repair Mode (711) and Normal Mode (712).

Fig. 8 is an example of a requirements model that embodies the sub-components of the "Normal Mode (712)" illustrated in Fig. 7. That is, it is an example of a requirements model for explaining the concepts of definition and integration of requirements models together with Fig. 7. Referring to Fig. 8, "Normal Mode (712)" is composed of "Tactical Mode" (810), "Part Training Mode" (820), "All Training Mode (830)", and "Replay Mode (840)". Every component in the code has its own role. Therefore, a unique name can be named for that role. Logicalizing the structure of the code through the name in this way has the meaning of symbolizing the behavior defined in the corresponding area. That is, it is assigning a mathematical symbol for the behavior. In the present invention, a program is expressed by structuring hierarchical sequential symbols. The name, which is a symbol for the behavior, is used as a unique identifier that distinguishes the same component between each requirements model.

The concept becomes clearer when viewed from the perspective of a completed program. Let us assume that there is a completed program and that each block of the program is given a meaningful name. Then, the program becomes a structured shape with names. When there is a specific function performed in the program, it can be said that the function is composed by combining the names of the corresponding blocks in the program. In other words, it can be said that the function is executed by sequentially performing blocks with certain names. This is a model composition from the perspective of the function, and this model is called a requirements model in the present invention. This is a function performed from a specific perspective and is fragmentary knowledge known to the programmer. The main concept of the present invention is to integrate and verify these fragmentary functions and automatically generate code.

There are two requirement models in Fig. 7 and Fig. 8, and it is easy to infer how they will be integrated. The components with the same name, "Seamark" (720) and "Normal Mode (712)", are gradually connected with the components of the subordinate relationship and the sequential relationship. This is the concept of integrating the structure of the model using the positional relationship and name.

Although each component is related by a positional relationship, assigning a unique name to this position constitutes a structure of a fragmentary program that has meaning. The main idea of the present invention is to perform automatic programming using this method of configuring requirements. As explained above, the component is composed of a name, a position, a logical operator, a proposition, and the declaration and use of data. In addition, the component can be expressed mathematically. That is, it can be expressed as a mathematical formula. An example of this is as follows.

- (Definition) Requirements Model

M = {e | e = (name, (p _n-1 , a n _k ), t, c, D _c , D _d , D _a )}

Here.

name ∈ S, S = {x | x is natural words}, {name} ≠ Ф

name ∈ S, S = {x | x is natural words}, {name} ≠ Ф

p _n = (p _n-1 , a _nk ), p1 = (1), p ₂ = (p ₁ , a _2k ), a _nk = a _n(k-1) + 1, a _n1 = 1, n ∈ N, k ∈ N, N = {x | x is a natural number}

t ∈ Type, Type = {sequence, selection, loop}, {t} ≠ Ф

c is a conditional statement in C language code

D _c = {x | x = (name _c : type _c ), x is a used variable in c }

D _d = {x | x = (name _d : type _d )}

D _a = {x | x = (name _a : type _a )}

According to the mathematical model above, it means that the requirements model (M) described above can be expressed as a set consisting of components (e). Each component has a unique name (name), a position indicating the relationship between components (i.e., position relationship), and also includes types of logical operators (t) such as while, if, and none, and propositions (c).

The data used in the component is also expressed, and there is a declaration data set (D _d ) meaning the data starting from the component, an access data set (D _a ) declared (starting) in the upper component but used in the current component, and a condition data set (D _c ) used in the proposition of the current component among the data used in the next-level component. It can be seen that the structure of the requirements model is visualized in the component with the location and name, there are types of logical operators and propositions for expressing the logical relationship between each component, and there is declaration/access/condition data for expressing the use of data between components. The elements that make up the component are defined as members in this way.

The mathematical model was introduced for automatic integration and verification of the requirements model. Among the structures and contents that constitute the code, the mathematical model above expresses only the structure. As explained above, the mathematical expressions of single sentences and fragments of code can be added as the rightmost member of the mathematical model set. Therefore, all requirements models, that is, structures and contents, can be expressed mathematically.

Meanwhile, the corresponding relationship between the members of the component and the code is as shown in the table below.

Member of a component Corresponding C language code p Position of curly brackets name None (comment) t
Sequence/ Selection/ Loop Logical operators below
None/ If/ While c proposition D _c doesn't exist D _d Declaration data statements ex) char name; D _a doesn't exist

Table 1 lists the mathematical models defined above and their corresponding C codes. It describes which part of the C code corresponds to the requirements model expressed in the structure of the code. This means that when the requirements model is constructed, the corresponding code can be constructed automatically. Of course, a lookup table can be constructed for this purpose.

For example, if there is a requirement model such as Fig. 7 and Fig. 8, place curly brackets at each location, describe the name as a comment on top of the curly brackets as in Fig. 5, place a logical operator in front of the curly brackets, and then describe the proposition with parentheses. Then, describe the components of the declaration data set as sentences inside the curly brackets. This is a method to automatically code the structure of the requirement model. If the bottom component contains a single sentence or a piece of code, inserting the content at that location completes the code.

Meanwhile, the integration between requirements models is described in detail as follows.

All logical thinking methods are the same, but in the requirements model, the integration is centered on common factors. In Fig. 7 and Fig. 8, there are two requirements models. The common components are "Seamark" and "Normal Mode". Therefore, integration is possible centered on common factors. Specifically, the method of integrating models is to maintain the shape of each requirements model to be topologically identical. This is the same concept as the method of integrating codes in general. If the relationship between the components that make up the integrated requirements model is maintained identically for the two requirements before integration, the integrated requirements can correctly reflect the meaning of each requirement. This is explained based on the mathematical model as follows. In Fig. 7 and Fig. 8, the Seamark component and the Normal Mode component are common factors. Integrating the two models centered on this is the same as inserting the components of another model into one model.

When a user defines requirements, the intention is to configure four modes under Normal Mode, so the four modes of Fig. 8 can be configured under Normal Mode of Fig. 7. If this is expressed in a logical relationship, the method for integrating the two models is to repeatedly insert non-identical components in a subordinate and subordinate relationship centered on the same components among the components of the model of Fig. 8 in the model of Fig. 7, insert components in a sequential relationship with the inserted components, and then insert components in a hierarchical relationship with those components.

In this process, the position of each model is used to distinguish the positional relationship between components. For example, the position (1,3,4) expressed as a nested ordered pair has the position of the next higher-order component as (1,3), and is in a sequential relationship with (1,3,1), (1,3,2), (1,3,3), etc. As another example, the next higher-order component of the position (1,6,7,3) is (1,6,7) and the next lower-order component is (1,6,7,3,1). In other words, the position and number of the nested ordered pair expressing the position include the positions of all higher-order components. This is because the positions of the higher-order components in the above example are (1), (1,6), (1,6,7). In other words, the hierarchical sequential positional relationship between the components of the requirements model can be known through the position expression. Therefore, in the above integration method, by sequentially inserting the subordinate, subordinate, and sequential relationships centered on the components with the same name in one requirements model to the other requirements model, integration of all components of the two models is possible.

The method of integrating two models is the same as providing a method of integrating multiple models sequentially two by two. Through this, all requirements models can be integrated through positional relationships.

Since the requirements model corresponds one-to-one with the code, integrating each requirements model means integrating two codes, and if the shapes of the two requirements models are integrated identically, it means that there is no distortion of meaning when integrating the two codes intended by the user to configure the entire code. Therefore, the two models in Figs. 7 and 8 can be integrated around the same name.

To explain more specifically using the mathematical model defined above, as explained above, location and name can be integrated centered on components with the same name, and members of components such as logical operators, propositions, and data can be integrated only for components with the same name, and components that do not have the same name can be left as is.

For example, in the two models of Figs. 7 and 8, "Normal Mode" requires integration between members, but "Repair Mode" and "Tactical Mode" do not have identical components, so there is no target for integration. Integration of identical components is performed for each member. Since the requirements model is a structured model that symbolizes the behavior that each block means, and each requirements model expresses fragmentary knowledge, the members belonging to the same behavior, that is, the components with the same name, may be expressed with different meanings. From the perspective of the program to be completed, the members of the same behavior, that is, the members of the same component, must be expressed by integrating them with the members of various requirements models that are expressed fragmentarily. Naturally, if there is no component with the same name, the members of that component have no target for integration.

The integration of logical operators is related to the logic of sequence/selection/repetition, so selection and sequence can be determined as selection, and selection and repetition can be determined as repetition. Since all propositions must be satisfied, propositions are integrated with AND logic, and since data must be used in all components, they are composed of a union. As above, the rule for integrating members for the same components is expressed mathematically as follows.

- (Definition) Method of integration between identical components

For any component e _alpha , unify components e _1alpha and e _2alpha of the same name.

Here, e _1alpha ∈ M1 , e _2alpha ∈ M2 , e _alpha ∈ M , e _1alpha = e _2alpha = e _alpha , M ₁ ∪ M ₂ = M .

Integration of logical operators

e _alpha (sequence) ⊂ e _alpha (selection) ⊂ e _alpha (loop),

e _1alpha (sequence)ㆍe _2alpha (selection) = e _2alpha (selection)ㆍe _1alpha (sequence) = ealpha (selection),

e _1alpha (loop)·e _2alpha (selection) = e _2alpha (selection)·e _1alpha (loop) = e _alpha (loop),

e _1alpha (loop)·e _2alpha (sequence) = e _2alpha (sequence)·e _1alpha (loop) = e _alpha (loop),

e _1alpha (sequence)ㆍe _2alpha (sequence) = e _alpha (sequence),

e _1alpha (selection)ㆍe _2alpha (selection) = e _alpha (selection),

e _1alpha (loop)ㆍe _2alpha (loop) = e _alpha (loop)

Propositional integration

e _1alpha (c)ㆍe _2alpha (c) = e _alpha (c)

Data Integration

e _1alpha (D _c ) ∪ e _2alpha (D _c ) = e _alpha (D _c )

e _1alpha (D _d ) ∪ e _2alpha (D _d ) = e _alpha (D _d )

e _1alpha (D _a ) ∪ e _2alpha (D _a ) = e _alpha (D _a ).

Meanwhile, the verification method is explained as follows.

Given an arbitrary integrated model, verification of the model is to check whether it is grammatically correct and whether each user-defined requirement model is correctly integrated. In other words, it is only necessary to check whether the requirement model is grammatically correct and whether the integration preserves the meaning of each requirement model.

Grammatical verification can be verified by a mathematical model of the requirements model. Grammatical verification is divided into the correct composition of each component and the detection of grammatical errors between components. Verification of each component is completed when it is confirmed that the members of each component are defined in the format defined in the mathematical model. This is to confirm whether the member composition of the component matches the definition.

Grammatical errors between components are to detect grammatical conflicts that users commit when defining a requirements model. Since components consist of names, locations, logical operators, propositions, and declaration/access/condition data, you only need to check for conflicts between components for each member. This is because there are no conflicts between different types of members. In other words, there is no conflict in names for locations. This means that using name B in location A does not cause a grammatical error. The same goes for other types of members.

Therefore, in a requirement model, conflicts between components are checked for each member. Since the name is a unique identifier in the process of performing programming, components with the same name should not exist in a model. Since the location is a value automatically assigned by the relationship between components in the requirement model, there is no possibility of user error. This is because the user does not directly assign it. If the user arbitrarily changes the location value, the location value can be assigned sequentially from the top component (1) and compared with the value arbitrarily assigned by the user.

Logical operators and conditional propositions do not have conflicting elements between components. Declaration data means the starting point of data, so declaration data with the same name should not exist in the higher-level component than the corresponding component. Access data means that the data declared in the higher-level component is used, so declaration data must exist in the higher-level component. Conditional data means that the data of the lower-level component is used in the proposition, so the declaration and access data of the lower-level component must include conditional data.

The above are the member conflicts between the components for a single requirement model. The grammar verification should be performed even after the integration of the requirement model. This is because the data usage of the requirement model is defined from the perspective of a single model composition, so the data usage should be redefined as the scope of the model expands.

Since the composition of the requirements model represents the user's intention, verification of the integrated requirements model is to confirm that each requirements model is reflected in the integrated model according to its original meaning. Since the model is composed of location, name, logical operator, proposition, and data by the mathematical model, it is confirmed whether each member is reflected correctly. As explained in the integration process above, it is possible to confirm whether the location relationship between each component of each requirement is correct by focusing on the same name.

For example, if the hierarchical and sequential relationships between each component expressed in Figs. 7 and 8 are maintained identically in the integrated model, the configuration of each requirement model in the integrated model is maintained identically, so it can be said that it is topologically correctly structured. If there is no component with the same name, integration is not possible and verification is unnecessary. This is because the absence of a component with the same name in the requirement model is equivalent to the absence of a method for integration. In this case, the requirement model should be structured in more detail so that the same name is configured.

Once the two models are verified as being structurally correct, such as in Figures 7 and 8, through location and name, the components with the same name can be verified to have been correctly integrated using the integration method defined above, including logical operators, propositions, and data.

The mathematical model for explaining whether each requirement is correctly integrated for the integrated model is as follows. Since the integrated model correctly integrates the meaning of each requirement model, the positional relationship between the components that make up one requirement model must be maintained. In other words, it must be confirmed that all subordinate relationships and sequential relationships between the components of one requirement model are maintained as upper relationships and sequential relationships in the integrated model. The name of each component in the integrated model must exist as a unique identifier only once. This enables verification that the location and name of each requirement model are correctly integrated. Verification is performed by checking whether the remaining members, which are logical operators, conditions, and data, include members of each requirement model in the components of the same name in the integrated model. This mathematically verifies that the meaning of each requirement model is correctly integrated into the integrated model.

Meanwhile, when the automatic program is completed, all declared data can be managed through the mathematical model. All data used in the previously defined mathematical model can be integrated and organized into one set, and data that changes according to the content at the bottom can be distinguished. Therefore, it is also possible to sequentially organize data that changes based on the location of the integrated model. Therefore, the integrated model, that is, the value at any location in the code, can be analyzed. In addition, it is possible to reconstruct from various perspectives how specific data is changed and organized in the integrated model. This means that all data in the program can be analyzed mathematically.

In addition, the steps of the method or algorithm described in connection with the embodiments disclosed herein may be implemented in the form of program instructions that can be executed by various computer means, such as a microprocessor, a processor, a CPU (Central Processing Unit), and the like, and recorded on a computer-readable medium. The computer-readable medium may include program (instruction) codes, data files, data structures, etc., alone or in combination.

The program (command) code recorded on the above medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium may include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs, DVDs, and Blu-rays, and semiconductor memory devices specially configured to store and execute program (command) codes such as ROMs, RAMs, and flash memories.

Here, examples of program (instruction) code include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc. The above-mentioned hardware device can be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

100: Programming System
110: Input section
120: Operation section
130: Exhibition Department
140: Storage
210: Model Structure Definition Module
220: Configuration Module
230: Structural Integration Module
240: Identification of mismatch elements module
250: Code generation module

Claims (18)

An input section (110) for receiving input information for defining the structure (311) and composing the contents (312) of a plurality of requirement models;
A computation unit (120) that identifies whether there are any inconsistent components among a plurality of the above requirement models, integrates the plurality of the above requirement models if there are no inconsistent components, generates an integrated model, and generates code information of the integrated model; and
It includes a display unit (130) that outputs information on a plurality of requirement models corresponding to the above-described inconsistent components under the control of the above-described operation unit (120);
The above structural definition (311) is defined using logical operators,
Many of the above requirement models are requirements that users must provide in order to automatically perform programming.
At the bottom of the above multiple requirement models, content (313) is configured, and the structure and content (313) configuring the above multiple requirement models are mathematically expressed and correspond to code,
The above content (313) is a programming system using a requirements model characterized by being a single sentence or piece of code.
In paragraph 1,
The above operation unit (120) is
A model structure definition module (210) that performs structure definition (311) of a plurality of the above requirement models;
A configuration module (220) that performs content configuration (312) of a plurality of the above requirement models using fragment codes or single sentences;
A structural integration module (230) that integrates multiple of the above requirement models;
A mismatch component identification module (240) that identifies whether there are any mismatch components between a plurality of the above requirement models; and
A programming system using a requirements model, characterized by including a code generation module (250) that generates the code information if there is no such mismatched component.
In the second paragraph,
The structure of the above requirements model is
Repeat (proposition) { }
Choice (proposition) { }
A programming system using a requirements model, characterized in that the requirements model structure is comprised of the following logical operators: sequence { } (wherein repetition, selection, and sequence are logical operators, and parentheses and curly brackets express propositions and blocks) , and the fragment code and single statement are within the curly brackets at the bottom of the requirements model structure comprised of the above logical operators.
In the second paragraph,
A programming system using a requirements model, characterized in that the above-mentioned inconsistent component identification module (240) generates guidance information indicating that inconsistent components should be corrected when there are inconsistent components between a plurality of the above-mentioned requirements models.
delete In paragraph 1,
The above structural definition (311) includes setting the location of each component, setting the name of each component, setting the logical operator of each component, and setting the data of each component, and a programming system through a requirements model characterized in that the location, name, logical operator, proposition, and data of each component become members of each component.
In paragraph 6,
A programming system using a requirements model, characterized in that the members of each component and the codes corresponding to the members are configured in advance as a lookup table.
In paragraph 6,
A programming system using a requirements model, characterized in that each of the above components is a lowest-level component (621), a second-level component (622) positioned adjacent to and above the above component (621), a component (622, 623) positioned above the above component (621), and a top-level component (623) positioned at the very top of each component, forming a hierarchical relationship between the components.
In Article 8,
A programming system using a requirements model, wherein a sequential positional relationship is a relationship between components positioned below the same upper-level component (622).
In paragraph 6,
A programming system using a requirements model, characterized in that the member names of each of the above components are used as unique identifiers for distinguishing components during an automatic programming process.
In paragraph 6,
A programming system via a requirements model, wherein a plurality of said components include propositions and data related to said components.
In paragraph 6,
A programming system using a requirements model, characterized in that the above integration is centered on components with the same name as the location, and the members of each component including the logical operator, the proposition, and the data are integrated only for components with the same name, and components that do not have the same name are maintained as is.
In Article 12,
A programming system using a requirements model, wherein the above components are expressed as a mathematical model.
(a) a step in which the input unit (110) receives input information for defining the structure (311) and composing the content (312) of a plurality of requirement models;
(b) a step of the operation unit (120) identifying whether there are any inconsistent components among the plurality of requirement models, and if there are no inconsistent components, integrating the plurality of requirement models to create an integrated model and generating code information of the integrated model; and
(c) a step in which the exhibition unit (130) outputs component information of the requirement model for a plurality of the requirement models corresponding to the mismatched components under the control of the operation unit (120);
The above structural definition (311) is defined using logical operators,
Many of the above requirement models are requirements that users must provide in order to automatically perform programming.
At the bottom of the above multiple requirement models, content (313) is configured, and the structure and content composing the above multiple requirement models are mathematically expressed and correspond to code,
The above content (313) is a programming method using a requirements model characterized by being a single sentence or piece of code.
In Article 14,
Step (b) above,
A step in which a model structure definition module (210) performs structure definition (311) of a plurality of the above requirement models;
A step in which a configuration module (220) performs content configuration (312) of a plurality of the above requirement models using fragment codes or single sentences;
A step of integrating a plurality of the above requirement models by the structural integration module (230);
A step for identifying inconsistent elements by a module (240) identifying whether there are inconsistent elements between a plurality of the above requirement models; and
A programming method using a requirements model, characterized in that it includes a step of generating the code information if the code generation module (250) does not have the above-mentioned inconsistent component.
In Article 14,
The above structural definition (311) includes setting the location of each component, setting the name of each component, setting the logical operator of each component, setting the proposition of each component, and setting the data of each component, and a programming method using a requirements model characterized in that the location, name, logical operator, proposition, and data of each component become members of each component.
In Article 16,
A programming method using a requirements model, characterized in that a plurality of the above requirements models are classified and managed based on the members of each component.
A computer-readable storage medium storing a program for executing a programming method using a requirements model according to any one of claims 14 to 17.