Modeling support system, modeling support method, and modeling support program

Abstract

To enable support for easily and appropriately modeling an application.SOLUTION: In a modeling support system 100 that supports modeling a plurality of entities related to an application, a processor is configured to: create an entity relation model of the plurality of entities on the basis of a schema of a database 108 of an application 102; generate an entity map 112 representing a relation between the plurality of entities on the basis of the entity relation model and a source code 104; calculate a behavior metric between entities on the basis of the entity map 112 and a source log 106; calculate a relation degree indicating the relation between entities on the basis of the behavior metric; generate a plurality of pieces of structure information indicating configurations of entities having different numbers of aggregation on the basis of the relation degree; and identify optimum aggregation structure information including an optimum aggregation boundary from the plurality of pieces of structure information.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This invention relates to a technology that assists in the modeling of applications. [Background technology]

[0002] For example, an application might be designed for a specific platform, but that platform might change. In this case, the application might not function correctly on the new platform.

[0003] For example, Patent Document 1 discloses a technique relating to the migration of a system to a platform different from the one it was originally designed for. The technique in Patent Document 1 proposes a novel method for partitioning a system or application for migration to container and microserver-based platform systems. The partitioning method is defined as reconfiguring or decomposing existing computer code to improve the performance of the existing computer code without changing the intended functionality of the code. This method includes a resource identifier that takes resource identification rules and sources, parses the input, and outputs a reconfigured microserver application deployment on the cloud and containers. [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] U.S. Patent No. 10901709 [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] For example, the technology disclosed in Patent Document 1 only considered the structural and static analysis of applications that required user specifications. Therefore, it often relied on prior knowledge, which was time-consuming and prone to human error.

[0006] This invention has been made in view of the above circumstances, and its purpose is to provide a technology that can easily and appropriately model applications. [Means for solving the problem]

[0007] To achieve the above objective, the modeling support system relating to one perspective is a modeling support system that supports the modeling of multiple entities related to an application, and has a processor, the processor creates an entity relationship model of the multiple entities based on the schema of the application's database, creates an entity map representing the relationships of the multiple entities based on the entity relationship model and the source code of the application, calculates a behavior metric that shows the relationship in the behavior between each entity based on the entity map and the source log relating to the behavior in the application, calculates a degree of relationship that shows the relationship between each entity based on the behavior metric, generates multiple structural information showing the configuration of entities, each with a different number of aggregates containing one or more entities based on the degree of relationship, and identifies optimal aggregate structure information, which is structural information containing the optimal aggregate boundary, from the multiple structural information. [Effects of the Invention]

[0008] According to the present invention, it is possible to provide support for easily and appropriately modeling applications. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is an overall configuration diagram of a modeling support system according to one embodiment. [Figure 2] FIG. 2 is a diagram for explaining the calculation of metrics according to one embodiment. [Figure 3] FIG. 3 is a configuration diagram of a first table group of an information table according to one embodiment. [Figure 4] FIG. 4 is a configuration diagram of a second table group of an information table according to one embodiment. [Figure 5] FIG. 5 is a configuration diagram of an entity attribute table according to one embodiment. [Figure 6] FIG. 6 is a flowchart of the overall process according to one embodiment. [Figure 7] FIG. 7 is a diagram for explaining an entity map according to one embodiment. [Figure 8] FIG. 8 is a flowchart of the processing of a behavior dynamic flow analyzer according to one embodiment. [Figure 9] FIG. 9 is a flowchart of the processing of an aggregation boundary identifier according to one embodiment. [Figure 10] FIG. 10 is a diagram for explaining the processing of an optimal aggregation identifier according to one embodiment. [Figure 11] FIG. 11 is a diagram showing the concepts of cohesion, coupling, and transition regarding aggregation according to one embodiment. [Figure 12] FIG. 12 is a flowchart of the processing of an optimal aggregation identifier according to one embodiment. [Figure 13] FIG. 13 is a configuration diagram of an information table output from a modeling support system according to one embodiment. [Figure 14] FIG. 14 is a flowchart of the processing of an aggregation route identifier according to one embodiment. [Figure 15] FIG. 15 is a diagram for explaining the calculation of the importance of an entity according to one embodiment. [Figure 16] FIG. 16 is a diagram for explaining the processing of a history data generator according to one embodiment. [Figure 17] FIG. 17 is a diagram for explaining the operation of a system for storing events according to one embodiment. [Figure 18]Figure 18 is a diagram illustrating semantic mapping according to one embodiment. [Figure 19] Figure 19 is a flowchart of the processing of a history data generator according to one embodiment. [Modes for carrying out the invention]

[0010] Embodiments will be described with reference to the drawings. Note that the embodiments described below are not intended to limit the invention as defined in the claims, and not all of the elements and combinations thereof described in the embodiments are necessarily essential to the solution of the invention.

[0011] In the following explanation, information may be described using the term "AAA table," but the information can be represented in any data structure. In other words, to show that the information is independent of the data structure, we can refer to the "AAA table" as "AAA information."

