用例图和用例描述设计实例
02-用例和用例图
3.4.4 几种关系的比较
关系类型
说明
表示符号
关联
actor与use case之间
泛化
actor之间或use case之间
包含
use case之间
扩展
use case之间
用例图
用例图(use case diagram)是显示一组用例、角色以及它 们之间的关系的图.
在UML中, 一个用例模型若干个用例图描述.
角色
由于Actor实际上是一个特殊类, 因此它们之间可以 存在一定的关系,如：
脚本/场景
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况.
其它译名: 情景、情节、剧本.
每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
实例分析：语音邮箱系统----用例脚本
用例3: 登录系统 1. 邮箱用户完成邮箱号输入操作. 2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 3. 语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语.
实例分析：语音邮箱系统----用例脚本
用例4: 接收信息 1. 邮箱用户完成登录操作. 2. 邮箱用户选择 “接收信息”菜单选项. 3. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 4. 邮箱用户选择“收听当前信息”菜单选项. 5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 6. 语音邮件系统播放信息菜单. 7. 用户选择”删除当前信息”,则信息被永久删除. 8. 继续执行第3步.
用例例子
应用举例 例2—医院病房监护系统 一、问题描述
为了对危重病人进行实时监护 随时了解病人病情， 实时监护， 为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。 进行处理，建立病房监护系统。 病症监视器安置在每个病床， 病症监视器安置在每个病床，通过网络将病人的病症信号 组合）实时传送到中央监护系统进行分析处理。 （组合）实时传送到中央监护系统进行分析处理。 在中心值班室里， 在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控， 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。 并打印病情报告和更新病历。 系统根据医生的要求随时打印病人的病情报告， 系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。 自动更新病历。
采样频率 改变 信号数据组合 <<include>> 模数转化 信号采集 病人
分解信号 <<include>>
<< include>> 生成病历
<<include>>
更新病历
用例“中央监护” 用例“中央监护”描述模板
用例名： 用例名： 中央监视 执行者： 值班护士、 执行者： 值班护士、医生 目标： 目标： 对病人的病症信号进行监测、处理，超过极限报警。 功能描述： 功能描述： 1.分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的 信号。 2.比较信号：将病人的病症信号与标准信号比较 。 3.报警：如果病症信号发生异常（即高于峰值），发出报警信号。 4.数据格式化：将处理后的数据格式化以便写入病历库 。 其他非功能需求: 高可靠性、实时性 其他非功能需求 高可靠性、 主要步骤： 主要步骤： 1.按设定频率连续接收来自各病人的病症信号，并进行分解。 2.将病人的病症信号与专家系统（标准病症信号库）中的标准信号进行比较判 断是否超过极限值。 3.若超过极限值，进行报警，并及时更新病历和打印病情报告。 相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。 相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。 相关信息： 优先级 性能、 执行率 ： 优先级、 相关信息：(优先级、性能、频执行率)： 优先级：报警处理具有最高优先级3,一般病历管理为1,其他2. 优先级：报警处理具有最高 性能：实时性、 性能：实时性、高可靠性 执行率 根据病情严重程度 12-30次/小时 频执行率：根据病情
用例图和用例描述设计实例
用例图和用例描述设计实例作者：ephyer 发表时间：2004-09-09 1 8:01:35更新时间：2004-09-09 1 8:01:35浏览：1954次主题：电脑技术评论：0篇地址：202.19 7.75.*:::栏目:::•Thinking in java 学习笔记•JA VA基础知识•UML•软件设计师•其他类别这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：后台管理系统用例图如下：对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。
如下：用例名称：网站公告发布用例标识号：202参与者：负责人简要说明：负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。
前置条件：负责人已经登陆家教网站管理系统基本事件流：1．负责人鼠标点击“修改公告”按钮2．系统出现一个文本框，显示着原来的公告内容3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改5．用例终止其他事件流A1：在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异常事件流：1．提示错误信息，负责人确认2．返回到管理系统主页面后置条件：网站首页的公告信息被修改注释：无四．总结其实用例建模并不是这么简单，它涉及到的知识还有很多，我这里只是简单的介绍一下，希望对初学UML建模的同学有所帮助。
上一篇下一篇展开所有评论发表评论推荐转载写信问候返回目录快速返回我的百宝箱用例名称：用户登录用例标识号：01参与者：管理员、普通用户简要说明：参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。
前置条件：参与者已经打开系统的登录页面（login.jsp）基本事件流：1．参与者在用户名输入框里输入用户名2．在密码框里输入密码3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。
用例及用例图案例
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？
uml综合案例：员工考勤系统
《UML2面向对象分析与设计》综合案例：员工考勤系统作业评分实施细则一、第四章作业（用例图和用例文档）1. 评分档次用例图和用例文档分别按照满分10分计算，以此作为评分标准，基本的评分准则如下：●一档（10分）：图形（文本）条理清楚，无任何明显错误●二档（8-9分）：图形/文本清楚，存在个别错误●三档（6-7分）：图形/文本一般，存在一定的错误●四档（5分）：图形/文本条理不清，存在致命错误或错误数过多一般情况下按错别个数扣分，每个错误按严重程度扣0.5、1、2分，最终成绩向上取整；同类错误不重复扣分。
2. 参考答案作业答案部分仅供参考，学生的作业可能会多种多样，具体按照第三部分的典型错误扣分，用例图：用例文档：员工（含小时工和普通员工）相关用例无前置条件员工已正确登录到该系统后置条件无（将在下次迭代中确定）涉众利益员工：准确地维护自己的考勤信息公司：要求员工的信息准确基本路径1—添加新的考勤1.1、用例起始于用户需要记录新的考勤信息1.2、系统显示当前日期和时间，并提醒用户该时间即为用户的上班时间1.3、用户确认该信息1.4、系统记录当前日期和时间，并将其作为用户考勤信息的上班时间2—提交考勤信息2.1、任何时刻用户都可以提交自己的考勤信息2.2、系统查询用户上班时的考勤记录（E-1）2.3、系统记录当前的日期和时间，作为用户考勤信息的下班时间2.4、系统显示用户今天完整的考勤信息2.5、用户确认提交考勤信息2.6、系统保存考勤信息，并将考勤信息的状态改为“已提交”（D-1）备选路径E-1 如果系统没有找到用户上班时的考勤信息，则用例终止；用户可以通过项目经理为其添加上班的考勤信息数据需求A-1 考勤信息主要包括：用户名、日期、上班时间、下班时间、状态D-1 考勤信息的状态有：“新考勤”（只有上班时间，没有下班时间的考勤信息）、“已提交”（有完整的上下班时间，但还没有进行工资结算的考勤）、“已完成”（已结算工资的考勤）业务规则B-1 作为用户考勤信息的上下班时间由系统自动获取，不允许用户编辑B-2 状态为“已提交”的考勤信息不允许普通用户进行任何操作；非功能需求无设计约束无待解决问题无参与者时间、项目管理数据库（外部系统）相关用例无前置条件无后置条件无（将在下次迭代中确定）涉众利益员工：…（包括临时工、普通员工、销售人员）公司：…基本路径—计算普通员工和销售人员工资1.用例起始于系统时间到达每月末晚上，需要计算普通员工和销售人员工资(E-1)；2.系统查询所有的普通员工和销售人员的个人信息（D-1）；3.对于每一个员工（普通员工、销售人员）：3.1.根据员工的类别获得其考勤信息或订单信息（E-2）；3.1.1.如果是普通员工，则获得本月的考勤信息（D-2）；3.1.2.如果是销售人员，则获得本月的销售信息（D-3）；3.2.系统从项目管理数据库中获得员工的工资级别信息（E-3）；3.3.系统根据员工的考勤信息（或销售信息）和工资级别信息计算该员工的工资，保存；4.计算完成后，系统产生一个提醒信息，以便于项目经理确认备选路径E-1—计算临时工工资1. 用例起始于系统时间达到每个周末的晚上，需要计算临时工工资2. 系统查询所有临时工的个人信息3. 对于每一个临时工：3.1. 获得员工的考勤信息3.2 从项目管理数据库中获得员工的工资级别信息；3.3 系统根据员工的考勤信息和工资级别信息计算该员工的工资，保存；4. 计算完成后，系统产生一个提醒信息，以便于项目经理确认E-2 如果找不到该员工的考勤信息或订单信息，则记录相关日志，并转回3计算下一个员工E-3 如果无法获得员工工资级别信息，则记录相关日志，并转回3计算下一个员工数据需求D-1. 员工信息=员工编号+员工姓名D-2 考勤信息参见“登记考勤”用例D-3 订单信息参见“登记订单”用例业务规则暂不明确非功能需求暂不明确设计约束3. 典型错误情况3.1 用例图部分3.1.1 参与者本系统中包含的参与者有：小时工、普通员工、销售人员、项目经理、项目管理数据库、时间，其中由于小时工和普通员工有关考勤的处理细节完全相同，因此为了便于简化和复用，可将他们统一合并为员工（不合并也可以，不算错误），但不能和销售人员合并，因为销售人员没有考勤信息，而是登记订单信息，需要明确区分。
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
如何描述软件系统的需求
（2）应用用例方法最主要的优点 因为它是用户导向的----从用户的角度来说明系统 所应该提供的功能。 注意：用例仅能捕获功能性需求，不适合捕获非功能性需 求和设计约束等。 （3）前面的餐馆定座系统用例图示例
2、用例图(Use Case Diagram) （1）什么是用例图 确定系统中所包含的各个参 与 者 、用例和两者之间关系 的 UML图。 （ 2 ）主要的作用：用例图描述的 是关于系统功能的一个概述 3、用例规约(Use Case Specification) 针对每一个用例都应该有一个用例规约文档与之相 对应，该文档描述用例的细节内容。
4、某项目的主要功能模块（系统的树型结构图）
5、采用功能结构图来描述系统的各个主要功能模块 （1）什么是功能结构图（面向过程中常常应用） 功能结构图（ Structured Analysis Diagram ）就是 将系统的功能进行分解，按功能从属关系表示的图表。并 用箭头指向子过程。 （2）决定功能结构图中的功能层次和各个功能模块的划分 上层功能包括 (或控制)下层功能，愈上层功能愈笼统， 愈下层功能愈具体。 功能分解的过程就是一个由抽象到具体、由复杂到简 单的过程——逐步求精。 （3）功能结构图设计过程其实也就是系统功能分解的过程 这种分解为多个功能较单一的模块的方法称做模块化， 它把一个复杂的系统分解为一些规模较小、功能较简 单的、更易于建立和修改的部分 各个模块具有相对独立性，可以分别加以设计实现
6、BBS 论坛系统 用例设计 示例
（1）各 种信息的 显示（面 向游客）
说明—请 见示范文档
本讲的简要回顾
1、子曰：“学而不思则罔，思而不学则殆。” “学而时习之”
2、子曰：“知之者不如好之者,好之者不如乐之者”
3、子曰：“三人行,必有我师焉”
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中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
教学管理系统设计用例图
教学管理系统设计用例图引言：教学是一项复杂而庞大的工作，它需要教师和学生之间的良好协同和管理。
为了优化教学流程和提高教学质量，许多学校和教育机构采用了教学管理系统。
本文介绍了教学管理系统的设计用例图，用例图展示了各个角色的操作和交互，有助于我们理解系统的功能和流程。
一、用例图简介用例图是一种结构化的图形化表示方法，用于展示系统的功能和角色之间的交互。
它包括了参与者、用例和关联关系。
参与者是系统的用户角色，用例是系统的功能模块，关联关系描述了参与者和用例之间的交互。
二、教学管理系统的参与者1.学生：学生是教学管理系统的主要使用者，他们可以进行选课、查看成绩、提交作业等操作。
2.教师：教师是教学管理系统的管理者和发布者，他们可以进行课程管理、作业发布、成绩录入等操作。
3.管理员：管理员是教学管理系统的最高权限用户，他们负责系统的配置、用户管理、系统维护等工作。
三、教学管理系统的用例1.学生选课：学生登录系统后，可以查看可选课程列表，选择自己感兴趣的课程，并进行选课操作。
2.教师管理课程：教师登录系统后，可以创建、编辑和删除课程，设置课程的基本信息、学时、授课时间等。
3.学生查看成绩：学生登录系统后，可以查看已选课程的成绩情况，包括平时成绩、考试成绩等。
4.教师发布作业：教师登录系统后，可以发布作业给学生，并设置截止日期和提交方式。
5.学生提交作业：学生登录系统后，可以查看已发布的作业，并按要求提交作业，可以上传附件或在系统中输入作业内容。
6.教师批改作业：教师登录系统后，可以查看学生提交的作业，并对其进行评分和批注。
7.管理员配置系统：管理员登录系统后，可以配置系统的各项参数，包括学期设置、成绩计算方式、学生选课限制等。
8.管理员管理用户：管理员登录系统后，可以管理学生、教师和管理员账号，包括创建、编辑和删除用户。
四、用例间的关联关系1.学生选课和教师管理课程：学生选课需要基于教师已经创建的课程，学生通过选课操作与教师管理课程做关联。
2.设计模式常用的UML图分析（用例图、类图与时序图）
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
第2章用例和用例图
成绩管理
UML用例图组成( UML用例图组成(续) 用例图组成
饮料销售机
UML用例图组成( UML用例图组成(续) 用例图组成
用例与用例的扩展关联用来表示通过对已有用例增加步 用例与用例的扩展关联用来表示通过对已有用例增加步 扩展关联用来表示 骤创建一个新的用例,即对原有的用例进行了扩展。 骤创建一个新的用例 即对原有的用例进行了扩展。扩展只能 即对原有的用例进行了扩展 发生在基用例的序列中的某个具体指定点上。这个点叫做扩 发生在基用例的序列中的某个具体指定点上。 展点.在UML图中，使用带虚线箭头表示，并在线上标有构造 展点 在UML图中，使用带虚线箭头表示， 图中 带虚线箭头表示 如下图所示： 型<<extend>> 。如下图所示：
UML用例图组成( UML用例图组成(续) 用例图组成
包含关联与扩展关联的区别： 包含关联与扩展关联的区别：
存在包含关联的两个用例,在执行基本用例时 一定会执 存在包含关联的两个用例 在执行基本用例时,一定会执 在执行基本用例时 行包含用例；存在扩展关联的两个用例,在执行基本用例时 在执行基本用例时, 行包含用例；存在扩展关联的两个用例 在执行基本用例时 可以执行,也可以不执行扩展部分 可以执行 也可以不执行扩展部分. 也可以不执行扩展部分
UML用例图的作用( UML用例图的作用(续) 用例图的作用
• 用例图的主要作用： 用例图的主要作用：
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础，驱动各阶段的开发工作 作为开发过程的基础， – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步. 画好用例图是由软件需求到最终实现的第一步.
UML用例图的建模( 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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
用例及用例描述
用例图用例描述用例：留言ID：1简单描述：用户在本网站留言板上进行留言（咨询）主参与者：user副参与者：数据库前置条件：本网站被打开且用户有留言需要主流：i)用户打开本网站ii)进入留言板页面iii)在留言板对话框内发布信息iv)点击确定，完成留言后置条件：用户留言成功附加流：数据库添加失败时提醒错误原因并询问是否重新留言用例：搜索ID：2简单描述：在本网站进行所需信息的搜索主参与者：user副参与者：数据库前置条件：本网站被打开且用户有搜索信息的需要主流：i)用户打开本网站ii)在网站搜索引擎中键入搜索条件或直接按类别搜索iii)点击确定，完成搜索iv)得到预期信息，用户可以对所得信息进行浏览后置条件：搜索完成并且用户得到预期信息附加流：搜索数据库无结果，提示原因并询问是否重新搜索用例：回复ID：3简单描述：客服对用户的留言板提问或留言进行回复主参与者：客服副参与者：数据库前置条件：有用户在留言板上提问或留言主流：i)客服登录网站后台ii)进入留言板回复页面iii)点击回复，在出现的对话框内键入回复内容iv)点击确定，完成回复后置条件：客服回复信息成功附加流：数据库添加失败时提醒错误原因并询问是否重新回复ID：4简单描述：普通管理员将最新资讯信息添加到网站数据库中主参与者：普通管理员副参与者：数据库前置条件：网站有最新的咨询信息需要添加主流：i)普通管理员登录网站后台页面ii)将最新资讯信息录入到数据库中iii)点击确定完成录入后保存所作修改iv)修改成功后关闭后台页面后置条件：最新资讯信息成功添加到数据库中附加流：添加信息出错时数据库提示出错信息用例：删除网站信息ID：5简单描述：普通管理员将废旧资讯信息从网站数据库中删除主参与者：普通管理员副参与者：数据库前置条件：网站有废旧的咨询信息需要删除主流：i)普通管理员登录网站后台页面ii)查询废旧的资讯信息iii)将废旧资讯信息从数据库中删除iv)点击确定完成删除后保存所作修改v)删除成功后关闭后台页面后置条件：废旧资讯信息成功从数据库中删除附加流：删除信息出错时数据库提示出错信息ID：6简单描述：普通管理员对网站数据库中数据进行修改主参与者：普通管理员副参与者：数据库前置条件：网站有待修改的数据信息需要修改主流：i)普通管理员登录网站后台页面ii)查询待修改的资讯信息iii)对待修改资讯信息进行修改iv)点击确定完成修改后保存所作修改v)修改成功后关闭后台页面后置条件：待修改资讯信息在数据库中修改成功附加流：修改信息出错时数据库提示出错信息用例：查询网站信息ID：7简单描述：对数据库中的网站信息通过不同条件进行搜索查询主参与者：普通管理员副参与者：数据库前置条件：已确定要查询信息的关键字主流：i)普通管理员登录网站后台页面ii)根据搜索关键字对信息进行搜索iii)搜索成功，显示查询到的语句后置条件：信息查询成功，得到所查信息详情附加流：搜索失败，未能得到要查询信息并提示出错信息用例：删除留言ID：8简单描述：对数据库中的留言进行删除管理主参与者：普通管理员副参与者：数据库前置条件：存在不合法留言信息，普通管理员需要对其进行删除操作主流：i)普通管理员登录网站后台页面ii)在数据库中查询到不合法的留言信息iii)对不合法留言信息进行删除操作iv)点击确定完成操作后进行保存v)保存后关闭后台页面后置条件：不合法留言信息得以成功删除附加流：删除留言信息失败并提示出错信息用例：查询留言ID：9简单描述：对数据库中的留言信息进行查询检索主参与者：普通管理员副参与者：数据库前置条件：确定要检索留言信息的关键字主流：i)普通管理员登录网站后台页面ii)根据不同的检索条件对留言信息进行查询iii)成功检索到所要查询留言信息并显示信息详情后置条件：所要查询留言信息得以成功检索附加流：未能查询到所要查询的留言信息并提示出错信息用例：登录ID：10简单描述：网站的超级管理员、普通管理员和客服登录进本网站后台主参与者：超级管理员、普通管理员，客服副参与者：无前置条件：各种管理员需要进入后台进行各种信息维护主流：i)进入网站后台管理页面ii)键入预先分配好的帐号和密码iii)点击登录，进入后台iv)登录成功后置条件：各种管理员登录后台成功附加流：登录出错时提示出错信息用例：创建管理员用户ID：11简单描述：超级管理员创建一个新的管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要新建一个管理员用户主流：i)超级管理员登录网站后台页面ii)创建一个新的管理员用户（帐号，密码）iii)点击确定完成新管理员用户的创建，数据库进行保存iv)创建成功后关闭后台页面后置条件：网站得到一个新的普通管理员用户或客服用户附加流：创建失败时数据库提示出错信息用例：删除管理员用户ID：12简单描述：超级管理员删除一个管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要删除一个管理员用户主流：i)超级管理员登录网站后台页面ii)删除一个管理员用户（帐号，密码）iii)点击确定完成管理员用户的删除，数据库进行保存iv)删除成功后关闭后台页面后置条件：删除一个普通管理员用户或客服用户成功附加流：删除失败时数据库提示出错信息用例：设置管理员权限ID：13简单描述：超级管理员对网站中的管理员设置权限主参与者：超级管理员副参与者：数据库，普通管理员，客服前置条件：需要对网站内的普通管理员和客服进行区分，对他们分别设置不同的权限主流：i)超级管理员登录网站后台页面ii)对普通管理员设置权限，令其能对网站信息进行增、删、改、查以及对游客留言信息（不合法）进行查询和删除对客服设置权限，令其只能对游客的留言或提问信息进行回复iii)点击确定完成权限设置，数据库进行保存iv)设置成功后关闭后台页面后置条件：普通管理员或客服的权限设置成功附加流：权限设置失败时数据库提示出错信息用例：查看管理员用户信息ID：14简单描述：超级管理员对普通管理员用户或客服用户的信息进行查看主参与者：超级管理员副参与者：数据库前置条件：需要查看管理员用户信息主流：i)超级管理员登录网站后台页面ii)对指定普通管理员用户或客服用户的信息进行查询iii)显示指定管理员用户信息后置条件：管理员信息查询成功，得到所查信息详情附加流：查询信息失败时数据库提示出错信息。
uml用例描述
uml用例描述在软件开发过程中，用例是一种用来描述系统功能和用户需求的工具。
UML（Unified Modeling Language）是一种常用的建模语言，其中用例图是用来描述系统功能和行为的图形表示方法。
本文将使用UML用例图的描述方式，来介绍一个名为“在线购物系统”的软件系统。
1. 引言在线购物系统是一个电子商务平台，为用户提供了在线购买商品的功能。
本系统的主要参与者包括注册用户、游客和管理员。
注册用户可以浏览商品、添加商品到购物车、下单购买商品等；游客可以浏览商品，但无法添加商品到购物车或下单购买；管理员负责管理商品信息和用户信息。
2. 用例图下面是“在线购物系统”的用例图：- 注册用户用例：注册用户可以执行的操作包括浏览商品、搜索商品、添加商品到购物车、下单购买商品、查看订单状态和评价商品。
- 游客用例：游客可以执行的操作包括浏览商品、搜索商品和查看商品详情。
- 管理员用例：管理员可以执行的操作包括添加商品、编辑商品信息、删除商品、管理用户信息和查看订单信息。
3. 详细描述3.1 注册用户用例- 浏览商品：注册用户可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：注册用户可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 添加商品到购物车：注册用户可以将感兴趣的商品添加到购物车中，以便稍后进行结算。
- 下单购买商品：注册用户可以选择购物车中的商品，生成订单并进行支付。
- 查看订单状态：注册用户可以查看自己的订单状态，包括待支付、待发货、已发货等。
- 评价商品：注册用户可以给已购买的商品进行评价，以供其他用户参考。
3.2 游客用例- 浏览商品：游客可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：游客可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 查看商品详情：游客可以查看具体商品的详细信息，包括商品介绍、规格、用户评价等。
用例和用例图
访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架
用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂
事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。
扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
用例图设计实例：
实验二：建立动态模型一旦定义了一个工程的用例，就可以用它们来指导对系统的进一步开发。
用例的实现描述了相互影响的对象的集合，这些对象将支持用例所要求的功能。
给出系统用例的实现，是从外部视图转到内部结构的第一步。
在UML中，用例的实现用交互图来指定和说明。
交互图通过显示对象之间的关系和对象之间处理的消息来对系统的动态特性建模。
有两种交互图：序列图和协作图。
1、创建交互图的步骤交互图一步一步地显示用例的实现流程。
它包括流中需要什么对象、对象之间发送什么、什么角色启动流、消息按什么顺序发送等。
系统要求实现的所有不同情形都在交互图中记录。
通过从用例建模得到的用例文档说明、词汇表和用例图来创建交互图。
2、实例本节主要以选课系统中的选课用例（Select Course）为例，来学习序列图的设计与实现。
2.1 分析为了使问题更简单一些，不考虑学生的登陆。
假设学生已经成功登陆系统，选课的事件流如下：（1）学生进入选课主界面。
（2）学生点击选课。
（3）系统显示所有课程信息。
（4）学生选择课程。
（5）系统验证课程是否可选。
A1：课程不可选（6）系统提示课程选择成功，提示学生交费。
（7）用例结束。
A1：课程不可选（1）系统提示课程不可选及原因。
（2）学生重新选课。
（3）重新验证直至成功。
（4）转选课事件流第6步。
首先，查找Select Course用例的对象。
从事件流中发现涉及以下对象：（1）界面。
（2）课程。
（3）对于业务层的操作，也应该有对象进行处理。
（4）事件流中设计的角色有：学生、数据库。
然后，分析对象、角色之间交互的消息。
本用例主要有以下交互：（1）学生通过界面发送选课命令。
（2）界面向控制对象请求课程信息。
（3）控制对象向数据库发送查询数据消息。
（4）控制对象暂存数据库的查询结果。
（5）界面对象从控制对象中取得所有的课程信息。
（6）在界面上显示所有的课程信息。
（7）界面对象发送命令要求控制对象删除课程信息。
第三章 用例和用例图
系统边界
… 参与者透过系统边界直接与系统交互，参与者的确定代表
系统边界的确定
有意义交互
任何事物
人、外部系统、外部因素等
武汉大学国际软件学院
12
3.2.2 识别参与者：参与者要点
•
参与者指在系统中所扮演的角色。即在确定参与者时， 应主要考虑他的角色，而不是这个角色的实例。
•
• • •
某些组织中可能有很多营销人员，但他们均起着同 一种作用，扮演着相同的角色。 … 一个用户也可以扮演多种角色：一个高级营销人员
经理
用例C
•
如系统中经理可以参加雇员 的所有用例
武汉大学国际软件学院
21
3.2.2 识别参与者：泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
武汉大学国际软件学院
22
3.2.3 识别用例（use case） 分析典型用例是开发者准确迅速地了解用户要求的最常用 也是最有效的方法，是用户和开发者一起深入剖析系统功 能需求的起点。 “用例”是Ivar Jacobson于20世纪60~70年代在爱立信公 司开发AKE、AXE系列时发明的。
武汉大学国际软件学院
29
用例要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
武汉大学国际软件学院
30
用例 VS. 功能
•呼叫某人
•传输/接收 •电源/基站 •输入输出（显示、键盘） •电话簿管理 •……
•接听电话
•发送短信 •记住电话号码
•…… 用户观点
UML的使用教程与实例分享
UML的使用教程与实例分享UML（统一建模语言）是一种用于软件开发过程中进行建模的标准化语言。
它提供了一种图形化的方式来描述软件系统的结构、行为和交互。
在软件开发过程中，使用UML可以帮助开发团队更好地理解和沟通需求，设计和实现高质量的软件系统。
本文将介绍UML的基本概念和常用图表，并通过实例分享来帮助读者更好地理解和应用UML。
1. UML的基本概念UML由一系列图表组成，每种图表都用于描述软件系统的不同方面。
常用的UML图表包括用例图、类图、时序图、活动图等。
用例图用于描述系统的功能需求，类图用于描述系统的静态结构，时序图用于描述系统的动态行为，活动图用于描述系统的业务流程。
了解这些基本概念是使用UML的前提。
2. 用例图用例图是UML中最常用的图表之一，用于描述系统的功能需求。
用例图由参与者（Actor）和用例（Use Case）组成。
参与者是系统的外部角色，可以是人、其他系统或设备等。
用例是系统的功能需求，描述了系统与参与者之间的交互。
通过用例图，可以清晰地了解系统的功能和参与者之间的关系。
3. 类图类图是UML中描述系统静态结构的图表。
类图由类、属性和方法组成。
类是对具有相同属性和行为的对象的抽象，属性是类的特征，方法是类的行为。
通过类图，可以清晰地了解系统中的各个类及其之间的关系。
类图还可以用于生成代码和数据库设计。
4. 时序图时序图是UML中描述系统动态行为的图表。
时序图描述了系统中对象之间的交互和消息传递顺序。
时序图由对象、生命线、消息和控制流程组成。
对象是系统中的实体，生命线表示对象的生命周期，消息表示对象之间的交互，控制流程表示对象之间的控制流程。
通过时序图，可以清晰地了解系统中对象之间的交互过程。
5. 活动图活动图是UML中描述系统业务流程的图表。
活动图由活动、决策、并行和合并等元素组成。
活动表示系统中的业务流程，决策表示系统中的判断条件，并行表示系统中的并发流程，合并表示系统中的流程合并。
小游戏用例图及用例说明
4.点击“返回”按钮，用例结束。
前置条件：玩家启动系统；想要更换背景音乐或调整音量大小
后置条件：背景音乐被改变或音量被调整
“选择模式”用例
用例编号：06
用例名：选择模式
执行者：玩家
目的：选择游戏的难度模式
事件流：
1.在主界面中点击“模式选择”按钮，进入游戏“模式界面”；
2.在模式界面选择你想玩的模式，例如：点击“初级模式”；
3.点击“关闭”按钮，用例结束
前置条件：玩家启动系统；初次使用或对该系统不了解
后置条件：玩家知道如何使用该系统
“背景设置”用例
用例编号：04
用例名：背景设置
执行者：玩家
目的：更换系统背景图片
事件流：
1.在主界面中点击“游戏设置”按钮，进入游戏“设置界面”；
2.在游戏设置界面中，在“背景设置”模块下，点击“选择背景图片”；
3.点击“返回”按钮，用例结束。
前置条件：玩家启动系统，想要选择模式
后置条件：模式选择，开始玩游戏或选择关卡
“选择关卡”用例
用例编号：07
用例名：选择关卡
执行者：玩家
目的：选择想玩的关卡
事件流：
1.在游戏界面中点击各个关卡按钮；
2.进入游戏，用例结束。
前置条件：玩家启动系统，进入游戏
后置条件：开始玩游戏
执行者：玩家
目的：玩游戏
事件流：
1.玩家启动系统
2.在主界面选择你想玩的模式，例如：点击“初级模式”；
3.进入到游戏级别页面，选择关卡；
4.开始玩游戏。
前置条件：一个想玩游戏的人
后置条件：保存游戏信息，进入下一关
“游戏设置”用例
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例图和用例描述设计实例
作者：ephyer 发表时间：2004-09-09 1 8:01:35
更新时间：2004-09-09 1 8:01:35
浏览：1954次主题：电脑技术
评论：0篇
地址：202.19 7.75.*
:::栏目:::
•T
hinkin
g in jav
a 学习
笔记
•J
A VA基
础知识•U
ML
•软
件设计
师
•其
他类别
这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：
后台管理系统用例图如下：
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。
如下：
用例名称：用户登录
用例标识号：01
参与者：管理员、普通用户
简要说明：
参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。
前置条件：
参与者已经打开系统的登录页面（login.jsp）
基本事件流：
1．参与者在用户名输入框里输入用户名
2．在密码框里输入密码
3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。
4．用户按登录后，系统验证参与者输入的有效性。
5．有效则进入系统的主界面。
无效则提示相应错误给用户。
6．用例终止
其他事件流A1：
在按“登录”按钮之前，参与者可以随按“取消（或关闭）”按钮。
异常事件流：
1．提示错误信息，参与人确认
后置条件：进入的主界面main.jsp ,装载相应的数据
注释：（可选：记住用户）。