利用用例图描述用户需求
利用用例图描述用户需求
（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所示，顾客共享用户的属性。
软件需求分析(案例)
案例one：教学管理系统（用例驱动的交互式需求获取）以一个教学管理系统JXGL的分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。
高等学校的教学管理内容十分丰富，工作繁多。
作为一个示例，规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。
教学管理系统JXGL的用户是学校的学生、教师和教学管理员。
学生使用JXG系统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。
学生还可以使用JXGL系统查询自己的课程成绩。
教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。
教学管理员使用JXGL系统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。
1.需求描述:对教学管理系统JXGL要求提供两个方面的服务:(1)选课管理，负责新学期的课程选课注册工作;(2)成绩管理，负责学生成绩管理。
在选课管理方面应填写的用户需求描述如下。
(1)录入与生成新学期课程表教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参考选择。
若某课程的实际选课学生少于10人，则停开该课程，把该课程从课程目录表中删除;若某课程的选课学生多于30人，则停止选课。
(2)学生选课注册新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请。
每个学生选课不超过4门课程。
每门课程最多允许30名学生选课注册。
学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。
在选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门和授课教师。
(3)查询可以查询课程信息、学生选课信息和学生、教师信息。
学生、教师、教学管理员可以查询课程表，获得课程信息。
查询的关键词以是:课程名，授课教师名，学分。
教师、教学管理员可以查询学生选课情况。
查询的关键词可以是:学生名、程名，授课教师名，学分。
学生只允许查询自己的选课信息，不允许查询别人选课信息。
UML用例图介绍
UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用？ (1)3、UML用例图的目的 (2)4、如何画用例图？ (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。
用例图展示了一个外部用户能够观察到的系统功能模型图。
用例图由主角，用例和它们之间的关系组成。
2、用例图怎么使用？要了解一个系统的动态，我们需要使用不同类型的图表。
用例图就是其中之一，其具体目的是收集系统的的需求和参与者。
用例图指定系统的事件和他们的流向。
但从未用例图描述了他们是如何实现的。
可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。
在这些图中使用的设计在一个非常高的水平。
那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。
一个结构良好的用例，还介绍了前置条件，后置条件和例外。
而这些多余的元素在执行测试时被用来制造测试的情况下。
用例都不是正向和反向工程，但他们仍然使用略有不同的方式。
同样是真实的逆向工程。
仍用例图的使用方式不同，使其逆向工程的一个候选。
在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。
所以下面的地方使用用例图：2.1.需求分析和高水平的设计。
2.2.模拟系统的上下文。
2.3.逆向工程。
2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。
用例图是用来收集系统的要求，包括内部和外部的影响。
这些要求大多是设计要求。
所以，分析一个系统时要收集其功能用例和确定参与者。
简单来说，用例图的目的如下：3.1.用例图用来收集系统的要求。
3.2.用例图用于获取系统的外观图。
3.3.用例图识别外部和内部因素影响系统。
3.4.用例图显示要求之间的相互作用是参与者。
4、如何画用例图？用例图被认为是高层次的需求分析系统。
因此，当系统的要求，分析被捕获在用例的功能。
面向对象需求分析——用例图和活动图
面向对象需求分析——用例图和活动图面向对象软件开发的方法有：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
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
用例图描述
1． 学生在用户名输入框里输入用户名 2． 在密码框里输入密码 3． 用户按登录后，系统验证学生输入的有效性。 4． 有效则进入系统的主界面。无效则提示相应错误给用户。 5． 用例终止
异常事件流：
显示错误信息，提示无效身份登录，认证无法通过登陆失败。
分支流程：
在按“登录”按钮之前 ，学生可以随按“关闭”按钮。
前置条件：
1.学生进入到聊天界面。
2.用户必须联网方能使用。
后置条件：
1.聊天信息必须显示，所有成员都能看到。
2.聊天记录可清空。
正常流程：
1.打开群聊天窗口界面。
2.输入信息，点击发送。
3.群中所有成员发送信息都显示在群聊天窗口上。
分支流程：
1.若想进行私聊，一对一聊天
1.点击你想要聊天的好友，打开聊天窗口。
3.显示“签到成功”信息。
特殊需求：
学生一次只允许签到一个用户。
发送文件
ID：
3
用例名称：
发送文件
参与者：
学生
用例描述：
产生的原因：学生需要将所完成的功课提交老师批阅。
大概过程：学生完成作业后，按“提交按钮”发送给老师。
输出结果：系统提示文件送达成功或者失败。
前置条件：
学生必须提供上传信息资源请求。
输出结果：在系统的登陆界面区域确定身份后，登录界面转换登录成功。
前置条件：
系统已启动到登录界面，教师在进行其余操作之前必要完成的步骤。
后置条件：
用户登录成功后系统显示信息查看的结果界面，用户登录成功后，进入到教师相应界面。
正常流程：
1． 教师在用户名输入框里输入用户名 2． 在密码框里输入密码 3． 用户按登录后，系统验证学生输入的有效性。 4． 有效则进入系统的主界面。无效则提示相应错误给用户。 5． 用例终止
uml各种图例及说明
uml各种图例及说明1、用例图描述角色以及角色与用例之间的连接关系。
说明的是谁要使用系统，以及他们使用该系统可以做些什么。
一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
2、类图类图是描述系统中的类，以及各个类之间的关系的静态视图。
能够让我们在正确编写代码以前对系统有一个全面的认识。
类图是一种模型类型，确切的说，是一种静态模型类型。
3、对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。
它描述的不是类之间的关系，而是对象之间的关系。
4、活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
5、状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。
可以捕获对象、子系统和系统的生命周期。
他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。
状态图是对类图的补充。
6、序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。
顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
7、协作图和序列图相似，显示对象间的动态合作关系。
可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。
如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
8、构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。
第4章 用例图
Home
4.2.3 活动者的确定
例： 教学管理系统中可能的用户： 教学管理人员、教师、学生、系统管理人员等。
4.3 Use Case
4.3.1 4.3.2 4.3.3
Home
Use Case概念 业务Use Case与系统Use Case Use Case图
4.3.1 Use Case概念
Use Case是对系统的用户需求（主要是功能需求）的描述， Use Case表达了系统的功能和所提供的服务。 Use Case描述活动者与系统交互中的对话。它可以用一系 列的步骤来描述，这些步骤构成一个“剧本”（Scenario）。 “剧本”的集合就是Use Case。全部的Use Case构成了对于 系统外部是可见的行为的描述。 Use Case只描述活动者和系统在交互过程中做些什么，并 不描述怎样做。 一个活动者可以运行多个Use Case，而一个Use Case可以有 多个活动者运行它。但是，也有的Use Case很难有与它明确 关联的活动者。
4.1 概述
所谓Use Case是指系统的外部事物（活动者）与系统的交互， 它表达了系统的功能，即系统所提供的服务。 具体地说，Use Case是关于系统的一组动作的说明 （Specification），这些动作对一个或多个活动者给出所需 要的结果（值）。 Use Case用于为待开发的系统建立功能需求模型。 Use Case图是Use Case模型的图形表示，能准确地表达活动 者与系统的交互情况和系统所提供的服务。 Use Case图是后续的系统分析与设计工作的依据，也是系 统测试的依据。 Use Case图对需求的描述规范化，较好地避免了表达的歧 义性，便于用户和开发人员理解系统的需求，取得共识。 Rational统一过程主张采用Use Case驱动的软件开发方式。
- 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框图和使用文档来确定系 统的高层视图