软件体系结构——第五章<用例模型>

一、理解需求

什么是需求？客户可接受的、系统必须满足的条件或具备的能力——由用户提出

二、从业务模型获取需求

3个步骤：

• 寻找业务改进点——从业务用例模型中寻找系统改进点；

• 定义项目远景——结合系统远景，获取系统用例来表达需求；

• 导出系统需求——采用需求启发技术，从涉众中获得

实例分析：

旅店系统开发远景:

• 随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间

• 然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响

• 为此，旅店老板想到了用计算机来管理——希望能够通过计算机来自动管理这些预订业务，但由于目前资金的问题，目前只开发一个单机版的系统，不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题

• 旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜

远景：酒店预订系统

• A很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口

• 结合现状和老板的要求，考虑到项目可扩展的要求，A首先通过利用业务用例、业务处理活动、业务对象进行了建模

• 之后，A初步定义了项目的远景（项目的目标）

  • 方便、快捷、准确地为旅客预订房间
  • 旅客可以方便的取消预订的房间
  • 旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格
  • 及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息
  • 预留接口：可为以后的网络版，以及其它业务系统的开发提供支持

三、建立用例模型

3.1、获取需求

需求只能来自涉众(stakeholders)、或相关利益者、或角色等等，但并不是直接从涉众中来，根据远景确定需求。

3.2、识别参与者

从需求中的业务用例模型识别参与者

• 参与者：在系统之外，通过系统边界与系统进行有意义交互的任何事物

要点：

• 任何事物 （参与者用小人表示，但是可以是everything）

参与者的命名：

规范的参与者命名：用能知道其角色的名称来命名

• 例如，学生、订单管理员、维护部门…

• 即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的

参与者之间的关系：泛化（继承）

泛化实例：

3.3、识别用例

关键词：提供的价值——业务功能

用例的特征：

• 用例实例是系统执行的一系列动作(执行过程)，这些动作将生成特定参与者可观测的结果值

• 一个用例定义一组用例实例（场景）

用例：参与者使用系统达到某个目标

用例的命名：

参与者（执行者）视角：动宾结构

用例粒度：指的是系统中某个用例所包含的系统服务或功能单元的多少。

• 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。

• 最常犯错误：①粒度过细，陷入功能分解 ②把步骤当用例 ③把系统活动当用例 ④CRUD会掩盖业务，锐变成关系数据库的建模

采用管理用例解决CRUD问题：

• 多数的基本数据管理业务都可以用一个用例表示

• 

• 可以把包含复杂交互的路径独立出去形成用例——用例扩展关系的利用

3.4、构建用例图

用例图：表达参与者与用例关系的图形

实例分析：旅游业务申请系统

四、编写用例文档

用例文档：更进一步对用例进行详细说明

• 需求规格说明书的核心，而用例图作为用例文档的索引图（也称软件功能总图）
• 有层次的文档
• 文档中每一句话都有其价值

用例文档的组成：

• 用例标识(UC)、名称、描述

• 涉及的参与者、涉及的用例

• 涉众利益——参与者的利益关系

• 前置条件 PreConditions（在用例开始前系统的状态）、后置条件 PostConditions（用例执行后系统的状态）

• 事件流

  • 基本路径Flow of events
  • 备选路径Alternate flow

• 补充约束

  • 字段列表、业务规则
  • 非功能需求、设计约束

• 待解决问题

• 相关图(用例图、活动图、类图)

事件流描述-用例交互四部曲：

事件流描述要点：

• ①使用业务语言，而非技术语言
• ②以参与者或系统为主语
• ③避免出现过细的GUI描述
• ④用例的重点在于描述功能需求

用例文档案例：记录时间 ，UC01：“Record Time”

用例标识	UC01
用例名称	Record Time
涉及的参与者	雇员、系统管理员
描述	雇员利用“Record Time”用例来登记他们的工时，系统管理员用这个用例为任何雇员登记时间
前置条件	用户必须已经登录到这个系统
后置条件	系统将雇员的工时正确的记录到数据库中
正常事件流（雇员记录时间）	1.雇员查看当前时间之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。
备选事件流（雇员更改时间）	1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目；3.雇员改变工时；4.系统在视图中更新这个信息，并在以后的视图中都可以看到。
非功能需求	无
设计约束	无
部署约束	用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙
未解决的问题	①雇员是否可以在以前的考勤卡上输入和更改时间？②雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？
相关图	用活动图来描述该用例的执行过程，即：场景（用户可以按照场景的描述来验证系统是否达到了预期目标——验证用例的有效性。）

