Appearance
第3章 业务建模之业务用例图
3.1 软件是组织的零件
有了愿景，我们知道老大对他所代表的组织的现状的某些指标不满意。 接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标 比较差，这就是业务建模（Business Modeling）的主要内容。
“业务建模”这个名字其实起得不好，应该更名为“组织建模”。出于对过去 叫法的尊重，本书依然称为“业务建模”。
- 含糊的“业务” “业务”这个词在软件开发团队中使用得很频繁，例如“我是一名业务 架构师”“我们要了解业务”，等等，但是往往说话的人未必真的理解 话中的“业务”具体指什么。 有时候“业务”指“核心域知识”。开发人员假装谦虚“我是做技术的， 业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这 样划分的： 我懂且我感兴趣→技术； 我懂但不感兴趣→业务； 我不懂但感兴趣→高科技； 我不懂且不感兴趣→忽悠。 有时候“业务”指“组织级别的知识”。例如，“业务建模”“业务用 例”“业务流程”说的就是组织级别的知识。
对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。 软件系统只是组织的一个零件。组织里面还有很多系统，其中最值 钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统， 它由“父母公司”开发，“老师公司”不断升级，组织以每人每月几千上万的 租金租用。为了让组织更好地对外提供价值，不一定要引进新的软件系 统，有时换新人更管用。
开发人员有时会有意无意把自己的系统想得太重要，还喜欢起××云平台 等很牛的名字，以为没有他们开发的系统，组织就玩不转了。有一次我 到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系 统的目标是，银行风险部能够对贷款做风险评估。我问道：难道银行以 前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其 实想想就知道，银行都成立多少年了，该公司才成立几年？所以为了抵 消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”，意思 是这个零件和组织厕所里的马桶没有本质区别。
开发团队经常发现需求“容易变化”。根源之一是需求的来路不正，没有 把系统当作一个零件放在组织中来看，靠拍脑袋得出需求，导致得到的 系统需求是错的。系统投入使用后，发现和组织的其他零件格格不入， 自然要改。“需求变化剧烈”是一个假象，真正的需求没有变，只不过一 开始得到的需求是假的。如果能正确运用业务建模技能，“需求变化”就 会消于无形。 在业务建模工作流，我们从内外两个视角来研究组织。
- 从外部看，组织是一些价值的集合，我们可以用业务用例图表示；
- 从内部看，组织是一些系统的集合，我们可以用业务序列图来表示。
3.2 【步骤】识别业务执行者
3.2.1 业务执行者（Business Actor）
以某组织为研究对象，在组织之外和组织交互的其他组织（人群或机 构）就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行 者。 以一家商业银行为研究对象，观察在它边界之外和它打交道的人群或机 构，可以看到储户来存钱，企业来贷款，人民银行要它作监管……这些 就是该商业银行的执行者。
业务执行者的图标是一个小人，头上有一道斜杠，这个带斜杠的小人实 际上是一个执行者的构造型BusinessActor的图形表示，Rational工具 和EA里都有。如果您使用的UML工具没有这个图形，可以用执行者的小 人图标加上文本构造型BusinessActor取代，或者不加构造型也无所 谓，因为边界框已经表明了研究对象是一个组织，它的执行者自然是业 务执行者。
3.2.2 业务工人和业务实体
组织内的人称为业务工人（Business Worker），例如某商业银行里面的营 业员。
业务执行者和业务工人的区别是：
一个在组织外面，一个在组织里面；
一个是组织不可替换的服务对象，一个是组织可以替换的零件。
经常有人会提到在家上班、在客户处上班、某些岗位人员的工资和保险 由外包公司负责等“特殊情况”，其实这些情况没有什么特别，因为组织 内外的边界是以责任划分，而不是物理位置。关于以责任划分边界，第 五章会再详细讨论。
业务工人是可以被替换的人脑零件，它可能会被其他业务工人替换，但
更有可能被业务实体（Business Entity）替换。
业务实体是组织中的非人智能系统，例如银行的ATM、点钞机、营业系统。
在没有点钞机的时代，储户拿着一摞钞票到银行存钱，营业员需要凭着 手感（界面层）一张张数，触摸信号传到大脑（核心域层），大脑要很 快判断钞票的真伪和计数。验钞、计数的逻辑封装在营业员的大脑里， 营业员非常累，而且营业员要有经验，小白是干不了的。这样，人力成 本高了很多。
有了点钞机，营业员只需要把整叠钞票放进点钞机过一下，点钞机会负 责验钞和计数。也就是说，验钞和计数的逻辑从人脑转移到了点钞机 的“大脑”。营业员轻松了，或者说，银行也就不需要那么 多有经验的营业员了。许多信息化程度很高的领域，绝大多数领域逻辑 目前已经运行在业务实体中，业务工人主要负责输入信息。银行所属的 金融领域就是如此。
责任转移的思想对识别待引入系统的需求很有帮助。开发人员说，“我在 开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现 有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了 ——我们画好现状的业务序列图，然后寻找改进点改进业务序列图。
在改进的业务序列图上，从外部指向所研究软件系统（业务实体）的消
息，可以直接映射为该软件系统的用例。
业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价
值，而是成本。在识别业务执行者时，不需要画业务工人和业务实体。
在接下来画业务用例的实现——业务序列图的时候，将业务工人和业务 实体作为类（Class）的一个构造型，放在名为“业务对象”的包里。和业 务执行者一样，如果您使用的工具没有BusinessWorker和BusinessEntity构造型， 可以自己造，或者干脆不要构造型直接用类表示。背后 的思想是一样的：类之间通过协作实现用例。组织的业务工人和业务实 体协作完成业务用例，系统的类协作完成系统用例。
3.2.3 识别业务执行者
把观察的焦点对准组织的边界，看看边界外有哪些人群或机构会和它交 互，交互的姿态可以是主动的，也可以是被动的；交互的形式可以是面 对面，也可以是发邮件、发微信……这些外部人群或机构就是所研究组 织的执行者。
这里要注意的是，作为观察者的建模人员本身是一个人脑系统，所以在 观察组织边界时，直觉上观察到的不是组织之间的交互，而是组织派出 的系统之间的交互，但是一定要把它理解成组织之间的交互，因为谈论 业务执行者时，研究对象是组织，所以外部对应物——业务执行者也应 该是组织。
二维生命观察三维宇宙，三维生命观察四维宇宙，同样难度很大。
例如，
以某国税局为研究对象，可以观察到企业财务人员到国税局报 税，但是业务执行者不是企业财务人员，而是企业。也许某个时期，企 业财务人员和国税局窗口人员交互；后来，企业财务人员和国税系统交 互；再后来，企业系统和国税系统交互。不管观察到哪两个系统交互， 从组织的抽象级别，都应该理解为企业和国税局这两个机构之间的交互。
同一个机构内部也是如此。如果以一个部门为研究对象，即使观察到的 是两个员工之间的交互，也应该找到现象背后的部门之间的交互。
有的时候，个人的背后不是机构而是人群。参与“组织晚 会”用例时，员工并不代表他所在的部门，只是作为员工人群的一分子。
如果您之前阅读过一些用例相关的书籍或文章，可能知道“系统定时发 生”的事件有时会提炼成“时间”这个外系统作为主执行者的系统用例。不 过，如果研究对象是一个组织，“时间”作为组织的执行者是不合适的， 应该把时间看作某个外部组织派来的一个接口系统，如水文站定期上报 监测数据的例子。应该考虑是不是水文局才是主执行者。
有箭头从执行者指向用例，也有箭头从用例指向执行者。
前一种执行者称为用例的主执行者，
后一种执行者称为用例的辅助执行者。
例如，营销部找产品部帮忙规划产品，产品部仅靠自己的力量不足以完成， 需要找研发部帮忙。 或者这样解读：营销部向产品部“购买”服务，产品部向研发部“购买”服务。
text
@startuml
actor "营销部"
actor "研发部"
rectangle "产品部" {
(规划产品)
}
"营销部" --> (规划产品)
(规划产品) --> "研发部"
@enduml
3.3 【步骤】识别业务用例
业务用例指业务执行者希望通过和所研究组织交互获得的价值。以上面 提到的某商业银行为例，储户和银行打交道的目的可能有存款、取款、 转账，所以银行针对储户的用例如图所示。
text
图3-9
@startuml
actor "储户"
rectangle "某商业银行" {
(存款)
(取款)
(转账)
}
"储户" --> (存款)
"储户" --> (取款)
"储户" --> (转账)
@enduml
可以看到，和业务执行者一样，业务用例上有个斜杠，表示这 是组织的用例。
如果工具不提供这个图标，处理方法参照业务执行者。
如果穿越回300年前，图3-9依然适用。业务用例代表组织的本质价值，很 难变化，变化的是业务用例的实现——业务流程。300年前，银行要实 现“储户→存款”的用例，需要许多人脑系统（业务工人）一起协作，现 在则变成了少数人脑系统（业务工人）和许多电脑系统（业务实体）之 间的协作。
业务用例刷新了业务流程的概念。我们把业务流程看作是业务用例的实 现，将其组织在业务用例的下面。组织内部之所以有业务流程，是因为 要实现业务用例。组织里发生的一切都是为了给业务执行者提供价值。
用例没变，实现用例的零件变了
这样的思路对改进业务流程有非常大的帮助：先归纳出组织对外提供什 么价值，再思考如何更好地优化组织内部流程来实现这些价值.
业务用例是组织的价值，不会因为某个人脑系统或电脑系统的存在或消 失而改变。所以“这个系统的业务用例是什么”这样的说法是错误的。
3.3.1 正确理解价值
用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点、买卖的 平衡点。
例如，以医院为研究对象，“患者→挂号”不是用例，因为挂号不是患者 对医院的期望和医院对患者的承诺的平衡点。如果挂到了号后医院的服 务到此为止，患者到医院来时心中的期望将无法得到满足，或者说医院 这个研究对象能承诺向患者提供的价值不是挂号，而是看病。
或者可以这样思考：医院能这样叫卖自己吗？“来呀来呀，我这家医院能 挂号呀！”患者一听，“哇，真棒耶，这医院能挂号耶，我赶紧去！”其实 患者巴不得不挂号也能看病，只不过人太多了，需要拿号排队。
如果把研究对象改为医院挂号室，“患者→挂号”就是合适的用例。患者 对挂号室的期望是能挂到号，不会因为挂号室没帮他看病就破口大骂。 挂号室对他的承诺也就是能给他号。 以上提到的正确和错误的用例图，如图3-12所示。
text
图3-12 期望和承诺的平衡
@startuml
' 错误示例：挂号作为医院的直接用例
actor "患者"
rectangle "医院" {
(挂号)
}
"患者" --> (挂号)
note right of (挂号)
❌ 错误：挂号是流程环节，不应作为医院的顶层用例
end note
@enduml
@startuml
' 正确示例：看病作为医院的顶层用例
actor "患者"
rectangle "医院" {
(看病)
}
"患者" --> (看病)
note right of (看病)
✅ 正确：看病是患者与医院的核心交互用例
end note
@enduml
@startuml
' 正确示例：挂号作为挂号室的用例
actor "患者"
rectangle "挂号室" {
(挂号)
}
"患者" --> (挂号)
note right of (挂号)
✅ 正确：挂号室作为研究对象，挂号用例是合理的
end note
@enduml
如果患者在窗口挂到的是明天的号，他离开医院回家了，明天再来医院 就诊，那么挂号算不算医院的一个用例呢？仍然是不算的，因为患者心 中仍然在期待，这件事情没有完。
（如果患者在家里使用医院的微信公众号挂到了第二天的号，明天再去 医院就诊，那么医院的用例图会有变化吗？显然不会，患者去医院的核心诉求还是没变）
业务用例是组织对组织的服务，相对于系统为系统提供的服务（系统用 例）来说，所需要的时间是比较长的，不能把用例实现过程中的某个交 互片段当成用例。如图3-13所示，企业和工商局打交道变更地址的过程 中，可能要发生多次交互，但是用例只有一个。
text
图3-13 业务用例持续的时间比较长
@startuml
' 错误示例：把每个交互当业务用例
actor "企业"
rectangle "工商局" {
(网上预约)
(受理变更材料)
(领取新执照)
}
"企业" --> (网上预约)
"企业" --> (受理变更材料)
"企业" --> (领取新执照)
note right of (网上预约)
❌ 错误：三个用例是同一业务的不同环节
end note
@enduml
@startuml
' 正确示例：工商局的业务用例
actor "企业"
rectangle "工商局" {
(变更地址)
}
"企业" --> (变更地址)
note right of (变更地址)
✅ 正确：变更地址是企业与工商局的业务用例
end note
@enduml
系统用例的持续时间比较短，如图3-14所示。一个典型的执行者使用系统 做了某事，达到了某个结果，然后离开系统去做别的事情，如果离开时 他心里认为得到目前的结果已经不算白做，就可以把做某事作为一个系 统用例。有一些词汇带有浓浓的“系统”味道，例如新增、查看、录入、 查询、修改、配置……带有这些词汇的用例，很可能不是组织提供的价 值，而是某系统提供的价值。
可能有这样的组织，例如“**情报所”，它对外提供的价值就是提供一些信 息。即使如此，业务用例名字最好也不要用“查询XX”这样软件味道十足的 名字，可以写成“了解XX” 注意这里是系统用例
text
图3-14 工商系统的用例
@startuml
' 工商系统用例图
actor "企业人员"
rectangle "工商系统" {
(预约)
(查看进度)
}
"企业人员" --> (预约)
"企业人员" --> (查看进度)
@enduml
- 边界框问题
从图3-12也可以看出，讨论“是不是用例”“有哪些用例”的时候，必须先说 清楚研究对象，否则讨论没有意义。画用例图时，能加上边界框尽量加 上。有的建模工具没有提供这个边界框，可以用一个Note注明研究对 象。 也有人觉得没有边界框比起有边界框更能利用更多空间。不过， 我建议初学者还是画边界框，以便时刻提醒自己当前的研究对象是什么， 熟练的建模人员自便。
3.3.2 识别业务用例的思路和常犯错误
识别业务用例有两条思路：
一条是从业务执行者开始，思考业务执行者和组织交互的目的；
另一条是通过观察组织的内部活动，一直问为什么，向外推导出组织外部的某个业务执行者。
第一条路线是主要的，第二条路线用于补漏。
识别业务用例本来应该是很简单的事情，但是，许多程序员出身的需求 人员受到了以往工作经历的影响，往往把简单的事情变得复杂。下面试 列举一些常见的错误。
- 错误1：把业务工人的行为当作业务用例
例如，以医院为研究对象，有人会画出图3-18。
text
图3-18 把业务工人的行为当作业务用例
@startuml
' 收费人员与收费用例
actor "收费人员"
(收费)
"收费人员" --> (收费)
note right of (收费)
❌ 错误：收费人员应该是医院内部的业务工人，不是业务执行者
end note
@enduml
@startuml
' 医生与诊治用例
actor "医生"
(诊治)
"医生" --> (诊治)
note right of (诊治)
❌ 错误：医生应该是医院内部的业务工人，不是业务执行者
end note
@enduml
这种情况的出现往往和没有注明研究对象有关。如果用边界框注明了研 究对象，如图3-19所示，建模人员就会警觉，收费人员和医生在医院里 面，是业务工人，不是业务执行者。
text
图3-19 边界框有助于辨别组织内外
@startuml
' 错误示例：收费人员作为业务工人，不参加业务用例
actor "收费人员"
rectangle "医院" {
(收费)
}
"收费人员" --> (收费)
note right of (收费)
❌ 错误：收费人员应该是医院内部的业务工人，不是业务执行者
end note
@enduml
@startuml
' 错误示例：医生作为业务工人，不参加业务用例
actor "医生"
rectangle "医院" {
(诊治)
}
"医生" --> (诊治)
note right of (诊治)
❌ 错误：医生应该是医院内部的业务工人，不是业务执行者
end note
@enduml
不过，可能又会有人害怕“收费人员收费”“医生诊治”的信息此时不表达出 来就忘记了。就像恋爱中的人担心以后没机会，迫不及待要表白一样， 建模人员千方百计要赶紧把自己牵挂的信息表达出来,而且他还有理由： 难道医院不要收费和诊治吗？收费和诊治不是医院的本质吗？ 这里反映了建模人员常见的一个问题: 分不清问题和问题的解决方案。
医院确实要收费，但说的不是收费，而是收费的一个解决方案—— 收费人员人脑系统坐在那里收费，背后的真实问题是医院的老板要通过 医院来赚钱，至于钱是怎么收上来的，是收费人员这个业务工人坐在那 里收钞票，还是各种业务实体互相协作来达到收费的目的，老板是无所 谓的。
同理，“医生诊治”也只是解决方案。患者要的是把病治好，治疗的过程 短，不痛苦，没有后遗症，收费还便宜，并不在意他的病是医生动手术 治好的，还是有个很牛的仪器给照好的。医院老板巴不得不用雇那么多 收费人员和医生，照样为患者看病赚钱，只不过目前做不到。
或者这样思考，医院的成立不是为了容纳收费人员和医生，以解决本地 户口的下岗人员和医科毕业生的就业问题，而是患者要看病、老板想赚 钱，于是才有了医院。
业务用例是为业务执行者服务，不是为业务工人服务。这不是什么规范 问题，背后有它的道理。要从业务执行者的角度去看，才能看得清楚组 织的本质价值。
像收费人员这样的人脑零件，以现在的IT技术替换掉没有问题，不过像 医生这样读了很多年书，经过许多年专业训练的人脑零件，替换起来更 难一些。
即使现在医生的地位还比较稳固，他的责任也已经被替换了一部分。过 去去看病，说“医生我咳嗽”，医生会让我们伸出舌头看一看，听诊器放 胸口听一听，躺在床上按一按。现在呢，医生抬头看一眼，啪啪就开 单，“去照个××吧”，把检查的责任转移给仪器了。
几年前人们还认为人工智能攻克围棋还需要很久，现在AlphaGo已经使这 个目标变为现实，也许不久的将来，各行各业打酱油的从业者将会被人 工智能代替。
- 错误2：业务用例随待引入系统伸缩
有的建模人员把臆想的待引入系统的用例直接当成业务用例画出来，如 图3-21所示。 根据前面讲的知识要点，如图3-21右侧所示，一看护士在组织边界外面， 就知道不对了。但是，要求建模人员按照业务用例的定义做时，有人就 会说：我的系统就是这个功能，我已经知道了，我还要考虑其他东西干 什么？
text
图3-21 将臆想的系统用例当成业务用例
@startuml
' 医院系统：护士审核医嘱用例图
actor "护士"
rectangle "医院" {
(审核医嘱)
}
"护士" --> (审核医嘱)
note right of (审核医嘱)
❌ 错误：一看护士在组织边界外面，就知道不对了。护士是业务工人
end note
@enduml
这是一种“致命的自负”。正是因为很多情况下拍脑袋得到的是错误的需 求，所以才要做业务建模，从组织的价值来推导系统应该具备什么价值 才会对组织有帮助，这样系统才能卖得出去。如果已经认定了系统有这 些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？
就像考试做题一样，如果已经知道答案是A，那就不用再花时间计算了。 问题在于，我们很多时候是不知道的，不过瞎蒙也有25%的概率蒙对，然 后就拿出来当作成功经验宣传，碰上掌握了方法的竞争对手，分分钟被 虐成渣。
好了，现在建模人员知道护士在所研究组织边界里面，不能作为业务执 行者了，但是又有可能还是受待引入系统的影响，导致组织的价值随着 所引入系统的价值大小伸缩。 因为建模人员臆想待引入系统的主要功能是审核医嘱，所以画出的图 中，医院或护士站就变成了一个“审核医嘱”的机构。
碰到这种情况，我通常都会用开玩笑的口气说，幸亏你们团队不是卖马 桶的，否则就有可能得到图3-23。
text
图3-23：医院变成了上厕所的机构
@startuml
' 图3-23：医院变成了上厕所的机构
actor "患者"
rectangle "医院" {
(上厕所)
}
"患者" --> (上厕所)
note right of (上厕所)
患者主要问题是患，是病。医院的厕所也不是主要价值。
end note
@enduml
即使真的是卖马桶的，想要打败其他对手把马桶成功卖给医院，也依然 需要研究医院的流程，找到适合用马桶来改进的改进点，才能打造出为 医院量身定制的贴心马桶. 一个组织，甚至组织的一条流程都涉及许许多多的系统。在开发不同的 系统时，研究业务用例和业务流程，发现得到的结果和开发另一个系统 时的研究结果差不多，这是很正常的。建模人员不必因此感到惊慌，更 不要因为“业务用例太少”“业务用例太简单了”不自觉地改变研究对象，把 待引入系统的用例搬上来。
- 错误3：把害怕漏掉的扩展路径片段提升为业务用例
如果待改进的流程片段位于业务用例的主流程中，建模人员会比较安 心，因为他预计往下建模时，他想要看到的部分肯定会出现；如果待改 进的流程片段位于业务用例的支撑流程中，建模人员可能就慌了，害怕 自己关心的部分漏掉了，于是为了让自己安心，把自己关注的片段提升 为组织的用例。
还是用上文的例子，医院的用例是“患者→看病”，但是下一步待改进的 可能是药剂科的药师盘点药品的流程片段，而这个看起来好像不能从患 者看病的流程里找出来，所以建模人员会担心，然后画出图3-25左侧。也 许画完后建模人员会意识到不妥，特地把研究范围缩小一些，得到图3-25 右侧。两个图药师都在药剂科外面，也是一眼错。
text
图3-25：错误示例 - 把流程片段当组织用例
@startuml
actor "药师"
rectangle "医院" {
(盘点药品)
}
"药师" --> (盘点药品)
note right of (盘点药品)
❌ 错误：盘点药品是药剂科的内部流程，不应作为医院的业务用例
end note
@enduml
@startuml
actor "药师"
rectangle "药剂科" {
(盘点药品)
}
"药师" --> (盘点药品)
note right of (盘点药品)
❌ 错误：盘点药品是操作环节，不应作为组织的业务用例
end note
@enduml
用例下面除了有一条基本路径，还有若干条扩展路径。扩展路径的目的 是预防或应对基本路径上发生的意外。
以上面的“药师盘点药品”为例，如果药师不盘点，会导致真实库存和账 面库存有差距，“患者→看病”的基本路径进行到取药片段时，才发现其 实某种药品已经没有库存或者现有库存药品是坏的，往“患者→看病”的 成功目标行进的道路上遇到了阻碍。当然现在药师盘点药品的责任也基 本分配给了药品记录的系统，也就是业务实体。同理，医院里为什么有保洁员打扫 卫生？为什么内部要花时间搞团队建设？都应该从“患者→看病”的高度 来看。
业务用例代表从组织视角看问题的高度。一个组织内部的所有零件，都 应该从组织价值的角度来认识。不仅指员工或软件系统这样的重要零 件，就连应该用什么颜色的桌子、什么品牌的电脑、盖什么形状的大 楼，都不是随意的。
在周星驰主演的电影《国产凌凌漆》中，陈司令对凌凌漆说，就算是一 张卫生纸、一条内裤，都有它本身的用处。话虽夸张却有道理，组织里 的一草一木都要服从组织的大局。
当前关注的改进点有时是在基本路径中，有时是在扩展路径中，都不应 该影响业务用例图。如果有较大把握判断和愿景相关的片段的位置，直 接在用例下面画该片段即可。否则先画基本路径，再画扩 展路径，画了一大堆才轮到待改进的片段，时间没有花在刀刃上。
就像看病一样，患者说“医生我这两天咳得厉害”（愿景：降低咳嗽的频 繁程度到正常人水平），医生从常理判断可能原因有：咽喉发炎、支气 管发炎、肺部发炎等，决定先给最可能的部位（愿景相关的片段）拍 片。当然，如果拍片发现前面这些推断都是错的，也许就需要来个全身 扫描了。
- 错误4：管理型业务用例
还有一种错误是从“药师盘点药品”推导出背后的好处，然后画成“管理型 业务用例”，如图3-27所示。
这样的“业务用例”不可取。它没有特定组织的味道，哪家营利机构不是 为了赚钱？另外，也很容易和愿景、涉众利益混在一起，发展下去，就 会有“顾客→希望东西更便宜”之类的“用例”。
text
图3-27 管理型业务用例
@startuml
' 错误示例：把组织目标当作用例
actor "董事会"
rectangle "医院" {
(提升利润)
}
"董事会" --> (提升利润)
note right of (提升利润)
❌ 错误：提升利润太宽了，作为愿景都大了
end note
@enduml
@startuml
' 错误示例：把管理口号当作用例
actor "医院管理层"
rectangle "药剂科" {
(加强管理)
}
"医院管理层" --> (加强管理)
note right of (加强管理)
❌ 错误：一眼废话
end note
@enduml