2.1.2　由粗到细的用例分析

我们先看一看“中医远程智慧医疗平台”的业务需求。中医远程智慧医疗平台，是一套集互联网、云计算、人工智能为一体的大数据医疗平台。该平台运用人工智能技术，对中医的诊断、治疗过程进行数据建模、医学仿真，运用大数据平台建立面向中医的智慧诊疗数据模型，然后通过云端服务平台，为各地的医院诊所以及通过互联网问诊的千万患者，提供远程诊断治疗，并在此基础上实现医生网上预约、医院网上挂号以及健康产品网上直销等服务。

依据以上对整个系统的分析，我们开始进行第0层的用例模型的分析。第0层的用例模型分析，就是从整体出发对整个系统的功能模块进行分析，如图2-1所示。这时，在用例模型中要分析的每一个用例代表一个子系统，或者一个功能模块。

图2-1　第0层用例模型

在第0层的用例模型中，我们将整个系统划分成了“诊断治疗”“诊所管理”“远程医疗”与“健康购物”四个用例。在“诊断治疗”这个用例中，医学专家录入模型参数，对系统进行模型构建，然后为各地的医生提供辅助诊疗。医生通过“远程医疗”在各地的诊所远程接诊，而各地的诊所有各类诊所人员进行诊所管理。患者通过“远程医疗”进行预约，并通过“健康购物”购买健康产品。

在第0层的用例模型中，一个非常重要的要点在于，一切都高度概括，不要做细节展开。比如在“诊所管理”中可能有各种类型的角色，包括护士、医师、结算中心、药房与管理人员，但在第0层都归为“诊所人员”。此外，各个参与者在系统中有各种类型的操作，然而在第0层的用例模型中只高度概括地列举主要操作。更多细节在后面第1层、第2层逐步展开的过程中再描述。

用例模型分析是一个逐步细化的过程，因此在第0层高度概括的分析以后，就要将第0层的每个用例进行展开，绘制它们第1层的用例模型。在以上案例中，第0层有4个用例，因此我们在此基础上展开每一个用例，第1层就有4个用例模型。譬如，对第0层的“诊断治疗”用例进行展开，就形成了第1层的“诊断治疗”用例模型，如图2-2所示。

图2-2　第1层诊断治疗用例模型

在该模型中，我们将“诊断治疗”这个模块进一步划分成了“问诊”“复诊”“诊断”“治疗”这几个用例。“问诊”是一个非常复杂的业务过程，因此又可以拆分出“主述问诊”“序列问诊”“联想问诊”和“补充问诊”4个子用例；而“诊断”可以分为“确定性诊断”与“程度性诊断”2个子用例。

这里特别要注意的一点是，用例模型是将系统看成一个黑盒，去分析它对外提供哪些功能。因此，不要在用例模型中为系统内部各功能的关系与流程绘制箭头。比如，在该案例中，从问诊到诊断再到治疗，似乎有一种流程关系，但在该图中不要为了描述这种流程关系而绘制箭头。用例与用例之间只有3种关系：包含、扩展与继承。

包含，就是将该用例中业务流程的某些相对独立的环节单独提取出来做成的用例，是原有用例的一部分，又称为“子用例”。除此之外，在用例设计时，还常常将各个功能都要使用的、共性的业务流程单独提取出来做成一个子用例。这样，各个功能在流程描述的时候，都可以调用该子用例进行复用，而不需要重复地描述该流程了。子用例通常用use或include进行描述。

扩展，就是在原有用例的基础上，在业务流程中的某个扩展点去扩展某些新功能，因而这些用例被称为“扩展用例”。这些扩展的功能是原有用例流程中分支出来的，并非必备的业务功能。如查询报表执行查询是必备的，但查询后的数据导出不是必备的流程，因此对于“查询报表”用例来说，“数据导出”是它的扩展用例。

最后就是继承关系，体现的是一种父子关系。比如，“支付”是一个父用例，它通过继承划分为“微信支付”“支付宝支付”“银行卡支付”。不论是包含关系还是扩展关系，其用例都是原用例的一部分，而继承关系通过继承可以替换原有的父用例。

此外，参与者与参与者之间也有继承关系，这是参与者之间唯一的关系。比如，“诊所人员”是系统中的一个参与者，他可以登录诊所管理系统，查看诊所中的一些通用信息，而“护士”是“诊所人员”的一个继承，他除了拥有“诊所人员”的所有功能，还有自己独有的一些功能，比如“挂号”。