企业综合信息管理系统UML需求建模用例图活动参考课件

扩展用例依赖于被扩展用例（基本用例），它不是完 整的独立用例，无法单独执行，因此一定没有活动者 指向扩展用例；
扩展用例不一定每次都被执行和调用。 扩展用例
-12-
用例间的关系3-泛化关系（ generalization）
一个用例和其几种情形的用例间构成泛化； 往往将父用例用抽象用例（abstract）表示（即，父用例
-54-
3 客房预订分析
客房预订涉及到“学生”，“订单”，“宾馆”和“客房” 几个类
假设一个订单可以预订到多个客房。
-55-
4 画出完整类图
-56-
本章目录
2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架
2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和通信图 2.11 状态图和活动图 2.12 组件图和部署图
而在OrderItem中有一个stateChange ()方法和 deliverState，不难猜出它就是用于改变其“是否交给 收货人”标志位的。
-29-
先调用Order的dispatch ()方法，它将根据其包含的 OrderItem中产品信息，来按供应商户分拆成若干个 DeliverOrder。商户登录系统后就可以获取其 DeliverOrder，并在执行完成后再调用close ()方法。 此时，就将调用OrderItem的stateChange()方法来改 变其状态。同时再调用Order的close()方法，判断该 Order的所有的OrderItem是否都已经送到了，如果是 就将其真正close()掉。
-37-
-38-
2.8.4 类图的构建步骤
类图的构建步骤 一个关于图书馆图书借阅管理的类图 一个实现旅游宾馆预订的类图

UML统一建模语言
三、用例的重要元素
2、用例的粒度
用例的粒度指的是用例所包含的系统效力或功能单元的多少。用例的 粒度越大，用例包含的功能越多，反之那么包含的功能越少。
假设用例的粒度很小，得到的用例数就会太多。反之，假设用例的粒 度很大，那么得到的用例数就会很少。
假设用例数目过多会呵斥用例模型过大和引入设计困难大大提高。 假设用例数目过少会呵斥用例的粒度太大，不便于进一步的充分分析。
UML统一建模语言
一、 什么叫用例图
2、用例图的作用
用例图是需求分析中的产物，主要作用是描画参与者和用例之间的关 系，协助开发人员可视化的了解系统的功能。借助于用例图，系统用户、 系统分析人员、系统设计人员、领域专家可以以可视化的方式对问题进展 讨论，减少了大量交流上的妨碍，便于对问题达成共识。
用例图可视化地表达了系统的需求，具有直观、规范等优点，抑制了 纯文字性阐明的缺乏。
UML统一建模语言
三、用例的重要元素
1、识别用例
任何用例都不能在短少参与者的情况下独立存在。同样，任何参与者 也必需求有与之关联的用例。所以识别用例的最好方法就是从分析系统参 与者开场，在这个过程中往往会发现新的参与者。
可以经过以下问题来寻觅用例： 1 参与者希望系统提供什么功能？ 2 参与者能否会读取、创建、修正、删除、存储系统的某种信息？假 设是的话，参与者又是如何完成这些操作的？ 3 参与者能否会将外部的某些事件通知给系统？ 4 系统中发生的事件能否通知参与者？ 5 能否存在影响系统的外部事件。
UML统一建模语言
二、用例图的构成要素
3、系统边境
在工程开发过程中，边境是一个非常重要的概念。这里说的系统边境 是指系统与系统之间的界限。通常我们所说的系统可以以为是由一系列的 相互作用的元素构成的具有特定功能的有机整体。

异常事件流处理：
（1）标识码有效性检查失败，允许学生重新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲
突时，系统提示重选。
2021/1/16
-
15
3.2.6 用例之间的关联
1．继承关联
2．扩展关联
2021/1/16
-
16
3．包含关联 4．使用关联
2021/1/16
-
17
考虑用例的 关联类型
2021/1/16
-
18
2021/1/16
-
19
3.2.7 用例图实例
2021/1/16
-
20
3.3 定义系统的对象和类
类 - 责 任 - 协 作 者 （ Class-ResponsibilityCollaborator， 简称CRC）技术：
2021/1/16
-
41
（4）“采购管理子系统”中的用例（第三层） • 制定采购计划； • 签订采购合同； • 货物入库检验； • 支付货款； • 检查合同履约。 （5）“库存管理子系统”中的用例（第三层） • 入库管理； • 出库管理； • 库存管理。
2021/1/16
-
42
3.6.5 分层绘制用例图
2021/1/16
-
35
2．具体功能要求
本案例只对其中的“进销存管理子系统”进行详细的需 求分析用例建模。
（1）销售管理 1）制定销售计划 2）与客户签订销售合同 3）检查合同履约率 4）生产调度管理部门组织生产 5）库存管理部门对产品进行入库、出库处理 6）财务管理部门收取客户货款 7）售后服务

