UML系统建模及分析设计

一个明确的有效地目标才是一个用例的来源。 一个真实的目标应当完备地表达执行者的期望。 一个有效地目标应当在系统边界内，由主角发动，并具有
明确的后果。
应当先建立业务用例模型，然后再从业务用例模型向系统 用例模型映射。
注意用例图的层次，从系统到子系统逐层建立用例图。
2020/10/1
软件工程方法
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2020/10/1
软件工程方法
12
储户 信用卡
银行人员 银行会计
2020/10/1
软件工程方法
13
2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系
学生
小学生
中学生
大学生
2020/10/1
2020/10/1
软件工程方法
29
3.描述用例
用例名： 简单名： 路径名：
2020/10/1
软件工程方法
30
用例文字描述
更详细地描述 用例的功能
错，这是一个过程步骤，不是完整目标
选择服务
错，这是一个过程步骤，不是完整目标
取钱
对，这是一个完整有效的目标
存钱
对，这是一个完整有效的目标
挂失卡片
对，这是一个完整有效的目标
交纳费用
对，这是一个完整有效的目标
警示骗子
错，已超出了边界范围
三次错误吞没卡片 错，这是一个业务规则，限定业务的 范围
2020/10/1
软件工程方法
17
回执性。 用例执行完毕，向执行者提供可识别的 返回值。用例的执行结果对参与者来说是可观测 的和有意义的。
如，系统会监控参与者在系统里的操作，并在参与者删除数据之 前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应 该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测 的，它应该在系统用例分析阶段定义。
2020/10/1
软件工程方法
2
1.1 建造需求模型——用例建模
用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对 典型用例的分析，使开发者能够有效地了解用户的需求。
对于正在构造的新系统用例描述系统应该作什么? 对于已构造完毕的系统用例则反映了系统能够完成什么样的功能?
用例建模的主要目标是：
本科生
Hale Waihona Puke Baidu
研究生
硕士研究生
博士研究生
软件工程方法
14
（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者
主动角色：Use Case的动作序列是由他先发起的，通常 系统返回最后结果
主叫方，采购人员，票据录入员等
从本质上讲,一个用例是用户与计算机之间的一次典型交 互作用。在UML中,用例被定义成系统执行的一系列动作 （功能）。
2020/10/1
软件工程方法
16
1.用例的特征
响应性。一个用例不自动执行，总是有执行者启
动。
这件事必须由一个执行者发起，执行者的愿望是用 例存在的原因。不存在没有执行者的用例，也不应 该主动启动另一个用例。
2020/10/1
软件工程方法
10
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2020/10/1
软件工程方法
11
4、该系统需要和哪些系统交互？ 答：目前还不清楚
系统用例是执行者与系统的交互，它描述了系统 的功能需求和动态行为。
系统用例用于建立系统用例模型，可通过分析系 统的业务流和控制流来寻找和确定系统用例。 （活动图）
2020/10/1
软件工程方法
23
如何获得用例——访谈
您对系统有什么期望？ 您打算在这个系统里面做些什么事情？ 您做这件事的目的是什么？ 您做完这件事情希望有一个什么样的结果？
系统为了维持正常运转需要增加的功能和信息的交互；
这些信息从何而来，到哪里去？
实现当前系统（可能是人工系统而不是自动化系统）的关 键问题是什么？
2020/10/1
软件工程方法
22
通过与用户反复交流，确定主要业务用例和次要 业务用例。
对于建立的每一个业务用例，都需要一组系统用 例来辅助和支持。（不严谨）
在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式 组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例 模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个 系统之后，还将根据用例模型设计出测试模型来对系统进行验证。
这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。 也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每 次都将越来越精化。
2020/10/1
软件工程方法
26
ATM取钱的场景中，取钱，读卡，验证账号， 打印回执单等都是可能的用例？
客户代表说：我希望这台ATM能支持跨行业 务，我插入卡片输入密码后，可以让我选择是 取钱还是存钱；为了方便，可以设置一些默认 的存取金额按钮；我可以修改密码，也可以挂 失；还有我希望可以交纳水费、电费和电话等 费用；为了安全起见，ATM上应当有警示小 心骗子的提示条，还有摄像头；如果输入三次 密码错误，卡片应当被自动吞没。
24
目标和步骤的误区
2020/10/1
软件工程方法
25
怎样确定用例的粒度？
用例的粒度（用例的大小）可大可小，一 般一个系统宜控制在20个用例左右。
用例是系统级的、抽象的描述，不是细化 的（是做什么，非怎样做）
对复杂的系统可以划分为若干子系统处理。
用例粒度的划分最标准的方法应该是：以该用 例是否完成了参与者的某个完整目的为依据的。
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
7
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。 定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
需求分析与用例建模
2020/10/1
软件工程方法
1
1 客户需求分析与用例建模
用例用于表示系统所提供的服务，它定义了系统是如何被 参与者所使用的，它描述的是参与者为了使用系统所提供
的某一完整功能而与系统之间发生的一段对话。
用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例 驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例 为目标。
用例模型由若干个用例图构成，用例图中主要描 述执行者和用例之间的关系。在UML中,构成用例 图的主要元素是用例和执行者及其它们之间的联 系。
2020/10/1
软件工程方法
5
用例建模的步骤：
•确定系统的范围和边界； •确定系统的执行者和用例； •对用例进行描述； •定义用例之间的关系； •审核用例模型。
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准； •为最终系统测试提供基准，据此验证系统是否达到功能要求；
•为项目目标进度管理和风险管理提供依据。
2020/10/1
软件工程方法
3
用例图中包含系
2020/10/1
软件工程方法
27
判断题
支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次错误吞没卡片
2020/10/1
软件工程方法
28
支持跨行业务 错，这是一个业务规则，限定业务的范 围
插入卡片
错，这是一个过程步骤，不是完整目标
输入密码
又比如，登录系统是一个有效的用例，但输入密码却不是。这是 因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权， 但输入密码却是没有意义的，输入完了呢？有什么结果吗？
2020/10/1
软件工程方法
18
完整性。 用例表示一个完整的功能，必须是一完
整的描述。 必须以向执行者提供返回值作为该用 例完整性的标志。
统、角色和用例
等三种模型元素，
以及它们之间的
关系。
贸易经理
营销人员
设置边界
更新帐目
风险分析 交易估价
《使用》 《使用》
评价
进行交易
《扩展》
超越边界
记账系统 销售人员
2020/10/1
软件工程方法
4
用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在 开发过程中保证了系统所有功能的实现,而且被用 于验证和检测所开发的系统,从而影响到开发工作 的各个阶段和 UML 的各个模型。
角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统 交换信息。
角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交 流的起点。一个执行者可用启动多个用例，而一个用例也可以被多个执 行者启动。
2020/10/1
软件工程方法
9
1.寻找和确定执行者
通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。
2020/10/1
软件工程方法
6
1.2 用例图
2020/10/1
软件工程方法
图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2020/10/1
软件工程方法
8
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
2020/10/1
软件工程方法
21
建立用例模型时，可询问？
用户(执行者)需要系统提供哪些业务功能,即系统能做什么? 用户最关心系统中哪些事件?从功能观点看,这些事件表示
什么? 用户要了解系统在工作中发生了哪些事件及其结果? 用户自己需要做什么?
用户是否要在系统中创建、删除、读、修改或存储某类业 务数据？
被动角色：系统通过调用角色来完成Use Case的动作序 列（或其中的某一个动作）
不是初始动作的发起者
当系统需要它们帮助的时候
最终是为了满足主动角色的需要
通常是机器或其他系统
用例1
2020/10/1
主角1 软件工程方法
用例2
主角2 15
1.5 确定用例
用例，就是一件事情，要完成这件事情，需要做一系列的 活动；而做一件事情可以有很多不同的方法和步骤，也可 能会遇到各种各样的意外情况，因此这件事情是由很多不 同情况的集合构成的，在UML中我们称之为场景。一个场 景就是一个用例的实例。
2020/10/1
软件工程方法
20
2．寻找和确定用例
业务用例：开始阶段，在确定用户需求过程中， 系统分析员通过与客户交流建立业务模型来发现 和确定的用例。
系统用例：系统构造阶段，系统分析和设计人员 在进行系统分析和设计时，根据系统的需求建立 的用例。
在系统开发的开端阶段，应把注意力集中在业务 用例上，在精化阶段和构建阶段再考虑系统用例。
2020/10/1
软件工程方法
19
用例的特征-动宾短语
用例必然是以动宾短语形式出现的。即，这件事必须 有一个动作和动作的受体。
例如，喝水是一个有效的用例，而“喝”和“水”却 不是。虽然生活常识告诉我们，在没有水的情况下人 是不会做出喝这个动作的，水也必然是喝进去的，而 不是滑进去的.
但是我们所见的很多用例中类似“计算”，“统计”， “报表”，“输出”，“录入”之类的并不在少数。