Microservice design support system, microservice design support method and program

Abstract

To realize design support without personal attributes in microservices design.SOLUTION: A microservices design support system is provided with a use case input unit 12 for inputting a use case related to a user's business process as textual information; a ubiquitous language generation unit 13 for generating a ubiquitous language related to a constituent element included in the textual information of the use case inputted to the use case input unit and a subdomain information output unit 14 for grouping use cases including matching or similar elements based on the ubiquitous language and the use case, further subgrouping the textual information of the grouped use cases based on whether the textual information is similar in the business process, and generating subdomain information.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a microservice design support system, a microservice design support method, and a program. [Background technology]

[0002] A technology has been disclosed for allocating the necessary resources to each microservice into which a monolithic system is divided when migrating the system to a new microservice-based system (see Patent Document 1).

[0003] Meanwhile, in order to improve business efficiency and productivity in companies, there is a demand to identify business processes that particularly contribute to business efficiency, and to turn the identified parts into microservices to enable flexible and rapid continuation of development. For example, in recent years, existing monolithic applications have been migrated to microservices based on the concept of domain-driven design. Domain-driven design is a design concept that models business processes based on information about a company's business domain. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2022-168796 Summary of the Invention [Problem to be solved by the invention]

[0005] Incidentally, in order to convert part of a business process into a microservice in order to improve business efficiency and productivity, it is necessary to identify the business processes that will particularly contribute to business efficiency, etc. However, if the customer's business processes are complex or the customer himself does not know which business processes should be converted into microservices in order to improve business efficiency, it is not easy to identify the business processes that should be converted into microservices.

[0006] In addition, business process reorganization is generally carried out by customers who are familiar with the business or experienced engineers, and it takes a lot of time. Therefore, in order to realize microservices in a short time, it is necessary to speed up the process of reorganizing business processes and the process of identifying the target business processes.

[0007] Given the above situation, there was a demand for a method to provide design support for microservices that was independent of individual expertise. [Means for solving the problem]

[0008] In order to solve the above problems, one aspect of the present invention provides a microservice design support system that supports the determination of areas in a user's business process to be turned into microservices, and includes a use case input unit, a ubiquitous language generation unit, and a subdomain information output unit. The use case input unit receives use cases related to the user's business process as text information. The ubiquitous language generation unit generates ubiquitous language related to components included in the text information of the use cases input to the use case input unit. The subdomain information output unit groups use cases that include matching or similar elements based on the ubiquitous language and the use cases, and further subgroups the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information. [Effects of the Invention]

[0009] According to at least one aspect of the present invention, it is possible to provide design support for microservices that is free from dependency on individual users. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1]FIG. 1 is a diagram illustrating an overview of a microservice design support system according to an embodiment of the present invention and a conventional technology. [Figure 2] FIG. 1 is a block diagram illustrating an example of a functional configuration of a microservice design support system according to an embodiment of the present invention. [Figure 3] 10 is a flowchart illustrating an example of a procedure for a ubiquitous language generation process according to an embodiment of the present invention. [Figure 4] 10 is a flowchart illustrating an example of a procedure for a subdomain information generation process according to an embodiment of the present invention. [Figure 5] 10 is a flowchart illustrating an example of a procedure for a subdomain classification process according to an embodiment of the present invention. [Figure 6] FIG. 1 is a diagram illustrating a specific example of classification of use case descriptions according to an embodiment of the present invention. [Figure 7] 10 is a flowchart illustrating an example of a procedure for past design information analysis processing according to an embodiment of the present invention. [Figure 8] 10 is a flowchart illustrating an example of a procedure for calculating a similarity between previous design information according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of a procedure for a context information output process according to an embodiment of the present invention. [Figure 10] 10 is a flowchart illustrating an example of a procedure for a microservice information output process according to an embodiment of the present invention. [Figure 11] FIG. 2 is a diagram illustrating an example of a database of past design information according to an embodiment of the present invention. [Figure 12] FIG. 2 is a diagram illustrating an example of a database of subdomain information according to an embodiment of the present invention. [Figure 13] FIG. 2 illustrates an example database of context information according to an embodiment of the present invention. [Figure 14] FIG. 1 illustrates an example of a database of microservice information according to an embodiment of the present invention. [Figure 15] FIG. 10 is a diagram showing an example of a display of a use case description input according to an embodiment of the present invention. [Figure 16] FIG. 10 is a diagram showing an example of a display of a ubiquitous language according to an embodiment of the present invention. [Figure 17] FIG. 10 is a diagram showing an example of display of subdomain information according to an embodiment of the present invention. [Figure 18] FIG. 10 is a diagram showing an example of a display for editing subdomain information according to an embodiment of the present invention. [Figure 19] FIG. 10 is a diagram showing an example of display of attribute information of subdomain information according to an embodiment of the present invention. [Figure 20] FIG. 10 is a diagram illustrating an example of a display of context information according to an embodiment of the present invention. [Figure 21] FIG. 10 is a diagram illustrating a display example of a context map according to an embodiment of the present invention. [Figure 22] FIG. 10 is a diagram illustrating an example of a display of microservice information according to an embodiment of the present invention. [Figure 23] FIG. 1 is a diagram illustrating an example of a hardware configuration of a microservice design support system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, examples of modes for carrying out the present invention (hereinafter referred to as "embodiments") will be described with reference to the accompanying drawings. In this specification and the accompanying drawings, identical components or components having substantially the same functions are designated by the same reference numerals, and redundant explanations will be omitted.

[0012] [Outline of the microservice design support system of this embodiment and conventional technology] First, an overview of a microservice design support system according to an embodiment of the present invention and the prior art will be described with reference to FIG.

[0013] Figure 1 is a diagram showing an overview of a microservice design support system according to one embodiment of the present invention and a conventional technology. In Figure 1, the upper part shows the conventional technology, and the lower part shows an overview of the microservice design support system according to this embodiment.

[0014] The conventional technology in the upper row shows a case where business system 1 is divided into microservices on a functional basis. Because the division focuses on the functions of business system 1 (functions A to C), it is possible that a function (function B) used by multiple businesses (business a, business b) may be extracted. This is an undesirable design that depends on multiple businesses.

