第4章需求获取

1、第四章第四章 需求获取需求获取 4.1 4.1 软件需求的初始表示软件需求的初始表示 4.2 4.2 需求获取的过程模型需求获取的过程模型 4.3 4.3 定义软件问题定义软件问题 4.4 4.4 创建框架用例创建框架用例 4.5 4.5 精化用例精化用例 4.6 4.6 评审用例模型评审用例模型 2021-6-23 1 第四章第四章 需求获取需求获取 目标目标 完整地收集、整理利益相关方对目标软件系统的完整地收集、整理利益相关方对目标软件系统的 需求，并以其容易理解的业务语言阐述这些需求，需求，并以其容易理解的业务语言阐述这些需求， 形成文档形成文档 意义意义 需求获取是需求工程中后续活动的

2、基础，需求工需求获取是需求工程中后续活动的基础，需求工 程又是后续软件开发活动的基础程又是后续软件开发活动的基础 需求获取对于软件项目的成败具有决定性影响需求获取对于软件项目的成败具有决定性影响 主要完成者主要完成者 是来自软件开发方的需求工程师是来自软件开发方的需求工程师 其他参与者其他参与者 来自委托方或投资方的客户来自委托方或投资方的客户 来自使用方的用户来自使用方的用户 项目软件经理和质量保证工程师项目软件经理和质量保证工程师 2021-6-23 2 需求获取需求获取 需求获取活动的输入制品包括：需求获取活动的输入制品包括： u有关项目目标、范围及价值的概述性文档有关项目目标、范围及价

3、值的概述性文档 u项目合同或任务书项目合同或任务书 u经评审通过的本次需求工程迭代的工作计划。经评审通过的本次需求工程迭代的工作计划。 其输出制品：其输出制品： u描述软件需求的初步的需求模型。描述软件需求的初步的需求模型。 该模型经过需求分析后将进化为正式的需求模型并该模型经过需求分析后将进化为正式的需求模型并 成为需求规约的主要组成部分。成为需求规约的主要组成部分。 2021-6-23 3 4.1 4.1 软件需求的初始表示软件需求的初始表示 本节介绍软件需求的用例和用例的初始表示。本节介绍软件需求的用例和用例的初始表示。 在需求获取过程中用到的在需求获取过程中用到的UMLUML图形机制主

4、要是用例图形机制主要是用例 图、类图与活动图。图、类图与活动图。 2021-6-23 4 4.1.1 4.1.1 用例用例 （一）用例的概念（一）用例的概念 从外部用户的视角看从外部用户的视角看 是是参与者参与者(actor)(actor)与目标软件系统之间一次典型的交互与目标软件系统之间一次典型的交互 作用，其效果就是参与者在软件系统的帮助下完成了作用，其效果就是参与者在软件系统的帮助下完成了 某项业务功能，或达成了某项业务目标。某项业务功能，或达成了某项业务目标。 从软件系统内部的视角看从软件系统内部的视角看 用例代表着系统执行的一系列动作，动作执行的结果用例代表着系统执行的一系列动作，动

5、作执行的结果 能够被外部的参与者所察觉能够被外部的参与者所察觉。 2021-6-23 5 用例用例 p如果多个用户在使用目标软件系统时扮演如果多个用户在使用目标软件系统时扮演 同一角色，这些用户用单一参与者表示。同一角色，这些用户用单一参与者表示。 p如果一个用户扮演多种角色，则需要用多如果一个用户扮演多种角色，则需要用多 个参与者来表示同一用户。个参与者来表示同一用户。 p参与者可以是一类用户，也可以是其他软参与者可以是一类用户，也可以是其他软 件系统或物理设备。件系统或物理设备。 2021-6-23 6 参与者参与者 也叫执行者（教材所用术语）、外部参与者也叫执行者（教材所用术语）、外部参

6、与者 是指外部用户或外部实体交互过程中扮演的是指外部用户或外部实体交互过程中扮演的角色角色，它，它 与软件系统交换信息（并使用本系统的功能）与软件系统交换信息（并使用本系统的功能） 用例用例 例如，在课程注册管理系统中，主要的参与者有：例如，在课程注册管理系统中，主要的参与者有： “Registrar”“Registrar”（教务管理员）（教务管理员） “Student” “Student”（学生）、（学生）、“Teacher”“Teacher”（任课教师）（任课教师） “Billing System”“Billing System”（收费系统）（收费系统） 在实际应用中，有些用例不由任何物理

7、实体触发，在实际应用中，有些用例不由任何物理实体触发， 而是由时间或外部事件来触发，此时可设置而是由时间或外部事件来触发，此时可设置定时器定时器 （TimerTimer）或或事件发送者事件发送者作为参与者。作为参与者。 例如，如果要求在每学期第一周的星期日自动触发例如，如果要求在每学期第一周的星期日自动触发“汇汇 总选课计划总选课计划”用例，那么该用例的参与者应为定时器。用例，那么该用例的参与者应为定时器。 2021-6-23 7 用例用例 相对相对独立性独立性和和完整性完整性是用例必备的两项特征是用例必备的两项特征 即，用例表示参与者为达成一项相对独立、完整的业务即，用例表示参与者为达成一项

8、相对独立、完整的业务 目标而与目标软件系统协同完成的功能。目标而与目标软件系统协同完成的功能。 为了清晰地描述这种外部可见功能，用例往往进一为了清晰地描述这种外部可见功能，用例往往进一 步表示为参与者与软件系统之间的步表示为参与者与软件系统之间的交互动作序列交互动作序列。 u对于参与者而言，这些交互的目的或者效果在于达成对于参与者而言，这些交互的目的或者效果在于达成 其业务目标；对于待开发的软件系统而言，交互的过其业务目标；对于待开发的软件系统而言，交互的过 程即是该项外部可见功能的使用过程。程即是该项外部可见功能的使用过程。 例如，课程注册管理系统中的用例有：例如，课程注册管理系统中的用例有

