Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to interpret the application model management based on MOF". In the daily operation, I believe that many people have doubts about how to interpret the application model management based on MOF. The editor has consulted all kinds of materials and sorted out the simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to interpret the application model management based on MOF". Next, please follow the editor to study!

Abstract: in order to break down the barrier between technology and business and build the bridge between technology and business, the application business model management ROMA ABM is realized based on the following process.

In the era of digital economy, data is becoming an extremely important strategic asset for enterprises. On the government side, for the first time, as a new factor of production, data is listed as the "fifth factor" comparable to land, labor, capital and technology. As the data increases, it becomes more and more difficult to figure out the specific meaning behind the data, causing some of the following problems:

It is difficult to find information in the era of big data, the amount of government and enterprise data is growing explosively, and it is not satisfactory to find data quickly and accurately in the mass of information.

There are differences in understanding inconsistent business understanding, which makes IT out of touch with the business into "two skins", resulting in a lot of repetitive work and even affecting business decisions.

High learning cost employees have a certain degree of mobility, such as the lack of business management methods, for new employees need to spend a lot of time and cost to do training, resulting in serious knowledge loss and money consumption.

For the above problems, build a set of perfect asset management methods by using business model to break through the semantic barrier and operation management to drive high-quality development.

In order to break down the barrier between technology and business and build a bridge between technology and business, the application business model management ROMA ABM (Application Business Model) is implemented based on the following process.

The key processes are explained and interpreted as follows to facilitate better understanding:

1. Model standard

First explain what model, the model is to describe the data, also collectively referred to as metadata, such as the book catalog (author, ISBN, price, etc.), simply corresponding to the physical table fields, API input and output, and so on.

The industry OMG specification organization has a specific definition of the model, and the model term M1 layer is included in the MOF 2.5 specification.

M3 is a metamodel used to define a metamodel, providing the basic model to quickly assemble a metamodel package, such as defining the domains, classes, attributes, relationships, etc. required by the metamodel.

M2 is a metamodel, an instance of M3, and a specification of the model. Specifically, it describes the relationship between the elements and the elements that make up the model, such as the relational database metamodel, from the library to the table, instance, table, field, index.

M1 is a model, which is the data used to describe the data, such as the catalog information of a book (author, ISBN, price, etc.), which generally corresponds to the table fields of the physical table, the fields of the API response, etc.

M0 is the object based on this model, that is, the data in the physical world, which generally corresponds to the data in the physical table.

two。 Model classification

ROMA ABM defines the classification methods recognized by the industry, which are mainly divided into two categories: technical model and business model.

The technical model includes: field name, field length, database table structure, API description, message description, file description and so on. The technical model usually collects the model through automated tasks, and it can also be acquired by other ways such as file import. The following are examples of relational databases and microservice model packages for reference.

Business model includes business name, business definition, business description, security policy and other business attributes that can be understood by other users. Users can quickly locate the data model they want to obtain according to their own business line or domain. The following is a sample package of the business model for reference.

3. Model design

Through ROMA ABM's metamodel visualization configuration ability, the metamodel can be designed quickly. The metamodel design reflects the designer's understanding of the whole business system, and the data classification sorted out from the business perspective, which can be called the business model, makes the whole organization unify the data language, and is the key element to open up the business flow, eliminate the isolated island of information and improve the efficiency of business flow integration. Before designing the business model, you need to sort out the organization's business end-to-end, such as business scope, business process, business occurrence subject, business event, etc., and then summarize the above content. Design a business model (metamodel) that is unique to your organization. Here, taking the scenario of Smart City as an example, sort out and summarize the business model of digital government:

The M2 metamodel configuration and attribute configuration of the digital government business model are completed through the ROMA ABM visual metamodel configuration capability. in order to help you better understand the design of the metamodel, M2 and M3 layers are described in detail through the digital government business model. M3 layer provides general metamodel design elements for M2 layer modeling. Specific references are as follows:

The design structure of the M3 layer is shown below:

The M2 layer design structure is shown below:

In addition to abstracting the business lines, the M2 layer also defines business attributes to help users obtain the business additional attributes that the underlying structures such as database tables and API depend on. These types of content cannot be obtained through the underlying system, and which attributes need to be added need to be combed by data managers in combination with business scenarios. The following are the general attributes provided in the digital government business model package for reference.

Through the above digital government business model, it is not difficult to find that the core competence of model management is to gradually decompose from abstraction to implementation. The relationship of M0, M1, M2, M3 objects in the real system can be summarized as follows:

M1 is the M0 layer abstraction, M0 represents the actual stored data, M1 represents the structure needed to store this set of data, usually corresponds to the business system is a set of table structure, a set of API, a set of files, and so on.

M2 is the abstraction of M1 layer. M2 represents the storage model of M1 table structure, API, file and so on. M2 layer is a metamodel, but M2 is also data, so the metamodel also needs a unified storage structure and scalability.

M3 is the abstraction of M2 layer. M3 represents the abstraction of M2. It is universal and similar to design tools, it can design all kinds of metamodels.

4. Model association

Through the above design, the design and configuration of the business model and the technical model are completed, but there is no relationship between the two models at this time, so we need to associate the business model with the technical model and let the technical language move towards the business language. it is very important to provide fast, stable and diverse relationships through tools.

In the whole MOF framework, M3-metamodel is the core of the whole model management, so how to construct the model collection framework of "configurability + diversity + stability" is very important. We can refer to the following principles:

M3 metamodel ability graphics component, by dragging and dropping to complete the construction of the metamodel package

Multiple sets of acquisition adapters under the same type of metamodel share "one set of programs" to collect and analyze models and relationships in various media, especially for diversified collection of technical models. The following is the adaptation sample diagram of the relational database:

Cross-package association is supported in the process of metamodel package design, that is, the current metamodel can have dependencies with other metamodels, and cross-package association can be realized automatically after model collection is completed.

Based on the above principles, the following model acquisition process is formed:

After dealing with the above steps, all the unreadable tables, fields, API and other information are transformed into models with business semantics, making it easier and more efficient for each department, system and developer to find the number of users, and completely realize the reversal from the technical model to the business model.

5. Model ecology

Application Business Model Management (ROMA ABM), as the carrier of metamodel-driven development, forms a good ecological cycle with surrounding systems or partners:

Automatically extract the technical models such as database tables, API and files in the inventory system, through the visual metamodel designer, so that all technical models can be stored uniformly according to the business domain, so that developers or users do not need to care about the actual details and shield the differences of the underlying system.

Through model twisting, the technical model is automatically associated with the business model, so that the underlying database tables, API and other incomprehensible data models have business semantics, and at the same time, all the underlying data models return to their own business scope, so that developers or users who understand the business can use their familiar business language to find the data model.

The third-party application or system can obtain the technical model and business model through a unified interface, and further complete the consumption of the model. After the third-party application or system generates a new model through composition and choreography based on the existing stock model, it gives back to the application business model management service, so that all models flow in the whole system like blood, and finally form a complete model ecology.

At this point, the study on "how to interpret MOF-based application model management" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.