Business logic formulation method, program, and business logic formulation device

Abstract

The present specification relates to a method for formalizing business logic, wherein the business logic formalizing device may include the steps of obtaining natural language-based business logic representing customer requirements, the business logic formalizing device extracting a graph-based data dictionary representing entities or relations from the business logic, and the business logic formalizing device generating a graph-based query that represents entities or relations nested based on the data dictionary from the business logic.

Description

Technology Field

[0001] The embodiments relate to a business logic formalization method, a program, and a business logic formalization device. Background Technology

[0002] In the customer requirements analysis phase of software development, business logic is written in Korean sentences. This business logic can be described as natural language-based business logic that represents customer needs. However, natural language inevitably possesses incompleteness. Due to its concise nature, natural language is often not detailed enough to meet the requirements of software development.

[0003] In general system integration (SI) development, the requirements analysis stage, which analyzes customer needs, is the least systematized phase. Since the output of the requirements analysis stage is in natural language, it can be incomplete, implicit, and vague. Due to these characteristics, the generated natural language cannot be utilized in the actual design and coding stages, leading to difficulties in software development, such as the need to return to the coding stage after conducting interviews with the customer. Prior art literature

[0004] Korean Patent Publication No. 10-2014-0049680 (April 28, 2014) The problem to be solved

[0005] In the relationship between data models and natural language, natural language written without a data model may result in the vague selection of nouns and verbs, potentially generating words that are not present in the data model or words with meanings different from customer requirements.

[0006] In the customer requirements analysis phase of software development, methods and devices are required to synchronize customer requirements with data models. means of solving the problem

[0007] A business logic formalization method according to one embodiment may include the steps of: a business logic formalization device acquiring natural language-based business logic representing a customer's requirements; the business logic formalization device extracting a graph-based data dictionary representing an entity or relation from the business logic; and the business logic formalization device generating a graph-based query that represents the entity or relation nested based on the data dictionary from the business logic.

[0008] Additionally, the above query can be defined using reserved words including For, which binds a variable to an object; Of, which constrains the object; Let, which specifies a path to the variable; Where, which filters the object; and Return, which returns the processed code.

[0009] Additionally, the above query may further include at least one reserved word among Group by, which groups objects with the same specified attribute value and outputs the result of applying an aggregate function to each group, and Having, which applies a constraint consisting of an aggregate function.

[0010] In addition, the business logic formalization method of the embodiment may further include the step of the business logic formalization device generating formalized natural language-based business logic from the query.

[0011] In addition, the step of generating the structured natural language-based business logic can generate the structured natural language-based business logic by matching natural language patterns from the query using a parsing tree.

[0012] In addition, if the business logic formalization device does not approve the generated formalized natural language-based business logic, it may return to the step of extracting the data dictionary.

[0013] In addition, the business logic formalization device may return to the step of extracting the data dictionary, re-extract the data dictionary, and if the query is invalid in the re-extracted data dictionary, output the invalid query by underlining it.

[0014] Additionally, the business logic standardization method may further include the steps of: the business logic standardization device storing or creating at least one scratch template corresponding to the business logic in advance; the business logic standardization device generating standardized business logic by inputting parameters of the scratch template using the query and object CRUD (create, read, update, delete); and the business logic standardization device generating the standardized business logic into Java code and registering it as a service.

[0015] A computer-readable medium according to another embodiment is one or more non-transitory computer-readable media storing one or more instructions, wherein the one or more instructions executable by one or more processors process operations using a graph convolutional network (GCN), wherein a business logic formalizing device obtains natural language-based business logic representing customer requirements, the business logic formalizing device extracts a graph-based data dictionary representing entities or relations from the business logic, and the business logic formalizing device can generate a graph-based query representing entities or relations nested from the business logic based on the data dictionary.

