DSM domain definition modeling and MDA model-Driven Architecture Analysis

Domain-specific modelingandmodel Driven Architecture DSM (domain-defined modeling) and MDA (model-driven architecture)

Role of Model in software development

Today, the development of information systems is becoming more and more complex and involves more and more fields. Developers must master many different technologies, including popular object-oriented technologies, XML, and scripting languages, interface Definition Language, Process Definition Language, database definition and query, etc. A deep understanding of many architectures and protocols is required to transform the demands from the problem field into solutions. Furthermore, end users often expect the results to be highly efficient, easy-to-use, and scalable, and secure for unknown and unreliable network connections.

In some fields other than software development, such as electronic products (televisions, hifi audios, and cameras), we can see low costs and high reliability. Over the past few decades, the manufacturing industry has been adopting the process of creating a TV or car through a series of complex steps, many of which are completely automated.

We like to build software using the same principle. The difference is that we have not developed a software instruction language that allows effective separation of concerns in the software. Although we use differentProgramDevelopment language to write application logic to complete different development tasks. For example, XML is used to transmit data in application components, SQL is used to access data, and WSDL is used to describe the interfaces of components for Web applications, however, none of them directly address the business problems faced by end users.

The software architecture technology introduced in this article is the development of domain-specific languages (domain Definition Language (DSL.

DSL is designed to be directly oriented to the problem areas it wants to solve. To some extent, it can replace coding, data exchange, and configuration. We often call this type of language a modeling language. We use these languages to model problem domains.

Every element in the model is mapped to a concept in the real world. For many years, the model has been very important for defining how the IT system stores data. Currently, the model is more widely used, for example, business process modeling, service deployment, and data center. The model is popular because it can express problems well and avoid getting into technical details. When technology becomes more and more complex, models are an essential means to increase productivity. Another benefit of the model is that it allows programmers and experts in the problem field to use the same expression, which facilitates communication between team members. We can also regard the use of models as a way to bridge the gap between technology and business.

Over the past few years, new modeling methods have begun to merge, especially under the banner of MDA and the commitment to improving software development productivity and software portability, OMG has vigorously promoted UML and related technologies. However, we must see the results of the CASE tool in 1980s. Obviously, the case has been unable to fulfill its original promise and we are still very skeptical about the MDA, unless it can prove that it has found a new way for the problems we face, it will not repeat the mistakes of the CASE tool. In my opinion, only the combination of models, models, frameworks, and other technologies can avoid failures like CASE tools.

Domain-specific ages

If we want to use models to make it easier for domain experts to solve problems, the models must be able to clearly describe the problem domains. Modeling Language refers to the tag and link definition used for modeling in the problem domain. A typical, but not necessary, modeling language can be a set of diagrams, a group of nodes connected by lines, or flowcharts or object-relational graphs.

Models are often labeled and modified by text elements. developers need to carefully examine and understand the information that the models under these modifications actually need to express. Therefore, to be able to perform modeling, you must understand the details of each element. This means that once you become a professional modeling skill, you will be rewarded.

Some may think that the correct idea is that a general modeling language should be defined, used to model all problem domains, and experts in those domains should be taught to use this general modeling language. From the experience gained from UML, we will discuss UML later.

Now, we call domain-specific ages (Domain Modeling Language) the modeling language designed to model specific problem domains ). Domain Modeling languages can be created for many problem fields, such as communications, banking, and spatial surveys.

In any case, designing and using a Domain Modeling Language is only a small part of the model used to assist software development. The model can be analyzed, verified, converted, and deployed and executed in many steps. This process includes development, analysis, and validation model. In many different fields, the model is converted through tools until the system is deployed.

In the construction of software systems, a model is a framework, and the framework is applicable to the entire field.CodeThe Implementation Framework provides extensions for different elements in the same field among multiple systems. There are many examples of frameworks: the infrastructure from GUI to ERP andAlgorithm. In all cases, the role of the model is to use the framework to define the extension points for specific applications. At this level, we can consider that a modeling language is a defined extension point that fits into the framework to adapt to users' understanding of the problem.

Another important alternative is the pattern. A pattern is essentially a pattern with many small holes and a rule for filling these small holes with other models. There is an efficient mode of use: Use a large model composed of many small models, or a model assembled by other types of models.

The key to using models, models, frameworks, and code in the software development process is that the final result must be "agile. There must be no irreversible or non-continuity between the Code and the model. during the development process, the visible factors must be quickly reflected, and the final result will be re-generated after the changes. The case error is that the framework is not used for the problem domain, but a huge and irreversible code generation process is used, which makes it impossible for developers to modify the generated code and completely invalidates the entire method. Only by combining models, models, and frameworks and seamlessly integrating them into an agile development process can we avoid the defects of the case method.

The process of using models, models, and frameworks looks very similar in manufacturing as a whole. We can regard software development as a value chain concept: getting input from suppliers, use your professional experience to add value to these inputs and generate output at the end of the chain. So far, the construction process of software is rarely seen as such a chain, the root cause is the limitation of the way the software is expressed, when the Code becomes the only means to express the software, the only person closely related to the product is the programmer. The development of domain-defined models, models, and frameworks should be included in the software value chain, that is, the product line.

At Microsoft, we firmly believe that modeling will become more and more important for software development. We will integrate modeling functions in the forthcoming Visual Studio, we believe that the essence of designing domain-defined language based on the skills of target customers is that we need to give customers an intuitive, agile, efficient, and seamless modeling experience. The goal of our first modeling product is to immediately deliver high benefits to our customers. At the recent Microsoft Developer Conference, we presented a modeling tool that helped developers develop and deploy SOA. The details of this presentation can be found in http://msdn.microsoft.com/vstudio/enterprise.

Over time, we will continue to expand our modeling tools for more fields, such as code visualization and business modeling, tools supporting more fields will also be integrated into Visual Studio. A longer-term plan is to integrate the complete software development process through multiple product lines, including models, frameworks, models, and tools.

Model Driven Architecture

In the IT field, the term MDA generally refers to the use of models during software development. But in fact, OMG has registered this term as a trademark and extended it to a special concept of model-driven development using OMG modeling technology. The core of the modeling technology used is UML and MOF (meta-Object Facility). In this section, we will briefly discuss the MDA and then focus on the modeling technology included in the MDA, in particular, UML and MOF will also discuss methodologies related to the MDA.

The essence of MDA is to distinguish platform independentmodels (PIMS) from platform specific models (psms ). When developing an application using MDA, you must first create a PIM (platform-independent model), then use the standard ing to convert it to the SM (platform-defined model), and finally generate the final program code by ing, follow the OMG's mda faq: Release ." In this way, the application is defined as platform-independent, so that the application can be transplanted. This makes it easy to recall the so-called "write once run anywhere" in Java and try to build a platform-independent framework, such as the swing UI library, the compromise between performance and platform integration must be made. In the past, this compromise was the root cause of many product failures, and the industry still had doubts about the MDA declaration, the session of MDA on oopsla 2003 is evidence.

However, the exploration of MDA is helpful in some applications. Some vendors have already presented us with J2EE-based web applications and created UML models that contain data entities and components, then Map to various J2EE applications. However, in any case, as mentioned above, this means that developers are fully switched to agile development without causing unnecessary changes and obstacles, for example, irreversible code generation and debugging problems.

It is very difficult to extend MDA to other fields. The concept of "platform" defined by OMG is vague. The real example is J2EE. It is effective and useful to use a model to create a J2EE application during software development. In fact, there are almost no ing standards between platform-independent models and platform-dependent models. The only one currently exists is for the Java platform. Although there are many non-standard, developmentCommunityThe implementation claims to support other platforms.

All in all, MDA has an incorrect name. Instead of an architecture, it is based on abstract model-driven development standards for similar platforms. When promoting MDA to the industry, OMG did not adopt the advice on integrating and models, frameworks, models, and tools to support the software product line, and we will see that, the UML and MOF protocols based on MDA will limit its usage.
The uniied modelinglanguage

UML is a general modeling language developed in the early 1990s S. It was combined by Grady booch, jamesrumbaugh, and Ivar jacbson into a unified graphical representation. The first standardization was completed in 1997 and has been revised several times. A second version is being developed recently.

UML is huge and difficult to understand, especially version 2. to gain a deeper understanding of UML, you must first understand how it is used. We use Martin flower to classify UML in UML Distilled. marting divides usage of UML into: Used as a sketch, used as a blueprint, and used as a programming language.

It is very popular to use UML as a sketch. Many projects use UML to draw a sketch on the whiteboard. Another implication of using UML as a sketch is that it is inappropriate to try to generate a structured document from the object-oriented design. In this case, UML is very successful, and it completely achieves the goal of eliminating the inconsistency between object-oriented design and graphic representation.

The use of UML as blueprint raises the threshold. At this time, the goal is to combine multiple UML models during the development process. For any changes and automation, the UML model is converted to the SystemSource codeThis means that the UML model must contain sufficient information to ensure that the conversion is effective and complete.

When we try to do this, we will soon find the problem of UML, because it cannot be directly converted to the technology we use, for example: a uml class cannot be used directly to describe a C # class, because the UML class cannot describe the attribute concept in C. Similarly, a UML interface cannot be used directly to describe a Java interface, because UML does not include the concept of static fields in Java. From this point of view, when using UML as a sketch, there is no problem, but when UML is used to develop a product of a class, it either violates the standard, or introduce some discord factors to fix these mismatched issues.

Some communities support UML as a programming language, but they do not like to be commercialized. We will not discuss it here.

Let's take a look at the main usage of these UML: As a sketch and blueprint. It is very useful to express the standards as a set of flexible and scalable illustrations and seamlessly map them to the technologies used by development without any mismatched descriptions. Most developers will receive seamless and reversible ing from the concepts described in the model. The UML profile allows for limited language extensions to make the blueprint scalable. However, practice has proved that this scalability is very limited, and it cannot provide seamless ing of popular technologies from UML.

At Microsoft, our approach is to use our modeling tools to express concepts using some easily recognizable extended notation. At the same time, we found that the UML representation is not clear enough, and we have supplemented it, for example, we make.. Net class visualization, which can contain more information and make it easier to use, and make the graphic element more accurate. This ensures that the terms and concepts in. Net can be clearly expressed in illustration. The feedback we get from customers is overwhelming support for this practice. Although our illustration method is not a standard UML, its meaning is very easy for anyone to understand.

In areas not specific to UML, we must create new conventions. For example, the designer supports developing logical data center models which are used to deploy distributed systems, here we can use the concepts not supported or supported in UML, And we can create a protocol for these fields. Domain definition language is used to develop new fields not supported by UML. We can expect to merge these protocols into these fields.

We may find that a modeling language may be generated after a large number of extensions to uml2.0. SDL (specification and Description Language, definition and interpretation language) is widely used in the field of communication technology. We look forward to seeing the UML illustration conventions and extensions in areas not covered by UML.

Defining languages ages andinterchanging Models

There is another important technology under the OMG's MDA flag: MOF. MOF is a technology that is more abstract and hard to understand than UML. I have understood more difficult terms, such as metamodel and meta-metamodel. Thanks for the absence of meta-model, we will also try our best to prevent this.

MOF mainly works in two ways. First, it is a domain-defined modeling language designed to define modeling languages: a mof model is the definition of an MDA modeling language. Second, it is a mechanism for calculating how an MDA model is serialized to an XML document or Java API.

A Domain Modeling Language involves many aspects. It must define concepts in a domain, represent concepts as graphs or texts, define how users interact with languages, and define whether a model is legal, you must define how models interact. However, MOF only defines the basic concepts of language and how the conceptual model is stored and interacted. MOF of a language does not provide many things that users really care about: what the language model contains, what it looks like, and how users interact with the model.

At Microsoft, we hope our language can be integrated into Visual Studio, including intelliisense ?, Toolbar, menu, attribute bar, and support for debug, we found that defining how to model concepts is only a secondary aspect in the entire work, in addition, our language definition tools must be integrated into Visual Studio, which is better than MOF.

In fact, although this is the common position of language definition technology, MOF is still a storage concept model and uses XMI (XML Metadata Interchange) the main technology used to convert a model to a Java API. If you use MOF to define the concept of a language, you can use XMI to automatically generate a language based on XML.

From this perspective, this seems quite attractive, but there are still some problems. First, XML generation is based on language definitions, which means that XMI serialization using the uml1.4 standard cannot be understood by the Implementation Based on uml2.0, unless your opinions on these concepts are consistent. In addition, XMI itself is changing, that is, there may be different versions of XMI serialization for the same model. Third, the definition of MOF is also changing. It will add new elements to deal with different combinations, which will lead to different orientations of MOF versions and will not be completely consistent. Therefore, although XMI claims to provide interoperability for modeling tools, the actual situation is that unless each tool supports all possible combinations under the MOF, XMI, and UML standards, there is no problem with the interaction between tools. The deeper problem with XMI is that, especially for older versions, the XML architecture generated by machines is often lengthy and hard to read, which forces developers to seek a higher degree of visualization, convertible technologies to maintain XML documents.

We do not think that XMI is the correct method for model serialization. XML is becoming more mature and there are a lot of models and tools in the market. We believe that the correct method is to have its own specific XML architecture for a specific modeling language, and provide tools to manage how to automatically interpret and map between languages and serialization formats. If you standardize a specific field, the XML architecture can be standard, which is widely used in the industry. Then, if the language definition develops, it can be expanded and transplanted in the old XML architecture. XMI effectively blocks the development of this clear idea and leads to a large number of incompatible XML architecture standards, which completely deviates from its interoperability purpose.

In short, Microsoft does not support MOF for the following reasons:

1. It is not a stable Standard

2. Using it as a language for designing our tools will produce undesirable results.

3. Support for commercial implementation of elements not provided by MoF. We will continue to introduce MOF definition changes.

4. MOF has not achieved its goal.

Conclusion

This article discusses the role of the model in software development, especially the definition and use of domain-specific languages, as well as the use of the model in the product line. At the same time, it gives an overall evaluation of the omg mda. We are confident that the model will be used more in agile software development, and we are building tools and technologies to support such development. We can see that UML is an important step. Its future is based on illustrated developers' conventions, and it can be used as an inspiration for domain definition languages in specific problem fields. We also see that XML is a key technology for model performance and interaction. We hope that the standardization of domain content can begin as soon as possible.

From: http://www.enet.com.cn/article/2006/1227/A20061227362775_2.shtml