9、：供教务管理员使供教务管理员使 用的用的“制订课表制订课表”用例、供教务管理员、学生和教师使用例、供教务管理员、学生和教师使 用的用的“查询课表及课程信息查询课表及课程信息”用例，供学生使用的用例，供学生使用的“制制 订选课计划订选课计划”用例，供教师使用的用例，供教师使用的“查询选课学生信息查询选课学生信息” 用例等。用例等。 2021-6-23 8 用例用例 （二）用例与软件需求之间的关系（二）用例与软件需求之间的关系 根据用例的定义易知，用例是根据用例的定义易知，用例是功能性软件功能性软件 需求需求的的主体部分主体部分。 u在用例驱动的需求工程中，用例描述将占据需在用例驱动的需求工程中，

10、用例描述将占据需 求获取结果文档的大部分篇幅。求获取结果文档的大部分篇幅。 u全局性的业务规则、大部分非功能性的软件需全局性的业务规则、大部分非功能性的软件需 求并不适于在用例中描述。求并不适于在用例中描述。 u某些仅作用于单个或少数用例的业务规则可以某些仅作用于单个或少数用例的业务规则可以 直接在用例描述中出现。直接在用例描述中出现。 u仅约束单个或少数用例的非功能性需求也可以仅约束单个或少数用例的非功能性需求也可以 在用例描述中阐明。在用例描述中阐明。 2021-6-23 9 用例用例 （三）框架用例（三）框架用例 框架用例是指宏观功能已基本明确但内容尚不框架用例是指宏观功能已基本明确但内

11、容尚不 完整的用例。完整的用例。 u引入框架用例的概念是为了满足需求获取过程中引入框架用例的概念是为了满足需求获取过程中 记录、表示细节尚未完全确定的用例的需要记录、表示细节尚未完全确定的用例的需要。 2021-6-23 10 4.1.2 4.1.2 用例图用例图 UMLUML的用例模型的用例模型由由一到多幅一到多幅用例图用例图构成，它构成，它 们表示从软件系统的们表示从软件系统的外部使用者外部使用者的角度看的角度看 到的到的各项系统功能各项系统功能，并清晰地说明，并清晰地说明软件系软件系 统的边界统的边界，即，用例图中的所有用例的集，即，用例图中的所有用例的集 合构成目标软件系统应该提供的功

12、能，除合构成目标软件系统应该提供的功能，除 此之外软件系统不再承诺其他功能。此之外软件系统不再承诺其他功能。 2021-6-23 11 图 图4.1 4.1课程注册管理系统的 课程注册管理系统的 用例图用例图 2021-6-23 12 （一）参与者与用例之间的关系（一）参与者与用例之间的关系 参与者与用例之间的关系在用例图中表示为它们之间的参与者与用例之间的关系在用例图中表示为它们之间的 连接边连接边，其意义为：参与者触发用例的执行，向用例提其意义为：参与者触发用例的执行，向用例提 供信息或者从用例获取信息。供信息或者从用例获取信息。 触发用例执行的参与者称为触发用例执行的参与者称为主动参与者

13、主动参与者，仅从用例获取，仅从用例获取 信息的参与者称为信息的参与者称为被动参与者被动参与者。 参与者与用例之间的连接边通常为参与者与用例之间的连接边通常为无向边无向边。仅在以下两。仅在以下两 种情形下才考虑采用有向边：种情形下才考虑采用有向边： u当有多个参与者与用例相连时，有时为了强调其中某个参与当有多个参与者与用例相连时，有时为了强调其中某个参与 者是该用例的主要参与者（者是该用例的主要参与者（primary actorprimary actor），则从该参与），则从该参与 者到用例之间连一条有向边。在这种有向边之上，信息传递者到用例之间连一条有向边。在这种有向边之上，信息传递 仍可能是

14、双向的。参与者需要提供初始信息以启动用例，用仍可能是双向的。参与者需要提供初始信息以启动用例，用 例的执行结果也可反馈至参与者。例的执行结果也可反馈至参与者。 u为了强调被动参与者仅从用例获取信息，而不向用例提供信为了强调被动参与者仅从用例获取信息，而不向用例提供信 息，可以从用例到被动参与者之间连一条有向边。息，可以从用例到被动参与者之间连一条有向边。 2021-6-23 13 （二）用例之间的关系（二）用例之间的关系 用例之间的关系主要有三种：用例之间的关系主要有三种：包含包含 （includeinclude）、扩展（）、扩展（extendextend）和继承）和继承 。 包含关系：包含关

15、系： 如果如果B B是是A A的某项子功能，并且建模者确切地知的某项子功能，并且建模者确切地知 道在道在A A所对应的动作序列中何时将调用所对应的动作序列中何时将调用B B，则称，则称 用例用例A A包含用例包含用例B B。包含关系经常被用来将多个。包含关系经常被用来将多个 用例中用例中公共的子功能公共的子功能项提取出来，以避免重复项提取出来，以避免重复 和冗余。和冗余。 例如，在课程注册管理系统中，除例如，在课程注册管理系统中，除“汇总选课计汇总选课计 划划”外的其他用例均要求验证用户的身份，可将外的其他用例均要求验证用户的身份，可将 此子功能表示为此子功能表示为“用户身份验证用户身份验证”