[0016] A business logic formatting device according to another embodiment includes a memory configured to store a plurality of instructions, an interface unit for acquiring natural language-based business logic representing customer requirements, and a processor functionally coupled with the memory. The processor may be configured such that when the plurality of instructions are executed, the business logic formatting device acquires natural language-based business logic representing customer requirements, the business logic formatting device extracts a graph-based data dictionary representing entities or relations from the business logic, and the business logic formatting device generates a graph-based query that represents entities or relations nested from the business logic based on the data dictionary. Effects of the invention

[0017] The embodiment makes it easier to write queries than with existing languages. In addition, since the embodiment does not require prior knowledge of relational models, users can easily learn and read it. Therefore, according to the embodiment, even users who are not proficient in programming languages ​​can develop software with minimal training.

[0018] The effects of the embodiments are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description of the invention. Brief explanation of the drawing

[0019] Figure 1 is a flowchart of a business logic standardization method of an embodiment. FIGS. 2(a) to FIGS. 2(d) are conceptual diagrams illustrating the generation of a data dictionary of an embodiment. FIG. 3 shows an integrated data dictionary according to one embodiment. Figures 4(a) and 4(b) are conceptual diagrams illustrating pattern matching of a parse tree. Figure 5 is a block diagram of a parse tree of an embodiment. FIGS. 6(a) and FIGS. 6(b) are conceptual diagrams illustrating the problem of simple matching in the embodiment. FIG. 7 is a flowchart of a business logic formalization method according to another embodiment. FIGS. 8(a) to FIGS. 8(d) and FIGS. 9(a) to FIGS. 9(e) illustrate examples of a business logic formalization method that is automatically completed according to an embodiment. Figure 10 shows the data models of Figures 8 (a) to 8 (d) and Figures 9 (a) to 9 (e). FIG. 11 is a block diagram of a business logic formalization device according to one embodiment. Specific details for implementing the invention

[0020] In describing the embodiments of this specification, detailed descriptions of known technologies related to this specification are omitted if it is determined that such descriptions would unnecessarily obscure the essence of this specification. Furthermore, the terms described below are defined in consideration of their functions within this specification, and these definitions may vary depending on the intentions or practices of the user or operator. Therefore, such definitions should be based on the content throughout this specification. Terms used in the detailed description are intended merely to describe the embodiments of this specification and should never be interpreted restrictively. Unless explicitly stated otherwise, expressions in the singular form include the meaning of the plural form. In this description, expressions such as "include" or "comprise" are intended to refer to certain characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof, and should not be interpreted as excluding the existence or possibility of one or more other characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof other than those described.

[0021] Terms containing ordinal numbers, such as “first,” “second,” etc., may be used to describe various components, but said components are not limited by said terms. These terms may be used solely in a nominal sense to distinguish one component from another, and their sequential meaning is determined not by such nomenclature but by the context of the description.

[0022] The term “and / or” is used to include all cases of any combination of the multiple items in question. For example, “and / or B” means including all three cases, such as “and B.”

[0023] When it is stated that one component is "connected" or "joined" to another component, it should be understood that while it may be directly connected or joined to that other component, there may also be other components in between.

[0024] Hereinafter, specific embodiments of the present specification will be described with reference to the drawings. The following detailed description is provided to facilitate a comprehensive understanding of the methods, devices, and / or objects described in the present specification. However, this is merely illustrative and the present specification is not limited thereto.

[0025] Figure 1 is a flowchart of a business logic standardization method of an embodiment.

[0026] Referring to FIG. 1, the business logic formalization method of the embodiment may include the step (S110) in which a business logic formalization device obtains natural language-based business logic representing a customer's requirements, the step (S120) in which the business logic formalization device extracts a graph-based data dictionary representing an entity or relation from the business logic, the step (S130) in which the business logic formalization device generates a graph-based query representing the entity or relation by nesting it based on the data dictionary from the business logic, and the step (S140) in which the business logic formalization device generates formalized natural language-based business logic from the query.

[0027] The problem with natural language writing is its incompleteness. For example, in the case of business logic such as "must complete prerequisite courses," the object being completed is a course, not a subject, yet customers and developers often use the terms "subject" and "course" interchangeably. Developers who lack knowledge of the customer's industry struggle with development because it is difficult for them to understand the precise meaning of the terms used by the customer during coding.

[0028] Another problem with natural language writing is connotation. If the logic is not sufficiently detailed due to connotation, it also causes difficulties for developers. For example, the natural language statement "The student completes course (a) and opens subject (b). And there is a prerequisite (c) for subject (b) and prerequisite (c) must be included in subject (b)" can be seen as detailed enough to be necessary for a developer's coding language logic development, but in reality, it is very rare for people to express natural language in this way in real life.

[0029] Another problem with natural language writing is its vagueness. Since natural language is not restricted by form, writers can produce creative writing in literary works. However, from a developer's perspective, the sheer number of language choices makes writing feel daunting. As such, converting natural language into coding languages ​​or vice versa is a difficult task.

[0030] The embodiment presents a new methodology that can be utilized in the requirements analysis stage, which analyzes customer requirements by interpreting natural language representing customer requirements.

[0031] Steps S110 and S120 are steps in which a business logic formalizing device acquires natural language representing customer requirements and extracts a graph-based data dictionary representing entities or relationships from the business logic.

[0032] Developers can obtain natural language-based business logic (e.g., "prerequisite courses must be completed") through interviews with customers and expand the necessary data dictionary using a business logic formalization mechanism. Based on the data dictionary, developers can then formulate queries. Additionally, developers can verify whether the formalized natural language generated from the queries matches the customer's intent. If it does not match the customer's intent, developers can modify the data dictionary and rewrite the queries. Through this sequence, sufficiently detailed natural language can be obtained. An example can present such a systematized requirements analysis methodology.

[0033] Steps S130 and S140 are steps in which a processor included in a business logic formalization device generates a query that represents the object or relationship by nesting it based on a data dictionary, and generates formalized natural language-based business logic from the query.

[0034] FIGS. 2(a) to FIGS. 2(d) are conceptual diagrams illustrating the generation of a data dictionary of an embodiment. FIG. 3 shows an integrated data dictionary according to one embodiment.

[0035] Referring to Fig. 2, the customer can convey to the developer a requirement that "prerequisite courses must be completed." This is a business rule required by the customer company. To enforce this rule, the developer can create a data dictionary such as (a) in Fig. 2.

[0036] In Figure 2(a), the prerequisite course and student, indicated by ellipses, are entities, and the straight line 'complete' between the entities represents the relationship between the entities. This can be expressed as the following query.

[0037] [Query 1]

[0038] Student=( for $ in student leta = $x.completed.prerequisites where a is not empty r return $x).

[0039] This means that the set of students is equal to the return set of folwr(for of let where return).

[0040] Query 1 can be expressed in natural language as "Students must complete at least one prerequisite course." However, this is not the query the customer wants. In the above query (folwr, for of let where return), $x is the key variable, which allows the business logic to be handled more formally. 'a' is the set of prerequisite courses, and the where clause expresses the condition that 'a' is not an empty set. 'return' returns the set of students ($x) that satisfy the condition. It also states that every set of students is equal to the set of students x that satisfy the condition. This generated business logic differs from the logic the customer wants: "Students must complete prerequisite courses." A detailed explanation of the folwr query will follow.

[0041] In Figure 2(b), a subject entity was introduced. A student can complete prerequisite courses and also complete subjects. The logic 'a student must complete at least one prerequisite course' must be redefined as 'when a student completes a subject, they must have already completed the prerequisite courses for that subject.'

[0042] Developers can enhance the data dictionary of Fig. 2(b). The data dictionary differs from an Entity Relationship Diagram (ERD) in that it does not express cardinality and lacks primary keys and foreign keys. This query is easier to write than SQL and is easier to understand and implement because it does not involve joins. Furthermore, no prior knowledge of the relational model is required.

[0043] The developer can redefine the business logic following based on the data dictionary of Figure 2 (b).

[0044] [Query 2]

[0045] Student = ( for $x in student let a = $x.course.prerequisite.prerequisite, b = $x.course.prerequisite where a < b return $x)

[0046] Query 2 can generate the following logic. The generation logic is 'the prerequisite course (a) of the course completed by the student must be included in the course (b) completed by the student'. At this point, the developer can see that the course and prerequisite course in the data dictionary overlap. And as the analysis continues, the developer can discover further requirements. The developer can discover that prerequisite courses can be expressed as a relationship called prerequisite requirements, as shown in (c) of Fig. 2.

[0047] Integrating (c) of Fig. 2 into an existing data dictionary results in (d) of Fig. 2.

[0048] Then, the above query 2 becomes invalid.

[0049] [Query 3]

[0050] Student = ( for $x in student let a = $x.Course.Prerequisite.Prerequisite. , b= $x.Completion.Prerequisites where a < b return $x)

[0051] Underline is an error message that can be automatically detected by the processor of the business logic formalization unit because the prerequisite no longer exists. Developers can modify follow as follows.

[0052] [Query 4]

[0053] Student = ( for $x in student let a = $x.course.prerequisite.course, b = $x.course.prerequisite where a < b return $x)

[0054] At this point, as further analysis is performed, the developer may discover that the student is completing a course rather than a subject, and the subject is opening a course. The integrated data dictionary is as shown in Fig. 3. When the data dictionary changes, the query may no longer be valid, and this can be determined by the processor. In the example, the syntax '$x.complete.subject.prerequisite.' and '$x.complete.subject' is no longer valid because the student is completing a course rather than a subject. At this time, the processor can validate and display an error message underline.

[0055] [Query 5]

[0056] Student = ( for $x in student let a = $x.courses_at_offering, b= $x.courses where a < b return $x)

[0057] Developers can change it as follows in the query.

[0058] [Query 6]

[0059] Student = ( for $x in student let a = $x.courses.courses, b=a.prerequisites.courses where b < a return $x)

[0060] The creation business logic is as follows: 'Let (a) be the course offered among the courses completed by the student, and let (b) be the prerequisite course for course (a). Course (a) includes course (b).'

[0061] The above-described embodiment explains a series of processes in which, if the natural language-based business logic is not approved, the process returns to step S120 to extract a graph-based data dictionary representing entities or relationships from the business logic.

[0062] The data dictionaries in FIGS. 2(a) through 2(d) differ from an entity relationship diagram (ERD) in that they do not express cardinality and lack primary and foreign keys. Compared to the relationship entity diagram (ERD), which is a representative data model, the data dictionary of the embodiment can provide a higher level of abstraction because the entities do not constrain the first normal form (1NF). Furthermore, while an ERD requires cardinality, the dictionary of the embodiment does not. Cardinality requires more business logic knowledge than expected, making it burdensome to describe it during the analysis of customer requirements. Additionally, ERDs often require primary and foreign keys, which also poses a burden during the analysis phase. Since the entities in an ERD are assumed to be in a table form, they also require detailed business logic knowledge, which can also be a burden during the analysis phase.

[0064] follow query

[0065] The `folwr(for of let where return)` query is simpler than SQL, making it easier for users to learn and read. While SQL is based on a relational model, `folwr` is based on a simple graph model. Because SQL relies heavily on joins based on a relational model, `folwr` does not use joins; instead, it uses nesting, making it much easier to learn. Joins are powerful, but only experienced developers can understand and write them. Since `folwr` does not use joins, even novice developers and customers can read and write it with minimal training.

[0066] The reserved words that folwr can include are as follows.

[0067] For $x in entity: binds $x to the entity object. Of It constrains the entity as {path[1]} = value1, {path[2]}=value2, … {path[k]}=value k. Let a[1] = path[1], a[2]=path[2], … a[k]=path[k] : Assigns path[i] to variable a[i]. path ends with an entity, property, or relationship. For example, path = $x._boarding.passenger ends with the passenger entity, $x.departureport ends with a property, and $x.boarding ends with a relationship.

