于一般的直接以文字来进行需求表达的方式，用例是从用户的角度，把整个系统 看做黑盒子，通过描述在完成功能过程中用户与系统的交互来刻画需求的手段。 用例是一系列动作和事件的列表，它定义了单个外部参与者(Actor)与系 统之间的交互，通过这种交互，系统提供了可见的价值。 为了理解用例，我们需要区别以下概念： 1)参与者：是位于系统外部、与系统具有交互的事物，可以是人，计算机系统 或组织，例如教室管理员。需要注意的是参与者不是某一个具体的人、系统或组 织，而是一类人、系统或者组织。在UML中，参与者的符号如下图4.1所示。 Actor 图4.1参与者的UML符号 2)场景(Scenario)：某一特定的参与者和系统之间的一次交互，也称为用例实 例。场景是使用系统的一个特定情节或用例的一条执行路径。在获取需求时，我 们通过列举若干重要的场景来发现用例。通俗地理解，场景就是讲一个有主人公 参加的一段故事，这个故事我们会分为若干步骤来描述。例如我们可以针对教室 预订系统，讲述一个小王如何在网上预订教室的一个故事。 ●场景名称：教室预订 参与者实例：教室申请人员小王，教室管理员小张 ●事件流： 1.小王根据活动需要打算使用教室预订系统预订一间教室。他在已接入互联网 的终端上激活了教室预订系统中的教室预订功能。 2.小王填写一份包含申请人信息、使用时间、使用目的、活动人数、希望安排 的教室规格和位置的表单并提交。然后小王等待系统的教室预订答复信息。 3. 教室管理员小张受到系统提醒后，收到了小王的申请表。小张根据目前的教 室预订情况以及小王的申请信息安排相应的教室并确认。 小王通过预留在系统中的电子邮件收到了来自教室预订系统的确认信息，教 室预订成功。于一般的直接以文字来进行需求表达的方式，用例是从用户的角度，把整个系统 看做黑盒子，通过描述在完成功能过程中用户与系统的交互来刻画需求的手段。 用例是一系列动作和事件的列表，它定义了单个外部参与者（Actor）与系 统之间的交互，通过这种交互，系统提供了可见的价值。 为了理解用例，我们需要区别以下概念： 1）参与者：是位于系统外部、与系统具有交互的事物，可以是人，计算机系统 或组织，例如教室管理员。需要注意的是参与者不是某一个具体的人、系统或组 织，而是一类人、系统或者组织。在 UML 中，参与者的符号如下图 4.1 所示。 图 4.1 参与者的 UML 符号 2）场景（Scenario）: 某一特定的参与者和系统之间的一次交互，也称为用例实 例。场景是使用系统的一个特定情节或用例的一条执行路径。在获取需求时，我 们通过列举若干重要的场景来发现用例。通俗地理解，场景就是讲一个有主人公 参加的一段故事，这个故事我们会分为若干步骤来描述。例如我们可以针对教室 预订系统，讲述一个小王如何在网上预订教室的一个故事。  场景名称：教室预订  参与者实例：教室申请人员小王，教室管理员小张  事件流： 1. 小王根据活动需要打算使用教室预订系统预订一间教室。他在已接入互联网 的终端上激活了教室预订系统中的教室预订功能。 2. 小王填写一份包含申请人信息、使用时间、使用目的、活动人数、希望安排 的教室规格和位置的表单并提交。然后小王等待系统的教室预订答复信息。 3. 教室管理员小张受到系统提醒后，收到了小王的申请表。小张根据目前的教 室预订情况以及小王的申请信息安排相应的教室并确认。 4. 小王通过预留在系统中的电子邮件收到了来自教室预订系统的确认信息，教 室预订成功