生成的依赖关系扩展点有如下三个

• public boolean update(PatternParameterValue value, PatternParameterValue dependencyValue)
• public boolean update(PatternParameterValue.Maintained value, PatternParameterValue.Removed dependencyValue)
• public boolean update(PatternParameterValue.Removed value, PatternParameterValue.Maintained dependencyValue)

    我们在此例中只有getEntry参数建立了依赖关系，而至扩展了第二个方法，因为第二个方法是在getEntry所依赖的Service方法删除时调用，而getEntry所绑定的参数的提供这恰为Service的参数，所以在Service参数解除绑定时，对应的getEntry也应该解除绑定，代码如下所示：

            public boolean update(PatternParameterValue.Maintained value,
            PatternParameterValue.Removed dependencyValue){
            Object obj = value.getValue();
            if( obj instanceof Operation) {
            Operation oper = (Operation) obj;
            // instance -- instance of the pattern in the model which gives values
            specified for this pattern.
            com.ibm.xtools.patterns.framework.AbstractPatternInstance patternInstance =
            value.getOwningInstance();
            CachePatternImplementation impl;
            impl = (CachePatternImplementation) instanceToImplMap.get(patternInstance);
            if (impl == null) {
            impl = new CachePatternImplementation (patternInstance);
            instanceToImplMap.put(patternInstance, impl);
            }
            impl.unbindOperation(oper);
            }
            return true;
            }
            

    这段代码利用CachePatternImplementation类中的方法解除了getEntry方法的参数绑定。

    3． 验证扩展点：

    在此例中我们注意到Service的参数应当为Interface或是Class，而我们在指定类型时只能将其指定为Classifier，而Classifer作为UML2种的一个类型，包含许多子类型，比如Component、UseCase等等，而将这些类型作为Service的参数是不允许的，所以我们必须使用验证扩展点来保证这一点。在此例中我们扩展的方法及代码如下所示是：

            protected  IStatus validToAddArgument(PatternParameterValue.Proposed proposed){
            // Use to judge whether the parameter can be bound.
            IStatus status = super.validToAddArgument(proposed);
            if (status.isOK()){
            Object obj = proposed.getValue();
            if ((obj instanceof Class)||( obj instanceof Interface)) ;
            else return Status.CANCEL_STATUS;
            }
            return status;
            }
            

    至此，基本Pattern Authoring 的工作就算完成了，下面进行调试。

    步骤四：调试

    调试是必须运行一个runtime_workbench，这里我们建议选择eclipse的JVM，并设置参数为-Xj9，这样可以支持"hotcode-replacement"方便我们减少我们在调试过程中启动runtime_workbench的次数。调试界面如下图所示：

    1. 在Runtime_workbench中切换到Model perspective，并打开Pattern Explorer视图，如上图所示。

    2. 可以看到我们刚刚创建的Cache Pattern已经在Tutorial Pattern组中，将其拖至建好的空的Model中，建立测试用的接口或类，绑定适当的参数，就可以借助RSA提供的强大功能进行调试了。

    调试完成，也就完成了这个简单而又实用的Cache Pattern的开发工作。 

    6 结语

    通过本文的介绍，我们可以看到，模式是一种抽象的软件解决方案，用来解决一个在特定场景中的连续的或反复出现的问题。开发设计过程中大量地使用模式有很多的优点，我们可以利用已有的模式来解决一些软件问题，从而节省了设计人员的时间。模式的用户并不需要知道如何去设计一个具体的模式，但是用户需要有好的模式文档，好的模式文档能帮助模式的用户定位、选择和应用不同的模式。用户需要了解这个模式是用来解决什么问题的，这个问题是如何被解决的以及应用这个模式的结果。模式的作者能够创造多种类型的与模式打包在一起的模式文档，在模式应用过程中，用户可以使用这些文档。

    模式的可重用性还能够节省大量的设计开发时间。 可重用的特性增加了软件的可靠性和编码设计的连续性。一个模式可以在一个项目中、一个公司内部以至不同公司间共享。模式的局限性由模式的设计以及模式开发者的设计意图所决定。而RSA中的模式都由标准的Eclipse插件构成，我们可以通过将包含模式的插件打包成可重用的资产（Reusable Asset Specifications）并且在RAS资产库中注册和管理它们来实现最大程度的模式可重用性。通过由模式开发者提供的模式的关键字和描述的匹配，潜在的模式用户可以从RAS资产库里搜索和选择所需的模式。模式这种特殊的资产遵循RAS（Reusable Asset Specifications）所制定的标准， 通过遵循这些统一的规范，模式用户和模式开发者之间可以非常便利地交换模式。