《大象：thinking in uml 》(第二版) 3章 UML核心元素 3节用例

只供参考，喜欢请支持正版图书

3.3 用例

用例在UML建模中是最最重要的一个元素。之所以说它重要，是因为UML是面向对象的，除用例之外，所有其他元素都是“封装”的、“独立”的。回顾一下我们在1.1.3节面向对象方法中讲到的内容，这些元素在没有“外力”作用时是“鸡犬之声相闻，老死不相往来”的。而用例正是施加这一“外力”的元素，正是用例使得其他那些“孤独”的UML元素能够共同组成一篇有意义的文字。因而没有准确的用例定义一切都无从谈起。

3.3.1 基本概念

用例：Use Case

所谓的用例，就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景。一个场景就是一个用例的实例

例如你想做一顿饭吃，你需要完成煮饭和炒菜两件事情，这两件事情就是两个用例,而煮饭这件事情是可以有不同做法的，你可以用电饭煲做，也可以用蒸笼做，这就是两种不同的场景，也就是两个实例。而同样是用电饭煲做，如果是糙米，你可能要先淘米，再下锅；如果是精米，你就可以省掉淘米步骤直接下锅。这是用例在不同条件下的不同处理场景。

要启动用例是有条件的，要做饭，首先得要有米。这是启动用例的前提，也称为前置条件；用例执行完了，会有一个结果，米变成了饭。这称为后置条件。综上所述，一个完整的用例定义由参与者、前置条件、场景、后置条件构成。图3.8展示了用例的结构。
一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来了。捕捉功能性需求，这就是用例的作用

3.3.2 用例的特征

■　用例是相对独立的
这意味着它不需要与其他用例交互而独自完成参与者的目的。也就是说用例从“功能”上说是完备的。用例本质体现了系统参与者的愿望，不能完整达到参与者愿望的不能称为用例。例如取钱是一个有效的用例，填写取款单却不是，如图3.9所示。因为完整的目的是取到钱，没有人会为了填写取款单而专门跑一趟银行的。

例如，有一个后台进程监控参与者在系统里的操作，并在参与者删除数据之前执行备份操作。虽然它是系统的一个必需的组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该作为系统需求在补充规约中定义而不是一个用户需求

又比如说，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但单纯地输入密码却是没有意义的，输入完了呢？有什么结果吗？如图3.10所示。
■　这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

用例总是由一个参与者发起的，参与者的愿望是这个用例存在的原因。例如从ATM取钱是一个有效的用例，ATM吐钞却不是。如果ATM无缘无故吐钞的话人们还需要工作吗？从此天天守在ATM旁守株待兔就行了。如图3.11所示。
■　用例必然是以动宾短语形式出现的
用例必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是，如图3.12所示。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的
■　一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元

3.3.3 用例的粒度

粒度是令人困惑的。比如在ATM取钱的场景中，取钱、读卡、验证账号、打印回执单等都是可能的用例，显然，取钱包含了后续的其他用例，取钱粒度更大一些，其他用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小用例合适呢？

这个问题并没有一个标准的规则，笔者可以给大家分享的经验是在项目过程中根据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱、报装电话、借书等表达完整业务的用例，而不要细到验证密码、填写申请单、查找书目等业务中的一个步骤

在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。

在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、派发任务单等。可理解为一个操作界面或一个页面流。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜.

请记住一点，用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。这样，实际上适合用例是借书。只有一个，其他都只是完成这个目的的过程。

现实情况中，一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。比如，针对一个50人年的大型项目应该选择更大的粒度，如果用例粒度选择过小，可能出现上百甚至几百个业务用例，造成的后果是需求因为过于细碎和太多而无法控制，较少的用例有助于把握需求范围，不容易遗漏。而针对一个10人月的小项目应该选择小一些的粒度，如果用例粒度选择过大，可能只有几个业务用例，造成的后果是需求因为过于模糊而容易忽略细节。一般来说，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。

不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的

3.3.4 用例的获得

在开始捕获用例之前，我们需要做好如图3.14所示的准备工作。
在准备发现用例之前，再强调并确认你已经能够清楚地理解了下面的几个问题：

