Design and development of Mode drive in Xde (II.)

Part II: The mode mechanism in XDE

1 overview

In the previous installment of the series, we gave a brief, theoretical introduction to patterns, particularly the modeling methods in UML. Now it's time to practice. There are not many tools that now support schema modeling and the ability to develop applications based on patterns. Rational Xde is one of the most famous, and it does provide a very good feature.

There are two versions of the Java version of Xde, one based on the Eclipse kernel's stand-alone version (currently supports only Eclipse1.0). The other one is integrated in WASD, as a WASD plug-in runs with it (currently supports only WASD 4.0). In fact WASD is using Eclipse's kernel, so there's not much difference in functionality (and even appearance). Now that the rational has been merged by IBM, there is enough reason to believe that the XDE function will be more perfectly integrated into the future Wsad.

XDE's biggest selling point is two, one is analysis design with code written in the same IDE, and can do forward-reverse engineering, the perfect implementation of iterative development of the required model-code mapping. The other is the subject of this article: the definition and application of patterns. Not only can you use the 23 classic Gof design patterns that are predefined in Xde, you can also define your own patterns, apply them in development, or export them for others to use.

The pattern mechanism is the core technology to realize reuse in XDE. You can use this mechanism to implement the reuse of model elements and other artifacts. It provides Model-to-model and Model-to-code transform functions. This allows you to use a model involved to help a particular design. It still has to be able to merge the elements of a pattern into the existing design model.

Description of patterns in 2 Xde

In Xde, the description of the pattern basically follows the parameterized collaboration standard defined by UML. However, since UML defines only how schemas are modeled, there is not much involved in how to define patterns, apply patterns, and specific code generation. Therefore, XDE has made some reasonable extensions on the basis of UML.

First, let's look at the concept of asset. A asset is a collection of software artifacts that are organized in order to solve a problem. Asset can be extended through its defined variable points (variability point), when asset reuse, developers need to provide specific content for these variable points to enrich the asset to complete asset reuse.

Rational now advocates a asset Based development process approach as a complement to RUP, asset is its key. There is no intention to asset and asset Based development too much, which has deviated from the subject of this article. In terms of patterns, you can simply think of asset as the definition, description and implementation of a pattern.

In Xde, Asset is represented as a package with a stereotype of >. Packages declared as > can be exported to facilitate reuse among different developers and even different tools, as long as they follow the ASSET specification reusable Asset specification.

A pattern is a asset, but asset is not necessarily a pattern. A model can be packaged in a asset without any pattern description. Xde can handle both of these reusable projects. In Xde, the pattern is represented as a collaboration diagram with template parameters in a > package. There are a number of ways to create a > package, but it should be noted that creating a UML package and manually setting its version to? does not register the package as a pattern.

In Xde, the > package can be exported as a. ras file. A. ras file is actually a zip file, but it has its own content structure, which is similar to the. war file in Java EE. It uses the Rasset.xml and resource.xml two XML files to provide a description of this compressed document. The rasasset.xsd file is a RAS XML Schema that defines the content format and meaning of both rasset.xml and resource.xml documents. Other files are model and document artifacts.