MOM-oriented business domain and technical domain model mapping method and device, equipment and medium

Abstract

The invention provides an MOM-oriented business domain and technical domain model mapping method and device, equipment and a medium, and relates to the technical field of software development, and the method comprises the steps: constructing an activity graph of a business target according to a plurality of key activities supporting the realization of the business target; extracting each key activity from the activity graph, and decomposing each key activity into a plurality of atomic tasks; according to the atomic tasks, a flow chart of each key activity is constructed, and a plurality of DDD concept objects are marked in the flow charts; extracting a plurality of DDD concept objects related to each atomic task from the flow chart, and constructing a class chart of a scene unit corresponding to each atomic task; and extracting a plurality of DDD core concept objects related to interaction from the class diagram, and constructing a time sequence diagram of a scene unit corresponding to each atomic task. According to the method, through a top-down modeling process, an expression path from a business target to a domain model to execution logic is realized, and the efficiency and quality of MOM software development are improved.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of software development, and provides a MOM-oriented business domain and technical domain model mapping method, device, equipment and medium. BACKGROUND

[0002] Manufacturing operation management (MOM) software is an important tool for supporting intelligent manufacturing, industrial internet and digital workshop construction, and undertakes the integration and management tasks of core businesses such as production planning, operation execution, quality control and inventory management. In order to meet the needs of manufacturing enterprises for multi-business integration, rapid response and flexible configuration, MOM software is evolving towards modularity, platformization and low code, and business modeling has become a key prerequisite for realizing software flexibility, model automatic generation.

[0003] The existing business modeling method mainly uses flowcharts, diagrams and other methods to describe the business, and mainly focuses on the expression of functional behavior. In the face of complex requirements such as multi-level decomposition of targets, nested execution of business activities, and close coupling of data and rules in manufacturing scenarios, there is often a lack of unified modeling language and multi-level structure support, making it difficult to clearly depict the internal relationship between business structure and execution logic, resulting in a lack of semantic consistency and technical traceability between business models and software implementation, affecting the efficiency and quality of MOM software development. SUMMARY

[0004] The application provides a MOM-oriented business domain and technical domain model mapping method, device, equipment and medium, which is used to solve the problems of poor efficiency and quality in the development process of MOM software.

[0005] In a first aspect, the application provides a MOM-oriented business domain and technical domain model mapping method, which comprises: According to a plurality of key activities supporting the realization of a business target, an activity graph of the business target is constructed; the activity graph is used to describe the execution logic between the plurality of key activities; Each key activity is extracted from the activity graph, and each key activity is decomposed into a plurality of atomic tasks; According to the plurality of atomic tasks, a flowchart of each key activity is constructed, and a plurality of DDD concept objects are labeled in the flowchart; the flowchart is used to describe the interaction process between the plurality of atomic tasks; A plurality of DDD concept objects involved in each atomic task are extracted from the flowchart, and a class diagram of a scenario unit corresponding to each atomic task is constructed; the class diagram is used to describe the structured dependency relationship between the plurality of DDD concept objects; extract a plurality of DDD core concept objects related to interaction from the class diagram, and construct a sequence diagram of a scene unit corresponding to each atomic task; the sequence diagram is used to describe an interaction process between the plurality of DDD core concept objects.

[0006] Optionally, constructing the activity diagram of the business target according to the plurality of key activities supporting the realization of the business target comprises: determining a business process for realizing the business target; determining a plurality of key activities supporting the realization of the business target and a control flow conversion sequence between the plurality of key activities according to the business process; determining a business domain to which each key activity belongs; the business domain is a production domain, a planning domain, a quality domain, a maintenance domain or a logistics domain; constructing the activity diagram of the business target according to the plurality of key activities, the business domain to which each key activity belongs and the control flow conversion sequence between the plurality of key activities.

[0007] Optionally, constructing a flowchart of each key activity according to the plurality of atomic tasks and marking a domain-driven design (DDD) object in the flowchart comprises: identifying a plurality of data objects related to the plurality of atomic tasks and a transmission direction between the plurality of data objects; determining a trigger event in the plurality of atomic tasks; constructing a flowchart of each key activity according to each key activity, the plurality of atomic tasks, the trigger event, the plurality of data objects and the transmission direction; marking the DDD object in the flowchart according to a reaction relationship between elements of the flowchart and the DDD concept object.

[0008] Optionally, the reaction relationship comprises: one key activity corresponds to one aggregate root, one business domain corresponds to one bounded context, one trigger event corresponds to one domain service, one atomic task corresponds to an aggregate, one data object corresponds to one entity or one value object.

[0009] Optionally, constructing a class diagram of a scene unit corresponding to each atomic task according to the DDD concept objects related to each atomic task from the flowchart comprises: extracting a plurality of DDD concept objects related to each atomic task from the flowchart; establishing a combination relationship and a dependency relationship between the plurality of DDD concept objects; constructing a class diagram of a scene unit corresponding to each atomic task according to the plurality of DDD concept objects, the combination relationship and the dependency relationship; the class diagram is marked with a type, an attribute and a method of each DDD concept object.