[0012] First, an overview of this embodiment will be described.

[0013] This embodiment is an automated method for modeling applications by focusing on the domain, similar to the principles of Domain-Driven Design (DDD). This embodiment introduces a novel approach to identify the structure of aggregates, one of the core building blocks of DDD within an application, based on past user behavior by analyzing logs during application execution. An aggregate is a cluster of related entities treated as a single unit, and therefore all entities constituting an aggregate must either be updated together or not updated at all. The method of this embodiment incorporates a dynamic behavior analysis component together with a structural static analysis component to identify the structure of aggregates and enable users to reconstruct previous states of the application based on user-defined events.

[0014] This embodiment proposes a method for modeling applications by adhering to the core principles of DDD. This embodiment eliminates the need for business experts for domain modeling, as it does not require specifications from business domain experts to understand the domain. The aggregate structure found with the help of this embodiment is useful for modeling the domain and for smoothly migrating to a microservices framework following DDD implementation. Furthermore, this embodiment also enables users to automate the generation of application history events and store them in a persistence infrastructure. These events can be used to access any previous state of the application or for analysis to make more informed business decisions.

[0015] This method requires, for example, the application's source code, a database, and logs as input. Often, logs include performance or dynamic data on code elements and relationships, as well as transaction data, executed SQL queries, resource consumption data, function calls, and test logs. The source code is used for static analysis of the application based on code elements and relationships. The database is used to reverse-engineer the entity-relationship model (ERM) to identify various relationships between entities, such as cardinality, inheritance (IsA relationships), inclusion (HasA relationships), and parent-child relationships.

[0016] The system of this embodiment uses relational analysis techniques for input from an application. The system may collect traces from the provided input, such as program execution data, user data flow, transactions, and entity relationship design. Relationships between entities are derived from function calls, message passing relationships, dependencies, communication frequencies, and other available data. The system may generate visualizations representing the relationships between entities as a graph structure, where entities are nodes and relationships between entities are links between entities.

[0017] This system may quantify the strength of relationships between entities using a structural static flow analyzer and a behavioral dynamic flow analyzer. In many cases, static analysis of an application does not need to reveal all information within the application. The behavioral dynamic flow analyzer provides behavioral metrics by extracting potential invariants from identified use cases based on application logs, which may include program traces, test execution logs, and transactions. The characteristic of aggregation is that it gives us the ability to enforce invariants by providing consistency boundaries. The structural static flow analyzer provides similarity and distance metrics. The strength between entities is calculated based on these three metrics, for example, by a weighted sum of the three metrics.

[0018] A system is provided to prepare N graphs (N = |E|, where E is the set of all entities). Here, the nth graph has n aggregate clusters. The N graphs are generated by employing a determined weighted graph clustering algorithm, varying the number of clusters from 1 to N. The resulting N graphs are information about possible configurations in the system, where each cluster provides an aggregate structure.

[0019] An optimal aggregate classifier is provided that can collect data for static and dynamic analysis and find the optimal number of aggregate boundaries based on metrics derived from the input data. The identified solution may minimize coupling and transitions between aggregates and maximize cohesion within aggregates. An aggregate root classifier is provided that can identify key entities within aggregates by following an entity importance algorithm based on data provided from logs, entity relationship models, and source code.

[0020] The system provides the user with information about the structure of each aggregate and its root. The output may also include details of all methods that act on each aggregate, based on mappings from source code and logs. In accordance with the properties of a DDD-based application, a command or state change method functions on only one aggregate at a time. Details of the system's structure and behavior help the user better understand their domain and appropriately refactor the application code.

[0021] The history data generator may use user-issued events as input to a defined file whenever a particular method is executed based on an identified optimal structure, and executions can be logged using semantic method mapping analysis. The history events thus generated are stored in a persistent infrastructure that can be further used for analyzing and accessing the history state.

[0022] The technology of this embodiment can assist software engineers (SEs) in modeling a domain based on Domain-Driven Design (DDD) principles, and as a result, SEs can implement microservices such as CQRS (Command Query Responsibility Separation) and ES (Event Sourcing) without the need to collaborate with domain experts. The technology of this embodiment can help SEs gain a clearer understanding of their domain and further assist them in dividing their programs based on identified boundaries of aggregates, which are one of the building blocks of the DDD software design approach. The technology of this embodiment can be further used to restore the historical state of an application by issuing historical events according to user-defined events. These historical events can be further used for data analysis and more informed business decision-making.

[0023] To illustrate the operation of this embodiment, various diagrams, including data flow diagrams, system diagrams, tables, and flowcharts, will be further described. The source log input may be, but is not limited to, any data describing the execution history of the program, and may include performance or dynamic data of code elements and relationships, transaction data, executed SQL queries, resource consumption data, function calls, test logs, etc. The tables may be in any format that can run on any possible tool or software, may be any database tables, and may contain any data in formats such as XML (Extensible Markup Language) or text.

[0024] Figure 1 is an overall configuration diagram of a modeling support system according to one embodiment.