出转换的条件应当是互斥的，这样可以保证只有 一条出转换能够被触发。 一个合并有两个带条件的入转换和一个出转换， 合并表示从对应的分支开始的条件行为的结束。
分支与合并
⑤ 分叉与汇合
分叉用于将动作流分为两个或者多个并发运行的分支，而 汇合则用于同步这些并发分支，以达到共同完成一项事务 的目的。
1. 描述工作流
订货处理活动图
2. 描述工程组织过程
建筑工程过程活动图
3. 描述算法流程
2 活动图的图形表示
在UML中，活动表示成圆角矩形。 如果一个活动引发下一个活动，两个活动的图
标之间用带箭头的直线连接。 活动图也有起点和终点。 活动图中还包括分支与合并、分叉与汇合等模
型元素。分支与合并的图标和状态图中的判定 的图标相同，而分叉与汇合则用一条加粗的线 段表示。
③ 动作流
所有动作状态之间的转换流称之为动作流。 活动图的转换也用带箭头的直线表示，箭头的
方向指向转入的Leabharlann 向。活动流④ 分支与合并
分支一般用于表示对象类所具有的条件行为。 条件行为用分支和合并表达。 在活动图中分支与合并用空心小菱形表示。 一个分支有一个入转换和两个带条件的出转换，
分支
分叉
Activity2
Activity1
活动起点 活动
Activity3
合并
Activity4
汇合
Activity5
Activity6
Activity7
PPT课件
活动终点 6
活动图的图形表示
3 活动图的组成元素
组成UML的图形元素： ① 动作状态（Action State） ② 活动状态（Activity State） ③ 动作流（Action Flow） ④ 分支（Branch）与合并（Merge） ⑤ 分叉（Fork）与汇合（Join） ⑥ 泳道（Swimlane） ⑦ 对象流（Object Flow）

系统用例着重于要设计的软件系 统。参与者如何与软件系统进行 交互？我们在系统用例说明中书 写的事件流应该足够详细，从而 用作编写系统测试脚本的出发点。 系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
后记Ｉ－系统分析
ห้องสมุดไป่ตู้
员工报销申请 用例实现的分 析类时序图
后记II-系统分析
VOPC类图
后记II-系统设计

系统架构 选择什么框架 基于框架和架构的时序图
• • • • • • • • • • • • • • • • • • • •
1、想要体面生活，又觉得打拼辛苦；想要健康身体，又无法坚持运动。人最失败的，莫过于对自己不负责任，连答应自己的事都办不到，又何必抱怨这个世界都和你作对？人生的道理很简单，你想要什么，就去付出足够的努力。 2、时间是最公平的，活一天就拥有24小时，差别只是珍惜。你若不相信努力和时光，时光一定第一个辜负你。有梦想就立刻行动，因为现在过的每一天，都是余生中最年轻的一天。 3、无论正在经历什么，都请不要轻言放弃，因为从来没有一种坚持会被辜负。谁的人生不是荆棘前行，生活从来不会一蹴而就，也不会永远安稳，只要努力，就能做独一无二平凡可贵的自己。 4、努力本就是年轻人应有的状态，是件充实且美好的事，可一旦有了表演的成分，就会显得廉价，努力，不该是为了朋友圈多获得几个赞，不该是每次长篇赘述后的自我感动，它是一件平凡而自然而然的事，最佳的努力不过是：但行好事，莫问前程。愿努力，成就更好的你！ 5、付出努力却没能实现的梦想，爱了很久却没能在一起的人，活得用力却平淡寂寞的青春，遗憾是每一次小的挫折，它磨去最初柔软的心智、让我们懂得累积时间的力量；那些孤独沉寂的时光，让我们学会守候内心的平和与坚定。那些脆弱的不完美，都会在努力和坚持下，改变模样。 6、人生中总会有一段艰难的路，需要自己独自走完，没人帮助，没人陪伴，不必畏惧，昂头走过去就是了，经历所有的挫折与磨难，你会发现，自己远比想象中要强大得多。多走弯路，才会找到捷径，经历也是人生，修炼一颗强大的内心，做更好的自己！ 7、“一定要成功”这种内在的推动力是我们生命中最神奇最有趣的东西。一个人要做成大事，绝不能缺少这种力量，因为这种力量能够驱动人不停地提高自己的能力。一个人只有先在心里肯定自己，相信自己，才能成就自己！ 8、人生的旅途中，最清晰的脚印，往往印在最泥泞的路上，所以，别畏惧暂时的困顿，即使无人鼓掌，也要全情投入，优雅坚持。真正改变命运的，并不是等来的机遇，而是我们的态度。 9、这世上没有所谓的天才，也没有不劳而获的回报，你所看到的每个光鲜人物，其背后都付出了令人震惊的努力。请相信，你的潜力还远远没有爆发出来，不要给自己的人生设限，你自以为的极限，只是别人的起点。写给渴望突破瓶颈、实现快速跨越的你。 10、生活中，有人给予帮助，那是幸运，没人给予帮助，那是命运。我们要学会在幸运青睐自己的时候学会感恩，在命运磨练自己的时候学会坚韧。这既是对自己的尊重，也是对自己的负责。 11、失败不可怕，可怕的是从来没有努力过，还怡然自得地安慰自己，连一点点的懊悔都被麻木所掩盖下去。不能怕，没什么比自己背叛自己更可怕。 12、跌倒了，一定要爬起来。不爬起来，别人会看不起你，你自己也会失去机会。在人前微笑，在人后落泪，可这是每个人都要学会的成长。 13、要相信，这个世界上永远能够依靠的只有你自己。所以，管别人怎么看，坚持自己的坚持，直到坚持不下去为止。 14、也许你想要的未来在别人眼里不值一提，也许你已经很努力了可还是有人不满意，也许你的理想离你的距离从来没有拉近过......但请你继续向前走，因为别人看不到你的努力，你却始终看得见自己。 15、所有的辉煌和伟大，一定伴随着挫折和跌倒；所有的风光背后，一定都是一串串揉和着泪水和汗水的脚印。 16、成功的反义词不是失败，而是从未行动。有一天你总会明白，遗憾比失败更让你难以面对。 17、没有一件事情可以一下子把你打垮，也不会有一件事情可以让你一步登天，慢慢走，慢慢看，生命是一个慢慢累积的过程。 18、努力也许不等于成功，可是那段追逐梦想的努力，会让你找到一个更好的自己，一个沉默努力充实安静的自己。 19、你相信梦想，梦想才会相信你。有一种落差是，你配不上自己的野心，也辜负了所受的苦难。 20、生活不会按你想要的方式进行，它会给你一段时间，让你孤独、迷茫又沉默忧郁。但如果靠这段时间跟自己独处，多看一本书，去做可以做的事，放下过去的人，等你度过低潮，那些独处的时光必定能照亮你的路，也是这些不堪陪你成熟。所以，现在没那么糟，看似生活对你的亏欠，其 实都是祝愿。