16、用例，并在原用例，并在原 用例与此用例之间建立包含关系，见用例与此用例之间建立包含关系，见图图4.14.1。 2021-6-23 14 扩展关系扩展关系 如果如果A A与与B B相似，但相似，但A A的功能较的功能较B B多，多，A A的动作序列是通过在的动作序列是通过在B B 的动作序列中的某些执行点上插入附加的动作序列而构成的，的动作序列中的某些执行点上插入附加的动作序列而构成的， 则称用例则称用例A A扩展用例扩展用例B B。 在扩展用例的情形下，允许建模者不确定何时会出现导致在扩展用例的情形下，允许建模者不确定何时会出现导致 附加动作序列必须执行的情况，甚至不确定这些情况是否会附加动作

17、序列必须执行的情况，甚至不确定这些情况是否会 发生。发生。 A A的附加动作在的附加动作在B B的动作序列中的插入点称为的动作序列中的插入点称为A A对对B B的的扩展点扩展点。 扩展关系经常用来扩展关系经常用来区隔区隔 正常的业务处理功能和带有例外处正常的业务处理功能和带有例外处 理的功能理的功能，这样可避免例外处理逻辑搅乱或湮灭，这样可避免例外处理逻辑搅乱或湮灭 正常处理逻正常处理逻 辑。辑。 例如，假定在课程注册管理系统中每门课程设置所容纳的例如，假定在课程注册管理系统中每门课程设置所容纳的 学生数量有限制，一旦超出限制需经任课教师同意。可设置学生数量有限制，一旦超出限制需经任课教师同意

18、。可设置 “制订选课计划制订选课计划 考虑学生数量限制考虑学生数量限制”用例，并将其作为用例，并将其作为 “制订选课计划制订选课计划”的扩展用例，见的扩展用例，见图图4.14.1。 2021-6-23 15 继承关系继承关系 如果如果A A与与B B相似，但相似，但A A的动作序列是通过改写的动作序列是通过改写B B的部分动作的部分动作 或者扩展或者扩展B B的部分动作而获得的，则称用例的部分动作而获得的，则称用例A A继承用例继承用例B B。 用例之间的继承关系同样须符合针对类间继承关系的可用例之间的继承关系同样须符合针对类间继承关系的可 替代性原则：任何特化用例都可应用于其泛化用例能够替代

19、性原则：任何特化用例都可应用于其泛化用例能够 应用的场合。应用的场合。 继承继承关系与扩展关系关系与扩展关系非常非常类似，在类似，在面对实际问题时，可面对实际问题时，可 按以下规则来决定二者的取舍：按以下规则来决定二者的取舍：如果能够指出明确的扩如果能够指出明确的扩 展点，则采用扩展关系；如果希望区隔正常的业务处理展点，则采用扩展关系；如果希望区隔正常的业务处理 功能和带有例外处理的功能，应采用扩展关系；如果不功能和带有例外处理的功能，应采用扩展关系；如果不 仅要插入新动作，而且要修改原动作，则采用继承关系。仅要插入新动作，而且要修改原动作，则采用继承关系。 如，假定在课程注册管理系统中，要求

20、每名学生选修的如，假定在课程注册管理系统中，要求每名学生选修的 课程的总学时数不得超出指定的限额，但对优异生课程的总学时数不得超出指定的限额，但对优异生 （Excellent StudentExcellent Student），此限额可以放宽，那么可设），此限额可以放宽，那么可设 置置“制订优异生选课计划制订优异生选课计划”用例，并让其继承用例，并让其继承“制订选制订选 课计划课计划 考虑学生数量限制考虑学生数量限制”用例，见用例，见图图4.14.1 2021-6-23 16 用例之间的关系用例之间的关系 为避免语义上的复杂性，用例之间的关系不应超过为避免语义上的复杂性，用例之间的关系不应超过

21、 两层。两层。 u例如，如果用例例如，如果用例A A、B B、C C、D D之间依次两两之间都有包之间依次两两之间都有包 含关系，则表明建模者采用了功能分解方法，这与用含关系，则表明建模者采用了功能分解方法，这与用 例建模所处的需求工程阶段不协调，也不符合面向对例建模所处的需求工程阶段不协调，也不符合面向对 象的思维方式。象的思维方式。 在用例图中，每个参与者必须至少与一个用例相关在用例图中，每个参与者必须至少与一个用例相关 联；反之，联；反之，除被包含、被扩展的用例外除被包含、被扩展的用例外，每个用例，每个用例 必经至少与一个参与者相关联。必经至少与一个参与者相关联。 如果一个参与者未与任何

22、用例相关联，那么它就没如果一个参与者未与任何用例相关联，那么它就没 有必要在用例图中出现。有必要在用例图中出现。 如果被继承的用例未与任何参与者相关联，那么应如果被继承的用例未与任何参与者相关联，那么应 该将它与其（用例继承意义上的）特化用例合并。该将它与其（用例继承意义上的）特化用例合并。 2021-6-23 17 用例之间的关系用例之间的关系 （三）参与者之间的关系（三）参与者之间的关系 继承关系继承关系 其意义与面向对象中基本的继承关系相似，但它主要强其意义与面向对象中基本的继承关系相似，但它主要强 调子类参与者对父类参与者与用例之间的交互行为的继调子类参与者对父类参与者与用例之间的交互