[0025] The modeling support system 100 is composed of a computer such as a PC (Personal Computer) or server having a processor, memory, and storage devices (e.g., hard disk drive, solid state drive). The modeling support system 100 includes an entity relationship model generator 110, an entity mapper 114, a structural static flow analyzer 116, a behavioral dynamic flow analyzer 124, an aggregation boundary identifier 128, an optimal aggregation identifier 132, an aggregation route identifier 136, an application refactorer 140, a history data generator 142, and an event store history event sequential storage 148. In this embodiment, each component is configured, for example, by the processor of the modeling support system 100 executing a program (modeling support program).

[0026] The entity relationship model generator 110 checks the schema of the database 108, generates an entity relationship model by reverse engineering it, and stores the information of the entity relationship model in the relevant tables of the information table T1000 (see Figures 3-5).

[0027] Based on the verified source code 104, source log 106, and entity relationship model, the entity mapper 114 may determine an entity map 112 that uses nodes as entities and links the relationships between related entities as links. In a legacy application, a class annotated with "entity" in a framework such as Spring Java (registered trademark), a model class of a model-view-controller (MVC) framework application, or any table may represent an entity.

[0028] The structural static flow analyzer 116 identifies a control flow mapping 118 based on static analysis and quantifies the dependencies between entities based on calculated metrics such as a similarity metric 120 and a distance metric 122. This facilitates further measuring the strength of the relationships between entities.

[0029] FIG. 2 is a diagram for explaining the calculation of metrics according to an embodiment.

[0030] The structural static flow analyzer 116 calculates the distance metric 122 according to Equation 1101 in FIG. 2. Here, e j , i , e j denotes an entity, and d(e i , e j ) is the distance between entities e i , e j . If there is a direct connection relationship between e i and e j , that is, if e i isA e j or e j isA e i , then d(e i , e j ) = 1. If there is no direct connection relationship between e i and e j but they are indirectly connected, then d(e i , e j ) is the shortest path between them, obtained by traversing the isA relationship in ascending / descending order, and d(ei ,e j )>1. Also, e i and e j If they are not connected even indirectly, then d(e i ,e j ) = ││E││, which is the total number of entities that exist. The structural static flow analyzer 116 also calculates the similarity metric 120 using equation 1102 in Figure 2. Here, Attr() indicates the attribute of the entity in parentheses.

[0031] Returning to the description of Figure 1, the behavioral dynamic flow analyzer 124 constructs a behavioral model of the system by identifying a set of invariants performed by the system based on the execution history of the application represented by the source log 106. The source log may be, but is not limited to, any data describing the execution history of a program, and may include performance or dynamic data of code elements and relationships, transaction data, executed SQL queries, resource consumption data, function calls, test logs, etc. The dynamic analysis infers the invariants and the entities involved in the execution of such invariants in order to measure the likelihood that two entities are in the same aggregate by quantifying the relationships of the behavioral metrics 126.

[0032] The aggregate boundary classifier 128 identifies various possible graphs (structural information) of the application's aggregate model based on the measured metrics.

[0033] The optimal aggregation classifier 132 takes "N" aggregation graph clusters 130 identified by the aggregation boundary classifier 128 as input and outputs an optimal aggregation boundary graph 134 (optimal aggregation structure information) which has the optimal aggregation boundaries for entities identified as aggregations, based on various metrics such as cohesion, cohesion, and transitionability.

[0034] The aggregated route identifier 136 identifies all route entities 138 within the aggregate of the optimal aggregate boundary graph 134 and outputs the result to the user.

[0035] The application refactorer 140 may refactor the application 102 based on the structure of the optimal aggregate boundary graph 134 identified by the optimal aggregate classifier 132 and the aggregate route classifier 136.

[0036] The history data generator 142 may generate history events 146 by using user-defined events 144 and mapping the methods defined in the source code 104 that generate each event, and generate application history data based on the semantic mapping. The events are sequentially stored for each aggregation in the history event sequential storage 148 within the event store in the persistence infrastructure.

[0037] Next, we will describe the information table T1000 created by the modeling support system 100. The information table T1000 is stored in the memory or storage device of the modeling support system 100.

[0038] Figure 3 is a diagram of the configuration of the first group of tables in an information table according to one embodiment, Figure 4 is a diagram of the configuration of the second group of tables in an information table according to one embodiment, and Figure 5 is a diagram of the configuration of the entity attribute table according to one embodiment.

[0039] Information table T1000 includes entity relationship model table T1100, entity table T1200, entity link table T1300, aggregate structure table T1400, entity relationship data table T1500, entity importance table T1600, and entity attribute table T1700.

[0040] The entity-relationship model table T1100 is derived from the database 108 of application 102. The entity-relationship model table T1100 stores entries for each entity (in this embodiment, for example, a table in database 108). The entries in the entity-relationship model table T1100 include fields for the primary entity T1110, the relation entity T1120, and the relation T1130.