[0010] Optionally, the step of extracting a plurality of DDD core concept objects involved in interaction in each atomic task from the class diagram to construct a sequence diagram of a scenario unit corresponding to each atomic task comprises: extracting a plurality of DDD core concept objects involved in interaction in each atomic task from the class diagram as a plurality of key classes; constructing a sequence diagram of each atomic task according to an interaction process between the plurality of key classes.

[0011] Optionally, after extracting a plurality of DDD core concept objects involved in interaction in each atomic task from the class diagram to construct a sequence diagram of a scenario unit corresponding to each atomic task, the method further comprises: performing a verification operation on the flowchart, the class diagram and the sequence diagram; the verification operation comprises: checking whether all DDD core concept objects in the sequence diagram are derived from the class diagram; checking whether message calling in the sequence diagram conforms to an operation method defined in the class diagram; checking whether aggregates in the class diagram interact through a domain service; checking whether the flowchart has covered the plurality of atomic tasks; checking whether preconditions, postconditions, data inputs and data outputs of each atomic task are explicitly defined in the flowchart.

[0012] In a second aspect, the present application provides a MOM-oriented business domain and technical domain model mapping device, the device comprising: an activity diagram construction module configured to construct an activity diagram of a business target according to a plurality of key activities supporting implementation of the business target, the activity diagram being configured to describe execution logic between the plurality of key activities; a flowchart construction module configured to extract each key activity from the activity diagram, decompose each key activity into a plurality of atomic tasks, construct a flowchart of each key activity according to the plurality of atomic tasks, and label a plurality of DDD concept objects in the flowchart, the flowchart being configured to describe an interaction process between the plurality of atomic tasks; a class diagram construction module configured to extract a plurality of DDD concept objects involved in each atomic task from the flowchart, and construct a class diagram of a scenario unit corresponding to each atomic task, the class diagram being configured to describe a structured dependency relationship between the plurality of DDD concept objects; a sequence diagram construction module configured to extract a plurality of DDD core concept objects involved in interaction from the class diagram, and construct a sequence diagram of a scenario unit corresponding to each atomic task, the sequence diagram being configured to describe an interaction process between the plurality of DDD core concept objects.

[0013] In a third aspect, the present application provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the MOM-oriented business domain and technical domain model mapping method in the first aspect.

[0014] In a fourth aspect, the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the processor executes the computer program to implement the MOM-oriented business domain and technical domain model mapping method in the first aspect.

[0015] Compared with the prior art, the present application has the following beneficial effects: The present application provides a MOM-oriented business domain and technical domain model mapping method, which comprises: constructing an activity graph of a business target according to a plurality of key activities supporting the implementation of the business target; the activity graph is used to describe the execution logic between the plurality of key activities; extracting each key activity from the activity graph, and decomposing each key activity into a plurality of atomic tasks; constructing a flowchart of each key activity according to the plurality of atomic tasks, and marking a plurality of DDD concept objects in the flowchart; the flowchart is used to describe the interaction process between the plurality of atomic tasks; extracting a plurality of DDD concept objects involved in each atomic task from the flowchart, and constructing a class diagram of a scene unit corresponding to each atomic task; the class diagram is used to describe the structured dependency relationship between the plurality of DDD concept objects; extracting a plurality of DDD core concept objects involved in the interaction from the class diagram, and constructing a timing diagram of the scene unit corresponding to each atomic task; the timing diagram is used to describe the interaction process between the plurality of DDD core concept objects.

[0016] As can be seen, the present application surrounds the business target, and performs target decomposition, activity arrangement, object modeling, and behavior interaction modeling through a top-down modeling process, and clearly defines the control logic and data flow path of the business process through the activity graph and the flowchart, and completes the static and dynamic modeling unification through the class diagram and the timing diagram, so as to ensure that the model structure is highly cohesive, the dependency is controllable, and the behavior is consistent, and to realize the expression path from the business target of the MOM software to the domain model and then to the execution logic, thereby providing strong structured support for efficient and high-quality MOM software development, and the present application can also be applied to the development of manufacturing operation type complex software in the future, and improves the clarity and reusability of the business model. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the following will briefly introduce the drawings needed to be used in the embodiments or the related art description. Obviously, the drawings described in the following are only a part of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of the provided drawings.

[0018] Figure 1 The computer device structure schematic diagram of the hardware running environment related to the embodiments of the present application; Figure 2 The process schematic diagram of the MOM-oriented business domain and technology domain model mapping method provided by the embodiments of the present application; Figure 3 The schematic diagram of the activity graph provided by the embodiments of the present application; Figure 4 The schematic diagram of the flowchart provided by the embodiments of the present application; Figure 5 The schematic diagram of the class diagram provided by the embodiments of the present application; Figure 6 The schematic diagram of the timing diagram provided by the embodiments of the present application; Figure 7 The framework schematic diagram of the MOM-oriented business domain and technology domain model mapping method provided by the embodiments of the present application; Figure 8 The structure schematic diagram of the MOM-oriented business domain and technology domain model mapping device provided by the embodiments of the present application.