23、行为的继 承。如果参与者承。如果参与者B B继承参与者继承参与者A A，A A触发执行用例触发执行用例UCUC，那么，那么 B B与与UCUC之间的触发执行关系即不必显式表示。之间的触发执行关系即不必显式表示。 例如，在例如，在图图4.14.1中，参与者中，参与者“Excellent Student”“Excellent Student”隐含隐含 地触发执行地触发执行“查询课表及课程信息查询课表及课程信息”用例，但是，它与用例，但是，它与 “制订选课计划制订选课计划”用例及其扩展用例用例及其扩展用例“制订选课计划制订选课计划 考考 虑学生数量限制虑学生数量限制”之间并无触发执行关系，因为它直接

24、之间并无触发执行关系，因为它直接 触发后者的特化用例触发后者的特化用例“制订优异生选课计划制订优异生选课计划”。 2021-6-23 18 用例之间的关系用例之间的关系 （四）布局规则（四）布局规则 用例图的布局攸关其用例图的布局攸关其可理解性可理解性。建议读者采纳以下。建议读者采纳以下 布局规则：布局规则： 主要的参与者应置于用例图的左上区域。主要的参与者应置于用例图的左上区域。 触发用例执行的主动参与者应位于用例的左面，触发用例执行的主动参与者应位于用例的左面， 接收用例产生的信息的被动参与者应置于用例的接收用例产生的信息的被动参与者应置于用例的 右面。右面。 多个用例沿垂直方向排列。如果

25、用例多个用例沿垂直方向排列。如果用例A A的执行时间的执行时间 一定在一定在B B之前，那么最好将之前，那么最好将A A置于置于B B之上。之上。 在水平方向绘制包含关系，并将被包含的用例置在水平方向绘制包含关系，并将被包含的用例置 于包含用例的右侧。于包含用例的右侧。 在垂直方向绘制扩展和继承关系，并将扩展用例在垂直方向绘制扩展和继承关系，并将扩展用例 置于被扩展用例的下方。将继承用例置于被继承置于被扩展用例的下方。将继承用例置于被继承 用例的下方。用例的下方。 2021-6-23 19 4.1.3 4.1.3 用例的表示用例的表示 在用例图中，限于版在用例图中，限于版 面，只能标示每个用面

26、，只能标示每个用 例的名称，不可能精例的名称，不可能精 确地描述用例的功能、确地描述用例的功能、 参与者与用例之间的参与者与用例之间的 信息流、交互动作序信息流、交互动作序 列等。列等。 有必要针对用例图中有必要针对用例图中 的每个用例，给出文的每个用例，给出文 档化的描述，档化的描述， 内容包括：内容包括： 用例名称用例名称 用例的功能或其业务目标用例的功能或其业务目标 与用例有关的参与者与用例有关的参与者 用例执行的触发条件（可用例执行的触发条件（可 选）选） 用例执行的前置条件（可用例执行的前置条件（可 选）选） 基本交互动作过程基本交互动作过程 扩展交互动作过程（可选）扩展交互动作过程

27、（可选） 用例执行完毕时的后置条用例执行完毕时的后置条 件（可选）件（可选） 业务规则（可选）业务规则（可选） 非功能需求（可选）非功能需求（可选） 2021-6-23 20 2021-6-23 21 4.1.4 4.1.4 类图类图 类图描述面向对象软件系统的类图描述面向对象软件系统的静态结构静态结构。 u类类图的图的结点结点表示系统中的类及其表示系统中的类及其属性和属性和操作操作 u类类图的图的边边表示类之间的表示类之间的关系关系。 在需求获取或业务理解在需求获取或业务理解的过程中，类图可用于的过程中，类图可用于 表达表达领域概念模型领域概念模型，即业务领域中的概念及概，即业务领域中的概念

28、及概 念之间的关系；念之间的关系； 在需求分析阶段在需求分析阶段，类图可用来表示软件需求模，类图可用来表示软件需求模 型之型之静态结构静态结构部分；部分； 在软件设计和实现阶段在软件设计和实现阶段，类图表示，类图表示软件的结构软件的结构 及详细设计及详细设计。 l类图的构造在面向对象分析与设计过程中处于类图的构造在面向对象分析与设计过程中处于 核心地位核心地位。 2021-6-23 22 图图4.2 4.2 课程注册管理系统的类图课程注册管理系统的类图 2021-6-23 23 （一）类（一）类 类的属性在类的属性在UMLUML中表示为：中表示为： 可见性可见性 名称名称:类型类型多重性多重性

29、= = 初值初值约束特性约束特性 类的操作在类的操作在UMLUML中表示为：中表示为： 可见性可见性 名称名称(参数表参数表):):返回类型返回类型约束特性约束特性 l其中处于其中处于“”“”与与“”“”之间的语法成分是可选项。之间的语法成分是可选项。在需求在需求 工程阶段工程阶段，为聚焦于需求的获取和分析并保持需求模型的，为聚焦于需求的获取和分析并保持需求模型的 简洁性，在不是特别必要的情况下并不关心这些可选项，简洁性，在不是特别必要的情况下并不关心这些可选项， 也不必在需求模型中示出。也不必在需求模型中示出。 2021-6-23 24 （a a）最简化的类图元（隐藏属性和操作部分）最简化的

30、类图元（隐藏属性和操作部分） （b b）隐藏操作部分的类图元）隐藏操作部分的类图元 （c c）隐藏属性部分的类图元）隐藏属性部分的类图元 （d d）完整的类图元）完整的类图元 2021-6-23 25 图图4.3 类的表示图元类的表示图元 （二）类之间的关系（二）类之间的关系 除面向对象基本概念中的除面向对象基本概念中的 继承和聚合外继承和聚合外，UMLUML还可还可 以表示类之间的以表示类之间的关联、依关联、依 赖和实现赖和实现关系。关系。 UMLUML将聚合关系进一步细将聚合关系进一步细 分为（一般）聚合和组合分为（一般）聚合和组合 两种。它们的表示图元如两种。它们的表示图元如 图图4.4