[0015] The microservice design support system according to this embodiment, shown in the lower part, divides the system into subdomains and context boundaries based on use cases. A use case describes what operations and responses should (or should not) be performed starting from a specific state when a user or other entity uses a business system to use some function or achieve a goal.

[0016] In this embodiment, by aggregating related use cases and designing subdomains and context boundaries, it is possible to design functions (functions B1 and B2) related to each business (business a and b) while maintaining their independence. Also, as will be described later, by also presenting subdomain candidates based on past design information (see past design information 22 in FIG. 11), it is possible to provide multiple materials for the user (designer) to consider.

[0017] [Functional configuration of the microservice design support system] Next, the functional configuration of the microservice design support system according to this embodiment will be described with reference to FIG. FIG. 2 is a block diagram showing an example of the functional configuration of a microservice design support system according to this embodiment.

[0018] The microservice design support system 10 includes a user interface unit 11, a use case input unit 12, a ubiquitous language generation unit 13, a subdomain information output unit 14, a context information output unit 15, and a microservice information output unit 16. The microservice design support system 10 also stores use case description information 17, industry terminology 18, ubiquitous language 19, organization information 20, business information 21, past design information 22, subdomain information 23, context information 24, and microservice information 25. These various pieces of information are stored in the form of a database, a table, or the like in a storage device 233 shown in FIG. 23, which will be described later.

[0019] The user interface unit 11 presents to the user, by means of screen display or the like, items prompting the user to input, items prompting the user to confirm, items prompting the user to edit, and the like at each step of microservice design. Specifically, the user interface unit 11 displays various screens for inputting use cases, checking and editing ubiquitous language, inputting organizational information and business information, checking and editing subdomain information, checking and editing context information, and checking microservice information. The user interface unit 11 is realized using a display device 236 and an input device 235 in FIG. 23 , which will be described later.

[0020] The use case input unit 12 receives text information (use case description) of a use case related to a business from the user (user interface unit 11 ) and stores it in use case description information 17 .

[0021] The ubiquitous language generation unit 13 generates a list of ubiquitous language candidates by morphologically analyzing the use case descriptions in the use case description information 17 with reference to industry terminology 18. Then, the ubiquitous language generation unit 13 presents the list of ubiquitous language candidates to the user via the user interface unit 11, accepts confirmation and editing operations of the ubiquitous language candidates by the user, determines the ubiquitous language, and stores it in the ubiquitous language 19.

[0022] The subdomain information output unit 14 generates subdomain candidate information by analyzing the analysis result (ubiquitous language 19) of the use case description information 17 by the ubiquitous language generation unit 13, organization information 20, business information 21, and past design information 22. Then, the subdomain information output unit 14 presents the subdomain candidate information to the user via the user interface unit 11, accepts confirmation and editing operations of the subdomain candidate information by the user, confirms the subdomain information, and stores it in the subdomain information 23.

[0023] The context information output unit 15 generates context candidate information by analyzing the subdomain information 23. Then, the context information output unit 15 presents the context candidate information to the user via the user interface unit 11, accepts confirmation and editing operations of the context candidate information by the user, finalizes the context information, and stores it in the context information 24.

[0024] The microservice information output unit 16 generates microservice candidate information by analyzing the context information 24. Then, the microservice information output unit 16 presents the microservice candidate information to the user via the user interface unit 11, accepts confirmation and editing operations of the microservice candidate information by the user, finalizes the microservice information, and stores it in the microservice information 25.

[0025] Completion notifications are sent between the use case input unit 12, the ubiquitous language generation unit 13, the subdomain information output unit 14, the context information output unit 15, and the microservice information output unit 16 when processing by each processing block is completed.

[0026] [Ubiquitous Language Generation Processing] Next, the ubiquitous language generation process in the microservice design support system 10 will be described with reference to FIG. 3 is a flowchart showing an example of the procedure for the ubiquitous language generation process, which is executed by the ubiquitous language generation unit 13.

[0027] In step S301, the ubiquitous language generation unit 13 acquires the use case description input by the user from the use case description information 17.

[0028] Next, in step S302, the ubiquitous language generation unit 13 acquires industry terms 18 that correspond to the industry to be analyzed. The industry to be analyzed may be specified by receiving an input from the user via the user interface unit 11, or the microservice design support system 10 may present a plurality of industry candidates to the user and allow the user to select one.

[0029] Next, in step S303, the ubiquitous language generation unit 13 executes loop processing on the acquired use case description.

[0030] In step S304, the ubiquitous language generation unit 13 performs morphological analysis on the use case description, and classifies the use case description, that is, the components of the sentence, into subjects, predicates, objects, and other components.

[0031] Next, in step S305, the ubiquitous language generation unit 13 checks whether the industry terminology 18 acquired in step S302 contains the same information as that contained in the classified sentence component. The information contained in the classified sentence component is the specific content of the parts of speech, such as nouns and verbs, contained in the component (an example of an element of a use case description). If a part of speech with the same content is contained in the industry terminology 18, that part of speech is assigned a higher priority than other parts of speech that are not included in the industry terminology 18. The priority may be designated by a character string such as "high" or a number such as "1." In this example, since the target part of speech is either included in the industry terminology 18 or not, the priority is either high or low (1 or 0). Note that if the priorities of parts of speech are the same, the order of those parts of speech is determined based on a preset rule (for example, alphabetical order).

[0032] Then, in step S306, the ubiquitous language generation unit 13 checks whether the execution of the loop processing has been completed for all use case descriptions. If the ubiquitous language generation unit 13 determines that the loop processing has not been completed, it returns to step S303 and continues the processing, and if it determines that the loop processing has been completed, it proceeds to step S307.

[0033] In step S307, the ubiquitous language generation unit 13 performs a synonym analysis on the above-mentioned parts of speech. Existing technologies and dictionaries can be used for the synonym analysis, such as WordNet or Word2Vec. The ubiquitous language generation unit 13 uses the results of the synonym analysis to create synonym groups for each part of speech. At this time, rules can be determined and stored in advance to determine the level of similarity required to determine synonyms. For example, a threshold value for similarity can be defined in advance, and groups can be created for each part of speech that has a similarity equal to or greater than the threshold value.

[0034] Next, in step S308, the ubiquitous language generation unit 13 generates ubiquitous language candidates based on the analyzed parts of speech and the synonym groups of those parts of speech. At this time, the ubiquitous language generation unit 13 sorts the parts of speech in descending order of priority according to the priority specified in step S305. In the case of synonym groups, a group that includes many high-priority parts of speech may be sorted before other synonym groups.

