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

Abstract

For defined automation tasks (programming), a programming system using a requirements model that does not require user intervention is disclosed. The programming system includes an input unit that receives input information for defining the structure and composing contents of multiple requirements models, and identifies whether there are inconsistent elements between the multiple requirements models. If there are no inconsistent elements, the multiple requirements models are generated. An operation unit that integrates to create an integrated model and generates code information of the integrated model, and an exhibition unit that outputs information on a plurality of the requirements models corresponding to the inconsistent components under the control of the annual unit. Do it as

Description

Automatic programming system and method using programming model}

The present invention relates to automatic programming performance technology, and more specifically, to an automatic programming system and method that automates the process of developing a program by introducing a programming model that includes expressions of all programming languages.

Existing methods of performing automatic programming include a method using mathematical specifications (Program Synthesis) and a method of combining pieces of a program constructed from a specific perspective that are effective in a specific domain but cannot be generalized (Domain specific programming). there is. It is difficult to consider this method as complete automation.

In the former, when the user provided a requirements specification, user intervention was required in the process of programming using the requirements specification, and in the latter, partial automation was possible only for specific predefined functions.

There is a method using artificial intelligence to compensate for these shortcomings, but this method is also a probabilistic approach based on empirical data. Therefore, user intervention is still necessary. This is because in a probabilistic approach, no matter how small the probability of user intervention, the probability exists.

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

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

The present invention provides a programming system through a requirements model in which a user automatically performs programming by defining a requirements model using a programming model to achieve the tasks presented above. The above programming model refers to a model that can mathematically express the control structure of a program.

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

In other words, a program structures its actions using a control structure. Here, the action may consist of a single sentence, such as a program execution command, or it may consist of a fragment of a program. Therefore, a program places actions in the intended location within all the control structures that make up the program. A programming model is a model that expresses the control structure that makes up the program as a mathematical model and structures data and actions in mathematical expressions.

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

The programming system is,

An input unit that receives input information for defining the structure and configuring content of a plurality of requirements models;

an operation unit that identifies whether there are inconsistencies between the multiple requirements models and, if there are no inconsistencies, integrates the multiple requirements models to create an integrated model and generates code information of the integrated model; and

and an exhibition unit that outputs component information of a plurality of the requirements models corresponding to the mismatched components under the control of the annual unit.

At this time, the calculation unit includes a model structure definition module that performs structure definition of a plurality of the requirements models; A configuration module that configures the contents of a plurality of the requirements models using fragment codes or single sentences; a structural integration module that integrates a plurality of the requirements models; an inconsistent element identification module that identifies whether there are inconsistent components between the plurality of requirements models; and a code generation module that generates the code information if there is no mismatch component.

Additionally, the structure of the requirements model is

repetition (proposition) { }

choice (proposition) { }

Contains a sequence { } (where repetition, selection, and sequence are logical operators, and parentheses and braces represent propositions and blocks) , and the fragment code and single statement are the requirements model structure consisting of the above logical operators. It is characterized by being within the curly brackets at the bottom.

In addition, the brace at the bottom is characterized by being a brace without any further braces within the brace.

Additionally, the inconsistent element identification module is characterized in that, if there are inconsistent components between the plurality of requirements models, it generates guidance information indicating to correct the inconsistent components.

Additionally, the structure definition is characterized by being defined using logical operators.

In addition, the structure definition is characterized in that it includes 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 location, name, logical operator, and data for various purposes become members of each component.

In addition, the members of each component and the codes corresponding to the members are characterized in that they are configured in advance as a look-up table.

In addition, each of the components includes the lowest level component of the lowest layer, the next-highest component placed at the adjacent top of the component, the top component placed at the top including the next-highest level component, and the second-lowest component placed at the adjacent bottom of any component. Components, lower-level components including lower-level components, the highest-level component at the top of each component, and the lowest-level component at the bottom of each component, which is a hierarchical relationship between components. distinguish between

In addition, each component is characterized by dividing the order of components located under the same higher-level component into a sequential relationship.

In addition, the member name of each component is used as a unique identifier to distinguish the component during the automatic programming process.

In addition, each of the components is characterized in that it includes data related to the proposition and the component.

In addition, the integration is centered around 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 the members of each component, including the logical operator, the proposition, and the data, are integrated only for components with the same name. Components that are not present are characterized in that they 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 includes: (a) an input unit receiving input information for defining the structure and configuring content of a plurality of requirements models; (b) a calculation unit identifying whether there are inconsistencies between the multiple requirements models, and if there are no inconsistencies, integrating the multiple requirements models to create an integrated model and generating code information for the integrated model; and (c) an display unit outputting component information of the requirements model for a plurality of the requirements models corresponding to the mismatched components under the control of the calculation unit. provides.