31、4.4所示。所示。 （a a）关联关系的表示）关联关系的表示 2021-6-23 26 （b b）聚合关系的表示）聚合关系的表示 （b）聚合关系的表示 图图4.4 4.4 类间关系的表示图元类间关系的表示图元 2021-6-23 27 c）组合关系的表示 （d）依赖关系的表示 （e）实现关系的表示 （f）继承关系的表示 关联关系关联关系表示两个类之间迥异于继承关系的一种语义上、表示两个类之间迥异于继承关系的一种语义上、 逻辑上的联系。逻辑上的联系。 u在代码中表现为：在在代码中表现为：在A A类中有一个成员变量，变量的类型类中有一个成员变量，变量的类型 是是B B类类 聚合关系是关联关系之一种

32、。聚合关系是关联关系之一种。 u如，在如，在“学生学生”与与“老师老师”之间存在一种既非继承、也非聚合的之间存在一种既非继承、也非聚合的 语义关联，因为一名学生可能选修某名老师所开的课程设置。语义关联，因为一名学生可能选修某名老师所开的课程设置。 在关联关系的表示图元的两端，可以标示参与在关联关系的表示图元的两端，可以标示参与关联的多重关联的多重 性性（multiplicitymultiplicity）、）、角色名角色名和和约束特性约束特性。 2021-6-23 28 类之间的关系类之间的关系 类之间的关系类之间的关系 （1 1）多重性多重性说明位于关联端的类可以有多少个实例对象说明位于关联端

33、的类可以有多少个实例对象 与另一端的类的单个实例对象相联系，它表示参与关联的与另一端的类的单个实例对象相联系，它表示参与关联的 两个类的对象之间的两个类的对象之间的数量数量对应关系。对应关系。 UMLUML的多重性表示符有：的多重性表示符有： 1 1，0.10.1（0 0或者或者1 1个），个），0.0.* * （0 0到任意多个），到任意多个），1.1.* * （1 1到任意多个），到任意多个），* *（与（与0.0.* *相同），相同）， m.n m.n（m m到到n n个，要求个，要求m nm n），），n.n.* *（n n到任意多个）到任意多个）等。等。 u如，在图如，在图4.24.

34、2中，每名学生可选中，每名学生可选0 0到多门课程设置，每门课程到多门课程设置，每门课程 设置可以容纳设置可以容纳0 0到多名学生。到多名学生。 l多重性的后两种表示符涉及到具体的数量上下界，这样多重性的后两种表示符涉及到具体的数量上下界，这样 虽然可以在可视化模型中直接体现相关的业务规则，但虽然可以在可视化模型中直接体现相关的业务规则，但 是一旦规则改变，模型即须修改，所以本书并不推荐此是一旦规则改变，模型即须修改，所以本书并不推荐此 种用法。种用法。 l具体的数量限制规则在类图的伴随文档中描述即可，不具体的数量限制规则在类图的伴随文档中描述即可，不 必直接标定于必直接标定于UMLUML模型

35、图之中。模型图之中。 2021-6-23 29 类之间的关系类之间的关系 （2 2）角色名描述参与关联的类的对象在关联）角色名描述参与关联的类的对象在关联 关系中扮演的角色或发挥的作用。关系中扮演的角色或发挥的作用。 例如，在例如，在“学生学生”与与“教师教师”之间的关联中，之间的关联中， 前者扮演前者扮演“学习者学习者”的角色，后者扮演的角色，后者扮演“知识知识 传授者传授者”的角色。的角色。 （3 3）约束特性说明针对参与关联的对象或对）约束特性说明针对参与关联的对象或对 象集的逻辑约束。在需求工程阶段应该直接象集的逻辑约束。在需求工程阶段应该直接 采用自然语言来表示这种约束。采用自然语言

36、来表示这种约束。 例如，例如，图图4.24.2中的中的“ordered” “ordered” 表示，如果表示，如果 一门课程设置有多位教师，那么他们之间是有一门课程设置有多位教师，那么他们之间是有 序的，因为主讲教师必须排在助理教师之前。序的，因为主讲教师必须排在助理教师之前。 2021-6-23 30 类之间的关系类之间的关系 UMLUML将面向对象中的将面向对象中的聚合概念聚合概念区分为（区分为（共享）共享） 聚合（聚合（aggregationaggregation）和和组合（组合（compositioncomposition） 两种关系两种关系。 u在在聚合关系聚合关系下，作为部件类的对

37、象可能是多个整下，作为部件类的对象可能是多个整 体类的对象中的组成部分，比如一名学生可以同体类的对象中的组成部分，比如一名学生可以同 时参与多个兴趣小组时参与多个兴趣小组； u在在组合关系组合关系下，一个部件类的对象只能位于一个下，一个部件类的对象只能位于一个 整体类的对象之中，一旦整体类对象消亡，其中整体类的对象之中，一旦整体类对象消亡，其中 包含的部件类对象也不能苟活。换句话说，整体包含的部件类对象也不能苟活。换句话说，整体 类必须具备完整的管理部件类生命周期的职责。类必须具备完整的管理部件类生命周期的职责。 例如，根据图例如，根据图4.24.2，如果一门，如果一门“课程课程”被取消，那被