[0035] Next, in step S309, the ubiquitous language generation unit 13 presents the ubiquitous language candidates generated in step S308 to the user via the user interface unit 11. The user selects which of the ubiquitous language candidates to confirm as the ubiquitous language via the user interface unit 11 (see FIG. 16 described later). Furthermore, the user may edit the ubiquitous language or edit by combining synonymous word groups into one part of speech via the user interface unit 11. The ubiquitous language generation unit 13 accepts the selection and editing operation of the ubiquitous language candidate by the user via the user interface unit 11.

[0036] Next, in step S310, the ubiquitous language generation unit 13 stores the results of the selection of the ubiquitous language candidate and the editing operation received in step S309 in the ubiquitous language 19. When the processing of this step ends, the ubiquitous language generation processing ends.

[0037] [Subdomain information generation process] Next, the subdomain information generation process in the microservice design support system 10 will be described with reference to FIG. 4 is a flowchart showing an example of the procedure for the subdomain information generation process, which is executed by the subdomain information output unit 14.

[0038] In step S401, the subdomain information output unit 14 acquires the target use case description from the use case description information 17.

[0039] Next, in step S402, the subdomain information output unit 14 executes subdomain classification processing by analyzing the use case description. Details of the subdomain classification processing will be described with reference to the flowchart in FIG.

[0040] Next, in step S403, the subdomain information output unit 14 generates subdomain candidate information by analyzing past design information 22 (see FIG. 11, which will be described later). The past design information 22 is information about microservice designs for other companies, other business divisions, etc., that have been carried out by the designer or design company in the past. Details of the past design information analysis process will be described using the flowchart in FIG. 7.

[0041] Next, in step S404, the subdomain information output unit 14 generates subdomain candidate information based on the analysis results of steps S402 and S403.

[0042] Next, in step S405, the subdomain information output unit 14 presents the subdomain candidate information to the user via the user interface unit 11. The user selects and edits the subdomain candidate information via the user interface unit 11 (see FIGS. 17 to 19, which will be described later). The subdomain information output unit 14 accepts the user's selection and editing of the subdomain candidate information via the user interface unit 11.

[0043] Next, in step S406, the subdomain information output unit 14 stores the results of the selection and editing of the subdomain candidate information received in step S405 in the subdomain information 23. When the processing of this step is completed, the subdomain information generation processing is completed.

[0044] [Subdomain classification processing] Next, the subdomain classification process (subroutine of S402) in the microservice design support system 10 will be described with reference to FIG. FIG. 5 is a flowchart showing an example of the procedure of the subdomain classification process performed by the subdomain information output unit 14.

[0045] In step S501, the subdomain information output unit 14 extracts subjects by morphologically analyzing the use case descriptions acquired in step S401, and groups the use case descriptions by subject.

[0046] Next, in step S502, the subdomain information output unit 14 executes loop processing (S503 to S507) on the grouped use case descriptions.

[0047] In step S503, the subdomain information output unit 14 extracts pairs of an object and a predicate from the use case description.

[0048] Next, in step S504, the subdomain information output unit 14 performs a synonym analysis on the extracted predicate to obtain a list of synonyms of the predicate.

[0049] Next, in step S505, the subdomain information output unit 14 performs a synonym analysis of the object within the same group of use case descriptions to acquire synonyms of the object.The subdomain information output unit 14 then acquires use case descriptions from the same group that match the object or a synonym of the object in the use case description to be processed (i.e., the use case description from which the object-predicate pair has been extracted).Furthermore, the subdomain information output unit 14 performs a synonym analysis of the predicate in the acquired use case description to acquire synonyms of the predicate, and acquires use case descriptions that match the predicate in the use case description to be processed or that match its synonym.

[0050] The subdomain information output unit 14 acquires the semantic distances between the objects of the use case descriptions and the semantic distances between the predicates of the use case descriptions by synonym analysis, and records the average value of these as the similarity. If the subdomain information output unit 14 determines that a corresponding use case description exists as a result of the analysis process (YES determination in S505), the process proceeds to step S506. A corresponding use case description is a use case description in which both the object and the predicate satisfy the above condition (match themselves or a synonym). On the other hand, if the subdomain information output unit 14 determines that a corresponding use case description does not exist (NO determination in S505), the process proceeds to step S507.

[0051] In step S506, the subdomain information output unit 14 classifies the use case description (sentence unit) acquired in step S505 into the same subdomain as the use case description to be processed. The name of the subdomain may be a character string combining the object and predicate of the use case description to be processed, or a character string numbered in the order in which the groups are generated, such as "Group 1."

[0052] In step S507, the subdomain information output unit 14 classifies the use case description to be processed into a new subdomain. The name of the subdomain may be a character string that combines the object and predicate of the use case description to be processed, or a character string that numbers the groups in the order in which they are generated, such as "Group 1."

[0053] Then, in step S508, the subdomain information output unit 14 checks whether there are any use case descriptions among the grouped use case descriptions that have not yet been classified into a subdomain. If there are any unclassified use case descriptions remaining, the subdomain information output unit 14 returns to step S502 and continues the loop processing. On the other hand, if there are no unclassified use case descriptions remaining, the subdomain information output unit 14 ends the loop processing. When the processing of this step ends, the subdomain classification processing ends, and the process proceeds to step S403.

[0054] [Examples of classification of use case description information] Here, the classification of use case descriptions according to this embodiment will be described with a specific example with reference to FIG. FIG. 6 is a diagram showing a specific example of classification of use case descriptions.

[0055] Consider the case where use case descriptions (a) to (f) are input as use case description information 17. Use case description (a) is "The policyholder can view the insurance product," use case description (b) is "The policyholder can refer to the insurance information," and use case description (c) is "The policyholder can check the progress of the contract." Furthermore, use case description (d) is "The agent can check the progress of the contract," use case description (e) is "The insurance agent can view the insurance product," and use case description (f) is "The policyholder can check the contract details."

[0056] In FIG. 6(1), morphological analysis is performed on the use case descriptions (a) to (f) to extract subjects and combinations of predicates and objects (corresponding to S501 to S503).

