用例建模系统需求
UML网络教学系统—
（3）系统管理员参与者的用例图 另外网站需要一个专门的管理者进行日常 维护与管理，所以需要有系统管理员的参 与。
Page MainTenance
CAI Process
Administrator
Information Update
Process Registration
• 说明： • 页面维护（Page Maintenance）：系统管理员可以对网站进行日常 维护与管理。 • 处理注册申请（Process Registration）：系统管理员可以处理学生或 教师用户的注册申请。 • CAI Process用例：教师上传的课件经过系统管理员的审批和处理 • 页面更新（Information Update）：系统管理员负责网站的页面更新， 除了文章，消息，图片等的更新，还包括页面的美化和板块的调整。
Look throgh info Student
Artical seach
• 说明： • 文章浏览用例（Look through info）:学生可以浏览诸如课程简介，教学 计划，学习方法等教师发布的文章。 • 文章搜索用例（Article search）:学生可以使用搜索功能根据关键字查询 相应的文章。 • 文章下载用例（Download）:学生可以使用下载功能将网站上的课件以 及资料信息下载到本地机器上。 • 权限认证用例（Identify）：此用例用来认证文件下载是否具有下载文件 的权限。
谢谢观赏
报告人： 报告人：马靖 班级： 班级：软件工程 学号： 学号：0950312005
（2）教师参与者的用例图 教师作为教学的主导者，使用此网站可以 发布学习方法，课程重点等和教学相关的 文章，以及和课程相关的通知等，还可以 将某一门课程的课件上传。
如何利用UML用例图描述软件系统的需求
因明
（4）参与者之间的主要关系---泛化（继承）关系
泛化或者继 承
（5）所要注意的问题
（6）如何获 得系统中的 参与者
5、用例模型中的用例（UseCase） （1）用例及其定义—某种特定的功能
（2）用例的分类——业务用例 描述一个业务的流程以及它们与外部各方(如客户和合 作伙伴)之间的交互 代表系统中需要提供的核心功能：如报表数据汇总计算 （3）用例的分类——系统用例 系统既定功能及系统环境的模型，描述且仅仅描述系 统的功能 系统提供的附加其它功能或者服务：如报表打印
Abstract use case – use case that reduces redundancy in two or more other use cases by combining common steps found in both.
（3）用例的横向方面的联系---扩展关联（Extension use case）
2、可以采用UML中的用例模型（用例图）方法 利用用例（Use Case）和用例图、需求文档来确定系 统的高层逻辑视图。
3、用例模型中的基本组成部件
用例最初由Ivar Jackboson博士提出，后被综合 到UML规范之中，成为需求表述的标准化体系。 Ivar Jacobson博士与Grady Booch和James Rumbaugh一道共同创建了UML建模语言，被业界誉 为UML之父。
（2）主要的特性
UML 由图和元模型组成，图是语法，而元模型则给出图的 意思，是UML的语义 它提供了描述软件系统模型的概念，同时由于它采用面向 对象的技术、方法，它的作用域不限于支持面向对象的分 析与设计,还支持从需求分析开始的软件开发的全过程。
（ 3 ）它是编制软件蓝图的标准化语言 ---- 是标准的建模 语言
UML实例UML案例(完整建模)(汽车租赁系统)
theWorkRecord : WorkRecord
系统的状态图
系统的活动图
customer request Employee check the request no new request store the request have new request handle new request
Manager Interface
Skill Worker
系统功能需求
① ② ③ ④ 满足上述需求的系统主要包括以下模块： 基本数据维护模块 基本业务模块 数据库管理模块 信息查询模块
基本数据维护模块
① ② ③ ④ 基本数据维护模块包括的主要功能模块： 添加车辆信息 修改车辆信息 添加员工信息 修改员工数据
基本业务模块
① ② ③ ④ 基本业务模块包含的功能： 用户填写预定申请 工作人员处理预定请求 技术人员填写服务记录 工作人员处理还车
建立UML模型框架
选择J2EE模式
系统的用例图
① ② 创建用例图之前首先需要确定参与者。 系统中的参与者主要有两类： 客户 公司职员
系统的用例图
1. 客户参与的用例图 2. 公司职员参与的用例图
客户参与的用例图
公司职员参与的用例图
系统的时序图
1. 2. 3. 4. 管理人员开展工作的时序图 客户预订车辆的时序图 客户取车的时序图 客户还车的时序图
数据库模块
① ② ③ ④ 数据库模块的功能： 客户信息管理 车辆信息管理 租赁信息管理 职员信息管理
信息查询模块
① ② ③ ④
信息查询模块是查询数据库中的相关信息， 包括： 查询客户信息 查询职员信息 查询车辆信息 查询客户记录
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
基于UML火车票网上售票系统的设计
基于UML火车票网上售票系统的设计火车票网上售票系统是一个基于UML（统一建模语言）的设计，用于方便用户在网上购买火车票。
下面将从系统需求、用例建模、类图设计和时序图设计等方面进行阐述。
1.系统需求规定：1.1用户注册登录：用户可以通过注册账号进行登录1.2查询车次信息：用户可以根据出发地、目的地和日期等条件查询火车票信息1.3购买车票：用户可以选择火车票并进行购买1.4订单管理：用户可以查看已购买的火车票订单，并进行管理1.5确认支付：用户需要确认订单并支付购买的火车票1.6退改签：用户可以选择进行火车票的退改签操作1.7管理员功能：管理员可以对系统进行管理，如添加车次信息、删除车次信息等2.用例建模：2.1用户注册登录用例：-用户输入账号和密码进行注册-用户输入账号和密码进行登录2.2查询车次信息用例：-用户输入出发地、目的地和日期等条件进行查询-用户查看查询结果2.3购买车票用例：-用户选择火车票并添加到购物车-用户确认购买并进行支付2.4订单管理用例：-用户查看已购买的火车票订单列表-用户选择订单进行管理，如退改签操作等2.5退改签用例：-用户选择订单进行退改签操作-用户支付差价（如有）2.6管理员功能用例：-管理员添加车次信息-管理员删除车次信息3.类图设计：3.1 用户类（User）：-属性：账号、密码、订单列表-方法：注册、登录、查询车次信息、购买车票、订单管理、退改签3.2 车次信息类（TrainInfo）：-属性：车次号、出发地、目的地、日期、余票数量-方法：查询车次信息3.3 火车票类（Ticket）：-属性：车次号、座位号、购买用户、购买日期、价格-方法：购买、退票、改签3.4 订单类（Order）：-属性：订单号、购票用户、购买日期、车票列表-方法：支付、取消3.5 管理员类（Admin）：-属性：账号、密码-方法：添加车次信息、删除车次信息4.时序图设计：-用户查询车次信息时序图：用户->系统:输入出发地、目的地和日期等条件系统->数据库:查询车次信息数据库->系统:返回查询结果系统->用户:显示查询结果-用户购买车票时序图：用户->系统:选择火车票进行购买系统->数据库:扣减余票数量数据库->系统:返回购买结果系统->用户:显示购买结果用户->系统:确认支付系统->用户:生成订单并显示支付结果通过上述的需求规定、用例建模、类图设计和时序图设计，可以实现一个基于UML的火车票网上售票系统，方便用户进行火车票的查询、购买和管理，同时还提供了管理员功能以便对系统进行管理。
03-系统需求建模-事件和事物
l
图形模型：描述系统的图表或系统某些方面的示 意性表示
8
１．３ 用于分析和设计的模型
分析阶段创建的模型
l l
设计阶段创建的模型
l l l l l l l l l l
事件列表 事物列表 基于UML的OO方法
l l l l l l
体系结构图 界面布局图 系统结构图 程序流程图 设计类图 时序图 包图 组件图 网络图 部署图 9
u
关联实体 – 解决上述问题的人为增加的数据实体，它
一定包含两端数据实体的关键字
33
５ 类图
u u u
面向对象的方法也强调对系统中所包含事物的理解 面向对象的方法给事物建立的模型即是“类图” “类”和“实体”是明显区别的
34
５ 类图
5.1 有关对象类的更复杂的问题
u
泛化／具体层次图 – 把类按照从最概括的父类到
３ 事物和系统需求
3.4事物的属性
属性：有关事物的一条特定信息 标示符（关键字）：能唯一标志事物的一个属性 复合属性：包括了许多相关属性的属性，如客户全名：名＋姓
所有客户具有如下属性 客户编号 名 姓 住宅电话 公司电话
每个客户的每个属性都有一个值 １０１ １０２ １０３ Ｊｏｈｎ Ｓｍｉｔｈ ５５５－９１８２ ５５５－３４２５ Ｍａｒｙ Ｊｏｎｅｓ ４２３－１２９８ ４２３－３４１９ Ｂｉｌｌ Ｃａｓｐｅｒ ８７４－１２９７
事件分三大类：外部事件、临时事件、状态事件
l 外部事件：系统之外发生的事件，通常是由外部实体或
系统参与者触发的
l 临时事件：由于到达某一时刻所发生的事件 l 状态事件：当系统内部发生了需要处理的情况时所引发
的事件
12
２．１ 事件的类型
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
需求建模的常用方法
需求建模的常用方法
需求建模是软件开发过程中非常重要的一环，它的作用是帮助开发团队更加清晰地了解用户需求，并将这些需求转化为可行的软件功能。
在实际的需求建模中，有许多常用的方法，下面就简单介绍一些常用的方法：
1. 用例建模
用例建模是一种基于场景的方法，它主要通过描述系统和用户之间的交互来帮助开发团队理解用户需求。
在用例建模中，我们通常会将用户的需求描述为一个个场景，然后通过建立用例图、流程图等方式来对这些场景进行描述和分析。
2. 面向对象建模
面向对象建模是一种比较常用的需求建模方法，它通常会将系统中的各个对象进行抽象，然后通过建立类图、时序图等方式来描述这些对象之间的关系和交互。
3. 数据流建模
数据流建模主要是从数据流的角度来分析系统的需求，它将整个系统看作一个数据流的传递过程，然后通过建立数据流图、数据字典等方式来描述数据流的传递过程和数据的属性。
4. 状态转换建模
状态转换建模通常会关注系统的状态变化和状态之间的转换，它通过建立状态图、状态转换表等方式来描述系统的状态变化和状态之间的转换。
总的来说，需求建模的方法还有很多，每种方法都有其独特的优劣和适用范围，因此在实际的需求建模过程中，开发团队应该根据具体的项目需求选择合适的方法来进行建模。
常用系统建模方法
常用系统建模方法系统建模是指对一个系统进行抽象和描述，以便更好地理解和分析系统的结构、行为和功能。
在系统建模中，有许多常用的方法和技术，本文将介绍其中几种常见的系统建模方法。
1. 信息流图（Data Flow Diagram，简称DFD）是一种用于描述系统功能的图形工具。
它通过将系统的各个模块和数据流之间的关系绘制成图表，清晰地显示了数据输入、处理和输出的过程。
DFD是一种简单直观的建模方法，适用于初步了解系统需求和功能的描述。
3. 状态转换图（State Transition Diagram，简称STD）是一种用于描述系统的状态和状态之间转换的图形工具。
它通过绘制系统的状态和状态之间的转换关系，清晰地显示了系统在不同状态下的行为和过程。
STD适用于描述系统中的状态机，是一种常用的建模方法，尤其适用于软件系统的行为建模。
4. 用例图（Use Case Diagram）是一种用于描述系统需求和功能的图形工具。
它通过绘制系统的参与者和用例之间的关系图，清晰地显示了系统的功能和用户之间的交互。
用例图适用于描述系统的功能需求，是一种常用的需求建模方法，常用于需求分析和系统设计中。
5. 结构图（Structure Chart）是一种用于描述软件系统模块和子程序之间的关系的图形工具。
它通过绘制系统的模块和模块之间的调用关系，清晰地显示了系统的结构和模块之间的依赖关系。
结构图适用于描述系统的模块组织和子程序调用，是一种常用的软件设计和实现建模方法。
除了上述常用的系统建模方法外，还有许多其他的建模方法和技术，如层次分析法、Petri网、数据流程图、活动图等等。
不同的建模方法适用于不同的系统和需求，可以根据具体情况选择合适的方法进行建模。
系统建模的目的是为了更好地理解和分析系统，从而进行系统设计、实现和优化，提高系统的可靠性、性能和效率。
软件工程之系统建模篇【设计用例模型】
软件⼯程之系统建模篇【设计⽤例模型】本⽂主要介绍⽤例模型的设计过程，⾸先从系统层设计⽤例模型，然后分别细化系统层识别的各⽤例，设计更为详细的⽤例模型。
⽤例模型是开发过程的起点，并驱动建模全过程。
以下以办公⾃动化（OA）中的办理发⽂⽤例模型为例，来讲解⽤例模型的设计过程。
⽤例模型包括办理公⽂⽤例图及⽤例描述。
办理发⽂⽤例模型 1、办理公⽂⽤例图 在设计办理发⽂⽤例模型之前，先要识别活动者和⽤例，活动者和⽤例识别以后，才能建⽴⽤例模型。
1.1 活动者识别 活动者是系统分析员与⽤户交流的起点，也是项⽬获得后续产品的关键。
活动者可以是使⽤系统功能的⼈，也可以是软件系统和硬件设备，凡是与系统进⾏信息交换的外部实物，都可以归为系统的活动者。
系统分析员与系统⽤户深⼊交流后，明确系统范围，系统功能和外部关联的事物。
识别活动者需要往复多次，可以通过向⽤户询问类识别活动者。
如：谁/什么对系统运⾏的结果感兴趣，会改变系统中的数据，从系统中获取信息，与系统交互。
通过对具备这些需求的⽤户进⼀步分析，即可识别系统活动者。
1.2 识别过程 与系统发⽣交互的外部实体有草拟⼈、审核⼈、复核⼈、签发⼈和分发⼈。
草拟⼈可识别为发⽂草拟⼈，审核⼈可设别为发⽂审核⼈、复核⼈可识别为发⽂复核⼈，签发⼈⼀般由相关领导担任，可识别为发⽂签发⼈，分发⼈可识别为分发⼈。
1.3 ⽤例识别 发⽂草拟⼈新拟发⽂编辑发⽂并保存在系统中 新拟发⽂⽤例 发⽂草拟⼈修改发⽂修改发⽂并保存所做操作 修改发⽂⽤例 发⽂审核⼈审核发⽂编辑审核意见并保存在系统中 审核发⽂⽤例 发⽂复核⼈复核发⽂编辑复核意见并保存在系统中 复核发⽂⽤例 发⽂签发⼈签发发⽂编辑签发意见并保存在系统中 签发发⽂⽤例 分发⼈ 分发发⽂对分发进⾏登记并保存在系统中 分发发⽂⽤例 发⽂草拟⼈送档案室 将发⽂转⼊档案室 送发⽂⾄档案室⽤例 1.4 ⽤例图 2、⽤例描述 2.1 新拟发⽂ ⽤例⽬标：当发⽂草拟⼈新拟⼀份发⽂时⽤例开始。
企业综合信息管理系统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 游客用例- 浏览商品：游客可以浏览系统中的商品列表，查看商品的基本信息和价格。
- 搜索商品：游客可以根据关键词搜索系统中的商品，系统会返回符合条件的商品列表。
- 查看商品详情：游客可以查看具体商品的详细信息，包括商品介绍、规格、用户评价等。
用例图建模流程
用例图建模流程
用例图建模是一种描绘系统功能需求的有效方式，其基本流程如下：
1. 确定参与者：识别系统外部所有与系统交互的实体，如用户、硬件设备或其他系统，定义为参与者。
2. 描述用例：列举系统应提供的各项主要功能，每个功能视为一个用例，描述其目的、前置条件、基本流程和可能的扩展流程。
3. 建立关系：在用例图中绘制参与者和用例，使用关联线连接参与者和他们所使用的用例，表示参与者与用例之间的交互关系。
4. 标注扩展和包含关系：若某个用例的行为可以根据特定条件变化或包含其他用例的行为，标注扩展（extend）和包含（include）关系。
5. 完善细节：添加必要的注释说明，细化用例描述，完善用例图，确保其准确反映系统功能需求。
UML用例图详解
二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是 UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
2．用例描述用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
基于用例模型的产品协同开发系统需求建模研究
（ｃｏｌ ｆ ｎｇｍ ｎ， ｈｎＵ ｉ ｒ ｔ ｏ ｅｈ ｏ ｇ ， ｈｎ４ ０ ７ ， ｈｎ） Ｓｈｏ ｏ ａｅ ｅ ｔＷｕ ａ ｎｖ ｓｙ ｆ ｃｎ ｌ ｙ Ｗｕ ａ ３ ００ Ｃ ｉａ Ｍａ ｅ ｉ Ｔ ｏ 摘 要 ： 例模 型通 过 用例 、 与 者 以及 它们 之 间 的关 系来 描 绘 系统 应 该 具 有 的 功 能 集 简单 介 绍 了用例 模 型及 其 基本 要 用 参 素 。通 过 产 品协 同开 发 系统 的 开发 实践 ， 参 与 者 、 倒 、 从 用 用例 图以及 用例 规 约 四 方 面 ， 开 发人 员和 用 户都 对 产 品 开发 系统 有 使 了总 体性 的认 识 和 把 握 ． 充分 体 现 了 用例 分 析 技 术 有 助 于提 高 需 求 分 析 效 率 和 质 量 的特 点 ． 为 建 立 一 个 柔 性 的 产品 开发 系 并
互协 同 ． 也使 产品开发系统更加复杂 ． 因此如何 提高研 发生产率 、 企业问如何协同将是亟待解决 的关键 问题 而在计算机应用发展飞速的今天 ．企业 不仅应 提高产
品核 心 生 产 技 术 水 平 ．还 应 建 立 一 个 更 具 柔 性 的产 品 协 同开 发 系统 。对 产 品协 同开 发 全 过 程 进 行 全 面 的管 理 。 而 来 提 高 产 品 研 发 生 产率 从 企 业 的 产 品协 同开 发 系统 ．是 ～ 个 非 常 复 杂 的 系
维普资讯
Ｖ ｌｅＥ ｇｎｅ ｎ ｏ１ ， ０ ａｕ ｎｉｅｒ ｇＮ ．０ ０ ７ ｉ ２
价值 工程 ２０ ０ ７年第 １ Ｏ期
基 于用例 模 型 的产 品协 同开发 系统 需 求建 模 研 究
Ｔｏ Ｓ ｕ ｙ ｏ ｒ ｄ ｃ ｏ ｅ ａ ｉ ｎ Ｄｅ ｅｏ ｍ ｅ ｔＳ ｓｅ ｔ ｄ ｎ Ｐ ｏ ｕ ｔＣｏ ｐ ｒ ｔ ｖ ｌ ｐ ｎ ｙ ｔ ｍ ｏ
需求分析与用例模型
第3章 需求分析与用例模型
在统一过程（UP）中，需求按照“FURPS”模型进行分类。
➢ 功能性（Functional）：特性、功能、安全性；
➢ 可用性（Usability）：人性化因素、帮助、文档；
非
➢ 可靠性（Reliability）：故障频率、可恢复性、可预测
功 能
性；
性
➢ 性能（Performance）：响应时间、吞吐量、准确性、有
用例之间的各种关系
3.包含关系 ➢包含关系描述的是一个用例需要某种功能，而该功能被另外一个 用例定义，那么在用例的执行过程中，就可以调用已经定义好的用 例。 ➢在UML中，用例之间的包含关系含有关键字<<include>>的带有箭 头的虚线表示。
3.包含关系
3.包含关系
3.包含关系
3.包含关系
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
事件流
➢ 说明用例如何开始和结束。只说明属于该用例的事件， 而不是发生在其他用例中或系统外部的事件。
➢ 避免不明确的术语，如“例如”、“等等”和“信息”
事件流
➢ 在事件流里要对事件流进行结构化说明 基本事件流 • 描述每个情节的行为者:目标语句对的顺序 • 假设之前的每一步都是成功的 备选事件流 • 异常情况
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使用用例建模系统需求:•介绍用例建模的优点.•定义参与者和用例.•描述用例模型图中可能出现的关系.•介绍使用用例模型图的步骤•介绍用例的详细内容An Introduction toUse-Case Modeling•对于信息系统开发来说，最主要的挑战是能够从关联人员那里提取出正确的确实需要的系统需求，并以关联人员可以理解的方式进行说明，以便需求可以得到证实和验证。
•构建一个软件系统最困难的部分是正确地确定要构建什么。
Fred BrooksUser-centered development–重点是理解关联人员的需求。
Use-case modeling–使用业务事件（business events ）、发起事件的人（actor），以及系统如何响应这些事件（system responds to those events）。
来建模系统功能的过程。
•用例建模来源于面向对象建模技术，但该技术在非对象开发方法中也比较流行，因为它被广泛认为是定义、记录和理解信息系统功能需求的最佳实践。
Benefits of Use-Case Modeling•提供了一个捕捉用户需求的工具•将系统分解成更易于理解（掌控）的小块•提供了与用户及其它关联人员进行交流的工具•提供了确定、分配、跟踪、控制和管理系统开发活动（尤其是增量和迭代开发）的手段•为定义测试计划和测试用例提供基础Benefits of Use-Case Modeling (continued)•为用户文档和系统开发文档提供基准•提供了需求跟踪的工具•提供确定数据对象和实体的起点•提供了用户和系统接口的说明•提供了驱动系统开发的一个框架Use case– a behaviorally related sequence of steps (scenario), both automated and manual, for the purpose of completing a single business task.用例是一系列行为上相关的步骤（场景），既可以是自动的也可以是手工的，其目的是完成一个单一的业务任务。
包括两部分：Use-case diagram：用例图Use-case narrative：用例描述Use case– subset of the overall system functionality•一个用例所描述的场景可能包含一个或多个需求Actor– anyone or anything that needs to interact with the system to exchange information.•human, organization, another information system,external device, even time.Temporal event– a system event triggered by time.•The actor is time.Association–a relationship between an actor and a use case in which an interaction occurs between them.•有箭头的表示参与者发起用例. (1)•Association lacking arrowhead indicates a receiver actor. (2)没箭头的表示参与者是接受者•关联关系可以使双向或单向的Use Case Extends Relationship（扩展关系）Extension use case–一个用例可能包含多个步骤的复杂功能，使得用例难以理解。
为了简化，将较复杂的步骤提取成专门用例，成为扩展用例，它与原用例间是扩展关系。
•一个用例可有多个扩展用例，扩展用例不能被其他用例调用•Labeled <<extends>>.Use Case Uses Relationship使用（包含）关系Abstract use case–多个用例包含相同的功能步骤，把公共步骤提取成抽象用例，代表某种形式的“复用”●抽象用例可以被其它用例调用●箭头指向抽象用例●Labeled <<uses>>Use Case Depends On Relationship（依赖关系）Depends On–use case relationship that specifies which other use cases must be performed before the current use case.•决定用例开发的顺序•Labeled<<depends on>>Use Case Inheritance Relationship(继承关系)Inheritance–当多个参与者共享同样的行为时（发起先同的用例），可以将这些公共行为分配给一个新的抽象参与者，减少与系统的通信。
•其它参与者可以继承此抽象参与者。
需求用例建模过程—P173•构造需求用例的目的是提取和分析需求信息，模型表示用户需要什么，不涉及如何构造和实现•Steps1.Identify business actors.2.Identify business use cases.3.Construct use-case model diagram.4.Documents business requirements use-case narratives.•如何发现actors？•Who or what provides inputs to the system?•Who or what receives outputs from the system?•Are interfaces required to other systems?•是否存在预定时间自动触发的事件?•谁维护系统中的信息?•使用名词或名词词组命名参与者（Actors）Step 2: Identify Business Requirements Use CasesBusiness Requirements Use Case - a use case created during requirements analysis to capture the interactions between a user and the system free of technology and implementation details.•一个系统可能包含许多用例，在需求分析阶段，出于时间和经费的考虑，我们仅粗略关注最关键、最复杂的用例，常称为基本用例（Essential Use Case）•When looking for use cases, ask the following questions:•Actor的主要任务是什么?•What information does the actor need form the system?•What information does the actor provide to the system?•系统需要通知actor发生的变化和事件吗?•Actor需要通知系统发生地变化和事件吗?•Use cases 通常使用动词词组命名(i.e. 提交订单)Step 3: 构建用例模型图(Use Case Diagram)Step 4: 记录业务用例需求描述（Use-Case Narratives)•首先在高层（high level）记录，以便尽快理解系统的事件和量级•然后回到每个用例，扩展它，详细记录业务需求描述。
Use Cases and Project Management•Use-case model 可以驱动整个系统开发过程•完成需求用例后，项目经理和系统分析员可以用需求用例安排项目计划。
•To determine importance of use cases, will create:•Use-case ranking and evaluation matrix•Use-case dependency diagramUse-Case Ranking and Priority Matrix（用例分级）•In most projects, the most important use cases are developed first.Use-case ranking and priority matrix–a tool used to evaluate use cases and determine their priority.•Evaluates use cases on 1-5 scale against six criteria.1.Significant impact on the architectural design.2.Easy to implement but contains significant functionality.3.Includes risky, time-critical, or complex functions.4.Involves significant research or new or risky technology.5.Includes primary business functions.6.Will increase revenue or decrease costs.确定用例的依赖关系Use-case dependency diagram– graphical depiction of the dependencies among use cases.•Provides the following benefits:•Graphical depiction of the system’s events and their states enhancesunderstanding of system functionality.•Helps identify missing use cases.•Helps facilitate project management by depicting which use cases aremore critical.。