■　主角是位于系统边界外的。
■　主角对系统有着明确的期望和明确的回报要求。
■　主角的期望和回报要求在系统边界之内。

接下来，可以开始对主角，即业务代表进行访谈。访谈时请不要试图让业务代表为你描述整个业务流程，也不要涉及表单填写一类的业务细节，甚至你可以不关心业务规则，更不要试图让业务代表理解将来的计算机系统会如何工作。你只需要让业务代表从他自己的本职工作出发来谈谈他的期望，并时时提醒和引导那些喜欢一讲什么事情就深入到细节当中去的客户。可以通过以下问题引导业务代表，这些问题对用例获取来说已经足够了。

■　您对系统有什么期望？
■　您打算在这个系统里做些什么事情？
■　您做这件事的目的是什么？
■　您做完这件事希望有一个什么样的结果？

也许只是他做事情的一个步骤。比如客户或许会说我首先做……，然后做……，最后做……，你需要从冗长的谈话中为客户总结出他的真实目标来

不同主角对同一目标可能会有不同的表达，例如客户甲说我希望能把我这些文件保存下来以供将来查询，而客户乙说我要能查看我之前工作过的所有工作记录。或许甲和乙口中的文件和工作记录就是同一件事情，你应当去伪存真，求同存异，而不是简单地就分为两个用例

不同主角的目标可能会相互重叠，呈现出一种交集的状态。你应当小心求证，是否这些主角所谈的都只是某个完整目标的一个部分？如果这样，应当合并成一个用例，并假定这两个主角在这个用例中只是担任业务工人的角色而不是真正的主角

或者这些主角所谈的是有交叉的部分，但的确是两个不同的目标。如果这样，应当就是两个用例

至于交集的部分，需要在概念模型（参看5.3节概念用例模型）中去提取公共的业务单元。总之，你应当确保：

■　一个明确的有效的目标才是一个用例的来源。
■　一个真实的目标应当完备地表达主角的期望。
■　一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。

在重新开始访谈以前，你应该考虑调整以下策略：

■　调整系统边界和主角。
■　扩大或缩小系统边界。
■　变更主角。
■　重新开始。

ATM取钱的示例虽然已经被用得很滥，但是这是每个人都熟悉的场景，用它来做一个例子，也是不错的选择

客户代表（主角）说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳电话费、水费、电费等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。

提给读者的问题1：下列哪些是有效用例，哪些不是？

■　支持跨行业务？
■　插入卡片？
■　输入密码？
■　选择服务？
■　取钱？
■　存钱？
■　挂失卡片？
■　交纳费用？
■　警示骗子？
■　三次错误吞没卡片？

3.3.5 用例和功能的误区

在实际应用中，用例是非常容易被误解和误用的。尤其是习惯了面向过程结构化设计方法的计算机技术人员，最普遍的理解错误是认为用例就是功能的划分和描述。他们认为一个用例就是一个功能点。在这种理解下，用例建模变成了仅仅是较早前需求分析方法中功能框图的翻版。很多人用用例来划分子系统、功能模块和功能点。如果这样，用例根本没有存在的必要，有功能框图就行了。请特别注意：虽然在用例的定义一节里谈到用例是捕获功能性需求的，但是有一个前提条件，即这个功能性需求是从参与者的角度出发的，用例并不是功能。

如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？很不幸，这个理解是错误的！

为了解释这个问题，我们需要从描述事物的方法入手。在描述一个事物的时候，我们可以从以下三个观点出发：

■　这个事物是什么？
■　这个事物能做什么？
■　人们能够用这个事物做什么？

例如，描述一辆自行车的时候，我们通常这样说明：第一，自行车是一种交通工具，它由传动系统、刹车系统等部分组成；第二，自行车可以骑行，可以载物；第三，人们可以用双脚蹬动踏板而向前行进，可以用手捏合刹车使自行车停下来。图3.15展示了描述问题的这三种观点。
第一种描述是一种结构性观点，即事物的客观存在。但是这个观点不能够说明事物的作用，也就是功能性方面的信息。从结构上来说，同样是一个圆环，把它用在汽车上，它可以是方向盘，把它用在自行车上，它就是轮子了。所以仅有结构性观点是不够的。