[0019] Marked in the figure: 101-processor, 102-communication bus, 103-network interface, 104-user interface, 105-memory. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solutions and advantages of the present application more clear, the following will combine the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only a part of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application. In the case of no conflict, the embodiments in the present application and the features in the embodiments can be combined with each other at will. And, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in different order from here.

[0021] In the actual research and development process, there are several problems in the business modeling link of MOM software. First, the business modeling granularity lacks unified specifications, and it is difficult to accurately distinguish the boundaries and levels between targets, activities, processes and entities in the modeling process. Second, the business logic expression is disconnected from the technical implementation model, resulting in a lack of consistency in the path from business description to software implementation. Third, the coverage relationship of software functions to business targets is not clear, and business requirements are difficult to form a verifiable goal-oriented model. These problems are particularly evident in multi-business scenario collaboration, complex domain modeling, and other aspects, directly affecting the rapid construction and model reuse of MOM software.

[0022] In view of this, the embodiment of the application provides a MOM-oriented business domain and technical domain model mapping method, which can be executed by a computer device. Please refer to Figure 1 , the computer device structure schematic diagram of the hardware running environment related to the embodiment of the application.

[0023] As Figure 1 shown, the computer device can include a processor 101, such as a central processing unit (CPU), a communication bus 102, a user interface 104, a network interface 103, and a memory 105. The communication bus 102 is used to realize the connection and communication between these components. The user interface 104 can include a display, an input unit such as a keyboard, and the user interface 104 can include a standard wired interface, a wireless interface. The network interface 103 can include a standard wired interface, a wireless interface (such as a wireless fidelity (WIreless-FIdelity, WI-FI) interface). The memory 105 can be a high-speed random access memory (RAM) memory, and can also be a stable non-volatile memory (Non-Volatile Memory, NVM), such as a magnetic disk memory. The memory 105 can also be a storage device independent of the aforementioned processor 101.

[0024] Those skilled in the art can understand that Figure 1 the structure shown in the foregoing embodiments does not constitute a limitation on the computer device, and can include more or fewer components than the illustrated components, or combine certain components, or different component arrangements.

[0025] As Figure 1 shown, the memory 105 as a storage medium can include an operating system, a network communication module, a user interface module, and a MOM-oriented business domain and technical domain model mapping device.

[0026] In Figure 1The computer device shown, the network interface 103 is mainly used for data communication with the network server; the user interface 104 is mainly used for data interaction with the user; the processor 101 in the computer device of the application, the memory 105 can be arranged in the computer device, the computer device calls the MOM-oriented business domain and technical domain model mapping device stored in the memory 105 through the processor 101, and executes the MOM-oriented business domain and technical domain model mapping method provided by the embodiment of the application.

[0027] Please refer to Figure 2 A flowchart of the MOM-oriented business domain and technical domain model mapping provided by the embodiment of the application is shown below. Figure 1 The MOM-oriented business domain and technical domain model mapping method shown in the computer device is introduced. Figure 2 The MOM-oriented business domain and technical domain model mapping method shown in the computer device is introduced.

[0028] S201, according to the multiple key activities supporting the business target implementation, the activity graph of the business target is constructed.

[0029] In a possible embodiment, the business process for realizing the business target is determined; according to the business process, the multiple key activities supporting the business target implementation and the control flow conversion sequence between the multiple key activities are determined; the business domain to which each key activity belongs is determined; the business domain is a production domain, a planning domain, a quality domain, a maintenance domain or a logistics domain; according to the multiple key activities, the business domain to which each key activity belongs and the control flow conversion sequence between the multiple key activities, the activity graph of the business target is constructed.

[0030] In the specific implementation process, first, the business target is converted into an executable business process with the enterprise-level business target as the starting point, multiple key activities playing a supporting role in the business process are identified, and the control flow conversion sequence between the multiple key activities is determined through business target decomposition and process mapping.

[0031] Secondly, the ISA-95 (Enterprise-Control System Integration) international standard proposes five business domains of manufacturing operation, including a production domain, a planning domain, a quality domain, a maintenance domain and a logistics domain; the key activities can be classified based on the business target, the operation object type and the functional positioning in the manufacturing process, so as to establish the standardized business domain boundary, and lay a foundation for subsequent scenario modeling and model semantic consistency.

[0032] Finally, according to the multiple key activities, the business domain to which each key activity belongs, and the control flow sequence between the multiple key activities, a business process chain is constructed by using the BPMN2.0 standard modeling language. The business domain is represented by a lane, the key activities in the lane are represented by sub-processes, and the sequence flow between the sub-processes represents the control flow sequence between the multiple key activities, so as to clearly express the responsibility boundary and control relationship of each business link, thereby constructing an activity graph of a business target, and describing the execution logic between the multiple key activities.

[0033] For example, the business target is that a factory hopes to realize rapid identification, response and disposal of an exception by constructing a standardized quality exception processing process, so as to improve the straight-through rate and shorten the exception processing time.

[0034] The steps of decomposing the business target and drawing a process graph are as described in S1.1-S1.3: S1.1, identifying key activities.

