[原创]UML建模例讲-一种基于互联网的翻译交易系统（之九） (入选推荐日志，加50币) (入选推荐日志，加50币)

翻译任务服务包

作为一个举例，本例讲选择展开翻译任务服务包进行展开分析。展开后包中放置与翻译任务服务相关的主用例图。

由于时间和精力有限，其他包就不做例讲了，有心的读者一定会自己参照我的例讲展开其他包的分析当作练习，如果他们把自己练习的结果发布到这里来的话，我会非常乐意给予一些参考意见。

我在讲解业务用例模型的时候，曾给业务模型下了如下的定义：“业务用例是在业务系统中的有用的和可用的过程事例”。只要把其中的”业务系统”换成”待开发的软件系统”,这个定义就适应于我们这里要讲的系统用例了.

下图描述了在“基于互连网的翻译交易系统”中，关于翻译任务服务的,“有用的和可用的事例”，以及这些事例都是预备给谁来用的，它们之间有什么关系。在这里，用例之间关系的原理和业务建模中没有什么大的不同，如果要说有什么微妙的差别的话，就是在业务用例模型中，比较侧重用例的“有用性”，而系统用例模型中，更侧重用例的“可用性”。说侧重的意思，并不是说会忽略另一面，而是根据各自目标不同需要来定的。

业务用例模型重在发现业务系统中的问题和机会，因此更注重价值链的驱动关系，每一个过程实现的是什么价值，和其他过程的价值是什么关系，是业务用例模型重点要表达的内容，这和流程管理中强调流程的增殖是不谋而合的。而软件系统中的用例模型，注重软件应满足的业务需求，以及这种需求如何在用户和软件系统之间的交互操作过程中来实现，所以软件系统的用例模型更注重可操作性，也就是过程的“可用性”。

说回上面的用例图，里面设计了5个可用的过程：

1． 撮合翻译任务

2． 执行翻译任务

3． 评审翻译任务

4． 观摩翻译任务

5． 翻译任务结算

意思就是说：将来的翻译交易系统开发出来以后，每天每时都会主要发生上面这五种事例来满足翻译任务服务的各方面主角的需求。相关的主角，打开软件就是为了发起上面这5种事例。系统分析员的职责就是要找到它们，并一步一步把它们内部的交互过程揭示出来。

用例图中出现了“扩展”和“衍生”两种关系，机会难得，就此展开讲讲它们的共同点和区别点。在业务用例模型中我讲到过，“扩展关系”和“衍生关系”本质上都是价值的延展，都是在一个有价值的过程基础上，延展出新的有价值的过程。

本例中的“评审翻译成果”延展了“执行翻译任务”的价值，让翻译过程得到的成果更加可靠，更值得“支付”，换句话说，某些不合格的翻译过程成果，是不需要被支付的。同样的道理，“让成功的翻译任务过程的供需双方实现价值交换”则是“翻译任务结算”用例在“执行翻译任务”用例基础之上扩展出来的价值；“让学员在观摩翻译任务实战过程中学到翻译知识和技巧”则是“观摩翻译过程”用例在“执行翻译任务”用例基础之上延伸出来的价值；

那么，“扩展”和“衍生”之间有什么区别呢？比较“评审翻译成果”和“观摩翻译过程”和“执行翻译任务”之间的操作过程关系。我们会发现，对“评审翻译成果”可以在操作流程上找到对“执行翻译任务”的明显的连接点，即在翻译成果出来后，接下来就进行评审翻译成果的过程。而“观摩翻译过程”在操作流程上和“执行翻译任务”则没有明显的操作连接过程。这就是我理解的“扩展”和“衍生”的区别。这种区别，最终会体现在目标系统的界面导航的设计上。

待续...
推荐到鲜果： 查阅更多相关主题的帖子: 需求管理 应用软件