[0057] In Figure 6 (2), use case descriptions with the same subject are classified, and use case descriptions with similar nouns in the subject are grouped by synonym analysis (corresponding to S501). As a result, use case descriptions (a) to (c), and (f) are classified into group G1, and use case descriptions (d) and (e) are classified into group G2.

[0058] In Figure 6 (3), if there are use case descriptions with similar objects and synonymous predicates, they are classified into the same subdomain group (corresponding to S505 and S506).If no use case description that meets these conditions is found, a new subdomain group is created (corresponding to S505 and S507).

[0059] As a result, group G1 is divided into group G11 containing use case descriptions (a) and (b) and group G12 containing use case descriptions (c) and (f). Group G2 is also divided into group G21 containing use case description (d) and group G22 containing use case description (e).

[0060] Then, as will be described later, the classification results of the use case descriptions are subjected to an analysis process using past design information in step S403, thereby creating subdomain candidate information.

[0061] [Past design information analysis processing] Next, the past design information analysis process (subroutine of S403) in the microservice design support system 10 will be described with reference to FIG. FIG. 7 is a flowchart showing an example of the procedure of the past design information analysis process performed by the subdomain information output unit 14.

[0062] In step S701, the subdomain information output unit 14 acquires the previous design information 22 (see FIG. 11).

[0063] Next, in step S702, the subdomain information output unit 14 calculates the similarity between the information currently being processed and the previous design information 22. Details of the similarity calculation process will be described with reference to the flowchart in Fig. 8. The information currently being processed is the ubiquitous language, industry / business type information, and organization information acquired in steps S801 to S803 in Fig. 8, which will be described later.

[0064] Next, in step S703, the subdomain information output unit 14 checks whether the similarity calculated in step S702 is equal to or greater than a threshold. If the subdomain information output unit 14 determines that the similarity is equal to or greater than the threshold (YES determination in S703), the process proceeds to step S704, and if the subdomain information output unit 14 determines that the similarity is less than the threshold (NO determination in S703), the process ends the past design information analysis process.

[0065] Here, the threshold value may be defined in advance in the microservice design support system 10. Alternatively, the user may specify the threshold value via the user interface unit 11 when executing the past design information analysis process. Furthermore, the microservice design support system 10 may hold only one threshold value, or may hold multiple threshold values. When multiple threshold values ​​are held, it is possible to generate multiple processing results by determining whether the similarity is equal to or greater than each threshold value, and proceeding to step S704 only for past design information having a similarity equal to or greater than the threshold value.

[0066] In step S704, the subdomain information output unit 14 acquires the subdomain information 113 of the past design information 22 (plural pieces of past design information) having a similarity equal to or greater than a threshold value.

[0067] Next, in step S705, the subdomain information output unit 14 acquires a use case description included in the corresponding subdomain information 113 of the past design information 22, classifies the components of the sentence into subjects, predicates, and objects by morphological analysis, and acquires synonyms of the parts of speech included in each component by thesaurus analysis. The subdomain information output unit 14 also acquires a use case description included in each subdomain of the subdomain candidate information currently being processed, classifies the components into subjects, predicates, and objects by morphological analysis, and acquires synonyms of each part of speech by thesaurus analysis.

[0068] Then, the subdomain information output unit 14 checks whether each part of speech of the use case description in the past design information 22 matches with that in the subdomain candidate information currently being processed, or whether their synonyms match. If each part of speech or synonyms of the comparison targets match, the subdomain information output unit 14 generates information in which the corresponding use case description is assigned to each subdomain in the past design information 22 as new subdomain candidate information. When the processing of this step is completed, the past design information analysis processing is completed, and the process proceeds to step S404.

[0069] [Similarity calculation process for past design information] Next, the similarity calculation process (subroutine of S702) for the past design information in the microservice design support system 10 will be described with reference to FIG. FIG. 8 is a flowchart showing an example of a procedure for calculating the similarity of previous design information by the subdomain information output unit 14. In FIG.

[0070] In step S801, the subdomain information output unit 14 acquires the ubiquitous language of the subdomain candidate information currently being processed.

[0071] Next, in step S802, the subdomain information output unit 14 acquires industry and business type information of the subdomain candidate information currently being processed. The industry and business type information may be stored in a configuration file (not shown) and may be specified by the microservice design support system 10 when the microservice design support system 10 is executed. Alternatively, the user may specify the industry and business type information (for example, life insurance) via the user interface unit 11.

[0072] Next, in step S803, the subdomain information output unit 14 acquires organizational information related to the currently processed subdomain candidate information. As with the industry / business type information, the organizational information may be specified when the microservice design support system 10 is executed, or may be specified by the user via the user interface unit 11.

[0073] Next, in step S804, the subdomain information output unit 14 executes a loop process on each piece of information from steps S801, S802, and S803.

[0074] In step S805, the subdomain information output unit 14 calculates the similarity between each piece of information and the previous design information 22. That is, the subdomain information output unit 14 acquires the ubiquitous language, industry / business type information, and organization information of the previous design information 22 corresponding to the subdomain, and calculates the degree of match (match rate) with each piece of information in steps S801, S802, and S803.

[0075] For example, the degree of match of ubiquitous language may be calculated as the similarity based on what percentage of all previous design information matches. The degree of match of industry / business type information may be calculated by determining whether the same industry / business type information exists in the previous design information, scoring it as 1 if it does, or 0 if it does not. The degree of match of organizational information may be calculated as the similarity based on what percentage of all previous design information matches, or the degree of match of organizational information may be calculated only if the industry / business type information matches. The total number of the degrees of match of each piece of information may be used as the similarity, or the average value of each piece of information may be used as the similarity.

[0076] Then, in step S806, the subdomain information output unit 14 checks whether there is any information among the above pieces of information for which the degree of coincidence with the previous design information 22 has not yet been calculated, and if there is any unprocessed information remaining, the process returns to step S804 to continue the loop process. When the process of this step is completed, the similarity calculation process for the previous design information is completed, and the process proceeds to step S703.

[0077] [Context information output processing] Next, the context information output process in the microservice design support system 10 will be described with reference to FIG. 9 is a flowchart illustrating an example of the procedure for the context information output process. The context information output process is executed by the context information output unit 15.

[0078] In step S901, the context information output unit 15 acquires the relevant subdomain information from the subdomain information 23.