[0035] The key activities supporting the implementation of the business target are: detection alarm, locking problem batch, root cause analysis, rework, scrap and material recycling.

[0036] S1.2, determining the business domain to which each key activity belongs.

[0037] The quality domain: detection alarm, locking problem batch, root cause analysis.

[0038] The production domain: rework.

[0039] The planning domain: scrap.

[0040] The inventory domain: material recycling.

[0041] S1.3, drawing a BPMN2.0 activity graph as shown in Figure 3 .

[0042] Figure 3 The right-angled rectangle in the figure represents a lane, the rounded rectangle in the right-angled rectangle represents a sub-process, the arrow flow between the rounded rectangles represents a sequence flow, the solid arrow represents the control flow sequence between the key activities in the same business domain, and the dashed arrow represents the control flow sequence between the key activities in different business domains.

[0043] In the embodiments of the present application, the enterprise strategic target is decomposed, the key business activities are identified, the activity graph is constructed by using the BPMN2.0 language, the business scope, control logic and sub-process boundary are determined, a unified business semantic range and domain structure are established, and a basis support is provided for subsequent modeling levels. The modeling process follows the classification standard of the MOM software business domain in the ISA-95 international standard, and provides a unified semantic hierarchical basis.

[0044] S202, extract each key activity from the activity diagram, and decompose each key activity into a plurality of atomic tasks.

[0045] In the implementation process, each key activity is extracted from the activity diagram, a series of steps required to complete the key activity is determined, each step is further decomposed into smaller and more specific tasks until it cannot be decomposed, and a plurality of atomic tasks are obtained. The atomic task refers to an independent executable and non-decomposable business operation unit, which has clear input, processing and output.

[0046] S203, according to the plurality of atomic tasks, construct a flowchart of each key activity, and mark a plurality of DDD concept objects in the flowchart.

[0047] In a possible embodiment, a plurality of data objects involved in the plurality of atomic tasks and a transmission direction between the plurality of data objects are identified; a trigger event in the plurality of atomic tasks is determined; a flowchart of each key activity is constructed according to each key activity, the plurality of atomic tasks, the trigger event, the plurality of data objects and the transmission direction; and a plurality of DDD concept objects are marked in the flowchart according to a reaction relationship between elements of the flowchart and the DDD concept objects.

[0048] In the implementation process, each atomic task needs to rely on or process certain data objects when executed, and the data object refers to a specific entity used for operation in the business process, which can be a table in the database, a class in the data model, or data for external system interaction. In the entire business process, the data object is transmitted from one atomic task to the next atomic task. Therefore, the plurality of data objects involved in the plurality of atomic tasks in each key activity can be analyzed according to a business scenario analysis document, and the transmission direction of the plurality of data objects between the atomic tasks is determined. The business scenario analysis document is a detailed analysis document of the scene, requirement, target and the like of a certain business in actual operation.

[0049] Further, the elements in the flowchart can be corresponded to the DDD concept objects, the elements in the flowchart include lanes (i.e., business domains), atomic tasks, trigger events and data objects, and the DDD concept objects include bounded context, aggregation, domain service, value object, entity and aggregate root. The corresponding relationship includes that one key activity corresponds to one aggregate root (i.e., one aggregate root is set in one key activity), one business domain corresponds to one bounded context, one trigger event corresponds to one domain service, one atomic task corresponds to aggregation, and one data object corresponds to one entity or one value object. Among them, the main business object in the data object corresponds to the entity, and the value of the other data object and the judgment condition corresponds to the value object.

[0050] Finally, the process diagram of each key activity is constructed by using the BPMN2.0 standard modeling language. The interaction process between multiple atomic tasks is described by using elements such as tasks, information flows, trigger events, data objects, and directional data associations, and the DDD concept objects are marked in the process diagram.

[0051] For example, the detection alarm is Figure 3 The first key business activity in the example is refined and the process diagram of the key activity is drawn according to steps S2.1-S2.4: S2.1, sub-process decomposition.

[0052] Each key activity (i.e., sub-process) is decomposed into multiple atomic tasks, including triggering an AOI, collecting quality data, analyzing detection data, judging whether an anomaly exists, recording a normal detection result, recording an abnormal detection result, archiving, and triggering an alarm.

[0053] S2.2, data object analysis.

[0054] The data objects involved in the multiple atomic tasks include part batch information, original detection data, analyzed detection data, and detection records (main business objects). The transfer direction is shown in Figure 4 .

[0055] S2.3, determination of a bounded context and a domain model.

[0056] In the detection alarm activity, a "detection alarm aggregate root" is set as an aggregate access entry; the quality domain to which the detection alarm activity belongs corresponds to a bounded context; triggering an AOI and triggering an alarm correspond to domain services, respectively; collecting quality data, analyzing detection data, recording a normal detection result, and recording an abnormal detection result correspond to aggregates, respectively; part production batch data, original detection data, analyzed detection data, and abnormal values correspond to value objects, respectively; and a detection record (main business object) corresponds to an entity.

