在软件和系统工程中，用例是一种对系统如何反应外界请求的描述，通常通过用户的使用场景来获取需求。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。
关系：每个用例提供了一个或多个场景。其中场景是指使用场景，用来说明系统可以做什么，系统是如何和用户或其他系统交互的，从而获得一个明确的业务目标。
主场景：也被称为 happy path，每一个用例中都包含一个主场景，主场景对应于系统主要的交互，通常是成功的场景，是最常用的直接地实现用户目标的场景。
复杂的业务本身业务流程就很复杂繁琐，而且涉及到的场景非常多，场景与场景之间也有各种各样的关联，编制完整用例需要建模相关知识和熟悉各个业务流程，还要注意用户交互的细节和相对于的支撑。
用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图，也是外部用户所能观察到的系统功能的模型图。
参与者（Actor）： 表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或外部系统。
用例（Use Case）： 表示的是对系统提供的功能、服务的一种描述。
包含关系（Include）： 表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。
泛化关系（Generalization）： 泛化指的是一个父用例可以被特定化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
关联关系（Association）： 表示的是参与者与用例之间的关系。
扩展/延伸关系（Extend）： 表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。
对语境建模：
识别系统外部的参与者。将类似参与者组织成泛化的结构层次。在需要加深理解的地方，为每个参与者提供一个构造型。将参与者放入到用例图中，并说明参与者与用例之间的通信路径。对需求建模：
识别系统的外部参与者来建立系统的语境考虑每一个参与者期望的行为或需要系统提供的行为。把这些公共的行为命名为用例。确定提供者用例和扩展用例。对这些用例，参与者和它们之间的关系建模。用注释修饰用例用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用。
选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求： 请使用用户的视角，描述用户目标或系统提供的服务 粒度达到子用例级别，并用 include 和 exclude 关联它们 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例 尽可能识别外部系统和服务
因为相似的系统业务相似，为了使降低用户的学习成本会使用相似的交互方式。
充分发挥LBS的优势，通过人工智能对用户数据进行分析，再定点投放。
在用例图中对创新用例使用某种颜色进行高亮标记。