[0068] Where It is used to filter entities. Operands are restricted to $x (the entity binding variable), a, and b (the variable binding the path in let). For example, in 'let a = $x_.boarding.passenger.where a > 20', the age of passengers on flight $x is 20 or older. Here, the underscore in _boarding signifies the inverse of the boarding relationship.

[0069] ReturnIt returns (a, b) with object-binding variable $x and path-binding variable. If group by is present, only the group by variable can be included in the return statement, and the rest must be aggregated using an aggregate function.

[0070] Group by It groups objects with the same value for a specified attribute and outputs the result of applying an aggregate function to each group. For example, 'for $x in Product let a = $x._Sold.Order group by $x.Name return $x.Name, max(a.Order.Date)' groups by product name and returns the most recent order date for each group.

[0071] Having It applies constraints consisting of aggregate functions. For example, `for $x in Product let a = $x._Sold.Order group by $x.Name having max(a.Date) < 2023 return $x.Name, max(a.Date)` returns only products with a recent order in 2023 or less and the most recent date.

[0072] For example, 'The percentage of course grades B+ or higher must not exceed 50%' can be expressed as follows.

[0073] [Query 7]

[0074] Course = ( for $x in courses let a = ( for $y in $x._completed.student where $y.Completion.Grade > B+ return $x, count($y)), b = count($x._이수.학생) where a.count < b *0.5 return $x)

[0075] Let (a) be the number of students whose grade in the course is B+ or higher, and let y be the number of students (b) who take the course. Then x is less than 0.5 times y.

[0076] As mentioned above, developers may use "course" and "subject" interchangeably. However, during the process of matching with the data dictionary, developers may understand "grade" as an attribute of the completion relationship; in such a setting, developers use "course" instead of "subject." In this way, developers can use terminology consistently in system development or within the organization.

[0077] Figures 4(a) and 4(b) are conceptual diagrams illustrating pattern matching of a parse tree.

[0079] Natural language generation

[0080] Parse trees can generate natural language by matching patterns. For example, there is a data model like (a) in Fig. 4.

[0081] Developers can write the following queries on a data model such as (a) in Fig. 4.

[0082] [Query 8]

[0083] flight booking request = ( for $x in flight booking request of $x.for.oneway-journey isNotNull where $x.return date isNull return $x)

[0084] The above example can be covered by the following pattern.

[0085] entity= for $x in entity of {path} is notNull where {property} is null return $x

[0086] In the pattern above, {path} can be expressed as $xr[1].r[2]…, where r[i] represents a relationship and e is the terminal entity of path. {property} is expressed as $xp and p is the property. The natural language generated from this pattern is e 'an entity that r[1] and r[]2] and… r[k] must not specify p'.

[0087] If we match the patterns in the example, we can see that since e is oneway-journey, r[1] is 'for' and p is 'return-date', the natural language generated is 'a flight booking request for oneway journey should not specify a return date'.

[0088] As an example of another pattern, entity = 'for $x in entity of {path1} is notNull where {path2} is not null return $x'. Here, {path1} is $x.r1[1].r1[2]… and {path2} is $x.r2[1].r2[2]…. This can generate the following natural language.

[0089] An entity that r[1] and r[2] e1 must r2[1] and r2[2] e2.

[0090] In a data model like Figure 4 (b), the developer can write the following.

[0091] [Query 9]

[0092] for $x in passengers of $x.boarding.flight is notNull where $x.Pass.ScreenScreening is notNull return $x

[0093] By applying the natural language generation pattern of the example above to the curriculum, the natural language "Passengers on board the flight must pass screen screening" can be generated.

[0094] For example, other embodiments,

[0095] [Query 10]