[0057] S2.4, a BPMN2.0-DDD process diagram is drawn as shown in Figure 4 .

[0058] In the embodiments of the present application, the key activities in a business process are refined from a business perspective, the internal execution logic and key data flow are analyzed, the bounded context and the entities, value objects, and aggregates associated with each activity are determined in combination with the bounded context and the domain model in DDD, the interaction relationship and state change process between business objects are established, and thus a BPMN2.0 specification activity diagram oriented to a business process is constructed. The embodiments of the present application use a structured modeling method to convert complex activities in a process into a business scenario structure with an execution boundary and data consistency, form a middle-level modeling view oriented to a business control logic, and realize double-consistency expression of process semantics and a domain model.

[0059] S204, extract a plurality of DDD concept objects involved in each atomic task from the flowchart, and construct a class diagram of a scenario unit corresponding to each atomic task.

[0060] In a possible embodiment, a plurality of DDD concept objects are extracted from the flowchart; a combination relationship and a dependency relationship between the plurality of DDD concept objects are established; and a class diagram of a scenario unit corresponding to each atomic task is constructed according to the plurality of DDD concept objects, the combination relationship and the dependency relationship; the class diagram is marked with a type, an attribute and a method of each DDD concept object.

[0061] In the specific implementation process, first, a plurality of DDD concept objects (aggregates, entities, value objects, aggregate roots and domain services) are extracted from the flowchart, and class diagram modeling is performed according to one aggregate. The entities, value objects, aggregate roots and domain services involved in one aggregate are modeled into classes, and the attributes and behaviors of the class objects are given. Then, the combination relationship and the dependency relationship between the objects are established according to the business meaning and the division of responsibilities. The combination relationship refers to the whole-part relationship between the aggregate root and the objects inside the aggregate. The dependency relationship includes the temporary calling relationship between the aggregate and the external interface and the use dependency relationship of the entity to the value object. Finally, the DDD concept objects and their structured dependency relationships are visually expressed using the UML class diagram, and the type, attribute and method of each DDD concept object are marked.

[0062] Taking the task of "collecting quality detection data" as an example, the task is one of the key steps in the detection alarm flow, and is responsible for collecting raw data from the AOI device and generating a business detection record.

[0063] The steps of static modeling and drawing a class diagram for the task of collecting quality detection data are described in S3.1-S3.3: S3.1, determine the objects in the scenario unit.

[0064] The DDD concept objects include a detection record (entity), a quality detection aggregate root (aggregate root), raw detection data (value object), part batch information (value object) and an external AOI interface (dependency). The object attributes and operations are shown in Table 1. Figure 5 .

[0065] S3.2, determine the relationship between the objects.

[0066] The combination relationship includes: the quality detection aggregate root and the detection record.

[0067] The dependency relationship includes: the quality detection aggregate root calling the external AOI interface, the detection record and the raw detection data, and the detection record and the part batch information.

[0068] S3.3, draw a class diagram as shown in Table 2. Figure 5 .

[0069] In the embodiments of the present application, after the atomic-level decomposition of the business activity and the identification of the data objects are completed, the data objects involved in the atomic task are further structured modeled to support the scenario-oriented business understanding and software implementation. Each atomic task with independent business semantics is promoted to a "scenario unit", and the object relationship inside and outside the aggregation is established by taking a class diagram as a carrier. In the modeling process, the static relationship between entities, value objects, aggregations, and aggregation roots is visually expressed by using a UML class diagram, aiming to support the design of a high-cohesion and low-coupling domain model.

[0070] S205, extract a plurality of DDD core concept objects involved in interaction in each atomic task from the class diagram, and construct a timing diagram of a scenario unit corresponding to each atomic task.

[0071] In a possible embodiment, a plurality of DDD core concept objects involved in interaction in each atomic task are extracted from the class diagram as a plurality of key classes; and a timing diagram of each atomic task is constructed according to an interaction process between the plurality of key classes.

[0072] In the specific implementation process, first, based on the class diagram, a plurality of DDD core concept objects involved in interaction in each scenario unit are extracted, including an aggregation root, an entity class, a value object, and an external trigger, as an interaction participant in a dynamic model. Second, according to the interaction process in the actual business scenario, the message transmission sequence, the trigger condition, and the behavior execution path between the participating objects are sorted out, to ensure that all external requests are uniformly received through the aggregation root, and the behavior response of the aggregation internal object is triggered through the aggregation root coordination; the cross-aggregation cooperation is realized through the domain service to realize the inter-object communication. Finally, the interaction behavior between the plurality of DDD core concept objects is visually modeled by using a UML timing diagram, to clearly define the message sender, the receiver, the calling sequence, and the return information, and to verify the logical rationality of the behavior coordination of the aggregation internal and external objects.

[0073] Taking the "collecting and detecting quality data" business scenario as an example, the steps of dynamically modeling the collecting and detecting quality data task and drawing a timing diagram are as described in S4.1-S4.3: S4.1, extract the key classes involved in interaction.

[0074] Key classes: external service (domain service), quality detection aggregation root, part batch information (value object), original inspection data (value object), and inspection record (entity).