38、取消，那 么，其中包含的所有么，其中包含的所有“课程设置课程设置”对象均须删除。对象均须删除。 2021-6-23 31 UML表示法表示法 UML表示法表示法 类之间的关系类之间的关系 假如假如A A类的某个方法中，使用了类的某个方法中，使用了B B类，那么类，那么 就说就说A A类依赖于类依赖于B B类，它们是依赖关系。类，它们是依赖关系。 A A类的某个方法使用类的某个方法使用B B类，可能是方法的参类，可能是方法的参 数是数是B B类，也可能是在方法中获得了一个类，也可能是在方法中获得了一个B B 类实例。但无论是哪种情况，类实例。但无论是哪种情况，B B类在类在A A类中类中 都是以

39、都是以局部变量局部变量的形式存在的。的形式存在的。 u依赖关系是有向的依赖关系是有向的 2021-6-23 32 类之间的关系类之间的关系 实现关系实现关系是是一种特殊的一种特殊的依赖关系依赖关系，它表示，它表示 一个类实现了另一个类中定义的对外接口一个类实现了另一个类中定义的对外接口。 2021-6-23 33 类类Circle、Rectangle 实现了接口实现了接口Shape的操的操 作作 Shape + Draw () Circle + Draw () Rectangle + Drarw () 依赖和实现关系所处的依赖和实现关系所处的抽象级别明显低于抽象级别明显低于 继承和关联关系，它

40、们与软件需求的关系继承和关联关系，它们与软件需求的关系 不大，但与详细设计和软件实现的关系较不大，但与详细设计和软件实现的关系较 密切。所以，在需求工程中，尤其是在需密切。所以，在需求工程中，尤其是在需 求工程的早期，不必过多考虑依赖和实现求工程的早期，不必过多考虑依赖和实现 关系。关系。 2021-6-23 34 类之间的关系类之间的关系 按照关联关系的定义，聚合和组合都是一按照关联关系的定义，聚合和组合都是一 种特殊的关联关系，只不过这种关联具有种特殊的关联关系，只不过这种关联具有 明确的部分明确的部分整体含义而已。整体含义而已。 关联和继承都是依赖关系之一种，关联和关联和继承都是依赖关系

41、之一种，关联和 继承之于依赖，相当于聚合和组合之于关继承之于依赖，相当于聚合和组合之于关 联。从耦合度的角度看，继承关系最强，联。从耦合度的角度看，继承关系最强， 组合次之，普通聚合再次之，除组合和聚组合次之，普通聚合再次之，除组合和聚 合之外的普通关联关系最弱。合之外的普通关联关系最弱。 2021-6-23 35 （三）关联的方向（三）关联的方向 关联关系在关联关系在分析模型中分析模型中表示表示两个类的逻辑联系两个类的逻辑联系 在在设计模型和实现模型设计模型和实现模型中，关联的含义将以此为中，关联的含义将以此为 基础逐步精化。基础逐步精化。 设计模型中的关联关系表示设计模型中的关联关系表示参

42、与关联的类参与关联的类必须具必须具 有有查询职责查询职责和和关系维护职责关系维护职责。 u查询职责查询职责是指，如果类是指，如果类A A、B B之间存在关联，则之间存在关联，则A A类应负类应负 责针对任一责针对任一A A类的对象类的对象a a查询与查询与a a链接的所有链接的所有B B类的对象，类的对象， 并且并且B B类也要负责提供反向的查询功能。类也要负责提供反向的查询功能。 u关系维护职责关系维护职责指，参与关联的对象在其生命周期中的指，参与关联的对象在其生命周期中的 任意时刻均须维护它与位于另一关联端的对象之间的任意时刻均须维护它与位于另一关联端的对象之间的 链接。链接。 2021-

43、6-23 36 关联的方向关联的方向 关联可以有方向：关联可以有方向：有向关联又称为有向关联又称为导航（导航（NavigationNavigation），）， 意义是：从一个关联端（通过查询操作）沿导航的方向可意义是：从一个关联端（通过查询操作）沿导航的方向可 以到达另一端，反之则不行。以到达另一端，反之则不行。 u如果类如果类A A、B B之间的关联是单向的，那么前述的对查询之间的关联是单向的，那么前述的对查询 职责、关系维护职责的要求便从对称的双向要求简化职责、关系维护职责的要求便从对称的双向要求简化 为单向要求，从而降低模型的复杂度。为单向要求，从而降低模型的复杂度。 在在分析模型中分析

44、模型中，并未考虑查询职责和关系维护职责，因此，并未考虑查询职责和关系维护职责，因此 不必急于确定关联的方向。不必急于确定关联的方向。 在在设计模型中设计模型中，必须完整地确定所有关联的方向，因为单，必须完整地确定所有关联的方向，因为单 向关联比双向关联要简单得多。向关联比双向关联要简单得多。 经推敲后认为确有必要的双向关联仍可表示为无向关联边。经推敲后认为确有必要的双向关联仍可表示为无向关联边。 2021-6-23 37 （四）布局规则（四）布局规则 类图往往是软件模型图中最复杂同时也最关键的一张类图往往是软件模型图中最复杂同时也最关键的一张UMLUML 视图。为提高其可理解性，本书推荐以下布

45、局规则：视图。为提高其可理解性，本书推荐以下布局规则： （1 1）尽量沿垂直方向表示继承、实现关系，沿水平方向尽量沿垂直方向表示继承、实现关系，沿水平方向 表示关联、聚合、组合、依赖、实现关系表示关联、聚合、组合、依赖、实现关系。在继承关系中，。在继承关系中， 父类应位于子类的上方；在单向关联、依赖和实现关系中，父类应位于子类的上方；在单向关联、依赖和实现关系中， 方向尽量从左至右；在聚合、组合关系中，整体类一般位方向尽量从左至右；在聚合、组合关系中，整体类一般位 于部件类的左面。于部件类的左面。 （2 2）在关联边上，多重性、角色名、约束特性等）在关联边上，多重性、角色名、约束特性等应靠近应