[0041] The primary entity T1110 stores the name of the entity of interest (primary entity) corresponding to the entry. The relational entity T1120 stores the names of the entities (relational entities) that are related to the primary entity corresponding to the entry. The relational entity T1130 includes fields for FK T1132, which stores information indicating the relationship between the primary entity and the relational entity corresponding to the entry, as well as Cardinarlity T1134, isA T1136, and hasA T1138.

[0042] FK T1132 stores information indicating whether the primary entity is related to the relational entity via a foreign key (FK). Cardinality T1134 stores the cardinality (multiplicity) between the primary entity and the relational entity. isA T1136 stores information indicating whether the primary entity has an inheritance relationship (isA relationship) with the relational entity. hasA T1138 stores information indicating whether the primary entity has an inclusion relationship (hasA relationship) with the relational entity.

[0043] The entity table T1200 is a table that manages entities and stores an entry for each entity. An entry in entity table T1200 includes the fields ID T1210, entity name T1220, and abbreviation T1230.

[0044] ID T1210 stores the ID of the entity corresponding to the entry. Entity name T1220 stores the name of the entity corresponding to the entry. Abbreviation T1230 stores the abbreviation of the entity corresponding to the entry.

[0045] The entity link table T1300 is a table that manages links that indicate relationships between entities, and stores an entry for each link for an entity. An entry in the entity link table T1300 includes the fields ID T1310, source T1320, and target T1330.

[0046] ID T1310 stores the ID that identifies the link corresponding to the entry. Source T1320 stores the ID of the entity that is the source of the link corresponding to the entry. Target T1330 stores the ID of the entity that is the destination of the link corresponding to the entry.

[0047] The aggregate structure table T1400 is a table that manages the possible configurations of recognized aggregates. Here, an aggregate is a group of entities. Entries in the aggregate structure table T1400 include fields for aggregate number T1410, aggregate ID T1420, and entity T1430.

[0048] The aggregation count T1410 stores the total number of aggregations included. The aggregation ID T1420 stores the ID of the aggregation. The entity T1430 stores the abbreviation of the entity included in the aggregation corresponding to the entry's ID.

[0049] The entity relationship data table T1500 is a table that manages the degree of relationship, which is a quantitative measure indicating the relationship between entities, and stores entries corresponding to each entity. Entries in the entity relationship data table T1500 include fields for source T1510, target T1520, and degree of relationship T1530.

[0050] Source T1510 stores the abbreviation of one entity between the entities corresponding to the entry. Target T1520 stores the abbreviation of the other entity between the entities. Relationship T1530 stores the degree of relevance between the entities corresponding to the entry.

[0051] The entity importance table T1600 is a table that manages the quantified importance of entities and contains entries for each entity. Entries in the entity importance table T1600 include fields for aggregate ID T1610, entity T1620, and importance T1630.

[0052] The aggregate ID T1610 stores the ID of the aggregate to which the entity corresponding to the entry belongs. The entity T1620 stores the abbreviation of the entity corresponding to the entry. The severity T1630 stores the severity of the entity corresponding to the entry.

[0053] The entity attribute table T1700 is a table that manages the attributes of each entity and stores entries for each entity. Entries in the entity attribute table T1700 include fields for entity T1710 and attribute T1720. Entity T1710 stores the abbreviation of the entity corresponding to the entry. Attribute T1720 stores the attributes of the entity corresponding to the entry.

[0054] Next, we will explain the processing operations performed by the modeling support system 100.

[0055] Figure 6 is a flowchart of the overall process according to one embodiment.

[0056] The modeling support system 100 inputs the source code 104, source log 106, and database 108 from the application 102 (P100). Next, the entity relationship model generator 110 obtains an entity relationship model (ERM) by reverse engineering the input database 108 and stores the related information in the information table T1000 (P101).

[0057] Next, the entity mapper 114 maps entities using the ERM, source log, and source code to generate an entity map 112 (P102).

[0058] Next, the structural static flow analyzer 116 calculates a distance metric and a similarity metric between entities based on the control flow mapped from the static analysis of the source code (P103).

[0059] Next, the behavioral dynamic flow analyzer 124 calculates a behavioral metric between entities based on the dynamic analysis using the source code (P104).

[0060] Next, the aggregation boundary identifier 128 calculates the degree of relationship between entities by calculating a weighted combination of the similarity metric, distance metric, and behavioral metric. The degree of relationship between entities is stored in the entity relationship data table T1500.

[0061] Next, the aggregation boundary identifier 128 obtains a plurality (for example, the maximum value of n) of graphs having n clusters (P106). Here, 1 < n < │E│, and E is the number of all possible entities.

[0062] Next, the aggregation boundary identifier 128 determines a graph having an optimal aggregation boundary from among the plurality of obtained graphs (P107).

[0063] Next, application refactorer 140 refactors the source code structure based on the determined graph (P108).

[0064] Next, the modeling support system 100 accepts from the user to define events in a file, along with all the information that triggers an event when the aggregate state changes (P109).

[0065] Next, the history data generator 142 issues previous events of the application through semantic mapping (P110).