[0075] S4.2, determine the object interaction process.

[0076] The specific interaction behavior is shown in Figure 6 .

[0077] S4.3, draw a timing diagram asFigure 6 are shown.

[0078] In the embodiments of the present application, based on the object structure defined by the static class diagram, whether the behavior cooperation between the entities, value objects and aggregate roots in the model meets the business logic is verified through dynamic modeling means, so as to build a time sequence diagram, which is a key step to realize the executable of the model.

[0079] In a possible embodiment, after completing the static structure modeling (class diagram) and dynamic behavior modeling (time sequence diagram), the flowchart, class diagram and time sequence diagram are checked. The checking operation includes: 1. Check the structural behavior consistency between the class diagram and the time sequence diagram.

[0080] (1) Check whether all DDD core concept objects in the time sequence diagram are derived from the class diagram.

[0081] For the class diagram and the time sequence diagram of the scenario unit corresponding to the same atomic task, check whether all DDD core concept objects in the time sequence diagram exist in the class diagram, to ensure that each object in the time sequence diagram has a corresponding class definition, and their behaviors have been defined in the class diagram.

[0082] (2) Check whether the message call in the time sequence diagram conforms to the operation method defined in the class diagram.

[0083] For the class diagram and the time sequence diagram of the scenario unit corresponding to the same atomic task, check whether the message call in the time sequence diagram is consistent with the method name, parameters and return value type defined in the class diagram.

[0084] (3) Check whether the aggregates in the class diagram interact through the domain service. Check whether the cooperation between the aggregates in the class diagram complies with the call constraints, for example, the aggregate objects can only interact through the domain service, and cannot directly call each other.

[0085] 2. According to the key path in the business process, check whether all important business scenarios have been modeled.

[0086] (1) Check whether the flowchart has covered multiple atomic tasks.

[0087] Check whether the flowchart of each key activity has covered multiple atomic tasks decomposed by the key activity, to ensure that no atomic task or key event in execution is missed.

[0088] (2) Check whether the preconditions, postconditions, data inputs and data outputs of each atomic task are defined in the flowchart.

[0089] Preconditions refer to conditions that must be met before an atomic task is executed. By ensuring that each atomic task has clear preconditions, we can avoid tasks being executed at inappropriate times, thus maintaining the smoothness and accuracy of the process. Postconditions are the desired state or result after the execution of an atomic task. Ensuring that postconditions are clear can ensure that the business process correctly transitions to the next step after each step is completed. By ensuring that the input and output data of each task is clear, we can avoid data loss or incorrect transmission.

[0090] In the embodiments of the present application, the consistency check and business logic coverage check verify the adaptability of the model from both business and technical dimensions, ensuring its logical consistency and implementation feasibility, and laying a foundation for subsequent development and application.

[0091] In a possible embodiment, the verified model results can be used in the following aspects: 1. Code generation preparation: class diagrams and interaction logic can be mapped to domain classes and service interfaces.

[0092] According to the class structure in the class diagram, the corresponding class definition is automatically generated, including attributes and methods. According to the interaction logic, the definition of the service interface is automatically generated, including interface methods and their parameters and return value types. According to the definition of the service interface, the corresponding implementation class framework is generated, which will usually be filled according to the specific business logic.

[0093] 2. Test case design: typical test scenarios are extracted according to different branch paths in the flowchart.

[0094] According to the flowchart, each decision node and the corresponding branch path are clearly defined, and it is identified which paths have special testing requirements, and the corresponding test cases are designed.

[0095] 3. Model reuse and maintenance: through model repository management, future model modification and version control under business evolution are facilitated.

[0096] All models (activity diagrams, flowcharts, class diagrams, and timing diagrams) are stored in a unified repository for easy viewing, retrieval, and management. Each model provides version management functions, allowing the tracking of modification history for different versions, ensuring that each update is recorded. Different teams or projects can find existing models in the repository, avoiding redundant development and improving efficiency. When a model problem occurs, it can be quickly rolled back to a previous stable version.

[0097] Please refer to Figure 7 for the framework diagram of the business domain and technical domain model mapping method for MOM provided in the embodiments of the present application. The following Figure 7 introduces the business domain and technical domain model mapping method for MOM provided in the embodiments of the present application.

[0098] Firstly, from the business target layer to the business activity layer, the business target is deconstructed by using an activity diagram, key business activities are identified, a process structure is constructed by using a BPMN 2.0 language, and the business scope, control logic and sub-process boundary are determined. The modeling process follows the classification standard of the MOM software business domain in the ISA-95 international standard, and provides a unified semantic layered basis.

[0099] Secondly, from the business activity layer to the business scenario layer, the business activities are refined to atomic process units layer by layer by using a flowchart, core business objects and business rules are extracted, and the process boundary is modeled in combination with an exception handling mechanism. In the modeling process, concepts such as bounded context, aggregation, entity, value object and domain service are introduced, and a domain-oriented business scenario expression is formed.

