第4章需求定义阶段 需求是驱动整个软件开发的因素。如果无法准确了解需求，显然是无法开发 出让用户满意的软件产品来的。需求定义是所有软件项目取得成功的前提，它的 好坏直接关系着软件的成败，目前，软件项目中百分之四十至百分之六十的问题 都是需求分析阶段留下的隐患。但是，需求的获取存在困难性：需求存在于用户 的脑海中，软件开发者需要通过沟通和交流，理解用户的需求，进而以用户能够 理解的方式把需求记录下来：由于需求都是和领域相关的，而软件开发者并不是 领域专家，因此理解用户的需求存在一定的障碍：有时候，用户实际上对自己的 需求也不是很明确，往往要再看到系统之后才了解自己需要什么，不需要什么： 此外，需求在开发过程中会发生变更。鉴于需求获取的困难性和需求的重要性， 需要采用系统化的方法定义需求。 4.1需求定义阶段的主要内容 IEEE软件工程标准中将需求定义为： (1)用户为了解决问题或达到某些目标所需的条件或权能(Capability)。 (2)系统或部件为了满足合同、标准、规范或其它正式规定文档所规定的要求 而需要具备的条件或权能。 (3)反映上面(1)或(2)所描述的条件或权能的文档化表述。 从另一方面看，软件的需求又可以分为三个层次： 1、业务需求：反映了组织或客户对业务的高层次的目标要求。业务需求通 常来自项目投资者、实际用户的管理者或产品策划部门。开发软件都是为了达成 某种业务目标。业务需求一般在项目立项前就给以了定义。 2、用户需求：描述了用户使用软件产品必须要完成的任务或者满足的条件。 用户需求派生自业务需求，用户希望通过软件来达到业务上的目标或者满足业务 上的要求。 3、功能需求：定义了设计开发人员必须实现的软件的功能，使得用户能够 通过软件来完成他们的任务，从而也满足了用户需求和业务需求。 软件需求获取有不同的渠道和形式，以下是经常采用的形式： 面谈和问卷调查：通过和用户面对面的沟通进行需求获取是最经常采用的方
第 4 章 需求定义阶段 需求是驱动整个软件开发的因素。如果无法准确了解需求，显然是无法开发 出让用户满意的软件产品来的。需求定义是所有软件项目取得成功的前提，它的 好坏直接关系着软件的成败，目前，软件项目中百分之四十至百分之六十的问题 都是需求分析阶段留下的隐患。但是，需求的获取存在困难性：需求存在于用户 的脑海中，软件开发者需要通过沟通和交流，理解用户的需求，进而以用户能够 理解的方式把需求记录下来；由于需求都是和领域相关的，而软件开发者并不是 领域专家，因此理解用户的需求存在一定的障碍；有时候，用户实际上对自己的 需求也不是很明确，往往要再看到系统之后才了解自己需要什么，不需要什么； 此外，需求在开发过程中会发生变更。鉴于需求获取的困难性和需求的重要性， 需要采用系统化的方法定义需求。 4.1 需求定义阶段的主要内容 IEEE 软件工程标准中将需求定义为： （1）用户为了解决问题或达到某些目标所需的条件或权能(Capability)。 （2）系统或部件为了满足合同、标准、规范或其它正式规定文档所规定的要求 而需要具备的条件或权能。 （3）反映上面(1)或(2)所描述的条件或权能的文档化表述。 从另一方面看，软件的需求又可以分为三个层次： 1、业务需求：反映了组织或客户对业务的高层次的目标要求。业务需求通 常来自项目投资者、实际用户的管理者或产品策划部门。开发软件都是为了达成 某种业务目标。业务需求一般在项目立项前就给以了定义。 2、用户需求：描述了用户使用软件产品必须要完成的任务或者满足的条件。 用户需求派生自业务需求，用户希望通过软件来达到业务上的目标或者满足业务 上的要求。 3、功能需求：定义了设计开发人员必须实现的软件的功能，使得用户能够 通过软件来完成他们的任务，从而也满足了用户需求和业务需求。 软件需求获取有不同的渠道和形式，以下是经常采用的形式： 面谈和问卷调查；通过和用户面对面的沟通进行需求获取是最经常采用的方
式，为了达到效果，必须具有一定的谈话技巧，否则可能引起用户的反感或 者效率不高。有时，也会结合问卷调查来获取更加明确的需求。 ●小组讨论：通过将用户和开发团队组织在一起通过会议的形式进行小组讨论 也是需求获取经常采用的方式。小组讨论的组织也要有一定的技巧，避免在 会议中经常出现的效率低下，少数人占有了发言权的问题。 ●情景串联：将若干界面通过讲解串联起来，以描述针对特定的功能用户如何 与各个界面进行交互，使得用户可以有直接的感受，从而可以提供直接的意 见和建议。 观察业务流程：对实际的业务流程进行观察，从中了解业务中需要解决的问 题，确定将来利用计算机和软件可以如何重新组织业务流程，以及软件如何 适应用户的实际工作习惯。 ●现有产品和竞争产品的描述文档：如果一个产品的目标是取代现有产品或者 竞争产品，那么现有产品和竞争产品的功能和性能就是目前待开发软件所要 比照的，并且通常待开发产品应该具有比现有产品和竞争产品更好的功能呢 和性能。 ●市场资料：通过各种渠道获取市场上对产品的期望。 需求定义阶段的任务就是获取正确的需求，并通过规范的方式进行需求的表 达。这个阶段的结果将主要体现在“软件需求规格说明”文档中。 有时也会把软件需求描述中的一些内容列成单独的文档，如： ● 补充规格说明：用以描述非功能需求、对软件产品的约束等。 ● 词汇表：用以对需求中涉及到的关键术语进行明确定义。词汇表可以作为需 求分析时识别类的依据之一。 4.2功能需求的表达 4.2.1基于用例的功能需求获取 需求是一个普遍使用的词汇，但是又是一个颇为复杂的概念。需求具有不同 的抽象层次。有些需求非常宏观笼统，例如对教室预订系统的一个需求是“系统 使用要很方便”，有些需求则非常细节具体，例如教室预订的时候先要进行登录。 显然，这种对需求的不同理解不利于需求的获取。 用例(Use Case)提供了以一致的方式来获取和表达功能需求的手段。不同
式，为了达到效果，必须具有一定的谈话技巧，否则可能引起用户的反感或 者效率不高。有时，也会结合问卷调查来获取更加明确的需求。 小组讨论；通过将用户和开发团队组织在一起通过会议的形式进行小组讨论 也是需求获取经常采用的方式。小组讨论的组织也要有一定的技巧，避免在 会议中经常出现的效率低下，少数人占有了发言权的问题。 情景串联；将若干界面通过讲解串联起来，以描述针对特定的功能用户如何 与各个界面进行交互，使得用户可以有直接的感受，从而可以提供直接的意 见和建议。 观察业务流程；对实际的业务流程进行观察，从中了解业务中需要解决的问 题，确定将来利用计算机和软件可以如何重新组织业务流程，以及软件如何 适应用户的实际工作习惯。 现有产品和竞争产品的描述文档；如果一个产品的目标是取代现有产品或者 竞争产品，那么现有产品和竞争产品的功能和性能就是目前待开发软件所要 比照的，并且通常待开发产品应该具有比现有产品和竞争产品更好的功能呢 和性能。 市场资料：通过各种渠道获取市场上对产品的期望。 需求定义阶段的任务就是获取正确的需求，并通过规范的方式进行需求的表 达。这个阶段的结果将主要体现在“软件需求规格说明”文档中。 有时也会把软件需求描述中的一些内容列成单独的文档，如： 补充规格说明：用以描述非功能需求、对软件产品的约束等。 词汇表：用以对需求中涉及到的关键术语进行明确定义。词汇表可以作为需 求分析时识别类的依据之一。 4.2 功能需求的表达 4.2.1 基于用例的功能需求获取 需求是一个普遍使用的词汇，但是又是一个颇为复杂的概念。需求具有不同 的抽象层次。有些需求非常宏观笼统，例如对教室预订系统的一个需求是“系统 使用要很方便”，有些需求则非常细节具体，例如教室预订的时候先要进行登录。 显然，这种对需求的不同理解不利于需求的获取。 用例（Use Case）提供了以一致的方式来获取和表达功能需求的手段。不同
于一般的直接以文字来进行需求表达的方式，用例是从用户的角度，把整个系统 看做黑盒子，通过描述在完成功能过程中用户与系统的交互来刻画需求的手段。 用例是一系列动作和事件的列表，它定义了单个外部参与者(Actor)与系 统之间的交互，通过这种交互，系统提供了可见的价值。 为了理解用例，我们需要区别以下概念： 1)参与者：是位于系统外部、与系统具有交互的事物，可以是人，计算机系统 或组织，例如教室管理员。需要注意的是参与者不是某一个具体的人、系统或组 织，而是一类人、系统或者组织。在UML中，参与者的符号如下图4.1所示。 Actor 图4.1参与者的UML符号 2)场景(Scenario)：某一特定的参与者和系统之间的一次交互，也称为用例实 例。场景是使用系统的一个特定情节或用例的一条执行路径。在获取需求时，我 们通过列举若干重要的场景来发现用例。通俗地理解，场景就是讲一个有主人公 参加的一段故事，这个故事我们会分为若干步骤来描述。例如我们可以针对教室 预订系统，讲述一个小王如何在网上预订教室的一个故事。 ●场景名称：教室预订 参与者实例：教室申请人员小王，教室管理员小张 ●事件流： 1.小王根据活动需要打算使用教室预订系统预订一间教室。他在已接入互联网 的终端上激活了教室预订系统中的教室预订功能。 2.小王填写一份包含申请人信息、使用时间、使用目的、活动人数、希望安排 的教室规格和位置的表单并提交。然后小王等待系统的教室预订答复信息。 3. 教室管理员小张受到系统提醒后，收到了小王的申请表。小张根据目前的教 室预订情况以及小王的申请信息安排相应的教室并确认。 小王通过预留在系统中的电子邮件收到了来自教室预订系统的确认信息，教 室预订成功
于一般的直接以文字来进行需求表达的方式，用例是从用户的角度，把整个系统 看做黑盒子，通过描述在完成功能过程中用户与系统的交互来刻画需求的手段。 用例是一系列动作和事件的列表，它定义了单个外部参与者（Actor）与系 统之间的交互，通过这种交互，系统提供了可见的价值。 为了理解用例，我们需要区别以下概念： 1）参与者：是位于系统外部、与系统具有交互的事物，可以是人，计算机系统 或组织，例如教室管理员。需要注意的是参与者不是某一个具体的人、系统或组 织，而是一类人、系统或者组织。在 UML 中，参与者的符号如下图 4.1 所示。 图 4.1 参与者的 UML 符号 2）场景（Scenario）: 某一特定的参与者和系统之间的一次交互，也称为用例实 例。场景是使用系统的一个特定情节或用例的一条执行路径。在获取需求时，我 们通过列举若干重要的场景来发现用例。通俗地理解，场景就是讲一个有主人公 参加的一段故事，这个故事我们会分为若干步骤来描述。例如我们可以针对教室 预订系统，讲述一个小王如何在网上预订教室的一个故事。 场景名称：教室预订 参与者实例：教室申请人员小王，教室管理员小张 事件流： 1. 小王根据活动需要打算使用教室预订系统预订一间教室。他在已接入互联网 的终端上激活了教室预订系统中的教室预订功能。 2. 小王填写一份包含申请人信息、使用时间、使用目的、活动人数、希望安排 的教室规格和位置的表单并提交。然后小王等待系统的教室预订答复信息。 3. 教室管理员小张受到系统提醒后，收到了小王的申请表。小张根据目前的教 室预订情况以及小王的申请信息安排相应的教室并确认。 4. 小王通过预留在系统中的电子邮件收到了来自教室预订系统的确认信息，教 室预订成功
3)用例：对相关的各种场景（包括成功的、失败的场景）的概括，用来描述参 与者如何使用系统实现其目标。场景是有具体的主人公参加的故事，用例则要把 这些故事上升为一个一般性的过程，在这个过程中主人公被角色所替代，描述中 的一些具体细节被通用的信息所替代。在UML中，用例的符号如下图4.2所示。 Use Case 图4.2用例的UML符号 4.2.2用例的编写方法 用例建模并非是画一个用例的UML符号，而是通过文字对用例进行表述。 用例的编写可以有不同的详略程度：在早期，可以是简略的写一段话，也可以用 几段话描述，而在详细描述的情形下，需要按照规定的格式，用几页纸来加以定 义。 用例的编写格式如下： 1.用例名字 在给用例起名字时，一般采用一个动宾词组，如果你发现很难用一个动宾词 组来刻画，那么很可能是用例选择的不恰当造成的。 2.范围 说明该用例是系统用例还是业务用例。系统用例是软件系统本身的用例。业 务用例是业务功能的描述，通常用于对业务分析。 3.级别 说明该用例是用户目标级别还是子功能级别。用户目标级别代表了一个参与 者会发起的完整用例。子功能级别代表了可能在几个用例中可以重用的子功能用 例，进一步的说明参考4.2.3。 4.主要参与者 定义这个用例中的参与者。用例必须有一个发起者(Initiating Actor),同时 可能有若干个参与这个用例的参与者(Supporting Actor)。注意参与者并不一定 是人。 5.涉众及其关注点 定义在此用例中各个人员关注的因素。 6.前置条件 定义该用例发生的前提条件
3）用例: 对相关的各种场景（包括成功的、失败的场景）的概括，用来描述参 与者如何使用系统实现其目标。场景是有具体的主人公参加的故事，用例则要把 这些故事上升为一个一般性的过程，在这个过程中主人公被角色所替代，描述中 的一些具体细节被通用的信息所替代。在 UML 中，用例的符号如下图 4.2 所示。 图 4.2 用例的 UML 符号 4.2.2 用例的编写方法 用例建模并非是画一个用例的 UML 符号，而是通过文字对用例进行表述。 用例的编写可以有不同的详略程度：在早期，可以是简略的写一段话，也可以用 几段话描述，而在详细描述的情形下，需要按照规定的格式，用几页纸来加以定 义。 用例的编写格式如下： 1. 用例名字 在给用例起名字时，一般采用一个动宾词组，如果你发现很难用一个动宾词 组来刻画，那么很可能是用例选择的不恰当造成的。 2. 范围 说明该用例是系统用例还是业务用例。系统用例是软件系统本身的用例。业 务用例是业务功能的描述，通常用于对业务分析。 3. 级别 说明该用例是用户目标级别还是子功能级别。用户目标级别代表了一个参与 者会发起的完整用例。子功能级别代表了可能在几个用例中可以重用的子功能用 例，进一步的说明参考 4.2.3。 4. 主要参与者 定义这个用例中的参与者。用例必须有一个发起者（Initiating Actor），同时 可能有若干个参与这个用例的参与者（Supporting Actor）。注意参与者并不一定 是人。 5. 涉众及其关注点 定义在此用例中各个人员关注的因素。 6. 前置条件 定义该用例发生的前提条件
7.后置条件 定义该用例完成后，系统中发生的改变以及对参与者的影响。 8.主流程 以事件流的方式定义参与者与系统进行的交互过程。在描述时必须能够清晰 刻画每一个事件的参与者以及产生的结果。主流程指的是正常的、一般的情形。 那些意外的情形将放在扩展中。 9.扩展流程 以事件流的方式描述各种意外或者特别的情形。必须说明是从主成功场景的 第几步跳到扩展中描述的事件流片段进行执行，然后再返回主流程。 10.特殊需求 描述与该用例相关的非功能需求，质量属性或约束。 11.发生频率 描述该用例发生的频繁程度。 以下为教室预订系统的一个用例的例子。 ● 用例名称：ApplyforClassroom ● 范围：系统用例 级别：用户目标 ●主要参与者：教室申请人员，教室管理员 ●涉众及其关注点： ”教室申请人员：希望能够方便、快捷地提出申请，并及时得到系统关于 是否同意使用申请的响应。 >教室管理员：教室使用审批符合无冲突原则。 前置条件：教师或学生具有合法的身份。 ●后置条件：更新教室使用记录，发送教室使用提示信息；或提示用户申请不 批准。 ● 主流程：
7. 后置条件 定义该用例完成后，系统中发生的改变以及对参与者的影响。 8. 主流程 以事件流的方式定义参与者与系统进行的交互过程。在描述时必须能够清晰 刻画每一个事件的参与者以及产生的结果。主流程指的是正常的、一般的情形。 那些意外的情形将放在扩展中。 9. 扩展流程 以事件流的方式描述各种意外或者特别的情形。必须说明是从主成功场景的 第几步跳到扩展中描述的事件流片段进行执行，然后再返回主流程。 10. 特殊需求 描述与该用例相关的非功能需求，质量属性或约束。 11. 发生频率 描述该用例发生的频繁程度。 以下为教室预订系统的一个用例的例子。 用例名称：ApplyforClassroom 范围：系统用例 级别：用户目标 主要参与者：教室申请人员，教室管理员 涉众及其关注点: 教室申请人员：希望能够方便、快捷地提出申请，并及时得到系统关于 是否同意使用申请的响应。 教室管理员：教室使用审批符合无冲突原则。 前置条件：教师或学生具有合法的身份。 后置条件：更新教室使用记录，发送教室使用提示信息；或提示用户申请不 批准。 主流程：
1. 教室申请人员输入身份信息。 2. 系统判别身份信息是否有效。 3.教室申请人员根据活动需要向系统提交教室使用申请，包括申请人、使用时 间、使用目的、活动人数、希望安排的教室规格和位置。 4.教室管理员根据现有的教室使用记录，安排相应的教室。 5.系统向教室申请人员反馈批准教室使用申请，并更新教室使用记录，同时发 送提示信息给教室申请人员。 ●扩展流程： 1.用户身份无法识别 在第2步，系统判别用户身份信息无效 (1)提示用户再次输入； (2)三次输入无效，提示该用户今日无法再次输入。 2.教室无法安排 在第4步，管理员判断该申请中教室的用途与学校的规定相冲突 (1)系统发送消息给申请人 在第4步，管理员查知在要求的时间内符合要求的教室不存在，但是存在地点或 者规格有差别的教室 (1)系统提示申请人该时间不存在符合要求的教室，但是存在与申请人要求有 所差别的教室。 (2)用户可以接受建议或者不接受建议重新提交修改后的申请。 在第4步，管理员查知在要求的时间内符合要求的教室不存在，其他类似的教室
1. 教室申请人员输入身份信息。 2. 系统判别身份信息是否有效。 3. 教室申请人员根据活动需要向系统提交教室使用申请，包括申请人、使用时 间、使用目的、活动人数、希望安排的教室规格和位置。 4. 教室管理员根据现有的教室使用记录，安排相应的教室。 5. 系统向教室申请人员反馈批准教室使用申请，并更新教室使用记录，同时发 送提示信息给教室申请人员。 扩展流程： 1. 用户身份无法识别 在第 2 步，系统判别用户身份信息无效 （1）提示用户再次输入； （2）三次输入无效，提示该用户今日无法再次输入。 2. 教室无法安排 在第 4 步，管理员判断该申请中教室的用途与学校的规定相冲突 （1） 系统发送消息给申请人 在第 4 步，管理员查知在要求的时间内符合要求的教室不存在，但是存在地点或 者规格有差别的教室 （1） 系统提示申请人该时间不存在符合要求的教室，但是存在与申请人要求有 所差别的教室。 （2） 用户可以接受建议或者不接受建议重新提交修改后的申请。 在第 4 步，管理员查知在要求的时间内符合要求的教室不存在，其他类似的教室
也不存在 (1) 系统提示申请人该时间不存在符合要求的教室，要求申请人修改申 请。 (2)用户修改申请并提交。 特殊需求：无 发生频率：可能随时发生，短时间内可能有大量申请。 4.2.3用例模型与用例图 将参与者、多个用例画在一张图上来完整地表达系统的功能需求，就形成了 用例图(Use Case Diagram),用例图加上用例描述就构成了用例模型。 参与者与用例之间的关系是一种通信关系，用带箭头的直线表示，箭头表示 的是访问的方向。发起参与者的箭头指向用例，而支持参与者与用例之间，有可 能箭头指向用例，也有可能指向支持参与者。在建模过程中，箭头可以暂时不画 出来。 Use Case Actor 图4.3参与者与用例的关系 用例之间也存在一定的关系，它们是包含关系、扩展关系和泛化关系。 1.包含关系 包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义， 那么在用例的执行过程中，就可以调用已经定义好的用例。包含关系有以下两种 典型用法： (1)如果两个以上用例有一致的功能，则可以将这个功能分解到另一个用例中， 其他用例可以和这个用例建立包含关系： (2)一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。 包含关系用虚线箭头上面加上符号>表示，箭头的方向从基用
也不存在 （1） 系统提示申请人该时间不存在符合要求的教室，要求申请人修改申 请。 （2） 用户修改申请并提交。 特殊需求：无 发生频率：可能随时发生，短时间内可能有大量申请。 4.2.3 用例模型与用例图 将参与者、多个用例画在一张图上来完整地表达系统的功能需求，就形成了 用例图（Use Case Diagram），用例图加上用例描述就构成了用例模型。 参与者与用例之间的关系是一种通信关系，用带箭头的直线表示，箭头表示 的是访问的方向。发起参与者的箭头指向用例，而支持参与者与用例之间，有可 能箭头指向用例，也有可能指向支持参与者。在建模过程中，箭头可以暂时不画 出来。 图 4.3 参与者与用例的关系 用例之间也存在一定的关系，它们是包含关系、扩展关系和泛化关系。 1. 包含关系 包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义， 那么在用例的执行过程中，就可以调用已经定义好的用例。包含关系有以下两种 典型用法： （1）如果两个以上用例有一致的功能，则可以将这个功能分解到另一个用例中， 其他用例可以和这个用例建立包含关系； （2）一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。 包含关系用虚线箭头上面加上符号>表示，箭头的方向从基用
例指向被包含的用例，如图4.4。 SubmitApplication > CheckAvailability > ProcessApplication 图4.4用例包含关系 图4.4展示了教室预定系统中一个具有包含关系的例子。在申请者申请预 定教室的过程中，他可以通过用例CheckAvailability检查当前申请教室的可用性。 同样管理员在处理申请时，也可以通过用例CheckAvailability检查教室可用性。 2.扩展关系 扩展关系表示用一个用例（可选）扩展了另一个用例（基本用例）的功能。 对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只 在特定条件下才执行的动作放在它的扩展用例中。符号表示> > SubmitApplication CloseConnection 图4.5用例扩展关系 扩展关系的箭头方向是从扩展用例指向被扩展的用例。 图4.5展示了教室预订系统中一个具有扩展关系的例子。用户在提交教室预 定申请的时候，可能遇到与教室预订系统连接关闭的情况，比如浏览器崩溃，或 者申请人误关闭网页。当连接关闭时，CloseConnection,用例打开提交申请用 例，处理提交申请用例的异常行为。 3.泛化关系 泛化关系(generalization)是一种继承关系，子用例将继承基用例的所有行 为、关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。 泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例
例指向被包含的用例，如图 4.4。 图 4.4 用例包含关系 图 4.4 展示了教室预定系统中一个具有包含关系的例子。在申请者申请预 定教室的过程中，他可以通过用例 CheckAvailability 检查当前申请教室的可用性。 同样管理员在处理申请时，也可以通过用例 CheckAvailability 检查教室可用性。 2. 扩展关系 扩展关系表示用一个用例（可选）扩展了另一个用例（基本用例）的功能。 对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只 在特定条件下才执行的动作放在它的扩展用例中。符号表示> 图 4.5 用例扩展关系 扩展关系的箭头方向是从扩展用例指向被扩展的用例。 图4.5展示了教室预订系统中一个具有扩展关系的例子。用户在提交教室预 定申请的时候，可能遇到与教室预订系统连接关闭的情况，比如浏览器崩溃，或 者申请人误关闭网页。当连接关闭时，CloseConnection用例打开提交申请用 例，处理提交申请用例的异常行为。 3. 泛化关系 泛化关系(generalization)是一种继承关系，子用例将继承基用例的所有行 为、关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。 泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例
SubmitApplication SubmitNewApplication SubmitChangedApplication WithdrawApplication 图4.6用例泛化关系 图4.6是教室管理系统中一个具有泛化关系的例子。提交申请用例 (Submitapplication)是一个笼统的提交申请用例，用术语描述了提交申请的过 程。提交一个新的申请(SubmitNewApplication),提交一个修改预定方案的申 请(SubmitChangedApplication)和提交一个撤销原有预定的申请 (WithdrawApplication)是提交申请的三种特殊情况。 通过将用例采用以上关系进行进一步合理组织后，就形成了用例图。 以教室管理系统为例，系统的用例图如图4-7所示。 Classroom Booking System SubmitNewApplication CloseConnection SubmitChangedApplication > 吃 △ WithdrawApplication SubmitApplieation☑ > Applicant CheckAvailability LogIn 》T NotificationSystem ProcessApplication > > RejectApplication ConfirmApplication Admin ArrangeClassroom Acdamic Information System
图 4.6 用例泛化关系 图 4.6 是教室管理系统中一个具有泛化关系的例子。提交申请用例 （SubmitApplication）是一个笼统的提交申请用例，用术语描述了提交申请的过 程。提交一个新的申请（SubmitNewApplication），提交一个修改预定方案的申 请 （ SubmitChangedApplication ） 和 提 交 一 个 撤 销 原 有 预 定 的 申 请 （WithdrawApplication）是提交申请的三种特殊情况。 通过将用例采用以上关系进行进一步合理组织后，就形成了用例图。 以教室管理系统为例，系统的用例图如图 4-7 所示
图4-7教室管理系统用例图 4.2.4用例建模流程与注意点 1.用例建模流程 用例建模可以遵照以下流程开展： (1)识别系统边界：通过确定系统边界后，就规定了系统的范围，也能确定什 么是系统内的，什么是系统外的。 (2)识别参与者：对位于系统外，并且与系统交互的实体进行一一识别。 (3)对每一个参与者，识别其发起的用例：对于每一个参与者，识别其发起的 用例。可以通过描述其涉及的典型场景，再在场景的基础上归纳出用例来。 (4)对用例进行修改：将不同用例中公共的部分抽取出来作为子用例，其它用 例包含它：如果一些用例大部分都相同，只有小部分不同，那么抽取一个公共用 例，其它用例继承它：将一个用例中较为复杂的特殊流程部分抽取出来作为扩展 用例。 在以上步骤的基础上，可以构造完成的用例图。 2.用例建模注意点 用例建模是获取需求的有效方式，但是它本身并非面向对象方法学的一部分。 在用其他方法学进行软件开发，包括传统的结构化方法进行软件开发时，依旧可 以采用用例建模来获取需求。 需要强调的是用例建模主要是写文档，而不是仅仅画用例图。许多初学UML 的人认为利用用例进行需求获取就是仅仅画出用例图，这显然是对用例建模的一 种误解。 在用例建模时，经常面对的用例的颗粒度问题。如果用例中包含的内容过多， 换言之，用例的颗粒度很大的话，很可能系统中只有一个用例或者非常少的用例， 这将给系统的分析、设计和实现带来困难。但是如果将很少的步骤都建模成用例， 系统中可能包含了过多的用例。如何判断用例的颗粒度是合适的呢？首先从定义 上说，用例包含了一般的场景和特殊的场景，所以用例是场景的集合。此外，每 个用例必须能够给用户带来可见的价值。因此，一个用例应该对应一个基本业务 过程单元。当然，那些被包含的用例或者扩展用例并不对应单独的业务过程单元， 而是和其依附的用例构成完成的业务过程单元。 用例反映的是系统”做什么”，而不是“怎么做”。在用例中，表达的是用户希 望如何通过该系统达成自己的目标。实现一个目标是有多种方式的，而且随着技
图4-7 教室管理系统用例图 4.2.4 用例建模流程与注意点 1. 用例建模流程 用例建模可以遵照以下流程开展： （1）识别系统边界：通过确定系统边界后，就规定了系统的范围，也能确定什 么是系统内的，什么是系统外的。 （2）识别参与者：对位于系统外，并且与系统交互的实体进行一一识别。 （3）对每一个参与者，识别其发起的用例：对于每一个参与者，识别其发起的 用例。可以通过描述其涉及的典型场景，再在场景的基础上归纳出用例来。 （4）对用例进行修改：将不同用例中公共的部分抽取出来作为子用例，其它用 例包含它；如果一些用例大部分都相同，只有小部分不同，那么抽取一个公共用 例，其它用例继承它；将一个用例中较为复杂的特殊流程部分抽取出来作为扩展 用例。 在以上步骤的基础上，可以构造完成的用例图。 2. 用例建模注意点 用例建模是获取需求的有效方式，但是它本身并非面向对象方法学的一部分。 在用其他方法学进行软件开发，包括传统的结构化方法进行软件开发时，依旧可 以采用用例建模来获取需求。 需要强调的是用例建模主要是写文档，而不是仅仅画用例图。许多初学 UML 的人认为利用用例进行需求获取就是仅仅画出用例图，这显然是对用例建模的一 种误解。 在用例建模时，经常面对的用例的颗粒度问题。如果用例中包含的内容过多， 换言之，用例的颗粒度很大的话，很可能系统中只有一个用例或者非常少的用例， 这将给系统的分析、设计和实现带来困难。但是如果将很少的步骤都建模成用例， 系统中可能包含了过多的用例。如何判断用例的颗粒度是合适的呢？首先从定义 上说，用例包含了一般的场景和特殊的场景，所以用例是场景的集合。此外，每 个用例必须能够给用户带来可见的价值。因此，一个用例应该对应一个基本业务 过程单元。当然，那些被包含的用例或者扩展用例并不对应单独的业务过程单元， 而是和其依附的用例构成完成的业务过程单元。 用例反映的是系统”做什么”，而不是“怎么做”。在用例中，表达的是用户希 望如何通过该系统达成自己的目标。实现一个目标是有多种方式的，而且随着技