[0079] Next, in step S902, the context information output unit 15 checks the attribute information of the subdomain information 23 and sorts the subdomain information in the order of the attribute information. The attribute information may also be sorted according to whether each subdomain belongs to a "core subdomain," a "general subdomain," or a "support subdomain."

[0080] Next, in step S903, the context information output unit 15 generates context candidate information based on the names of the subdomains in the subdomain information 23.

[0081] Next, in step S904, the context information output unit 15 presents the context candidate information to the user via the user interface unit 11 (see FIG. 20, which will be described later). The user can change the name of the context information or further integrate or divide the context information via the user interface unit 11. The context information output unit 15 accepts an editing operation by the user via the user interface unit 11 and updates the context information.

[0082] Next, in step S905, the context information output unit 15 accepts the user's operation of creating and editing the connection relationships between contexts (see Figure 21 described later) via the user interface unit 11, and generates the connection relationships between contexts as context map information.

[0083] Next, in step S906, the context information output unit 15 stores the generated context information and context map information in the context information 24. When the processing of this step ends, the context information output processing ends.

[0084] [Microservice information output processing] Next, the microservice information output process in the microservice design support system 10 will be described with reference to FIG. 10 is a flowchart illustrating an example of the procedure for the microservice information output process. The microservice information output process is executed by the microservice information output unit 16.

[0085] In step S1001, the microservice information output unit 16 acquires information on the corresponding context from the context information 24.

[0086] Next, in step S1002, the microservice information output unit 16 acquires attribute information of each context of the context information. The attribute information may be information indicating whether the subdomain corresponding to each context belongs to a "core subdomain," a "general subdomain," or a "support subdomain."

[0087] Next, in step S1003, the microservice information output unit 16 generates microservice candidate information by using the attribute information acquired in step S1002. As an example, when the attribute information of a context is a core subdomain (for example, "assessment" in FIG. 19 described later), the context may be generated as microservice candidate information.

[0088] Next, in step S1004, the microservice information output unit 16 presents the microservice candidate information to the user via the user interface unit 11. The microservice candidate information may be highlighted so that the relevant portion can be identified on a context map of the context information stored in the context information 24, or the relevant context may be indicated by a character string. The user can edit the microservice candidate information by adding or deleting it via the user interface unit 11. The microservice information output unit 16 accepts an editing operation for the microservice candidate information via the user interface unit 11 and updates the microservice candidate information.

[0089] Next, in step S1005, the microservice information output unit 16 stores the microservice candidate information as microservice information in the microservice information 25. When the processing of this step ends, the microservice information output processing ends.

[0090] [Past design information] Next, the contents of the past design information 22 will be described with reference to FIG. FIG. 11 is a diagram showing an example of the database of the past design information 22. As shown in FIG.

[0091] In the past design information 22, business type / industry information 111, organization information 112, subdomain information 113, context information 114, and microservice information 115 are set (stored) in association with each other.

[0092] The business type / industry information 111 may be set to a character string indicating the business type / industry to which this design information was applied, such as "life insurance," or may be set to a character string that serves as an identifier for an external business type / industry dictionary (for example, "001").

[0093] Organizational information 112 is information about customers who use the business process for which microservices are being considered, such as information indicating the company, department, team, etc. related to the use case description (e.g., name, alphanumeric identifier, etc.).

[0094] The subdomain information 113 includes one or more subdomains included in the design information, and each subdomain is stored in the format of the subdomain information 23 shown in FIG.

[0095] The context information 114 is set with one or more contexts included in the design information, and is stored in the format of the context information 24 shown in FIG.

[0096] The microservice information 115 is set with one or more pieces of microservice information included in the design information, and is stored in the format of the microservice information 25 shown in Fig. 14. In Fig. 11, a circle is displayed for the information (e.g., assessment) of the target context information 114, but a character string indicating the name of the context information 114 or the like may also be displayed.

[0097] For example, in FIG. 11, "Life Insurance" is set in the business type / industry information 111, and "Company A Sales Department" is set in the organization information 112. "Product Viewing", "Reception", and "Assessment" are set in the subdomain information 113. Similarly, "Product Viewing", "Reception", and "Assessment" are also set in the context information 114. Furthermore, in the microservice information 115, "Assessment" of the context information 114 is specified.

[0098] [Subdomain information] Next, the contents of the subdomain information 23 will be described with reference to FIG. FIG. 12 is a diagram showing an example of a database of the subdomain information 23. As shown in FIG.

[0099] In the subdomain information 23, a subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125 are set (stored) in association with each other.

[0100] Each subdomain 121 has one character string set to indicate that subdomain. Multiple subdomains are set for each business domain (target business range). Therefore, a subdomain is entered for each type of subdomain 121 in the subdomain information 23. It can also be considered that subdomain information 23 is created for each type of subdomain 121. Information in the subdomain information 23 is registered for each subdomain.

[0101] In the use case description 122, a use case description associated with information on the subdomain 121 is set by the analysis of the subdomain information output unit 14.

[0102] In the ubiquitous language 123, a ubiquitous language associated with information of the subdomain 121 is set by analysis by the ubiquitous language generation unit 13 and the subdomain information output unit 14.

[0103] The similarity 124 is set to the similarity between the information of the subdomain 121 (assessment in the example of FIG. 12) and the previous design information 22 calculated in the similarity calculation process (S702 in FIG. 7) of the subdomain information output unit 14.

[0104] The attribute information 125 contains attribute information set by the user to the related subdomain via the user interface unit 11. In this embodiment, "core subdomain," "general subdomain," and "support subdomain" are provided as subdomains (see FIG. 19 described later).

[0105] The "core subdomain" is the subdomain that forms the core of the business domain. The "general-purpose subdomain" is a general-purpose subdomain that can be used not only in the target industry but also in other industries. The "support subdomain" is a subdomain that supports the core subdomain.

[0106] For example, in Fig. 12, "assessment" is set in the subdomain 121, and "The insurance company reviews the documents," "The insurance company examines the health status," and "The insurance company examines the income status" are set in the use case description 122. "Documents," "inspection," and "examination" are set in the ubiquitous language 123. Furthermore, "0.80" is set in the similarity 124, and "core subdomain" is set in the attribute information 125. The information stored in Figs. 10 to 12 is accumulated within the scope of the business domain based on the use case description.