[0066] Next, the history data generator 142 stores the events in each event stream corresponding to a single aggregate in the database (P111).

[0067] Next, we will describe the entity map 112 output by the entity mapper 114.

[0068] Figure 7 illustrates an entity map according to one embodiment.

[0069] In the entity map 112, each node 400 represents an entity, and the relationships between entities are represented as links 404. Here, a weight 402 indicating the degree of relationship between entities is associated with each link. The weights between each entity can be represented, for example, as shown in the rectangular adjacency matrix 406. For example, the weight w8 between Customer and Delivery Info is 1.69 in the rectangular adjacency matrix 406. In this embodiment, the degree of relationship between each entity is managed by the entity relationship data table T1500.

[0070] Next, we will explain the processing of the behavioral dynamic flow analyzer 124.

[0071] Figure 8 is a flowchart of the processing of a behavioral dynamic flow analyzer according to one embodiment. This processing is performed in step P104 of Figure 6.

[0072] First, the behavioral dynamic flow analyzer 124 receives the source log 106 of application 102 (P200).

[0073] Next, the behavioral dynamic flow analyzer 124 uses dynamic analysis of the source log to extract data invariants that indicate the expected range of values ​​for variables selected during normal program execution, event invariants that capture common patterns of system events, such as the order in which events occur, and time invariants that capture the normal duration of event frequency (P201).

[0074] Next, the behavioral dynamic flow analyzer 124 uses the invariants extracted by the dynamic analysis to infer the user behavior flow (P202). Here, the most frequently occurring user actions can be identified by analyzing combinations of invariants, such as event-specific data invariants that capture the temporal relationship between data and events, time-specific event invariants that capture constraints between events and time and represent the transition time boundary from one event to another, and time-specific data invariants that capture the relationship constraints between time and data invariants. Subsequent analysis helps identify the behavior of various users of the application. For example, a customer who wants to order a product needs to follow a specific flow each time. Such recurring user behavior is identified by the system.

[0075] Next, the behavioral dynamic flow analyzer 124 determines whether or not it is the end of the identified user behavior (P203). If it is the end of the identified user behavior (P203: Yes), the process proceeds to step P208.

[0076] On the other hand, if it is not the end of the specified user behavior (P203: No), the behavior dynamic flow analyzer 124 identifies all data invariant conditions in the user behavior flow (P204) and determines whether it is the end of the identified data invariant conditions (P205).

[0077] As a result, if it is the end of the data invariant conditions (P205: Yes), the behavior dynamic flow analyzer 124 advances the process to step P203.

[0078] On the other hand, if it is not the end of the data invariant conditions (P205: No), the behavior dynamic flow analyzer 124 identifies all entities involved in the calculation of the data invariant conditions, together with the entities involved in the calculation of the identified entity (P206). An entity is a combination of various variables. The calculation of the data invariant conditions may include the processing of several variables. In this process, entities containing variables that are part of the calculation of the data invariant conditions are also included in the above-mentioned entities.

[0079] Next, based on the previous analysis, the behavior dynamic flow analyzer 124 calculates a behavior metric representing the strength of the relationship between entities based on dynamic analysis (P207) and advances the process to step P205.

[0080] In step P208, the behavior dynamic flow analyzer 124 stores the behavior metric values between each entity in the database. Note that the behavior metric values will be used to quantify the relationship between entities.

[0081] Next, the processing of the aggregation boundary identifier 128 will be described.

[0082] FIG. 9 is a flowchart of the processing of the aggregation boundary identifier according to an embodiment. This processing is the processing executed in step P106 of FIG. 6 and is a process of generating a graph of a plurality (the maximum value of n) of n clusters. Here, 1 < n < │E│, where E is the set of all entities, and each cluster represents an aggregation boundary.

[0083] The aggregate boundary classifier 128 receives the entity map 112 obtained from the entity mapper 114 as input (P300).

[0084] Next, the aggregate boundary classifier 128 calculates the total number of entities N present in application 102 (P301).

[0085] Next, the aggregated boundary classifier 128 determines whether N is less than 1 (P302).

[0086] As a result, if N is not less than 1 (P302: No), the aggregation boundary classifier 128 generates a graph of N clusters (aggregates) (P303). Here, the method for dividing multiple entities into N clusters is based on the degree of relationship between each entity. Specifically, clusters are constructed so that entities with strong relationships belong to the same cluster.

[0087] Next, the aggregate boundary classifier 128 stores the generated graph data in the database (P304), subtracts 1 from N (P305), and proceeds to step S302.

[0088] On the other hand, if N is less than 1 (P302: Yes), it means that all graphs have been created, so the aggregate boundary classifier 128 supplies the data of all created graphs to the optimal aggregate classifier 132 (P306).

[0089] Next, we will explain the processing performed by the optimal aggregation classifier 132.

[0090] Figure 10 is a diagram illustrating the processing of an optimal aggregation classifier according to one embodiment.