活动图-简述用例流程：

五、重构用例模型

利用用例建模的高级技术重构用例模型：

• 用例关系——可降低用例的复杂度
• 用例分级——可寻找重要的用例
• 用例分包——可按应用来组织管理用例

5.1、用例关系

5.1.1、扩展

某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示某个用例的功能被扩展

扩展使用带有 <<extend>> 的虚线表示。箭头由扩展的用例指向基用例，通过扩展点指明在基用例中的扩展位置

基用例路径本身是完整的，可能是一条被扩展的路径。其特点主要表现为：

• 扩展路径步骤多

• 扩展路径内部还有扩展点——扩展之扩展

扩展点必须是系统能感知的:

5.1.2、包含

某个用例中包含了其他用例的行为

用带有<<include>>的虚线来表示。箭头由原用例指向被包含部分的用例——用例的复用

何时运用包含：

• 某些步骤在多个用例中重复出现，且能单独形成价值

• 另外，用例步骤较多时，可用Include简化（慎用，会增加用例模型的复杂性）

5.1.3、扩展vs包含

包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能，离开用例B就无法工作

扩展：由用例B连向用例A。用例A描述了一项基本需求，用例B则描述了该基本需求的特殊处理情况，即一种功能扩展

案例：网络购物系统

5.1.4、泛化

泛化：表示子用例继承了父用例

用途：

• 一个用例可以特化另一个普通用例（普通用例泛化特殊用例）

用例泛化关系：

是指一种从子用例到父用例（比较抽象）的关系，它指定了子用例如何特化父用例的所有行为和特征。

5.1.5、扩展vs泛化

扩展用例只是对基用例进行功能扩展，而泛化用例是完全可以取代基用例的功能，并添加新的行为

5.2、用例分包

作用：

• 让用例图更为清晰地表现出系统的业务逻辑关系和层次
• 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式

分包方式：

• 按参与者分包

• 按主题分包

• 按开发团队分包

• 按发布情况分包

分包经验：先按主题分包，主题内再按参与者、开发团队和发布情况分包

案例：申请业务审查系统顶层用例包图

5.3、用例分级

用例和迭代开发的关系：

• 迭代开发中开发周期是围绕用例的需求来组织的
• 一个迭代周期需要被指派一个到多个用例。如果某个用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本和完整版本的用例，分阶段来完成。如图所示：

用例分级原则：寻找高级别用例（5种途径）

• 对架构设计有重要影响的用例，如：在领域层中包含多个类的用例、或者需要持久化（数据存储）的用例

• 不需要花费很多努力就可以从中获得重要信息和线索的那些用例，即代表主要的在线业务流程的用例

• 含有开发风险、时间紧迫或功能复杂的用例

• 涉及到重要技术研究或者新技术和高风险的用例

• 能产生直接经济效益或者降低成本的用例

用例分级实施策略：

• 可以使用一个简单的但是有些不精确的经验分类方法，如将用例划分成高、中、低三个等级

• 依照上述影响用例级别的特性(5种途径)给用例打分（特性也可能带有权值）

六、企业进、存、销管理系统案例分析

6.1、需求分析

（1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。

（2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。

（3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。

（4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。

（5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。

6.2、识别参与者

（1）销售员：为客户客提供销售产品的服务。

（2）仓库管理员：负责库存产品的管理活动。

（3）采购员：负责企业生产原料的订购。

（4）会计（统计人员）：负责企业经营状况的统计。

（5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。

6.3、销售员用例图

销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。

6.4、仓库管理员用例图

仓库管理员能够通过该系统进行如下活动：

1、处理盘点，每天需要对库存产品信息进行盘点。

2、产品入库。当产品生产后，将产品进行入库。

3、产品出库。当产品销售发货后，进行出库处理。

4、管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置。

6.5、采购员用例图

采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。

6.6、会计用例图

会计负责产品的统计分析管理，它能够通过该系统进行如下活动：

1、查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。

2、查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。

3、查询供应商信息。会计能够查询供应商信息。

4、查询缺货信息。会计能够查询缺货信息。

5、查询报损信息。会计能够查询报损信息。

6.7、系统管理员用例图

系统管理员能够通过该系统进行如下活动：

1、维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。

2、维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。

3、系统设置。系统管理员能够根据一些需要进行必要的系统设置。