Use Case是什么?
用况的概念最早是Jacobson提出的，他给出的定义是：一个用况是通过使用系统功能的某些部分而使用系统的一种具体形式。每个用况包括一个由参与者发动的完整事件过程。它详细说明了参与者与系统之间发生的交互。因此，一个用况是一个由参与者和系统在一次对话中执行的特定的相关事物序列。
《面向对象分析与设计》给出的定义是：参与者使用系统的一项功能时所进行的交互过程的描述，其中包括由双方交替执行的一系列动作。
理解Use Case定义
这两者的定义是有些许差别的，我更倾向于使用后者的定义。因为前者认为用况是由参与者发动的完整事件过程。但是如果系统内部发现异常，那么系统需要作为动作发起者，通知参与者做出外部干预，那么这一系列动作的发起者不是外部参与者，而是系统本身，所以前者定义不够全面。
回到第二个用况定义，深入理解它所表达的含义。
- 一个用况只描述参与者对单独一项功能的使用情况。如果一个功能可以拆成许多较小的功能（仍是完整的），则应该使用多个用况描述。举一个简单的例子，银行系统中的资金管理功能，这不是一个用况能描述清楚的。
- 用况陈述了参与者与系统在交互过程中双方所做的事，而不是单独一方所做的事。如果多个功能都进行了同样的操作，而这个操作不能被操作者直接启动的话，书中是不建议单独分出一个用况的（不必要的），我觉得有时分出来也不是完全不行（暂时理解不到为什么把这种情况给去掉了）。
- 在所有用况中，由参与者发起的对话最为常见，但是有些对话也可能是系统发起的。
- 用况的典型用法是描述参与者和系统彼此为了对方做了什么，而是描述怎么做！
- 一个用况可以由多种参与者使用。
- 一项系统功能需要多个参与者同时交互才能使用。
如何定义Use Case
要想分析用况，首先需要将自己当作参与者，然后与设想中的系统进行交互，考虑以下几个问题：
- 进行这种交互是为了使用系统的什么功能
- 使用该功能的目的是什么
- 为达目的，需要向系统输入什么信息（信息的传递过程即为交互）
- 希望系统进行怎样的处理并从它那得到什么结果（系统内部行为）
交互行为连接了功能分析和用况分析，即参与者/系统会主动做出那些交互行为，从交互起点入手、分析以此为起点的一系列动作。
要点：
- 全面的了解和收集用户所要求的各项系统功能，确定系统边界，找出所有参与者，向用户和有关专家了解各项功能的相关业务流程。
- 把用户提出的功能组织成合适的单位，即：一次交互完成一个完整而独立的功能。（需要多次交互才能完成的功能可以认为是前置的多个交互（用况）完成后的单次交互结果，比如：第一，拍照功能。你需要打开相机、调整焦距、按下快门。那么拍照这个功能可以分解为3个用况，因为你进行了3次交互。第二，银行的转账，这之间其实也包含了多次交互，输入目标账号、金额，点击转账，输入密码，点击确定。那么这个需要分成4个用况吗？分的太散显然是不合理的，因为输入密码和点击确认虽然是两次交互动作，但是这两个动作是密不可分的，所以可以是转账用况（基用况）包含了密码确认用况（包含用况））。
- 穷举每一类参与者所使用的每一项系统功能，定义相应的用况。
- 检查用户对系统的各项功能需求是否都通过用况得到了描述。
个人感觉从不同的参与者需要与系统进行交互的种类为入手点好思考一些。因为交互连接了系统与参与者，每次交互都是为了完成某一项功能，它连接了需求分析和功能分析。
之后还有一些用况之间的关系，比如包含、延伸、泛化等，这些分类方法可以在已有用况中分离部分动作作为基础用况，让整体的模型更为生动。当然泛化关系是不建议使用，因为这种机制难以描述清楚在什么位置、什么条件下插入被包含的用况，倒不如使用包含的关系，由一个基用况来判断在什么条件下使用哪一个子用况。
Use Case图绘制要素
一个完整的用况图应该包含系统、参与者、用况和关系。
Systems
系统就是开发的所有东西。它可以是网站、软件组件、应用程序或者其他。
通常使用一个矩形来代表系统。
这个矩形定义了此系统的范围，此矩形内的所有内容都在银行这个应用中发生。
Actors
通常使用一个火柴人来表示参与者。
Actor将是系统实现目标的某人、某物甚至外系统。
在银行App中常见的参与者有顾客和银行本身。那么顾客和银行有什么区别呢？谁是主要的使用者，谁是被动接受者呢？
在系统中 Primary Actors是 Initiates the use of the system，而 Secondary Actors 是 Reactionary。比如此例中顾客是主要参与者，银行是次要参与者。顾客开始提出存款、取款、查询等要求，银行被动给予回应。
一般将主要参与者放置在左侧，次要参与者放置在右侧。
Use Cases
用况是真正开始需求建模的地方。一般用一个椭圆形代表一个用况，表示要做的一件工作。
那么银行App能做些什么呢？这里将功能进行简化。
- 允许客户登录，检查账户余额，转账，存款，按发票付款。
每个用况的开头都是动词。如果想对系统中的用例进行更为详细的描述，比如此用况已经发生，那么对于分析来说十分混乱，所以最好按逻辑顺序排列用况。如上所述，log in是其他所有用况的起点，但是在描述其他用况的时候不会再提及登录操作，并且将log in放在最前面，因为这事顾客使用App时需要做的第一件事。。
Relationships
最后一个要素是关系。参与者使用系统来实现需求，因此每个参与者必须与系统中至少一个用况进行交互。在上述示例中，顾客登录到银行应用程序，因此在顾客和log in用况之间用直线相连——关联关系。
除去关联关系外还有包含关系、延伸关系和泛化关系。
在顾客输入他们的登录信息时，银行应用会验证密码，如果密码不正确，银行将向应用程序发送一条错误信息。
所以我们需要再加上两个用例，检查密码正确性和发送密码错误信息。
档顾客想要转账时，银行首先需要验证账号里的钱是否充足，因此需要再加上一个用例。
那么密码验证用况和整个图表的其他部分有什么关系呢？我们的参与者都没有直接发起这项动作，但是每次进行登录操作时它的确会运行。所以这就是一个包含关系，意思是每当执行主要用况时，也会执行包含的用况。一般使用指向包含用况的虚线箭头表示这种包含关系。
另一种重要的关系时延伸关系。延伸包含两方，基本用况和延伸用况。当执行基本用况时，有时会发生用况延伸，有时不会，仅当满足特定条件才会使用延伸用况。比如上述用况中的展示密码错误用况。延伸关系使用一条指向基本用况的带箭头的虚线表示。
延伸与包含的关系也可以简单描述为包含关系的两个用况一定同时运行，延伸关系的两个用况不一定同时运行。
值得一提的是，多个基本用况可以包含相同的扩展用况。如转账和支付都需要检查账号的钱够不够。
Use Cases的好处
- 用例图是一种功能需求文档编辑技术，它将功能作为一个黑盒子引出，其中包含所有具有访问权限或角色的用户
- 以一种简单且非技术性的方式呈现，易于所有技术和业务用户理解
- 将客户和所有其他用户带到了同一个界面上，使交流变得容易
- 将一个大型复杂项目表示为一组小型功能
- 从最终用户的角度呈现，便于开发人员理解业务目的
- 参与者和其他外部应用程序之间的关联使系统健康验证所需的验证和检查更加清晰
- 用例驱动的项目开发和跟踪方法有助于从功能准备的角度评估项目的进度。关键开发活动状态使项目负责人能够从客户可交付成果的角度展示准备情况
- 项目开发可根据关键的可交付功能进行优先排序，以便于更好地控制和管理项目收入
Multiplicity Of Use Case And Actor
用例可以和多个参与者关联，这叫做用况的多重性。如下图的例子，查看课程可以和两个参与者关联——“新用户”和“注册用户”
Multiplicity Of Actor
- 参与者的多重性是一个由数字表示的关联，可以是0到任何数字
- 多重性为零——代表用况可能没有参与者
- 当通过现金支付处理课程支付用例时，将不需要银行支付服务。因此，参与者“银行支付服务”的多重性可以为零
- 要查看课程时，必须有一名参与者“新用户”，因此此关联的多重性为一
多重性为一——代表用况必须有一个参与者
多重性大于一——意味着用况实例中可能涉及多个参与者。多个参与者可以同时关联，也可以在不同的时间点或顺序关联
- 参与者超过一个的情况是罕见的。考虑一个马拉松竞赛游戏的用例图，其中多个玩家在给定的比赛实例中同时运行。（这里的描述是转载自<网络链接>。虽然参与者实例不止一个，但是多个玩家都是一类，都是参赛者，所以此处的多重性的分离究竟意义多大呢）
- 考虑一个象棋游戏的用况。在国际象棋比赛中，两名棋手将按顺序关联，因为每个棋手采取的步骤不是平行的，而是顺序的。
- 在描述单个接力赛团队活动的用例图中，多个玩家将在不同的时间点关联。在一次比赛中，一个队的所有队员在不同的时间点都处于活动的状态。（如果以一个队为单位呢，参与者是一个队呢？）
绘制用例图之前的准备
- 将项目分解为多个小功能
- 了解大型复杂项目，将其分解为多个功能，并开始记录每个功能的细节
- 确定目标并确定优先顺序
开始列出每个功能，并确定该功能要实现的目标
根据业务可交付成果计划对已识别的功能进行优先顺序
- 功能范围
了解功能的范围并绘制系统边界
识别所有需要称为系统一部分以实现目标的用况
列出在系统中具有角色的所有参与者（用户和服务）。
- 确定关联和关系
- 明确用况和参与者之间的关系和相互依赖性
- 确定包含用况和延伸用况
- 列出所有带有延伸的用况/包含的用况
识别用况/参与者多样性
命名用况和参与者
遵循命名用况和参与者的标准
在文档的特定部分总结用况的功能的简要细节以及可以访问用况的参与者
- 重要注意事项
- 使用注释强调要点
- 回顾检查
- 开始绘制用例之前，检查并验证文档
实例
项目名称：在线培训网站
- 项目中的参与者列表
- 项目中的用况列表
- 系统列表
- 绘制用况图：分步指南
第一步：
- 绘制系统边界并命名系统
第二步：
- 通过参考“List of System”部分中的“Allowed Actor”绘制参与者，并根据项目标准对其命名
- 参与者“New-User”、“Registered-User”和“Employee-Cashier”是系统的主要参与者
- 另外两个支持服务参与者，即“Bank-Payment-Service”（银行支付服务）和“User-Authentication-Service”（用户认证服务）是支持参与者
第三步：
通过参考“List of System”中的“Use Case names”，在系统范围内绘制用例
第四步：
通过参考文档中的“List of Use Cases”部分，为范围内用况添加包含和延伸用况。“Join-a- Course”包含“Course-payment”和“View-Courses”。
用“Register-help”和“Location-Search-help”帮助描述“Register-User”
如图所示，添加note功能以提供详细信息
第五步：
在参与者和用况之间建立联系。文档中的“List of Use Cases”中的“Allowed Actors/Multiplicity number of Actor”给出了所有参与者和用况之间的关联。
用况允许某些参与者在系统中没有任何的职责，比如说讲师，他们可以访问用况“查看课程”，但是当前描述的系统中没有任何职责。