[0096] entity = ( for $x in entity let a[1] = path[1], … a[k] = path[k] where expression(a[1], a[2]. … return $x)

[0097] Here, path[i] is as follows: path[i] = $xr[i][1].r[i][2]…

[0098] Natural language generation is as follows.

[0099] Let r[1, 1], r1, [2], and … of entity be (a[1]), … r[k, 1], r[k, 2], and … p[k] be a[k], and this is a natural language expression. Natural language expression functions can convert queries into natural language.

[0100] [Query 11]

[0101] flight booking request = for $x in flight booking request let a = $x.departure-date, b=$x.booking-date where b < a return $x

[0102] The converted natural language is as follows: 'If the departure date of a flight booking request is (a) and the booking date is (b), then a must be greater than b.'

[0103] Figure 5 is a block diagram of a parse tree of an embodiment.

[0104] When a developer writes and inputs `folwr` into a device, the processor parses it. A matching algorithm then searches the resulting parse tree within a pattern repository to find matching patterns, and generates and outputs natural language from these patterns. Parsing was performed using xtext to input bnf (backus-naur form) rules. xtext can receive this input and provide an editor with autocomplete capabilities. Flex and bison can be used for natural language generation.

[0105] In addition, the embodiment can generate standardized business logic using a scratch template mediated by queries and object CRUD (create, read, update, delete).

[0106] That is, the processor included in the business logic formalization device can be configured to store or create at least one scratch template corresponding to the business logic in advance, create formalized business logic by inputting parameters of the scratch template using queries and object CRUD, generate the formalized business logic as Java code, and register it as a service.

[0107] Therefore, the embodiment can represent the data model by simplifying it into a graph, and the query of the embodiment can provide a simplified query based on the graph.

[0108] FIGS. 6(a) and FIGS. 6(b) are conceptual diagrams illustrating the problem of simple matching in the embodiment.

[0109] Developers can simply consider the idea of ​​matching nouns to entities and attributes, and verbs to relationships when writing requirements analysis in Korean. Developers can detect nouns and verbs when writing in Korean and request matching. For example, as shown in Fig. 6 (a), in the Korean sentence of business logic '{Student} must {complete} {Prerequisite} courses', prerequisite courses can be matched to the dictionary's {Prerequisite}, student to the dictionary's (student), and completion to {Completion}.

[0110] As a similar example, the developer can modify the prerequisite courses into the relationship between courses as shown in Fig. 6 (b).

[0111] However, the business logic '{Student} must {complete} {Prerequisite}' in the example implementation does not match. This is because {Prerequisite} cannot be matched. To address this, {Prerequisite} can be expressed using the follow query language. The query is as follows.

[0112] Student ($x) must complete the prerequisite course {for $x in Student return $x.Completion.Course.Prerequisite.Course} {}.

[0113] The method described above can be relatively easy to write. However, let's consider another example: 'The percentage of grades with a B+ or higher in {Subject} must not exceed 50%.' Since only {Subject} is matched, it is impossible to analyze requirements at the algorithm level. In other words, it can be seen that a meaningful requirements analysis at the algorithm level cannot be performed using the simple matching method.

[0114] FIG. 7 is a flowchart of a business logic formalization method according to another embodiment.

[0116] action and function

[0117] Actions and functions, along with business logic, are deliverables of requirements analysis. Unlike business logic, they cannot be expressed as queries. A scenario refers to a group of action and function patterns frequently encountered during development. These scenarios are provided to developers as templates, allowing them to select and edit the scenarios they desire. Developers receive templates containing markers and must create correspondences by writing `follow` for each marker. The dictionary must support this query to ensure it becomes a valid query. For example, the `copyFrom` scenario is as follows.

[0118] The copyFrom template is as follows: It creates <Object 2> by receiving data from <Object 1>. It creates the corresponding <Object 2> using a portion of <Object 1> as a copy candidate. At this time, <Property 1> of <Object 1> is passed as <Property 2> of <Object 2>.

[0119] Accordingly, the developer must create a data dictionary or follow query for <Object 1>, <Object 2>, <Property 1>, and <Property 2>, respectively, to establish a correspondence. In the embodiment, <Object 1> is for $x in estimate return $x), <Object 2> is an order ( for $x in order return $x) <Attribute1> is the quantity of the estimate ( for $x in estimate return $x.sale.product.quantity) <attribute2> is the order quantity ( for $x in order return $x.sales.product.quantity) is.

