CN113190212A - Domain demand modeling method and device for driving open ecological cloud ERP - Google Patents
Domain demand modeling method and device for driving open ecological cloud ERP Download PDFInfo
- Publication number
- CN113190212A CN113190212A CN202110455617.2A CN202110455617A CN113190212A CN 113190212 A CN113190212 A CN 113190212A CN 202110455617 A CN202110455617 A CN 202110455617A CN 113190212 A CN113190212 A CN 113190212A
- Authority
- CN
- China
- Prior art keywords
- model
- service
- business
- data
- platform
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 125
- 238000013499 data model Methods 0.000 claims abstract description 60
- 238000006243 chemical reaction Methods 0.000 claims abstract description 39
- 230000002457 bidirectional effect Effects 0.000 claims abstract description 7
- 230000008569 process Effects 0.000 claims description 85
- 238000004590 computer program Methods 0.000 claims description 18
- 238000013507 mapping Methods 0.000 claims description 14
- 238000004364 calculation method Methods 0.000 claims description 9
- 230000000694 effects Effects 0.000 claims description 6
- 230000004888 barrier function Effects 0.000 abstract description 3
- 238000010586 diagram Methods 0.000 description 12
- 238000012545 processing Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000004931 aggregating effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 239000002243 precursor Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000004575 stone Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/24—Object-oriented
Abstract
The invention relates to the technical field of cloud native platform service, in particular to a field demand modeling method and a device for driving open ecological cloud ERP, wherein the method comprises the following steps: acquiring basic terms, and extracting a field and a theme from a field knowledge base; establishing a bidirectional conversion relation from the concept model to the business model, from the business model to the service model and from the service model to the data model according to the field and the theme; acquiring the data type of a service model, and establishing a conversion relation from the service model to the data model; and determining a target platform, converting the service model into a front-end model, a rear-end model and a flow model, and converting the data model into a database corresponding to the platform, so that the problems in the traditional ERP system are solved, the barrier between enterprises is broken, and the ERP system enters a more open interconnected ecological system.
Description
Technical Field
The invention relates to the technical field of cloud native platform services, in particular to a field demand modeling method and device for driving open ecological cloud ERP.
Background
Cloud ERP (Enterprise Resource Planning) is an Enterprise information management system deployed on a cloud platform based on internet and cloud computing. Although the cloud ERP system has lower cost and shorter deployment time compared with the traditional ERP system, the current cloud ERP system is still in an internally closed information island, and information and resources can not be exchanged among enterprises. In order to maximize the advantages of cloud computing and make up for the defects of the traditional ERP system, the barriers between enterprises must be broken, the opening and sharing of information and resources are realized, and the cloud ERP enters a more open and interconnected ecological environment.
Enterprises need to have the external cooperation capability of improving the boundary crossing of the enterprises, the ERP is required to be evolved from a single system to a distributed and decentralized micro-service set, the traditional ERP is widely advanced towards the cloud ERP, meanwhile, the problem of messy and various services and data difficult to control caused by opening is solved, and higher requirements are provided for the development and implementation of the cloud ERP in order to eliminate information islands, realize the quick response of service demand change and the boundary crossing control.
Disclosure of Invention
In view of the above, embodiments of the present invention are proposed to provide a domain demand modeling method and apparatus driving open ecological cloud ERP that overcomes or at least partially solves the above-mentioned problems.
The invention provides a field demand modeling method for driving open ecological cloud ERP, which comprises the following steps:
acquiring basic terms of a conceptual model in a calculation independence model layer, and extracting a field and a theme matched with the basic terms from a field knowledge base of a same model layer;
according to the fields and the subjects, establishing bidirectional conversion relations from a concept model to a business model, from the business model to a service model and from the service model to a data model, wherein the concept model and the business model belong to a calculation independence model layer, and the service model and the data model belong to a platform independence model layer;
acquiring the data type of the business model, and establishing a conversion relation from the business model to the data model according to the data type;
and converting the service model to a front-end model, a rear-end model and a process model corresponding to the target platform according to the target platform in the platform-related model layers determined by the user selection, and converting the data model to a database corresponding to the platform.
Preferably, the converting the conceptual model into the business model further includes:
acquiring coding information of the conceptual model and coding information of the business model;
and mapping the coding information of the conceptual model to the coding information of the business model.
Preferably, the step of converting the service model into a front-end model, a back-end model and a process model corresponding to the target platform according to a target platform in the platform-related model layers determined by the user selection, and converting the data model into a database corresponding to the platform includes:
determining a business process in the service model after the business model is converted into the service model according to the basic terms and the specific definitions of the fields and the subjects;
and establishing a conversion relation from the service model to the process model according to the business process.
Preferably, the selecting, according to a target platform in the determined platform related model layers by the user, the service model to be converted into a front-end model, a back-end model and a process model corresponding to the target platform, and the converting the data model to be converted into a database corresponding to the platform include:
acquiring a front-end service and a back-end service in a service model;
converting the back-end service into a back-end model in a platform correlation model layer, and extracting components from the database through the back-end model;
and acquiring a service object of the service model and a target service process corresponding to the service object, and binding a component corresponding to the service object with the service object according to the target service process.
Preferably, the process model includes a process definition, a triggering condition that must be satisfied for the smooth operation of the business process, input information, a precursor activity for gathering a pre-process required for completing the process, and a subsequent activity for gathering a subsequent process for completing the process, and the process definition includes a start rule for initializing a business process instance; defining a notification rule of a notification and receiving mode of information in the process of the business process; defining an execution rule of an execution mode of the business process; and defining the ending rule of the condition and the mode for ending the business process.
Preferably, the obtaining the data type of the service model and establishing a conversion relationship from the service model to the data model according to the data type include:
acquiring coding information of a business model, and determining a basic term corresponding to the business model according to a conversion relation between the business model and the concept model;
determining a basic item of a corresponding data point in the data model according to the basic term, and determining the data type of the data point according to the definition of the basic item;
and mapping the coding information of the service model to the data points of the data model according to the data type.
Preferably, the method further comprises the following steps: linking the concept model to an industrial ecology and service value chain layer, linking a business model to a solution layer, linking a service model to an application layer, and linking a data model to a cloud native layer.
Still provide a field demand modeling device of drive open ecological cloud ERP, include:
the first acquisition module is used for acquiring basic terms of the conceptual model in the computation independence model layer and extracting the fields and topics matched with the basic terms from the field knowledge base of the same model layer;
the first establishing module is used for establishing a bidirectional conversion relation from a concept model to a business model, from the business model to a service model and from the service model to a data model according to the fields and the subjects, wherein the concept model and the business model belong to a calculation independence model layer, and the service model and the data model belong to a platform independence model layer;
the second acquisition module is used for acquiring the data type of the business model and establishing a conversion relation from the business model to the data model according to the data type;
and the second acquisition module is used for converting the service model to a front-end model, a rear-end model and a process model corresponding to the target platform according to the target platform in the platform-related model layers determined by the user selection, and converting the data model to a database corresponding to the platform.
The electronic device comprises a processor, a memory and a computer program which is stored on the memory and can run on the processor, and when the computer program is executed by the processor, the computer program realizes a field requirement modeling method for driving open ecological cloud ERP.
A computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements a domain requirements modeling method that drives open ecological cloud ERP.
The embodiment of the invention has the following advantages:
the invention provides an open ecological cloud ERP based on 'knowledge + data' model drive, systematically researches key technical problems such as model definition, model mapping and the like, provides a corresponding solution, solves the problems existing in the traditional ERP system, breaks through the 'barrier' between enterprises, and enables the ERP system to enter a more open interconnected ecological system.
Drawings
FIG. 1 is a flowchart of the steps of a domain demand modeling method driving open ecological cloud ERP, in accordance with the present invention;
fig. 2 is a structural block diagram of a field demand modeling device driving open ecological cloud ERP according to the present invention.
FIG. 3 is a block diagram of a computer device for driving domain demand modeling for open ecological cloud ERP, in accordance with the present invention.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in further detail below.
Most of the traditional ERP systems are modeled by taking a process as a center and do not have the capacity of on-demand response. The embodiment of the application takes business as a center, and provides a method for realizing open ecological cloud ERP based on knowledge + data model drive, so as to solve the problem that a great number of messy businesses and data in open ecology are difficult to control.
The method follows the general structural form of a model-driven architecture, adopts a unified modeling language UML to formally describe all models in the architecture, wherein the models comprise a conceptual model, a business model, a service model and a data model, and are distributed in a CIM layer (a computation independence model layer), a PIM layer (a platform independence model layer) and a PSM layer (a platform relevance model layer).
The concept model and the service model are both subordinate to a computation independence model layer in a model driven architecture, and the service model and the data model are both subordinate to a platform independence model layer in the model driven architecture. The business model is quoted to the conceptual model, and the service model is the further refinement of the business model, stipulate the flow and front, back end service that the business needs, wherein, the front, back end service can make up the form model, can change into the front end model and back end model belonging to the correlation model layer of the platform through the selected platform, offer more detailed service for the business flow, include the flow model corresponding to business flow in the correlation model layer of the platform; the data model provides data support for the business model and the service model and corresponds to a database in the platform correlation model layer.
Model transformation and mapping are the most critical steps in model-driven engineering, and are essentially the process of generating a target model based on a source model and transformation rules. The defined conversion rule is a bridge between the source model and the target model, which fully describes the corresponding relation between the constituent elements of the source model and the target model, and the conversion and mapping process can be represented by a triple:
wherein, SourceModel is a source model, TargetModel is a target model, Rules is a conversion/mapping rule, and the relationship among the SourceModel, the TargetModel and the Rules is as follows:
in the following, the implementation of the open ecological cloud ERP in the present application will be further described with reference to the conversion and mapping between the source model and the target model.
As shown in fig. 1, a flowchart illustrating steps of a domain demand modeling method for driving open ecological cloud ERP is shown, where the method includes:
s100, obtaining basic terms of a conceptual model in the calculation independence model layer, and extracting the fields and topics matched with the basic terms from a field knowledge base of the same model layer;
s200, establishing a bidirectional conversion relation from a concept model to a business model, from the business model to a service model and from the service model to a data model according to the fields and the subjects, wherein the concept model and the business model belong to a calculation independence model layer, and the service model and the data model belong to a platform independence model layer;
s300, acquiring the data type of the business model, and establishing a conversion relation from the business model to the data model according to the data type;
s400, according to the target platform in the platform-related model layers determined by the user selection, converting the service model to a front-end model, a rear-end model and a process model corresponding to the target platform, and converting the data model to a database corresponding to the platform.
Both the conceptual model and the business model belong to the computation independence model layer in the model driven architecture. The computation independence model layer belongs to the highest level of a model-driven architecture and is mainly used for defining what services are provided by an application program. A domain knowledge base containing a complete domain knowledge set is designed in a calculation independence model layer, and the domain knowledge refers to related concepts such as objects, attributes and the like related to services in a specific domain and the relationship among the related concepts.
It is understood that the conceptual model has the most basic term definition, is a unification of concept hierarchy across business fields, is a high level of consolidation and abstraction of various aspects involved in the cloud ERP system, has a certain structure, refers to the term definition of the probability model, and has unique features in different business fields, for example, related terms determined in a field knowledge base according to the first encoded information of the conceptual model are defined as "transaction accounts", the fields thereof are "funds" or "stocks", and the conceptual model is converted into a corresponding "fund account" business model or "stock account" business model.
The conversion between the concept model and the business model is realized through the fields and the subjects, and the rules are as follows:
wherein, the concept Model is a concept Model, the Business Model is a Business Model, and the Theme indicates that the conversion rule is a Theme.
Specifically, the converting the conceptual model into the business model further includes:
acquiring coding information of the conceptual model and coding information of the business model;
and mapping the coding information of the conceptual model to the coding information of the business model.
The coding of the concept model and the coding of the business model have uniqueness, understandably, the design of the concept model is similar to a controlled vocabulary, in order to prevent misusing the vocabulary in the modeling process and causing the difficulty of semantic disorder, limited vocabulary sets are used for describing things, preferred words (basic terms) and variants (related terms) are adopted to represent consensus in a certain business field, and the coding and the definition of related vocabulary have uniqueness in the computer application modeling to ensure accurate conversion between the models.
Similarly, the conversion from the business model to the service model and the conversion from the service model to the data model establish conversion relations according to the fields and the subjects, and the codes of the corresponding models can form a mapping relation.
The conversion between the business model and the service model is realized by the field and the theme, and the rule is as follows:
wherein, the Service Model is a Service Model, and the Domain and the Theme are fields and themes;
the conversion between the service model and the data model is realized by the fields and topics, and the rules are as follows:
wherein, the Data Model is a Data Model.
In this embodiment, the conversion between the service model and the data model is realized by the data type of the service model, and the data model is converted into the corresponding data model according to the data type of the service model, and the rule is as follows:
wherein, Data Table is Data Table, Atomic Data is Atomic Data, and Data Point is Data Point.
It should be noted that the data of the business model is stored in two forms: the data table is composed of a plurality of atomic data, and the atomic data are not subdivided and are composed of texts of character types or enumeration types.
Understandably, the business model refers to a self-concept model, which is an instantiation description of the concept model in a specific business field. The service model is further refined by the business model, and defines the flow and front-end and back-end services required by the business. The data model is used as a foundation stone to provide support for the business model and the service model. The service model can provide user data for the data model, and the data model in turn promotes the evolution of the service model, so as to provide more detailed personalized service for the user.
In particular, the data model includes data points and a data space, each data point being defined by a member of the base item and a dimension characterizing the member.
The obtaining of the data type of the service model and the establishment of the conversion relationship from the service model to the data model according to the data type include:
acquiring coding information of a business model, and determining a basic term corresponding to the business model according to a conversion relation between the business model and the concept model;
determining a basic item of a corresponding data point in the data model according to the basic term, and determining the data type of the data point according to the definition of the basic item;
and mapping the coding information of the service model to the data points of the data model according to the data type.
The above-mentioned basic items refer to basic features of data, mapped to basic terms of a conceptual model, e.g., assets; the dimensions are used to partition all the information contained by the data points, for example: asset type, currency type, etc.; members are values for each dimension, for example: the "asset type" has member "mobile assets", "fixed assets", and the like. In general, two or more members are required for each dimension. Data points are stored in a data space in a format.
In an embodiment, the converting, according to a target platform in the platform related model layers determined by the user selection, the service model to a front-end model, a back-end model, and a process model corresponding to the target platform, and the converting the data model to a database corresponding to the platform include:
determining a business process in the service model after the business model is converted into the service model according to the basic terms and the specific definitions of the fields and the subjects;
and establishing a conversion relation from the service model to the process model according to the business process.
The business model refers to the conceptual model, basic terms in the conceptual model and related fields and topics make corresponding definitions on the business model, and the business model can be mapped into a business process in the service model when being converted into the service model because the business fields and the topics have different defined business processes, and the rules are as follows:
wherein, Business Process is a Business Process.
It should be noted that the service model includes a front-end service, a back-end service, and a business process, and as described above, the business process is derived from the conversion of the business model, and the back-end service and the front-end service form the service to provide a specific interface and information processing service according to the business process.
Specifically, a front-end service and a back-end service in a service model are obtained; converting the back-end service into a back-end model in a platform correlation model layer, and extracting components from the database through the back-end model; and acquiring a service object of the service model and a target service process corresponding to the service object, and binding a component corresponding to the service object with the service object according to the target service process.
Generally, business objects are bound to components, and multiple components constitute a page. For example, in the business process of "personal registration", the front-end interface displays components such as a nickname input box, a gender input box, and the like, which are respectively bound with business objects such as "user name", "user gender", and the like, and these components together form an interface of the front-end service of "personal registration".
In one embodiment, the process model includes a process definition, a trigger condition that must be satisfied for a business process to smoothly proceed, input information, a precursor activity for aggregating a pre-process required for completing the process, and a subsequent activity for aggregating a subsequent process for completing the process, and the process definition includes a start rule for initializing a business process instance; defining a notification rule of a notification and receiving mode of information in the process of the business process; defining an execution rule of an execution mode of the business process; and defining the ending rule of the condition and the mode for ending the business process.
Generally, a service is completed by a combination of multiple processes. The traditional ERP system mostly takes a flow model as a core for modeling, however, the method obviously cannot well meet the design and implementation of the ERP system of the enterprise in the face of intense industry competition and various user requirements. In the open ecological cloud ERP system, the system takes a service as a center, the process is selected according to the service requirement, the change of the service process only causes the change of the related code without influencing the architecture of the ERP, and the personalized requirement of a user is more easily realized.
The invention is based on a general model driving architecture, and also comprises the following steps: linking the concept model to an industrial ecology and service value chain layer, linking a business model to a solution layer, linking a service model to an application layer, and linking a data model to a cloud native layer.
The cloud native layer is a cloud service system established on the basis of technologies such as containers, DevOps and micro-services; the application layer provides a normalized and fragmented cloud service application for the enterprise based on the management idea from clues to cash (LTC); the solution layer provides industry interconnection-oriented solutions aiming at different application scenes, wherein the solutions comprise O2O, B2B, B2C, S2B, solutions for full-channel marketing, new retail and the like; industrial ecology and service value chain layer: all participants and the incidence relation thereof in the collaborative network between enterprises are included, and the service value chain is namely scene application.
The cloud native layer is the basis of the model layer, and the model layer is used for realizing the design and development of the ERP system driven by the model, so that the portability, the code reusability and the development efficiency are greatly enhanced. The industrial ecology and service value chain layer converges all participants and association relations in the industry, the participants and the relations jointly form an open interconnected ecosystem, and standards and business processes from all the industries are stored in a domain knowledge base. These different domain knowledge can provide the user with a clear application of scenarios that make the concept polymorphic and consistent with the concept model to business model mapping concept in the model layer. The application layer provides fragmented cloud services for enterprises by using the management idea of LTC, the solution layer is based on application of the application layer and provides solutions under different scenes, and the conversion from the application layer to the solution layer is guided by the model layer, namely different services are provided by different businesses under different scenes. In addition, the new retail mode proposed in the solution layer is to construct a user portrait by using user data and provide more intelligent and personalized services for users based on big data and AI, which is reflected in the conversion and mapping of the data model, the business model and the service model in the model layer.
Each horizontal layer and the model layer are the relationship between theory and method, that is, the horizontal layer gives the definition and the function of the included components, and the model layer provides a specific implementation mode for the horizontal layer. The model layer provides a complete method system for realizing the open ecological cloud ERP based on model driving, so that the enterprise ERP system can be better guided by the field knowledge and the user data.
It should be noted that, for simplicity of description, the method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the illustrated order of acts, as some steps may occur in other orders or concurrently in accordance with the embodiments of the present invention. Further, those skilled in the art will appreciate that the embodiments described in the specification are presently preferred and that no particular act is required to implement the invention.
Referring to fig. 2, a structural block diagram of a domain demand modeling apparatus for driving open ecological cloud ERP of the present invention is shown, and specifically, the structural block diagram may include the following modules:
a first obtaining module 100, configured to obtain a basic term of a conceptual model in a computation-independent model layer, and extract a domain and a topic that are matched with the basic term from a domain knowledge base of a same model layer;
a first establishing module 200, configured to establish a bidirectional conversion relationship from a concept model to a business model, from the business model to a service model, and from the service model to a data model according to the domain and the theme, where the concept model and the business model belong to a computation independence model layer, and the service model and the data model belong to a platform independence model layer;
a second obtaining module 300, configured to obtain a data type of the service model, and establish a conversion relationship from the service model to the data model according to the data type;
a second obtaining module 400, configured to convert, according to a target platform selected by a user from the determined platform-related model layers, the service model into a front-end model, a back-end model, and a process model corresponding to the target platform, and convert the data model into a database corresponding to the platform.
For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.
As shown in fig. 3, a computer device for driving domain demand modeling of open ecological cloud ERP of the present invention is shown, and specifically may include the following:
in an embodiment of the present invention, the present invention further provides a computer device, where the computer device 12 is represented in a general computing device, and the components of the computer device 12 may include but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including the system memory 28 and the processing unit 16.
The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)31 and/or cache memory 32. Computer device 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from and write to non-removable, nonvolatile magnetic media (commonly referred to as "hard drives"). Although not shown in FIG. 3, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 by one or more data media interfaces. The memory may include at least one program product having a set (e.g., at least one) of program modules 42, with the program modules 42 configured to carry out the functions of embodiments of the invention.
A program/utility 41 having a set (at least one) of program modules 42 may be stored, for example, in memory, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules 42, and program data, each of which examples or some combination thereof may comprise an implementation of a network environment. Program modules 42 generally carry out the functions and/or methodologies of the described embodiments of the invention.
The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, for example, to implement the field requirement modeling method for driving open ecological cloud ERP provided by the embodiment of the present invention.
In an embodiment of the present invention, the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a domain requirement modeling method for driving open ecological cloud ERP, as provided in all embodiments of the present application.
Any combination of one or more computer-readable media may be employed. The computer readable medium may be a computer-readable storage medium or a computer-readable signal medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPOM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Embodiments of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing terminal to cause a series of operational steps to be performed on the computer or other programmable terminal to produce a computer implemented process such that the instructions which execute on the computer or other programmable terminal provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the embodiments of the invention.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.
The field requirement modeling method and device for driving the open ecological cloud ERP provided by the invention are introduced in detail, a specific example is applied in the text to explain the principle and the implementation mode of the invention, and the description of the embodiment is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (10)
1. A field demand modeling method for driving open ecological cloud ERP is characterized by comprising the following steps:
acquiring basic terms of a conceptual model in a calculation independence model layer, and extracting a field and a theme matched with the basic terms from a field knowledge base of a same model layer;
according to the fields and the subjects, establishing bidirectional conversion relations from a concept model to a business model, from the business model to a service model and from the service model to a data model, wherein the concept model and the business model belong to a calculation independence model layer, and the service model and the data model belong to a platform independence model layer;
acquiring the data type of the business model, and establishing a conversion relation from the business model to the data model according to the data type;
and converting the service model to a front-end model, a rear-end model and a process model corresponding to the target platform according to the target platform in the platform-related model layers determined by the user selection, and converting the data model to a database corresponding to the platform.
2. The method of claim 1, wherein the converting the conceptual model into a business model further comprises:
acquiring coding information of the conceptual model and coding information of the business model;
and mapping the coding information of the conceptual model to the coding information of the business model.
3. The method of claim 1, wherein converting the service model to a front-end model, a back-end model, and a process model corresponding to the target platform according to a user selection of a target platform in the determined platform-related model layers, and converting the data model to a database corresponding to the platform comprises:
determining a business process in the service model after the business model is converted into the service model according to the basic terms and the specific definitions of the fields and the subjects;
and establishing a conversion relation from the service model to the process model according to the business process.
4. The method of claim 3, wherein the converting the service model to a front-end model, a back-end model, and a process model corresponding to the target platform and the data model to a database corresponding to the platform according to the target platform in the determined platform-related model layers selected by the user comprises:
acquiring a front-end service and a back-end service in a service model;
converting the back-end service into a back-end model in a platform correlation model layer, and extracting components from the database through the back-end model;
and acquiring a service object of the service model and a target service process corresponding to the service object, and binding a component corresponding to the service object with the service object according to the target service process.
5. The method of claim 3, wherein the process model includes a process definition, trigger conditions that must be met for the business process to proceed smoothly, input information, predecessor activities that are required to assemble a pre-process to complete the process, and successor activities that are required to assemble a successor process to complete the process, the process definition including a start rule that initializes a business process instance; defining a notification rule of a notification and receiving mode of information in the process of the business process; defining an execution rule of an execution mode of the business process; and defining the ending rule of the condition and the mode for ending the business process.
6. The method according to claim 1, wherein the obtaining the data type of the business model and establishing the conversion relationship from the business model to the data model according to the data type comprises:
acquiring coding information of a business model, and determining a basic term corresponding to the business model according to a conversion relation between the business model and the concept model;
determining a basic item of a corresponding data point in the data model according to the basic term, and determining the data type of the data point according to the definition of the basic item;
and mapping the coding information of the service model to the data points of the data model according to the data type.
7. The method of claim 1, further comprising: linking the concept model to an industrial ecology and service value chain layer, linking a business model to a solution layer, linking a service model to an application layer, and linking a data model to a cloud native layer.
8. A field demand modeling device for driving open ecological cloud ERP is characterized by comprising:
the first acquisition module is used for acquiring basic terms of the conceptual model in the computation independence model layer and extracting the fields and topics matched with the basic terms from the field knowledge base of the same model layer;
the first establishing module is used for establishing a bidirectional conversion relation from a concept model to a business model, from the business model to a service model and from the service model to a data model according to the fields and the subjects, wherein the concept model and the business model belong to a calculation independence model layer, and the service model and the data model belong to a platform independence model layer;
the second acquisition module is used for acquiring the data type of the business model and establishing a conversion relation from the business model to the data model according to the data type;
and the second acquisition module is used for converting the service model to a front-end model, a rear-end model and a process model corresponding to the target platform according to the target platform in the platform-related model layers determined by the user selection, and converting the data model to a database corresponding to the platform.
9. Electronic device, characterized in that it comprises a processor, a memory and a computer program stored on said memory and capable of running on said processor, said computer program, when executed by said processor, implementing the method according to any one of claims 1 to 7.
10. Computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, carries out the method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110455617.2A CN113190212B (en) | 2021-04-26 | Domain demand modeling method and device for driving open ecological cloud ERP |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110455617.2A CN113190212B (en) | 2021-04-26 | Domain demand modeling method and device for driving open ecological cloud ERP |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113190212A true CN113190212A (en) | 2021-07-30 |
| CN113190212B CN113190212B (en) | 2024-04-19 |
Family
ID=
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114445043A (en) * | 2022-01-26 | 2022-05-06 | 安徽大学 | Open ecological cloud ERP-based heterogeneous graph user demand accurate discovery method and system |
| CN114493516A (en) * | 2022-01-18 | 2022-05-13 | 安徽大学 | Heterogeneous graph comparison learning-based knowledge completion method and system under cloud ERP |
| CN114979251A (en) * | 2022-04-26 | 2022-08-30 | 东莞市海数云电子科技有限公司 | Cross-system cooperative service heterogeneous data exchange tool |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100077386A1 (en) * | 2008-09-22 | 2010-03-25 | International Business Machines Corporation | System and a method for cross-platform porting of business applications and making them contexually-aware on target platforms |
| CN103455325A (en) * | 2013-07-24 | 2013-12-18 | 北京起步科技有限公司 | Business-model-based architecture platform |
| CN109829660A (en) * | 2019-03-01 | 2019-05-31 | 国网上海市电力公司 | Data processing system and its design method based on electric power enterprise grade data model |
| US20200302350A1 (en) * | 2019-03-18 | 2020-09-24 | International Business Machines Corporation | Natural language processing based business domain modeling |
| CN111949643A (en) * | 2020-08-14 | 2020-11-17 | 中国工商银行股份有限公司 | Data processing method and system based on business modeling |
| CN112328239A (en) * | 2020-09-30 | 2021-02-05 | 合科软件（北京）有限责任公司 | CIM model definition method and device |
| CN112416336A (en) * | 2020-11-11 | 2021-02-26 | 北京京航计算通讯研究所 | Software architecture design method for aerospace embedded system |
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100077386A1 (en) * | 2008-09-22 | 2010-03-25 | International Business Machines Corporation | System and a method for cross-platform porting of business applications and making them contexually-aware on target platforms |
| CN103455325A (en) * | 2013-07-24 | 2013-12-18 | 北京起步科技有限公司 | Business-model-based architecture platform |
| CN109829660A (en) * | 2019-03-01 | 2019-05-31 | 国网上海市电力公司 | Data processing system and its design method based on electric power enterprise grade data model |
| US20200302350A1 (en) * | 2019-03-18 | 2020-09-24 | International Business Machines Corporation | Natural language processing based business domain modeling |
| CN111949643A (en) * | 2020-08-14 | 2020-11-17 | 中国工商银行股份有限公司 | Data processing method and system based on business modeling |
| CN112328239A (en) * | 2020-09-30 | 2021-02-05 | 合科软件（北京）有限责任公司 | CIM model definition method and device |
| CN112416336A (en) * | 2020-11-11 | 2021-02-26 | 北京京航计算通讯研究所 | Software architecture design method for aerospace embedded system |
Non-Patent Citations (5)
| Title |
|---|
| ADEDOTUN OLANREWAJU ADETUNLA: "Developing Manufacturing Execution Software as a Service for Small and Medium Size Enterprise", pages 1 - 69, Retrieved from the Internet <URL:《http://i-rep.emu.edu.tr:8080/xmlui/bitstream/handle/11129/2805/adetanladotun.pdf?sequence=1 》> * |
| M. ASIF RASHID等: "Smart factory: E-business perspective of enhanced ERP in aircraft manufacturing industry", 《2012 PROCEEDINGS OF PICMET \'12: TECHNOLOGY MANAGEMENT FOR EMERGING TECHNOLOGIES》, 17 September 2012 (2012-09-17), pages 1 - 14 * |
| 人人都是产品经理社: "从0到1，ERP体系的高阶模型", pages 1 - 15, Retrieved from the Internet <URL:《https://weibo.com/ttarticle/p/show?id=2310474293869268286097》> * |
| 金纪文, 金烨: "基于模型驱动和流程配置的ERP系统的关键技术研究", 计算机集成制造系统-CIMS, no. 07, 25 July 2005 (2005-07-25), pages 1 - 10 * |
| 魏栩弘: "基于计算无关模型企业ERP系统重构研究", 《中国优秀硕士学位论文全文数据库 信息科技辑》, 15 March 2019 (2019-03-15), pages 138 - 271 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114493516A (en) * | 2022-01-18 | 2022-05-13 | 安徽大学 | Heterogeneous graph comparison learning-based knowledge completion method and system under cloud ERP |
| CN114493516B (en) * | 2022-01-18 | 2022-12-23 | 安徽大学 | Heterogeneous graph comparison learning-based knowledge completion method and system under cloud ERP |
| CN114445043A (en) * | 2022-01-26 | 2022-05-06 | 安徽大学 | Open ecological cloud ERP-based heterogeneous graph user demand accurate discovery method and system |
| CN114979251A (en) * | 2022-04-26 | 2022-08-30 | 东莞市海数云电子科技有限公司 | Cross-system cooperative service heterogeneous data exchange tool |
| CN114979251B (en) * | 2022-04-26 | 2023-08-11 | 广东海术云电子科技有限公司 | Cross-system collaborative service heterogeneous data exchange system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Langley et al. | The platform political economy of FinTech: Reintermediation, consolidation and capitalisation | |
| Bezuidenhout et al. | Beyond the digital divide: Towards a situated approach to open data | |
| Graham et al. | Digital labour and development: impacts of global digital labour platforms and the gig economy on worker livelihoods | |
| Hedges et al. | Academic crowdsourcing in the humanities: Crowds, communities and co-production | |
| Irani | The cultural work of microwork | |
| Lattanze | Architecting software intensive systems: A practitioners guide | |
| Moore | Detribalizing the later prehistoric past: Concepts of tribes in Iron Age and Roman studies | |
| Barbosa et al. | Designing and evaluating interaction as conversation: a modeling language based on semiotic engineering | |
| Sweeney | Achieving service-oriented architecture: applying an enterprise architecture approach | |
| Kow et al. | Imaginaries and crystallization processes in bitcoin infrastructuring | |
| CN105027116A (en) | Flat book to rich book conversion in e-readers | |
| Lin | Transdisciplinarity and digital humanities: Lessons learned from developing text-mining tools for textual analysis | |
| Yan et al. | Hands-On Data Science with Anaconda: Utilize the right mix of tools to create high-performance data science applications | |
| EP4145273A1 (en) | Natural solution language | |
| Zohuri et al. | A Model to Forecast Future Paradigms: Volume 1: Introduction to Knowledge Is Power in Four Dimensions | |
| Ernst | A pattern-based approach to enterprise architecture management | |
| Cooke | Global innovation networks, territory and services innovation | |
| Soriano | Maximizing benefits from IT project management: from requirements to value delivery | |
| CN113190212B (en) | Domain demand modeling method and device for driving open ecological cloud ERP | |
| CN113190212A (en) | Domain demand modeling method and device for driving open ecological cloud ERP | |
| US20220207384A1 (en) | Extracting Facts from Unstructured Text | |
| Urquhart | Flow Architectures | |
| US9646083B2 (en) | Web 2.0 system and method for dynamic categorization of heterogeneous and regulated enterprise assets | |
| Croker | Formation of the cloud: History, metaphor, and materiality | |
| Wong et al. | The use of multiple methods in the Joint Irregular Warfare Analytic Baseline (JIWAB) study |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |