Part III: Advanced Topics in XDE In the previous part, we introduce XDE's way of use, but there are many concepts about models in XDE, and some are very straightforward, and some of them are more comparable. The content of this part will be preliminaryly explained to some of the advanced concepts in XDE and give some small examples. I hope to help you have more, more in-depth understanding of the XDE itself, and the model driver advocated by XDE. If you haven't seen the readers in the previous period, it is best to find a look, directly look at the first period, understands that there may be some difficulties.
1. Code template (Code Template)
Mode, or design mode, to a large extent, a description of the object structure. That is to say, mode ultimate implementation and generated code, most of which belong to the frame nature - only class, attributes, definitions, references between classes, inheritance, etc., for specific The code in the method, it is often in powerless. This is also a part that most of the forward engineering tools are lacking.
In fact, if it is just some simple semantics, such as the creation of the object, the fixed method is called without complex interaction, we also generate specific code from the semantics of the model. In XDE, pass the code template to complete the parameterized code generation of some simple methods.
As with the mode, the code template can also have parameters and replace it when specifically generated. In the code template, two types of parameters can be used: Strings and Model Elements.
Strings: Simple strings, XDE will replace all of these strings parameters with specific strings when the code is generated.
Model Elements: A model element. A simple programming model is provided in XDE, which can be customized by completing complex code customization by calling the model element API (such as all public methods to get a class). When you link together, the parameters of the Model Elements type can be a template parameter in the mode. When the mode is expanded, the specific template parameter value is replaced with the parameters in this code template.
The XDE code template is in the form of a form in JSP or ASP. If you understand the JSP mechanism, then you can easily understand the mechanism of code template.
In one code template, the code is divided into two parts, and a portion is direct output, no processing. Another part is the scripting content between <% and%> The two labels, and outputs it after the processing of parameters or other elements. If JSP or ASP is the same, it is also the output of variables with simple <% = var%> (VAR is a variable). The content between all <% and%> is written in scripting languages. The code template in XDE is now only supports JavaScript language.
An example of one of the code templates below is selected from the XDE's online document to print the current state of the object when debugging. Each method for applying this code template will output an object in the console before the call method is used for debugging.
Part III: Advanced Topics in XDE In the previous part, we introduce XDE's way of use, but there are many concepts about models in XDE, and some are very straightforward, and some of them are more comparable. The content of this part will be preliminaryly explained to some of the advanced concepts in XDE and give some small examples. I hope to help you have more, more in-depth understanding of the XDE itself, and the model driver advocated by XDE. If you haven't seen the readers in the previous period, it is best to find a look, directly look at the first period, understands that there may be some difficulties. 1. Code Template mode, or design mode, to a large extent, a description of the object structure. That is to say, mode ultimate implementation and generated code, most of which belong to the frame nature - only class, attributes, definitions, references between classes, inheritance, etc., for specific The code in the method, it is often in powerless. This is also a part that most of the forward engineering tools are lacking. In fact, if it is just some simple semantics, such as the creation of the object, the fixed method is called without complex interaction, we also generate specific code from the semantics of the model. In XDE, pass the code template to complete the parameterized code generation of some simple methods. As with the mode, the code template can also have parameters and replace it when specifically generated. In the code template, two types of parameters can be used: Strings and Model Elements. Strings: Simple strings, XDE will replace all of these strings parameters with specific strings when the code is generated. Model Elements: A model element. A simple programming model is provided in XDE, which can be customized by completing complex code customization by calling the model element API (such as all public methods to get a class). When you link together, the parameters of the Model Elements type can be a template parameter in the mode. When the mode is expanded, the specific template parameter value is replaced with the parameters in this code template. The XDE code template is in the form of a form in JSP or ASP. If you understand the JSP mechanism, then you can easily understand the mechanism of code template. In one code template, the code is divided into two parts, and a portion is direct output, no processing. Another part is the scripting content between <% and%> The two labels, and outputs it after the processing of parameters or other elements. If JSP or ASP is the same, it is also the output of variables with simple <% = var%> (VAR is a variable). The content between all <% and%> is written in scripting languages. The code template in XDE is now only supports JavaScript language. An example of one of the code templates below is selected from the XDE's online document to print the current state of the object when debugging. Each method for applying this code template will output an object in the console before the call method is used for debugging.
<% // assume: myClass is "this" Class with debug operationfunction 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 operationfunction 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.iumloperty "); debugopance (myoperty); // end%> In the above code template, two methods DebugStatemen are defined TS and DEBUGOPERATION, DEBUGOPERATION accept the current element as a parameter, and get the parameters of DebugStatements - a object containing this method, and outputs in DebugStatements: system.out.println ("<% = attrname%>"); The status of the object is output in the console. In the code template, you can use a "THISELEMENT" predefined variable to represent the element of the code template applied, in the current version of XDE, only the code template can be applied to the method in the class. Of course, a maximum role of the code template is to use the template parameters together. A simplest example, for example, if I have created two template parameters, set to TP1 and TP2, representing two classes, respectively. I need to create an object representative of TP2 in the method OP1 () representative of TP1 and assignerate it to a TP2 type. Then we can define a parameter CODETP in the code template, type String, and assign it to its value of <% = TP2%>.
In the code template created by OP1 (), we can write: <% = CODETP%> a <% = codep%> Object = new <% = CODETP%> (); assuming that TP2 is finally bound to On a class named classtp, the result after the code mode is expanded is: classtp aclasstpobject = new classtpObject (); this completes the features we want. This is just a simplest function. In fact, the functionality of the code template in XDE is very powerful, through the JavaScript scripting language and XDE built-in programming model, we can create a very complex code template that greatly improves the generation rate of the code. 2. Mode Small Script Skirt is an executable code snippet, in fact, in the introduction of the code template, we have come into contact with this small script. <% = Var%> is a simple small script. Small scripts can not only be applied in the code template, but also otherwhere in the model, such as class, attributes, or method, an attribute value of the element, a document annotation of the model, and the like. Almost anything you can use with a string can use a small script. This kind of small script is very simple: <% = scripTlet text%>. Use the JavaScript scripting language, you can also add other program blocks between <% and%> tags. The small script is run when the pattern is deployed, and the script is replaced with the running result string. The most common usage is the name of an alternative temptation parameter used to dynamically. 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 brought to TP1 when the mode is deployed. If the TP1 helps a class named TPClass, then all <% = TP1%> is replaced with TPCLASS. Complicated, for example, we can use this small script in this class: name length: <% = tp1.getname (). Length ()%> name substring: <% = tp1.getname (). Substring (0, TP1.GETNAME (). Length () - 1)%> This is also completed. The specific API used in the script is not announced in Rational, but you can use the following tips to get an API of a model element. First define a function
Function show_props (obj, obj_name) {var result = ""; for (var i in obj) {EaEventData.addoutputMessage (obj_name "." i "=" Obj [i]);}} and then call it :
Show_props (TP1, "TP1"); this script can output an API that can be used in the XDE's output window. 3. Value Source and Value Set When you create a parameter, you can select a source of this parameter to indicate the input method of this parameter accepted. These methods have three types: · User: Default. After selecting this parameter input method, it means that when the application mode is selected, the user must select a type of type in the existing model as a value passed to this parameter. · Generated: This value means that the parameter value will be automatically created when the application mode is applied. Users only need to provide a string as the name of the generated parameter value. · Collection: A value or value set is sent from a given element to assign a value for the target parameter. This given element is called the host element of Collection, which can be any model element. After specifying the name of the host element, you can create a filter to select the content you need to derive from it, ie Collection. A simple example, you can select all the public properties of a class as a Collection, then pass these attribute values to the target parameters. These methods can be used separately, or may be combined to provide a variety of options to users. XDE provides a value set mechanism for certain types of template parameters to limit the value of the template parameters. For example, a value set can be provided for the INTEGER type template. When the application mode is used, the value of this template parameter can only be selected from a given collection. Sometimes this skill is useful, can constrain the user's value range, and there will be no unhanect results. 4. An optional element can be created by constraints with constraints. Whether this element is generated when the pattern is expanded, depending on the value of a given constraint: if the value of the constraint is true, it will be generated; it is not generated. This constraint can be applied to any element in the model. The conditions of constraints are usually dependent on the value of a certain element property. For example, it is judged that the visibility of a class is public what is PUBLIC. You can also connect a single property judgment through both, or, not to construct more complex constraints. For example, the following expression: modl1 :: package2 :: class1.visibility = "public" is a constraint, used to judge the visibility of Model1 :: package2 :: Class1 (can be public, private, protected or package) PUBLIC. If so, the constraint expression return value is True, otherwise, the return value is false. If Model1 :: package2 :: class1 does not exist, the expression indicates that there is an error existence. There are two constraints in the XDE mode definition: 1. Property constraints: is a constraint for the meta-model attribute of the model element. The above example is a property constraint. 2. Relationship constraints: used to determine a specific relationship between the model elements. For example, the relationship between the inheritance relationship between the two classes, the implementation of classes, and interfaces, and so on.
You can do not need to remember what properties in a type of meta model, what methods between the two classes, in XDE, there is a constraint editor to help you build constraints, all the work only needs to use Mouse selection can be. 5. The callouts of the Callouts mode are used to respond to some events, such as before application mode, or after the application mode, respectively correspond to the two Callouts of PREPPLY and PostApply, respectively. When these events occur, the scripts defined in the corresponding callout are called. Not all modes need to use Callouts, which is just a problem that is difficult to solve with some general mode mechanisms. Callouts can be defined on mode or template parameters. As shown below: When creating a callout, you usually need to use JavaScript to perform some processing. In XDE, there is a global EaEventData object that provides programming interfaces for the mode engine and other parts of XDE. However, about it, because the document is not full, we have not known that it is estimated that there will be disclosed in the subsequent version of the XDE. A simple example is as follows:
EaEventData.AddoutputMessage ("Test Message";
ADDOTPUTMESSAGE method at the EAEventData object can add a row of string data in the Output view.
Because Callouts provides excuses for mode engines and XDE, in theory, it can complete the functions that any mode engine can complete. Therefore it is very powerful. However, we should also avoid using it because it is too complicated and the specific interface has not been standardized. Before considering using Callouts, you should look for other places in the mode settings to see if it has been implemented.
6. Mode combination
Many times the mode is not used alone. For example, when using abstract factory (Abstract Factory), we often need to define abstract factories as a single piece, only allowed by an abstract factory instance. In this way, we need to use another creation mode: Singleton. Examples of such a combination are actually a lot. A simple usage method in XDE is to first apply an abstract factory model, and then apply a single mode on the basis of the mode. However, XDE also provides a more powerful and more complex way: combine the mode, create a new mode - on the above example, we call it a single-piece mode. In this way, we only use this application mode, you can get a good effect.
This is actually not difficult in XDE. You only need to define the structure of the mode to define a good mode. For example, when defining an abstract factory mode, assuming that all abstract factories of abstract factories now have been established. To introduce a single-piece mode, just simply select in the context menu, just as in the normal application mode, specify the parameter value of the Singleton template parameter in the single mode, and then apply One piece mode can be used. The combination of this mode provides a solution for greater and more complex issues.
to sum up
Rational XDE is indeed a very powerful feature, which discusses its detailed discussion on the topic of mode modeling and application, and basically involves all aspects of the pattern in XDE. I believe that the concept of pattern development based on XDE should have a relatively clear understanding. In fact, the functionality is only a small part of XDE, and there are many other features are also very powerful, such as forward / reverse engineering.
However, at this stage, XDE can only be called a very potential product, and it is not yet known as a mature product. On the one hand, the development model and development method it advocates is not very popular. On the other hand, the BUG of the product itself is also more, and the reference is relatively small. When we use XDE to develop, although it is convinced for its powerful performance, there are always some small harses that are annoying. However, XDE is in the continuous improvement process, believes that the next Eclipse 2.0-based version will be more excellent. references:
1. "UML Reference Manual" Machinery Industry Press
2. "UML User Guide" Machinery Industry Press
3. "Design mode: can be used for object-oriented software" machinery industry publishers
4. Rational XDE Online Document, where most of the introduction to XDE is used
5. Rational.net developer website: www.rational.net. Detailed documentation with many features about xde