At this time, step (b) includes a model structure definition module performing structure definition of a plurality of the requirements models; A configuration module performing content configuration of a plurality of the requirements models using fragment codes or single sentences; A structural integration module integrating a plurality of the requirements models; identifying, by an inconsistency element identification module, whether there are inconsistency components between a plurality of the requirements models; and generating, by a code generation module, the code information if the mismatched component does not exist.

In addition, a number of the requirements models are characterized in that they are classified and managed based on the membership 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 the structure and content of the code can be expressed and related mathematically, which allows the machine to integrate individual requirements models, detect syntactic and integrated errors, and automatically generate code.

In addition, another effect of the present invention is that a description composed of natural language can be added as a member of the component in the same way as the method of configuring the content previously described for each component, which allows the description to be related in a structured form using mathematical logic. This means that all outputs related to software development can be managed through a mathematically structured system.

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

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

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. Because programming languages are similar to the use of general languages, it is difficult to accurately express the relationships between sentences even if they are clearly described. It is difficult to explain individually which parts are in contact with each other and which parts have the same information, and it is impossible to express them in a structural form. The advantage of mathematical expressions is that it is possible to clearly understand which symbols are the same symbol and what relationships are established between the symbols.

All meaning of a program is physically expressed on a circuit. The circuit performs meaningful actions by changing the data states of 0 and 1 through statements. These statements become programs by being structured using logical operators such as AND, OR, NOT, and GOTO. In the concept of Structured Programming, logical operators on a circuit structure program statements with 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, mathematically expressing the relationship between control structures in structured programming is equivalent to expressing all logical structures in a circuit.

Since the present invention introduces a model that mathematically expresses the relationship between these control structures, the control structures of all programming languages can be expressed mathematically.

Additionally, 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 methods described in the present invention were derived by introducing a mathematical model that expresses the relationship between the control structures of the programming language.

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

A Turing machine is a method of performing modeling through the result data obtained by giving initial values and executing the program, assuming that there is a random program. In other words, it models the transition relationship of data due to program execution.

This modeling method cannot distinguish differences in control structure between programs that have different control structures but produce the same results. In other words, it has non-determinism regarding the control structure. This means that the relationship of the control structure cannot be clearly defined, which ultimately makes the correspondence between the model and code ambiguous. Therefore, program synthesis using mathematical specifications based on this modeling concept failed to realize automatic programming.

1 is a block diagram of a programming system according to an embodiment of the present invention.
FIG. 2 is a detailed block diagram of the operation unit shown in FIG. 1.
Figure 3 is a conceptual diagram of programming through a requirements model according to an embodiment of the present invention.
Figure 4 is a flowchart showing a programming process through a requirements model according to an embodiment of the present invention.
Figure 5 is an example of code according to an embodiment of the present invention.
Figure 6 is an example of positional relationships between components omitting logical operators according to an embodiment of the present invention.
Figure 7 is an example of a requirements model expressed only in the names and positional relationships of components according to an embodiment of the present invention.
Figure 8 is an example of a requirements model to explain concepts such as definition and integration of the requirements model together with Figure 7.

Since the present invention can be modified in various ways and can have various embodiments, specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all changes, equivalents, and substitutes included in the spirit and technical scope of the present invention.

When describing each drawing, similar reference numerals are used for similar components. Terms such as first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another.

For example, a first component may be referred to as a second component, and similarly, the second component may be referred to as a first component without departing from the scope of the present invention. The term “and/or” includes any of a plurality of related stated items or a combination of a plurality of related stated items.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by a person of ordinary skill in the technical field to which the present invention pertains.

Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and unless clearly defined in the present application, should not be interpreted in an ideal or excessively formal sense. It shouldn't be.

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 an embodiment of the present invention has the following characteristics.

ηProvides a method to automatically integrate the user's requirements model.

사용자의 요구사항 모델에 대한 불일치 구성요소를 식별해준다.

Identifies inconsistent components to the user's requirements model.

요구사항 모델의 구조와 내용을 코드와 대응시킨다(모델 통합이 완료되면 통합된 코드를 얻는다)

Match the structure and contents of the requirements model with the code (once model integration is complete, the integrated code is obtained)

④ The structure and contents 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 that constitutes the program. As long as the user knows the purpose of the program that he or she needs, he or she can select a completed program. If a user has the knowledge to modify the structure of a program, he or she can change the structure of the program by borrowing a completed module depending on the purpose of use. If a user has all the knowledge to construct a program, he or she can construct the program from start to finish.

One embodiment of the present invention provides all such users with the usefulness of mechanical automation for integrating and verifying the logic pieces by allowing them to use a method to organize knowledge about the program into a requirements model, which is a defined logical expression. If the user does not know the program well, he or she cannot know whether the functions included in the program are the functions the user wants. Therefore, as described above, the user can select a program, configure only part of the program, or configure the entire program based on his or her knowledge. As in science fiction movies, it is a misconception about automation that a programming machine automatically implements functions that the user does not know about. 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 programming. The main concept of the present invention is how the requirements model that the user must provide to the programming machine is constructed and what roles the programming machine should automatically perform.

