用户界面的UML建模04

 3 任务建模（Task Modeling）

图1 所示的用例BrowseBooks 表明一个借阅者可以浏览图书。但是，借阅者必须登录才能执行其它任何功能。

若使用UML 术语即指，角色Borrower 只能在之前使用了用例ConnectToSystem 的情况下，使用用例BrowseBooks。

事实上，在这种情况下稍微有些复杂。一个借阅者在使用ConnectToSystem 前并不意味着他/她登录进了系统。比如当借阅者尝试去登录却返回失败时，便会发生这种情况。同样地，用例图还表明了用例CheckBookStatus 扩展了用例SearchBook 和BrowserBooks，但是并没有解释该情况会如何发生。

以上所描述的问题是指，用例图是为需求分析进行设计的。但是它们并不提供与任务相关的控制流（control flow）的信息。如图3（a）所示的活动图 (activity diagram)表示了一个借阅者如何与图书馆系统的用户界面进行交互（interact）。我们可以注意到，活动图并不等同于用例图，活动Log in（登录）对应着当系统用户成功登录时所使用的用例ConnectToSystem。该活动图还表示了一个用户在登录系统后，需要选择下面的一个选项：检索一本图书，浏览图书，或者退出与应用程序的交互。而且，用户只有通过活动Select book（选定图书）来选定一本图书后，才能检查该书的状态。

图3：任务模型的部分视图

像传统的层次任务分析（HTA，Hierarchical Task Analysis）[13,14,4]一样，使用活动图来控制
用户界面的导航，已被广泛用来描述用户任务模型（user task model）。活动（activities），用例以及任务（task）并非完全等同，尽管它们具有相似的特征。例如，可以把用例考虑为高层次的任务，而有些活动往往类似于任务。然而，用例和活动之间的关系在UML 中并没有特别地进行区分。实际上，用例不提供经常与用户需求相关联的一些特性，如目标（goal），前置条件（pre-condition）和后置条件（post-condition），但是这些特性对于活动图的设计却是很有帮助的。

（？？）
一个单独的活动图能够对整个任务流控制进行建模，但是活动还能够进行分解。事实上，活动并不是原子的，这就意味着它们在执行一段时间后可以被中断[2]。利用这种可分解性，图3（a）中的活动Search book 可另外作为一个附加的活动图，来进行更精确地说明，如图3（b）所示。

许多任务需要来自领域模型的信息，及用户提供的信息[8]。例如在图3（a）所示的活动图中，一本被选定的图书需要从活动Select book 传递到活动Check book status。这种活动图中的数据流（data flow）可以使用对象流（object flow）来进行建模。如图3（a），活动Select book 标识了Book 类的对象b 被传递到活动Check book status中去。这些数据项也可在与用例相关联的交互图（interaction diagram）中进行获取。然而，活动图所提供的对象流技术，避免了通过检查交互图来发现任务是如何进行信息访问的必要。