[0107] [Context Information] Next, the contents of the context information 24 will be described with reference to FIG. FIG. 13 is a diagram showing an example of a database of the context information 24. As shown in FIG.

[0108] In the context information 24, a context 131, a related subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125 are set (stored) in association with each other.

[0109] A single character string indicating the context is set in the context 131. The information in the context 131 is often the same as the information in the subdomain 121. In the subdomain 121, one or more character strings indicating the subdomain associated with the information of the context 131 are set by the context information output unit 15. In this example, the "assessment" of the subdomain 121 is associated with the "assessment" of the context 131. There is not necessarily one subdomain for one context, and there may be multiple subdomains. The use case description 122, the ubiquitous language 123, the similarity 124, and the attribute information 125 will not be described here.

[0110] [Microservices Information] Next, the contents of the microservice information 25 will be described with reference to FIG. FIG. 14 is a diagram illustrating an example of a database of the microservice information 25.

[0111] The microservice information 25 includes a microservice 141, a related context 131, a related subdomain 121, a related use case description 122, a related ubiquitous language 123, a similarity 124, and attribute information 125, which are set (stored) in association with each other.

[0112] A microservice 141 has one character string set to indicate the microservice. In the context 131, one character string indicating a context associated with the information of the microservice 141 by the microservice information output unit 16 is set. In the subdomain 121, one or more character strings indicating a subdomain associated with the information of the context 131 by the context information output unit 15 are set. The use case description 122, the ubiquitous language 123, the similarity 124, and the attribute information 125 will not be described here.

[0113] [Example of use case description input] Next, a display example of the use case description input will be described with reference to FIG. Fig. 15 is a diagram showing an example of a display on the user interface unit 11 for inputting a use case description. Fig. 15 shows an example of an interface screen 150 including an input field for a use case description.

[0114] The interface screen 150 has a "Use Case" button 151, a "Ubiquitous" button 152, a "Subdomain" button 153, a "Bounded Context" button 154, a "Context Map" button 155, an input field for use case description 156, an "OK" button, and a "Cancel" button.

[0115] When the "Use Case" button 151 is pressed, the user interface unit 11 displays an interface screen 150 for inputting a use case description as shown in FIG. When the "Ubiquitous" button 152 is pressed, the user interface unit 11 displays an interface screen 160 for checking and editing the ubiquitous language as shown in FIG. When the "Subdomain" button 153 is pressed, the user interface unit 11 displays an interface screen 170 for checking and editing subdomain information as shown in FIG. When the "bounded context" button 154 is pressed, the user interface unit 11 displays an interface screen 200 for checking and editing context information as shown in FIG. When the "Context Map" button 155 is pressed, the user interface unit 11 displays an interface screen 210 for creating a context map as shown in FIG.

[0116] The input field 156 has input fields for each category to help the user organize and input use case descriptions. Examples of categories (a) to (g) are shown in Fig. 15. An assist button "?" is displayed for each category to display an explanation of that category.

[0117] For example, category (a) is "Product / Customer Value." The use case description for category (a) is "Customers can view insurance products." Category (b) is "Price / Cost." The use case description for category (b) is "The insurance company (new contract) confirms the payment of the insurance premium." Category (c) is "Place / Convenience." The use case description for category (c) is "Customers access using a web browser." Category (d) is "Promotion / Communication." The use case description for category (d) is "Customers can receive recommendations for insurance products."

[0118] Category (e) is "Personnel." The use case description for category (e) is "Customers use this system." Category (f) is "Process." The use case description for category (f) is "The insurance company (common to all departments) sends various notifications to policyholders." Category (g) is "Physical Evidence." The use case description for category (g) is "The insurance company (new contract) sends the insurance policy to the right holder."

[0119] Use case descriptions can be entered in multiple lines in one input field 156. After entering use case descriptions for all categories in the input fields 156, pressing the "OK" button at the bottom sends the use case descriptions to the use case input unit 12, and the display transitions to the example of ubiquitous language in FIG. 16.

[0120] [Ubiquitous language display example] Next, a display example of ubiquitous language will be described with reference to FIG. Fig. 16 is a diagram showing a display example of the user interface unit 11 for checking and editing a ubiquitous language. Fig. 16 shows an example of an interface screen 160 for checking a list of ubiquitous language candidates and adopting a ubiquitous language.

[0121] On the interface screen 160, a list of candidate ubiquitous languages ​​generated by the ubiquitous language generation unit 13 is displayed in a left-hand column 161. The user can select a term to be used as a ubiquitous language from the candidate list and move the selected term to the ubiquitous language column 162 on the right by pressing a "move" button 163 in the center of the screen. To cancel a term moved to the ubiquitous language column 162 on the right, the user can select the term to be canceled from the list of ubiquitous languages ​​and press a "back" button 164 to cancel the move.

[0122] For example, the following are registered as ubiquitous language candidates: "customer," "policyholder," "insurance company (new contract)," "system," "contract," "required matters / required documents (application)," "documents," "inspection," "access," "authentication / authorization," "product viewing," "application," etc. In this example, all of the ubiquitous language candidates displayed in the left-hand column 161 have been moved to the ubiquitous language column 162 on the right-hand side.

[0123] Furthermore, by pressing the "Edit" button 165, the user can display an editing window where they can change the name of the ubiquitous language or add a new one. After selecting and editing all the ubiquitous languages, by pressing the "OK" button at the bottom, the ubiquitous languages ​​are sent to the ubiquitous language generation unit 13, and the display transitions to the example of subdomain information in Fig. 17.

[0124] [Example of subdomain information display] Next, examples of displaying subdomain information will be described with reference to FIGS. FIG. 17 is a diagram showing an example of a display on the user interface unit 11 for checking and editing subdomain information.

[0125] 17 shows an example of an interface screen 170 for confirming and editing candidate information for subdomain information. The interface screen 170 has a file selection field for organization information 171, a file selection field for business information 172, a subdomain information display area 173, and an “Edit” button 174.

[0126] The user specifies and uploads a file of organizational information 171 and a file of business information 172 related to this use case description. The organizational information 171 may be the name of a department or team related to the use case description, and may be provided in text format, or in a spreadsheet file format. The business information 172 may be the name of a department or role related to the use case description, and may be provided in text format, or in a spreadsheet file format.