第二种描述是一种功能性观点，说明事物可利用的价值。但是这个观点不能够说明事物在某种情形下的真正价值，也就是它缺乏上下文环境，没有人来使用，事物的所有可利用价值可能是无意义的。换句话说，没有人使用的功能是没有意义的。

第三种描述是一种使用者观点，说明事物对于使用者的意义，以及使用者可以怎么使用它，得到什么样的利益。这种观点不能够说明事物的本质结构，它只是从表面揭示了事物相对于使用者来说是什么，能做什么，可以获得什么。

软件恰恰就是一种还不存在的事物。对于正准备开发的软件，我们不能从结构观点去描述它，也不能从功能观点去描述它，最好的方法就是从使用者的观点去描述它。不能从结构观点去描述好理解，毕竟这是一个还没有做的东西，结构是未定的；不能从功能的角度去描述它，读者心里一定在犯嘀咕，不可理解，软件有什么功能不是显而易见的吗？真的如此吗？

那么请你制造一个具有开启功能的东西。嗯？你不清楚究竟要你做什么？好，让我从使用者观点再说明一下，请你制造一个东西，人们可以用它来开启酒瓶。现在清楚了么？

回到软件开发上来，从功能观点出发，采用功能分解方式来获取需求的方式，因为缺少了上下文，功能很可能就变成了对使用者无用的，或者使用者不知道怎么用的东西。

客户想要一个开瓶器，你可能给客户送来一把钥匙，反正都是具有开启功能的呀。在软件开发过程中，经常出现开发完成之后客户不满意，认为这不是他们想要的东西，与其说是需求不清楚，不如说是方法不对路。因为在一开始，需求收集人员就没有从使用者的观点出发来描述系统，由于缺乏了使用者上下文，功能描述偏离使用者预期就是很正常的了。

使用者观点实际上就是用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得出结构性的和功能性的内容，最终实现用例，也就实现了使用者的观点。

通过上面的分析可以得出这样一些总结：
第一，功能是脱离使用者的愿望而存在的。习惯于以功能来看待系统的团队，喜欢从系统的角度出发，说明系统能做什么，而常常系统能做什么并不是使用者关心的。用例是描述使用者愿望的，描述的是使用者对系统的使用要求，用用例来看待系统的团队，则是从使用者角度出发，说明使用者将在系统里做什么。

第二，功能是孤立的，给一个输入，通过计算就有一个固定的输出——只要按下开关灯就亮。用例是系统性的，它需要描述谁在什么情况下通过什么方式开灯结果是什么。习惯使用功能分解来看待系统的团队，习惯从开发者角度出发，提供大量的功能点，指望客户像UNIX高手一样，自己从指令集中找到适合的指令来完成工作。而用用例来看待系统的团队，习惯从客户角度出发，为客户量身定制他们的要求。

第三，如果非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式。并且，不是先有了这些“功能”才来组合成某个场景，而是先有了场景，才分解出“功能”。这里的“功能”之所以打引号，是因为在UML里是没有功能这个词的，实际上从场景分解出来的是对象，这些对象通过消息相互交流而完成场景

最后举一个例子。从功能的角度出发，对电视的描述是能开关，能显示，可以调频道，可以调声音，以上四者是独立的；从用例的角度出发，对电视的描述是有一个人要观看电视节目的用例，要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来的。读者可以细细品味一下这其中的区别。

3.3.6 目标和步骤的误区

一个用例是参与者对目标系统的一个愿望，一个完整的事件。为了完成这个事件需要经由很多步骤，但这些步骤不能够完整地反映参与者的目标，不能够作为用例

如何理解这个误区呢？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。把寄信作为用例是很自然的事情，根据图3.16，可以这样描述这个事件：寄信人到邮局寄信。
如果以完成这个完整事件的步骤作为用例，图3.17看上去似乎也挺合理的。但是如果我们来描述这些事件，就会出现这样的笑话：寄信人到邮局付钱。你也许会争辩说，付钱也是合理的，因为我之前买了信封，买了邮票，所以付钱。没错，你需要加上前因后果才能把这件事情讲清楚。但是别忘了你现在是在描述一个需求，寄信人会有一个到邮局付钱的需求吗？

