用例建模
uml的用例模型
UML（Unified Modeling Language）统一建模语言是一种用于对软件密集系统进行可视化建模的标准化建模语言。
用例模型是UML中的一个重要概念，主要用于描述系统的功能需求和行为。
用例模型主要由三个部分组成：参与者（Actor）、用例（Use Case）和它们之间的关系。
参与者（Actor）：参与者是与系统进行交互的用户或其他系统，可以是外部实体或内部实体。
用例（Use Case）：用例描述了系统执行的功能，即参与者与系统之间的交互行为。
一个用例通常描述了一个单一的功能或业务过程。
关系：关系描述了参与者与用例之间的交互，包括关联（Association）、泛化（Generalization）和依赖（Dependency）等。
在构建用例模型时，通常首先识别参与者，然后确定系统的功能需求，为每个功能需求创建一个用例。
接着，通过添加关系来描述参与者与用例之间的交互。
用例模型的主要目的是帮助开发人员理解系统的功能需求和行为，以便更好地设计和实现系统。
通过用例模型，开发人员可以更好地理解系统的边界、参与者与系统的交互以及系统的功能需求，从而更好地进行系统设计和开发。
用例建模目标
用例建模目标
用例建模的目标是描述系统的功能需求，通过使用用例图、用例描述和用例之间的关系来定义系统的行为和功能。
具体来说，用例建模的目的是：
1. 确定系统的功能需求：通过分析业务场景和角色与系统的交互，识别系统的功能需求。
2. 描述系统的行为：用例描述了系统在特定场景下的行为，包括前置条件、后置条件和系统与角色的交互等。
3. 定义系统边界：用例建模可以帮助确定系统的边界，明确系统与外部实体（如用户、其他系统等）的交互。
4. 建立需求基线：通过用例建模，可以建立一个清晰的需求基线，为后续的开发和测试提供依据。
5. 沟通工具：用例建模使用图形化的方式描述系统功能，便于开发人员、测试人员和业务分析师等不同角色之间的沟通。
6. 评估和验证：通过评估用例的完整性、正确性和可行性，确保系统功能需求的准确性和完整性。
7. 驱动开发：用例可以作为开发过程中的重要输入，指导开发人员实现系统的功能。
8. 测试依据：测试人员可以根据用例编写测试用例，确保系统功能的正确性和可靠性。
总之，用例建模是一种有效的需求工程方法，可以帮助团队更好地理解和管理系统需求，确保开发出符合业务需求的软件产品。
用例建模
10 1-10
ATM例子 寻找参与者 – ATM例子
1）如果我们所要定义的系统边界仅限于ATM机本身， 如果我们所要定义的系统边界仅限于ATM机本身， ATM机本身 那么后台服务器就是一个外部的系统， 那么后台服务器就是一个外部的系统，可以抽象为一个 参与者。 参与者。
2）如果我们所要定义的系统边界扩大至整个银行系统， 如果我们所要定义的系统边界扩大至整个银行系统， ATM机和后台服务器都是整个银行系统的一部分 机和后台服务器都是整个银行系统的一部分， ATM机和后台服务器都是整个银行系统的一部分，这时 候后台服务器就不再被抽象成为一个参与者。 候后台服务器就不再被抽象成为一个参与者。
17 1-17
使用角色和用例图组织你的用例
用例图是在一个图上显示了多个用例, 用例图是在一个图上显示了多个用例 它是一组用例的 全景图. 有时候角色我们称呼为用户,但是常常会指定一 全景图 有时候角色我们称呼为用户 但是常常会指定一 个具体的角色名称(比如 顾客).用户或者说角色位于系 比如:顾客 个具体的角色名称 比如 顾客 用户或者说角色位于系 统边界之外. 而系统在边界内. 统边界之外 而系统在边界内 角色也可以指非人类的外 部系统,但有时候许多人对这一点迷惑不解 但有时候许多人对这一点迷惑不解,我们已经发 部系统 但有时候许多人对这一点迷惑不解 我们已经发 现使用机器人这种图标可以消除这种迷惑误解. 现使用机器人这种图标可以消除这种迷惑误解 在用例和角色之间的连线表示这个角色是用例的执行者. 在用例和角色之间的连线表示这个角色是用例的执行者 这根连线也表示责任.比如 一个Customer(顾客 指向用 比如:一个 顾客)指向用 这根连线也表示责任 比如 一个 顾客 表示这个顾客负责执行check out(结帐 结帐) 例check out,表示这个顾客负责执行 表示这个顾客负责执行 结帐 可以有多个角色指向同一个用例.表示这个用例与多个 可以有多个角色指向同一个用例 表示这个用例与多个 角色关联.同样的 一个用户可以拥有多个角色.同一个用 同样的,一个用户可以拥有多个角色 角色关联 同样的 一个用户可以拥有多个角色 同一个用 户可以是一个职员,也可能是一个管理员 也可能是一个管理员. 户可以是一个职员 也可能是一个管理员
用例建模法
用例建模法
用例建模是一种分析和设计软件系统的方法，它将系统看作一系列用例，每个用例描述了系统与用户之间的一个交互场景。
用例建模的步骤如下：
1. 确定系统的边界和参与者：确定系统与外部世界的交互范围，并确定参与系统的各种角色。
2. 鉴别用例：识别系统中的主要功能点和用户需求，每个功能点对应一个用例。
3. 描述用例：详细描述每个用例的功能特点，包括前置条件、主要场景、预置条件、异常场景等。
4. 绘制用例图：用例图是用例建模的核心图。
它通过图形的方式展示出各个用例之间的关系，包括参与者、用例和它们之间的关联关系。
5. 完善用例：根据需求分析的结果，不断完善用例的描述，使其更加准确和完整。
通过用例建模，可以清楚地了解系统的功能需求，识别系统中的主要功能点，帮助系统分析师和设计师更好地理解系统的需求，从而设计出更好的系统。
同时，用例建模也可以帮助开发人员和测试人员更好地理解系统的功能点，从而更好地开发和测试系统。
面向对象分析与设计(3)-用例建模
有些备选事件流将返回到基本事件流，而有些将结束
此用例的执行
2021/4/17
35
基本流
❖ 基本流描述的是该用例最正常的一种场景，在基本流中系统执行一 系列活动步骤来响应参与者提出的服务请求。
3.用户选择准备购买的图书，并加入购物车。系统 记录已加入购物车的图书并计算价格。
4.用户准备结账，系统提示确认购物清单，并提示 输入银行账号、送货地址等关键信息。
5.用户输入以上信息，并确认。系统完成交易，并 显示交易信息。用例结束。
以用例的方式定义需求处处关心用户
2021/4/17
到底想用系统做什么，如何做
❖ 这种参与者与系统功能特性间的交互关系就 是我们所说的“用例”
2021/4/17
14
用例建模的特点
❖ 显式地表达用户的任务目标层次，突出系 统行为与用户利益间的关系；
❖ 通过描述执行实例情节（交互行为序列、 正常/非正常事件流）能够完整地反映软件 系统用以支持特定功能的行为；
❖ 以契约（前/后置条件等）的形式突出了用 户和系统之间常常被忽略的背后的关系；
2021/4/17
33
流程四：用例规约详述
❖ 用例名字（Name）
❖ 简要说明（Brief description）
❖ 事件流（Flows of Events）
❖ 特殊需求（Special requirements）
❖ 前置条件（Pre-conditions）
▪ 开始用例前所必需的系统及其环境的状态
▪ 起始于参与者的输入 ．其中，系统是一个黑盒 ▪ 用于描述系统行为，但不描述如何实现
❖ 识别用例时需要注意
▪ 用例的粒度不要太大也不要太小 ▪ 用例描述的是系统做什么，初始识别用例的时候不要
用例建模
38
与系统交互的Actor
Registrar Professor
Student Billing System
39
寻找用例
• Actors的行为决定了他们的需求
– – – – 注册管理员：管理和维护课程表 教师：请求学生名单 学生：维护自己的课程安排 计费系统：从注册系统获取费用信息
Maintain Curriculum
27
功能：
订票
1. 2. 3. 4.
传输/接收 电源/基站 输入输出（显示、键盘） 电话簿管理
顾客 查询车次 用户观点
。。。。。。
用例：
1. 2. 3. 4. 呼叫某人 接听电话 发送短消息 记住电话号码
顾客
处理订票
显示车次 系统观点
。。。。。。
28
！！！在用例描述中不要包 含GUI设计，因为用例是针对 需求的，而界面设计是“设 计”，不要把设计的东西放 进需求里。
A T M 取 款 用 例 描 述
1, 储户插卡；
2. ATM机提示输入用户口令； 3.储户输入口令； 4.ATM机口令验证通过，提示输入钱数； 5.储户输入钱数； 6.ATM机进行钱数有效性检查，提示操作成功，吐出 卡和钱；
24
7.储户取走卡和钱；
8.ATM机屏幕恢复为初始状态。 扩展点 4a. ATM机验证用户口令不通过 4a1. ATM机给出提示信息，并吐出信用卡； 4a2. 储户取出卡； 4a3. ATM机屏幕恢复为初始状态.
30
顾客
<<extend>>
签订汽车购买合同
签订保险单
顾客
<<extend>>
下载软件
用例建模 用例规约
用例建模用例规约标题：点外卖系统用例建模与规范引言：随着互联网技术的快速发展，外卖行业迅猛壮大，点外卖已经成为人们日常生活中的一部分。
为了提高用户体验和系统效率，点外卖系统开发成为了一项重要的任务。
本文将通过用例建模与规约的方式，详细描述了点外卖系统的各个功能以及系统与用户之间的交互过程，旨在帮助开发团队和用户更好地理解和操作该系统。
一、用例建模1. 用户注册与登录- 用例名称：用户注册- 用例描述：用户需要提供个人信息进行注册，包括用户名、密码、手机号等，系统验证信息合法性后完成注册。
- 前置条件：用户打开点外卖系统，未登录状态。
- 后置条件：用户成功注册并登录系统，可进行下一步操作。
- 主要参与者：用户、系统。
- 触发事件：用户点击注册按钮。
- 用例步骤：1) 用户选择注册功能。
2) 用户填写个人信息并提交。
3) 系统验证信息合法性。
4) 系统生成唯一标识符并存储用户信息。
5) 系统自动登录用户。
2. 点餐与支付- 用例名称：用户点餐与支付- 用例描述：用户选择餐厅、浏览菜单、添加菜品到购物车，并进行支付操作。
- 前置条件：用户已注册并登录系统，进入特定餐厅界面。
- 后置条件：用户完成支付，生成订单，并进行配送。
- 主要参与者：用户、系统、餐厅。
- 触发事件：用户点击某个餐厅进入。
- 用例步骤：1) 用户选择特定餐厅。
2) 用户浏览菜单并添加菜品到购物车。
3) 用户选择支付方式并完成支付。
4) 系统生成订单，并通知餐厅。
5) 餐厅确认订单，并进行配送。
二、用例规约1. 用户注册规约- 前置条件：无。
- 后置条件：用户成功注册并登录系统。
- 基本流程：1) 用户打开点外卖系统，点击注册按钮。
2) 用户填写用户名、密码、手机号等个人信息并提交。
3) 系统验证信息合法性。
4) 如果验证通过，系统生成唯一标识符并存储用户信息，自动登录用户。
5) 如果验证失败，系统返回错误信息，用户重新填写信息。
- 异常流程：- 用户输入的用户名已被注册：系统返回错误信息，提示用户换一个用户名。
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
参与者需要系统中获取哪些功能。即参与者要系统“做什么”。
参与者是否需要读取，产生，删除，修改或存储系统中的某种信息。
系统的状态改变时，是否通知参与者。
是否存在影响系统的外部事件。
系统需要什么样的输入，输出信息。
（2）用例在确定时需要注意的问题：
用例图中每个用例都必须有一个唯一的名字以区分其他用例。
每个用例的执行都独立于其他用例。
用例表示系统中所有对外部用户可见的行为。
用例不同于操作，用例可以在执行过程中持续接受或持续输出与参与者
交互的信息
2.用例描述通常有以下几个属性：
用例名称：每个用例都有唯一的用例名称每个用例名称只针对唯一的用例。
编号或标识符：对用例的唯一识别标识，可以使用字母或数字，可以省
谁来安装，维护和管理系统，保证系统正常运行。
系统控制的硬件设备有哪些。
系统需要与哪些其他系统进行交互。
在预定的时刻，是否有事件自动发生。
系统是否需要定期产生事件或结果。
系统如何获取信息。
二、实验过程记录：
图书管理系统用例图
对于图书管理系统，通过系统的分析我们可以得出该系统的功能可分为书
籍信息管理，借阅管理，管理员管理和读者管理等。可得参与者有图书信息管
管理员登录系统并管理书籍节约归还和统计书籍受损情况的功能；后台管理功
能；后台维护功能。
在借阅图书用例中，对其细化描述：图书管理员输入借书证信息；系统确
保读者的借书证有效；系统计算读者所借阅的图书数量是否超过规定数量；检
查读者是否有超期的借阅信息；图书管理员输入读者所借阅的图书信息；生成
新的借阅信息并保存；系统显示读者的所有借阅的图书信息；在归还图书用例
****实验报告
课程名称：软件建模与分析项目名称：用例建模
姓名：***专业：计算机科学与技术班级：*班
学号：*******同组成员：无
一、实验准备：
实验环境：Windows8 Visio 2012
实验目的：掌握识别执行者和用例方法，掌握用例的描述格式，掌握利用建模
工具建立用例模型的方法。
实验所需知识点：
1.用例的识别：识别用例的最好方法是从参与者来分析。用例图是从系统
的用户来描述系统的，而用例则是从参与者的角色来描述系统功能的。识别用
例需要考虑每一个参与者如何与系统进行交互，以及系统对每个事件的响应。
用例模型的识别是一个迭代过程。
（1）参考参与者的识别方法，建模者从参与者的角度出发，制定了以下几个
理员，图书借阅管理员，系统管理员，读者和短信提醒系统这5个参与者中。
根据得出的参与者可以分析出四个系统用例图：借阅系统用例图，系统后台用
例图，读者信息管理系统和图书信息管理系统。通过对用例的分析，可以得出
系统拥有的功能。系统拥有如下功能：读者登录查阅信息的功能；系统短信提
醒功能；图书信息管理员登录系统并进行图书信息维护的功能；图书借阅功能；
的细化描述：图书管理员输入图书信息；系统检阅图书的有效性；系统将根据
该图书的信息查找阅读信息；系统根据借阅信息获取借阅者信息；查找借阅者
是否有超期借阅信息；删除与该图书对应的借阅信息；保存更新后的借阅信息；系统显示读者还书后所剩余的所有借阅信息；审查记录图书损坏程度。
系统用例图如下：
二、实验小结：
通过本次实验我对识别执行者和用例的方法有了一定的掌握。通过这次
可以省略。
分支流：基本流程同时作用与多个方面时各个方面的流程，可以省略。
分支流相关流：分支流在条件改变，出现异常等情况下的流程，可以省
略。
扩展点：流程中可能发生的其他情况，可以省略。
变异点：流程被中断的情况，可以省略。
3.参与者的确定：
（1）参与者的确定需要借助以下几个问题：
系统的主要客户是谁。
谁需要借助系统完成日常工作。
略。
用例简述：对用例的简单介绍，可以省略。
参与者：与用例关联的参与者，可以省略。
状态：用例的状态，可以省略。
前置条件：系统执行该用例的条件，若条件不满足，用例将不会被启动。
后置条件：用例执行后系统的状态。
扩充条件：其他条件，可以省略。
基本流程：系统执行用例时具体的操作流程。
基本流程相关流程：基本流程在条件改变，出现异常等情况下的流程，
的实验，让我能够认真地分析系统所要完成的功能。通过之前学习的知识找
到参与者，关系及用例。了解到了用例图的相关知识点，从之前的不理解到
后来的理解，对我来说是一个很好的进步。
实验报告成绩（百分制）__________实验指导教师签字：__________