面向对象技术引论课件 第四章(华大)

对系统的语境建模，包括围绕整个系统画一条线， 并声明有哪些参与者位于系统之外并与系统进行交互。
Credit Card validation System
Perform Card
Customer
Process Customer bill
Reconcile
transaction Manage Customer account
在该语境中，还有代表机构的参与者（出现在模型 的右边），如零售机构（顾客通过该机构刷卡，购买 商品或获得服务）、主办金融机构（负责信用卡帐户 的结帐服务）。在现实世界中，这两个参与者不是人， 而可能是一个软件密集型系统。
（2）对系统语境建模所要遵循的策略（步骤）
通过以下几组事物来识别系统周围的参与者：
主事件流：在系统提示顾客输入PIN编号时用况开始。 顾客通过按键输入PIN编号；顾客按“输入”按钮确认 登录；系统校验该PIN号是否有效。如果有效，系统 承认这次登录，该用况结束。
异常事件流1：顾客可以在任何时间通过按“取消”按钮 取消一个事务，这样该用况重新开始。顾客的帐户未 发生改变。 异常事件流2：顾客可以在确认之前的任何时刻消除 PIN号，并重新输入一个新的PIN号。 异常事件流3：如果顾客输入一个无效的PIN号，用况 重新开始；如果连续3次输入无效的PIN号，系统将取 消整个事务，并在60秒内阻止该顾客与ATM交易。
Place Order
<<include>>
Track Order
Validate User
<<include>>
3） 用况之间的延伸关系
用况之间的延伸关系表示基础用况在由延伸用况 间接地说明的一个位置上隐式地合并了另一个用况的 行为。
基础用况可以单独存在，但在一定条件下，它 的行为可以被另一个用况的行为延伸。
该基础用况只是在一个被称为它的延伸点的确 定位置上被延伸。
可以将延伸关系理解为延伸用况把行为放入基 础用况中。 可以将延伸关系表示成一个构造型为extend的 依赖关系。
例：Place Order（发出订单）用况和Place rush Order（发出急需单号）用况之间存在延伸关系。
延伸点
Place Order <<extend>> Extension point (set priority) Set priority
Retail institution
Individual Customer
Corporate Customer
Sponsoring financial institution
上图（右图）显示了一个信 用卡验证系统的语境，它强 调围绕在系统周围的参与者， 这些参与者分为两类：人和 其他事物。 出现在模型左边的的参与者是顾客，分为个人顾客 和团体顾客（存在泛化关系）。这些参与者是人与系 统交互时所扮演的角色。
1）公共特性
用况图只是图的一种特殊类型，它具有与所有 UML图一样的公共特征，即一个名称以及投影到模型 上的图形化的内容。
2）内容
用况图通常包括： • 用况 • 参与者 • 依赖（包含、延伸）、泛化及关联关系 • 注解和约束。
3）一般应用
用况图用于对系统的静态用况视图建模。该视图 主要支持对系统行为的描述 ，即描述该系统在它的周 边环境的语境中所提供的外部可见服务。 具体而言，对系统的静态用况视图建模时，一般 会以对系统的语境建模和对系统需求建模两种方式来 使用用况图。 （1）对系统的语境建模 系统的语境：给定一个系统，会有一些事物存在于 系统的内部，一些事物存在于系统的外部，所有存在 于系统外部并与系统进行交互的事物（参与者）构成 了系统的语境。语境定义了系统存在的环境。
需要从系统中得到帮助以完成其任务的组； 执行系统的功能时所必须的组；
与外部硬件或其他软件系统进行交互的组； 为了管理和维护而执行某些辅助功能的组。
（2）对系统语境建模所要遵循的策略（续）
利用泛化关系将相类似的（具有相同性质的）参与 者组织成一般/特殊的结构层次。 在需要加深理解的地方，为每个参与者提供一个构 造型。
下图是对信用卡验证系统语境模型（用况图）的扩充，它 加入了一些用况，这些用况对于一般顾客虽然不可见，但仍是 系统的基本行为。
Credit Card validation System
Customer
Perform Card transaction
Report on account status
第四章 用况和用况图
一个用况代表一个系统或系统的一部分的行为， 它的主要用处是：捕获与描述系统需求，同时也驱动 整个开发过程。
用况图也称为用况模型，用于对系统的用况视图 建模（用况视图是系统体系结构的五大视图之一）， 也可以认为是对系统的外部行为建模。 多数情况下，包括对系统、子系统或类的语境建 模，或对这些元素的行为需求建模。它对可视化、详 述和文档化一个元素的行为是非常重要的。
从非功能性需求中发现用况的附加成分。 用况除了描述功能需求之外，还可以说明某些非 功能性需求，例如对某个用况特定的性能、可用性、 准确度和安全性等的需求。这些都有必要作为用况的 附加成分，附加到相应的用况中。
例如：对于“取款”这一用况而言，应该附 加下面的性能要求：
银行储户从指定取款数量到得到相应的货币的响 应时间在所有用况实例的95%中应该小于30秒。
单独的名称称为简单名，在用况名前加上它所属 的包的名称，称为路径名。
Place order
简单名
路径名
Validate user
Sensors:: Calibrate location
（4）用况与参与者
一个参与者表示用况的使用者在与这些用况进行 交互时所扮演的角色的一个紧密的集合。 参与者所代表的角色有：人、硬件设备，或甚至 是另一个系统。 例如：如果你在银行工作，你可能是一个贷款员， 如果你在该银行有存款，那么你同时也扮演一名顾 客的角色。所以，一个参与者的一个实例代表以一 种特定的方式与系统进行单独的交互。 注意：尽管在模型中使用参与者，但参与者实际上 并不是系统的一部分。
将这些参与者放入用况图中，并说明从每个参与者 到系统的用况之间的通信路径。
（3）对系统的需求建模 需求是一个系统的设计特性、特征或行为。当陈述 一个系统的需求时，就相当于陈述建立在系统外部的 事物和系统之间的一份契约，契约上声明了期望系统 做什么。 对一个系统的需求建模，主要是说明这个系统应该 做什么（从系统外部的一个视点出发），而不考虑系 统应该怎样做。 用况图说明了系统所能提供的行为。因此用况图使 我们能够将系统看作一个黑盒子，仅仅只能观察系统 外部有什么，系统怎样与那些外部事物相互作用，但 却看不到系统内部是如何工作的。
取款
存款 银行储户
在不同帐户 间转帐
1.用况模型（续）
用况模型是所有可能使用系统（用况）的方式的完 整的规格说明，它可以用作与客户签定合同的一部分。
用况模型用来与用户和客户在“系统应该做什么” 方面达成共识。也即用况模型表示功能性需求。
用况模型用用况图来表示。
2. 用况图
术语：用况图（use case diagram）是显示一组用况、 参与者以及它们之间关系的图。
4.1 用况
1. 用况（use case） （1）用况的定义
用况是对一组动作序列（业务过程）的描述，系 统执行这些动作将产生一个对特定的参与者有价值而 且可观察的结果。
（2）用况的图形符号
在图形上，一个用况用一个椭圆表示。
取款
（3）用况的名称
每一个用况都必须有一个区别于其他用况的名称。 用况名称（name）是一个字符串。在实际应用中，用 况的名称是简短的主动语态的动词词组，用来描述被 建模的系统的某些行为。
Place rush Order
延伸关系用于对可能被用户看作是可选系统行 为的用况的一部分建模（Place rush Order是可选 的）。
通过这种方式，可以把可选行为从必须行为中 分离出来。
实例应用：一个零售系统将与订货的顾客进行交互， 然后，系统将装运订货、并通告顾客付帐。可以通过将 这些元素的行为声明为用况来对系统的行为建模。 所声明的用况包括：Place order、Track order、 Ship order和Bill customer。 用况模型如下图所示：
2. 用况之间的关系
用况之间存在泛化关系、包含关系和延伸关系， 我们可以利用这些关系来组织用况。
1） 用况之间的泛化关系
用况之间的泛化关系就像类之间的泛化关系，子 （特殊）用况继承父（一般）用况的行为和含义；子 用况还可以增加或覆盖父用况的行为；子用况可以出 现在父用况出现的任何位置。 例：ATM系统中的Validate User用况，根据校验设备 的不同可以特例化为以下二个特殊用况： Check Password用况和Retinal Scan用况。
参与者 出纳员 顾客 发起或参加的活动 登录、用现金结算 购买商品、退还商品
基于事件的方法 a. 识别出系统必须响应的外部事件。
b. 把事件与参与者及用况联系起来。
4.2 用况模型和用况图
1.用况模型
系统的所有参与者和用况以及用况之间的关系 （依赖、延伸、泛化等）构成用况模型。
参与者“银行储户” 使用ATM从帐户中 取款，或存款到帐 户中，或在不同的 帐户之间转帐。上 述行为可以由三个 用况与“银行储户” 这个参与者之间的 交互来表示。
参与者的图形符号是人形图符
Customer
可以定义参与者的一般种类（比如Customer） 并通过泛化关系将其特殊化（比如Commercial Customer）。
Customer Commercial Customer
（5）用况与事件流
可以通过足够清晰的、外部人员容易理解的文字 描述一个或一些事件流来说明一个用况的行为，也即 通过事件流来详述用况。 事件流中应该包含用况何时开始、何时结束，用 况何时和参与者交互，什么对象被交换，以及该行为 的基本流（主事件流）和可选择流（异常事件流）。 例：在ATM系统中，可以采用下面的主事件流和异常 事件流来描述用况Validate User的行为：