下面就是这样一个场景，来自笔者与一个网友的真实对话。这位网友在为一个绘制3D模型的绘图工具建模，他的用例类似如下：选择某个模型、配置模型参数、调整模型等。为了让他明白他所定义的用例是值得商榷的，并没有体现参与者的完整目标，笔者与他进行了以下对话：

笔者：用例是一个完整目标，要达成目标要分几个步骤，但只有完整的目标才是用例。

网友：“完整”的目标，怎么理解啊？

笔者：假设你去邮局寄信，你需要做些什么事情？

网友：很多事情啊，找到邮局，填写邮寄地址表，付钱……

笔者：好，就拿付钱来说，付钱本身也可以分很多步，对吧？

网友：对。

笔者：问题是你付钱的时候可以只完成其中的一部分步骤吗？比方说只掏出来给邮局职员看一眼。

网友：不可以。

笔者：所以你可以判断付钱是完整的事件，从口袋里掏钱包就不是。

网友：明白了，掏钱的目的是为了“付钱”。那付钱是一个用例喽？

笔者：是吗？如果这是一个用例，意味着你去了邮局，把钱给柜台，然后就回家了，你会吗？

网友：不会。这么说付钱也不是用例，付钱是为了别的目标，比如寄信。

笔者：对！

网友：还有寄包裹也算。

笔者：是的。完整的目标要从参与者的角度出发。如果你不能确认，就设置一个场景，像我们刚才一样，设问一下就明白了。

网友：那我明白了，选择某个模型、配置模型参数这些都是绘制模型的步骤，不能作为用例的。

笔者：实际上这些也是可以作为用例的，但是你不能用它们来描述功能性需求。在进行用例分析的时候，它们可以作为概念用例使用，或者在建立系统模型的时候，它们也可以作为系统用例使用。但是在描述功能性需求时，记住用例一定是参与者的完整目标。

在对需求进行分析时，实际上我们已经进入了用例的内部。进入用例的内部意味着边界已经改变，而边界的改变必然导致参与者也在改变（请参看3.2参与者一节中参与者与边界的关系）。通常，参与者已经变成了原来的业务工人，自然的，参与者的完整目的也就改变了。同时，还由于已经进入用例的内部，表示现在参与者的所有活动都处于该用例的上下文环境之内

寄信和收钱，两个用例大小不同，边界不同，参与者也不同，它们显然不应该同时出现在一个视图里。但是现实情况是很多人将不同大小的用例建模在同一个视图里，这就引出了下一个误区：用例粒度的误区。

3.3.7 用例粒度的误区

产生用例粒度错误的原因首先是分不清目标和步骤，在上一节中已经讲过，用步骤划分用例会导致不准确的需求获。

用例粒度另一个常常被误用的误区是在同一个需求阶段中的用例粒度大小不一

举例说明，假设有一个网上购物系统。在获取需求时，我们决定采用整个系统的边界作为起点，那么参与者就应当是系统之外的，例如买家、卖家、系统管理员等。相应的，这些参与者的完整目标就构成用例，用例的粒度就是系统的最高层次，它们展示业务构成。例如买家购买商品，卖家发布商品，系统管理员维护网站等。初看上去这些用例的粒度很大，有点大而空，离指导开发还很遥远。如果是一个很复杂的系统，采取这样的高层次抽象角度是很有必要的。这个例子的用例获取结果如图3.18所示。
图3.18的结果是由边界和抽象层次决定的，但是如果在心中没有时时紧守边界的建模者，非常容易因为嫌粒度太大什么都没说清楚而试图把需求说得更清楚，其结果反而是过犹不及，不自觉地突破了无形边界的限制，把用例的粒度搞得一片混乱。