Figure 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 identifies whether there are inconsistency elements between the input unit 110 and the requirements models, which receives input information for defining the structure and configuring the contents of a plurality of requirements models, and determines whether the inconsistency elements are present. If not, a calculation unit 120 that generates a code by integrating a plurality of requirements models, and an exhibition unit 130 that outputs discrepancy information about the plurality of requirements models corresponding to the discrepancy element under the control of the calculation unit 120. , and a storage unit 140 that stores information related to the requirements model.

The input unit 110 performs the function of receiving user commands. Of course, the received input information can also be converted into digital information. Input information may be text, but is not limited to this, and may be voice or action. To this end, the input unit 110 may be configured to include a keyboard, microphone, touch screen, camera, DSP (Digital Signal Processor), etc.

The calculation unit 120 performs a function of identifying whether there are inconsistencies between the multiple requirements models and, if there are no inconsistencies, generating a code by integrating the multiple requirements models. In other words, when the user logicalizes the requirements model in the order of structure definition and content composition, the operation unit 120 integrates the structure of the requirements models and identifies inconsistencies between the requirements models if they exist, and displays the display unit 130. Notifies the user through

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 inconsistent elements, the operation unit 120 generates code information by integrating the currently configured requirements models. Therefore, users receive code that correctly reflects all requirements models.

Code is mainly used in the process of creating an executable program, 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 requirements information for the requirements model corresponding to the mismatch element under the control of the calculation unit 120. Of course, it is possible to provide the user with a screen for inputting input information, a guidance screen for guiding input, an execution screen for execution, etc. The display unit 130 may be a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED (OLED) display, a touch screen, or a flexible display. In the case of a touch screen, it can also be used as an input means.

The storage unit 140 performs the function of storing requirements models, code information, etc. Of course, it includes programs, software, data, etc. that implement algorithms that integrate the requirements model. Accordingly, the storage unit 140 may be a flash memory type, a hard disk type, a multimedia card micro type, or a card type memory (e.g., Secure Digital (SD)). or eXtreme Digital (XD) memory, etc.), Random Access Memory (RAM), Static Random Access Memory (SRAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Programmable Read Only Memory), magnetic memory, magnetic disk, optical disk, etc. Additionally, it may operate in connection with web storage and cloud servers that perform storage functions on the Internet.

FIG. 2 is a detailed block diagram of the calculation unit 120 shown in FIG. 1. Referring to FIG. 2, the calculation unit 120 includes a model structure definition module 210, a configuration module 220, a structure integration module 230, an inconsistent element identification module 240, a code generation module 250, etc. It can be configured as follows.

The model structure definition module 210 receives input information for defining the structure of a requirements model from the input unit 110 and performs the function of defining the structure of the requirements model. To elaborate, this 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.

The configuration module 220 is responsible for configuring the contents of one requirements model. To elaborate, the content may be a single sentence or piece of code. A piece of code refers to a collection of code that a user sets up in advance to reuse.

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

The inconsistency element identification module 240 performs a function of identifying whether there are inconsistency elements between requirements models. In detail, the identification of inconsistent elements is carried out by identifying grammatical errors for individual components, identifying inconsistencies between components for one requirements model, and identifying inconsistencies between requirements 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 refers to a unit that processes at least one function or operation, and may be implemented in software and/or hardware. In hardware implementation, an application specific integrated circuit (ASIC), digital signal processing (DSP), programmable logic device (PLD), field programmable gate array (FPGA), processor, microprocessor, and other devices designed to perform the above-described functions. It may be implemented as an electronic unit or a combination thereof. In software implementation, software composition components (elements), object-oriented software composition components, class composition components and task composition components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, and data. , databases, data structures, tables, arrays, and variables. Software, data, etc. can be stored on 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 conceptual diagram of programming through a requirements model according to an embodiment of the present invention. Referring to FIG. 3, the programming concept diagram may be divided into a user function 310 and a programming machine function 320.

Before explaining FIG. 3, the concept of automatic programming will first be explained.

In order to conceptualize the automatic performance of programming, it is necessary to distinguish which part is the requirements that must be provided by the user and which part is the programming that must be performed by the machine. To do this, we must first look at the characteristics of a general program (imperative program). Here, C code is explained as an example, but other types of programming languages have the same characteristics in terms of code structure and content.

In any C code, putting braces before and after all statements except those containing logical operators does not change the meaning of the code. These curly brackets clearly distinguish the relationship between sentences and the scope of data use. Code is actually executed based on these relationship expressions, but in text-based programming, this logical structure is omitted for the convenience of programmers. Additionally, 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. What you need to be careful about here is that the statement that declares a variable and assigns a value should be divided into a variable declaration statement and a value assignment statement. In text-based programming, these functions are provided for the user's convenience, but in the concept of distinguishing and automating the structure and content of the code, these convenience functions are a factor that hinders the algorithmicization of programming. This assumption can be generalized because the result of a code constructed through automatic programming is not limited in the range of expression just because it does not use a specific convenience function in coding.

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

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 in 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 braces. The reason C code is structured like this is to explain that all code is divided into structure and content. All code other than the logical operator block defined below is divided by content, and the logical operators below are named by structure.

