2.2 用例图与系统需求
2.2.1 | 布吉医院案例背景描述
HSDC RA 与布吉医院特助针对布吉医院住出院系统的工作流程取得共识后，接下来，要开始找出布吉医院住出院系统的相关系统需求。
HSDC RA 采用 HSDC 所建议的“从业务流程到用例”的分析方式（有关这部分的详细步骤，请参考“第二篇 UML与软件开发实战”的介绍），想办法找出有关布吉医院住出院系统中的用例。
但由于用例分析对于布吉医院特助及用户来说，是一个全新的需求搜集的方式，因此，HSDC RA 与布吉医院的涉众之间，有了以下的对话过程。
HSDC RA：特助、主任及所有承办人员大家好，今天主要是开始进行需求的访谈，为了让整个访谈过程可以顺利进行，我们预计采用“用例”的方式来和各位进行沟通。
布吉医院特助：用例？这和我们以前熟悉的访谈方式好像不大一样，能够进一步说明吗？
HSDC RA：各位，其实这和一般的访谈方式很类似，只是让我们能够更加明确地知道现在要谈的主题是什么？
举例来说，若今天我要和各位谈的主题是“登记住院记录”，经由我们的分析，这个主题相关的人员主要是住院柜台的人员，因此，我们将只访谈住院柜台人员以确切了解他们需求，并把所有的需求全部整理到“登记住院记录”的这个需求规格中，这个需求规格就称为“用例”。
布吉医院特助：哦，这样我了解了，其实你所说的用例就是以前其他软件公司说的“需求功能”嘛！
HSDC RA：嗯，有点类似。只是我们的每个用例都会找出使用这个用例的相关人员，我们称之为“执行者”（Actor），由于有这样的分析，因此，在访谈时会更有效率。
布吉医院特助：嗯，听起来还不错。不过以往其他的软件公司都会提供相当多的功能菜单让我们选择… …
HSDC RA：是的，不过我想请问一下，这些软件公司所提供的功能，贵单位是否会全盘使用？
布吉医院特助：哈哈，这是我们一个非常大的困惑，其实软件公司提供的功能菜单中，有很多我们搞不懂要做什么，像什么“医保芯片读取格式转换”、“医保媒体申报格式转换”之类的功能；我们又觉得有些功能很无趣，比如“病人基本数据建立作业”、“医生基本数据建立作业”等。总之一句话，你们信息人员的术语，对我们来说真是“天数”啊！
HSDC RA：是啊，这就是为什么我们要采取“用例”取代这个“功能菜单”的原因啊！“用例”着重的是贵单位用户对于系统的“期望”（Expectation），因此，我们会先利用贵单位的“标准作业程序”作为基础，找出真正对贵单位有帮助的系统功能及其相关执行者，这样一来，我们就可以针对每个功能进行需求搜集，让整个系统 的开发更有效率！
布吉医院特助：嗯，听起来挺不错的，那我们就开始吧！
2.2.2 | 问题与分析
在笔者多年的教育经验中，很多刚开始接触用例的学员常常会问几个问题：
- 什么是用例？
- 用例跟表单是否有关系？
- 用例的开发有没有顺序性？
- 用例跟数据库有关还是无关？
- 为什么不能够用“功能树”（Function Tree）来取代用例？
以上这些问题，其实跟前面布吉医院的特助所问的问题有一些相似之处。其实这些问题的答案，都跟以下这个基本假设有相当大的关系：
系统的功能究竟是用户所想要的，还是系统开发人员凭空想象出来的？
用例本身并不是一个困难重重的学问，事实上，说穿了，也不过是一句话而已：系统需求的本质，最终不过是想办法捕捉到用户心中的真正期望！
因此，需求工具本身应该具备以下3个特性：
- 让用户很容易望文生义，也就是说，要尽量利用用户容易理解的字眼来描述某个功能需求。
- 功能需求的描述必须是“目的性”的，而非“操作性”的，也就是说，要尽可能表达出用户进入到系统后，通过这个功能需求可以“达到什么”，而不是平铺直叙地说明。
- 应该能够明确地指出使用这个功能需求的相关人员及系统，如此才容易跟这些相关人员沟通，了解到该功能需求的细节。
正由于以上的几个特点，Jacobson才设计出了“用例”这个需求搜集工具，其主要目的就是要让需求搜集人员可以很容易地利用这个工具达成上述的几个重要特性。
也因此，在搜集功能需求时，我们并不需要考虑过多跟设计有关的议题，只需要把重心放在该功能需求的描述上即可。
当然，根据不同的开发方式，在找出功能需求的方法上略有不同，然后，当功能需求一旦被确认出来，整个开发的动力就可以被驱动起来，这样的方式，在UP（Unified Process）被称为“用例驱动”（Use Case Driven），这几乎已是目前大部分软件公司所采用的设计方式。
本书的第二篇，将会介绍从业务流程到用例分析的整个步骤，有兴趣的读者，可以先行研读。本节只着重于用例模型中的“用例图”，至于“用例叙述”，则留待第二篇再进行讨论。
2.2.3 | 用例图的基本认识
用例在表达用户需求上，已经成为非常重要的工具，最主要是因为用例的元素非常单纯，但是在表达系统的“外显功能”上，却又有相当好的效果。就如同所有简单的设计一样，用例非常容易学习，但要分析得好，却又非常困难。以下就是有关用例的相关定义。
根据用例的创始者 Ivar Jacobson 的说法，用例是：
A use case is a sequence of transactions in system whose task is to yield a result of measurable value to an individual actor of the system.（《The Object Advantage》, Ivar Jacobson, 1994, p. 105）
用例是在一个系统中所进行的一连串的处置活动，该活动主要是要能够满足系统外部的执行者对于系统的某种预期。
从这个定义来说，用例主要就是在陈述系统是如何满足特定执行者的某些期望，而将用例的观念落实到信息系统之后，Jacobson 又说：
Each information-system use case is a complete fow of events in the information system, as seen from the users’ perspective.（《The Object Advantage》, Ivar Jacobson, 1994, p. 246）
每一个信息系统的用例都是一连串完整的流程，而这个流程必须要能够满足用户的观点。
从这个角度观之，我们可以知道，就 Jacobson 的观点来说，每一个信息系统的用例代表着用户对于系统的“某一个完整的期望”。
图 2-15 是一张标准的用例图
图 2-15 请假系统的用例图
接着，就上图中的几个重要的元素，分别叙述如下：
- 用例（Use Case）
用例图中最重要的元素当然就是用例。如同前面所述，用例代表着用户对于系统的一个“完整的期望”，也就是说，一个用例代表某个特定的用户在完成该期望后，就可以离开系统，而不需要再留恋。
以图 2-15 为例，员工进入系统，申请了请假之后，就不需要再对系统做其他的处理，因此“申请请假”，就代表着“员工”这个用户对于系统的一个“特定期望”。
用例的图形，主要是一个椭圆形来表示
。
- 执行者（Actor）
执行者代表着扮演某个特定角色的用户或系统。对于系统来说，执行者代表系统外部对于系统有影响力的用户或外部系统，也就是说，对于系统而言，“执行者”并非系统所关心的问题。
在 UML 中，执行者的图形是
的图形。
- 边界（Boundary）
边界代表着系统的范围，利用边界，可以可视化呈现系统的内与外。如此一来，就可以明确地了解整个系统开发过程中应该关心与不应该关心的部分。
在 UML 中，边界的图形是一个矩形
的图形。
从图 2-15 看出，由于“工作流系统”位于“工作流系统”位于边界之外，因此，可以很明确地知道，现在要开发的系统与“工作流系统”（Workflow System）没有关系，设计人员充其量只需知道“工作流系统”相关的接口就可以了，如此一来，就可以确实凝聚开发团队的共识。
- 泛化（Generalization）
执行者与执行者之间，可以有一个泛化的关系。
以图 2-15 为例，“员工”是“主管”的泛化，这代表“员工”所参与使用的“用例”，主管都可以参与使用，也就是说，“员工”在“人事管理系统”中，可以使用“列出 To Do List”及“申请请假”这两个用例；而主管则同时可以使用“列出 To Do List”、“申请请假”及“审核请假”3个用例。
泛化的关系的图示是：
。
- 关联（Association）
根据标准的 UML 定义（UML 1.x 规定），执行者与用例之间的关系，只能够使用“关联”关系。
“关联”关系的图示为：
。
2.2.4 | 布吉医院住、出院系统的用例图
找出用例的方法非常多，可以利用两阶段的方式，先找出企业层级的用例，在利用 Worker 与 系统的关系找出信息系统的用例（这是 Jacobson 所建议的方式）。
当然，由于用例要同时满足管理的需求（符合工作流程）及用户的操作性需求，因此，也可以通过业务流程来辅助找寻相关的信息系统用例，有关这个方法，我们会在第 2 篇加以详述。
HSDC RA 根据第 2 种方法，找出了以下的用例图：
图 2-16 布吉医院住出院系统用例图
根据图 2-16 可以看出，主执行者（箭头方向从执行者指向用例）可以是信息系统（图中的门诊系统），也可以是一般用户（图中的医护人员及护理站人员）；但辅执行者（箭头方向从用例指向执行者），则必须要和系统的边界（布吉医院住出院系统）同一级别。也就是说，如果我们的用例位于“信息系统”的范围内，则辅执行者也只能够是“信息系统”！
2.2.5 | 在 EA 中绘制用例图
接着，我们将利用 EA 绘制一张用例图。
第1步：选择“用例图”放置的位置。
请在 ch02-example.qea 中的“Model -> Use Case Model -> 布吉医院住出院系统”下新建一张“用例”，命名为“布吉医院住出院系统”。
图 2-17 新建一张“布吉医院住出院系统”的用例图
第2步：绘制系统“边界”。
接着，请拖拽一个“边界”到工作区中，并命名为“布吉医院住出院系统”。
图 2-18 在工作区中建立一个系统的边界
第3步：建立用例图形。
在“边界”的左边放置“主执行者”，在边界中放置一个名为“通知住院”的用例。
紧接着，拖动执行者右上角的箭头到用例上，建立“关联”关系。
图 2-19 建立主执行者与用例的关系
同理，在“通知住院”的用例中利用“关联”建立用例与辅执行者的关系。
第4步：重复 第3步 直到所有的用例都完成为止。
转载请注明：56data个人站点 » 《UML与Enterprise Architech 16 项目实战》2.2 用例图与系统需求