Pattern-driven design and development in xde (III)

Part 3: Advanced topic in xde

In the previous section, we introduced in detail how to use xde. However, there are many concepts about xde, some of which are straightforward, but some are relatively vague. In this section, we will give a preliminary explanation of some advanced concepts in xde and give some small examples. We hope to help you learn more about xde and the pattern-driven development methods promoted by xde. If you have not read the previous readers, it is better to look at the content of the first phase. It may be difficult to understand it.

　1. Code Template)

Mode, or design mode, is largely a description of the object structure. That is to say, the final implementation of the pattern and the generated code are also of the framework nature-only the definition of classes, attributes or methods, reference between classes, inheritance, and other code, code in a specific method is often powerless. This is also a part that most of the forward engineering tools lack.

In fact, if only some simple semantics, such as object creation and call of fixed methods, do not involve complex interactions, we can also generate specific code from the semantics of the model. In xde, code templates are used to generate parameterized code for some simple methods.

Like the pattern, the code template can also have parameters and replace and bind them when they are generated. Two types of parameters can be used in the Code Template: strings and model elements.

Strings: A simple string. When the code is generated, xde replaces all these string parameters with specific strings.

MODEL elements: a model element. Xde provides a simple programming model. You can call the Model Element API (for example, get all public methods of a class) to complete complicated bit code customization. When it is associated with the mode, the parameters of the model elements type can be a template parameter in the mode. When the mode is expanded, the parameters in the code template are replaced with the specific template parameter values.

The form of xde code template is similar to that used in JSP or ASP. If you are familiar with the JSP mechanism, you can easily understand the code template mechanism.

In a code template, the code is divided into two parts, one of which is directly output without any processing. The other part is the script content between the two labels <% and %>, Which is output after processing parameters or other elements. Like JSP or ASP, it uses simple <% = var %> to output variables (VaR is a variable ). All content between <% and %> is written in script language. Currently, the Code templates in xde only support the Javascript language.

The example of the following code template is selected from the xde online document to print the current state of the object during debugging. Every method that applies this code template will output the object status on the console before calling the method for debugging.