while (proposition) { }

if (proposition) { }

{ }

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

In more detail, it will be explained using Figures 5, 7, and 8 as follows. When programming, users first envision relationships between macro functions and then specify them. Figure 7 shows two modes (Repair Mode and Normal Mode) taken into consideration when configuring the Seamark program. At this time, the user can shape the relationship between the two modes and consider the conditions for the two modes to be executed. Of course, the data that should be used at this time can also be configured.

However, there is no need to think about the specifics that need to be performed within each mode. It's not yet the stage to consider that. Figure 8 shows the configuration of functions in Normal Mode in a more specific form. Four more modes may exist under Normal Mode. At this time, there is no need to consider the above two modes (Repair Mode, Normal Mode). You only need to consider the relationship between the four modes below the Normal Mode above. Matters to be considered at this time include the location, name, logical operator, proposition combined with the logical operator, use of data, etc. of each component.

Positions, names, logical operators, and propositions combined with logical operators are used to form relationships between components. The idea is to consider how the Seamark program should be structured. Afterwards, these components configure the data necessary to perform the defined functions. Through this, you can complete the use of control structures and data, which are the basic components of programming. In this way, users can sequentially construct the structure of the requirements model one by one.

And these requirements models can be integrated around the same component, Normal Mode. This is the same as the normal way to integrate code. Naturally, Repair Mode and Normal Mode are located at the bottom of the Seamark component, and the above four modes are configured sequentially under Normal Mode. In order to algorithmize this relationship, the upper, lower, lower, and sequential relationships between components are explained above. By integrating the two requirements models above, the relationship between components from the perspective of each requirements model can be expressed in an integrated form of code, as shown in FIG. 5. Users can gradually construct requirements models in terms of each function, and the programming machine automatically integrates these requirements models.

When constructing the components of each requirements model in this way, there are components whose meaning cannot be split any further or whose meaning does not need to be split any further. At the bottom, you can place reused fragments of code or single sentences. This defines the members of all requirements model components. This is how to construct a requirements model, and once 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 consists of structure definitions 311-1 to 311-n for each requirements model. The structure definitions 311-1 to 311-n may include location settings for each component, name settings for each component, logical operator settings for each component, and data settings for each component.

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

1) Construct a fragmented requirements model for each component identified by name using logical operators and hierarchical sequential positional relationships.

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

3) The structure and contents that make up the requirements model are expressed mathematically and correspond to codes.

The content composition 312 is also composed of each content composition (312-1 to 312-n) for each requirements model to suit each requirements model. Each content configuration (312-1 to 312-n) consists of one content (313) for one component. Content 313 consists of a single sentence or fragment code.

When the user logically defines the structure of the requirements model (311) and configures the content (312), the calculation unit 120 performs structural integration of the requirements model (321).

In the process of integrating the structure, the operation unit 120 uses a programming machine to identify inconsistent components between the requirements models (322). To elaborate, when mismatched component identification 322 occurs, the calculation unit 120 displays this on the display unit 130 to inform the user that there is a currently identified mismatched component through guidance information. Here, the programming machine is software with an algorithm that integrates the requirements models so that the meaning of all requirements models is maintained.

Additionally, the programming machine can identify mismatched components between requirements models. Additionally, the programming machine can verify grammatical errors in the structure and content of the requirements model.

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

Continuing to refer to Figure 3, the user modifies the corresponding requirements model by modifying the corresponding components. By repeating this process, if the user no longer configures the requirements model and the programming machine does not identify inconsistent elements, the user receives an integrated model that integrates the currently configured requirements models from the programming machine and corresponding code information (330 ) is obtained.

Program completion through the construction method of the requirements model is explained as follows.

The process of configuring, integrating, and verifying the requirements model is performed repeatedly from sketching the requirements model at a macro level to completing the detailed configuration. This is the same way as configuring a general program. However, in one embodiment of the present invention, the user constructs a requirements model based on fragmentary logic, and a programming machine performs integration, verification, and code generation.

Once the user completes the code structure by repeatedly executing the requirements model with an automatic programming machine, the remaining task is to insert content into the bottom component. 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 construct the content mathematically is to construct 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, content can be added as the last member of the component. The content can be composed of single sentence types and various code expressions or data values, as shown in the example below. For example,

printf("Hello world! ")

The above single sentence can be expressed mathematically as follows.

(kind of statement, String)

where kind of statement ∈ K = { x | x is a type of statement in C code}, String = { x | x is a combination of words }

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