[0127] In the subdomain information display area 173, subdomain information candidates are displayed in switchable tabs, and multiple subdomain information candidates can be displayed by switching between them. In Fig. 17, the "Candidate 1" tag is selected. The subdomain information displays the subdomain candidate information generated by the subdomain information output unit 14.

[0128] For example, the subdomain candidate information displayed includes "Access (browser / smartphone)," "Authentication / Authorization," "Contract information management," "System operation," "Product registration," "Product viewing," "Application," "Inspection," "Appraisal," "Insurance premium payment," "Securities shipping," "Insurance claim application," "Review," "Insurance claim payment," "Progress management (contractor / business)," and "Notification."

[0129] [Example of editing subdomain information] FIG. 18 is a diagram showing an example of a display for editing subdomain information. 18, the user can draw arrows indicating connections between subdomains according to the business flow by pressing the "Edit" button 174. When the user presses the "Edit" button 174, an editing window is displayed, allowing the user to input lines and arrows between subdomains.

[0130] [Example of subdomain attribute information display] FIG. 19 is a diagram showing an example of display of attribute information of subdomain information. As shown in Fig. 19, the user can press an "Edit" button 174 to open an editing window and assign attribute information to each subdomain. Fig. 19 shows an example in which each subdomain has been edited to belong to one of a support subdomain 191, a core subdomain 192, and a general-purpose subdomain 193. For example, each subdomain can be easily distinguished from other subdomains by using different display colors or line styles for the support subdomain 191, the core subdomain 192, and the general-purpose subdomain 193.

[0131] After the user has finished editing the subdomain information, by pressing the “OK” button at the bottom, the currently displayed subdomain candidate information will be sent to the subdomain information output unit 14, and the display will transition to the example of context information shown in Figure 20.

[0132] [Example of context information display] Next, a display example of the context information will be described with reference to FIG. FIG. 20 is a diagram showing a display example of the user interface unit 11 for checking and editing the context information.

[0133] 20 shows an interface screen 200 as an example of how context information is displayed. The interface screen 200 has a "Use Case" button 151, a "Ubiquitous" button 152, a "Subdomain" button 153, a "Bounded Context" button 154, a "Context Map" button 155, a context information display area 201, an "Edit" button 202, an "OK" button, and a "Cancel" button.

[0134] The context information display area 201 displays the context information generated by the context information output unit 15. This context information is displayed in the order rearranged by the context information output unit 15. In this example, in the context information display area 201, the attribute information is displayed in the upper row as a subdomain of the support subdomain 191 (product browsing, etc.), the attribute information is displayed in the middle row as a subdomain of the core subdomain 192 (assessment), and the attribute information is displayed in the lower row as a subdomain of the general-purpose subdomain 193 (insurance payment, etc.).

[0135] The user can open an editing window by pressing the "Edit" button 202, where they can change the name of the context information, add new information, or integrate multiple pieces of context information. When adding a new context, an editing screen is displayed where they can select and associate subdomain information.

[0136] After the user has finished editing the context information, by pressing the "OK" button at the bottom, the context information is sent to the context information output unit 15, and the display transitions to the example context map shown in Fig. 21. When integrating contexts by editing the user's context, the context information output unit 15 also integrates the associated subdomain information and ubiquitous language, and updates the subdomain information 23 and context information 24.

[0137] [Context map display example] Next, a display example of a context map will be described with reference to FIG. FIG. 21 is a diagram showing an example of a display on the user interface unit 11 for creating a context map.

[0138] 21 shows an interface screen 210 as an example of a context map display. The interface screen 210 has a "Use Case" button 151, a "Ubiquitous" button 152, a "Subdomain" button 153, a "Bounded Context" button 154, a "Context Map" button 155, a context map display area 211, an "Edit" button 212, an "OK" button, and a "Cancel" button.

[0139] In the initial state, the context map display area 211 of the interface screen 210 displays the context information 24 after the editing of the context information in Fig. 20 is completed. The context map displayed on the interface screen 210 is a candidate diagram of the microservice boundary regarding the correspondence between each process included in the business process.

[0140] The user can open an editing window by pressing the "Edit" button 212 and draw the connection relationships between contexts. The user can also add strings representing the upstream "U" and downstream "D" of the context to the lines between contexts. Furthermore, the user can add strings representing the connection method between contexts, such as "Open Host Service" (OHS), "Anti-Corruption Layer" (ACL), and "Published Language" (PL), to each context.

[0141] After the user has completed creating the context map, by pressing the "OK" button at the bottom, the context map is sent to the microservice information output unit 16, and the display transitions to the example of microservice information shown in FIG.

[0142] [Example of displaying microservice information] Next, a display example of microservice information will be described with reference to FIG. FIG. 22 is a diagram showing a display example of the user interface unit 11 for checking and editing microservice information.

[0143] FIG. 22 shows an example of an interface screen 210 in which microservice candidate information (microservice candidate 1 in the figure) is highlighted on a context map created by the user. The microservice candidate information displays the microservice candidate information created by the microservice information output unit 16. The microservice candidate information is displayed in an example in which the corresponding context is surrounded by a line (for example, a frame 221) that highlights the corresponding context. As another display method, the corresponding context may be displayed in a different color or flashed.

[0144] [Hardware configuration of the microservice design support system] FIG. 23 is a diagram illustrating an example of the hardware configuration of the microservice design support system 10. The microservice design support system 10 includes, as hardware, a calculator 230. The calculator 230 is used as a computer and includes a processor 231, a main memory 232, a storage device 233, a communication device 234, an input device 235, and a display device 236, which are connected to a bus 237.

[0145] The storage device 233 stores data in a writable and readable manner, and stores the use case description information 17, industry terminology 18, ubiquitous language 19, organizational information 20, business information 21, past design information 22, subdomain information 23, context information 24, and microservice information 25 shown in Figure 2.

[0146] The processor 231 reads data stored in the storage device 233 into the main memory 232 and executes the processing of the software program using the main memory 232. The processor 231 executes the software program to realize the user interface unit 11, use case input unit 12, ubiquitous language generation unit 13, subdomain information output unit 14, context information output unit 15, and microservice information output unit 16 shown in FIG.

[0147] The communication device 234 transmits information processed in the processor 231 via a communication network including wired and / or wireless networks, and also conveys information received via the communication network to the processor 231. The information received by the communication device 234 is used for software processing in the processor 231.