46、靠近 关联端关联端。 （3 3）如果多条边表示相同种类的关系，它们有公共的类）如果多条边表示相同种类的关系，它们有公共的类 端点，并且在公共端的标注相同，则汇合这些边。例如，端点，并且在公共端的标注相同，则汇合这些边。例如， 图图4.24.2将将“用户用户”与与“教务管理员教务管理员”、“教师教师”和和“学生学生” 之间的三条继承边汇合，布局成树形结构。之间的三条继承边汇合，布局成树形结构。 2021-6-23 38 4.1.5 4.1.5 活动图活动图 活动图活动图描述实体为完成某项功能而执行的描述实体为完成某项功能而执行的操作序列操作序列， 其中的某些操作或者操作的子序列可以其中的某些操作

47、或者操作的子序列可以并发和同步并发和同步。 活动图适合描述在没有活动图适合描述在没有外部事件触发外部事件触发的情况下的系的情况下的系 统内部的逻辑执行过程；否则，状态图更容易描述。统内部的逻辑执行过程；否则，状态图更容易描述。 类似于传统意义上的类似于传统意义上的流程图流程图。 活动图主要用于：活动图主要用于： u业务建模业务建模时时，用于详述业务用例用于详述业务用例，描述一项业务的执描述一项业务的执 行过程；行过程； u设计时设计时，描述操作的流程。描述操作的流程。 在描绘对象之间的交互协作方面，活动图不如顺序在描绘对象之间的交互协作方面，活动图不如顺序 图；在描绘对象的行为方面，活动图不如

48、状态图。图；在描绘对象的行为方面，活动图不如状态图。 2021-6-23 39 活动图活动图事物事物 活动 (ActionState) 动作的执行 起点 (InitialState)活动图的开始 终点(FinalState) 活动图的终点 对象流 (ObjectFlowState) 活动之间的交换的信息 发送信号 (signalSending) 活动过程中发送事件，触发另 一活动流程 接收信号 (SignalReceipt) 活动过程中接收事件，接收到 信号的活动流程开始执行 泳道(SwimLane)活动的负责者 活动图关系活动图关系 迁移迁移(transition)活动的完成与新活动的开始活

49、动的完成与新活动的开始 分支分支(junction point) 根据条件，控制执行方向根据条件，控制执行方向 分叉分叉(fork)以下的活动可并发执行以下的活动可并发执行 结合结合(join)以上的并发活动再此结合以上的并发活动再此结合 图图4.5 “4.5 “制订课表制订课表”用例的活动图用例的活动图 2021-6-23 42 图4.5 五种类型的活动图节点五种类型的活动图节点 下面结合此图描述活动图的建模机制。下面结合此图描述活动图的建模机制。 活动（活动（activityactivity） 计算过程的抽象表示，它或者是一个基本的计算步骤，或计算过程的抽象表示，它或者是一个基本的计算步骤

50、，或 由一系列基本的计算步骤和子活动构成。由一系列基本的计算步骤和子活动构成。 如，如，图图4.54.5中包含的活动有中包含的活动有“验证用户名和密码验证用户名和密码”、“添添 加课程设置加课程设置”、“修改课程设置修改课程设置”、“发布课表发布课表”等。等。 决策点（决策点（decision pointdecision point） 当到达边为一条、离开边有多条时，当到达边为一条、离开边有多条时，决策点包含监护条件，决策点包含监护条件， 它表示经条件判断后从多条后续的处理路径中选择一条路它表示经条件判断后从多条后续的处理路径中选择一条路 径继续推进；径继续推进； 当到达边有多条、离开边为一条

51、时，当到达边有多条、离开边为一条时，决策点不包含条件，决策点不包含条件， 它表示，只要控制流沿其中一条边到达，则处理流程沿离它表示，只要控制流沿其中一条边到达，则处理流程沿离 开边继续推进，并不等待其他到达边上的控制流。开边继续推进，并不等待其他到达边上的控制流。 2021-6-23 43 两种活动图的边两种活动图的边 在决策点的后一种情况下，决策点可以省略（隐在决策点的后一种情况下，决策点可以省略（隐 藏），直接将多条到达决策点的有向边越过决策藏），直接将多条到达决策点的有向边越过决策 点指向决策点的后继节点。点指向决策点的后继节点。 可以在决策点内部或附近直接标注条件，也可以可以在决策点内

52、部或附近直接标注条件，也可以 将条件分别标注在从决策点出发的多条边上，甚将条件分别标注在从决策点出发的多条边上，甚 至可以省略（实际上是隐藏）决策点，直接从前至可以省略（实际上是隐藏）决策点，直接从前 一节点引出多条有向边，在每条边上标注条件。一节点引出多条有向边，在每条边上标注条件。 图图4.54.5包含两个决策点。包含两个决策点。 2021-6-23 44 两种活动图的边两种活动图的边 并发控制：并发控制：表示控制流经此节点后分叉成多条可表示控制流经此节点后分叉成多条可 并行执行的控制流，或者多条并行控制流经此节点并行执行的控制流，或者多条并行控制流经此节点 后同步合并为单条控制流。后同步

53、合并为单条控制流。 u这两种情形依次称为分叉（这两种情形依次称为分叉（forkfork）和汇合（）和汇合（joinjoin）。）。 u前者的到达边为一条，离开边有多条，后者刚好相反。前者的到达边为一条，离开边有多条，后者刚好相反。 分叉分叉/ /汇合节点的示例请见汇合节点的示例请见图图4.84.8。 对象：对象：表示活动需要输入的对象或者作为活动的表示活动需要输入的对象或者作为活动的 处理结果输出的对象。处理结果输出的对象。 如果同一个对象在活动图中出现多次，但其状态如果同一个对象在活动图中出现多次，但其状态 （或者属性值）随处理流程的推进而发生变化，（或者属性值）随处理流程的推进而发生变化，