This can be very cumbersome if it is text-based programming, but in graphic-based programming, selecting the type at the location where the content will be added and entering the input value may not be so cumbersome. The same applies when using voice. In addition, if the content consists of a piece of code to be reused rather than a single sentence, it can be expressed mathematically by naming the piece of code and forming (piece code format, name) as a member. When generating code through integration of the requirements model, simply insert the fragment code at the location of the corresponding name.

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

Figure 4 is a flowchart showing a programming process through a requirements model according to an embodiment of the present invention. Referring to FIG. 4, first, the command generated by the user for the structure of the requirements model is converted into input information in the input unit 110, and the structure and content of the requirements model are defined according to this input information (step S410,S420).

Afterwards, the calculation unit 120 integrates the structures of the requirements models and identifies components between the requirements models to determine whether there are mismatched components (steps S440 and S450).

In step S450, if there is a mismatched component as a result of the confirmation, the calculation 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). Afterwards, steps S420 to S450 proceed.

On the other hand, in step S450, if there are no mismatched components as a result of confirmation, the annual unit 120 integrates the structures of the requirements models to generate code information (step S460). In other words, automatic programming takes place.

Figure 5 is an example of code according to an embodiment of the present invention. In particular, Figure 5 is an example of code written in C-language, and Figure 5 shows various modes of a program called "Seamark". Referring to Figure 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 consist of a single sentence or piece of code and is located in the curly brackets at the bottom. Of course, the requirements model can be additionally configured to detail the structure for each mode.

Here, the bottom brace means a brace that no longer has braces within it. If a single statement exists in the middle of the requirements model structure, that is, at a location other than the bottom component, curly braces for the mathematical logic structure described above can be added before and after the single statement. This means that components of sequential logic are additionally constructed at that location, that is, logic consisting of only braces is constructed, and a single sentence is placed inside it. This also has the same meaning as placing a single sentence at the bottom position. Therefore, it can be said that it is a characteristic of generalized programming that content (single statement or piece of code) that is not 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 as well as logical operators are required to express the structure. Since propositions are made up of data, the use of data in code should also be included in the category of structure. Here, the data value is unnecessary. This is because the logic is structured and data values are not used.

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

Programming is the process of logicalizing the purpose to be performed and expressing it as code. In other words, the purpose consists of several requirements models, and programming is to logically structure and integrate these requirements models. Performing programming based on what was explained above means structuring content related to a specific purpose into the logical structure described above and filling it with meaning that cannot be further divided.

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

Since requirements are structured in natural language, it is very ambiguous, so if we structure the contents using the logic of sequential, selection, and repetition, which is the logic used above, to form fragmentary requirements, the role of the programming machine is to create fragments of these requirements. The goal is to produce code by correctly integrating them, and in this process, the role of the programming machine is to detect inconsistencies between requirements models and grammatical errors in the code.

A machine cannot judge whether a requirement is right or wrong. This is because it is defined by the user. However, errors resulting from inconsistencies between user-defined requirements can be detected. However, the machine cannot determine which of these requirements is correct.

This is because this is also determined 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 has the function of integrating requirements models, producing integrated code for the integrated requirements model, and detecting errors in the integrated code and inconsistencies between requirements. Perform.

Users compose requirements and correct grammatical errors in the requirements and any inconsistencies between the requirements. In other words, the user's role is to formulate the correct requirements. And the requirements defined by the user are expressed in mathematical logic, which is defined in more detail later.

Figure 6 is an example of positional relationships between blocks with logical operators 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. To express this relationship, the sequential and hierarchical relationships between components are expressed using nested ordered pairs. However, the parentheses are omitted in this expression. This is because when expressing multiple components, the number of parentheses increases and the visibility of the expression decreases.

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 position relationship 620 corresponding to the example of code information 610 expressed on the left side. The highest element 623 is (1), the lowest element 621 is (1, 2, 2), and the next highest element 622 of the lowest element 621 is (1, 2). Both (1) and (1,2) are higher order components of (1,2,2). (1,2,1) sequentially precedes (1,2,2), and the next highest component (1,2) is the same. Sequential positional relationships are under the same next-level component. Therefore, (1,1,1) and (1,2,1) are not sequential positional relationships.

In detail, each component is the lowest level component of the lowest layer, the next higher level component placed at the adjacent upper level of the component, the higher level component placed at the upper level including the next higher level component, and the lower level level placed at the adjacent lower level of any component. Components, lower-level components including lower-level components, the highest-level component at the top of each component, and the lowest-level component at the bottom of each component, which is a hierarchical relationship between components. distinguish between

Figure 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 an embodiment of the present invention. In other words, the requirements model can be expressed with only name and location relationship. All requirements models can be constructed piecemeal as long as they are correct. This is because algorithms that integrate requirements models exist. Therefore, users can configure and manage requirements models from various perspectives. Referring to Figure 7, the "Seamark" (720) program consists of Repair Mode (711) and Normal Mode (712).

