图4-7教室管理系统用例图 4.2.4用例建模流程与注意点 1.用例建模流程 用例建模可以遵照以下流程开展： (1)识别系统边界：通过确定系统边界后，就规定了系统的范围，也能确定什 么是系统内的，什么是系统外的。 (2)识别参与者：对位于系统外，并且与系统交互的实体进行一一识别。 (3)对每一个参与者，识别其发起的用例：对于每一个参与者，识别其发起的 用例。可以通过描述其涉及的典型场景，再在场景的基础上归纳出用例来。 (4)对用例进行修改：将不同用例中公共的部分抽取出来作为子用例，其它用 例包含它：如果一些用例大部分都相同，只有小部分不同，那么抽取一个公共用 例，其它用例继承它：将一个用例中较为复杂的特殊流程部分抽取出来作为扩展 用例。 在以上步骤的基础上，可以构造完成的用例图。 2.用例建模注意点 用例建模是获取需求的有效方式，但是它本身并非面向对象方法学的一部分。 在用其他方法学进行软件开发，包括传统的结构化方法进行软件开发时，依旧可 以采用用例建模来获取需求。 需要强调的是用例建模主要是写文档，而不是仅仅画用例图。许多初学UML 的人认为利用用例进行需求获取就是仅仅画出用例图，这显然是对用例建模的一 种误解。 在用例建模时，经常面对的用例的颗粒度问题。如果用例中包含的内容过多， 换言之，用例的颗粒度很大的话，很可能系统中只有一个用例或者非常少的用例， 这将给系统的分析、设计和实现带来困难。但是如果将很少的步骤都建模成用例， 系统中可能包含了过多的用例。如何判断用例的颗粒度是合适的呢？首先从定义 上说，用例包含了一般的场景和特殊的场景，所以用例是场景的集合。此外，每 个用例必须能够给用户带来可见的价值。因此，一个用例应该对应一个基本业务 过程单元。当然，那些被包含的用例或者扩展用例并不对应单独的业务过程单元， 而是和其依附的用例构成完成的业务过程单元。 用例反映的是系统”做什么”，而不是“怎么做”。在用例中，表达的是用户希 望如何通过该系统达成自己的目标。实现一个目标是有多种方式的，而且随着技图4-7 教室管理系统用例图 4.2.4 用例建模流程与注意点 1. 用例建模流程 用例建模可以遵照以下流程开展： （1）识别系统边界：通过确定系统边界后，就规定了系统的范围，也能确定什 么是系统内的，什么是系统外的。 （2）识别参与者：对位于系统外，并且与系统交互的实体进行一一识别。 （3）对每一个参与者，识别其发起的用例：对于每一个参与者，识别其发起的 用例。可以通过描述其涉及的典型场景，再在场景的基础上归纳出用例来。 （4）对用例进行修改：将不同用例中公共的部分抽取出来作为子用例，其它用 例包含它；如果一些用例大部分都相同，只有小部分不同，那么抽取一个公共用 例，其它用例继承它；将一个用例中较为复杂的特殊流程部分抽取出来作为扩展 用例。 在以上步骤的基础上，可以构造完成的用例图。 2. 用例建模注意点 用例建模是获取需求的有效方式，但是它本身并非面向对象方法学的一部分。 在用其他方法学进行软件开发，包括传统的结构化方法进行软件开发时，依旧可 以采用用例建模来获取需求。 需要强调的是用例建模主要是写文档，而不是仅仅画用例图。许多初学 UML 的人认为利用用例进行需求获取就是仅仅画出用例图，这显然是对用例建模的一 种误解。 在用例建模时，经常面对的用例的颗粒度问题。如果用例中包含的内容过多， 换言之，用例的颗粒度很大的话，很可能系统中只有一个用例或者非常少的用例， 这将给系统的分析、设计和实现带来困难。但是如果将很少的步骤都建模成用例， 系统中可能包含了过多的用例。如何判断用例的颗粒度是合适的呢？首先从定义 上说，用例包含了一般的场景和特殊的场景，所以用例是场景的集合。此外，每 个用例必须能够给用户带来可见的价值。因此，一个用例应该对应一个基本业务 过程单元。当然，那些被包含的用例或者扩展用例并不对应单独的业务过程单元， 而是和其依附的用例构成完成的业务过程单元。 用例反映的是系统”做什么”，而不是“怎么做”。在用例中，表达的是用户希 望如何通过该系统达成自己的目标。实现一个目标是有多种方式的，而且随着技