[0148] The input device 235 is a device that receives information input by a user through a keyboard, a mouse, etc. The information input by the input device 235 is used in software processing in the processor 231.

[0149] The display device 236 is a device that displays image and text information on a display screen in accordance with software processing by the processor 231. The interface screens exemplified in Figures 15 to 22 are displayed by the display device 236.

[0150] As described above, the microservice design support system according to this embodiment is a microservice design support system that supports the user in determining which areas of their business process should be turned into microservices, and includes a use case input unit, a ubiquitous language generation unit, and a subdomain information output unit. A use case related to a user's business process is input as text information (use case description) to a use case input unit (use case input unit 12). The ubiquitous language generation unit (ubiquitous language generation unit 13) generates ubiquitous language related to the components included in the text information of the use case input to the use case input unit. The subdomain information output unit (subdomain information output unit 14) groups use cases that include matching or similar elements based on the ubiquitous language and the use case, and further subgroups the text information of the grouped use cases based on whether the information is similar in terms of the business process, thereby generating subdomain information.

[0151] According to this embodiment with the above configuration, it is possible to systematize the organization of steps included in a customer's business process (subdomain information generation) based on input information (text information of use cases) related to the business process (business domain), and to support the creation of microservices. In other words, it is possible to realize design support for microservices that eliminates dependency on individuals. This has the effect of stabilizing design quality without relying on the intuition or experience of skilled workers.

[0152] In addition, the microservice design support system according to this embodiment can be further configured to include a context information output unit (context information output unit 15) that generates context information representing boundaries between similar contexts in a business process based on subdomain information, and a microservice information output unit (microservice information output unit 16) that generates, based on the context information, a candidate diagram (microservice map) of microservice boundaries relating to the correspondence between each process included in the business process.

[0153] With this configuration, in this embodiment, microservice candidate information can be automatically displayed, so that even those without experience can identify the parts of a business process that should be converted into microservices.

[0154] The microservice design support system according to this embodiment further includes a past design information storage unit (past design information 22) that stores past microservice design information, and a similarity calculation unit (subdomain information output unit 14) that calculates the similarity between subdomain information and the past microservice design information. If the similarity is equal to or greater than a threshold, the subdomain information output unit (subdomain information output unit 14) acquires subdomain information from the past microservice design information, updates the generated subdomain information based on the similarity between the acquired subdomain information and the generated subdomain information, and outputs the subdomain information.

[0155] With this configuration, in this embodiment, by updating subdomain information using past microservice design information (past design information 22), it is possible to create a more appropriate microservice boundary candidate diagram (microservice map) that reflects the past microservice design information.

[0156] The present invention is not limited to the above-described embodiments, and various other applications and modifications are possible without departing from the spirit of the present invention as set forth in the claims. For example, the above-described embodiments have been described in detail and specifically to clearly explain the present invention, and are not necessarily limited to those including all of the components described. Furthermore, it is also possible to add, replace, or delete other components from part of the configuration of the embodiments.

[0157] Furthermore, the above-described configurations, functions, processing units, etc. may be partially or entirely realized in hardware, for example, by designing them as integrated circuits, etc. As the hardware, a broad processor device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) may be used.

[0158] Furthermore, each component of the microservice design support system 10 according to the above-described embodiment may be implemented in any hardware as long as the respective hardware can transmit and receive information to and from each other via a network. Furthermore, the processing performed by a certain processing unit may be realized by a single piece of hardware, or may be realized by distributed processing using multiple pieces of hardware.

[0159] In addition, in the microservice design support system 10 of the above-described embodiment, the control lines and information lines are those that are considered necessary for explanation, and not all control lines and information lines are necessarily shown in the product. In reality, it can be considered that almost all components are interconnected.

[0160] In this specification, processing steps describing chronological processing include not only processing performed chronologically in the order described, but also processing that is not necessarily performed chronologically but is performed in parallel or individually (for example, processing by objects). Furthermore, the processing order of processing steps describing chronological processing may be changed as long as it does not affect the processing results. [Explanation of symbols]

[0161] 10...Microservice design support system, 11...User interface section, 12...Use case input section, 13...Ubiquitous language generation section, 14...Subdomain information output section, 15...Context information output section, 16...Microservice information output section, 17...Use case description information, 18...Industry terminology, 19...Ubiquitous language, 20...Organizational information, 21...Business information, 22...Past design information, 23...Subdomain information, 24...Context information, 25...Microservice information

Claims

1. A microservice design support system that supports determining areas to be converted into microservices in a user's business process, a use case input unit into which use cases related to the user's business process are input as text information; a ubiquitous language generation unit that generates ubiquitous language related to components included in the text information of the use case input to the use case input unit; a subdomain information output unit that groups use cases including matching or similar elements based on the ubiquitous language and the use cases, and further subgroups the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information. Microservice design support system.

2. a context information output unit that generates context information representing a boundary between similar contexts in the business process based on the subdomain information; and a microservice information output unit that generates a candidate diagram of a microservice boundary regarding a correspondence relationship between each process included in the business process based on the context information. The microservice design support system according to claim 1 .

3. a past design information storage unit for storing past microservice design information; Further comprising a similarity calculation unit that calculates a similarity between the subdomain information and the past microservice design information, When the similarity is equal to or greater than a threshold, the subdomain information output unit acquires subdomain information from the past microservice design information, updates the generated subdomain information based on the similarity between the acquired subdomain information and the generated subdomain information, and outputs the subdomain information. The microservice design support system according to claim 1 .

4. A microservice design support method using a microservice design support system that supports the determination of areas to be converted into microservices in a user's business process, a process of inputting a use case related to the user's business process as text information; A process of generating ubiquitous language related to components included in the input text information of the use case; and a process of grouping use cases including elements with similar meanings based on the ubiquitous language and the use cases, and further subgrouping the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information. Microservice design support method.

5. The microservice design support system helps users decide which areas of their business processes to turn into microservices. inputting a use case related to the user's business process as text information; A step of generating ubiquitous language related to components included in the input text information of the use case; a procedure for grouping use cases including elements with similar meanings based on the ubiquitous language and the use cases, and further subgrouping the text information of the grouped use cases based on whether the information is similar in the business process, thereby generating subdomain information; The program to run.

Images