Figure 8 is an example of a requirements model specifying the sub-configuration of "Normal Mode (712)" shown in Figure 7. That is, together with Figure 7, it is an example of a requirements model to explain concepts such as definition and integration of the requirements model. Referring to Figure 8, "Normal Mode (712)" consists of "Tactical Mode" (810), "Part Training Mode" (820), "All Training Mode (830)", and "Replay Mode (840)". there is. Every component in the code has its own role. Therefore, you can give a unique name to that role. In this way, logicalizing the structure of the code through the name has the meaning of symbolizing the actions defined in the corresponding area. In other words, it assigns mathematical symbols to actions. In the present invention, a program is expressed by structuring hierarchical sequential symbols. The name, which is a symbol for behavior, is used as a unique identifier to distinguish the same component between each requirements model.

When we look at it from the perspective of a completed program, the concept becomes clearer. Suppose we have a random, completed program, and we give each block of the program a meaningful name. The program then becomes a structure structured by name. When there is a specific function performed in the program, it can be said that the function in the program is composed by combining the names of the corresponding blocks. In other words, it can be said that the function is executed by sequentially executing blocks with a certain name. This is a model configuration in terms of its functionality, and this model is named a requirements model in the present invention. This is a function performed from a specific perspective and is a piece of knowledge known by the programmer. The main concept of the present invention is to automatically generate code by integrating and verifying these fragmented functions.

There are two requirements models in Figures 7 and 8, and it is easy to infer how they will be integrated. You can gradually connect the components of the next-order relationship and sequential relationship around the components of the same name, “Seamark” (720) and “Normal Mode (712).” This is the concept of integrating the structure of the model using positional relationships and names.

Each component is related by positional relationship, but assigning a unique name to this position constitutes the structure of a fragmentary program with meaning. The main idea of the present invention is to perform automatic programming using this requirements configuration method. As explained earlier, components consist of names, locations, logical operators, propositions, and declaration and use of data. Additionally, components can be expressed mathematically. In other words, it can be expressed as a mathematical equation. An example of this is as follows:

- (Definition) Requirements Model