[0120] Table 1 shows a list of scenarios.

[0121] copyTo action Values ​​are passed from <Object 1> to create <Object 2>. copyFrom action <Object 2> is created by retrieving values ​​from <Object 1>. BOM function It supports the Bill of Material function. MRP function Material Requirements Planning. reservation action Orders and productions reserve inventory. Cost calculation function There are FIFOP, LIFO, average, etc. Matching action Match the transfer transaction to the invoice transaction. inventory action Explains inventory-related functions. (initial quantity, inventory tracking, stock posting, goods receipt from production) accounting action Explains functions related to accounting. (posting) Return action This explains the functions related to returns. Open items function It is <Object1> for which no value was passed in copyTo and copyFrom. Resource allocation action Allocate resources to a process Work plan processing action Manages work schedules. Serial number management action

[0122] Actions and functions may not be scenarios. In this case, the developer must write actions and functions using 'simple matching with queries'. Furthermore, to ensure that the number of simple matches is not excessive, senior developers need to verify and approve whether the actions and functions are detailed at the algorithm level. This process can be represented by a flowchart as shown in Fig. 7.

[0123] FIGS. 8(a) to 8(d) and FIGS. 9(a) to 9(e) illustrate examples of a business logic formalization method that is automatically completed according to an embodiment. FIG. 10 illustrates the data models of FIGS. 8(a) to 8(d) and FIGS. 9(a) to 9(e).

[0124] FIGS. 8(a) to FIGS. 8(d) and FIGS. 9(a) to FIGS. 9(e) are examples of implementations of autocomplete natural language for the statement 'For all flight reservation requests, the flight request reservation is a one-way reservation, and a one-way reservation must not specify a return date.' The data model in FIG. 10 represents the structure of the target data.

[0125] The business logic formalization method according to the various embodiments described above is based on a simple graph model and does not require knowledge of relational data models. In addition, the embodiments support user-friendly paths instead of joins, and do not require cardinality to be specified, thereby reducing the complexity of the programming language. Furthermore, the embodiments are easier to write and understand than SQL, and do not require the concepts of primary keys and foreign keys. Additionally, the data dictionary of the embodiments has the advantage of not requiring table-shaped objects compared to ERDs and having no restrictions on objects.

[0126] In addition, the embodiment is suitable for the analysis phase of analyzing customer requirements, and can generate data based on a graph model using an easy program such as Scratch.

[0127] FIG. 11 is a block diagram of a business logic formalization device according to one embodiment. FIG. 11 is a reconstruction of the business logic formalization method of FIG. 1 from a hardware perspective.

[0128] Referring to FIG. 11, the business logic formalization device of the embodiment may include an interface unit (1110), a processor (1120), and a memory (1130).

[0129] The interface unit (1110) can receive natural language-based business logic representing customer requirements and transmit it to the processor (1120). Additionally, the interface unit (1110) can present natural language-based business logic and receive approval from a developer or user.

[0130] The processor (1110) may be configured such that a business logic formalizing device obtains natural language-based business logic representing customer requirements, the business logic formalizing device extracts a graph-based data dictionary representing entities or relations from the business logic, and the business logic formalizing device generates a graph-based query that represents the entities or relations nested from the business logic based on the data dictionary.

[0131] Embodiments according to the present specification may be implemented by various means, e.g., hardware, firmware, software, or a combination thereof. In the case of implementation by hardware, an embodiment of the present specification may be implemented by one or more ASICs (application specific integrated circuits), DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), a processor (1120), a controller, a microcontroller, a microprocessor, etc. In the case of implementation by firmware or software, an embodiment of the present specification may be implemented in the form of a module, procedure, function, etc., that performs the capabilities or operations described above. Software code may be stored in memory (1130) and executed by the processor (1120). The memory (1130) may be located inside or outside the processor (1120) and may exchange data with the processor (1120) by various means already known.

