Summary: Software mode, especially design patterns are increasingly important in today's software development. In many standards, tools, and development methods, the concept is introduced. This article describes how to model software modes in UML and combine specific tool Rational XDE, which is detailed, how to apply, how to apply patterns, and point out some related issues.
Part II: Mode Mechanism in XDE
1 Overview
In the previous series of articles, we made a brief introduction to the model, especially design model in UML, theoretical introduction. It should be practiced now. It is now not much tool that supports mode modeling and can develop based on mode. Rational XDE is the most famous one and does provide an extremely excellent function.
XDE's Java version has two, one is a stand-alone run version based on the Eclipse kernel (Eclipse1.0 only supports only). Another one is integrated in WASD, as a plugin for WASDs with its operation (currently only WASD 4.0). In fact, WASD is used by Eclipse's kernel, so both of these are functional (or even appearance) is not much different. Now Rational has been merged by IBM, so there is enough reason to believe that in future WSAD, XDE features will be integrated into it.
XDE has two, one is to analyze the design of the same code is completed in the same IDE, and can perform forward-reverse engineering, perfect implementation of the model-code mapped in iterative development. Mapping. The other is the subject of this article: the definition and application of the pattern. Not only can you use the 23 classic GOF design patterns predefined in XDE, but also define them themselves, apply them in development, or export for others to use.
The mode mechanism is a core technology that implements reuse in XDE. You can achieve reuse of model elements and other products through this mechanism. It provides the transformation capabilities of Model-to-Model and Model-to-Code. This allows you to help a model involved as a specific design. It still has to merge the contents of the elements in a mode into the deposited design model.
2 The mode in XDE is described in XDE, and the description of the mode basically follows the parameterized collaboration criteria defined by UML. However, since the UML is defined in the mode modeling, it is not too much to define the mode, application mode, and the specific code generation. Thus, XDE made some reasonable extensions on the basis of UML. First, let's take a look at the concept of Asset. A Asset is a collection of software products that are organized together with a period to solve a problem. Asset can extend through its defined variable point (VARIABILITY POINT), the developer needs to enrich the ASSET when performing ASSET reuse. Rational now advocates an Asset based developments process, as a supplement to RUP, Asset is its key. It doesn't intend to make too much discussion on Asset and Asset Based Developments, which has deviated from the theme of this article. From the scope of mode, you can simply regard Asset as a definition, description, and specific implementation thereof. In XDE, Asset is represented as a package that constructs << asset >>. Package that is declared for << asset> can be derived to reuse in different developers, even different tools, as long as they follow the ASSET specification Reusable Asset Specification. The mode is an Asset, but Asset is not necessarily a mode. A model can be packaged in an ASSET, and there is no pattern description thereof. XDE can handle these two reusable projects. In XDE, the mode is represented as a collaborative diagram with template parameters included in a << asset >> package. There are many ways to create a << asset >> package, but you need to pay attention to creating a UML package and handling its version to << asset >> does not register this package as a mode. In XDE, the << asset >> package can be exported as a .ras file. A .ras file is actually a zip file, but it has its own content structure, this is very similar to the .war file in J2EE. It uses rasset.xml and resource.xml to provide a description of this compressed document. Rasasset.xsd files are RAS's XML Schema, define the content format and meaning of the two documents of Rasset.xml and Resource.xml. Other files are models and documentates. In XDE, the mode consists of some of the following parts: Asset at the bottom of a mode is a package of << asset >>. All of the contents involved in the mode are included in this package, which is also a logical unit used to export a reusable mode that conforms to the RAS specification (the actual physical package unit can be a package, or a model). The mode can also not be present in the ASSET package, but because the mode creation goals are desired to be reused through the RAS specification, this method is not recommended. Template Collaboration (Template Collaboration) is Template Collaboration in Mode Asset, which is the core of the pattern.
Almost all of the contents involved are defined therein. The properties of the template parameters can be viewed by Pattern Explorer. Template parameters (Template Parameters) A template collaboration contains one or more template parameters, each defining a specific mode input. For example, if you want to have a parameter named myclassInput, you can create a template parameter using that name. Type Element has a type with a type, defined by its Type property. For example, if the type of the template parameter is Class, then this template parameter accepts only the class as its parameter value. This is the same as the type (such as int), which needs to specify its parameters as defining parameters of a function. Basis Basite Context A mode has a basis for the basis, and other elements introduced during the creation mode are organized in this place. These elements are usually created directly, requiring little or no parameters at all. For example, a support class that will be used in a mode. By default, the basic context is an Asset package. You can switch it to other packages in Pattern Explorer. In actually in the ASSET package in the mode, there may be any type of element, such as a class diagram describing the mode structure, the sequence diagram of the interaction between the participants in the mode, and the like, can be placed in the basis, Copy it together to the extension at the time of the schema is expanded. In order to provide visual development and representation of the model, XDE adds a new Model perspective (Perspective) on the basis of Eclipse. In fact, all models related content is not just mode, which is implemented in this perspective. For model, in addition to all models of Model Explorer, there is a Pattern Explorer and Pattern Property view to provide definitions and descriptions of the pattern. The use of these interfaces is relatively simple. The key is to figure out what properties are made, and the setting value is what. In addition to the standard Eclipse graphic elements of the above, Pattern Wizard has introduced Pattern Wizard to help you complete the application. 3. Application XDE mode application, can be seen as a template-based method: define a good template parameter, the convergence of the elements consistent with the same model type in the existing model, or the same model Complete the extension of the mode. There is no element defined as a template parameter in the mode, which will be created automatically at the extension point. When applying a pattern, there are two basic concepts: 1, an exference location: This is where the generated class and other elements are placed after the mode is applied. Even the mode does not generate any elements, and the basically the above is not involved in any element, this extension is still needed for the application of the mode. 2, binding and binding point (Binding location). Binding is the process of parameters in the mode to be given a specific parameter value, which may be a model element specified by the user, or an element that is automatically created with the default value. When a mode is applied, there is a binding object in the specified binding point to be created, which is used to maintain the template parameters of this mode and the binding relationship between the specific parameter values.
The usual binding effect is to re-apply mode after modifying the mode, without setting the parameter values required to set the application mode again through the Pattern Wizard, you can also modify the binding directly in the binding object. Parameter value. In the default, the binding point and the extension point are the same location. With these two basic concepts, we can simply describe the application of the model as the following process: in the extension point, specify specific parameter values by specifying the specific parameter values defined in the mode, and put these parameter values instance Chemically in the specific model. Other elements in the package in the package are also created accordingly, including class diagrams, sequential diagrams, etc. We still use the Command mode as an example to exempt the definitions and applications of a pattern. To apply the mode, we call up the shortcut menu on the model that needs to be applied, select Apply Favorite Pattern, then select (GOF) Command mode, as shown below: Pattern Wizard, help you enter the parameter value of the mode: pattern wizard The first page gives a detailed mode description, and interaction between the main participants to help developers choose the appropriate mode. After the next step, it is to enter the parameter value: the general parameter value specifies two methods: SELECTED Element: As shown above, you need to specify a type of element in the model, which is a class. This method will fuse the content defined in the template parameters in existing elements without any effect on the original elements. Generated value: As shown below, you need to provide a string name for a given parameter, and generate a new element of the corresponding name. When each parameter specifies a binding value, specify the extension and binding point, this, the application of a mode is completed. The semantic information described in the Command mode, and the specific model elements are introduced into the existing model. In fact, there are many ways to apply models in XDE, but using pattern wizard is the standard is also the most simple method, and XDE also allows for a detailed customization of each page in Pattern Wizard when defining a pattern. , Make the application of the model more convenient and concise. Other methods, such as use of structural types, use binding objects, etc., this is no longer detailed. The above is a brief description of the application process in XDE. From the XDE's internal working mechanism, the application is divided into three steps as follows: 1. Binding: Specify specific parameter values for each temple parameter in the mode. 2. Calculation / mapping of parameters: calculate the content related to parameters, such as constraints, scripts, and more. And mapping and matching parameter values based on the number of specified parameter values. 3. Expand: After all parameters are determined, the mode can be expanded. Parametric values that pass in will be modified or created, and then copy to the extension point, the deployment of the mode is complete. It is important to understand this process, because we need to apply existing patterns, but also need to define, create mode. The understanding of this process can make our relationship between template parameters and their bindings. This is precisely the core of the model definition. 4. Definition of mode The example from the above mode can be easily seen that in XDE, the key to the mode definition is defined for the template parameters, which includes the type, generation of the template, and the like. Before developing modes in XDE, the abstract pattern should be refined so that it can be implemented.
For example, the implementation of the pattern will be different for different languages. The process of refining is more cumbersome, and there is no certain criterion, which is not discussed here. We pay more attention to how to develop a model in XDE. In XDE, a mode development can follow the steps: 4.1 Creating a mode Asset says, a mode is included in a package of constructed << asset >>, so before you create a mode, first need Create this package. You can create this package by selecting Add UML> Pattern Asset in Model Explorer's context menu. As shown in the figure below, the following dialog box appears: The above figure should be noted that an ASSET can be defined in a packet to be individually defined in one model. This will determine the basis of the basis, and the package is a package or the entire model. 4.2 Participants who define the template model for the participants are the responsibility of the model, which is where the template parameters need to be defined. Of course, the template parameters can also contain other information, not just the participants of the mode. Simply put, the template parameter defines that all modes need to be customized. To create a template parameter, you can select Add UML> Template Parameter in the context menu of the newly created mode collaboration in Model Explorer. Once the modal parameters are defined, you also need to specify a type. Select Add UML in the context menu created by the template parameter, then select the specific type: can be class, method, attribute, interface, string, integer, etc. Basically most of the UML elements can be created as a template parameter. Of course, for the participants of a mode, its type is usually class, or interface. For a template parameter set to class type, we may also need to add an attribute, method, and so on. For the method therein, you can specify a code template for it. These contents will be introduced into the specific model development as the template parameters. We can also set the way the parameters are generated. The judgment template parameter value is to select a model element or newly created one, or derived from other template parameters? These different generation methods depends on the value source value of the template parameters, which can be one of the three situations, or the combination thereof. This has more detailed introductions in the Value Source in the later section. You can set the value of value Source in the Advanced Properties in Pattern Explore. 4.3 Creating Mode The structural class diagrams can be included in the definition of the mode or multiple class diagrams to define cooperation and relationships between the various participants of the mode. Select Add Diagram> Class in the context menu of the newly created mode collaboration in Model Explorer. In fact, this class diagram is not required for mode applications. However, this class diagram can be described very good to describe the structure of the pattern, and it is also necessary. 4.4 Adding Other Optional Mode Elements You can also add a model element of other non-moderal parameters in Model Explore. These elements are placed on the basis of the pattern, and when they are binding, they will be created automatically and placed at the extension. In Pattern Explorer, you can see these contents in the root context directory of the pattern. 4.5 Creating a Code Template Code Mode for Mode Participants Filled the specific code implementation.