M = {e | e = (name, (p _n-1 , a _nk ), 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 above mathematical model, it means that the requirements model (M) described above can be expressed as a set composed of components (e). Each component has a unique name, a position that indicates the relationship between components (i.e., positional relationship), and a type (t) and proposition (c) of logical operators such as while, if, none, etc. do.

Data used by a component is also represented: there is a declaration data set (D _d ), which refers to data originating from that component, and an access data set (D _a ), among the data used in the next-level component, there is a conditional data set (D _c ) used in the proposition of the current component. The structure of the requirements model is represented by the location and name of the components, there are types and propositions of logical operators to express logical relationships between each component, and declaration/access/condition data to express data use between components. You can assume that there is. In this way, the elements that make up the component are defined as members.

Mathematical models were introduced for automatic integration and verification of requirements models. Among the structure and contents that make up the code, the above mathematical model expresses only the structure. As explained previously, mathematical expressions of single sentences and fragment codes can be added as the rightmost member of the mathematical model set. Therefore, all requirements models, that is, structure and content, can be expressed mathematically.

Meanwhile, the correspondence between component members and code is as shown in the table below.

member of the component Corresponding C language code p Location of braces name None (comment) t
Sequence/Selection/Loop Logical operators below
None/If/While c proposition D _c doesn't exist D _d Declaration data sentences ex) char name; D _a doesn't exist

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

For example, if there is a requirements model like Figures 7 and 8, place braces at each position, describe the name as a comment at the top of the braces as shown in Figure 5, place a logical operator before the braces, and then place the parenthesis Describe the proposition with . And inside the braces, you can write statements declaring the components of the declaration data set. This is a way to automatically code the structure of the requirements model. If there is a single sentence or piece of code as content in the bottom component, inserting the content at that location completes the code.

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

Although all logical thinking methods may be the same, in the requirements model, integration between them is centered around common factors. There are two requirements models in Figures 7 and 8. Common components are "Seamark" and "Normal Mode". Therefore, integration is possible around common factors. Specifically, the way to integrate models is to keep the shape of each requirements model topologically the same. This is the same concept as the general method of code integration. If the relationship between the components that make up the integrated requirements model remains the same for the above two requirements before integration, the integrated requirements are integrated into each requirement. This means that the meaning of the matter can be reflected correctly. This is explained based on the mathematical model as follows. In Figures 7 and 8, the Seamark component and the Normal Mode component are common factors. Integrating two models around this is the same as inserting components from another model into one model.

Since the user's intention when defining requirements is to configure four modes under Normal Mode, the four modes shown in FIG. 8 can be configured under Normal Mode in FIG. 7. Expressing this in a logical relationship, in the model of FIG. 7, non-identical components in a next-higher and lower-lower relationship are inserted centering on the same component among the components of the model in FIG. 8, and in a sequential relationship with the inserted component. The way to integrate the two models is to repeat by inserting existing components and inserting components that have 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, in the position (1,3,4) expressed as a nested ordered pair, the position of the next highest component is (1,3), (1,3,1), (1,3,2) ), (1,3,3), etc. are in a sequential relationship. As another example, the next highest component of position (1,6,7,3) is (1,6,7) and the next lowest component is (1,6,7,3,1). In other words, the positions and numbers of nested ordered pairs expressing positions include the positions of all higher-order components. This is because in the above example, the positions of the higher-level components are (1), (1,6), and (1,6,7). In other words, the hierarchical and sequential positional relationship between the components of the requirements model can be known through the positional expression. Therefore, in the above integration method, if the position of another requirements model is sequentially inserted into one requirements model with the next-highest, second-lowest, and sequential relationships centered on components with the same name, all components of the two models Integration is possible.

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

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

To explain in more detail using the mathematical model defined above, as explained previously, positions and names can be integrated around components with the same name, and members of components such as logical operators, propositions, and data are the same. Only the components of the name are integrated, and components that do not have the same name can be left as is.

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

Since the integration of logical operators involves the logic of sequence/selection/repetition, selection and sequence can be determined by selection, and selection and repetition can be determined by repetition. Propositions are unified by AND logic because all propositions must be satisfied, and data is composed of a union because it must be used in all components. As described above, the rules for integrating members of the same component can be mathematically expressed as follows.

- (Definition) Integration method between identical components

For an arbitrary component e _alpha , the components e _1alpha and e _2alpha of the same name are combined.

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

Logical operator integration

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.

When an arbitrary integrated model exists, verification of the model is to check whether there are grammatical errors and whether each requirement model defined by the user has been correctly integrated. In other words, you only need to ensure that the requirements models are grammatically correctly structured and integrated so that the meaning of each requirements model is maintained.

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

Syntactic errors between components detect grammatical conflicts that users make when defining the requirements model. Since components are composed of name, location, logical operator, proposition, declaration/access/condition data, you only need to check for conflicts between components for each member. This is because there is no conflict between different types of members. In other words, there is no conflict of names for locations. This means that using the name B in place of A will not cause a grammatical error. The same goes for other types of members.

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

There are no conflicting elements between logical operators and conditional propositions. Since declaration data means the starting point of data, declaration data with the same name should not exist in a component higher than the corresponding component. Access data means using data declared in the parent component, so declared data must exist in the parent component. Since conditional data means that the data of the next-level component is used in the proposition, the conditional data must be included in the declaration and access data of the next-level component.

The above are member conflict elements between components for one requirements model. Grammar verification should also be performed after integration of the requirements model. This is because the use of data in a requirements model defines the start and use from the perspective of constructing a single model, so when the scope of the model expands, the use of data must be newly defined.

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 as its original meaning. Since the model is composed of location, name, logical operator, proposition, and data according to the mathematical model, check whether each member is reflected correctly. As explained earlier in the integration process, it is possible to check whether the positional 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 shown in Figures 7 and 8 remain the same in the integrated model, the configuration of each requirements model remains the same in the integrated model, so it is topologically correctly configured. It can be said that it has been done. If components with the same name do not exist, they cannot be integrated and verification is not necessary. This is because not having components with the same name in the requirements model means not having a method for integration. In this case, the requirements model must be structured in more detail so that the same names are configured.

As the two models are integrated in Figures 7 and 8 through location and name, once it is verified that they are structurally correct, components with the same name are checked to see if logical operators, propositions, and data are correctly integrated using the previously defined integration method. It can be verified.

The mathematical model explains whether each requirement has been correctly integrated into the integrated model as follows. Since the meaning of each requirements model is correctly integrated in the integrated model, the positional relationship between the components that make up one requirements model must be maintained. In other words, it must be confirmed that all higher-order relationships and sequential relationships between components of one requirements model are maintained as higher-order relationships and sequential relationships in the integrated model. In an integrated model, each component must have only one name as a unique identifier. Through this, it is possible to verify whether the location and name of each requirements model are correctly integrated. The remaining members, such as logical operators, conditions, and data, are verified by checking whether the members of each requirements model's components are included in the components of the same name in the integrated model. This mathematically verifies that the meaning of each requirements model has been correctly integrated into the integrated model.

Meanwhile, once the automatic program is completed, all declared data can be managed through a mathematical model. All data used in the mathematical model defined above can be integrated into one set, and data that changes can be distinguished by the content at the bottom. Therefore, it is also possible to sequentially configure 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. Additionally, it is possible to reconstruct from multiple perspectives how specific data is changed and structured in the integrated model. This means that mathematical analysis of all data in the program is possible.

Additionally, the steps of the method or algorithm described in relation to the embodiments disclosed herein are implemented in the form of program instructions that can be executed through various computer means such as a microprocessor, processor, CPU (Central Processing Unit), etc., and are computer readable. Can be recorded on any available medium. The computer-readable medium may include program (instruction) codes, data files, data structures, etc., singly or in combination.

The program (instruction) code recorded on the medium may be specially designed and constructed for the present invention, or may be known and usable by those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROM, DVD, and Blu-ray, and ROM and RAM. Semiconductor memory elements specially configured to store and execute program (instruction) code, such as RAM), flash memory, etc., may be included.

Here, examples of program (instruction) code include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may 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 unit
120: calculation unit
130: Exhibition Department
140: storage unit
210: Model structure definition module
220: configuration module
230: structural integration module
240: Mismatch element identification module
250: Code generation module

Claims (18)

An input unit 110 that receives input information for defining the structure of a plurality of requirements models (311) and configuring content (312);
an operation unit 120 that identifies whether there are inconsistencies between the multiple requirements models and, if there are no inconsistencies, integrates the multiple requirements models to create an integrated model and generates code information of the integrated model; and
an exhibition unit 130 that outputs information on a plurality of the requirements models corresponding to the mismatched components under the control of the annual unit 120;
A programming system through a requirements model comprising:
According to claim 1,
The calculation unit 120,
a model structure definition module (210) that performs structure definition (311) of a plurality of the requirements models;
A configuration module 220 that configures the contents of a plurality of the requirements models using fragment codes or single sentences (312);
A structural integration module 230 that integrates a plurality of the requirements models;
an inconsistency element identification module 240 that identifies whether there are inconsistency components between a plurality of the requirements models; and
A programming system using a requirements model, comprising a code generation module (250) that generates the code information if there is no mismatched component.
According to claim 2,
The structure of the requirements model is
repetition (proposition) { }
choice (proposition) { }
Contains a sequence { } (where repetition, selection, and sequence are logical operators, and parentheses and braces represent propositions and blocks) , and the fragment code and single statement are of the requirements model structure consisting of the above logical operators. A programming system through a requirements model, characterized by what is in the bottom curly brackets.
According to claim 2,
The inconsistent element identification module 240 is a programming system through a requirements model, characterized in that if there are inconsistent components between a plurality of the requirements models, it generates guidance information indicating to correct the inconsistent components.
According to claim 1,
A programming system through a requirements model, characterized in that the structure definition 311 is defined using logical operators.
According to claim 1,
The structure 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 setting the location, name, and logical operator of each component. , propositions, and data are members of each component. A programming system through a requirements model.
According to claim 6,
A programming system using a requirements model, wherein the member of each component and the code corresponding to the member are configured in advance as a lookup table.
According to claim 6,
Each of the components includes a lowest component 621, a next-highest component 622 adjacent to the component 621, and components 622 and 623 located above the component 621. A programming system through a requirements model characterized by forming a hierarchical relationship between components as the highest level component (623) placed at the top of the components.
According to claim 6,
A programming system through a requirements model, characterized in that the sequential positional relationship is a relationship between components (621) located below the same next-level component (622).
According to claim 6,
A programming system through a requirements model, characterized in that the member name of each component is used as a unique identifier to distinguish the component during the automatic programming process.
According to claim 6,
A programming system through a requirements model, wherein the plurality of components include propositions and data related to the components.
According to claim 6,
The integration is centered on components with the same name and position, 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 the members of each component, including the logical operator, the proposition, and the data, are integrated only for components with the same name. A programming system through a requirements model, wherein components that are not present are maintained as is.
According to claim 12,
A programming system through a requirements model, wherein the components are expressed as a mathematical model.
(a) the input unit 110 receiving input information for defining the structure (311) and configuring content (312) of a plurality of requirements models;
(b) the calculation unit 120 identifies whether there are inconsistencies between the multiple requirements models, and if there are no inconsistencies, integrates the multiple requirements models to create an integrated model and generates code information for the integrated model. ; and
(c) the display unit 130 outputting component information of the requirements model for a plurality of the requirements models corresponding to the mismatched components under the control of the calculation unit 120;
A programming method through a requirements model comprising:
According to claim 14,
In step (b),
A model structure definition module 210 performing structure definition 311 of a plurality of the requirements models;
A configuration module 220 performing content configuration 312 of a plurality of the requirements models using fragment codes or single sentences;
The structural integration module 230 integrates a plurality of the requirements models;
identifying, by the inconsistent element identification module 240, whether there are inconsistent elements between a plurality of the requirements models; and
A programming method using a requirements model comprising: generating, by the code generation module 250, the code information if the mismatched component does not exist.
According to claim 14,
The structure definition 311 includes setting the position 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. A programming method through a requirements model, wherein location, name, logical operator, proposition, and data become members of each component.
According to claim 16,
A programming method through a requirements model, characterized in that the plurality of requirements models are classified and managed based on the membership 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.