利用用例图描述用户需求
利用用例图描述用户需求
（4）用例的命名
每个用例应有唯一的名称 命名的方式：用例通常用动词 + 名词短语来命名---如：登录系统
请见文档中的说明 书写用例的模板格式
四、UML中的用例图
1、用例图 （1）什么是用例图
提供用例图的目的之 一是下面的描述
用例图是一种图形化的工具，它用简单的图形元素表示出 系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和 包含
（1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 系统层用例图：描述系统提供的全部主要的功能或服务。 子系统层用例图：描述某一子系统所应该提供的服务，它 的外部交互者可以是其他的子系统或高一层的参与者。 对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。
（3）用例图的组成元素
在一个用例图中，一般主要 包含有 系统边界 参与者 用例和用例关系 （泛化、使用和扩展等 三种形式）。
这在前面已经 加以说明过
2、用例图的主要作用 （1）面向用户
可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者； 也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者 表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统，则反映了系统能够完成什么 样的功能
产品需求文档的写作(五) – 用例文档(UML用例图、流程图)
产品需求文档的写作(五) –用例文档(UML用例图、流程图)在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。
在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。
用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。
用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。
用例文档中有两个关联文件，分别是用例图和流程图。
用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。
流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。
写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。
一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。
用例文档的大概组成部分如下：1、修改记录：每次修改的备注记录，同PRD文档。
2、角色介绍：描述参与系统中的各个角色3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。
用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。
1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。
系统软件需求和需求分析说明书模板(用例图+界面+文档)
1系统需求和需求分析说明书模板Mohit系统需求和需求分析说明书模板第一部分概述1．项目名称及背景➢项目名称➢开发背景2．文档说明第二部分任务说明1．功能概述2．用户环境浏览器(如IE 6以上版本)+网络开发(生产)环境:第三部分需求分析1．实现功能➢系统用例图用户业务逻辑如下图所示：95➢管理员功能清单功能编号功能名称文中标题编号备注101 人事管理101001 机构管理101002 部门管理101003 员工管理➢普通用户功能清单2．用例说明➢ [用例1] ●用例图●描述●参与者➢[用例2] ●用例图●描述●参与者➢[用例3] ●用例图●描述●参与者➢[用例4] ●用例图●描述●参与者➢[用例5] ●用例图●描述●参与者➢[用例6 ●用例图●描述●参与者➢[用例7] ●用例图●描述●参与者➢ [用例8]●用例图●描述●参与者➢ [用例9]●描述文件搜索功能：可以按条件查询需要的文件。
●参与者//*参与者，参与用例的对象*// ➢[用例10]●用例图发送消息消息管理管理消息●描述消息管理主要包括：创建消息、修改消息、删除消息、发布消息。
●参与者//*参与者，参与用例的对象*// ➢[用例11]●用例图●描述●参与者➢[用例12] ●用例图●描述●参与者➢[用例13] ●用例图●描述●参与者➢[用例14]●用例图●描述●参与者3．用例关系附1.2 系统设计说明书模板系统设计说明书版本历史第一部分概述1．文档说明2．系统需求概述第二部分系统总体结构第三部分系统设计类图//*系统中主要的、关键实体类图，参考图如下*//➢[用例1]实现●时序图//用例1的时序图，参考图如下*//●描述界面设计1．公共模块界面设计说明：页面设计要求尽量使用div布局完成。
所有的GridView要求实现分页功能。
图1.1用户登陆首页用户登陆首页要求：只有当用户名、密码都正确时才能通过验证。
107图1.2 管理员登录后看到的主界面管理员登录后的主页面要求：显示个人便签信息，左侧显示系统菜单和个人基本信息，上标栏有“主页”、“重新登录”、“修改密码”、显示当前时间功能。
需求的用例描述
了解系统所依赖的其他系统、数据源和外部实体，以 及任何限制或约束。
编写需求用例
编写清晰、简洁的用例描述
使用简练的语言描述用例，包括前置条件、后置条件、操作流程 和结果等。
确定用例的优先级
根据业务重要性和紧急程度，为用例分配优先级，以便合理安排开 发进度。
编写验收准则
为每个用例编写明确的验收准则，以便于测试和验证。
需求的用例描述
• 引言 • 需求用例描述基础 • 需求用例的识别和编写 • 用例描述的详细内容 • 用例描述的常见问题 • 用例描述的实践建议
景
简述主题的背景信息，包括相关 领域的发展状况、市场需求等。
主题意义
阐述主题的重要性和意义，说明 为什么这个主题值得研究。
目的和目标
准确的，有助于团队成员更好地理解和实施需求。
用例的属性
用例的属性包括用例的标识符、名称、 描述、优先级、状态等。
标识符是唯一标识一个用例的编号或名称， 用于在文档和项目管理工具中追踪和引用。
名称是用例的简短描述，用于标识用 例的主要功能或目标。
描述是对用例的详细说明，包括参与者和 用例之间的交互以及用例的行为和条件。
优先级用于确定用例的开发顺序，高优先级的 用例通常先于低优先级的用例进行开发和实现。
状态表示用例的开发阶段，如草稿、 开发中、已完成等。
03
需求用例的识别和编写
识别需求用例
识别主要业务场景
从业务需求中识别出主要业务场景，包括业务流程、 角色和操作等。
识别非功能性需求
分析系统应具备的性能、安全、可用性等非功能性需 求。
目的
明确提出研究的目的，即希望解决什么问题或满足什么需求 。
目标
用例图
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
UML用例图的主要元素解析与使用方法
UML用例图的主要元素解析与使用方法UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，用例图是UML的一种图表类型，用于描述系统的功能需求和用户与系统之间的交互。
在软件开发过程中，用例图是非常重要的工具，它能够帮助开发团队更好地理解系统需求，设计出更合理的系统架构。
本文将对UML用例图的主要元素进行解析，并介绍其使用方法。
一、参与者（Actors）参与者是指与系统进行交互的实体，可以是人、其他系统或外部设备。
在用例图中，参与者用一个小人的图标表示。
参与者与系统之间通过用例进行交互。
一个参与者可以在多个用例中出现，也可以在一个用例中有多个参与者。
二、用例（Use Cases）用例是对系统功能的描述，它表示系统为参与者提供的一项功能或服务。
用例图中，用例用一个椭圆形图标表示。
每个用例都有一个名称，通常使用动词短语来描述功能。
用例之间可以有关系，如包含关系（include）、扩展关系（extend）等。
三、关系（Relationships）在用例图中，参与者与用例之间可以有不同类型的关系，如关联关系（association）、包含关系（include）、扩展关系（extend）等。
关联关系表示参与者与用例之间的关联，包含关系表示一个用例包含另一个用例，扩展关系表示一个用例可以扩展另一个用例。
四、系统边界（System Boundary）系统边界是用于表示系统的边界，用一个矩形框表示。
在用例图中，系统边界将参与者和用例包围在内，表示系统的范围和边界。
五、泛化（Generalization）泛化是一种继承关系，用于表示两个用例之间的继承关系。
在用例图中，泛化关系用一个带有箭头的实线表示，箭头指向父用例。
六、扩展点（Extension Points）扩展点用于表示一个用例可以被扩展的地方。
在用例图中，扩展点用一个小圆圈表示，并与扩展用例之间用虚线连接。
使用UML用例图进行系统建模时，需要按照以下步骤进行：1. 确定参与者：首先，需要确定系统中的参与者，包括用户、其他系统或外部设备。
需求中如何画用例图
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
如何应用UML用例图描述软件系统的用户需求(第3部分)
1.1如何应用UML用例图描述软件系统的用户需求（第3/3部分）1.1.1UML用例的事件流1、用例所涉及的主要事件（1）用例的事件流用例的事件流是对完成用例行为所需的事件的描述。
事件流描述了一个用例的行为实现的主要过程。
（2）作用可以通过一个清晰的，易被用户理解的时间流来说明一个用例的行为。
（3）用例的事件流建模的基本要求在事件流中包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流。
（4）为什么要应用用例的事件流建模对用例进一步细化，同时也为后面的动态建模提供基础。
2、一个用例的事件流的组成（1）所应该包含的内容----可以参考提供的格式模板（2）主要的内容1)简要说明：描述该使用案例的作用（可以不写出）；2)前置条件：开始使用该用例之前必须满足的系统和环境的状态和条件（必要条件而不是充分条件）3)主事件流：用例的正常流程（事件流是关注系统干什么，而不是怎么干），也称为用例的路径。
4)其它（备选）事件流：用例的非正常流程，如错误流程5)后置条件：用例成功结束后系统应该具备的状态和条件（但不是每个用例都有后置条件）（3）主事件流（用例的路径）事件流中可能包含有基本路径、备选路径、异常路径、成功路径和失败路径等几个方面的内容。
但首先要写基本路径，因为它是客户最想看到和最关心的东西。
3、描述用例的事件流的主要方式●结构化语言（用例事件流）每个用例只描述没有大的分支的行为的单个线索，在事件流中要对事件流进行结构化说明（主事件流和备选事件流）。
利用用例事件流，可以很细腻的表达一些用例的过程，但是，当用例的事件流比较复杂的时候，单纯用文字表达难以清楚的表示相互之间的关系，特别是一些并发关系，这时，可以借用活动图来表示。
●UML中的顺序图作为交互图中的一种，顺序图显示了参与交互作用的参与者或对象，以及它们生成的按时间排序的事件。
通常，顺序图显示特定用例实例产生的事件并且侧重描述消息在对象之间如何传送。
软件工程实验——软件需求分析
（4）提高了解决问题的能力：在实验过程中，我遇到了一些问题和困难，通过思考和探索，我学会了如何解决这些问题。通过不断解决问题和总结经验，我提高了自己的解决问题的能力。
注意事项：
（1）调研和需求分析是关键。在实验初期，需要深入相关单位进行调研，了解计算机销售业务的流程和需求，与用户进行交流，了解用户对系统的期望和需求。同时，需要收集并整理相关的资料，对需进行进一步的分析和整理。
（2）数据流图和数据字典是进行需求分析的重要工具。在绘制数据流图时，需要分清系统的边界和内部结构，将系统划分为多个子系统或模块。在定义数据字典时，需要对每个条目进行详细的描述和定义，确保数据的准确性和完整性。
（3）细心、耐心和责任心是必备的素质：软件需求分析是一项复杂而繁琐的工作，需要细心、耐心和责任心。在绘制数据流图、定义数据字典、绘制类图和描述用例时，需要仔细思考和分析，不能出现错误或遗漏。同时还需要对工作负责到底，及时解决问题和总结经验。
（4）良好的沟通和协作能力是成功的保障：软件需求分析是一项团队合作的工作，需要与团队成员和其他相关人员密切合作和沟通。良好的沟通和协作能力能够提高工作效率和质量，同时也能避免出现偏差和错误。在沟通过程中要清晰明确地表达自己的想法和建议，同时也要尊重他人的意见和建议。
（2）数据流图和数据字典定义不够准确。数据流图和数据字典是进行需求分析的重要工具，如果定义不够准确，可能会影响后续的系统设计和开发。因此，在定义数据流图和数据字典时，需要仔细考虑每个条目的准确性和完整性，确保数据的准确性和完整性。
（3）软件需求规格说明（SRS）撰写不够规范。SRS是实验的最后一步，如果撰写不够规范，可能会影响其他人对系统的理解。因此，在撰写SRS时，需要遵循一定的规范和标准，确保SRS的清晰度和可读性。
用例图
顾客顾客用户2.1 用例建模技术2.1.1 参与者和用例参与者（actor ）是系统外部与系统有交互的任何事物，是为了完成一个事件而与系统交互的外部实体。
参与者主要用于描述系统的边界。
例如，向银行提交贷款申请的顾客；通过因特网访问预订系统查询座位情况的旅行社，等等。
在UML 中，参与者经常用人形符号表示，或者用类的构造型《actor 》表示，如图2-3所示。
图2-3 参与者的UML 表示符号参与者并不一定是系统的用户。
它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。
图2-4展示参与者是外部系统的例子。
图2-4参与者是外部系统的例子当参与者是人时，它是指一个与系统有交互的用户所扮演的角色。
一个参与者并不是指一个特定的人或一个特定的实体。
例如，参与者“顾客”是对顾客的概念建模，而不是对张三这个特定的顾客建模。
一个用例并不仅局限于一个参与者; 参与某用例的参与者可能是多个。
然而，一个用例况必须向至少一个参与者提供可度量的价值。
参与某用例的多个参与者各有不同的角色和职责：一些负责接收用例提供的价值，一些则负责向用例提供服务，其它则负责触发或初始化用例。
Ivar Jacobson[1992]将参与者划为两类：主要的和次要的。
主要参与者(primary actor)是从系统获得可度量价值的用户。
主要参与者的需求驱动了用例所表示的行为或功能。
如果他们的需求或角色发生了变化，那么系统将必须有重大的修改。
次要参与者(secondary actor)在用例中提供服务，并且不能脱离主要参与者而存在。
在图2-4所示的例子中，顾客是主要参与者，而客户关系系统则是次要参与者。
顾客<<Actor>>顾客 客户关系管理系统 （已有） 网上商店系统（要开发） 问卷调查系统 （已有）图2-5 抽象参与者的例子一些参与者只扮演概念上的角色，而另一些则更具体。
如图2-5所示，顾客共享用户的属性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
那我们怎么描述？--形式和内容是什么 形式和内容是什么！ （2）那我们怎么描述？--形式和内容是什么！
因为我们在系统开发时必须要了解并准确描述用户的各 个方面的需求，这包括功能、 个方面的需求，这包括功能、非功能以及环境的约束等方面 需求。同时， 需求。同时，我们所采用的方法能否避免常规的方法所带来 的问题？ 的问题？
（1）用例及其定义—某种特定的功能 用例及其定义 某种特定的功能
用例的确定只是与 用户交流的目的， 用户交流的目的， 而不是交流的手段
（2）用例的分类 业务用例：如报表数据汇总计算 业务用例：
系统用例： 系统用例：如报表打印
获得用例的手段可以有很 多种---可以是“ ---可以是 多种---可以是“不择手 段”！
请见文档中的说明 书写用例的模板格式
UML中的用例图 四、UML中的用例图
1、用例图 （1）什么是用例图
提供用例图的目的之 一是下面的描述
用例图是一种图形化的工具， 用例图是一种图形化的工具，它用简单的图形元素表示出 系统的参与者、 系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
可以实现从用户角度来描述系统所应该具有的功能， 可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者； 并能够指出各功能的操作者； 也能够显示出与系统进行交互的外部参与者及其使用方式。 也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者 表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统， 同时对已经构造完毕的系统，则反映了系统能够完成什么 样的功能
说法不一，见仁见智！ 说法不一，见仁见智！ 不同项目和面向不同的 用户都不一样！ 用户都不一样！
如何确定系统中的用例-----参考文档说明 （3）如何确定系统中的用例---参考文档说明
识别用例有一个简单的判断方法：用户（活动者） 识别用例有一个简单的判断方法：用户（活动者）通过 系统实现×××目的。 ×××目的 系统实现×××目的。 一个系统中的用例的种类大致如下： 一个系统中的用例的种类大致如下：系统的开始和停止的 用例、系统维护的用例、维护系统中存储的数据的用例、 用例、系统维护的用例、维护系统中存储的数据的用例、修 改系统行为的功能的用例和系统中代表业务功能的用例。 改系统行为的功能的用例和系统中代表业务功能的用例。
提供用例图的目的之二是帮助开发团队理解 客户对系统的各种功能需求。 客户对系统的各种功能需求。
本讲的简要回顾
1、子曰：“学而不思则罔，思而不学则殆。” 子曰： 学而不思则罔，思而不学则殆。 学而时习之” “学而时习之” 2、子曰：“知之者不如好之者,好之者不如乐之者” 子曰： 知之者不如好之者,好之者不如乐之者”
用例的纵向方面的关系---------泛化关联 （2）用例的纵向方面的关系-----泛化关联
泛化关联代表一般与特殊的关系， 泛化关联代表一般与特殊的关系，它充分体现了面向对象 的继承性 根据继承关系：子类具有父类的所有属性， 根据继承关系：子类具有父类的所有属性，还可以拥有自 己的属性特点及行为---因此， ---因此 己的属性特点及行为---因此，父子用例也应该具有这些 特性。 特性。
因此，参与者不 因此， 完全都是“ 完全都是“人”
（3）某项目中的各个参与者示例说明
（4）参与者之间的主要关系---泛化关系 参与者之间的主要关系---泛化关系 --特化或者继 承
（5）所要注意的问题
（6）如何获得系统中的参与者
用例模型中的用例（UseCase） 4、用例模型中的用例（UseCase）
子曰： 三人行,必有我师焉” 3、子曰：“三人行,必有我师焉” 子曰： 我非生而知之者,好古,敏以求之者也” 4、子曰：“我非生而知之者,好古,敏以求之者也”
UML中的用例之间的关系 二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和 包含
用例的层次化（纵向方面） （1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层） 按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 统层（可以再细分）和对象类层（最低层） 系统层用例图：描述系统提供的全部主要的功能或服务。 系统层用例图：描述系统提供的全部主要的功能或服务。 子系统层用例图：描述某一子系统所应该提供的服务， 子系统层用例图：描述某一子系统所应该提供的服务，它 的外部交互者可以是其他的子系统或高一层的参与者。 的外部交互者可以是其他的子系统或高一层的参与者。 对象类层的用例图描述对象类提供的功能片或操作， 对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。 外部交互者可以是其他对象类或高一层活动者。
一般是采用自然语言（如中文）来描述对系统的需求， 一般是采用自然语言（如中文）来描述对系统的需求，这 样的方法有几个致命的缺陷。 样的方法有几个致命的缺陷。 缺乏描述的形式化，随意性较大， 缺乏描述的形式化，随意性较大，常常产生理解上的含混 及不确定性-------自然语言的描述容易产生歧义 及不确定性----自然语言的描述容易产生歧义 ； 没有统一的格式，不能自动化地验证 ； 没有统一的格式， 不能保证文档与程序同步。 不能保证文档与程序同步。
参与者和用例之间的使用关系， 参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
（3）用例图的组成元素
在一个用例图中， 在一个用例图中，一般主要 包含有 系统边界 参与者 用例和用例关系 泛化、 （泛化、使用和扩展等 三种形式）。 三种形式）。
这在前面已经 加以说明过
2、用例图的主要作用 （1）面向用户
在Rose中的 Rose中的 实现状态 在Visio中 Visio中 的实现状态
（4）用例的横向方面的联 系---扩展关联
基本的用例必须声明若干新 的规则-----扩展点 的规则---扩展点 扩展用例只能在这些扩展点 上增加新的行为并且基本用 例不需要了解扩展用例的实 其一侧重于问题的特殊性， 其一侧重于问题的特殊性，而另一种则侧重 现细节
网上银行 系统中的 用例关系
人员管理 系统中的 用例关系
用例的横向方面的联系-----包含关联 （3）用例的横向方面的联系---包含关联
包含关联指一个基本用 例的行为包含了另一个 用例的行为 这种包含关联是一种依 赖关系， 赖关系，被包含的用例 不能独立存在， 不能独立存在，只能作 为包含它的用例的一部 分
用例建模方法最主要的优点-------在于它是用户导向的 3、用例建模方法最主要的优点----在于它是用户导向的
（1）用户可以根据自己所对应的用例来不断细化自己的需求。 用户可以根据自己所对应的用例来不断细化自己的需求。 此外，使用用例还可以方便地得到系统功能的测试用例。 （2）此外，使用用例还可以方便地得到系统功能的测试用例。
（4）用例的命名
每个用例应有唯一的名称 命名的方式： 名词短语来命名---命名的方式：用例通常用动词 + 名词短语来命名---如：登录系统
命名用例一般要 用动词开头 ！
用例的UML UML图示 （5）用例的UML图示
5、用例模型中的系统
（1）什么是系统 系统代表的是一部机器设备或者是一个商务活动等， 系统代表的是一部机器设备或者是一个商务活动等，而并 不是所要实现的最终软件系统； 不是所要实现的最终软件系统； 系统的边界用来说明构建的用例模型的应用范围（ 系统的边界用来说明构建的用例模型的应用范围（用例在 系统之内）。 系统之内）。 工具中没有体现！ 在Rose 工具中没有体现！ （2）表示形式 用例图中的系统采用一个长方形框表示， 用例图中的系统采用一个长方形框表示，系统的名字写在 方框的上面或者方框内
2、用例模型中的基本组成部件 用例（UseCase） （1）用例（UseCase） （2）的参与者
（1）参与者：参与者表示系统用户所扮演的各个角色(role） 参与者：参与者表示系统用户所扮演的各个角色(role） (role
（2）参与者可能有 三大类 系统用户 （使用者或 者操作员） 者操作员） 与所建系统 交互的其他 系统 其它设备
于问题的延续性（ 于问题的延续性（在修改和录入中都有保存的功 但还提供了除保存之外的附加功能）。 能，但还提供了除保存之外的附加功能）。
注意区分扩展关系与前面的泛化关系的不同
三、如何进行用例建模
1、用例建模的主要步骤
2、如何编写用例
3、各种用例示例点评
（1）用例示例点评一：错误用例：提取现金 用例示例点评一：错误用例： （2）用例示例点评二：错误用例：提取现金 用例示例点评二：错误用例： 用例示例点评三：错误用例： （3）用例示例点评三：错误用例：买东西
利用用例图描述用户需求（ 利用用例图描述用户需求（用例建模 ）
在本讲您能了解如下知识点
UML中的用例 UML中的用例 用例之间的关系 用例图的组成部件 UML中的用例图及项目实例 UML中的用例图及项目实例
UML中的用例及用例图 一、UML中的用例及用例图
1、用例及用例建模技术产生的背景概述 UML之前对系统的需求描述方法 （1）UML之前对系统的需求描述方法
我们可以采用UML中的用例模型方法！ UML中的用例模型方法 （3）我们可以采用UML中的用例模型方法！
项目开始时， Case视图的主要使用者是客户 视图的主要使用者是客户、 项目开始时，Use Case视图的主要使用者是客户、分析人 员和项目管理员。 员和项目管理员。 这些人利用使用案例、 Case框图和使用文档来确定系 这些人利用使用案例、Use Case框图和使用文档来确定系 统的高层视图