UML用况图PPT课件
合集下载
UML状态图课件
终止状态在一个状态图中可以有多个，它 用一个套有一个实心圆的空心圆表示。
5 判定
判定在状态图中的位置：工作流在此处按 监护条件的取值而发生分支。
判定用空心小菱形表示。
因为监护条件为布尔表达式，所以通常条 件下的判定只有一个入转换和两个出转换。
根据监护条件的真假可以触发不同的分支 转换。
然而处于不同状态下的对象会通过不同的 动作对同一事件做出不同的反应。
示意图：
状态图
1 状态
状态由一个带圆角的 矩形表示。
状态图标可以分为： ① 名称 ② 内部转换
名称
entry/ exit/
2 转换
转换用带箭头的直线表示，一端连接源状态即转 出的状态，箭头一端连接目标状态即转入的状态。
如图所示：
准备
常见的三个活动是：
entry/ 进入教室 do/ 打开投影 exit/ 宣布上课
1、入口动作（entry ） ：进入某一状态时执行的动作。
2、动作（do）：系统处于该状态时要发生的动作。
3、出口动作 （exit ）：离开某一状态时执行的动作 。
子状态（substate）
某些状态存在于另一个状态之中，因此它们被称为 子状态。子状态以两种形式出现：顺序子状态和并 发子状态。
状态图
讲授内容
状态图基本表示 状态、事件、转移、活
动 状态图练习 状态图知识点小节
什么是状态图
按电灯的开关时，电灯改变了它的状态 按遥控器的调频按钮时，电视机的状态由显
示一个频道的节目变为显示另一个频道的节 目 经过一段时间，洗衣机由洗涤变为漂洗状态 夏天树叶绿了，秋天变黄了 如何表示这些变化呢？
作业
自学历史状态
5 判定
判定在状态图中的位置：工作流在此处按 监护条件的取值而发生分支。
判定用空心小菱形表示。
因为监护条件为布尔表达式，所以通常条 件下的判定只有一个入转换和两个出转换。
根据监护条件的真假可以触发不同的分支 转换。
然而处于不同状态下的对象会通过不同的 动作对同一事件做出不同的反应。
示意图：
状态图
1 状态
状态由一个带圆角的 矩形表示。
状态图标可以分为： ① 名称 ② 内部转换
名称
entry/ exit/
2 转换
转换用带箭头的直线表示，一端连接源状态即转 出的状态，箭头一端连接目标状态即转入的状态。
如图所示：
准备
常见的三个活动是：
entry/ 进入教室 do/ 打开投影 exit/ 宣布上课
1、入口动作（entry ） ：进入某一状态时执行的动作。
2、动作（do）：系统处于该状态时要发生的动作。
3、出口动作 （exit ）：离开某一状态时执行的动作 。
子状态（substate）
某些状态存在于另一个状态之中，因此它们被称为 子状态。子状态以两种形式出现：顺序子状态和并 发子状态。
状态图
讲授内容
状态图基本表示 状态、事件、转移、活
动 状态图练习 状态图知识点小节
什么是状态图
按电灯的开关时，电灯改变了它的状态 按遥控器的调频按钮时，电视机的状态由显
示一个频道的节目变为显示另一个频道的节 目 经过一段时间，洗衣机由洗涤变为漂洗状态 夏天树叶绿了，秋天变黄了 如何表示这些变化呢？
作业
自学历史状态
UML概述ppt课件精选全文
用于表示从同步消息激活的动作返回到调用 者的消息
注释体 用于对UML实体进行文字描述
注释连接
注释连接将注释体与要描述的实体相连。说 明该注释体是对该实体所进行2-
协作图（通讯图）
协作图表示一组对象间关系以及交互活动
协作图可以认为是对象图的扩展，它增加了一些符号用于表 示对象间的交互。协作图和顺序图具有同构性。
指向源同步 消息
表示对象间从目的对象向源对象发送同步消息
指向目的的 同步消息
表示对象间从源对象向目的对象发送同步消息
注释体
注释连接
-35-
示例：协作图
-36-
活动图
活动图：通过动作来组织，主要用于描述某一方法、机制或 用例的内部行为
主要使用场合：业务建模、用例分析
-37-
活动图元语-1
活动 组合活动
1997.1公布 UML 1.0 合作伙伴
业
公
意见
众 1996.6和1996.10 UML 0.9&0.91
化
反
馈 OOPSLA95 Unified Method 0.8
标
准
Booch93 OMT-2
化
Booch91 OOSE
OMT-1 其他方法 统
一
UML基本图
静态模型 (系类统图结 构) class diagrams
转移
用于说明两个对象间存在某种关系，如满足某 个条件并当某一事件发生时，对象将从一个状 态变迁到另一个状态并同时执行一些活动
注释体
注释连接
示例：状态图
顺序图
顺序图：主要用于显示对象间的交互活动，但没有明确的交 互环境和对象状态
主要使用场合：系统分析（用例分析）、设计
注释体 用于对UML实体进行文字描述
注释连接
注释连接将注释体与要描述的实体相连。说 明该注释体是对该实体所进行2-
协作图（通讯图）
协作图表示一组对象间关系以及交互活动
协作图可以认为是对象图的扩展，它增加了一些符号用于表 示对象间的交互。协作图和顺序图具有同构性。
指向源同步 消息
表示对象间从目的对象向源对象发送同步消息
指向目的的 同步消息
表示对象间从源对象向目的对象发送同步消息
注释体
注释连接
-35-
示例：协作图
-36-
活动图
活动图：通过动作来组织，主要用于描述某一方法、机制或 用例的内部行为
主要使用场合：业务建模、用例分析
-37-
活动图元语-1
活动 组合活动
1997.1公布 UML 1.0 合作伙伴
业
公
意见
众 1996.6和1996.10 UML 0.9&0.91
化
反
馈 OOPSLA95 Unified Method 0.8
标
准
Booch93 OMT-2
化
Booch91 OOSE
OMT-1 其他方法 统
一
UML基本图
静态模型 (系类统图结 构) class diagrams
转移
用于说明两个对象间存在某种关系，如满足某 个条件并当某一事件发生时，对象将从一个状 态变迁到另一个状态并同时执行一些活动
注释体
注释连接
示例：状态图
顺序图
顺序图：主要用于显示对象间的交互活动，但没有明确的交 互环境和对象状态
主要使用场合：系统分析（用例分析）、设计
第2讲用例与UML用例图精品PPT课件
用例与UML用例图
学习目标
上讲回顾 用例的概念 用例分析的过程 使用用例模型捕获系统需求
上讲回顾
UML的全称__________________________________. UML的图基本构造块包括_______和______. UML的基本构造块中的关系包括哪几种__________. UML的图包括哪几种____________. 动态图包括哪些_____________________________. 静态图包括哪些_____________________________. RUP是______________________________________.
评价应聘者
录用应聘者
录用应聘者
拒绝应聘者
拒绝应聘者
参与者的泛化
Employee Manager
面试面应试聘应者 聘者 评评价价应应聘聘者 者 录录用用应应聘聘者者
拒拒绝绝应应聘者聘者
参与者的泛化
• 只有在子参与者使用了父参与者所使用的 所有用例时，参与者泛化才是合适的。
• 参与者泛化会带来不必要的复杂性，所以 不要强加一个不存在的关系。
用例的特点 ： 用例捕获某些用户可见的需求，实现一个具 体的用户目标。 用例由参与者激活，并提供确切的值给参与 者。 用例可大可小，但它必须是对一个具体的用 户目标实现的完整描述。
参与者（Actor）
参与者是指对用例所描述的事件序列的发 起者。
参与者可以是一个人、另一个系统、一台 硬件设备或某段时间的流逝。
后置条件：顾客得到现金
事件流
（1）事件流由简短步骤的序列组成。 （2）陈述性的、带编号、按时间排序 （3）每个步骤简单地描述了什么东西执
行了什么动作。 每个步骤应该具有如下格式： <编号> <某事> <行为> （4）一个事件流仅描述用例中的一条路径， 不包括其它的分支。
学习目标
上讲回顾 用例的概念 用例分析的过程 使用用例模型捕获系统需求
上讲回顾
UML的全称__________________________________. UML的图基本构造块包括_______和______. UML的基本构造块中的关系包括哪几种__________. UML的图包括哪几种____________. 动态图包括哪些_____________________________. 静态图包括哪些_____________________________. RUP是______________________________________.
评价应聘者
录用应聘者
录用应聘者
拒绝应聘者
拒绝应聘者
参与者的泛化
Employee Manager
面试面应试聘应者 聘者 评评价价应应聘聘者 者 录录用用应应聘聘者者
拒拒绝绝应应聘者聘者
参与者的泛化
• 只有在子参与者使用了父参与者所使用的 所有用例时，参与者泛化才是合适的。
• 参与者泛化会带来不必要的复杂性，所以 不要强加一个不存在的关系。
用例的特点 ： 用例捕获某些用户可见的需求，实现一个具 体的用户目标。 用例由参与者激活，并提供确切的值给参与 者。 用例可大可小，但它必须是对一个具体的用 户目标实现的完整描述。
参与者（Actor）
参与者是指对用例所描述的事件序列的发 起者。
参与者可以是一个人、另一个系统、一台 硬件设备或某段时间的流逝。
后置条件：顾客得到现金
事件流
（1）事件流由简短步骤的序列组成。 （2）陈述性的、带编号、按时间排序 （3）每个步骤简单地描述了什么东西执
行了什么动作。 每个步骤应该具有如下格式： <编号> <某事> <行为> （4）一个事件流仅描述用例中的一条路径， 不包括其它的分支。
UML用例图.ppt
3
系统
系统是用例图的一个组成部分，它是对真正软件 系统活动范围的一个抽象。系统的边界用来说明 构建用例的应用范围。系统边界框定义系统的边 界或限制，所以，系统的所有功能或过程会被限 制在系统内，即此边界将系统的所有过程/功能与 外界环境分隔。
4
系统
5
案例分析 汽车租赁---任务陈述
商店将汽车的跟踪自动化---使用条码、柜台终端和激光阅读器，这有许多 优点：租赁助手的效率提高了20%，汽车很少失踪，客户群变大。
Use Case图是后续的分析工作的依据，也是系统测试的 依据。Rational统一过程主张采用Use Case驱动的软 件开发方式。
1
二、Use Case图—示例
ATM
存钱
取钱
用例图是由
转帐
参与者、系 统、用例三
客户
者构成的。
查询
2
主要内容
1. 系统 2. 参与者 3. Use Case 4. Use Case 的联系 5. Use Case 图建立
Rational统一过程主张采用Use Case驱动的 软件开发方式。
13
开发典型用例
14
“剧本（场景）”描述
参与者与系统的对话过程可用一系列步骤（也称 “剧本”）来描述， “剧本”的集合就是Use Case，系统全部的Use Case构成了对于系统 外部可见行为的描述。
15
2.2 Use Case示例
可以是带一个构造型《Actor》的对象类图标表 示，也可以用简易的人形图标表示。
《Actor》 参与者名
业务 参与者名
系统 参与者名
8
1.3 参与者的确定
凡是与系统进行信息交互（包括数据信息与控制信息交换）的外部事 物可以确认为参与者。
系统
系统是用例图的一个组成部分，它是对真正软件 系统活动范围的一个抽象。系统的边界用来说明 构建用例的应用范围。系统边界框定义系统的边 界或限制，所以，系统的所有功能或过程会被限 制在系统内，即此边界将系统的所有过程/功能与 外界环境分隔。
4
系统
5
案例分析 汽车租赁---任务陈述
商店将汽车的跟踪自动化---使用条码、柜台终端和激光阅读器，这有许多 优点：租赁助手的效率提高了20%，汽车很少失踪，客户群变大。
Use Case图是后续的分析工作的依据，也是系统测试的 依据。Rational统一过程主张采用Use Case驱动的软 件开发方式。
1
二、Use Case图—示例
ATM
存钱
取钱
用例图是由
转帐
参与者、系 统、用例三
客户
者构成的。
查询
2
主要内容
1. 系统 2. 参与者 3. Use Case 4. Use Case 的联系 5. Use Case 图建立
Rational统一过程主张采用Use Case驱动的 软件开发方式。
13
开发典型用例
14
“剧本（场景）”描述
参与者与系统的对话过程可用一系列步骤（也称 “剧本”）来描述， “剧本”的集合就是Use Case，系统全部的Use Case构成了对于系统 外部可见行为的描述。
15
2.2 Use Case示例
可以是带一个构造型《Actor》的对象类图标表 示，也可以用简易的人形图标表示。
《Actor》 参与者名
业务 参与者名
系统 参与者名
8
1.3 参与者的确定
凡是与系统进行信息交互（包括数据信息与控制信息交换）的外部事 物可以确认为参与者。
第9章-状态图和活动图课件
第9章-状态图和活动图
CD Player
9.2 状态图元素
需要stop状态吗？
第9章-状态图和活动图
9.2 状态图元素
中间状态的组成（除初态终态外，最常见的 状态） •状态名（name） •入口/出口动作（entry/exit action） •内部转化（internal transition） •子状态（substate） •延迟事件（deferred event）
前门－入口，后门－出口
不出去，只在内部发生的转换－内 部转换
从后门出去，又从前门进来－自转
换，自转换会引起entry和exit动作
的执行
第9章-状态图和活动图
9.2 状态图元素
子状态（substate） 嵌套在另外一个状态中的状态 空调：停止、运行状态，运行状态中可 嵌套制 冷、制热、除湿等子状态
Lighting
转换域， 可选
再当处转理出次，该用状 d态efe时r这，个做特关定 动作灯表动示作延迟
entry/ turnOn do/ blinkFivetimes
event poweroff/ powerSupplySdeolf活动是只
exit/ turnOff event selfTest/ defer
第9章-状态图和活动图
9.2 状态图元素
9.2.2 状态 • 状态详细描述
状态名称
入口动作 出口动作 内部转换 延迟事件 内部活动
输入密码
entry / pwd.reset()
exit / pwd.test() clear / pwd.reset() help / display help
print / defer do / suppress
状态名称
CD Player
9.2 状态图元素
需要stop状态吗？
第9章-状态图和活动图
9.2 状态图元素
中间状态的组成（除初态终态外，最常见的 状态） •状态名（name） •入口/出口动作（entry/exit action） •内部转化（internal transition） •子状态（substate） •延迟事件（deferred event）
前门－入口，后门－出口
不出去，只在内部发生的转换－内 部转换
从后门出去，又从前门进来－自转
换，自转换会引起entry和exit动作
的执行
第9章-状态图和活动图
9.2 状态图元素
子状态（substate） 嵌套在另外一个状态中的状态 空调：停止、运行状态，运行状态中可 嵌套制 冷、制热、除湿等子状态
Lighting
转换域， 可选
再当处转理出次，该用状 d态efe时r这，个做特关定 动作灯表动示作延迟
entry/ turnOn do/ blinkFivetimes
event poweroff/ powerSupplySdeolf活动是只
exit/ turnOff event selfTest/ defer
第9章-状态图和活动图
9.2 状态图元素
9.2.2 状态 • 状态详细描述
状态名称
入口动作 出口动作 内部转换 延迟事件 内部活动
输入密码
entry / pwd.reset()
exit / pwd.test() clear / pwd.reset() help / display help
print / defer do / suppress
状态名称
UML状态图的画法[优质ppt]
![UML状态图的画法[优质ppt]](https://img.taocdn.com/s3/m/c460612ca417866fb84a8ea3.png)
6
3.1 状态机[2]
状态机用于对一个模型元素建立行为模型，该模型元素通 常是一个对象类，也可以是一个子系统，甚至整个系统。
在UML中状态机用状态图可视化表示。 状态图：状态的节点、转移的弧、事件等组成。
源状态
事件
目标状态
7
3.2 状态
状态：对象全部属性的当前值。
（问题：对象任何一个新的属性值组合就是一个新状态，状态空间太大）
14
事件
事件（event）是指某个时刻发生的事情。 事件中最常见的是：
信号事件（signal event）:从一个对象到另一个对象 的明确的单向信息流动。
变更事件（change event）：是指由满足布尔表达式 而引起的事件。
时间事件（time event）：是指在绝对时间上或在某 个时间间隔上发生的事情所引起的事件。
状态属性：对确定对象的状态有重要意义的属性。 状态属性一般具有少量的值，而且这些属性的值的转换是有限的。
并且其属性值反映所属对象的特定状态。
如：对于“汽车”对象，可能有“型号”、“车况”、“使用情况”、 “公里数”、“汽油剩余量”等属性。不应取“公里数”或“汽油剩余量” 作为状态属性，可取“使用情况”作为属性状态。则，“汽车”对象的有 限个不同状态：“开动”、“停车”、“维修”、“闲置”、“报废”等。
15
3.3 转移[2]
打开PC机
初始化
do / 自启动
工作
关闭机器
关闭
[等待超时]
击键或移动鼠标
状态机的组成：状态、转移、事件、活动、动作等。 状态（State）：表示一个模型元素在生存期的一种状况，如满足某些条件， 进行某些活动，或等待某些事件出现等。一个状态在有限的时间段内存在。 转移/迁移（Transition）:表示一个模型元素的不同状态之间的联系。在 事件触发下，一个状态可以转移到另一个状态。 事件（Event）：一个有意义的出现（Occurrence）的说明。该出现在某 个时间或空间点发生，并且立即触发一个状态的转移。例如，一个信号、一 个操作的调用、一个对象的创建或销毁、超时、某个条件的改变等。 动作（Action）：一个可执行的原子计算，它导致状态的变更或返回一个值。 不能被中断。 活动（Activity）：是在状态机中一系列动作的执行。活动可能被某个事件 中断。
3.1 状态机[2]
状态机用于对一个模型元素建立行为模型，该模型元素通 常是一个对象类，也可以是一个子系统，甚至整个系统。
在UML中状态机用状态图可视化表示。 状态图：状态的节点、转移的弧、事件等组成。
源状态
事件
目标状态
7
3.2 状态
状态：对象全部属性的当前值。
（问题：对象任何一个新的属性值组合就是一个新状态，状态空间太大）
14
事件
事件（event）是指某个时刻发生的事情。 事件中最常见的是：
信号事件（signal event）:从一个对象到另一个对象 的明确的单向信息流动。
变更事件（change event）：是指由满足布尔表达式 而引起的事件。
时间事件（time event）：是指在绝对时间上或在某 个时间间隔上发生的事情所引起的事件。
状态属性：对确定对象的状态有重要意义的属性。 状态属性一般具有少量的值，而且这些属性的值的转换是有限的。
并且其属性值反映所属对象的特定状态。
如：对于“汽车”对象，可能有“型号”、“车况”、“使用情况”、 “公里数”、“汽油剩余量”等属性。不应取“公里数”或“汽油剩余量” 作为状态属性，可取“使用情况”作为属性状态。则，“汽车”对象的有 限个不同状态：“开动”、“停车”、“维修”、“闲置”、“报废”等。
15
3.3 转移[2]
打开PC机
初始化
do / 自启动
工作
关闭机器
关闭
[等待超时]
击键或移动鼠标
状态机的组成：状态、转移、事件、活动、动作等。 状态（State）：表示一个模型元素在生存期的一种状况，如满足某些条件， 进行某些活动，或等待某些事件出现等。一个状态在有限的时间段内存在。 转移/迁移（Transition）:表示一个模型元素的不同状态之间的联系。在 事件触发下，一个状态可以转移到另一个状态。 事件（Event）：一个有意义的出现（Occurrence）的说明。该出现在某 个时间或空间点发生，并且立即触发一个状态的转移。例如，一个信号、一 个操作的调用、一个对象的创建或销毁、超时、某个条件的改变等。 动作（Action）：一个可执行的原子计算，它导致状态的变更或返回一个值。 不能被中断。 活动（Activity）：是在状态机中一系列动作的执行。活动可能被某个事件 中断。
uml建模状态机图PPT专业课件
4
例：CD播放器
5
一、状态（state）
2、状态的表示 状态名称 入口动作 出口动作 内部转换 内部活动 可推迟事件
状态示例
6
动作（Action）
可执行的原子计算。 不可中断，其执行时间可忽略不计。
两种特殊动作：
进入动作（entry action）：进入某状态时执 行的动作，用“entry/要执行的动作”表示。
34
10.3 建立状态机图
1．寻找主要的状态 飞机票有以下4种状态：无预订、部分预订、
预订完、预订关闭。 （1）在刚确定飞行计划时，显然没有任何预订，
且在顾客预订机票之前都将处于“无预订”状态。 （2）对于订座而言，有“部分预订”和“预订完”
两种状态。 （3）当航班快要起飞时，要“预订关闭”。
35
11
（3）简单状态
组成： 状态名 进入/退出动作 内部转移----不导致状态改变的转换，不会
执行entry和exit动作。 内部活动 延迟事件----延迟到下一状态处理的事件。
12
EnterPassword
entry/ set echo * exit/ set echo normal event keypress/ handle character event help/ display help event save/ defer do/ get password
Maintaining The train stop
22
（2）内部转换
有一个源状态但没有目标状态，转换后的状态 仍是它本身。
23
（3）自动转换
在没有外部事件的作用下，对象执行了某些活 动后，自然而然地完成的转换。
例：CD播放器
5
一、状态（state）
2、状态的表示 状态名称 入口动作 出口动作 内部转换 内部活动 可推迟事件
状态示例
6
动作（Action）
可执行的原子计算。 不可中断，其执行时间可忽略不计。
两种特殊动作：
进入动作（entry action）：进入某状态时执 行的动作，用“entry/要执行的动作”表示。
34
10.3 建立状态机图
1．寻找主要的状态 飞机票有以下4种状态：无预订、部分预订、
预订完、预订关闭。 （1）在刚确定飞行计划时，显然没有任何预订，
且在顾客预订机票之前都将处于“无预订”状态。 （2）对于订座而言，有“部分预订”和“预订完”
两种状态。 （3）当航班快要起飞时，要“预订关闭”。
35
11
（3）简单状态
组成： 状态名 进入/退出动作 内部转移----不导致状态改变的转换，不会
执行entry和exit动作。 内部活动 延迟事件----延迟到下一状态处理的事件。
12
EnterPassword
entry/ set echo * exit/ set echo normal event keypress/ handle character event help/ display help event save/ defer do/ get password
Maintaining The train stop
22
（2）内部转换
有一个源状态但没有目标状态，转换后的状态 仍是它本身。
23
（3）自动转换
在没有外部事件的作用下，对象执行了某些活 动后，自然而然地完成的转换。
需求分析——UML用例图PPT课件
-32-
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
UML的状态图图解及应用
状态图可以帮助理解系统的行 为和状态转换过程
状态图可以用于描述系统的动 态行为和状态转换关系
状态图的组成
状态：表示系统在某个时间点的状态
动作：状态转换过程中执行的操作
转换：表示系统从一个状态到另一个状 态的变化
事件：触发状态转换的条件
监护条件：状态转换的附加条件
状态图：表示系统状态和状态转换的图 形表示
UML的状态图图解及应用
汇报人：XX
UML状态图的概述 UML状态图的图解 UML状态图的应用场景 UML状态图的实践案例 UML状态图的优缺点
UML状态图的发展趋势和未来展望
UML状态图的概述
状态图的定义
UML状态图是一种描述系统状 态和状态转换的图形工具
状态图描述了系统在不同状态 下的行为和转换关系
添加标题
添加标题
添加标题
添加标题
技术融合：与其他建模技术相结合， 如BPMN、SysML等
标准更新：UML标准不断更新，以 适应新的技术和应用需求
未来展望
应用领域：UML状态图将在软件开发、系统设计等领域得到更广泛的应用
技术发展：随着人工智能、大数据等技术的发展，UML状态图将更加智能化、高效化
标准制定：UML状态图将逐渐成为国际标准，为软件开发提供更统一的规范
转换的表示
转换：从一个状态到另一个状态的变化 转换条件：触发转换的事件或条件 转换动作：在转换过程中执行的操作 转换目标：转换后的目标状态
动作的表示
动作名称：在箭头上方或下 方标注动作名称
动作表示：使用箭头表示动 作，箭头指向目标状态
动作条件：在箭头上方或下 方标注动作条件
动作结果：在箭头上方或下 方标注动作结果
业务过程建模
一小时看懂UMLPPT课件
※ 协作图描述对象间的协作关系，协作图跟顺序图 相似，显示对象间的动态合作关系。除显示信息 交换外，协作图还显示对象以及它们之间的关系.
※ 协作图的一个用途是表示一个类操作的实现
状态图(State Chart Diagram)
※ 状态图是一个类对象所可能经历的所有历程的 模型图。状态图由对象的各个状态和连接这些 状态的转换组成
UML
-6-
前言—UML图及特征
用例图( Use Case Diagram )
※ 用例图是从用户角度描述系统功能， 是 用户所能观察到的系统功能的模型图，用 例是系统中的一个功能单元
类图(Class Diagram)
※ 类图描述系统中类的静态结构。不仅定义系 统中的类，表示类之间的联系如关联、依赖、 聚合等，也包括类的内部结构(类的属性和操 作)
初始状态 Available
assigned subscription
time out 状态
lock
Locked
to buy
Sold
unlock
转换 exchange
触发器事件
UML
-9-
前言—UML图及特征
活动图(Activity Diagram)
※ 活动图是状态图的一个变体，用来描述 执行算法的工作流程中涉及的活动
一小时看懂UML
UML
-1-
UML
整体概况
+ 概况1
您的内容打在这里，或者通过复制您的文本后。
概况2
+ 您的内容打在这里，或者通过复制您的文本后。
概况3
+ 您的内容打在这里，或者通过复制您的文本后。
-2-
目录
1. 前
言
2. 用 例 图
※ 协作图的一个用途是表示一个类操作的实现
状态图(State Chart Diagram)
※ 状态图是一个类对象所可能经历的所有历程的 模型图。状态图由对象的各个状态和连接这些 状态的转换组成
UML
-6-
前言—UML图及特征
用例图( Use Case Diagram )
※ 用例图是从用户角度描述系统功能， 是 用户所能观察到的系统功能的模型图，用 例是系统中的一个功能单元
类图(Class Diagram)
※ 类图描述系统中类的静态结构。不仅定义系 统中的类，表示类之间的联系如关联、依赖、 聚合等，也包括类的内部结构(类的属性和操 作)
初始状态 Available
assigned subscription
time out 状态
lock
Locked
to buy
Sold
unlock
转换 exchange
触发器事件
UML
-9-
前言—UML图及特征
活动图(Activity Diagram)
※ 活动图是状态图的一个变体，用来描述 执行算法的工作流程中涉及的活动
一小时看懂UML
UML
-1-
UML
整体概况
+ 概况1
您的内容打在这里，或者通过复制您的文本后。
概况2
+ 您的内容打在这里，或者通过复制您的文本后。
概况3
+ 您的内容打在这里，或者通过复制您的文本后。
-2-
目录
1. 前
言
2. 用 例 图
UML流程图(PPT 41张)
• 结点 • 连接
部署图
老师在线答疑系统部署图
课后练习
老师在线答疑系统的网络白板需求描述： 1、同时使用白板的用户必须是2个，一个老师和一个学生 2、使用白板的2个用户是对等的，两个用户看到的内容是一 样的
3、用户可以在上面写文字和作图，后者包括：直线，圆， 椭圆和矩形
4、用户可以增删，选择，移动上面的文字和图形标记
活动图
老师登陆系统
活动图
练习 1、学生第一次开学入学，首先正确填写表格， 如果表格不正确，那么必须获得帮助以正 确填写它们。接着办理大学的入学手续。 但是，在大学里成功入学后，必须参加指 定的概况介绍，还要至少登记一个研习班 并交付一部分的学费。使用活动图来表达 该流程
顺序图
顺序图用来描述对象之间动态的交互关系， 着重体现对象间消息传递的时间顺序。 • 对象 • 消息
状态图
状态图表示某个类所具有的不同状态和状态 转移时的触发条件。 • 状态 • 转移
状态图
• 老师在线状态图
状态图
练习
1、汽车有向前行驶，向后行驶和停止3种状
态，请使用UML图将3种状态之间的转移关
系表达出来
活动图
活动图用来描述工作的流程，对并行的工 作流程能很好的支持。 • 活动 • 转移的功能单元。 • 参与者 • 用例 • 关联关系 • 依赖关系 • 继承关系
用例图
老师在线答疑系统需求描述 • 他是一个用于老师和学生之间进行即时沟通的系统。 • 系统由老师使用的老师端，学生使用的学生端和一个有公 网地址的登陆服务端组成。 • 老师登陆系统后会在老师列表中出现，并显示出他的专业、 姓名、专长和状态是否忙等信息。也可以看到其他所有登 录的老师的信息。 • 学生登陆后可以看到所有已经登录的老师列表。 • 学生可以选择一个不忙的老师进行问题咨询，和选择的老 师建立连接后就可以通过语音加白板和老师进行交流。此 时其他学生将看到该老师处于忙的状态。
第06章UML用例图ppt课件
基于这些信息的高层用例图。这些用例就构成了该 局域网系统的功能需求。
6.4.4 进一步深化
详细论述这些高层用例中的一个，并建立一个用 例模型。咨询公司中最重要的一项活动是书写提案。 因此检验一下“Create a proposal〞这个用例。
与某个顾问面谈，他就能通知他这个用例中的许 多步骤。首先，用例的发起者是一个顾问。顾问要登 录到局域网，并作为一个有成效户被验证。然后他运 用办公软件套件(包括文字处置软件包、电子表格软 件包以及绘图软件包等)来书写提案。在这个过程中， 顾问能够要重用一部分以前的提案。咨询公司的
上一章“引见用例〞中还给出了用例“Buy soda 〞的一些可选的场景。在详细描画中，可以分别列出 这些场景，或者把它们作为用例根本场景的扩展来思 索。详细怎样做需求根据客户、用户和他对问题的了 解。
要阐明一个场景中的步骤，还可以运用UML活动 图对场景进展描画(这部分内容将在 “活动图〞一章 中讨论)。
6.2.1 包含
上一章中的“Restock〞和“Collect〞用例都从 开锁和拉开销售机的门开场，都以关门和上锁终了。 第1步建立了“Expose the inside(翻开销售机)〞用例， 并且第2步创建了“Unexpose the inside (封锁销售机) 〞用例。“Restock〞和“Collect〞两者都包含了这 两个新用例。
6.1 用例模型的表示法
用例是由参与者发起的，参与者(也许是发起 者，但不是必需的)可以从用例的执行中获得有价 值的事物。用例模型的图形表示法很直观。用例 用一个椭圆形表示，直立人形图标表示参与者。 用例的发起参与者在用例图的左侧，接纳参与者
在用例图的右侧。参与者的名字放在参与者图标的下方， 用例的名字可以放在椭圆形里面也可以放在椭圆形下面。 关联线衔接参与者和用例，并且表示参与者与用例之间有 通讯关系。关联线是实线，和类之间的关联线类似。
UML分析类、状态图基础和画法30页PPT
–描述一个用例所具有的事件流控制行为 –实现对用例行为的封装，将用例的执行逻辑与边界和实
体进行隔离 控制类是控制系统中对象之间的交互，通常每个用例都是一 个控制类。
控制类的UML表示
课堂作业
图中的实体类为： 图中的控制类为： 图中的边界类为：
内容提纲
1、面向对象分析概念
• 分析类：边界类、控制类、实体类 • 用例实现
分析类的类型
–实体类：表示系统存储和管理的永久信息 –边界类：表示参与者与系统之间的交互 –控制类：表示系统在运行过程中的业务控制逻辑
实体类
实体类
–描述必须存贮的信息及其相关行为 –通常对应现实世界中的“事物”
实体类与数据库中的表对应，类的实例对应于表中的一条 记录；类中的属性和记录中的字段对应。
思考：如何识别MiniLibrary的实体类？
MiniLibrary：识别实体类
定义交互行为
交互图可以将用例和分析对象联系在一起，实现将 用例的行为分配到所识别的分析类中，并且帮助开 发人员发现和补充前面遗漏的分析类。
MiniLibrary：“登记借书”基本 流
MiniLibrary：“登记借书”基本 流
事件，不要描述窗口组件等界面的组成元素； –在分析阶段，力求使用用户的术语描述界面； –边界类实例的生命周期并不仅限于用例的事件流， 如果两
个用例同时与一个参与者交互，那么它们有可能 会共用一个边界类，以便增加边界类的复用性。
MiniLibrary：识别边界类
识别分析类
识别控制类
–控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物。
实体类的UML表示
边界类
边界类
–描述外部的参与者与系统之间的交互 –类型：用户界面、系统接口、设备接口
体进行隔离 控制类是控制系统中对象之间的交互，通常每个用例都是一 个控制类。
控制类的UML表示
课堂作业
图中的实体类为： 图中的控制类为： 图中的边界类为：
内容提纲
1、面向对象分析概念
• 分析类：边界类、控制类、实体类 • 用例实现
分析类的类型
–实体类：表示系统存储和管理的永久信息 –边界类：表示参与者与系统之间的交互 –控制类：表示系统在运行过程中的业务控制逻辑
实体类
实体类
–描述必须存贮的信息及其相关行为 –通常对应现实世界中的“事物”
实体类与数据库中的表对应，类的实例对应于表中的一条 记录；类中的属性和记录中的字段对应。
思考：如何识别MiniLibrary的实体类？
MiniLibrary：识别实体类
定义交互行为
交互图可以将用例和分析对象联系在一起，实现将 用例的行为分配到所识别的分析类中，并且帮助开 发人员发现和补充前面遗漏的分析类。
MiniLibrary：“登记借书”基本 流
MiniLibrary：“登记借书”基本 流
事件，不要描述窗口组件等界面的组成元素； –在分析阶段，力求使用用户的术语描述界面； –边界类实例的生命周期并不仅限于用例的事件流， 如果两
个用例同时与一个参与者交互，那么它们有可能 会共用一个边界类，以便增加边界类的复用性。
MiniLibrary：识别边界类
识别分析类
识别控制类
–控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物。
实体类的UML表示
边界类
边界类
–描述外部的参与者与系统之间的交互 –类型：用户界面、系统接口、设备接口
UML用况图
第3章 用况图
3.1 系统边界 3.2 参与者 3.3 用况 3.4 用况图 3.5 用况分析 3.6 高级用况建模 3.7 检查与调整 3.8 例题
1
第3章 用况图
什么是用户需求？
用户需求即用户对所要开发系统提出的各种要求和 期望。 它包括系统的功能、性能、可靠性和保密要求以及 交互方式等技术性要求和资金额度、交付时间、资源使 用限制等非技术性要求。
其他子系统 其上级系统
3、设备
所有与系统交互的设备
监视器、鼠标、键盘等标准用户接口 设备，不算 外部传感器、受控马达等算
13
到此，我们找出食堂管理系统的参与者
参与者间的关系
在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。
参与者间的泛化关系 示例：
14
第3章 用况图
识别和组织参与者的策略：
27
第3章 用况图
（1）包含关系 起因： 两个或多个用况中有重复行为，把重复行为放在同一个 用况中，原用况引入该用况。 将过长用况分解 A到B的包含关系：用况A在它内部说明的某一位置显式的 使用用况B的行为结果
<<include>>
<<include>> 记录成绩 <<include>> 保存成绩
测试效果差，因为测试人员不明白软件要做什么 支付了客户并不想要的产品
3
第3章 用况图
软件项目中，40%-60%的问题都是在需求分析阶段 埋下的隐患，在需求审核上投入1个小时，可节省10倍以上 错误更正时间，返工开工占开发总费用的40%，而70%80%的返工是由需求方面的错误导致。
成功有效的需求开发和需求管理能为组织节省大量时 间和金钱。 需求提取：可能是软件开发中最困难、最关键、最容易出错， 最需沟通的方面（引导用户说出他们想要的东西：面谈、 问卷、观察、文档、原型法等——记录下需求） Ivar Jacobson 从1967年开始在爱立信公司所从事的近 20多年对大量不同电话呼叫类型建模的工作经验，发明了 use case概念。
3.1 系统边界 3.2 参与者 3.3 用况 3.4 用况图 3.5 用况分析 3.6 高级用况建模 3.7 检查与调整 3.8 例题
1
第3章 用况图
什么是用户需求？
用户需求即用户对所要开发系统提出的各种要求和 期望。 它包括系统的功能、性能、可靠性和保密要求以及 交互方式等技术性要求和资金额度、交付时间、资源使 用限制等非技术性要求。
其他子系统 其上级系统
3、设备
所有与系统交互的设备
监视器、鼠标、键盘等标准用户接口 设备，不算 外部传感器、受控马达等算
13
到此，我们找出食堂管理系统的参与者
参与者间的关系
在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。
参与者间的泛化关系 示例：
14
第3章 用况图
识别和组织参与者的策略：
27
第3章 用况图
（1）包含关系 起因： 两个或多个用况中有重复行为，把重复行为放在同一个 用况中，原用况引入该用况。 将过长用况分解 A到B的包含关系：用况A在它内部说明的某一位置显式的 使用用况B的行为结果
<<include>>
<<include>> 记录成绩 <<include>> 保存成绩
测试效果差，因为测试人员不明白软件要做什么 支付了客户并不想要的产品
3
第3章 用况图
软件项目中，40%-60%的问题都是在需求分析阶段 埋下的隐患，在需求审核上投入1个小时，可节省10倍以上 错误更正时间，返工开工占开发总费用的40%，而70%80%的返工是由需求方面的错误导致。
成功有效的需求开发和需求管理能为组织节省大量时 间和金钱。 需求提取：可能是软件开发中最困难、最关键、最容易出错， 最需沟通的方面（引导用户说出他们想要的东西：面谈、 问卷、观察、文档、原型法等——记录下需求） Ivar Jacobson 从1967年开始在爱立信公司所从事的近 20多年对大量不同电话呼叫类型建模的工作经验，发明了 use case概念。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求技术种类 用例(Use case)
用户故事 (user story) 需求特性
(Feature)
描述
描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险 承担人，Stakeholder)之间就系统的行为所达成的契约
由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编 写，其长度约为三句话左右
Ivar Jacobson 从1967年开始在爱立信公司所从事的近 20多年对大量不同电话呼叫类型建模的工作经验，发明了use case概念。
.
4
需求技术
获取软件的需求是软件开发过程的重要难题，在当今的软件需求的实践中， RUP过程中的用例技术、XP中的用户故事（User Story）技术、FDD的Feature 描述技术是获取需求的最佳技术，这三个技术的共同点是：站在用户的角度看 待系统、定义系统 ；使用用户能够看懂的语言来描述系统，定义系统．三种 需求技术的特点见表6-1所示。
2、通过找出与系统交互的外部事物,说明它们如何与系统 交互更易于对系统进行探讨和理解。
3、用况图是进行OOA的第一步工作,对OOD阶段的人机交 互设计和系统测试来说,用况也是非常重要的。
.
6
3.1 系统边界
第3章 用况图
系统边界：一个系统所包含的所有系统成分与系统以外事物 的分界线。
对系统的组成认识： 系统：被开发的计算机软硬件自身 系统成分：在OOA/OOD中定义的那些系统元素 系统外部实体：人员、设备、外系统
就是一个小的，具有客户价值的功能，通常表示为<action><result><object>
•表6-1 三种获取需求的技术
.
5
第3章 用况图
软件开发的途径：首先要准确地描述用户需求中的功能需 求,形成功能规格说明（SRS）。（大多数情况下,使用的是自 然语言。）
用况图的作用：
1、实现对功能需求描述。用于对系统的功能及与系统进 行交互的外部事物建模。
参与者间的泛化关系 示例：
.
14
第3章 用况图
识别和组织参与者的策略：
启动系统行为的参与者——最容易识别的参与者 从用户角度考虑怎样使用这个系统，重点考虑上述三种
类型的参与者 记录参与者责任 通过识别继承关系，组织参与者
我们给出的参与者可否使用继承关系组织？
第3章 用况图
3.1 系统边界
3.2 参与者
3.3 用况
3.4 用况图
3.5 用况分析
3.6 高级用况建模
3.7 检查与调整
3.8 例题
.
1
第3章 用况图
什么是用户需求？ 用户需求即用户对所要开发系统提出的各种要求和
期望。 它包括系统的功能、性能、可靠性和保密要求以及
交互方式等技术性要求和资金额度、交付时间、资源使 用限制等非技术性要求。
参与者命名，应是最能描述其功能的合适名称。
避免为代表人的参与者起一个实际人名。 张三、李四
要以他们使用系统时的工作头衔作为参与者命名。
教师、开发 人员等
即使工作头衔不同，但所做操作相同，也需要将其合
并。
讲师、助教、副教授、教授
教师
.
12
第3章 用况图
3.2.2 识别参与者
1、人员
从直接使用系统的人员发现参与者。强调直接使用
超市-收款员（顾客） 某些事物即使属于问题域，也与系统责任没有什么关系。
超市-保安
.
8
第3章 用况图
系统是由一条边界图包围起来的未知空间，系统只 通过有限几个接口与外部交互。因此，把内外交互情况 描述清除就确切定义了系统需求。
1．用例图的认识
用例图是描述用例、参与 者及其关系的图。与所有UML 的其它图一样，用例图可以包 括注释、约束。
注意：特定的人在系统中扮演不同的角色，因此要分 属不同的参与者
2、外部系统
所有与系统交互的外部应用系统都是参与者
其他子系统 其上级系统
3、设备
监视器、鼠标、键盘等标准用户接口
所有与系统交互的设备 设备，不算
外部传感器、受控马达等算
到此，我们找出食堂管理系统. 的参与者
13
参与者间的关系
在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。
收款
超市收款员
检查货物 检查会员卡
.
10
第3章 用况图
参与者是虚拟的概念：可以是人、设备、外系统。一 个人可以扮演多个角色。
参与者可以请求系统提供服务 参与者也可以响应系统发出的请求
所有参与者的请求/响应的完全集成构成了可以觉察到 的系统边界。
表示法：
顾客
《actor》 外系统
.
11
第3章 用况图
对分析员而言,功能需求是分析阶段要考虑的核心因 素。
.
2
第3章 用况图
软件开发中的常见现象（严峻的现实）： 用户提出的要求不完整、不准确 需求经常变化，工作没完没了 开发后期才发现误解了需求 功能都实现了，但由于性能，使用方面问题导致用户不满 客户的许多增强需求未及早提出，导致软件后期维护费用 陡升 测试效果差，因为测试人员不明白软件要做什么 支付了客户并不想要的产品
.
3
第3章 用况图
软件项目中，40%-60%的问题都是在需求分析阶段 埋下的隐患，在需求审核上投入1个小时，可节省10倍以上 错误更正时间，返工开工占开发总费用的40%，而70%80%的返工是由需求方面的错误导致。
成功有效的需求开发和需求管理能为组织节省大量时间 和金钱。
需求提取：可能是软件开发中最困难、最关键、最容易出错， 最需沟通的方面（引导用户说出他们想要的东西：面谈、 问卷、观察、文档、原型法等—— 用况图
现实世界中的事物与系统的关系包括如下几种情况:
某些事物作为系统成分位于系统边界内。 超市-商品
某些事物将是与系统进行交互的参与者，系统中没有相
应的成分作为它们的抽象表示。它们只是系统边界外的
参与者。
超市-收款员
某些事物可能既有一个对象作为其抽象描述，而本身(作 为现实世界中的事物)又在系统边界以外与系统进行交互。
图中的元素包括：参与者、 用例、一个方框和一些表示关 系的连接线，所有的用例都位 于方框之内，该方框称为“系 统边界”。 方框内是棋牌管 理系统的多个用例，方框外是 外部参与者。
.
9
第3章 用况图
3.2 参与者
3.2.1 概念与表示法
1、参与者的语义及表示法
参与者：是为了完成某个任务，而与系统进行交互的 实体。是用户相对系统而言所扮演的角色