[0091] Graph A700 is a graph corresponding to the data supplied to the optimal aggregate classifier 132 by the aggregate boundary classifier 128. Graph A700 is supplied to processor A706, which functions as the optimal aggregate classifier 132. Processor A706 takes source code 104 and source log 106 as input and performs three types of analyses in parallel: cohesiveness analysis A708, coupling analysis A710, and transition analysis A712.

[0092] Cohesion analysis A708 is a process that calculates a cohesion metric that represents how closely entities in a particular aggregate are related to each other. Joint analysis A710 is a process that calculates a join metric that represents the dependency between one aggregate and another. Transition analysis A712 is a process that calculates a transition metric that shows the frequency of ACID transactions moving from one aggregate to another in the behavior of a particular user. For example, the transition metric can be calculated using the following equation (1).

[0093] Transition metric = │T(Ai,Aj)│ / │T(Ai)∪T(Aj)│ ···(1) Here, the numerator represents the total number of ACID transactions between the two aggregates Ai and Aj, and the denominator represents the total number of ACID transactions contained within the two aggregates Ai and Aj.

[0094] The optimal aggregation generator A714 identifies (determines) the optimal aggregation boundary graph A716, which is the optimal graph, based on the coupling metric, the transition metric, and the cohesiveness metric, and outputs the identification result. In this embodiment, the optimal aggregation generator A714 identifies a graph in which the coupling metric and the transition metric are at their lowest values ​​and the cohesiveness metric is at its maximum value, and outputs the identification result. In this case, for example, the graph that maximizes the value of equation (2) below becomes the optimal aggregation boundary graph.

[0095] a*binding metric + b*transition metric + c*(1 / cohesive metric)···(2) Here, a, b, and c are constants.

[0096] Next, we will explain the concepts of cohesion, bonding, and transitionality in relation to aggregation.

[0097] Figure 11 shows the concepts of cohesiveness, bonding, and transitionality for an aggregate according to one embodiment. In Figure 11, cohesiveness B702, bonding B704, and transitionality B706 are shown in aggregate B700.

[0098] Cohesion B702 is determined using a cohesion metric that quantifies the dependencies between entities within an aggregate. Higher cohesion indicates better grouping within the aggregate. Joint B704 is determined by a join metric that quantifies the dependencies between two aggregates. Lower join indicates better grouping within the aggregate. Transitivity B706 is determined by a transitionivity metric that quantifies how often or how necessary ACID transactions move from one aggregate to another. Lower transitionivity indicates better grouping within the aggregate.

[0099] Figure 12 is a flowchart of the processing of an optimal aggregation classifier according to one embodiment.

[0100] The optimal aggregation classifier 132 receives multiple graphs created by the aggregation boundary classifier 128 as input (P400).

[0101] The optimal aggregation classifier 132 assigns the number of all entities in the input graph to N (P401).

[0102] Next, the optimal aggregation classifier 132 determines whether N is less than 1 (P402).

[0103] As a result, if N is not less than 1 (P402: No), the optimal aggregate classifier 132 selects N aggregate graphs from the graph (P403), calculates the cohesion metric, bonding metric, and transition metric for each aggregate in these graphs (P404), stores the metric values ​​for each aggregate in these graphs in the database (P405), subtracts 1 from N (P406), and proceeds to step S402.

[0104] On the other hand, if N is less than 1 (P402: Yes), it means that metric values ​​have been calculated for all graphs. In this case, the optimal aggregation classifier 132 determines the graphs with the optimal number of aggregation boundaries (optimal aggregation boundary graphs) based on the three metric values ​​for each graph, and stores information about the optimal aggregation boundary graphs in the optimal aggregation structure table T2100 (see Figure 13) (S407).

[0105] Figure 13 is a diagram showing the configuration of an information table output from a modeling support system according to one embodiment.

[0106] Information table T2000 contains the optimal aggregation structure table T2100. The optimal aggregation structure table T2100 is a table that manages the optimal aggregation structure (optimal aggregation structure: optimal aggregation boundary graph 134) and contains entries for each aggregation included in the optimal aggregation structure. The entries in the optimal aggregation structure table T2100 include fields for aggregation ID T2110, structure T2120, and root T2130.

[0107] The aggregate ID T2110 stores the ID of the aggregate corresponding to the entry. The structure T2120 stores the abbreviation of the entity included in the aggregate corresponding to the entry. The root T2130 stores the abbreviation of the root entity in the aggregate corresponding to the entry. Note that the value of root T2130 is stored by the processing of the aggregate root identifier 136 in Figure 14.

[0108] Next, we will explain the processing performed by the aggregated route identifier 136.

[0109] Figure 14 is a flowchart of the processing of an aggregated route identifier according to one embodiment.

[0110] The aggregated route identifier 136 receives data about the optimal aggregated boundary graph (P500).

[0111] Next, the aggregation route discriminator 136 determines whether all aggregations in the optimal aggregation boundary graph have been considered (P501).

[0112] As a result, if not all aggregations are considered (P501: No), the aggregation route identifier 136 determines whether it has covered the processing of all entities within the aggregation being processed (P502).