假设上面所述的网上购物系统中，买家购买商品时有这样一个业务过程：买家下的定单如果出现了问题，或者商家和买家任一方要求修改定单时，将由系统管理员来完成修改工作。相比大而空的购买商品用例，这个业务过程清楚多了。面对这个需求信息，不知读者会如何来建立模型？相信有相当一部分读者会很迫不急待地把这个重要的信息加入业务模型，得到图3.19所示的结果。
读者觉得图3.19所示的模型有问题么？初看上去十分符合要求，修改定单的确是系统管理员做的一件事情，似乎并无什么不妥。但是无形中建模者已经缩小了边界，降低了抽象层次，实际上修改定单这个用例的粒度已经比其他用例的粒度要小。有读者要问，不一致就不一致，有什么问题吗？有，有很多问题。

首先，作为修改定单的参与者，虽然名字仍然叫做系统管理员，但实际上就修改定单这件事情来说，系统管理员只是购买商品这个用例场景中的一个业务工人，也就是说系统管理员修改定单的目的是服务于购买商品用例的，并不是一个完整目标。这种情况下，当我们用业务模型中的用例来描述它们如何构成业务场景的时候，修改定单是无法融入到这个业务场景中的。例如这样来描述这个业务场景，说商家发布商品，买家购买商家发布的商品，系统管理员修改订单，就会显得修改定单在这个业务场景中格格不入。因为修改定单根本就和发布商品和购买商品不在一个层面上，它只是购买商品过程中的一个子过程而已

其次，用例将驱动软件架构的建立，如果这样建模，把本来属于购买商品用例中的一个步骤提升成一个用例与购买商品用例并列，那么很自然地软件架构中系统管理员就会拥有修改定单的一个专门模块，而这个模块则必须依赖于购买商品模块，从架构上讲，两个原本关系紧密，有强依赖关系的逻辑被分成了两个在架构上要求独立的模块，总是一种很糟糕的设计。

那么应当怎么处理系统管理员修改定单这个业务过程呢？办法是紧守边界，认识到现在的抽象层次高于这个业务需求，它不能作为一个单独的用例在这个抽象层次上出现。保持图3.18的原状不动，在接下来单独分析购买商品用例的时候，由于边界已经缩小为购买商品用例的内部，自然地不管是修改定单作为购买商品的一个步骤也好，还是系统管理员作为购买商品用例的一个业务工人也好，都能够很自然地出现在概念模型里，成为购买商品这个用例实现过程中的一个关键概念。这时，由于已经位于购买商品的上下文环境里，它就能够很自然地与其他购买商品的关键概念构成用例场景，比如这样描述业务场景：买家提交修改定单请求，系统管理员修改定单请求就很自然了。

还是那句话，不论边界和抽象层次如何选择，粒度大小如何决定，在同一个需求阶段，必须保持所有用例的粒度在同一量级！

3.3.8 业务用例

业务用例（business use case）是用例版型中的一种，专门用于需求阶段的业务建模。在为业务领域建立模型时应当使用这种版型。请注意业务用例只是普通用例的一个版型，并不是另一个新的概念，因此业务用例具有普通用例的所有特征。

业务建模是针对客户业务的模型，也就是现在客户的业务是怎么来建立模型的。严格来说业务建模与计算机系统建模无关，它只是业务领域的一个模型，通过业务模型可以得到业务范围，帮助需求人员理解客户业务，并在业务层面上和客户达成共识。有一点必须说明，业务范围不等于需求，软件需求真正的来源是系统范围，也就是系统模型（6.2节系统建模工作流程）。业务模型是系统模型的最重要输入

既然业务用例是用于描述客户现有业务的，它的参与者就是业务主角。站在业务主角的立场上看到的边界是业务边界而非系统边界，这一点请务必区分。如果说用例是用来获取功能性需求，那么可以说业务用例用来获取功能性业务。

举例说明，为一个图书馆开发借书系统，建立的业务模型是基于客户的现有业务的，也就是说哪怕我们明明知道计算机可以实现自动提示哪些读者逾期没有归还图书这一要求，在业务建模时业务用例也不应当将计算机包括进来。如果要描述这项业务要求，应当用“查阅逾期未还者”之类的描述，而不应当用“计算机自动提示逾期未还者”之类的描述。因为就算没有计算机参与，客户也有这样一项业务存在，尽管可能只是手工翻看登记台账。

之所以不能够把计算机引入进来，是因为业务范围不等于系统范围，不是所有的业务都能够用计算机来实现的

3.3.9 业务用例实现