54、 则需要在对象名称后附以不同的状态名来区分它则需要在对象名称后附以不同的状态名来区分它 们。们。 2021-6-23 45 两种活动图的边两种活动图的边 控制流：控制流：连接在两个非对象节点之间的有连接在两个非对象节点之间的有 向边，表示处理流程的顺序推进。向边，表示处理流程的顺序推进。 对象流：对象流：从对象节点指向活动节点的有向从对象节点指向活动节点的有向 边表示将对象作为输入数据传入活动；边表示将对象作为输入数据传入活动； 从活动节点指向对象节点的有向边表示对从活动节点指向对象节点的有向边表示对 象是活动的输出数据象是活动的输出数据。 2021-6-23 46 2021-6-23 47

55、活动图活动图 活动图的活动图的泳道机制泳道机制指，将活动图用形如游泳池中的泳道分指，将活动图用形如游泳池中的泳道分 成数个活动区，每个区由一个对象或一个控制线程负责。成数个活动区，每个区由一个对象或一个控制线程负责。 这样表示的活动图也称泳道图。这样表示的活动图也称泳道图。 每个活动节点应位于负责执行该活动的对象或线程所在的每个活动节点应位于负责执行该活动的对象或线程所在的 区域内。区域内。 带泳道的活动图清晰地表示了对象或线程的职责、它们之带泳道的活动图清晰地表示了对象或线程的职责、它们之 间的分工、协同和同步。间的分工、协同和同步。 如，如，图图4.54.5包含三条泳道，从左至右依次由包含

56、三条泳道，从左至右依次由RegistrarUIRegistrarUI、 LoginManagerLoginManager和和CurriculumManagerCurriculumManager三个对象负责。三个对象负责。 2021-6-23 48 活动图活动图 活动图可包含活动图可包含初始节点初始节点和和终止结点终止结点。 u初始节点的含义是，通过一条简单的有向边指明进入初始节点的含义是，通过一条简单的有向边指明进入 活动图时首个被执行的活动。活动图时首个被执行的活动。 u终止节点表示整个活动图执行完毕。终止节点表示整个活动图执行完毕。 l每张活动图都应该有每张活动图都应该有唯一的初始节点唯一

57、的初始节点。 l表示表示持续过程的活动图可以没有终止结点持续过程的活动图可以没有终止结点； l其他情况下，每张活动图其他情况下，每张活动图至少应包含一个至少应包含一个终止结点。终止结点。 2021-6-23 49 4.2 4.2 需求获取的过程模型需求获取的过程模型 在需求获取阶段之初，需求工程师必须学习并理解与软件在需求获取阶段之初，需求工程师必须学习并理解与软件 问题相关的业务知识，研究其业务背景、理解业务术语、问题相关的业务知识，研究其业务背景、理解业务术语、 领域概念及业务流程，在此基础上对待解的软件问题进行领域概念及业务流程，在此基础上对待解的软件问题进行 定义定义 u定义软件系统的

58、定义软件系统的业务目标、业务范围与边界，明确其业务目标、业务范围与边界，明确其 业务价值。业务价值。 在定义软件问题之后，接下来应该通过各种信息渠道在定义软件问题之后，接下来应该通过各种信息渠道获取获取 并记录软件需求并记录软件需求。 uUMLUML的用例和用例图是表示需求的最恰当工具之一。的用例和用例图是表示需求的最恰当工具之一。 2021-6-23 50 用例表示的需求：用例表示的需求： 用例描述中包含交互动作序列等细节性信息。用例描述中包含交互动作序列等细节性信息。 对于大中型软件系统，首先关注整体和全局，然后再逐步添对于大中型软件系统，首先关注整体和全局，然后再逐步添 加细节。加细节。

59、 为避免需求工程师过早陷入细节，本书将表示软件需求的用为避免需求工程师过早陷入细节，本书将表示软件需求的用 例的创立和细化进一步划分为例的创立和细化进一步划分为创建框架用例创建框架用例、精化框架用例精化框架用例 两项活动。两项活动。 u创建框架用例创建框架用例试图通过若干框架用例尽可能完整地覆盖需求试图通过若干框架用例尽可能完整地覆盖需求 u精化框架用例精化框架用例是在已经建立的框架用例的基础上填充细节使每是在已经建立的框架用例的基础上填充细节使每 个框架用例进化为完整的用例。再将这些用例汇聚在一起，系统个框架用例进化为完整的用例。再将这些用例汇聚在一起，系统 地研究各种优化方案的可能性并地研

60、究各种优化方案的可能性并实施优化实施优化。 l例如，将业务上相关或者功能上相似的多个小规模用例合并例如，将业务上相关或者功能上相似的多个小规模用例合并 为一个用例，通过用例之间的包含关系合并多个用例中的公为一个用例，通过用例之间的包含关系合并多个用例中的公 共子过程，等。共子过程，等。 精化后的用例及用例图构成精化后的用例及用例图构成可供评审的用例模型可供评审的用例模型，它是需求，它是需求 模型的最初形态。模型的最初形态。 2021-6-23 51 需求工程师应该邀请需求工程师应该邀请利益相关方利益相关方、业务领域专家业务领域专家、项目软项目软 件经理件经理和和质量保证工程师质量保证工程师等参