业务用例模型
业务用例模型描述一个业务的流程以及它们与外部各方（如客户和合作伙伴）之间的交互。 （业务用例流程图） 解释 由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。 直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务 都可以在模型中给出。
业务用例的不同类型
当考查业务中的活动时，至少可以确定三类工作，它们对应着三种业务用例类型。
第一类是在商业上比较重要的活动，常称为业务流程。 第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。 系统管理、清洁和安全等工作就是这类活动的示例。该业务用例具有支持的性质。 第三类是管理工作。具有管理性质的业务用例所显示的工作影响如何管理其他 业务用例以及该业务和其所有者的关系。
一个业务有多个业务用例
一个业务有多个业务用例。多个不同业务用例的实例或一个业务用例的多个实例并行执行的情况是很正常的。 一个用例实例可以遵循的路径的数目几乎是没有限制的。这些不同的路径代表了工作流程说明中用例实例的 各种选择。根据具体事件和情况，用例实例可以沿着多种可能路径中的一种进行下去，例如： （1）来自主角的输入。 （2）一条业务规则。
业务用例是否总是与业务主角相关？
每个核心业务用例都应该和某个业务主角之间存在通信关系。该规则强调了构建业务的目的， 即构建业务是为了提供用户要求的服务。如果业务用例模型中存在无人要求的业务用例， 这就说明模型存在问题。
业务用例可以周期性地触发，也可以长时间工作；监督功能就是后者的一个示例。这些业务用例中 甚至还存在最初启动这些业务用例并期望得到不同服务的业务主角。否则，它们将不能成为业务的 一部分。其他业务用例将产生业务主角需要的结果，尽管业务主角并没有明确地启动它们。 例如，某个广泛发布产品的开发很少是由某个可以确定的客户启动的。而对新产品的需求通常是通 过市场研究和积累大量的用户请求了解到的。
尽管管理和支撑业务用例一般都有某种外部联系，但它们不一定需要与业务主角进行联系。 例如，管理业务用例可以将业务的所有者或董事会作为其业务主角。 抽象业务用例不需要业务主角，因为它们从不独立进行实例化（“启动”）。
建立业务用例模型
建立业务用例模型有三个主要原因： 使业务用例更易于理解。 复用多个业务用例共享的部分工作流程。 使业务用例模型更易于维护。
blog comments powered by Disqus