XDE中模式驱动的设计与开拓(三)
副标题#e#
第三部门：XDE中模式的高级话题
在前面的部门中，我们具体先容了XDE的利用要领，可是XDE中关于模式的观念有许多，有一些很直接，而有一些却较量的忌讳。这一部门的内容，将对XDE中的一些高级观念作劈头的阐释，并给出了一些小的例子。但愿可以或许辅佐各人更在对XDE自己，以及XDE所倡导的模式驱动的开拓要领有更多，更为深入地相识。假如没有看过前几期的读者，照旧最好找来看看，直接看着一期的内容，领略起来大概会有一些坚苦。
1．代码模版（Code Template）
模式，可能说设计模式，很洪流平上是对工具布局上的描写。也就是说，模式最终的实现以及生成的代码，也大大都是属于框架性质的–只有类，属性可能要领的界说，类之间的引用，担任等等之类的代码，而对付详细的要领中的代码，它往往无能为力。这也是大大都正向工程东西都欠缺的一个部门。
实际上，假如只是一些简朴的语义，好比工具的建设，牢靠要领的挪用而没有涉及巨大的交互的，我们也是可以或许从模子的语义中生成详细的代码。在XDE中，通过代码模版，来完成一些简朴要领的参数化的代码生成。
如同模式一样，代码模版也是可以拥有参数并在详细生成的时候举办替换绑定的。在代码模版中，可以利用两种范例的参数：strings和model elements。
Strings：简朴的字符串，在代码生成的时候XDE会用详细的字符串来替换所有的这些字符串参数。
Model elements：一个模子元素。XDE中提供了一个简朴的编程模子，可以通过对模子元素API的挪用（好比获得一个类的所有公有要领）来完成给位巨大的代码定制。和模式接洽在一起的时候，Model Elements范例的参数可以是模式中的一个模版参数，在模式展开的时候，会用详细的模版参数值来替换这个代码模版中参数。
XDE代码模版的形式很像Jsp可能Asp中利用的形式。你假如对Jsp的机制很相识的话，那么你也可以很容易的领略代码模版的机制了。
在一个代码模版中，代码被分为两个部门，一部门是直接输出的，不颠末任何的处理惩罚。别的一个部门是在<%和%>这两个标号之间的剧本内容，通过对参数可能其它元素的处理惩罚之后再举办输出。假如Jsp或Asp一样，它也是用简朴的<%=var%>来举办变量的输出（var是一个变量）。所有<%和%>之间的内容，是利用剧本语言来编写的。此刻XDE中的代码模版只支持Javascript语言。
下面的一个代码模版的例子选自XDE的在线文档，用以在调试的时候打印工具的当前状态。每一个应用了这个代码模版的要领，将会在挪用要领前在节制台输出工具的状态，供调试利用。
<%
// 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
%>
在上面的代码模版中，界说了两个要领debugStatements和debugOperation，debugOperation接管当前元素作为参数，并由其获得debugStatements的参数–一个包括了这个要领的工具，并在debugStatements中输出：System.out.println( "<%=attrName%>" );
#p#副标题#e#
以在节制台输出工具的状态。
在代码模版中，可以用一个"thisElement"的尺度的预界说变量来代表代码模版被应用的元素，在当前版本的XDE中，只可以或许在类中的要领上应用代码模版。
虽然，代码模版的一个最大的浸染，就是同模式的模版参数一起来利用了。一个最简朴的例子，好比说，假如我建设了两个模版参数，设为tp1和tp2，别离代表了两个类。我需要在tp1代表类的要领op1()中建设tp2所代表类的一个工具，并把它赋给一个tp2范例的引用。那么我们可觉得代码模版中界说一个参数codetp，范例为String，并为其赋值为<%=tp2%>。则在为op1()所建设的代码模版中，我们可以这样写：
<%=codetp%> a<%=codetp%>Object=new <%=codetp%>();
假设tp2最后被绑定到一个名为ClassTP的类上，代码模版被展开后的功效就是：
ClassTP aClassTPObject=new ClassTPObject();
这样就完成了我们想要的成果。
#p#分页标题#e#
这只是一个最为简朴的成果。实际上，XDE中的代码模版的成果长短常强大的，通过javascript剧本语言和XDE内建的编程模子，我们可以建设很是巨大的代码模版，使得代码的生成率大大提高。
2．模式小剧本（Scriptlets）
小剧本是一种可执行的代码片段，实际上在上面临代码模版的先容中，我们已经打仗到这种小剧本。<%=var%>就是一种简朴的小剧本。小剧本不只可以或许应用在代码模版中，还可以利用在模子的其它处所，好比类，属性，可能要领的名字，元素的属性值，模子的文档注释，关联的端点名，等等。险些在任何可以利用字符串的处所都可以利用小剧本。这种小剧本的语法很简朴： <%=scriptlet text%>。利用javascript剧本语言，还可以在<%和%>标志之间插手其它的措施片段。
小剧本在模式被展开的时候被运行，并用运行的功效字符串来替代这段剧本。最为普遍的一个用法是用来动态的替代模版参数的名字。好比，假如在模式中界说了一个名为tp1的模版参数，那么小剧本<%=tp1%>在模式被展开时被替换成tp1所绑定的参数值的名字。假如tp1帮定到一个类名为TPClass的类上，那么最后所有的<%=tp1%>都被替换成TPClass。
巨大一点的，好比，我们可以在对这个类的文档中利用这个小剧本：
Name Length: <%= tp1.getName().length()%>
Name Substring: <%= tp1.getName().substring(0, tp1.getName().length()-1)%>
这样，最后的文档也完成了。
在剧本中利用的详细的API在Rational尚未发布，可是可以利用如下的一个小能力来获得一个模子元素的API。首先界说一个函数
function show_props(obj, obj_name) {
var result = "";
for (var i in obj) {
EAEventData.AddOutputMessage(obj_name + "." + i + " = " + obj[i]);
}
}
然后再挪用它：
show_props(tp1, "tp1");
这样这个剧本可以或许在XDE的输出窗口中输出给定模子元素可以被利用的API。
3．值源（Value Source）和值集
在建设一个参数的时候，你可以选择的指定这个参数的一个值源，来指明这个参数所接管的输入的要领。这些要领有如下的三种：
· User：缺省值。在选择了这种参数输入要领后，意味着在应用模式时，用户必需从现有的模子中选择一个范例相符的元素来作为通报给这个参数的值。
· Generated：这个值意味着在应用模式时参数值将被自动的建设。用户只需要提供一个字符串作为生成的参数值的名字即可。
· Collection：从一个给定的元素中派生出一个值可能值集，来为方针参数赋值。这个给定的元素，被称为Collection的宿主元素（Owning Element），它可以是任何的模子元素。在指定了宿主元素的名称后，可觉得其建设过滤器，来选择需要从中派生的内容，即Collection。一个简朴的例子，你可以选择一个类的所有公有的属性作为一个Collection，然后将这些属性值通报给方针参数。
这些要领可以被单独的利用，也可以被组合利用来给用户提供多种选择的要领。
XDE中为某些范例的模版参数提供了一种值集的机制，来限定模版参数的取值。好比可觉得Integer范例的模版参数提供一个值集，在应用模式的时候，这个模版参数的取值就只可以或许从给定的荟萃中选取。有些时候这种能力是很有用的，可以约束用户的取值范畴，不会呈现不正当的功效。
4．用约束建设可选元素
XDE中可以通过约束来建设一个可选的元素。这个元素是否在模式展开的时候被生成，取决于给定约束的值：假如约束的值为true，它就会被生成；反之，就不会被生成。这种约束可以被应用到模子中任何的元素上。约束的条件，凡是取决于某一元素属性的取值。好比，判定一个类的可见性是不是public什么。也可以通过AND，OR，NOT来毗连单个的属性判定，来结构更为巨大的约束。
譬喻，下面的表达式：
Model1::Package2::Class1.Visibility = "PUBLIC"
就是一个约束，用来判定Model1::Package2::Class1的可见性（可以是PUBLIC，PRIVATE，PROTECTED可能PACKAGE)是否为PUBLIC。假如是，约束表达式返回值为true，不然，返回值为false。假如 Model1::Package2::Class1不存在，表达式指出有错误存在。
在XDE的模式界说中可以有两种约束存在：
1、 属性约束（Property constraints）：是对模子元素的元模子属性的约束。上面的例子即为属性约束。
2、 干系约束（Relationship constraints）：用来判定模子元素之间的特定干系。譬喻，两个类之间的担任干系，类和接口之间的实现干系，等等。
#p#分页标题#e#
你可以不消去记获得底某个范例的元模子中到底有哪些属性，某两个类之间到底有哪些要领，在XDE中，有一个约束编辑器来辅佐你构建约束，所有的事情只需要用鼠标选择即可。
5．Callouts
模式的Callouts用来响应一些事件，好比在应用模式之前，可能在应用模式之后，别离对应着PreApply和PostApply这两个Callouts。在产生这些事件的时候，相对应的Callout中界说的剧本被挪用。
并非所有的模式都需要利用到Callouts，它只是用来搪塞一些用一般的模式机制难以办理的问题。Callouts 可以或许界说在模式可能模版参数上。 如下图：
在建设一个Callout的时候，凡是需要利用到Javascript来举办一些处理惩罚。在XDE中，有一个全局的EAEventData工具，它提供对模式引擎以及XDE中其它部门的编程接口。可是，关于它的细节，因为文档不全，我们尚未得知，预计在今后的XDE版本中会有披露。一个简朴的例子如下：
EAEventData.AddOutputMessage("Test message");
在EAEventData工具的AddOutputMessage要领可以在output视图中添加一行的字符串数据。
因为Callouts提供了对模式引擎和XDE的捏词，理论上来讲，它可以来完成任何模式引擎可以或许完成的成果。因而它长短常强大的。可是，我们照旧该当只管的制止利用它，因为它太巨大并且详细的接口尚未被尺度化。在思量利用Callouts之前，应该先查找模式配置的其它处所，看看是否已经被实现了。
6．模式的组合
许多时候模式并不是单独利用的。譬喻在利用抽象工场模式（Abstract Factory）的时候，我们往往需要将抽象工场界说为一个单件，只答允由一个抽象工场的实例存在。这样，我们就需要利用到别的的一个建设型模式：单件模式（Singleton）。这样的模式组合的例子其实许多。XDE中一个简朴的利用步伐，就是先应用一次抽象工场模式，再在模式展开的基本上应用一次单件模式。但XDE还提供了更为强大也更为巨大的要领：将模式组合在一起，建设一个新的模式–就上面的例子，我们暂时称其为工场单件模式吧。这样，我们只用这个应用模式一次，就可以获得很好的结果。
这样的实此刻XDE中其实并不难。只需要在界说模式的布局时，在引入以界说好的模式即可。好比，在界说抽象工场模式的时候，假设此刻所有的抽象工场的参加者和模版参数都已经成立好了。要引入单件模式，只需要简朴的在上下文菜单中选择，就如同在一般环境下应用模式一样的，将抽象工场中的参加者ConcreteFactory指定为单件模式中Singleton模版参数的参数值，然后应用单件模式即可。这种模式的组合为更大，更巨大的问题提供了办理方案。
总结
Rational XDE确实是一个很是强大的成果，本文对其在模式建模及应用方面的话题作了具体的接头，根基上涉及了XDE中模式的方方面面。相信各人对XDE中基于模式开拓的观念应该有了一个较量清楚地相识。而实际上，模式的成果只是XDE中的一个小的部门，尚有许多其它的成果也长短常的强大的，好比正向/逆向工程。
可是，在现阶段，XDE还只能被称为是一个很有潜力的产物，尚不能称为一个成熟的产物。一方面，它所倡导的开拓模式和开拓要领还不长短常的风行，另一方面，产物自己的Bug也较量多，参考资料也较量少。我们再操作XDE举办开拓的时候，固然为其强大的机能所折服，但也老是有一些小短处让人很烦。不外，XDE正处在不绝的完善进程中，相信其下一个基于Eclipse2.0的版本会越发的优秀。
参考文献：
1．《UML参考手册》 机器家产出书社
2．《UML用户指南》 机器家产出书社
3．《设计模式：可复用面向工具软件的基本》机器家产出书社
4．Rational XDE在线文档，个中可以获得XDE利用的大部门先容
5．Rational.net开拓者网站：www.rational.net。有很多关于XDE的成果的具体文档
