银狐999个人BLOG

其有一个gui端的测试控制端，是

au.edu.qut.yawl.engine.gui.YEngineGUI类。

List newSpecIDs = _engine.addSpecifications(selectedFile, _ignoreErrors, errorMessages);

但是，其在load specification的时候，会应为验证不通过而抛错误，需要修改一点程序。将 au.edu.qut.yawl.unmarshal.YMarshal 类中的 unmarshalSpecification 方法 中有关验证部分的代码屏蔽掉，即可：

//        String errors = YSchemaChecker.getInstance().checkSchema(specificationSetFileID);

//        if (errors == null || errors.length() > 0) {

//            throw new YSyntaxException(

//                    " The file failed to verify against YAWL's Schema:\n"

//                    + errors);

//        }

其engine类 Yengine 提供了 加载 specification的方法：addSpecifications

在这个方法中，会调用 Ymarshal类的来完成 xml到对象的转换：

newSpecifications = YMarshal.unmarshalSpecifications(specificationFile.getAbsolutePath());

       2004年9月30日早上5点，在睡梦中突然醒来，想到了这几天和老宋讨论的有关Petri Net，Workflow，Workflow Pattern之类的事情；又想到我曾经写的《工作流模型分析》。标准的workflow pattern是没有“return”，“rollback”，“Unrestricted Routing”等等的。

       那么将这些“return”之类的放于何处呢？放在workflow feature，就有些太不抽象；这也是我曾经写《工作流模型分析》一个原因。?? 当时，实在无法用“工作流模式”这个词，所以才用的“工作流模型”来指明他们的区别：文章中，我把“Unrestricted Routing”之类的归属于“特殊运转模型”就是这个意思。但是，当时，这个区别以及层次，实际上不是很清晰的（那时候理解也并不是很透彻）。

        当然，期间，我有些想把这几种“特殊运转模型”纳入workflow pattern范畴。甚至中间想把《工作流模型分析》更改名称为《工作流模式分析》。为此，也为自己找了一些托词，什么“国内的特殊情况”等等之类的，但是，也不得不承认，“return”，“rollback”这些与pattern沾不上多少边，可能更偏重于一种“Feature”或“Function”。

       为此，我规划出一个单独的层次：工作流运转模型（Workflow Transition Model.），如下图：



       其实，这种图并不能很好的表达Workflow Transtion Model与Workflow Pattern之间的真正的关系：就像你无法用于图形，表达一个java应用与一个模式之间的关系一样。

       或者说，Workflow Pattern可以用图形非常直观形象的表达流程的“规则运转方式”，而Workflow Transition Model则表达了 一种流程运行表现的应用模型。

       比如，一个处于Sequence（从模式上划分，属于Sequence）的活动点，其可能表现为“rollback”，甚至“Unrestricted”；当然，也可能其本身表现的就是一个Sequence。

       这样划分，也就是想将很多问题，从Patterns中跳跃出来，但也不至于一下子就跳跃到workflow feature或function这些抽象度很低的层次上。