UML需求建模-用例描述
UML实例UML案例(完整建模)(汽车租赁系统)
建立UML模型框架
▪ 选择J2EE模式
系统的用例图
▪ 创建用例图之前首先需要确定参与者。 ▪ 系统中的参与者主要有两类： ① 客户 ② 公司职员
系统的用例图
▪ 1. 客户参与的用例图 ▪ 2. 公司职员参与的用例图
客户参与的用例图
公司职员参与的用例图
系统的时序图
▪ 1. 管理人员开展工作的时序图 ▪ 2. 客户预订车辆的时序图 ▪ 3. 客户取车的时序图 ▪ 4. 客户还车的时序图
theCommonWorker : CommonWorker
theSkillWorker : SkillWorker
theCar : Car
theServiceRecord : ServiceRecord
theCustomerRecord : CustomerRecord
theRenBiblioteka Record : WorkRecord
4: InServiced( )
3: check( )
8: new CustomerRecord
theCustomerRecord : CustomerRecord
客户取车的协作图
1: show_notice( )
4: take_car( ) : custormer
theRequestOrder : RequestOrder
returnback
check_carstatus( )
fillRecord( )
notify_payment( ) pay()
return
update_carstatus( )
end( ) updateRecord( )
系统的协作图
▪ 1. 客户预订的协作图 ▪ 2. 客户取车的协作图 ▪ 3. 客户还车的协作图
UML用例和用例图
h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足
产品需求文档的写作(五) – 用例文档(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、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。
UML之用例图
UML之⽤例图⽤例图⽤例图是⽤来描述系统功能的技术，表⽰⼀个系统中⽤例与参与者及其关系的图，主要⽤于需求分析阶段。
⽤例图的基本组成元素：参与者、⽤例、元素之间的关系。
⽤例图使⽤范围：需求分析1.捕获需求。
描述功能需求、⾏为需求（系统要完成什么任务）2.分析需求。
明确类和对象，建⽴之间的关系⽤例图的基本概念1、⽤例图是表⽰⼀个系统中⽤例与参与者关系之间的图。
它描述了系统中相关的⽤户和系统对不同⽤户提供的功能和服务。
2、⽤例图相当于从⽤户的视⾓来描述和建模整个系统，分析系统的功能与⾏为。
3、⽤例图中的主要元素包括参与者、⽤例以及元素之间的关系。
此外，⽤例图还可以包括注解和约束，也可以使⽤包将图中的元素组合成模块。
如：参与者的概念1、参与者是与系统主体交互的外部实体的类元，描述了⼀个或⼀组与系统产⽣交互的外部⽤户或外部事物。
2、参与者位于系统边界之外，⽽不是系统的⼀部分。
3、参与者是从现实世界中抽象出来的⼀种形式，却不⼀定确切对应的现实中的某个特定对象。
符号：如何确定参与者？通过对参与者进⾏关注和分析，我们可以把重点放在如何与系统交互这⼀问题上，便于进⼀步确定系统的边界。
另外，参与者也决定了系统需求的完整性。
确定参与者可以从以下⼏个⾓度来考虑：1）为系统提供输⼊的⼈或事物2）接收系统输出的⼈或事物3）需要接⼊的第三⽅系统或设备4）时间是否会触发某些事件5）负责⽀持或维护系统中信息的⼈系统中的参与者⼀般可以分为四类：主要业务参与者：主要从⽤例的执⾏中获得好处的关联⼈员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联⼈员。
外部服务参与者：响应来⾃⽤例的请求的关联⼈员。
外部接收参与者：从⽤例中接收某些价值或输出的⾮主要的关联⼈员。
参与者的泛化关系当系统中的⼏个参与者既扮演⾃⾝的⾓⾊，同时也有更⼀般化的⾓⾊时，可以通过建⽴泛化关系来进⾏描述。
与类相似，⽗参与者可以是抽象的，即不能创建⼀个⽗参与者的直接实例，这就要求属于抽象⽗参与者的外部对象⼀定能够属于其⼦参与者之⼀。
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
如何应用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中的顺序图作为交互图中的一种，顺序图显示了参与交互作用的参与者或对象，以及它们生成的按时间排序的事件。
通常，顺序图显示特定用例实例产生的事件并且侧重描述消息在对象之间如何传送。
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
如何利用UML用例图描述软件系统的需求
如果应用人的自然语言（如中文）描述，则尽量采用 “主语＋动作”的简单表达方式。
（2）那我们怎么描述？--形式和内容应该是什么！ 因为，在系统开发时必须要了解并准确描述系统的各个方
面的需求----这主要包括功能、非功能以及环境的约束等方面 需求。同时，我们所采用的描述方法能否避免常规的方法所带 来的问题？
软件系统需要处理的整个问题空间的范围，因为一个软件 系统不可能处理所有问题，必须得给它定义这个问题空间的 范围。 系统的边界用来说明构建的用例模型的应用范围，而且用 例一定要在系统之内。
（2）表示形式
用例图中的系统采用一个长方形框表示，系统的名字写在 方框的上面或者方框内。
在Rose 工具中没有体现！
如何利用UML用例图描述软件系统的需求 （用例建模 ）
UML（Unified Modeling Language）概述
1、UML是什么及主要的特性 （1）UML是一种标准的图形化建模语言，它是面向对象分 析与设计的一种标准表示。
注意：它不是一种可视化的程序设计语言，而是一种可 视化的建模语言；也不是工具或知识库的规格说明，而是一 种建模语言说明，是一种表示的标准；它也不是过程，也不 是方法，但允许任何一种过程和方法使用它。
（1）参与者 （2）用例（UseCase）（3）系统 （4）用例之 间的关系
4、用例模型中的参与者
（1）参与者：参与者表示系统用户所扮演的各个角色(role）
（2）参与者可能 有三大类型 系统用户 （使用者或 者操作员） 与系统边界 内的用例有 交互的其他 外部系统— —提供服务 其它设备
6、如何确定系统中的用例
识别用例有一个简单的判断方法：用户（活动者）通过 系统实现×××功能目的。
（1）基本方法 从需求清单中找出动词----每个动词初步看成为一个 用例 然后分析这些动词（同时再除掉无关的动词），找出 这些动词之间的关系（也就是用例之间的关系）和发现 出每个用例所对应的参与者 最后在Rose中描述（画）出它们
UML中的用例(Use Case)概念分析及实例
UML中的用例(Use Case)概念分析及实例文/登峰2005-02-25在UML中use case似乎最簡單的，用例建模的最主要功能就是用来表达系统的功能性需求或行为，依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的各种关系，包括泛化，包含，扩展等。
本文准备向大家介绍以下内容,所有图示均用PowerDesigner所画.◆用况◆参与者◆泛化◆<<use>>◆<<include>>◆<<extend>>◆用例描述１．用况（use case）图１用况图是对一组动作序列（其中包括它的变体）的描述，系统执行该动作为执行此动作的参与者产生一个可观察的结果值。
比如你使用计算器，这里可以把计算器看作为用况，参与者是登峰，登峰按了３＋３（用况执行的序列），计算机器返回一个结果６。
２．参与者(Actor)参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
３．泛化泛化和类中的泛化概念是一样的，子用况继承父用况的行为和含义，还可以增加或覆盖父用况的行为;子用况可以出现在任何父用况出现的位置（父和子均有具体的实例）。
下面给出两种图示来说明泛化的概念和含义图２含义继承图３行为继承４．<<user>><<use>>: 其关系非常象一个函数调用或一个子过程以这种方式使用的用例称为抽象用例因为它不能单独存在而必须被其它用例使用，请看下图图４使用<<use>>示例５．<<include>>怎么解释这个定义呢？还是说明一下它的功能吧，<<include>>可以把几个用例的公共步骤分离出来成为一个单独的被包含用例。
软件工程：UML之用例模型
二、主角
Hwadee 华迪实训
•系统所使用的外部硬件。
示例： 控制建筑物中温度的通风系统不断地从建筑物中的传感器处获取温度信息。所以，
传感器就是一个主角。 •与该系统交互的其他系统。
示例： 一个自动柜员机必须和保存银行帐户的中央系统进行通信。中央系统很可能是一个外
部系统，因此它应该是一个主角。 如果您在构建一个基于 Internet 的应用程序，那么您的主要主角在某种意义上将是 匿名的。您并不真正知道这些主要主角是谁，而且也无法假定他们的技能和背景。但 您仍能说明您希望他们在您的系统中担任的角色。 示例：
(2) UML表示法 定义UML符号的表示法,为开发者或开发工具使用这 些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达 的是应用级的模型,在语义上它是UML元模型的实例。
7
一、UML简介
Hwadee 华迪实训
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设 备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的 依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的 对应关系。 从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据 需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其 中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、 对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。 其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互 关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言 UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静 态建模机制和动态建模机制两大类。
《UML与软件建模》实验1 用例建模
《UML与软件建模》实验1用例建模[实验日期]年月日[实验目的]·掌握客户需求分析的方法和步骤·了解以用例驱动的软件开发方法·识别并编写用例·掌握用Rose进行用例建模的具体方法和步骤[实验内容]要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。
亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”(参见“项目背景及简要分析.pdf”)。
[实验原理和步骤]建模原理：(1)需求获取。
以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。
(2)用例分析。
确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）（3）用例描述。
分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：（1）需求获取。
自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。
（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。
（2）用例分析。
确定系统范围和边界、确定参与者、确定用例。
（3）用例描述。
分层绘制用例图、描述用例。
画图原理：采用Rose软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。
步骤：（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统”->“进销存管理”子系统->“销售管理”->“合同管理”->“收款单处理”为主线，完成附录2中的操作过程（亦可选择“企业综合信息管理系统”->“进销存管理”子系统->“库存管理”->“原材料出库”->“领料单处理”主线）[实验结果]《学生填写》采用ROSE绘制的“企业综合信息管理系统”的1级用例图，以及其中的“进销存管理”用例的文字描述。
staruml用例描述
staruml用例描述
StarUML是一款流行的UML建模工具，用于创建和编辑软件系统的各种UML图。
在StarUML中，用例描述是指对系统功能和用户需求的描述，通常用于用例图和用例规约的编写。
用例描述通常包括以下内容：
1. 用例名称，描述用例的名称，通常是对功能的简洁描述，例如“用户登录”或“查看订单”。
2. 参与者，列出参与该用例的各种角色或实体，包括主要参与者和次要参与者。
参与者可以是人、其他系统或外部实体。
3. 描述，对用例的功能和行为进行详细描述，包括用例的目标和预期结果。
这部分通常包括用例的主要流程和可能的替代流程。
4. 先决条件，描述执行该用例所需满足的条件或假设，例如“用户已经注册并且拥有有效的登录凭证”。
5. 后置条件，描述用例执行完成后系统的状态或行为，例如“用户成功登录后进入系统主页”。
6. 异常情况，描述可能发生的异常情况和处理方式，例如“用
户输入的用户名或密码不正确”。
在StarUML中，可以通过创建用例图和使用用例描述来呈现系
统的功能和用户需求，帮助团队成员更好地理解系统的行为和交互。
通过使用用例描述，开发人员和利益相关者可以更清晰地了解系统
的功能和行为，从而更好地进行系统设计和开发工作。
企业综合信息管理系统UML需求建模(用例图+活动图)
2020/11/27
管理课件
5
（4）系统运行的软件、硬件环境 1）系统运行的软件环境 2）系统运行的硬件环境
3.6.2 确定系统范围和系统边界
1．进销存管理子系统的业务范围 2．进销存管理子系统的系统边界
3.6.3 确定执行者
“进销存管理子系统”有5个人执行者和2个系统执行 者，即“采购人员”、“销售人员”、“仓库管理 员”、“客户”、“公司经理”、“生产调度管理子 系统”和“财务管理子系统”。
管理课件
2
（2）采购管理
1）制定原材料（零部件）采购计划 2）与客户签订采购合同 3）检查合同履约率 4）库存管理部门对原材料进行入库验收、存储 5）财务管理部门支付货款
（3）库存管理
1）产品入库管理 2）原材料（零部件）入库管理 3）原材料（零部件）出库管理 4）产品出库管理 5）库存管理 6）采购管理部门组织采购 7）生产调度管理部门安排生产 8）财务管理部门对库存物资进行核算
1．“增加销售合同”用例
用例编号：04010101（共有4层用例图结构，每层用2位数字表 示， 采用8位编号。）
用例名： 增加销售合同 执行者: 人执行者：合同管理员、客户、公司经理。系统执
行者：“财务管理子系统”和Байду номын сангаас生产调度管理子系
统”。
目 的: 合同管理员将与客户签订的销售合同的详细内容录 入管理系统，用于对销售合同进行统计、查询、检查 是否履约等，监控正在履约的合同。
类 型： 端点、主要的、基本的 级 别： 一级
2020/11/27
管理课件
14
过程描述：
（1）合同管理员输入标识码（ID），系统识别标识码的有效
性；
（2）初始化一个新销售合同，设置各种处室标志；
uml用例描述
uml用例描述在软件开发过程中，用例是一种用来描述系统功能和用户需求的工具。
UML（Unified Modeling Language）是一种常用的建模语言，其中用例图是用来描述系统功能和行为的图形表示方法。
本文将使用UML用例图的描述方式，来介绍一个名为“在线购物系统”的软件系统。
1. 引言在线购物系统是一个电子商务平台，为用户提供了在线购买商品的功能。
本系统的主要参与者包括注册用户、游客和管理员。
注册用户可以浏览商品、添加商品到购物车、下单购买商品等；游客可以浏览商品，但无法添加商品到购物车或下单购买；管理员负责管理商品信息和用户信息。
2. 用例图下面是“在线购物系统”的用例图：- 注册用户用例：注册用户可以执行的操作包括浏览商品、搜索商品、添加商品到购物车、下单购买商品、查看订单状态和评价商品。
- 游客用例：游客可以执行的操作包括浏览商品、搜索商品和查看商品详情。
- 管理员用例：管理员可以执行的操作包括添加商品、编辑商品信息、删除商品、管理用户信息和查看订单信息。
3. 详细描述3.1 注册用户用例- 浏览商品：注册用户可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：注册用户可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 添加商品到购物车：注册用户可以将感兴趣的商品添加到购物车中，以便稍后进行结算。
- 下单购买商品：注册用户可以选择购物车中的商品，生成订单并进行支付。
- 查看订单状态：注册用户可以查看自己的订单状态，包括待支付、待发货、已发货等。
- 评价商品：注册用户可以给已购买的商品进行评价，以供其他用户参考。
3.2 游客用例- 浏览商品：游客可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：游客可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 查看商品详情：游客可以查看具体商品的详细信息，包括商品介绍、规格、用户评价等。
UML用例图说明
UML⽤例图说明前些时间参加了潘加宇⽼师的技术讲座，UML建模技术受益匪浅。
我也把平时的⼀些积累和上次的收获总结在这篇⽂章中，主要讲解⽤例图相关的知识。
⽤例图是软件需求分析到最终实现的第⼀步，它描述⽤户如何使⽤系统及使⽤系统什么样的功能。
⽤例图从业务⾓度上体现谁来使⽤系统、⽤户希望系统提供什么样的服务，以及⽤户需要为系统提供的服务，也便于软件开发⼈员最终实现这些功能。
⽤例图在开发中被⼴泛的应⽤，但是它最常⽤来描述系统提供了什么样的功能给什么样的⽤户使⽤。
在官⽅⽂档中⽤例图包含六个元素，分别是：执⾏者(Actor)、⽤例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
但是有些UML的绘图⼯具多提供了⼀种直接关联关系(DirectedAssociation)。
⽤例图可⼀个包含注释和约束，还可⼀个包含包，⽤于将模型中的元素组合成更⼤的模块。
有时，可以将⽤例的实例引⼊到图中。
⽤例图模型如下所⽰，执⾏者⽤⼈形图标来标识，⽤例⽤椭圆来表⽰，连线表⽰它们之间的关系。
⼀、执⾏者（Actor）1、执⾏者概念是指⽤户在系统中扮演的⾓⾊。
如图1-1是⼀个⽤户管理的⽤例图，图中的⽤户、管理员就是⽤例的执⾏者。
图1-12、从业务中找出执⾏者获取系统⽤例⾸先要找出系统的执⾏者。
我们可以通过⽤户回答⼀些问题的答案来识别执⾏者。
可以参考以下问题：1. 谁使⽤系统的主要功能（主要使⽤者）？2. 谁需要系统⽀持他们⽇常⼯作？3. 谁来维护、管理系统使其正常⼯作（辅助使⽤者）？4. 系统需要控制哪些硬件？5. 系统需要其他哪些系统交互？这⾥包含其他计算机系统或者应⽤程序。
6. 对系统产⽣结果感兴趣的是哪些⼈和哪些事物？3、执⾏者之间关系因为执⾏者是类，所以多个执⾏者之间可以具有与类相同的关系。
在⽤例图中，使⽤了泛化关系来描述多个执⾏者之间的公共⾏为。
UML建模——用例图（UseCaseDiagram）
UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。
说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。
⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
⼆、⽤例图所包含的的关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。
但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。
这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。
学生选课系统UML用例描述
填写学习计划用例1.简要说明本用例说明学生填写学习计划的过程。
2．事件流（1）基本流①学生登录系统。
②学生填写学习计划。
③系统检验学习计划是否可行。
④系统保存学习计划。
（2）备选流1.a如果无法正常登录，则该过程结束。
3.a如果系统检验学习计划不可行，则该过程结束。
3．特殊需求（1）系统中每个学生只能保存一份学习计划。
（2）系统需要长期稳定运行，及时备份数据。
4．前置条件无。
5．后置条件学习计划成功存储到计算机中。
6．扩展点无。
7．相关的数据学生信息，课程信息，教师信息。
8．问题说明无。
检验学习计划用例2.简要说明本用例说明系统检验学习计划的过程。
2．事件流（1）基本流①系统检验学习计划。
②将学习计划保存到数据库中。
（3）备选流1.a如果系统检验出学习计划不可行，则该过程结束。
3．特殊需求（1）系统中每个学生只能保存一份学习计划。
（2）系统需要长期稳定运行，及时备份数据。
4．前置条件学生已经填写好了学习计划。
8．后置条件无。
9．扩展点无。
10．相关的数据学生和学习计划的相关信息。
8．问题说明无。
选课用例3.简要说明本用例说明学生选课的过程。
2．事件流（1）基本流①学生登录系统。
②学生根据课表选课。
③系统保存选课结果。
（4）备选流1.a如果无法正常登陆，则结束。
3.a如果系统检查出该学生没有修该课程的先修课程，则结束。
3.b如果课程人数已满，则结束。
3．特殊需求系统需要长期稳定运行，及时备份数据。
4．前置条件无。
11．后置条件将选课信息成功存储到数据库中。
12．扩展点无。
13．相关的数据学生的信息，课程的信息。
8．问题说明无。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
描述用例
用例描述了系统和它的用户之间在一
火龙果 整理
定层次上的完整的交互 在用例的不同实例中将发生什么样的 细节，会在很多方面有所不同 一个用例实例中可能会出现差错，将 不能达到原来的目的 一个用例的完整描述必须指明，在用 例所有可能的实例中可能发生什么
描述用例
文本形式的用例规格说明具有许多优点：
1. 2.
简单易用，不需要CASE工具的支持。 不需要了解有关软件开发方法学的知识。
3.
4. 5.
不需要培训。
便于携带。 可以在任何时间任何地点编写用例。
6.
需求建模
以顾客能够理解的自然语言描述用例。
28
火龙果 整理
文本形式的用例规格说明所具有的上述优点使之成为与非技术
购买商品
登 录
收银员 顾客
退还商品
火龙果 整理
用例的关键特征
用例描述的系统行为是具体的、完整的场景。
用例描述的不是的具体功能。
你不能将用例分解为一些小的模块，然后将这些小
模块称之为用例。
注意：利用用例进行系统的功能分解是一个常见的
项目相关人员及其兴趣
前置条件 成功后的保证（后置条件） 主要成功场景（或基本流程） 扩展（或替代流程） 特殊需求 技术与数据的变化列表
销售点终端的主要参与者
火龙果 整理
调用系统服务来完成目标的主要参
与者
收银员 顾客
？
火龙果 整理
在1米之外看清 90%的信用卡授权机构的响应应该在30秒收到 ……
技术和数据的变化列表
火龙果 整理
技术和数据的变化列表：系统通常有一些技术上的变化是
关于“应该怎么做”，而不是“应该做什么”，需要在用 例中将这种变化记录下来。
“这个POS系统必须支持信用卡帐号的读卡器 输入和键盘输入”
火龙果 整理
3.系统记录单件商品，并显示该商品的描述、 价格和累加值。价格可以根据一套定价规格来 计算
收银员重复3-4步
4. ，输入完商品信息后，向销售 终端发出提示，提示商品信息录 入完毕 6.收银员录入顾客所付金额 5.系统记录和显示该顾客的商品价值总额，并 计算税金 7.系统显示应找金额，打印付款收据；并将销
为汽车加油
就餐
需求建模
33
火龙果 整理
扩展(extend)关联的含义是基用例(如图中的"旅行")可以通过可
选的扩展用例(extending use case，如图中的"就餐")加以扩 展。 一个扩展用例事实上改变了基用例的事件流。 扩展用例的行为是否被执行要取决于主事件流中的判定点。 在本例中，当基场景到达Eat Meal选择项代表的扩展点 (extension point)时，司机必须决定他是否想要进餐。如果是， 则扩展用例Eat Meal将被执行。如果不是，则沿基用例的事件 流继续执行。 旅行
注意：这一部分不应包含用来表述不同情况下不同行 为的多个步骤，如果有必要，将这些步骤记录在“扩展” 部分
火龙果 整理
用例规格说明力图简洁，限制在几页的篇幅内。用例规格说明的目
的是紧凑地说明用例的事件流。如果篇幅太大，那么用例要做的事
情就会过多，或者在编写用例时可能使你在不重要的可选流上花费 过多的精力。
例如：对于销售点终端系统来说，一些可能的参 与者和他们发起的过程有：
参与者 事件
销售员
顾客
登录 用现金结算 购买商品 退还商品
项目相关人员及其兴趣
火龙果 整理
用例应该包含满足了所有的项目相关人员兴趣的内
容 以项目相关人员的兴趣作为视点来观察，会为我们 提供一种彻底的、系统化的程序，用来发现和记录 所有必需的行为
火龙果 整理
用例描绘的场景(或事件流)展示了参与者如何
使用系统。
典型地，一个用例应该包含一个主事件流和
其他不同的可选场景，就像地图描绘了主路 线同时也展示了其他可选择的路线。
描述用例(续)
火龙果 整理
用例描述可能包含大量信息，
需要某种系统的方法来记录这 些信息 UML没有定义一种描述用例的 标准形式 许多开发人员定义了用例描述 的模板
扩展（替代/可选流程）
火龙果 整理
说明了所有其他的场景或分支，无论是成功的场景
还是失败的场景
扩展场景是从主要成功场景中分支出来的，因此应该遵
从主要成功场景的标记方式
3.收银员输入商品标识
扩展
一个扩展以两个部分 组成：条件和处理
3a.无效的商品ID 1.系统指示错误并拒绝输入 2.收银员响应该错误，重新输入 3b.有多个具有相同商品类别的信息（如5条A式毛巾），不需要 跟踪每个商品的唯一身份 1.收银员可以输入商品类别的标识和数量
旅行
为汽车加油
需求建模
31
火龙果 整理
包含(include)关联的含义是包含用例(include use case，如
图中的Fuel Vehicle)嵌入在基用例(base use case，如图中 的Take Trip)的流中。 包含用例是可重用的用例——多个用例的公共用例。 尽管包含用例是公共用例，但它同样是强制性的。 在这个例子中，如果没有它的包含用例Fuel Vehicle，则基 用例Take Trip是不完整的。在基用例的场景中，当基用例的 执行到达包含用例的包含点(inclusion point)时，包含用例 被执行。 旅行
为汽车加油
就餐
34
需求建模
火龙果 整理
错误。
需求建模
5
如何写用例
火龙果 整理
也称之为用况，是一个描述型文档，用来
描述一个参与者（一个外部的主动者）使 用系统完成某个过程时的事件发生顺序。
通俗而言，用例就是如何使用系统来达到
目标的一组情节，其本质是通过写出多种 使用系统的情节来发现和记录功能性需求
简单有效
为条件
5.系统显示总值并计算税金
方式1
5a.系统检测到与外部的税金计算系统的通信故障
方式2
5b. 外部的税金计算系统工作不正常
？
推测
火龙果 整理
扩展处理也可以包含一系列步骤：
扩展
3-6a.顾客要求收银员从已输入的商品中去掉一个商品 1.收银员输入商品标识并将其删除 2.系统显示更新后的累加值
归档用例
火龙果 整理
基本用例 每一个用例必须包含这样一些细节， 这些细节告诉人们需要完成哪些步 骤才能实现这个用例的功能 基本功能 所有可选方案 异常情况 进入用例之前以及退出用例时必 须正确的一切
一个用例格式模版
主要参与者
火龙果 整理
售和付款信息发送到外部的记账系统 （进行记账）和库存系统（记录销售信息
和更新库存）
8.顾客带着商品和收据离开
扩展（替代/可选流程）
火龙果 整理
说明了所有其他的场景或分支，无论是成
功的场景还是失败的场景
扩展场景是从主要成功场景中分支出来的，
因此应该遵从主要成功场景的标记方式
人员(例如顾客、业务发起人)打交道时的一种理想描述形式。
用文本形式描述用例也有一个严重的缺陷。这样描述的用例与
其他所有文本形式的规格说明一样：规格说明越来越复杂时， 其中的各种条目之间的关系和信息交互将变得难以理解。
解决的办法：用UML顺序图描述用例 这也正是用UML顺序图描述用例的长处所在。
寻找扩展路径的方法
方法一：沿着基本 方法二：用以下大类
火龙果 整理
路径一条一条地找， 并且考虑：
在这个点上还可以执
去发现可选路径
行别的活动吗？ 在这个点上有没有什 么可能出错的？ 有什么随时可能发生 的行为吗？
火龙果 整理
描述指导原则：以系统或参与者能够监测到的某事物作
顾客要求兑换账户积分
顾客要求其它的支付方式 顾客要求使用优惠券 顾客索要赠品票据
特殊要求
火龙果 整理
特殊要求：如果有一些与此用例有关的非功能需求（象质
量属性或约束条件），那么将它们和用例记录在一起。
FURPS+模型
在大型平板显示器上的触摸屏界面。文本信息要能够
前置和后置条件表示用例开始和结束会发
生什么
前置：规定了在用例中的一个场景开始之前
必须为“真”的条件 后置：规定了在用例中的一个场景成功结束 后必须为“真”的条件
前置条件：收银员必须已经被确认和认证 存储销售信息 生成收据 更新账务和库存 这一“保证”应该满足 记录提成 所有项目相关人员 的需要 准确计算税金 记录支付授权的批准
在你开发其他用例的过程中，你会发现有一个活动在每个场
景中都会出现，那就是“Fuel Vehcile(为汽车加油)”。
需求建模
30
火龙果 整理
为汽车加油的动作在每个用例中是相同的。这种公共的行为 可以用一种特殊的关联表示，如图所示，在一个带箭头的虚 线上附加一个“<<include>>”标记。
需求建模
29
火龙果 整理
用例之间的关系
包含（include）
用例不仅仅与参与者之间存在交互关系，一个用例还可以与其
他用例存在关系。
假设你正在开发一个与开车旅行有关的用例。为了讨论的方 便，假设“Take Trip(旅行)”是一个用例，它的流包括旅行 规划、为汽车加油、驶往目的地、观光和驾车返回。这个用 例可能包含多个可选的场景。
3－6b.顾客要求取消销售交易 1.收银员在系统中取消销售交易 2.系统开始新的销售 3－6c.收银员延迟销售交易 1.系统记录销售交易信息，使其能够在任何登录中恢 复操作 2.系统显示用来恢复销售交易的“延迟票据”，包括 商品项目和销售交易ID