OO系统分析员之路--用例分析系列(6)--用例实现、用例场景和领域模型
上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。
这三项工作成果形成了基本的需求框架，并圈定了业务范围。
这时应当做一份基线。
当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。
这一篇就来说说详细的需求过程和产出物，以及这些成果对需求的贡献。
在开始之前，还是提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。
上一篇确定了业务用例，以及业务场景。
该场景只描述了业务框架，接下来要对业务用例进行场景分析。
用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。
若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。
用例规约将在下一篇描述。
首先是业务用例实现视图。
并非所有的业务用例都一定要最终在系统中实现，因此，这个视图的含义是表达由需求范围到系统范围的映射关系。
这个视图没什么技巧，也可以省略，不过笔者建议不要省略。
需求应当保持过程的连续和可追溯性，这是软件过程可控的重要保证。
业务用例实现视图：
针对每个业务用例实现，应当对用例的实现过程进行场景模拟。
上一篇是业务场景，而用例实现既然已经谈到“实现”，则应当将计算机包括进来，从人-机交互的视角来模拟业务场景。
这是概念模型的一种，表达用户的实际业务在计算机环境下是如何实现的，给用户一个初步印象，告诉他们将来他们将怎样来做业务。
请注意，虽然计算机已经参与需求描述，但是要尽量避免使用计算机术语，因为这时的文档仍然属于需求文档，是要与用户交流的，太多的计算机术语会大大降低用户对需求的理解能力。
霍金在写时间简史时曾经说过，在书中加入哪怕一个数学公式，都会让书的销量减半。
业务用例场景是概念模型的一种，但不是概念模型的全部。
概念模型本篇不打算讨论，简单说一下，概念模型主要包括业务架构和系统原型。
应当在业务用例实现里添加活动图用以描述用例场景，下图为示例，用活动图绘制。
如果有多个场景，则应当绘制多个场景图。
业务用例场景(借书过程)：
用例场景有另一个重要意义，是帮助系统分析员发现和定义业务实体。
业务实体一般来说就是调研时用户所提供的各类表单或报表，但在很多情况下，并非每一份表单就是一个业务实体，所有业务表单也不一定涵盖全了所有业务实体。
很多系统分析员声称业务实体的发现过程是全凭经验的，到底有哪些业务实体，靠经验进行提取。
笔者要说，经验固然重要，但经验有一个最大的缺陷---不能重复和验证。
即，这些实体是怎么从业务中提取出来的？它们是怎样参与业务的？这些实体已经足够支持业务了吗？凭经验分析者无法通过文档将这个提取过程记录下来，而脑子里的东西是无法共享和传承的，越大的团队，越复杂的项目，尤其是横向结构的项目组结构下，这个缺陷越严重。
很多人觉得用UML和RUP描述的需求总是一块块分离的，不知道是怎么出来的，觉得很乱，原因就在于此。
实际上，RUP做需求，每一步都是可验证和回溯的。
用例实现视图是一个例子，这里也是一个例子。
让我们看看上面的业务场景视图，每一个活动都有类似的命名：出示借阅证、查找需要的图书、放入借书栏.....看出什么来了吗？每个活动都是一个动作加上一个动作的受体。
受体正是我们要寻找的业务实体，这些名词就是实体的来源。
在需求阶段，系统分析员不要去考虑什么抽象，什么模式，别急，那是系统模型做的事情。
抽象了，还弄一堆什么Factory模式，Builder模式之类的出来，用户能看懂吗？别忘了我们正在做的是需求文档，是做给用户看的。
观察上面的用例场景，分析出现的名词，我们得到一个个业务实体，再根据场景分析这些业务实体之间的关系。
实际上就是大家都熟悉的ER模型，但是与数据库建模的视角还是有所差别的。
数据库ER模型要受到数据关系范式的限制，而业务实体ER模型则不必理会这种限制。
只要与现实物体符合就OK。
好了，罗嗦了一大堆，我们终于得到了我们的成果。
借阅图书过程业务实体视图：
上图中画那么多虚线连接到业务用例实现是用来表示业务实体与业务用例实现之间的追溯关系的，这些线虽然麻烦，但是笔者强烈建议不要图省事。
因为业务实体通过它们可以追溯到原始需求，再次重申，软件过程要可控，需求可追溯是需要时时谨记的。
当然，如果嫌麻烦，您也可以用下面的这种形式，是不是简
洁得多呢？
经过以上的过程，我们得到了什么呢？往下看之前笔者建议您回想一下，总结一下。
第一、我们通用用例实现视图，从业务用例中找出了那些我们将在系统中实现的用例，并且记录了要在系统中实现的用例是如何映射到原始需求的。
这提供了需求可追溯的验证。
第二、针对每个用例实现，我们引入了计算机，将实际的业务从人-机交互的角度模拟了执行过程。
不仅得到了一个业务怎样在计算机环境下执行的概念模型，同时也给用户描述了他们将怎么和计算机交互以达到他们的目标。
笔者提醒大家，用例场景非常非常的重要，后续工作就得靠它们了！！绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。
第三、通过对场景的分析，给了我们重要的线索去发现业务实体。
而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现。
现在请读者思考一下，如果记不清了，可以翻翻之前的文章。
到现在为止，我们的需求是不是一步一步推出来的？从粗到细，从模糊到清晰，从原始需求到计算机的引入，是不是每一步都是可以追溯的呢？每一步的分析结果是不是都有方法来验证正确性和完备性呢？如果您之前迷惑于需求的各个阶段无法关联，也
说不清分析结果是否是正确的，那么建议您再从头看看笔者目前已经完成的文章，找出这些线索来，相信您会对UML和RUP的理解提高一个层次的。
领域建模方法
领域建模方法领域建模方法是指在软件开发过程中，通过对特定领域进行建模，以便更好地理解和描述该领域的相关概念、属性和关系。
领域建模方法通过对领域的抽象和建模，可以帮助开发团队更好地理解用户需求，准确地描述和分析问题，从而更好地设计和实现软件系统。
一、领域建模的作用领域建模的主要作用是帮助开发团队更好地理解和描述问题领域，准确地捕捉用户需求，从而更好地设计和实现软件系统。
具体而言，领域建模可以帮助开发团队实现以下目标：1.明确问题领域：通过对领域的建模，可以帮助开发团队更好地理解和描述问题领域，明确系统开发的范围和目标。
2.捕捉用户需求：领域建模可以帮助开发团队准确地捕捉用户需求，明确系统的功能和性能要求。
3.分析和设计系统：通过领域建模，开发团队可以深入分析问题领域，识别问题领域中的概念、属性和关系，从而更好地设计和实现系统。
4.验证和验证系统：领域建模可以帮助开发团队验证和验证系统的正确性和一致性，从而确保系统满足用户需求。
二、常用的领域建模方法在软件开发过程中，有许多常用的领域建模方法，包括以下几种：1.实体关系模型（ERM）：实体关系模型是一种常用的领域建模方法，它通过识别和描述问题领域中的实体和实体之间的关系，来建立问题领域的模型。
2.用例图：用例图是一种常用的领域建模方法，它通过识别和描述系统的用例（即系统功能）和参与者（即系统的用户），来建立系统的功能模型。
3.领域模型：领域模型是一种常用的领域建模方法，它通过识别和描述问题领域中的概念、属性和关系，来建立问题领域的模型。
4.状态图：状态图是一种常用的领域建模方法，它通过描述系统的状态和状态之间的转换，来建立系统的行为模型。
5.数据流图：数据流图是一种常用的领域建模方法，它通过描述系统中的数据流和数据处理，来建立系统的数据模型。
三、领域建模的步骤领域建模通常包括以下几个步骤：1.确定问题领域：首先要确定问题领域，即系统开发的范围和目标。
软考高级-系统架构设计师真题知识点总结
1.常见缩写基于架构的软件设计（Architecture-Based Software Design, ABSD)特定领域软件架构（Domain Specific Software Architecture，DSSA）软件架构评估方法：1）架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）2）软件架构分析方法（Software Architecture Analysis Method， SAAM）快速应用开发（Rapid Application Development，RAD)软件开发环境（Software Development Environment，SDE)架构描述语言（Architecture Description Language, ADL)“4+1”视图模型（逻辑开发（姬发）进屋里的场景）-类实现进程部署的例子设计模式：1）创建型：单元相公造；2）结构型：理赔乔装观元组软件架构风格：流返购机舱用例关系包括：包含include、扩展extend、泛化UML图、类图关系：范组局联谊（泛化、组合、聚合、关联、依赖）系统可靠性：冗余技术、软件容错技术（恢复块设计、N版本程序设计）、双机容错技术、集群技术软件可靠性：软件容错设计（恢复块设计、N版本程序设计）、检错设计和降低复杂度设计2.*基于架构的软件设计（ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。
它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。
用例描述的是功能需求，质量属性场景描述的是质量需求。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始。
ABSD方法有三个基础：第一个是功能分解，在功能分解中使用已有的基于模块的内聚和耦合技术。
第二个是通过选择架构风格来实现质量和商业需求。
第三个是软件模板的使用。
ABSD方法是一个自顶向下，递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件的类。
需求分析用例范文
需求分析用例范文用例是一种需求分析工具，用于描述系统如何与各种类型的用户（称为参与者）交互以实现特定的目标。
以下是一个需求分析用例的示例，对于一个在线购物网站：用例名称：用户购买商品主要参与者：用户、网站管理员目标：用户能够浏览和购买在线商城中的商品前提条件：用户必须具有有效的账户，并且已经登录到网站成功情况：用户成功选择并购买所需的商品主要流程：1.用户登录到网站，并使用功能浏览商品目录。
2.用户在结果中选择感兴趣的商品。
3.用户查看商品详细信息，包括价格、描述和评价等。
4.用户决定购买该商品，并将其添加到购物车中。
5.用户选择继续购物或者进行结账。
6.如果用户选择继续购物，则返回步骤27.如果用户选择结账，则显示订单确认页面。
8.用户确认订单，并选择支付方式。
9.如果用户选择在线支付，则跳转到支付平台进行支付。
扩展流程：-如果用户在结果页面中没有找到合适的商品，可以进行新的。
-如果用户在浏览商品详细信息时发现误导性的信息，可以向网站管理员举报。
-如果用户对购物车中的商品进行更改或删除，更新购物车并重新计算总价。
-如果用户选择货到付款或其他非在线支付方式，则不需要跳转到支付平台，而是将订单状态设置为待支付。
特殊要求：-网站应提供安全性保护措施，以保护用户的个人信息和支付信息。
-网站应提供订单跟踪功能，以便用户查看订单的状态和物流信息。
这个用例描述了用户购买商品的正常流程以及一些可能发生的异常情况。
它可以帮助开发团队和用户更好地理解交互过程，并指导系统的设计和实施。
除了这个用例，还可以创建其他用例来描述系统的其他功能，例如注册用户、查询订单等。
这有助于全面考虑系统的需求，并确保系统满足用户的期望和需求。
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
面向对象的分析与设计——用例图实验
面向对象的分析与设计——用例图实验实验目的1、熟悉UML用例图的功能和元素2、学会识别参与者和用例3、掌握用例图的绘制方法4、学会编写用例描述实验内容：任务一：分析图书管理系统的登录模块，且绘制用例图用例图主要在系统需求分析阶段和系统设计阶段使用。
在系统需求分析阶段，用例图用来获取系统的需求，理解系统应当如何工作；在系统设计阶段，用例图用来规定系统要实现的行为。
1、分析用户登录模块的功能需求提供输入“用户名“和“密码“的文本框，验证用户身份的合法性。
2、识别参与者在用户登录模块中，根据工作内容和操作权限的不同，可细分为4类参与者：图书借阅员、图书管理员、系统管理员、图书借阅者。
图书借阅员必须先进行登录，然后才可以执行借出或归还图书的操作；图书管理员必须先进行登录，然后才可以执行编制书目、图书入库等操作；系统管理员必须先进行登录，然后才可以进行系统的维护操作；图书借阅者也必须先进行登录，然后才能查询图书借阅情况或查询图书馆藏书信息。
3、识别用例用户登录模块的主要功能是：输入“用户名“和“密码“，验证用户身份的合法性，故主要用例有两个：输入用户名和密码、验证用户身份。
4、绘制用例图操作步骤：1)运行Microsoft Office Visio 20072)选择“软件和数据库”中的“UML模型图”模板3)鼠标点击选择“UML用例”，展开UML用例图的图标4)用鼠标选拉图标进行绘图5、描述用例用例名称验证用户身份用例编号简要说明验证用户所输入的“用户名“和“密码“是否有效参与者图书管理员、系统管理员、图书借阅员、图书借阅者当前状态等待审查使用频率较高前置条件已输入有效的“用户名“和“密码“后置条件登录进入系统基本操作流到“用户信息“数据表中检索是否存在相应的“用户名“和“密码“备选操作流如果“用户名“和“密码“有误，显示提示信息。
任务二分析网上书店的业务需求，且绘制用例图站在客户的角度分析，网上书店要实现的基本功能主要有以下几种：（1）用户注册（2）用户登录（3）图书查询与浏览（4）用户订购图书（5）用户购物车管理（6）订单维护（7）个人信息维护当客户打开网上书店后，无需登录即可查询图书，还可查看图书的详细信息。
用例（UseCase）
⽤例（UseCase）1. 基本概念⼀个⽤例就是与参与者（actor）交互的，并且给参与者提供可观测的有意义的结果的⼀系列活动的集合。
所谓的⽤例就是⼀件事情，要完成这件事情需要做⼀系列的活动；⽽做⼀件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为⽤例场景，⼀个场景就是⼀个⽤例的实例。
要启动⽤例是有条件的，这是启动⽤例的前提（前置条件）；⽤例执⾏完了会有⼀个结果，成为后置条件。
综上所述，⼀个完整的⽤例由参与者、前置条件、场景、后置条件构成。
2. ⽤例的特征⽤例之间是相互独⽴的⽤例的执⾏结果对参与者来说是可观测且有意义的不存在没有参与者的⽤例，参与者启动⽤例（⽤例不应该⾃动启动，也不应该主动启动另⼀个⽤例）⽤例必然是以动宾短语形式出现的（构成⼀个完整的事件，例如喝⽔⽽不是喝）⼀个⽤例就是⼀个需求单元、分析单元、设计单元、开发单元、测试单元，甚⾄部署单元3. ⽤例的粒度（如何细分/尺度的确定）业务建模阶段：⼀个⽤例可以描述⼀项完整的业务流程（这有助于明确需求范围）概念建模阶段：⼀个⽤例能描述⼀个完整的事件流（⼀项完整业务中的⼀个步骤）系统建模阶段：⼀个⽤例能描述操作者与计算机的⼀次交互总结：粒度选择问题本质上由边界的认定不同⽽产⽣，原则是在同⼀个需求阶段，所有⽤例的粒度应该是同⼀个量级的。
4. ⽤例的获得⽤例的定义就是：由参与者（actor）驱动的，并给其提供可观测的有意义的结果的⼀系列活动的集合。
所以⽤例的来源就是：参与者（actor）对系统的期望。
所以发现⽤例的前提条件就是：发现参与者；⽽确定参与者的同时就确定了系统边界。
接下来通过以下问题引导业务代表，并从访谈结果中找出⽤例：您对系统有什么期望？（⼀件可以做的事，⽽不仅仅是⼀个主观愿望）您打算在这个系统⾥做些什么事情？您做这件事的⽬的是什么？您做完这件事希望有⼀个什么样的结果？应当确保：⼀个明确的有效⽬标才是⼀个⽤例的来源⼀个真实的⽬标应当完备地表达主⾓的期望⼀个有效的⽬标应当在系统边界内，由主⾓发动，并具有明确的后果如果发现有些业务总是说不清，应当考虑重新进⾏访谈，并考虑以下策略：调整系统边界和主⾓扩⼤或缩⼩系统边界变更主⾓然后重新开始5. ⽤例的实现完整叫法是系统⽤例的实现，不过系统⼆字可以省略。
uml用例描述
uml用例描述在软件开发过程中，用例是一种用来描述系统功能和用户需求的工具。
UML（Unified Modeling Language）是一种常用的建模语言，其中用例图是用来描述系统功能和行为的图形表示方法。
本文将使用UML用例图的描述方式，来介绍一个名为“在线购物系统”的软件系统。
1. 引言在线购物系统是一个电子商务平台，为用户提供了在线购买商品的功能。
本系统的主要参与者包括注册用户、游客和管理员。
注册用户可以浏览商品、添加商品到购物车、下单购买商品等；游客可以浏览商品，但无法添加商品到购物车或下单购买；管理员负责管理商品信息和用户信息。
2. 用例图下面是“在线购物系统”的用例图：- 注册用户用例：注册用户可以执行的操作包括浏览商品、搜索商品、添加商品到购物车、下单购买商品、查看订单状态和评价商品。
- 游客用例：游客可以执行的操作包括浏览商品、搜索商品和查看商品详情。
- 管理员用例：管理员可以执行的操作包括添加商品、编辑商品信息、删除商品、管理用户信息和查看订单信息。
3. 详细描述3.1 注册用户用例- 浏览商品：注册用户可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：注册用户可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 添加商品到购物车：注册用户可以将感兴趣的商品添加到购物车中，以便稍后进行结算。
- 下单购买商品：注册用户可以选择购物车中的商品，生成订单并进行支付。
- 查看订单状态：注册用户可以查看自己的订单状态，包括待支付、待发货、已发货等。
- 评价商品：注册用户可以给已购买的商品进行评价，以供其他用户参考。
3.2 游客用例- 浏览商品：游客可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：游客可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 查看商品详情：游客可以查看具体商品的详细信息，包括商品介绍、规格、用户评价等。
面向对象需求分析——用例图和活动图
面向对象需求分析——用例图和活动图面向对象软件开发的方法有：a，面向对象分析（OOA）b,面向对象设计(OOD）c,面向对象实现（00I）d，面向对象测试（OOT）,e，面向对象维护（OOM）这几个主要大步骤。
下边我们就从面向对象的角度来学习UML的相关图。
这里介绍面向对象分析阶段的用例图和活动图。
面向对象分析阶段，我们要明确系统的职责，范围和边界；确定软件的功能和性能；构建需求模型（用例模型）。
首先在这里说一下，为什么将这两个图放在一起，主要原因就是活动图的一个目的是更细致的描述用例图，和文档的配合使用，使用例图更加清楚明了。
先介绍一下：用例图1，概念：用例是系统的一个功能单元，是对用户需求的描述。
2，组成：参与者，用例及其之间的关系（包括关联关系，泛化关系，包含关系，扩展关系）：3，用例建模的步骤：a,确定系统的范围和边界；b,确定系统的用例和参与者；c,描述用例；d，对用例分类，并确定用例之间的关系；e,建立用例图，并定义用例图的层次结构；f,评审用例模型。
下边我们看个例子：这是一个教务管理系统的总用例图和一个子一级用例图，当然还可以再分：在上述6个步骤中，我简单总结一下：a,系统边界，就是一个系统内部所有元素与系统外部事物的分界线。
b,用例和参与者，需要我们根基实际情况去抽象。
c,描述用例，这个我重点写一下（举例，选课注册）：用例编号：0101用例名称：选课注册执行者：学生功能：实现学生选课注册的过程类型：主要用例，基本用例级别：一级过程描述：1，学生输入系统账号和密码，系统进行验证；2，查询课程信息3，查询个人选课信息4，若可以选课，则进行选课注册，并将选课信息写入数据库中5，返回选课注册是否成功异常事件流处理：1，学生的账号和密码错误，允许重新输入（3次）2，学生未按时交纳学费，不可选课3，学生人数已达到上限，不可选课。
（当然在这里在把下边的活动图，添加进来即可）d,用例分类和确定之间的关系，有端点用例，基本用例，主要用例，辅助用例等，关系弄准确就可以。
用例和用例图
访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架
用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂
事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。
扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
第3章 用例图
案例分析--用例图
实例：“杂志流通”
在杂志的内容被一个雇员分析之前，每个杂志 首先由图书馆登记；分析员认为有意义的文章 被汇总输入到系统中；随后，杂志在雇员中传 阅。在此过程中，要求生成流通通知。该通知 被附到杂志上，并且包含现在正在阅读杂志的 雇员的名字。最后，在最后一名读者把杂志返 回到图书馆时，它由图书馆来存档。
3.1 参与者
从上面的问答得到系统中初步的类和对象：
GUI（图形用户界面）：识别用户的命令，接收 用户的输入，显示程序的结果。
Recorder（记录员）：记录中奖信息。 Chooser（抽奖者）：抽出中奖号码。 Printing（打印对象）：打印中奖信息。 Searching（查询对象）：为奖票持有者查询中
3.2 用例
问：抽奖主持人用这个系 抽奖程序初步的用例图
统做什么事情？兑奖人员
抽奖程序
如何用这个系统帮助兑奖
？
抽出中奖号码
答：抽奖主持人用这个系统 活动主持人 抽出中奖号码，兑奖人员用
活动主持人
这个系统打印本次活动所有
打印中奖记录
的中奖记录。再对照记录兑 兑奖者
兑奖者
奖。
查询中奖情况
奖票持有者
奖票持有者
用例图的构成4要素：
参与者 用例 系统边界 关联
用例图的基本概念
3.1 参与者
1. 参与者(Actor)的概念
参与者是指存在于被定义系统外部并与该系统发生 交互的人或其他系统，他们代表的是系统的使用者 或使用环境。
在确定系统的用例时，首要问题就是识别参与者 （是一个类！！！！！！不是对象）。
如何识别用例？
参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？