[0113] As a result, if the processing of all entities within the aggregate being processed is covered (P502: Yes), the aggregate route identifier 136 proceeds to step P501.

[0114] On the other hand, if the processing of all entities within the aggregate being processed is not covered (P502: No), the aggregate root identifier 136 identifies the connected ancestor and descendant entities for the entity and calculates the total number (P503).

[0115] Next, the aggregated route identifier 136 measures the set of attributes of the entity and the inherited attribute of the entity (P504).

[0116] Next, the aggregate route identifier 136 calculates the total number of collections in which entities and inherited entities participate (P505).

[0117] Next, the aggregate route identifier 136 calculates the importance of the entities and stores it in the entity importance table T1600 (P506), then proceeds to step P502.

[0118] On the other hand, if all aggregations are considered (P501: Yes), the aggregation route identifier 136 assigns the entity with the highest importance in each aggregation to the route of each aggregation (P507), The optimal aggregation structure table T2100 stores information about the root entity in the aggregation process (information about the root entity) (P508).

[0119] Next, we will explain how to calculate the importance of entities.

[0120] Figure 15 illustrates the calculation of the importance of an entity according to one embodiment.

[0121] The aggregation route identifier 136 calculates the importance of each entity in the aggregation using the entity importance calculation formula B804. The importance of entity e is I. TIM (e) is the number of ancestor entities (parents and their ancestors) of entity e (ancestor count: par inh (e)) and the number of descendants (children and their descendants) of entity e (number of descendants: chi) inh (e)) and the number of attributes of entity e and the attributes of entities that possess those attributes (attribute count: attr inh (e)) and the number of entities that have a relationship with entity e (relational entities) and entities that have a relationship with relational entities (assoc inh (e)) is calculated based on the following. For example, if the aggregation is represented by entity P800 and link P802 in Figure 15, then the importance of entity A is I TIM (A) is calculated to be 7, as shown in Figure 15.

[0122] Next, we will explain the processing of the history data generator 142.

[0123] Figure 16 is a diagram illustrating the processing of a history data generator according to one embodiment.

[0124] The history data generator 142 uses source code 104, source log 106, user-defined event 144, and optimal aggregation structure table T2100 as input data 900. The history data generator 142 includes semantic mapper 910 and history event generator 912.

[0125] The semantic mapper 910 takes input data 900 as input and maps previously executed methods to the event data structure. The history event generator 912 generates history events based on the application's past execution trace and stores them in the persistence infrastructure 918. Event streams 914 and 916, containing time-series history events, each correspond to one aggregate.

[0126] Figure 17 is a diagram illustrating the operation of an event storage system according to one embodiment.

[0127] This system is modeled based on the DDD principle. Client B900 executes methods B902 and B904, also called system commands. These methods are state modification methods that create, update, or delete the application state by, for example, modifying aggregates B906 and B908.

[0128] Any change to an aggregate will result in the issuance of events B910 and B912, which are sequentially stored in event streams B914 and B916 of the persistence infrastructure B918. In this model, each command is routed to only one aggregate. While multiple commands can be routed to an aggregate, each command functions for only one aggregate. Additionally, each event stream will contain events sequentially issued by a single aggregate. This makes the system design and maintenance relatively easy.

[0129] Next, we will explain semantic mapping using semantic mapper 910.

[0130] Figure 18 is a diagram illustrating semantic mapping according to one embodiment.

[0131] The user must define event C900, which contains a variable command describing method C904, accompanied by the issuance of a specific event C902. The semantic mapper 910 maps the executed methods and executes the past program execution traces C910, C912, C914. The semantic mapper 910 identifies the execution of the aggregate from the program trace so that the execution traces C910, C912, C914 indicate the execution of the aggregate. Event C902 is issued after the transaction of the aggregate has finished and is stored in the persistence infrastructure. The metadata properties of the issued event are populated with the aggregate's values ​​after the state change so that they contain all the information necessary to build and analyze the previous state. For example, in the case of execution trace C912, it would be populated with "ssn_id:1000000,name:custOne,age:26,..." etc.

[0132] Next, we will explain the processing operation by the history data generator 142.

[0133] Figure 19 is a flowchart of the processing of a history data generator according to one embodiment.

[0134] The history data generator 142 takes user-defined events, source logs, and source code as input (P600), and identifies methods by semantically mapping the names of methods defined in user-defined events with the names defined in the source code (P601). The output optimal aggregation boundary map allows the user to understand the aggregation structure, see which methods lead to the execution of which specific methods, and thereby define user-defined events appropriately.

[0135] Next, the history data generator 142 identifies logs output by a specific method identified from the user-defined event file format when the method is executed (P602), and groups logs containing some entities of the aggregate by mapping the logs from the source logs issued by the execution of the method, as shown in the execution traces C910, C912, and C914 in Figure 18 (P603).

[0136] Next, the history data generator 142 inputs the changed aggregate state value (data) into the metadata property of the issued event, as shown in event C902 in Figure 18 (P604). This process is performed on logs that include INSERT, UPDATE, and DELETE statements of SQL queries. Then, once the data is input, the history data generator 142 issues an event with all the data as metadata (P605).

