UML核心元素之 用例

用例在UML中是最重要的一个元素。之所以说它重要，是因为UML是面向对象的，除用例之外其他元素都是“封装”的、“独立”的。
基本概念
用例（Use Case）是一种把现实世界的需求捕获下来的方法。这个世界功能性体现在，首先有某个人的一个愿望，这个愿望驱使人去做事并获得一个确定的结果。一个系统就是由各种各样的愿望组成的。换句话说，各种各样的人为了各自的目的做着各种各样的事情共同组成了一个系统。如果要描述这个系统功能性需求，就要找到对这个系统有愿望的人，让他们说明他们会在系统中做什么事，想要得到什么结果。
官方定义：用例（Use Case）定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的结果。也就是说，一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。简单的说,所谓用例就是一件事情，要完成这件事情，需要做一系列的活动。而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景。一个场景就是一个用例的实例。因此，一个完整的用例定义由参与者、前置条件、场景、后置条件构成。
一个系统的功能性是由这些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达到了参与者的一个愿望，当全部的参与者的愿望都能通过用例来达到，那么这个系统就被确定下来了。用例的作用就是捕捉功能性需求。
用例的特征
1、用例是相对独立的。
用例的这一特征说明，它不需要与其他用例交互而独自完成参与者的目的。即用例从“功能”上来说是完备的。用例的本质体现了与系统交互的参与者的愿望，不能完整达到参与者愿望的不能称之为用例。
2、用例的执行结果对参与者来说是可观测的和有意义的。
3、这件事必须由一个参与者发起。
不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起的，参与者的愿望就是这个用例存在的原因和全部意义。
4、用例必然是以动宾短语的形式出现。用例必须有一个动作和动作的受体。
5、一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至是部署单元。
一旦决定了用例，软件开发工作的其他活动都以这个用例为基础，围绕着他进行。
用例的粒度
用例的粒度没有一个标准的规则，在项目的不同阶段使用不同粒度的用例。在业务建模阶段，用例的粒度以每个用例能说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整的业务中的一个步骤。在这个阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。
用例分析是以参与者为中心的，用例粒度的划分依据（尤其是业务用例）最标准的方法是以该用例是否完成了参与者的某个完整的目的为依据。一般说来，一个系统的业务用例定义在10个到50个之间，否则就应该考虑一下粒度选择是否合适了。
同时应特别注意，不管粒度如何选择，必须把握的一个原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。粒度选择的问题本质上还是边界认定的问题。
如何获取用例？
正如用例的定义所述，用例是由参与者（actor）驱动的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。用例的来源就是参与者对系统的期望，因此发现用例的前提条件是发现参与者。
在准备获取用例之前，需要特别注意一下几个问题（这里把参与者叫做主角）：
1、主角是位于系统别解之外的。
2、主角对系统有着明确的期望和明确的回报要求。
3、主角的期望和回报要求在系统边界之内。
接下来，就可以开始对主角进行访谈了，在访谈中要注意一下问题的答案：
1、您对系统有什么期望？
2、您打算在这个系统里做什么事情？
3、您做这件事的目的是什么？
4、您做完这件事希望有一个什么样的结果?
对主角的访谈结果进行记录，并从中找出用例。在提取用例的时候应确保：
1、一个明确的有效地目标才是一个用例的来源；
2、一个真实的目标应该当完备地表达主角的期望；
3、一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果；
区分用例和功能
虽然用例是捕获系统功能性需求的，但是有一个前提，即这个功能性需求是从参与者的角度出发的，用例不是功能。
为了区分用例和功能，我们需要从描述事物的方法入手。在描述一个事物的时候，可以从一下三个方面出发：
1、这个事物是什么？
2、这个事物能做什么？
3、人们能够用这个事物做什么？
第一种描述是一种结构性观点，即事物的客观存在性。第二种描述是一种功能性的观点，说明事物可利用的价值。第三种描述是一种使用者的观点，说明事物对于使用者的意义，以及使用者可以怎样使用它，得到什么样的利益。它虽然不能够说明事物的本质结构，但从表面上揭示了事物对使用者来说是什么，能做什么，可以获得什么。这正是我们获取用例时考虑问题的角度。
从使用者观点出发描述软件则是非常合适的。使用者观点告诉需求收集人员，使用者希望这个系统是什么样，他将怎样使用这个系统，希望获得什么结果。
使用者观点实际上就是用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，获得结构性的和功能性的内容，最终实现用例，也就实现了使用者的需求。
通过上面的分析，可以得出这样的一些总结：
第一，功能是脱离使用者的愿望而存在的。习惯于从功能看待系统的团队，喜欢从系统的角度出发，说明系统能做什么，而常常系统能做什么并不是使用者关心的。用例是描述使用者愿望的，描述的是使用者对系统的使用要求，用用例来看待系统的团队，则是从使用者的角度出发，说明使用者将在系统里做什么。
第二，功能是孤立的，给一个输入，通过计算机就有一个固定的输出。例如，只要按下开关灯就亮。而用例是系统的，它需要描述谁在什么情况下通过什么方式开灯结果是什么。
第三，如果非要从功能的角度解释用例，那么用例可以理解为一系列完成一个特定目标的功能的组合，针对不同的应用场景，这些功能体现不同的组合方式。
目标与步骤的误区
一个用例是参与者对目标系统的一个愿望，一个完整的事件。为了完成这个事件需要经过很多步骤，但这些步骤不能够完整地反映参与者的目标，不能够作为用例。用例是整个系统的架构基础，用例获取不准确，会导致系统根基不稳，建立出错误的架构。
用例粒度的误区
产生用例粒度错误的原因首先是分不清楚目标和步骤。用例粒度另一个常常被误用的误区是在同一个需求阶段中的用例粒度大小不一。这个问题产生的本质是因为建模者心中没有一个清楚地边界，没有时时检查现阶段处于哪个抽象层次造成的。
业务用例
业务用例（Business Use Case）是用例版型中的一种，专门用于需求阶段的业务建模。在为业务领域建立模型时应当使用这种版型。业务建模是针对客户业务的模型，也就是现在客户的业务是怎么建立模型的。严格来说业务建模与计算机系统无关，它只是业务领域的一个模型，通过业务模型可以得到业务范围，帮助需求人员理解客户业务，并在业务层面上和客户达成共识。业务模型是系统模型的最重要的输入。
业务用例实现
业务用例实现（Business Use Case Realization），也称为业务用例实例，是用例版型中的一种，专门用于需求阶段的业务模型。
业务用例实现就是业务用例的一种实现方式。一个业务可能有多种实现方式，它们的关系可以类比编程上的接口和实现类的关系，同一个接口可以有多个实现类。业务用例实现的意义就在于表达同一项业务的不同实现方式。
业务用例实现是实现对象追溯到需求的一个重要环节。在后续的建模过程中，我们根据业务用例实现将得出关键业务对象，再从业务对象转化到设计对象，从而实现代码。
概念用例
概念模型用来获取业务模型中的关键概念，分析出业务模型中的核心业务结构以得到一个易于理解的业务架构。
作为概念模型中的核心元素，概念用例用来获取业务用例中的核心业务逻辑，这些核心业务逻辑揭示了业务模式，成为业务架构的重要指导。同时，概念用例还是从业务用例到系统用例过渡的非常重要的指导。概念用例并不是必需的，但是对于复杂业务来说，缺少了概念用例，系统用例的产生会显得突兀和生硬。
系统用例
系统用例是用来定义系统范围、获取功能性需求的，系统用例是软件开发的全部范围，是我们得到的最终需求。