行为建模分析

4、系统作用者和用例之间的联系：关联关系
例子：通过用例描述软件系统的功能。 假定设计开发一个名为“位图观察器(bmpviewer)”的软件产品 它为用户提供图像显示和浏览的功能。 经过对用户提出的功能需求的分析和整理，得出的用户期望得到的 产品的功能如下： 打开一个 bitmap 文件 可对文件进行放大显示(Zoom-in) 可对文件进行缩小显示(Zoom-out) 可对文件进行浏览(Pan) 可将文件继续保存到磁盘
显示窗口
用户
5. 保存文件
位图文件
用例为软件系统的功能建模
在上页图中，还标出了和系统交互的系统作用者。 设计的是一个通用软件，其使用者可不加以分类的 名为“用户”的系统作用者。 还有些功能的执行结果将涉及软件系统之外的软/硬件对 象 这些对象也是系统作用者 “显示窗口” 代表用来显示位图的操作系统图形用户界面 的一个窗口， “位图文件” 代表保存在计算机外部存储器中的位图件，它是本 软件系统处理的对象。
场景（Scenario） 一个用例可以有多个事件流，每一个事件流是一个完整的用户对系 统的功能的使用。 它们出于同一个目的，但出于事件流不同，使得系统产生的响 应不同。 这样的用例/事件流的对应关系正是前面讲到的 UML 公用划分 机制的一个例子, 它是对系统功能使用的特例（合法或非法的）, 因此事件流是用例的实例（instance） 。 。 用例的实例在 UML 中被称为场景（Scenario） 协同（Collaboration） 用例对应着系统内部的一系列的建模元素，这些建模元素实现 了用例规定的动态行为 这些建模元素中既包括结构建模元素也包括行为建模元素 它们的共同工作构成了用例的动态行为的实现 。 这些建模元素,在 UML 中，被称为协同（Collaboration） 用例/协同也是前面提到的 UML 公用划分机制的一个例子 接口和实现的划分 用例是接口，协同是其实现 用例/协同之间的规定(接口)与实现的关系称为实现关系 (realization), 见下页图
显示窗口
用例图: 打开位图文件
这条直线在 UML 里代表关联关系。 例如，上页图中“用户”和“打开文件”用例之间的 的关联关系代表用户对软件系统的打开文件功能的使 用。
单向关联关 系
位图文件 用户 打开文件
用例图: 打开位图文件
显示窗口
关联关系 关联关系是 UML 的关系的一种，它代表两个类的对象之间的语义联 接。 未经过修饰的关联关系是双向的。 两个类之间有关联关系，代表两个类之间可以互相访问， 因而提供了它们进行交互的基础。 在用例图中使用的关联关系通常被修饰为单向的关联关系 它在模型图被表示为一条带箭头的直线 单向关联关系是关联关系的一个特例 它由关联关系经修饰而得 它意味着访问是有向的。 在处于有向关联关系中的两个类中， 位于箭头所指方向的类的对象可以被另一个类的 对象访问， 反之则不然。
因此，在分析软件系统的功能设置时 应该把重点放在描述软件系统的外部边界上 即重点考虑用户对软件系统的功能设置的合理性、方便性 和运行效率的要求 而不应该在需求分析阶段就过多地考虑软件系统的结构和 内部实现机制。 这是在对软件系统进行需求分析时， 应该遵循的一个重要原则。
软件系统不是孤立存在的 它的使用价值是通过和它所存在的环境发生交互实现的 其因此在描述软件系统的边界、 分析软件系统应具备的功能时， 应首先分析软件产品与外界环境的联系 发现外界环境中哪些对象将和软件系统产生 交互 不但需要分析共有哪些用户将要使用软件系统， 而且还需要分析软件系统的运行结果将要对哪些对象 产生影响， 这包括 指定运行结果的输出和存储的媒介 指定被软件系统运行结果控制的硬件设备， 如 显示器 打印机 工业机器人 数控机床，等等。
写文件
用户
2. 放大(ZoomIn)
显示窗口
用户
5. 保存文件
位图文件
用例为软件系统的功能建模
例如， 绘图软件 它调用操作系统提供的图形绘制接口 控制图形在显示设备上的输出 这时可以把 操作系统的的图形接口和图形输出设备 用一个系统作用者来建模。 类似的情形也可以应用于描述软件系统的计算结果的保存上 软件系统的计算结果通常都是通过操作系统的文件存取接口以 文件的形式存放在计算机的外部存储器上的， 在为软件系统的边界建模时 如果需要强调软件系统的结果的保存 就可以把操作系统的文件存取接口和文件本身用一个系统作用 者来代表。
(from 图 3.3 用例图: 打开位
事件流的描述 用例代表系统和系统作用者之间发生的一系列的事件 这些事件流构成了用户对系统功能的一次使用。 在用例图中必须对事件流进行描述，以构成一个完备的用例模型。 对事件流的描述包括四种形式，即： 形式文本 非形式文本 交互图 状态图 有相应的 UML 成员作为这些描述的载体 文本和正式文本可用注标（note）表示， 交互图和活动图本身即是一个标准的 UML 成员。 主事件流 （main flow of events） 和次要事件流 （alternative flow of events） 。 用来区分对系统功能的合法使用和非法使用 主事件流（main flow of events） 合法使用 只有一个 次要事件流（alternative flow of events） 可包含若干个。 在描绘事件流时，必须用足够清晰的语言以使得一个普通的用户能够理 解。
位图文件 用户 打开文件
显示窗口
ห้องสมุดไป่ตู้、用例和系统作用者的绘制
任何一个完备的 UML 成员，必须有一个名字 在用例图上， 系统作用者、 用例和关联关系都有一个名字来标识 （图 3.4） ， 名字被设置在相应的模型元素的图符附近。 用例的名字分为两种 简单名字 简单名字 路径名字 Place order 路径名字 简单名字是一个不包 含冒号的字串 用户 路径名则是简单名字 Sensors::Calibrate location Validate User 前面加上一个包含此 用例的所在的模型包 图 3.4 名字、简单名字和路径名字 的名字。 它们之间用两 冒号隔开。
系统作用者除了可以代表作为人的软件使用者之外，还可以代表 直接和软件系统交互的软件系统赖以运行的软/硬件平台 以及与软件系统有信息交换的计算机外部设备。
读文件
更新显示
位图文件
更新显示
用户
用户
3. 放大(ZoomOut)
更新显示
显示窗口
1.打开图象文件
显示窗口
用户
4.拖动图象(Pan)
显示窗口
更新显示
系统作用者和软件系统的交互是具体地和特定的某项功能相联系的 而软件系统的功能在 UML 模型是用例 所以系统作用者和软件系统的交互表明了系统作用者和用例之 间存在着某种对应 为了表达系统作用者通过某项功能与系统交互，在 UML 模型 中，用一条直线把系统作用者和用例相连接。
单向关联关 系
位图文件 用户 打开文件
例子： 在下图中，和系统打交道的外部对象有 3 个，其中 “用户”代表软件的使用者 它通过访问这项用例启动软件“打开文件”的功能。 系统对这些事件应采取一系列的动作进行响应， 响应的过程中，将访问硬盘中的数据，并更新显 示。 因此，有两个系统作用者与此相对应， “位图文件” “显示窗口” 。 “显示窗口”代表用来显示位图的操作系统图形用户界面 的一个窗口， 单向关联关 “位图文件” 代表保 系 存在计算机外部存 储器的位图文件 从这个例子也可以看到， 位图文件 系统作用者不仅仅代表 打开文件 用户 人， 还可以是软件或硬件 系统。
当提取出了软件系统运行的外部环境中与之交互的对象之后 需要为这些对象与软件系统进行的交互指定具体内容。这包括 对交互中包含的动态行为进行详细描述， 还包括对这些动态行为进行合理的分类和组织， 以使得这些动态行为所代表的软件系统的功能的设置能为用户 提供其所需的价值， 并具备令用户满意的易用性和效率。 媒介： 交互图 状态图
当软件的使用者考查一个软件产品的功能时 其考虑的内容通常包括 软件的功能的设置的合理性 软件的运行效率 软件功能使用的方便程度 这些内容是软件产品的外部特性, 软件系统通过其边界呈现给用户的特性 外部特性通常是动态的 通过外部特性， 软件系统的使用价值得到了体现 呈现在软件系统的边界上的外部特征 是由软件系统的内部实现决定的 但是，对于软件系统的使用者而言 软件功能的内部实现不是他们关心的问题 他们所关心的只是其所需要的功能是否以令其满意的方式 得到了实现。
系统作用者 系统作用者代表位于系统之外并和系统进行交互的一类对象（图） 用它可以对软件系统与外界发生的交互进行分析和描述。 软件系统在和外界发生交互时涉及的具体的对象，在 UML 里，用 系统作用者来建模。
用例 系统作用者
用例和系统作用者
可以用系统作用者建模的对象 软件系统的使用者 软件系统的使用者要通过使用软件和系统交互 使用者处于系统之外 随着软件系统的应用领域的不同，在用例视图模型中代表系统使用 者的系统作用者的数目也有可能不同。 对于那些通用的软件产品 如：文字处理软件、网络通讯软件、图形绘制软件 它们的使用者通常是不需要分类的 只需要一个系统作用者就可以代表其所有的用户 对于那些专业化较强的专用软件系统 如，管理信息系统、工业生产流程控制系统等， 它们的使用者随其在软件的应用领域的职责的不同，对软 件的使用方式也会有所不同 例如，在一个公司的管理信息系统中，公司的管理者 对信息系统的存取权限将高于公司的普通员工。 有必要对软件系统的使用者进行分类 多个不同的系统作用者将同时出现在用例视图模型中
3、用例
指定系统作用者以后 需要详细描述系统作用者和软件系统交互的具体内容。 对交互所代表的软件系统的功能进行分类 对这些功能详细指定其代表的软件系统的动态行为 在 UML 里，软件系统的功能和其代表的动态行为是用用例来建模 的。
用例 用例代表系统为响应系统作用者引发的一个事件而执行的一系列的 处理，而且这处理应该为系统作用者产生一种可见的价值。 用例描述了当系统作用者和软件系统进行交互时，软件系统所执行的一系列 的动作序列。 这些动作序列 不但应包含正常使用的各种动作序列， 而且应包含对非正常使用时软件系统的动作序列的描述。 用例用来为软件系统所提供的功能及其动态特征建模 在考虑软件系统的功能划分时，要考虑功能设置的合理性和使 用的方便性。 一个用例代表系统作用者和系统的一次交互 用例视图中用例的设置，就代表了软件系统的功能的划分。 为了得到得合理而方便的软件系统的功能设置， 必须仔细考虑每个用例代表的动态行为的内容，使得每个 用例都能产生一个有价值的结果。 在通过用例考虑软件系统的功能划分时 应使得功能的分布较为均衡、易于理解、易于使用 这也是用例的定义中所谓“产生可见的价值”的含义。
第二部分 行为建模基础 第三章 需求分析和用例视图
1、需求分析
软件产品建造的第一步 需求分析 根据用户对产品的功能的期望, 提取出产品外部功能的描述。 用例视图 支持产品外部功能描述的视图。 用例视图 从软件产品的使用者的角度 而不是开发者的角度 描述用户对待开发的产品的需求 分析产品所需的 功能 动态行为。
利用用例和系统作用者的概念，把上述功能通过用例在用例图上加以表 达。 在这里把上列的每项功能都用一个用例表示(图)
读文件
位图文件
更新显示
更新显示
用户
用户
3. 放大(ZoomOut)
显示窗口 更新显示
1.打开图象文件
显示窗口
用户
4.拖动图象(Pan)
显示窗口
更新显示
写文件
用户
2. 放大(ZoomIn)
显示窗口
关联关系的有向性 在下图所示的用例中， “打开文件”对应的系统所采取的动作序列中涉及文件“读取” 但关联关系的箭头仍指向文件而不是反之。 这是因为有向关联关系的箭头 代表的是访问的方向 而不是数据的流向。 数据文件不会（主动地）访问用例，所以对读取或保存文 件，都应有同样的访问方向。
单向关联关 系
2、系统作用者
对软件产品的需求分析就是定义软件系统的边界，包括两个方面的内容 第一、分析软件产品与外界的联系 第二、确定软件产品与外界的联系时包含动态行为及其相互关系。 在 UML 中，下列建模元素为上述两个方面的内容提供支持 系统作用者(actor) 用例(use case)。 它们存在于用例视图中 所在模型图： 用例图(use case diagram)