业务用例实现（business use case realization），也称为业务用例实例，是用例版型中的一种，专门用于需求阶段的业务建模。在为业务领域建立模型时采用这种版型。

从字面上理解，业务用例实现就是业务用例的一种实现方式。一个业务用例可以有多种实现方式，它们的关系可以类比编程上的接口和实现类的关系，同一个接口可以有多个实现类。同样的，一个业务用例的多个业务用例实现都是为了达成同一个目的，但是每个业务用例实现为达成这个目的而采用的方式各不相同。业务用例实现的意义就在于此，它们表达了同一项业务的不同实现方式。

举例说明，我们使用电话，就需要向电话局交纳电话费。将电话局作为一个业务边界，那么作为这个业务边界的参与者，电话使用者就有交纳电话费的业务目标，我们可以为电话使用者建立一个交纳电话费业务用例。如果我们向电话局展开调研，就会发现同样是交纳电话费的业务目标，有很多种可能的实现方式。比如可以直接到电话局营业厅交纳，也可以在电话局预存一笔话费，还可以到银行通过银行代缴。每一种可能的方式都实现同样的交费目的，从业务目标上来讲并没有什么差别，但在业务执行上是完全不同的。因此在建立业务模型的时候，我们就可以用营业厅交费、预存话费和银行代交费的业务用例实现来“实现”交纳电话费业务用例，如图3.20所示。
业务用例实现是实现对象追溯到需求的一个重要环节。在后续的建模过程中，我们根据业务用例实现将得出关键业务对象，再从业务对象转化到设计对象，从而生成代码。

3.3.10 概念用例

概念模型用来获取业务模型中的关键概念，分析出业务模型中的核心业务结构以得到一个易于理解的业务框架。实际上业务架构（参看5.7.1.1节业务架构）就是在这个阶段产生的。

注：即使是业务架构本身，也很少被人使用。但业务架构的确是业务分析中很重要的一个成果，它对软件架构有着直接的影响。

作为概念模型中的核心元素，概念用例用来获取业务用例中的核心业务逻辑，这些核心业务逻辑揭示了业务模式，成为业务架构的重要指导。同时，概念用例还是从业务用例到系统用例过渡时非常重要的指导。虽然概念用例不是必需的，但是对于复杂业务来说，缺少了它，系统用例的产生就会显得突兀和生硬，基本上都是拍脑袋得出来的结果。
上面的例子仅作为简单的示例，更多内容将在5.3节概念用例模型中讲述。

3.3.11 系统用例

系统用例没有定义版型。实际上它就是我们天天挂在嘴边的用例，因此接下来本书中把系统二字去掉，直接称之为用例。如果不是特别强调，读者可以把用例等同于系统用例。

系统用例是软件系统开发的全部范围，系统用例是我们得到的最终需求。估计大部分人在绘制用例图的时候并没有认真想到过采用用例这一元素建模，实际上正在做的事情是划定开发范围，确定系统需求。

3.3.12 用例实现

勿须过多解释，用例实现的前面还有两个字，完整的叫法是系统用例实现，不过“系统”二字同样可以省略。类似业务用例实现，一个用例实现代表了用例的一种实现方式

虽然理解起来不会有太多困难，我们还是举个例子来说明。有这样一个需求，我们要在网上申报业务，就需要提交申请。考虑到填写内容较多，时间过长，会话可能失效，也考虑到有些用户使用拨号上网带宽窄速度慢的问题，系统打算支持两种提交方式，一种是在线提交申请，另一种是离线提交申请。第一种方式在网页上在线填写申请单，直接提交；第二种方式则是下载一个表格，填写完之后再上传。这两种方式都是实现提交申请这个用例的，因此可以用在线提交申请和离线提交申请这两种用例实现来表达这种需求。

现实情况中绝大部分项目都是做完用例模型后，直接开始进入数据库表设计、类设计等。有些思考比较深入的项目组成员常常心存疑虑，因为他们不知道这些数据库表和类是依据什么出来的，好像是一拍脑袋就出来了，美其名曰凭经验。其实用例实现正是连接起用例模型和系统实现之间的桥梁。

只供参考，喜欢请支持正版图书