[0100] Then, from the business scenario layer to the scenario unit layer, the relationship between the domain objects involved in the atomic task is constructed based on a class diagram, and the structured dependency relationship between the aggregate root, value object and entity is identified. The class diagram is used to determine the aggregation boundary, constraint rule and reference mode, and to support the construction of a highly cohesive domain model.

[0101] Finally, from the scenario unit layer to the execution unit layer, the dynamic interaction process between the business objects is expressed by using a time sequence diagram, and the message calling, event driving and command execution logic are described. This modeling step models the objects extracted in the class diagram, and ensures the executability of the scenario semantics.

[0102] In summary, the application provides a MOM-oriented business domain and technical domain model mapping method, which divides the MOM-oriented business domain and technical domain model mapping process into five levels, namely the business target layer, the business activity layer, the business scenario layer, the scenario unit layer and the execution unit layer. The business content and modeling granularity are refined layer by layer, the modeling conversion from the business target to the execution logic is realized, the model expression from the execution logic to the domain structure is realized, and finally the interactive logic and time sequence behavior in the software system are realized, realizing the expression path from the business target of the MOM software to the domain model and then to the interactive logic. The method realizes the unified mapping between the business structure and the software structure by constructing a layered modeling method from the business domain to the technical domain, guarantees the accurate expression of the business requirements and the consistency of the technical implementation, and helps to improve the efficiency and quality of the subsequent MOM software development.

[0103] Based on the same inventive concept, please refer to Figure 8 The application also provides a MOM-oriented business domain and technical domain model mapping device, which comprises: An activity diagram construction module is configured to construct an activity diagram of a business target according to a plurality of key activities supporting the implementation of the business target, wherein the activity diagram is used to describe the execution logic between the plurality of key activities; A flowchart construction module is configured to extract each key activity from the activity graph, decompose each key activity into a plurality of atomic tasks, construct a flowchart of each key activity according to the plurality of atomic tasks, and mark a plurality of DDD concept objects in the flowchart; the flowchart is used to describe an interaction process between the plurality of atomic tasks. A class diagram construction module is configured to extract a plurality of DDD concept objects involved in each atomic task from the flowchart, and construct a class diagram of a scenario unit corresponding to each atomic task; the class diagram is used to describe a structured dependency relationship between the plurality of DDD concept objects. A sequence diagram construction module is configured to extract a plurality of DDD core concept objects involved in interaction from the class diagram, and construct a sequence diagram of the scenario unit corresponding to each atomic task; the sequence diagram is used to describe an interaction process between the plurality of DDD core concept objects.

[0104] It should be noted that the processor in this embodiment corresponds to each step in the foregoing method for mapping a business domain to a technology domain model in a MOM, and therefore the specific embodiments of this embodiment can refer to the embodiments of the foregoing method for mapping a business domain to a technology domain model in a MOM, which will not be described herein again.

[0105] Based on the same inventive concept, the present application further provides a computer device, which comprises a processor, a memory, and a computer program stored in the memory, and the computer program is run by the processor to implement the foregoing method for mapping a business domain to a technology domain model in a MOM.

[0106] Based on the same inventive concept, the present application further provides a computer storage medium, which stores a computer program, and the computer program is run by a processor to implement the foregoing method for mapping a business domain to a technology domain model in a MOM.

[0107] In some embodiments, the computer readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or various devices comprising one or any combination of the above memories. The computer can be various computing devices including smart terminals and servers.

[0108] In some embodiments, the executable instructions can be in the form of programs, software, software modules, scripts or codes, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and can be deployed in any form, including being deployed as independent programs or as modules, components, subroutines or other units suitable for use in a computing environment.

[0109] As an example, executable instructions can correspond to a file in a file system, but in many cases will reside in a portion of the main memory (e.g., random access memory) during execution; in some cases, the executable instructions can also reside on secondary storage (e.g., a disk) from which they are loaded into memory at runtime. As an example, executable instructions can be stored in a compressed, unidentified form and then decompressed and / or identified (e.g., decrypted) prior to execution.

[0110] As an example, the executable instructions can be deployed to be executed on one computing device, or on multiple computing devices that are located at one site, or that are distributed over multiple sites and that are interconnected by a communication network.

[0111] It has to be noted that, as used herein, the terms "includes", "includes", "has", "has" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article or system that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article or system. Without further limitation, an element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article or system that includes the recited element.

[0112] The above-mentioned sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0113] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be realized by means of software and necessary general hardware platforms, of course, they can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory / random access memory, a magnetic disk, an optical disk) and includes a plurality of instructions for causing a multimedia terminal device (which can be a mobile phone, a computer, a television receiver, or a network device, etc.) to execute the methods described in the various embodiments of the present application.

