用例图实例
用例例子
应用举例 例2—医院病房监护系统 一、问题描述
为了对危重病人进行实时监护 随时了解病人病情， 实时监护， 为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。 进行处理，建立病房监护系统。 病症监视器安置在每个病床， 病症监视器安置在每个病床，通过网络将病人的病症信号 组合）实时传送到中央监护系统进行分析处理。 （组合）实时传送到中央监护系统进行分析处理。 在中心值班室里， 在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控， 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。 并打印病情报告和更新病历。 系统根据医生的要求随时打印病人的病情报告， 系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。 自动更新病历。
采样频率 改变 信号数据组合 <<include>> 模数转化 信号采集 病人
分解信号 <<include>>
<< include>> 生成病历
<<include>>
更新病历
用例“中央监护” 用例“中央监护”描述模板
用例名： 用例名： 中央监视 执行者： 值班护士、 执行者： 值班护士、医生 目标： 目标： 对病人的病症信号进行监测、处理，超过极限报警。 功能描述： 功能描述： 1.分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的 信号。 2.比较信号：将病人的病症信号与标准信号比较 。 3.报警：如果病症信号发生异常（即高于峰值），发出报警信号。 4.数据格式化：将处理后的数据格式化以便写入病历库 。 其他非功能需求: 高可靠性、实时性 其他非功能需求 高可靠性、 主要步骤： 主要步骤： 1.按设定频率连续接收来自各病人的病症信号，并进行分解。 2.将病人的病症信号与专家系统（标准病症信号库）中的标准信号进行比较判 断是否超过极限值。 3.若超过极限值，进行报警，并及时更新病历和打印病情报告。 相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。 相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。 相关信息： 优先级 性能、 执行率 ： 优先级、 相关信息：(优先级、性能、频执行率)： 优先级：报警处理具有最高优先级3,一般病历管理为1,其他2. 优先级：报警处理具有最高 性能：实时性、 性能：实时性、高可靠性 执行率 根据病情严重程度 12-30次/小时 频执行率：根据病情
第5章 用例图
用例与事件流
• 用例分析处于系统的需求分析阶段，这个
阶段应该尽量避免考虑系统实现的细节问 题，这些细节问题写在事件流文件中。事 件流文件即用例的逻辑流程文档包括：
• 1. 简要说明：描述用例的作用； • 2. 前提条件：用例之前必须满足的条件；例：用户是否有运行权限 • 3. 事件流（主事件流、其他事件流、错误流 ）：描述参与者执行用
习题：
• 2、一台饮料自动售货机能提供6种不同的 、一台饮料自动售货机能提供6
饮料。售货机上有6 饮料。售货机上有6个按钮，分别对应于这 6中饮料，顾客可以通过按钮来选择所要的 饮料。每个按钮旁边有一个指示灯，用来 表明该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽，用来收钱 和找钱。
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
3. 系统管理员进行系统维护的用例
① 查询借阅者信息 ② 查询书籍信息 ③ 增加书目 ④ 删除或更新书目 ⑤ 增加书籍 ⑥ 删除书籍 ⑦ 添加借阅者帐户 ⑧ 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 使用Rational Rose绘制用例图 的步骤
扩展关系
• 扩展用例被定义为基础用例的增量扩展，这称作
扩展关系。
用例间的扩展关系
扩展关系例子
扩展关系指的是基础用例执行的情况下可选择是否执行提供者用例。
泛化关系
• 父用例也可以被特别列举为一个或多个子用例。 • 子用例从父用例处继承行为和属性，还可以添加
行为或覆盖、改变继承的行为。
用例间的泛化关系 泛化关系例子
例的具体步骤； • 4. 事后条件：用例执行完毕后必须为真的条件。例：用例完成之后 设置一个标志，这种信息就是事后条件。
利用用例图描述用户需求
（4）用例的命名
每个用例应有唯一的名称 命名的方式：用例通常用动词 + 名词短语来命名---如：登录系统
请见文档中的说明 书写用例的模板格式
四、UML中的用例图
1、用例图 （1）什么是用例图
提供用例图的目的之 一是下面的描述
用例图是一种图形化的工具，它用简单的图形元素表示出 系统的参与者、用例以及它们之间的联系
（2）用例图中的参与者和用例之间的通信
参与者和用例之间的使用关系，在用例图中表示为一个 带箭头的直线
二、UML中的用例之间的关系
1、用例之间的关系
主要体现在纵向方面的层次化关系和横向方面的关联性和 包含
（1）用例的层次化（纵向方面）
按照抽象层次，用例可以划分为系统层（最高层）、子系 统层（可以再细分）和对象类层（最低层）。 系统层用例图：描述系统提供的全部主要的功能或服务。 子系统层用例图：描述某一子系统所应该提供的服务，它 的外部交互者可以是其他的子系统或高一层的参与者。 对象类层的用例图描述对象类提供的功能片或操作，它的 外部交互者可以是其他对象类或高一层活动者。
（3）用例图的组成元素
在一个用例图中，一般主要 包含有 系统边界 参与者 用例和用例关系 （泛化、使用和扩展等 三种形式）。
这在前面已经 加以说明过
2、用例图的主要作用 （1）面向用户
可以实现从用户角度来描述系统所应该具有的功能，同时 并能够指出各功能的操作者； 也能够显示出与系统进行交互的外部参与者及其使用方式。 （2）面向开发者 表示正在构造的新系统应该具有的功能 同时对已经构造完毕的系统，则反映了系统能够完成什么 样的功能
用例及用例图案例
用例及用例图-案例
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) 什么叫事件流,作用是什么？
用例图, 类图
Get Upload Files
Receive Data
Manage Log
Breake Connection
Time
18/336
1.用例图 (19/29)
•
20/336
21/336
22/336
1.用例图 (22/29)
23/336
24/336
1.用例图 (25/29)
智能电梯系统
25/336
1.用例图 (26/29)
Deal with Auditing Data
Auditing break connection
break connection
Server 17/336
1.用例图 (18/29)
• 学生课程注册系统例子
– 每个学生都可以增删改查自己的课程注册表 – 每个教师都可以查询课程花名册 – 学校管理人员可以维护全部课程，可以登记
Dat aObjec t
38/336
2.顺序图 (8/19)
40/336
2.顺序图 (9/19) 2.顺序图 (11/19)
41/336
: Actor
FormObject
1: Open form
ControlObject
DataObject
2: Enter information
3: Save informat ion
is displayed
4. Select a file
12/336
1.用例图 (12/29)
• 例子: 远程通讯
– 背景 – 任务
• 远程审核 • 远程客户端
Client
13/336
logon Request Data Receive Data
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中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
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.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
用例和用例图
技巧 实地观察
访谈
描述
• 直接观察个人工作旳情况，以发觉现存旳实践方式和
问题
• 从个人处搜集特定信息
特定群体 调查
对一组人员进行调查，以便了解工作态度和共同看法
• 问卷调查 搜集详细数据和统计意义上比较主要旳数据
• • 顾客指 导
让最终顾客告诉你，他们是怎样操作系统旳
• 原型制作 模拟一种无法直接测试旳系统
人、外部系统、外部因素等
12
3.2.2 辨认参加者：参加者要点
• 参加者指在系统中所扮演旳角色。即在拟定参加者时，
应主要考虑他旳角色，而不是这个角色旳实例。
• 某些组织中可能有诸多营销人员，但他们均起着同
一种作用，扮演着相同旳角色。
• 一种顾客也能够扮演多…种角色：一种高级营销人员
既能够是贸易经理，也能够是一般旳营销人员。
小一点旳蓝色大理石
5
3.2.1 获取原始需求：如此脆弱
客户/顾客旳要 求/想法/期望
验收
分析和设计
没价值旳 软件需求
补文档
软件产品 编码和测试
软件设计
6
3.2.1 获取原始需求：也需要开发
客户/顾客旳要 求/想法/期望
软件产品
开发
验收
编码和测试
有价值旳 软件需求
分析和设计
软件设计
7
3.2.1 获取原始需求：技巧
第三章 用例和用例图
1
3.1 概述
• 用例图着重从系统外部执行者旳角度来描述系统需要提
供哪些功能，执行者能够是人或外部系统。
2
3.1 概述
用例图旳构成元素
• 图中旳元素涉及：参加者、用例、某些表达关系旳连接
单项练习之用例图
单项练习——用例图实验目的：1.掌握用例图的涵义和内容2.掌握用例图的绘制方法3.掌握用例图的使用范围实验内容：画出下列描述的用例图：某零食厂家使用购物预约管理系统。
预约管理人责任客户预约商品的登录、浏览、更改和删除。
员工查看已预约的商品，确定当天的工作。
该预约管理系统与客户信息管理系统连动，在进行预约商品登录的同时可以浏览预约订货客户的信息。
客户、管理员和员工进行操作时要先登录。
实验指导：1.用例图的简介用例模型用来获得系统的需求。
用例意味着和用户和相关人员通信得到系统打算做什么。
一个用例图展示了系统和系统外部的实体之间的交互。
这些外部实体就是actors。
Actors 既包括人类用户，也包括硬件或者其他系统。
一个actor经常用一个人的符号表示，或者用类框加上《actor》原型表示。
Actor可以泛化出其他更详细的actor。
见图1.图1 actor用例意味着一件唯一的工作。
它提供了一个高级别的在系统外部可观察到的人或事的行为。
用椭圆表示。
Actor和用例之间用一个带箭头的实线表示属于这个actor的用例。
如图2，客户取款的用例。
图2 客户取款的用例一个用例的定义通常包括以下部分：名字和描述、需求、约束等。
名字和描述：一个用例通常用一个动词短语命名，并给出一个简短的非正式的文本描述。
需求：指的是一个用例必须提供给最终用户的正式的功能性需求。
需求是一个用例必须执行一个动作或者向系统提供某个值的协约或者约定。
约束：指的是用例操作在前置条件、后置条件和常量条件下的约束。
前置条件指用例进行前必须具有的状态。
后置条件指用例执行后必须为真的状态。
常量状态指用例执行过程中始终为真的状态。
用例场景：指用例在实际执行的时候会有很多的不同情况发生，是用例的实例。
我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。
在用例规约中，场景的描述可以由基本流和备选流的组合来表示。
特殊需求：通常指非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。
用例图3
20/83
基于用例的需求分析过程
1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包
8/83
用例图是骨架，而用例规约则是其内在的肉
9/83
高屋建瓴与细致入微相得益彰
文本 in Word
图形 in Rose
10/83
用例规约
用例规约包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本 流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。 特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性 等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属 性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件 是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求 在某个用例执行完后，必须执行另一个用例。
如系统中经理可以参加雇 员的所有用例
用例A 雇员 用例B
经理
用例C
27/83
泛化关系的误用
银行用例及用例图
4.4 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能, 通过一组用例可以描述软件系统能够给用户提 供的功能.
用例图可以作为整个系统开发过程中的开发依 据,指导和驱动其他模型.
2. 用例图的形式
取款用例描述实例
● 用例：取款 ●参与者：储户 ●操作流：
① 通过读卡机,储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号. ③ 储户键入密码,系统检验密码. ④储户按确认键,输入取款金额. ⑤ATM把帐号和取款金额传递给银行系统,取回确认信息 和帐户余额. ⑥ ATM输出现金,并显示帐户余额. ⑦ATM记录事务到日志文件.
① 管理员选择进入管理界面,用例开始. ② 系统提示输入管理员密码. ③ 管理员输入密码. ④ 系统检验密码.
A1：密码出错. ⑤ 进入管理界面,系统显示当前所建立的全部课程信息. ⑥ 管理员选择增加课程,管理员输入新课程信息. ⑦系统验证是否与已有课程冲突.
Ａ２：有冲突. ⑧系统填写新课程,并提示填写成功. ⑨系统回到管理主界面,显示所有课程,用例结束.
用例及用例图
张鲲
用例及用例图
4.1 用例 4.2 参与者 4.3 用例之间的关系 4.4 用例图 4.5 发现用例
4.1 用例
1. 用例的概念 用例use case: 表示参与者与系统的一次交互过程.
2.用例的表示 用例用椭圆表示
3. 用例的特点 ① 用例用于描述系统的功能,这个功能是外部
使用者看到的系统功能,不反映功能的实现方式.
● ⑥ 编制用例说明.
● 用例：退房结帐 ●参与者：柜台工作人员 ●说明：
① 工作人员启动退房结帐功能. ② 输入旅客标志信息. ③ 系统显示旅客入住信息. ④ 显示入住天数,费用. ⑤ 接收费用. ⑥ 打印发票. ⑦ 入住登记结束.
第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驱动的软件开发方式。
EnterpriseArchitect学习之用例图
EnterpriseArchitect学习之⽤例图⽤例模型⽤例模型⽤来记录系统的需求，它提供系统与⽤户及其他参与者的⼀种通信⼿段。
执⾏者⽤例图显⽰了系统和系统外实体之间的交互。
这些实体被引⽤为执⾏者。
执⾏者代表⾓⾊，可以包括：⽤户，外部硬件和其他系统。
执⾏者往往被画成简笔画⼩⼈。
也可以⽤带«actor»关键字的类矩形表⽰。
上图中，备选⽅案的画法是，创建⼀个类元素，名称（Name）命名为客户，把构造型（Stereotype）设为Actor，并设置Feature and Compartment Visibility的Structure Compartment可见。
在下图中，执⾏者可以详细的泛化其他执⾏者：⽤例⽤例是有意义的单独⼯作单元。
它向系统外部的⼈或事提供⼀个易于观察的⾼层次⾏为视图。
⽤例的标注符号是⼀个椭圆。
使⽤⽤例的符号是带可选择箭头的连接线，箭头显⽰控制的⽅向。
下图说明执⾏者“Customer”使⽤“Withdraw”⽤例。
⽤途连接器（uses connector）可以有选择性的在每⼀个端点有多重性值，如下图，显⽰客户⼀次可能只执⾏⼀次取款交易。
但是银⾏可以同时执⾏许多取款交易。
多重性设置是在⽤途连接器的两端分别设置。
⽤例定义⼀个典型的⽤例包括：名称和描述需求约束情形情形图附加信息名称和描述⽤例通常⽤⼀个动词词组定义，⽽且有⼀个简短的⽂字说明。
需求需求定义了⼀个⽤例必须提供给终端⽤户的正式功能性需求。
它们符合构造⽅法建⽴的功能性规范。
⼀个需求是⽤例将执⾏⼀个动作或提供多个值给系统的约定或承诺。
约束⼀个约束是⼀个⽤例运⾏的条件或限制。
它包括：前置条件，后置条件和不变化条件。
前置条件指明了⽤例在发⽣之前需要符合的条件。
后置条件⽤来说明在⽤例执⾏之后⼀些条件必须为“真”。
不变化条件说明⽤例整个执⾏过程中该条件始终为“真”。
情形情形是⽤例的实例在执⾏过程中，事件发⽣流程的形式描述。
用例图实例
医院病房监护系统
现有一医院病房监护系统，病症监视器安置在每 个病房，将病人的病症信号实时传送到中央监视系统进行 分析处理。在中心值班室里，值班护士使用中央监视系统 对病员的情况进行监控，根据医生的要求随时打印病人的 病情报告，定期更新病历，当病症出现异常时，系统会立 即自动报警, 并实时打印病人的病情报告，立即更新病历。
1、通过以下六个问题识别角色 (1)谁使用系统的主要功能？ (2)谁需要系统的支持以完成日常工作任务？ (3)谁负责维护，管理并保持系统正常运行？ (4)系统需要应付（或处理）哪些硬设备？ (5)系统需要和哪些外部系统交互？ (6)谁（或什么）对系统运行产生的结果（值）感兴趣？
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四 个角色：值班护士，医生，病人，标准病症信号库。
3、当病症信号异常时，系统自动更新病历并打印病情 报告。
4、值班护士可以查看病情报告并进行打印。 5、医生可以查看病情报告，要求打印病情报告，也可 以查看或要求打印病历。 6、系统定期自动更新病历。
首页 上页 下页 末页 退出
需求分析
三、用UML的静态建模机制定义并描述系统的静态结构 （一）建立系统的用例图
f 模数转化 将采集来的模拟信号转化为数字信号。
g 信号数据组合 将采集到的脉搏，血压等信号数据组合为一 组信号数据。
h 采样频率改变 根据病人的情况改变监视器采样频率。
3、提供标准病症信号 i（此用例不分解）
用例细化
4、病历管理 分解为：j 生成病历
k 查看病历 l 更新病历 m 打印病历 5、病情报告 分解为：n 显示病情报告 o 打印病情报告
(1)使用系统主要功能 (2)对系统运行结果感 兴趣
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
在显示器上显示病情 在打印机打印病情报告
给出细化的用例图
细化的用例图
提供标准 《 use》
病症信号
比较信号
标准病症 信号库
《 Extend 》
《 Extend 》
分解信号
报警
《 use》
《 use》
采样频率 改变
信号数据组合 《 use》
值班护士
数据格式化
《 use》
《 use》
《 use》 生成病历
更新病历
需求分析
二、简单的需求分析说明 系统名称：医院病房监护系统 根据分析系统主要实现以下功能：
1、病症监视器可以将采集到的病症信号（组合），格 式化后实时的传送到中央监护系统。
2、中央监护系统将病人的病症信号开解后与标准的病 症信号库里的病症信号的正常值进行比较，当病症出现异常 时系统自动报警。
THANK YOU
2019/10/8
角色描述
通过分析可以初步识别出系统的用例为：中央监护，病症 监护，提供标准病症信号，病历管理，病情报告管理。顶层用 例图为：
值班护士 医生
中央监护
《使用》 病症监护
病情报 告管理
《使用》
《使用》
提供标准 病症信号
ห้องสมุดไป่ตู้
病历管理
病人
标准病症 信号库
用例细化
将用例细化，可以得到分解的用例：
3、当病症信号异常时，系统自动更新病历并打印病情 报告。
4、值班护士可以查看病情报告并进行打印。 5、医生可以查看病情报告，要求打印病情报告，也可 以查看或要求打印病历。 6、系统定期自动更新病历。
首页 上页 下页 末页 退出
需求分析
三、用UML的静态建模机制定义并描述系统的静态结构 （一）建立系统的用例图
要求根据现场情景，对医院病房监护系统进行需 求分析， 建立系统的Use case model。
情景教学
医院病房监护系统
监视病情
产生 病情报告
经过初步的需求分析，得到系统功能要求：
1、请监视对病系员统的需病求症（进血行压分、析体！温、脉搏等）
2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。
f 模数转化 将采集来的模拟信号转化为数字信号。
g 信号数据组合 将采集到的脉搏，血压等信号数据组合为一 组信号数据。
h 采样频率改变 根据病人的情况改变监视器采样频率。
3、提供标准病症信号 i（此用例不分解）
用例细化
4、病历管理 分解为：j 生成病历
k 查看病历 l 更新病历 m 打印病历 5、病情报告 分解为：n 显示病情报告 o 打印病情报告
角色描述模板
角色：病 人 角色职责： 提供病症信号
角色职责识别：
负责生成、实时提供 各种病症信号。
角色：医 生 角色职责：
对病人负责，负责
处理病情的变化
角色职责识别： (1)需要系统支持以完 成其日常工作 (2)对系统运行结果感 兴趣
角色：值班护士 角色职责： 负责监视病人的病 情变化 角色职责识别：
(1)使用系统主要功能 (2)对系统运行结果感 兴趣
角色:标准病症信号库 角色职责： 负责向系统提供病症 信号的正常值
角色职责识别： (1)负责保持系统 正常运行 (2)与系统交互
通过分析可以初步识别出系统的用例为：中央监护，病症 监护，提供标准病症信号，病历管理，病情报告管理。顶层用 例图为：
SUCCESS
用例图实例
医院病房监护系统
现有一医院病房监护系统，病症监视器安置在每 个病房，将病人的病症信号实时传送到中央监视系统进行 分析处理。在中心值班室里，值班护士使用中央监视系统 对病员的情况进行监控，根据医生的要求随时打印病人的 病情报告，定期更新病历，当病症出现异常时，系统会立 即自动报警, 并实时打印病人的病情报告，立即更新病历。
1、通过以下六个问题识别角色 (1)谁使用系统的主要功能？ (2)谁需要系统的支持以完成日常工作任务？ (3)谁负责维护，管理并保持系统正常运行？ (4)系统需要应付（或处理）哪些硬设备？ (5)系统需要和哪些外部系统交互？ (6)谁（或什么）对系统运行产生的结果（值）感兴趣？
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四 个角色：值班护士，医生，病人，标准病症信号库。
1、中央监护
分解为： a 分解信号 将从病症监护器传送来的组合病症信号分解为系 统可以处理的信号。
b 比较信号 将病人的病症信号与标准信号比较 。
c 报警 信号。
如果病症信号发生异常（即高于峰值），发出报警
d 数据格式化 将处理后的数据格式化以便写入病历库 。
2、病症监护
分解为：e 信号采集 采集病人的病症信号。
显示病情报告
打印病情报告
《 Extend 》
模数转化
信号采集
《 use》
查看病历
更新病历
病人
医生
打印病历
SUCCESS
THANK YOU
2019/10/8