[0132] Meanwhile, the embodiments of this specification may be implemented as computer-readable code on a computer-readable recording medium. A computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. Additionally, the computer-readable recording medium may be distributed across networked computer systems, so that computer-readable code can be stored and executed in a distributed manner. Furthermore, functional programs, code, and code segments for implementing the embodiments can be easily inferred by programmers in the art to which this specification belongs.

[0133] The foregoing description of this specification is for illustrative purposes only, and those skilled in the art will understand that other specific forms can be easily modified without altering the technical spirit or essential features of this specification. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive.

[0134] The scope of this specification is defined by the claims set forth below rather than by the detailed description above, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts thereof should be interpreted as being included within the scope of this specification.

Claims

Claim 1 A business logic formalization method comprising: a step in which a business logic formalization device obtains natural language-based business logic representing a customer's requirements; a step in which the business logic formalization device extracts a graph-based data dictionary representing an entity or relation from the business logic; a step in which the business logic formalization device generates a graph-based query representing the entity or relation in a nested manner based on the data dictionary from the business logic; and a step in which the business logic formalization device generates formalized natural language-based business logic from the query, wherein the step of generating formalized natural language-based business logic generates the formalized natural language-based business logic by matching natural language patterns from the query using a parsing tree, and if the business logic formalization device does not accept the generated formalized natural language-based business logic, returns to the step of extracting the data dictionary. Claim 2 A method for formalizing business logic according to claim 1, wherein the query is defined using a reserved word including: For, which binds a variable to an object; Of, which constrains the object; Let, which specifies a path to the variable; Where, which filters the object; and Return, which returns processed code. Claim 3 A method for standardizing business logic according to paragraph 2, wherein the query further includes at least one reserved word among Group by, which groups objects with the same specified attribute value and outputs the result of applying an aggregate function to each group; and Having, which applies a constraint consisting of an aggregate function. Claim 4 delete Claim 5 delete Claim 6 delete Claim 7 A business logic standardization method according to claim 1, wherein the business logic standardization device returns to the step of extracting the data dictionary, re-extracts the data dictionary, and if the query in the re-extracted data dictionary is invalid, outputs the invalid query by underlining it. Claim 8 A method for standardizing business logic according to claim 1, further comprising: a step in which the business logic standardizing device stores or creates at least one scratch template corresponding to the business logic in advance; a step in which the business logic standardizing device creates standardized business logic by inputting parameters of the scratch template using the query and object CRUD (create, read, update, delete); and a step in which the business logic standardizing device generates the standardized business logic into Java code and registers it as a service. Claim 9 In one or more non-transitory computer-readable media storing one or more instructions, said one or more instructions executable by one or more processors process operations using a graph convolutional network (GCN), wherein a business logic formalizing device acquires natural language-based business logic representing customer requirements, said business logic formalizing device extracts a graph-based data dictionary representing entities or relations from said business logic, said business logic formalizing device generates a graph-based query representing the entities or relations nested from said business logic based on said data dictionary, said business logic formalizing device generates formalized natural language-based business logic from said query, said formalized natural language-based business logic by matching natural language patterns from said query using a parsing tree, and said business logic formalizing device generates said formalized natural language A computer-readable medium that reverts to the process of extracting the above data dictionary if the business logic based on it is not approved. Claim 10 A business logic formalizing device comprising: a memory configured to store a plurality of instructions; an interface unit for acquiring natural language-based business logic representing customer requirements; and a processor functionally coupled with the memory, wherein when the plurality of instructions are executed, the processor is configured such that a business logic formalizing device acquires natural language-based business logic representing customer requirements, the business logic formalizing device extracts a graph-based data dictionary representing entities or relations from the business logic, the business logic formalizing device generates a graph-based query that expresses the entities or relations in a nested manner based on the data dictionary from the business logic, the business logic formalizing device generates formalized natural language-based business logic from the query, wherein the business logic formalizing device generates the formalized natural language-based business logic by matching natural language patterns from the query using a parsing tree, and if the business logic formalizing device does not accept the generated formalized natural language-based business logic, the device is configured to return to the process of extracting the data dictionary.

Images