用例与UML用例图
学习目标
上讲回顾 用例的概念 用例分析的过程 使用用例模型捕获系统需求
上讲回顾
UML的全称__________________________________. UML的图基本构造块包括_______和______. UML的基本构造块中的关系包括哪几种__________. UML的图包括哪几种____________. 动态图包括哪些_____________________________. 静态图包括哪些_____________________________. RUP是______________________________________.
评价应聘者
录用应聘者
录用应聘者
拒绝应聘者
拒绝应聘者
参与者的泛化
Employee Manager
面试面应试聘应者 聘者 评评价价应应聘聘者 者 录录用用应应聘聘者者
拒拒绝绝应应聘者聘者
参与者的泛化
• 只有在子参与者使用了父参与者所使用的 所有用例时，参与者泛化才是合适的。
• 参与者泛化会带来不必要的复杂性，所以 不要强加一个不存在的关系。
用例的特点 ： 用例捕获某些用户可见的需求，实现一个具 体的用户目标。 用例由参与者激活，并提供确切的值给参与 者。 用例可大可小，但它必须是对一个具体的用 户目标实现的完整描述。
参与者（Actor）
参与者是指对用例所描述的事件序列的发 起者。
参与者可以是一个人、另一个系统、一台 硬件设备或某段时间的流逝。
后置条件：顾客得到现金
事件流
（1）事件流由简短步骤的序列组成。 （2）陈述性的、带编号、按时间排序 （3）每个步骤简单地描述了什么东西执
行了什么动作。 每个步骤应该具有如下格式： <编号> <某事> <行为> （4）一个事件流仅描述用例中的一条路径， 不包括其它的分支。

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 参与者的确定
凡是与系统进行信息交互（包括数据信息与控制信息交换）的外部事 物可以确认为参与者。

2021/3/26
20 UML建模语言 ppt课件
手机类图案例分析2
请用UML类图描述如下关系： • 每个品牌的手机开关机的功能相同 • 每个品牌备wifi功能,但是普通手
机不具备此功能、而有些手机具有蓝牙的功能 • 所有手机都可以打电话,发短信
2021/3/26
21 UML建模语言 ppt课件
时序图（Sequence Diagram）
• 时序图（Sequence Diagram）是强调消息时间 顺序的交互图。时序图描述类系统中类和类之间 的交互，它将这些交互建模成消息交换。时序图 是一个模型，用于描述对象组如何随着时间在某 些行为方面进行协作。
目
1. UML介绍
录
2. 用例图
3. 类图
4. 顺序图
5. 状态图
UML介绍
• 什么是软件危机 • 什么是软件工程 • UML概念、发展、意义
2021/3/26
2 UML建模语言 ppt课件
UML用例图
• 用例图概述 • 用例图包含的2元素4关系 • 用例图实例：京东商城用例图
2021/3/26
}
2021/3/26
14 UML建模语言 ppt课件
类图—泛化关系(generalization）
• 泛化关系实际上就是继承关系，他是依赖关系的 特例
public abstract class DaoSupport{ public void save(Object entity){ } public void delete(Object id){ }
单向一对 一关系
Person 1
-card IDCard 1
双向一对 一关系
Person -person 1

-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页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。