[0137] Next, the history data generator 142 sequentially stores the events in the event stream of the event store (P606).

[0138] It should be noted that the present invention is not limited to the embodiments described above, and can be implemented with appropriate modifications without departing from the spirit of the invention.

[0139] Furthermore, in the above embodiment, some or all of the processing performed by the processor may be performed by hardware circuits. Also, the program in the above embodiment may be installed from a program source. The program source may be a program distribution server or a recording medium (for example, a portable recording medium). [Explanation of symbols]

[0140] 100…Modeling support system, 102…Application, 104…Source code, 106…Source log, 108…Database, 110…Entity model relational model generator, 114…Entity mapper, 116…Structural static flow analyzer, 124…Behavioral dynamic flow analyzer, 128…Aggregation boundary classifier, 132…Optimal aggregation classifier, 136…Aggregation route classifier, 140…Application refactorer, 142…History data generation unit

Claims

1. A modeling support system that assists in modeling multiple entities related to an application, It has a processor, The aforementioned processor, Based on the schema of the application's database, create an entity relationship model for multiple entities. Based on the entity relationship model and the source code of the application, an entity map representing the relationships between multiple entities is created. Based on the entity map and the source logs related to the behavior in the application, behavioral metrics indicating the relationships in the behavior between each entity are calculated. Based on the aforementioned behavioral metrics, a relationship degree indicating the relationship between each entity is calculated. Based on the aforementioned relationship, multiple structural information sets are generated that show the configuration of entities, each with a different number of aggregates containing one or more entities. From the aforementioned plurality of structural information, we identify the optimal aggregated structural information, which is the structural information containing the optimal aggregated boundary. Modeling support system.

2. The aforementioned processor, Based on the source code of the application, the entity relationship model, and the transaction flow in the source log, an entity map is created that links together entities with high relationships. The modeling support system according to claim 1.

3. The aforementioned processor, Based on the entity map, a distance metric indicating the distance between entities is calculated, and based on the database, a similarity metric indicating the similarity of attributes between entities is calculated. The relationship is calculated based on the behavior metric, the distance metric, and the similarity metric. The modeling support system according to claim 1.

4. The aforementioned processor, For each of the multiple structural information sets, a cohesion metric indicating the dependencies between entities within the aggregate included in the structural information, a coupling metric indicating the dependencies between two aggregates, and a transition metric indicating the frequency or necessity of moving from one aggregate to another are calculated. Based on the cohesion metric, the coupling metric, and the transition metric, the optimal aggregate structural information is identified. The modeling support system according to claim 1.

5. The aforementioned processor, The structural information that maximizes the cohesiveness metric and minimizes the bonding metric and the transition metric is identified as the optimal aggregated structural information. The modeling support system according to claim 4.

6. The aforementioned processor, For each entity in the aggregation, the importance of the entity is calculated based on the number of ancestors, descendants, attributes, and related entities. Based on the aforementioned importance level, identify the root entity in the aggregation. The modeling support system according to claim 1.

7. The aforementioned processor, Based on the identified optimal aggregate structure information, the application is refactored. The modeling support system according to claim 1.

8. The aforementioned processor, Historical events are generated by mapping user-defined events defined by the user to methods defined in the source code that generate each event, thereby generating historical data. The modeling support system according to claim 1.

9. A modeling support method using a modeling support system that assists in the modeling of multiple entities related to an application, The processor of the aforementioned modeling support system is Based on the schema of the application's database, create an entity relationship model for multiple entities. Based on the entity relationship model and the source code of the application, an entity map representing the relationships between multiple entities is created. Based on the entity map and the source logs related to the behavior in the application, behavioral metrics indicating the relationships in the behavior between each entity are calculated. Based on the aforementioned behavioral metrics, a relationship degree indicating the relationship between each entity is calculated. Based on the aforementioned relationship, multiple structural information sets are generated that show the configuration of entities, each with a different number of aggregates containing one or more entities. From the aforementioned plurality of structural information, we identify the optimal aggregated structural information, which is the structural information containing the optimal aggregated boundary. Modeling support methods.

10. A modeling support program that is run on a computer to assist in the modeling of multiple entities related to an application, To the aforementioned computer, Based on the database schema of the aforementioned application, create entity relationship models for multiple entities. Based on the aforementioned entity relationship model and the source code of the application, an entity map representing the relationships between multiple entities is created. Based on the entity map and the source logs related to the behavior in the application, a behavior metric indicating the relationship between the behaviors of each entity is calculated. Based on the aforementioned behavioral metrics, the relationship degree, which indicates the relationship between each entity, is calculated. Based on the aforementioned relationship, multiple structural information sets are generated that show the configuration of entities, each with a different number of aggregates containing one or more entities. The system is designed to identify optimal aggregated structural information, which includes the optimal aggregated boundary, from the aforementioned multiple pieces of structural information. Modeling support program.

Images