Part 3: Advanced topic in xde In the previous section, we introduced in detail how to use xde. However, there are many concepts about xde, some of which are straightforward, but some are relatively vague. In this section, we will give a preliminary explanation of some advanced concepts in xde and give some small examples. We hope to help you learn more about xde and the pattern-driven development methods promoted by xde. If you have not read the previous readers, it is better to look at the content of the first phase. It may be difficult to understand it. 　1. Code Template) Mode, or design mode, is largely a description of the object structure. That is to say, the final implementation of the pattern and the generated code are also of the framework nature-only the definition of classes, attributes or methods, reference between classes, inheritance, and other code, code in a specific method is often powerless. This is also a part that most of the forward engineering tools lack. In fact, if only some simple semantics, such as object creation and call of fixed methods, do not involve complex interactions, we can also generate specific code from the semantics of the model. In xde, code templates are used to generate parameterized code for some simple methods. Like the pattern, the code template can also have parameters and replace and bind them when they are generated. Two types of parameters can be used in the Code Template: strings and model elements. Strings: A simple string. When the code is generated, xde replaces all these string parameters with specific strings. MODEL elements: a model element. Xde provides a simple programming model. You can call the Model Element API (for example, get all public methods of a class) to complete complicated bit code customization. When it is associated with the mode, the parameters of the model elements type can be a template parameter in the mode. When the mode is expanded, the parameters in the code template are replaced with the specific template parameter values. The form of xde code template is similar to that used in JSP or ASP. If you are familiar with the JSP mechanism, you can easily understand the code template mechanism. In a code template, the code is divided into two parts, one of which is directly output without any processing. The other part is the script content between the two labels <% and %>, Which is output after processing parameters or other elements. Like JSP or ASP, it uses simple <% = var %> to output variables (VaR is a variable ). All content between <% and %> is written in script language. Currently, the Code templates in xde only support the Javascript language. The example of the following code template is selected from the xde online document to print the current state of the object during debugging. Every method that applies this code template will output the object status on the console before calling the method for debugging. <% // Assume: myclass is "this" class with debug operation Function debugstatements (myclass ){ VaR attributecollection = myclass. getattributecollection (); VaR attributecollection1 = interfaces. QueryInterface (attributecollection, "com. Rational. RMS. irmselementcollection "); VaR attributecount = attributecollection. getcount (); Debugstatements = ""; For (I = 1; I <= attributecount; I ++ ){ VaR rmsattribute = attributecollection1.getelementat (I ); VaR attrname = rmsattribute. getname (); %> System. Out. println ("<% = attrname %> "); <% } } // Assume: myoperation is debug operation Function debugoperation (myoperation ){ VaR thisoperation = interfaces. QueryInterface (myoperation, "com. Rational. uml70.iumloperation "); VaR thisclass = thisoperation. getcontainer (); VaR myclass = interfaces. QueryInterface (thisclass, "com. Rational. uml70.iumlclass "); Debugstatements (myclass ); } VaR myoperation = interfaces. QueryInterface (thiselement, "com. Rational. uml70.iumloperation "); Debugoperation (myoperation ); // End %> In the code template above, two methods are defined: debugstatements and debugoperation. debugoperation accepts the current element as the parameter and obtains the debugstatements parameter-an object containing this method, and output in debugstatements: system. out. println ("<% = attrname %> "); To output the object status in the console. In the code template, a standard pre-defined variable of "thiselement" can be used to represent the elements applied to the code template. In the xde of the current version, you can only apply code templates to methods in the class. Of course, the biggest role of a code template is to use the template parameters in the same mode. The simplest example is that if I create two template parameters, TP1 and TP2, they represent two classes. I need to create an object of the class that TP2 represents in the TP1 method OP1 () and assign it to a reference of the TP2 type. We can define a codetp parameter for the code template. The type is string and the value is <% = TP2 %>. In the Code Template created for OP1 (), we can write as follows: <% = Codetp %> A <% = codetp %> Object = new <% = codetp %> (); Assume that TP2 is finally bound to a class named classtp. After the code template is expanded, the result is: Classtp aclasstpobject = new classtpobject (); This completes the functions we want. This is just the simplest feature. In fact, the Code templates in xde are very powerful. Through the Javascript scripting language and the xde built-in programming model, we can create very complex code templates, greatly improving the code generation rate. 　　2. Mode small script (scriptlets) The script is an executable code snippet. In fact, we have come into contact with this small script in the introduction to the code template. <% = Var %> is a simple small script. A small script can be used not only in code templates, but also in other places of the model, such as classes, attributes, or method names, element attribute values, and model document annotations, the name of the associated endpoint, and so on. Small scripts can be used almost anywhere strings can be used. The syntax of this small script is very simple: <% = scriptlet text %>. You can also add other program fragments between the <% and %> flag using the Javascript script language. The script is run when the mode is expanded and replaced by a running result string. The most common usage is to dynamically replace the name of a template parameter. For example, if a template parameter named TP1 is defined in the mode, the small script <% = TP1 %> is replaced with the name of the parameter value bound to TP1 when the mode is expanded. If TP1 is bound to a class named tpclass, all the final <% = TP1 %> values are replaced with tpclass. For example, we can use this small script in the document of this class: Name Length: <% = tp1.getname (). Length () %> Name substring: <% = tp1.getname (). substring (0, tp1.getname (). Length ()-1) %> In this way, the final document is complete. The specific APIs used in the script have not yet been published in rational, but you can use the following tips to get an API for model elements. First define a function Function show_props (OBJ, obj_name ){ VaR result = ""; For (var I in OBJ ){ Eaeventdata. addoutputmessage (obj_name + "." + I + "=" + OBJ [I]); } } Then call it: Show_props (TP1, "TP1 "); In this way, the script can output the APIs that can be used for a given model element in the xde output window. 　　3. value source and value set When creating a parameter, you can specify a value source for this parameter to specify the input method accepted by this parameter. There are three methods: · User: default value. After this parameter input method is selected, it means that in application mode, you must select a type-consistent element from the existing model as the value passed to this parameter. · Generated: This value means that the parameter value will be automatically created in application mode. You only need to provide a string as the name of the generated parameter value. · Collection: generates a value or value set from a given element to assign values to the target parameter. The given element, called the collection host element, can be any model element. After specifying the name of the host element, you can create a filter for it to select the content to be derived from, that is, collection. In a simple example, you can select all the public attributes of a class as a collection, and then pass these attribute values to the target parameter. These methods can be used independently or in combination to provide users with multiple options. Xde provides a value set mechanism for some types of template parameters to limit the values of template parameters. For example, you can provide a value set for the integer type template parameter. In the application mode, the value of this template parameter can only be selected from the given set. In some cases, this technique is useful and can constrain the user's value range without any illegal results. 　　4. Create optional elements with Constraints Xde allows you to create an optional element through constraints. Whether this element is generated when the mode is expanded depends on the value of the given constraint: if the value of the constraint is true, it will be generated; otherwise, it will not be generated. This constraint can be applied to any element in the model. The constraints usually depend on the value of an element attribute. For example, determine whether the visibility of a class is public or not. You can also use and, or, not to join a single attribute judgment to construct more complex constraints. For example, the following expression: Model1: package2: class1.visibility = "public" A constraint is used to determine whether the visibility (public, private, protected, or package) of model1: package2: class1 is public. If yes, the return value of the constraint expression is true. Otherwise, the return value is false. If model1: package2: class1 does not exist, the expression indicates that an error exists. There are two constraints in the xde mode definition: 1. Property constraints: constraints on the meta-model attributes of model elements. The preceding example shows the property constraints. 2. Relationship constraints: used to determine the specific relationship between model elements. For example, the inheritance relationship between two classes, the implementation relationship between classes and interfaces, and so on. You don't need to remember what attributes exist in a certain type of metadatabase, and what methods are available between two classes. In xde, there is a constraint editor to help you build constraints, all work can be selected with the mouse. 　　5. callouts Mode callouts are used to respond to some events, such as before the application mode or after the application mode, which correspond to the preapply and postapply callouts respectively. When these events occur, the scripts defined in the corresponding callout are called. Not all models need to use callouts. It is only used to deal with problems that are difficult to solve with general mode mechanisms. Callouts can be defined on the mode or template parameters. For example:

When creating a callout, JavaScript is usually used for some processing. In xde, there is a global eaeventdata object that provides programming interfaces for the pattern engine and other parts of xde. However, we have not yet learned the details about it because the documents are incomplete and it is estimated that it will be disclosed in future xde versions. A simple example is as follows:

Eaeventdata. addoutputmessage ("Test message ");

The addoutputmessage method of the eaeventdata object can add a line of string data in the output view.

Because callouts provides an excuse for the mode engine and xde, in theory, it can complete the functions that any Mode engine can accomplish. Therefore, it is very powerful. However, we should try to avoid using it because it is too complex and the specific interfaces have not been standardized. Before using callouts, you should first look for other places set in the mode to see if it has been implemented.

　　6. A combination of modes

In many cases, the mode is not used independently. For example, when using the abstract factory mode, we often need to define the abstract factory as a single piece and only allow instances of an abstract factory to exist. In this way, we need to use another creation mode: Singleton ). There are many examples of such a combination of modes. In xde, a simple method is to apply the abstract factory mode once and then the single-piece mode once Based on the expanded mode. But xde also provides a more powerful and complex method: combining patterns together to create a new pattern-let's call it the factory single-piece pattern in the above example. In this way, we only use this application mode once to achieve good results.

This implementation is not difficult in xde. You only need to introduce a defined pattern when defining the schema. For example, when defining the abstract factory model, assume that all the participants and template parameters of the abstract factory have been established. To introduce the single-piece mode, you only need to simply select in the context menu, just as in general, the application mode is the same, specify concretefactory in the abstract factory as the parameter value of the singleton template parameter in single-piece mode, and then apply the single-piece mode. This combination of models provides a solution for larger and more complex problems.

　　Summary

Rational xde is indeed a very powerful feature. This article discusses in detail its topic in pattern modeling and application, basically involving all aspects of the pattern in xde. I believe that you should have a clear understanding of the concept of xde-based development. In fact, the features of the mode are only a small part of xde, and many other features are also very powerful, such as forward/reverse engineering.

However, at this stage, xde can only be called a very promising product, but it cannot be called a mature product. On the one hand, the development model and development method it advocates are not very popular, on the other hand, there are many bugs in the product itself, and there are few references. When we use xde for development, although we are impressed by its powerful performance, there are always some minor issues that are annoying. However, xde is constantly improving, and I believe its next eclipse2.0-based version will be even better.

References:

1. UML reference manual Mechanical Industry Press
2. UML User Guide Mechanical Industry Press
3. Mechanical Industry Press: design patterns: the basis for reusable Object-Oriented Software
4. Rational xde online documentation, which provides most of the introduction to xde.
5. rational.net developer Website: www.rational.net. There are many detailed documents on xde Functions