[0114] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the contents of the specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for mapping business domain and technical domain models for MOM, characterized in that: The method comprises: Constructing an activity diagram for the business goal based on multiple key activities that support the realization of the business goal; the activity diagram is used to describe the execution logic between the multiple key activities; Extract each key activity from the activity diagram, and decompose each key activity into multiple atomic tasks; Based on the multiple atomic tasks, a flowchart of each key activity is constructed, and multiple DDD concept objects are annotated in the flowchart; the flowchart is used to describe the interaction process between the multiple atomic tasks; Extracting multiple DDD concept objects involved in each atomic task from the flowchart, and constructing a class diagram of the scenario unit corresponding to each atomic task; the class diagram is used to describe the structured dependency relationship between the multiple DDD concept objects; A plurality of DDD core concept objects involved in the interaction are extracted from the class diagram, and a sequence diagram of a scenario unit corresponding to each atomic task is constructed; the sequence diagram is used to describe the interaction process between the plurality of DDD core concept objects.

2. The method for mapping business domain and technical domain models for MOM according to claim 1, wherein: The steps of constructing an activity diagram for a business goal based on multiple key activities that support the achievement of the business goal include: Identify business processes to achieve business goals; Determine, based on the critical path of the business process, multiple key activities that support the achievement of the business objectives and the control flow sequence between the multiple key activities; Determine the business domain to which each key activity belongs; the business domain is production domain, planning domain, quality domain, maintenance domain or logistics domain; An activity diagram of the business goal is constructed according to the multiple key activities, the business domain to which each key activity belongs, and the control flow sequence between the multiple key activities.

3. The method for mapping business domain and technical domain models for MOM according to claim 1, wherein: The steps of constructing a flowchart of each key activity based on the multiple atomic tasks and marking domain-driven design (DDD) objects in the flowchart include: identifying a plurality of data objects involved in the plurality of atomic tasks and transfer directions between the plurality of data objects; determining trigger events among the plurality of atomic tasks; Constructing a flowchart for each key activity according to each key activity, the multiple atomic tasks, the triggering event, the multiple data objects, and the transfer direction; The DDD objects are marked in the flowchart according to the reaction relationship between the elements of the flowchart and the DDD concept objects.

4. The method for mapping business domain and technical domain models for MOM according to claim 3, wherein: The reaction relationship includes: a key activity corresponds to an aggregate root, a business domain corresponds to a bounded context, a trigger event corresponds to a domain service, an atomic task corresponds to an aggregate, and a data object corresponds to an entity or a value object.

5. The method for mapping business domain and technical domain models for MOM according to claim 1, wherein: The steps of extracting the DDD concept objects involved in each atomic task from the flowchart and constructing a class diagram of the scenario unit corresponding to each atomic task include: Extracting multiple DDD concept objects involved in each atomic task from the flowchart; Establishing a combination relationship and dependency relationship between the multiple DDD concept objects; A class diagram of a scenario unit corresponding to each atomic task is constructed based on the multiple DDD concept objects, the combination relationship, and the dependency relationship; the class diagram is annotated with the type, attributes, and methods of each DDD concept object.

6. The method for mapping business domain and technical domain models for MOM according to claim 1, wherein: The steps of extracting multiple DDD core concept objects involved in the interaction in each atomic task from the class diagram and constructing a sequence diagram corresponding to the scenario unit for each atomic task include: Extract multiple DDD core concept objects involved in the interaction of each atomic task from the class diagram as multiple key classes; A timing diagram for each atomic task is constructed according to the interaction process between the multiple key classes.

7. The method for mapping business domain and technical domain models for MOM according to claim 1, wherein: After extracting multiple DDD core concept objects involved in the interaction in each atomic task from the class diagram and constructing a sequence diagram corresponding to a scenario unit of each atomic task, the method further includes: Performing a verification operation on the flow chart, the class diagram, and the timing diagram; the verification operation includes: Check whether all DDD core concept objects in the sequence diagram are derived from the class diagram; Check whether the message call in the sequence diagram complies with the operation method defined in the class diagram; Check whether the aggregates in the class diagram interact with each other through domain services; Checking whether the flowchart has covered the multiple atomic tasks; Check whether the preconditions, postconditions, data inputs, and data outputs of each atomic task are clearly defined in the flowchart.

8. A business domain and technology domain model mapping device for MOM, characterized in that: The device comprises: An activity diagram construction module is used to construct an activity diagram of a business goal based on multiple key activities that support the realization of the business goal; the activity diagram is used to describe the execution logic between the multiple key activities; A flowchart construction module is used to extract each key activity from the activity diagram and decompose each key activity into multiple atomic tasks; based on the multiple atomic tasks, a flowchart of each key activity is constructed and multiple DDD concept objects are annotated in the flowchart; the flowchart is used to describe the interaction process between the multiple atomic tasks; A class diagram construction module is used to extract multiple DDD concept objects involved in each atomic task from the flowchart and construct a class diagram of the scenario unit corresponding to each atomic task; the class diagram is used to describe the structured dependency relationship between the multiple DDD concept objects; A timing diagram construction module is used to extract multiple DDD core concept objects involved in the interaction from the class diagram and construct a timing diagram of the scenario unit corresponding to each atomic task; the timing diagram is used to describe the interaction process between the multiple DDD core concept objects.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor executes the computer program to implement the MOM-oriented business domain and technology domain model mapping method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and the processor executes the computer program to implement the MOM-oriented business domain and technology domain model mapping method according to any one of claims 1 to 7.

Images