原文(adiag于2001/04/01 10:08粘贴)
关于用ROSE设计数据库软件的问题
--------------------------------------------------------------------------------

1，在画顺序图的时候，是否把窗口做为一个类？
2，那“实体类”的消息呢？例如某个窗口向某个“实体类”发消息，那这个实体类是否要有这个消息的“方法”来跟消息对应？
3，如果实体类有方法，那以后映射成关系数据库后，方法放在那里？在窗口？
4，窗口类是“接口类”吗？
===
原文(Ms.OO于2001/04/01 12:17粘贴)
我的理解
--------------------------------------------------------------------------------

1，在画顺序图的时候，是否把窗口做为一个类？
窗口是界面类
2，那“实体类”的消息呢？例如某个窗口向某个“实体类”发消息，那这个实体类是否要有这个消息的“方法”来跟消息对应？
那当然得有了，否则发消息干吗？
3，如果实体类有方法，那以后映射成关系数据库后，方法放在那里？在窗口？
方法当然在类里呀，数据库是存储手段
4，窗口类是“接口类”吗？
窗口是Boundary，接口是Interface
===
原文(adiag于2001/04/01 16:51粘贴)
回复: 我的理解
--------------------------------------------------------------------------------

我还是有疑问：“方法当然在类里呀，数据库是存储手段 ”
现在我把ENTITY CLASS都变成了关系数据库的二维表格，那这些实体类的方法怎么放啊？是做为数据库的“存储过程”吗？但很多都没有必要的，因为都很简单。例如：在某窗口类向某个实体类发消息“读取”，那对应的工作很简单，如果用SQL语句，就是SELECT了，没必要写成“存储过程”，那究竟该怎么写呢？

====
原文(liuzhiming于2001/04/01 20:30粘贴)
我的理解
--------------------------------------------------------------------------------

数据库里的表纪录应该理解为某个类的实例（instance)的属性数据,数据库只是永久存储类实例的属性的地方，从数据库读取数据的过程应该理解为恢复类实例的属性的过程，对应于每个表在程序中应该创建相应类（定义类方法及属性），并用数据库里的表纪录恢复实例属性，RUP也提到了数据库表同类的映射关系（Guidelines: Reverse-engineering Relational Databases），但这里也有问题因为许多数据引擎实现了表到类的转换工作，但他们并不知道你需要的类有哪些具体方法，因此他们提供给你的类只是数据类,比如ado的recordset类,BDE的ttable类,所以要实现你的具体应用，一般都是自己再定义一些类同数据库引擎提供的类协作完成工作（使用聚合关系等）

====
原文(adiag于2001/04/01 22:34粘贴)
感谢liuzhiming的回答
--------------------------------------------------------------------------------

经过你的解析，我也有点眉目了。
照你这么说，那就是实体类也应该是个类，而且也有方法的。对吗？
那就是说：我们在数据库内的“二维表格”都不是属于类来的，而他们的子模式才是类，我们在实际中，是先设计出他们的子模式，然后用传统的方法（规范化），设计成数据库表，所以由模型内得到的实体类都是有方法的。对吗？
====
原文(adiag于2001/04/02 20:47粘贴)
回复: 感谢liuzhiming的回答
--------------------------------------------------------------------------------

我的疑问还是那样，究竟数据库表是“类”吗
1：把数据库表当做类，而且用存储过程做方法
2：把数据库表的子模式做类，而数据库表只是子模式的综合（规范化），不做为类，

2种说法那个正确？
如果2种都不矛盾，那是为什么？
======
原文(liaofan于2001/04/02 21:45粘贴)
关系数据库与面向对象
--------------------------------------------------------------------------------

我们现在用的数据库是关系数据库，非面向对象的数据库。类的方法要在程序代码中实现，数据库表也不是类。只是类的存储采用关系数据库，表现为类定义转变为表定义，类属性转变为表字段，但两者的映射也可以有一些其他方式，存储过程与类方法没有必然联系。
等面向对象的数据库实现后，才能把类的属性和方法同时存储到数据库中。
===
原文(mrshiwei于2001/04/03 14:05粘贴)
回复: 关系数据库与面向对象
--------------------------------------------------------------------------------

关系数据库的存在，本质上说为了解决持久数据的存贮。而持久数据的存储访问的方法很多，基于关系型理论的方式，也就是关系型数据库，是其中解决的比较好的。其实我们不必坐等真正的面向对象的数据库的出现和广泛应用，EJB中的持久性对象模型EntityBean给我们提供了关系世界和面向对象的桥梁。Rose2001中可以很方便地将一个类转换成持久性类--EntityBean。只可惜EJB的支撑环境比较昂贵，限制了它的广泛使用。

=====
原文(lgjut于2001/04/02 22:06粘贴)
回复: 感谢liuzhiming的回答
--------------------------------------------------------------------------------

2可能更正确一些吧
《Mapping Objects To Relational Databases》中的
The Persistence Modeling process pattern指出
Object-Oriented Model->Logical Persistence Model->Persistence Physical Model
===
原文(adiag于2001/04/03 12:58粘贴)
回复: 感谢liuzhiming的回答
--------------------------------------------------------------------------------

非常感谢各位的回答，以后有什么要帮忙的，尽管MAIL给我，我也会尽力的
===
原文(liuzhiming于2001/04/02 22:31粘贴)
回复: 感谢liuzhiming的回答
--------------------------------------------------------------------------------

首先数据库表可以作为一个类，但这个类只负责数据的存储，而定义另外的类实现具体的功能，就设计的顺序来说，应该是根据完成的功能设计出类，然后考虑类所处理的信息，确定如何在数据库中存储这些信息（设计数据库表），为了将数据由数据库中提取出来，需要定义一个类负责数据的存储，:
考虑下面的纸牌类：
class Card {
public:
void FaceUp();
void FaceDown();
Card(Rank r,Suit s);
private:
Rank int;
Suit int;
Color int;
};
为了将每张牌的Rank,Suit,Color信息存入数据库表，可在数据库表中建立表Card（column : rank,suit,color)，现在需根据数据库表Card的数据创建52张牌（假设数据库表以输入了52条纪录），定义tablecard类，负责读取rank,suit,color信息，然后card类根据这些信息创建52个对象

from umlchina.com.cn
其余请看
http://www.umlchina.com/Article/BestIndex1.htm
many  thanks

用Rose C ＋ ＋ 实 现
大 型 实 时 监 控 软 件
北 京 跟 踪 与 通 信 技 术 研 究 所
姬 孟 洛--彭 利 文

--------------------------------------------------------------------------------

---- 实 时 监 控 应 用 软 件（CTS） 开 发 过 去 采 用 的 大 多 是 结 构 化 方 法， 采 用 的 编 程 语 言 也 是 汇 编 语 言、Fortran、C、Ada 等 结 构 化 编 程 语 言。 随 着 面 向 对 象 语 言 的 普 及， 如C ＋ ＋， 业 界 也 曾 有 过 分 析 和 设 计 阶 段 采 用 结 构 化 方 法、 编 程 实 现 采 用 面 向 对 象 语 言 的 尝 试， 其 结 果 是 只 能 使 用 面 向 对 象 语 言 的 结 构 化 特 性， 这 和 使 用 结 构 化 语 言 是 一 样 的。 我 们 首 次 尝 试 采 用 面 向 对 象 工 具（Rational Rose C ＋ ＋）、 面 向 对 象 方 法（UML） 以 及 面 向 对 象 编 程 语 言（Visual C ＋ ＋） 完 整 地 实 现 大 型 实 时 监 控 应 用 软 件， 收 到 了 较 好 的 成 效。

----UML（ 统 一 建 模 语 言） 是 美 国Rational 公 司 创 建 的 面 向 对 象（OO） 开 发 中 一 种 通 用 的、 统 一 的 图 形 化 模 型 语 言，1997 年11 月 被 美 国OMG 小 组 批 准 为OO 开 发 的 行 业 标 准 语 言， 同 时 太 平 洋 技 术 软 件 公 司 将Rational 公 司 产 品 引 入 国 内。Rose 是Rational 公 司 面 向 对 象 的 软 件 分 析 设 计 建 模 工 具， 可 以 创 建 基 于UML 标 准 的 模 型， 图 形 化 地 对 软 件 系 统 结 构 加 以 描 述 和 定 义， 并 且 通 过 建 立 的 模 型 直 接 生 成 代 码 框 架。 同 时， 还 可 以 从 开 发 者 编 的 应 用 系 统 中 直 接 逆 向 生 成 模 型。 下 面 就 监 控 应 用 软 件 的 分 析 设 计 作 一 简 介。

UML 模 型
----本 监 控 系 统SCS 由 中 心 和 站 组 成。 站 将 测 量 设 备 传 来 的 测 量 数 据 转 送 给 远 程 的 中 心， 由 中 心 对 测 量 数 据 进 行 实 时 和 事 后 处 理； 站 对 测 量 数 据 进 行 部 分 实 时 处 理， 同 时 接 收 并 转 发 中 心 对 设 备 的 控 制 命 令。 这 里 仅 描 述 站 的 实 时 应 用 软 件 系 统。CTS 是 监 控 系 统 的 中 心， 它 主 要 用 来 监 视 和 控 制 测 量 设 备 实 时 跟 踪 和 测 量 飞 行 目 标， 实 时 处 理 测 量 结 果， 并 兼 有 显 示、 打 印、 记 录 等 功 能。 它 和 测 量 设 备 的 关 系 如 图1 所 示。



图1 监 控 制 系 统 框 图
----通 信 控 制 处 理 机（CCP） 负 责 将 处 理 机 传 来 的 数 据 转 发 给 通 信 端 口， 并 从 通 信 端 口 接 收 信 息， 然 后 转 发 给 处 理 机。

----实 时 应 用 软 件 通 过 数 据 包 和 测 量 设 备 交 换 信 息。 该 软 件 实 时 性 要 求 较 高， 在 每 个 采 样 周 期 内， 必 须 完 成 该 周 期 的 数 据 处 理 工 作， 也 要 有 一 定 的 人 工 干 预 能 力。

----实 时 应 用 软 件 模 型 用 来 描 述 软 件 各 层 次 的 各 个 方 面， 它 包 括Use Case 图、 类 图、 序 列 图、 状 态 图、 分 布 图 和 组 件 图。

---- Use Case 图

----Use Case 也 称 为 用 例、 使 用 情 况， 它 是 系 统 分 析 人 员 从 用 户 使 用 的 角 度 所 看 到 的 系 统 功 能、 功 能 之 间 的 关 系 以 及 用 户 与 功 能 之 间 的 关 系， 是 系 统 功 能 以 及 用 户 与 功 能 之 间 的 关 联。 利 用Use Case 系 统 分 析 人 员 对 系 统 的 功 能 和 行 为 加 以 描 述。 对 于CTS， 所 有Use Case 的 工 作 都 必 须 在 指 定 的 时 间 周 期 内 完 成。

---- 类 图

----类 图 是 系 统 的 逻 辑 结 构， 是 模 型 的 核 心 部 分。 它 描 述 了 系 统 中 的 类 与 类 之 间 的 关 系， 类 图 描 述 系 统 的 静 态 结 构。 类 包 是 子 系 统 中 相 关 类 的 集 合， 它 类 似 于Peter/Coad 方 法 中 的 主 题 词（subject）。 图2 描 述 了CTS 的 类 包 及 其 关 系， 这 个 类 包 图 以 及 每 个 类 包 对 应 的 类 图 都 是 由Rose C ＋ ＋ Analyzer 自 动 生 成 的。




图2 CTS的 类
----类 包DisplayProcess、DataProcess、CAbnormity 和CommunicateProcess 是 我 单 位 自 己 开 发 的， 是 系 统 的 核 心， 其 余 的 类 包 是 由Microsoft 提 供 的。DisplayProcess 类 包 包 含 了 显 示 所 需 要 的 所 有 和MFC 有 关 的 类，DisplayProcess 类 包 中 的 类 都 是 从MFC 派 生 的， 一 般 都 增 加 了CTS 系 统 所 需 要 的 特 性；CommunicateProcess 类 包 包 含 了 通 信 处 理 所 需 要 的 类 与 类 之 间 的 关 系；DataProcess 类 包 是CTS 类 包 中 的 核 心 部 分， 它 包 括 了 数 据 处 理 所 需 的 所 有 类， 这 个 类 包 比 较 复 杂；CGdFeature 类 是 数 据 处 理 部 分 的 类， 它 有 两 个 最 主 要 的 操 作： 轨 道 积 分 和 坐 标 转 换；CAbnormity 类 包 包 含 异 常 处 理 以 及 操 作 台 应 急 处 理 所 需 要 的 类。

---- 序 列 图

----CTS 的 动 态 特 性 用 序 列 图 表 示， 序 列 图 用 来 描 述 一 个 软 件 的 运 作 顺 序（ 场 景）， 一 个Use Case 包 含 多 个 软 件 的 运 作 场 景。 序 列 图 用 来 刻 画Use Case 图， 一 个Use Case 可 以 有 多 个 序 列 图， 每 个 场 景 用 一 个 序 列 图 刻 画。 合 作 图 与 序 列 图 等 价， 可 以 由 序 列 图 转 化 得 到， 两 者 各 有 优 缺 点。 序 列 图 对 于 实 时 系 统 的 时 间 要 求 刻 画 得 很 好， 但 结 构 不 明 显； 合 作 图 的 对 象 间 关 系 明 显， 但 它 用 消 息 顺 序 号 表 示 时 间， 时 间 表 示 不 清 楚， 不 太 适 用 于 实 时 系 统。

---- 状 态 图

----CTS 的 动 态 结 构 主 要 用 来 描 述 类 的 动 态 特 性， 它 由Rational Rose 的 状 态 图StateDiagram 来 描 述。 行 为 导 致 了 状 态 的 迁 移， 状 态 图 用 来 显 示 一 个 给 定 类、 给 定 事 件 的 状 态。 每 个 状 态 图 都 与 一 个 类 或 一 个Use Case 相 关 联。 状 态 图 刻 画 软 件 系 统 的 行 为 视 点， 它 基 于 有 穷 状 态 自 动 机 的 图 示 机 制。 一 个 状 态 图 包 括 一 个 类 在 生 命 周 期 内 的 状 态 转 换 和 描 述。

----由 于 一 个 激 活 的 类 对 应 一 个 或 几 个 线 程， 我 们 这 里 可 以 认 为 是 每 个 状 态 图 或 状 态 子 图 对 应 一 个 线 程， 状 态 图 描 述 了 线 程 的 工 作 特 性。

---- 组 件 图

----逻 辑 模 型 表 示 了 系 统 的 逻 辑 结 构， 每 个 逻 辑 模 型 都 应 有 一 个 或 多 个 到 物 理 实 现 — — 组 件 图 的 映 射。 组 件 图 显 示 了 物 理 上 组 件（ 主 程 序、 包 和 任 务） 之 间 的 依 赖 关 系 以 及 和 逻 辑 模 型 之 间 的 映 射 关 系。 组 件 的 设 计 和 系 统 的 运 行 环 境 以 及 逻 辑 模 型 的 结 构 有 关。 相 对 而 言， 组 件 图 比 较 容 易 设 计。

---- 软 件 分 布 图

----软 件 系 统 需 要 和 硬 件 环 境 一 起 工 作， 软 件 分 布 图 也 表 示 了 硬 件 设 备 和 它 们 的 界 面， 以 及 硬、 软 件 的 协 同 工 作。CTS 的 软 件 分 布 图 表 示 了 执 行 程 序、 计 算 机 节 点 以 及 设 备 的 布 局。

实 现
----在 系 统 的 逻 辑 设 计（ 模 型） 和 组 件 设 计（ 模 型） 完 成 之 后， 就 可 以 进 入 编 程。CTS 的 编 程 实 现 采 用Microsoft 的VC ＋ ＋ 语 言，Rational Rose C ＋ ＋ 对VC ＋ ＋ 有 专 门 的 支 持。 编 程 实 现 主 要 是 利 用Rose 的 生 成 和 反 向 生 成 工 具 根 据 系 统 的 设 计 模 型 来 完 成 的。 它 包 括 三 大 步 骤， 每 个 步 骤 又 包 括 多 个 过 程。
---- 系 统 设 置

----系 统 设 置 主 要 用 来 设 置Rose 的 特 性 和 目 录， 它 包 括 四 步， 由 于 篇 幅 关 系 这 里 不 作 详 细 叙 述。

---- 开 始 一 个 新 的VC ＋ ＋ 项 目

----在 开 始VC ＋ ＋ 编 程 时， 首 先 创 建VC ＋ ＋ 应 用 程 序， 此 时 应 遵 循 以 下 步 骤：

使 用VC ＋ ＋ 的Application Wizards 为 应 用 生 成 框 架；
创 建Rose 分 析 器Analyzer 下 的 项 目， 加 入VC ＋ ＋ 创 建 的 文 件；
定 位 头 文 件， 关 闭 不 含 类 也 不 能 由 分 析 器 生 成 和 反 向 重 新 生 成 的 文 件 的Regenerate 属 性， 并 向Rose 输 出 初 始 模 型；
在Rose 下 打 开.red 文 件；
反 向 生 成 的 模 型 不 带 特 性， 选rosevcpp.pty 文 件 作 为 新 的 特 性 文 件， 最 后 把 模 型 保 存 为.mdl 文 件。
----增 加 类、 数 据 成 员 和 成 员 函 数

----把Rose 模 型 中 的 类 增 加 到VC ＋ ＋ 应 用 程 序 中 可 分 为 两 种 情 况： 一 种 是 不 使 用VC ＋ ＋ 的Class Wizard 支 持 机 制 的 类（ 如 信 息 映 射）， 一 种 是 使 用 此 机 制 的 类。 前 一 种 情 况 比 较 简 单， 它 在Rose 中 生 成 代 码， 然 后 把 这 些 文 件 加 入VC ＋ ＋ 项 目 中 即 可。 对 于 后 一 种 情 况， 其 步 骤 大 致 如 下：

在VC ＋ ＋ 中 创 建 新 类， 然 后 将 新 类 的 文 件 加 入Rose 的Analyzer 对 应 的 项 目 中；
在 分 析 器Analyzer 中 进 行 特 性 设 置 以 反 映 项 目 当 前 的 变 化；
在 分 析 器Analyzer 中 输 出 文 件。
----向 已 经 存 在 的 文 件 中 添 加 数 据 成 员 和 成 员 函 数 的 方 法 与 添 加 类 的 方 法 相 同。

优 势
----从 应 用 的 结 果 看， 使 用Rational Rose C ＋ ＋ 进 行 监 控 实 时 应 用 软 件 开 发 取 得 了 比 较 好 的 效 果， 与 以 前 使 用 的 结 构 化 方 法 相 比 有 明 显 的 优 势， 这 主 要 表 现 在 以 下 几 个 方 面：
从 分 析 到 设 计 到 编 程 衔 接 自 然， 这 既 得 力 于Rose C ＋ ＋ 工 具 的 支 持， 也 取 决 于 面 向 对 象 开 发 方 法 的 优 势。
Use Case 是 系 统 分 析 人 员 从 用 户 的 视 角 出 发、 从 功 能 边 界 来 描 述 目 标 软 件 系 统， 这 从 模 型 上 规 范 了 对 需 求 的 描 述， 也 能 够 和 后 面 的 设 计 较 好 地 衔 接， 比 以 前 纯 粹 的 文 字 描 述 要 好 一 些。 用UML 描 述 需 求 对 于 用 户 有 很 好 的 可 理 解 性， 便 于 软 件 开 发 人 员 与 用 户 的 交 互， 用 户 可 以 尽 早 介 入 目 标 软 件 系 统 的 开 发 工 作。
逻 辑 设 计 代 替 功 能 模 块 设 计 和 实 体 － 关 系 设 计， 解 决 了 以 前 的 功 能 和 数 据 分 离 的 问 题 以 及 模 块 中 数 据 的 组 织 问 题。
用 状 态 图 在 较 高 的 层 次 上 描 述 了 系 统 的 动 态 结 构。 5.
由 于 同 时 使 用 了 文 档 生 成 工 具， 使 得 系 统 设 计 和 文 档、 程 序 代 码 保 持 一 致， 较 好 地 解 决 了 极 易 造 成 的 文 档 和 实 现 不 一 致 的 现 象。 这 一 点 非 常 重 要。

Yahoo!如果建模，会是怎样的呢？请指点

原文(loveuml于2001/02/22 04:28粘贴)
Yahoo!如果建模，会是怎样的呢？请指点
--------------------------------------------------------------------------------

要设计一个零部件库存查询系统，要让顾客打入关键字或按类别循次渐进查询所需零部件的现有库存和定价....。

零部件分为螺钉，螺栓，螺母，垫圈...等类别，每类零件的表征方法不尽相同，如螺母有内径，高度等等，垫圈就没有....。请问类图如何设计？如果每种部件一个Class（映射到关系数据库中自然是一张Table了），那如果有几百种部件（当然，没有），不就有几百个Class。显然不对。

事实上，我觉得这和Yahoo!的目录数据库差不多，目录，站点....，Yahoo!如果建模，会是怎样的呢？请指点！
====
真的没有人理睬吗？也许不该用Yahoo那么醒目的标题 - <0b> loveuml 2001/02/23 00:56 (13次点击)
==
原文(abug于2001/02/23 01:59粘贴)
some one will help u, dont worry about it.(0b)
--------------------------------------------------------------------------------

Sorry, I was crazy busy right now.
So I can give you little advise.
You need to know concept model, and design model got difference.
And not every real concept need to become class in desing or inplement model. You got the requirement, that is your criteria came from.
==
原文(Ms.OO于2001/02/27 00:42粘贴)
我的理解
--------------------------------------------------------------------------------

关于商品或物品，有三个主类

1. 属性：重量，长度，属性有层次，也许是树状，也许是网状。

2. 类别: 螺钉，螺栓...，类别具有若干特定属性，类别有层次，也许是树状，也许是网状

3. 物品: 物品属于某类别，具有该类别的属性值

有启发吗？
====
原文(lgjut于2001/02/27 20:42粘贴)
我做过
--------------------------------------------------------------------------------

我采用的就是数据库中存几百个表，当然，数据库中应该有元模型来描述。
我以前在学校做的，没有实用，源代码给你都可以。
===
原文(umlchina于2001/03/03 07:56粘贴)
这样做是有问题的，建议你看看这本书...
--------------------------------------------------------------------------------

Oracle UML 对象建模设计第16章“类建模”－－技术6：将表结构作为数据存储，就是说你的问题。方法和下面MsOO说的类似。这是一本很好的书，由Martin Fowler作序的，值得建模者一读再读。
===
谢谢think及Mr.oo ，《Oracle UML 对象建模设计》我刚开始看。 - <0b> lgjut 2001/03/04 21:01 (9次点击)

原文(SoftRen于2001/02/13 10:27粘贴)
各路UML高手：请教一个关于角色和用例如何划分的问题???
--------------------------------------------------------------------------------

假定有这样一个订票系统：用户通过计算机访问订票系统，再将订到的票通过打印机打印出来，请问：
1． 角色和实例按下面的方式划分是否比较合理？
角色： 订票者、计算机、打印机、订票系统
实例： 订票功能、打印功能

2． 计算机访问订票系统可以为B/S方式或者为C/S方式，对于划分角色和实例是否应该有很大的不同？比如说：1中划分的方式比较切合C/S方式的功能描述。

=====
原文(szsoft于2001/02/13 17:03粘贴)
呵呵，你也在做网上订票系统吗？
--------------------------------------------------------------------------------

我去年做过一个，
角色好象没有那么多吧！
我那次做时只做了订票者。
你定义那么多东东好象应该是类才对呀！
两全用例我将打印定义为被订票用例使用的用例。

你应该是想做网上订票的吧。
呵呵，看看www.selfticket.com吧。

=====
原文(SoftRen于2001/02/13 17:31粘贴)
回复: 我不是做订票系统的，只是看书看到这里，就想举例求证！
--------------------------------------------------------------------------------

我不是做订票系统的，只是看书看到这里，就想举例求证！
如果是B/S结构，我同意你的看法，但如果是C/S结构，我觉得客户端有更多的功能需要定义。
另外，我想向各位求教的是：计算机控制的外部设备在什么时候可以定义为角色？
=====
原文(szsoft于2001/02/13 19:48粘贴)
回复: 我不是做订票系统的，只是看书看到这里，就想举例求证！
--------------------------------------------------------------------------------

当这个外部设计发送了一个消息给系统，
而这个系统被激活执行了一个功能。
这时外设就可以当做一个角色。
比如UPS系统。停电后，继电器断开
从而激活了UPS保护应用的程序，如提醒用户
有的还可以CALL系统管理员

=====
原文(lgjut于2001/02/13 20:54粘贴)
订票系统本身不是角色吧
--------------------------------------------------------------------------------

角色是在系统外与系统直接打交道的。
另外，角色有主动角色与被动角色之分。
====
原文(huaiqj于2001/02/13 22:27粘贴)
回复: 各路UML高手：请教一个关于角色和用例如何划分的问题???
--------------------------------------------------------------------------------

角色是不是可以只有订票者，订票系统/数据库两个？
====
原文(SoftRen于2001/02/14 09:17粘贴)
回复: 根据各位先生的讨论，我把这个问题总结一下。请指教：
--------------------------------------------------------------------------------

根据各位先生的讨论，我把这个问题总结一下：
1． 明确考察的对象是订票系统（包括个人计算机、打印机、订票处理系统）
2． 所以角色只应该有一个：订票者（系统外直接与系统打交道的）
3． 系统的二个主要的功能定义为实例：订票功能、打印功能

以上总结是否合理？ 另外：
打印机是否可以作为被动角色处理？

=====
原文(Ms.OO于2001/03/01 10:58粘贴)
Ms.OO的理解
--------------------------------------------------------------------------------

角色是系统之外的概念
角色必须透过系统边界和定义系统直接作用

以上系统定义“定票者”一个角色合适。描述的系统是一个黑匣子软件，打印机并非系统的一部分，但也不是角色。被动角色并非打印机之流，而是事先等候消息再启动，但这只是启动条件，它自己启动以后还是要发消息给别人，表现在顺序图上，就是除了第一条消息的方向不同，其他和主动角色相同。

关于Rose的对话
***** ROSE介绍 （一. 面向对象建模） *****

面向对象建模的概念是理解ROSE这个面向对象的CASE工具（嗨嗨，等等，什么是CASE？-- CASE就是Computer Aide
-d Software Engineering，即用计算机帮助人们来创建软件，使软件生成过程尽量自动化）的基础。我们做软件，不过是用软件来刻画客观事物及其联系。人脑中形成了对客观世界的正确认识之后，如果能正确的映射到软件成分上，那么软件就一定是对客观事物的正确描述和映射，因而是正确的。如果这个过程中出现了问题，无论是在人脑认识阶段（这不就是需求分析吗？）还是在人的认识到软件成分的映射阶段（这不就是软件设计吗？），都会使软件失败。

面向对象的思想为这种建模提供了强有力和直观的支持（唔？--客观世界有子程序吗？但是客观世界有“学生”这个对象，也有“课程”这个对象。瞧，面向对象对客观世界的描述是不是比结构化方法更直观，更好理解呀？--那当然啦！）。长期以来人们一直在试图创造一种面向对象的可视化的语言和方法，使建模人员能更加直观和严格的描述客观世界，并产生了一些流派，如Yourdan和Coad的OOA、OOD，Booch的方法、Rumbaugh的OMT、Jacobson的OOSE方法等。历史发展到今天，Booch、Rumbaugh和Jacobson一起合作，吸收了各种流派的优点和其他一相关领域的成果，终于创造出一种较成熟全面的面向对象建模语言--UML（话说天下大势，合久必分，分久必合）。并把UML融入Rational公司的CASE工具ROSE之中。ROSE试图用UML语言支持软件开发的大部分过程（测试除外）的建模。在ROSE中，只要你用UML描述了软件的各个成分（也就是为软件建立了一个面向对象的模型），ROSE就为你生成所需的大部分源代码（呀！这不是可以省很多时间吗？可以多玩会儿Quake啦！

--更重要的是，从此以后你就可以充分利用OO的诸多优点啦--象模型稳定性、重用等等，这将大大降低软件维护和升级的成本，别忘了，维护和升级成本往往会占总成本的百分之七、八十呢！）。

下一篇文章我将向大家介绍UML的建模思想。




*****ROSE介绍 （二. UML的建模思想）*****


看到大家对ROSE和UML这么感兴趣，豆子真是好激动啊！接下来我想为大家介绍一下UML的建模思想.正好我的两个朋友--老幺(1)和小灵(0)也正在学ROSE和UML,我们一起来学好了.Let's go!

小灵：老幺哥，现在你在捣鼓什么呢？
老幺：小灵弟，我刚刚从清华BBS的虫虫那搞到了ROSE 4.0和UML 1.1，正在闭门修炼呢!
小灵：嗨，这真是芝麻掉到针眼里--巧极了！我也从那搞到了一套。（小灵和老幺亲热的握手。）
小灵：UML里面的概念太多了，真让人头大！还有那么多花花绿绿的图 图，我现在是狗咬刺猬--无从下口了。老幺哥，能不能帮我一下？
老幺（大搔其头）：确实，我也有同感。可是，我从哪开始讲呢？
小灵：呃…… 最好是从需求分析开始顺序侃下去。
老幺：好吧。小灵弟，如果你拿到了一个项目,想用OO建模的方法来建造,第一步要做什么呢？
小灵：我以前看过Youdan和Coad的OOA、OOD的书，我想应该先分析问题域的 对象吧？我从问题域的特点和自己的经验出发，分析问题域都有哪些对象，它们的关系如何，and so on。但是这总是给人一种“玄而又玄”的感觉，全凭经验和感觉了。而且把这些图图拿给用户看，他们是丈二的和尚--摸不着头脑了。
老幺：着啊！这就是USE CASE的用武之地了。
小灵（兴奋的）：对了对了，快给我讲讲这个USE CASE是个什么东东.我连怎么翻译都不知道。
老幺：我也不知道怎么翻译，所以干脆就不翻了。本来就是人洋人的东西，还是入乡随俗吧，唉。USE CASE最早是由Rational三剑客之一的Jacobson在他的OOSE方法中提出的，由于其非常有用，现在遗传给了 UML。OO思想曾经遭到过一些人的批评，理由是用户关心的和理解的只是系统的功能，他不可能去学习你的OO模型，所以虽然OO建模减小了分析设计和编码的鸿沟，但是却和用户的距离拉远了。
小灵：批评的很中肯呀！
老幺：是啊。我觉得传统的OO建模在用户交流方面还不如功能分析做的好呢 ！不过，有了USE CASE，情况就大大改观了。一个USE CASE是系统体现给外界的一个连贯的功能单元，系统外部的人员或者其他系统（就是Actor啦！）通过和USE CASE交换一系列消息来使用系统的功能。
小灵：唔…… 这和功能分析没什么两样啊？
老幺：别急。注意USE CASE是由系统中的对象相互发消息、相互作用来完成的，而不是和功能分析一样是由子功能之间的调用实现的，这样，就 弥补了OO建模和用户之间的裂痕。
小灵：纯粹是让用户逼出来的。
老幺：用户就是上帝么！不过USE CASE的作用也不光是和用户交流、做需求分析，它还可以指导测试用例的选择、用户界面的设计甚至用户手册的编写等等工作。
小灵：呀！用处这么大呀！
老幺：除了USE CASE分析，第一步要做的工作也包括你刚才提到的问题域对象分析，其实是类分析。USE CASE分析和类分析可以相互支持、补充。
老幺：USE CASE和初步的类分析做完之后，我们就可以用得到的Actors和类的对想来描述USE CASE的实例了。这样就产生了交互图Interaction Diagram。
小灵：老幺哥，这次你怎么会翻译了？
老幺：尽力而为（主要是中文输入和英文输入换来换去太麻烦，嘻嘻）。交互图分两种--顺序图Sequence Diagram和协作图Colaboration
Diagram。它们一起来描述系统的动态行为，就是对象之间的交互。
小灵（哭丧着脸）：这两个图图没什么区别嘛！反正我是看不出来。
老幺：sequence diagram和colaboration diagram都是描述系统动态行为的图。二者从语义上来讲并无二至，但是sequencediagram强调时间，时间在其 中作为一个轴显式的存在，所以sequence diagram用来描述实时行为最为合适。而colabrationdiagram在描述了系统中对象及其关联的情况下对象之间的消息传递，突出的是动态行为发生的语境，时间在其中是隐式描述的（用1、2等消息标号）。二者是对同一系统动态行为的不同视角的描述，可以加深建模人员对系统动态行为的理解。
小灵：原来如此。那么，我可以画多个交互图啦？
老幺：是呀！原则是说，Actors有多少行为，就要画多少交互图来描述系统 内的对象是怎样配合工作完成Actors所要求的功能。
小灵：我的老妈呀！那要画多少图图呀？
老幺：不过，实际上不需要画这么多的。只需要把最重要的和最难理解的USE CASE实例，唔，对了，USE CASE的实例叫做剧情Scenario，描述清楚就行了。
小灵：Siiiiii... 这个词儿怎么发音？
老幺：/si'na:riou/。
小灵：/si'na:riou/、/si'na:riou/、/si'na:riou/。那没画的图图怎么办呢？
老幺：我们只需为每个类做一张状态图State Diagram就可以了。类的状态图描述这个类的对象在外界事件发生时状态发生怎样的变化，产生哪些 动作等。外界的事件包括其他对象发来的消息、各种异步事件等，产生的动作包括向其他对象发送消息、产生异步事件等等。这样，把状态图和交互图综合起来看，就可以对系统的动态行为有一个较全面深刻的理解。
小灵：分析基本上可以了，现在接着讲设计吧。
老幺：我们早已经开始讲设计啦！
小灵：唔？
老幺：OO建模的好处就是不用在分析和设计之间划一到鸿沟，设计只需要在分析的基础上进一步根据实现系统的限制不断进行各种成分的扩充和细化。
老幺：详细的设计完成之后，我们就可以对系统的实现进行建模了。在UML中，这是用实现图Implementation Diagram来完成的。实现图分部件图 Component Diagram和实施图Deployment
Diagram两种。
小灵：这个部件Component和时下流行的软件部件，象Java Applet啦、ActiveX部件啦，有什么关系？
老幺：这个概念在Booch的方法中就有，不过那时叫模块Module。象某个子程序啦、某个任务啦等等都是Module。我猜UML为了适应软件部件的发展 ，用Component来扩充了Module的概念，使UML和软件部件的思想结合的更加紧密。
小灵：部件图和实施图有什么关系？
老幺：部件图描述了软件实现的组成和结构。它把软件的实现分成一个个的部件，把部件组织成包。分析设计时用来组织类的逻辑包可以映射到实现的部件包上，而类可以映射到部件上。
小灵：对了，学ROSE时,老是搞不清Logical View中的包和Component View中的包有什么区别。
老幺：在UML中,Package只是一种将关系比较紧密的成分组织起来的一种方式。ROSE的Logical
View中的包是用来组织类的，它在Booch的方法中被称为Class Catalog，而Component View中的包是用来组织部件的，二者基本没什么关系，不过可以把逻辑包映射到部件包上，这就是说，这个逻辑包中的类是由这个实现包中的部件实现的。
小灵：ActiveX和Java现在都有一种称为CAB文件柜的文件，其中打包了若干个Control或者Applet，是不是有些象实现包？
老幺：我想是的。
小灵：那实施图呢？
老幺：实施图描述了软件系统将要运行的环境，包括各种计算资源、设备和这些设备之间的连接。实施图还描述软件系统的各个进程在这些资源和设备上的分布情况。
小灵：这又是赶网络和分布式计算的时髦喽！
老幺：嗨，我们搞计算机的，就是一辈子赶时髦，做一辈子花花公子。
小灵（伸了个懒腰）：啊…… UML还挺全的嘛，除了测试，它都包了！
老幺：测试可以用Rational的黑盒测试工具SQA、白盒测试工具Purify呀！
小灵：得啦，你少来为Rational做广告啦！
老幺：不过说实话，人那东西做的确实不错。
小灵：老幺哥，谢谢你给我讲了这么多，真是让我茅塞顿开呀！
老幺：别客气。
小灵：我要回家了。下次我们再侃ROSE。
老幺：Bye-bye！

***** ROSE介绍 （三. ROSE的使用）*****


这些天来，小灵和老幺都在认真学习ROSE和UML。这一天，老幺来到小灵家来做客，看到小灵正在玩ROSE。
老幺：小灵，ROSE玩得怎么样啊？
小灵：嘿，老幺哥，你来啦。请坐。（小灵给老幺让座、倒茶）
小灵：老幺哥，我发现如果UML的基本概念掌握好了,再加上一些例子，ROSE其实并不难学嘛。
老幺：那好啊，我们来切磋切磋。你来给我介绍一下你的成果吧！
小灵（清了清嗓子）：OK！我们先来看一看ROSE的界面吧。（老幺和小灵坐到电脑前）
小灵：ROSE的界面基本分成三个窗口：浏览窗口browser window、图形窗口 diagram window和文档窗口document diagram。它们共同来创建和操作模型。浏览窗口主要是来创建各种模型元素，并在模型中遍历和漫游。图形窗口主要是用来绘制和显示模型中的各种图，而文档窗口用来书写和显示模型元素的描述。
老幺：对.我觉得,很重要的一点是要搞清楚我们所建的模型和我们所见的模型之间的关系。UML中的各种图不过是从不同的角度来把模型可视化而已.同一个模型元素,可以出现在多个图中。
小灵：这就好象同一个意象，诗人用诗歌的形式表现它，画家用绘画的形式表现它，而作曲家用音乐的形式来表现它一样。
老幺：ROSE中的浏览窗口、图形窗口和文档窗口都是同一模型的不同表现形式而已，它们用不同的方法组织和表现模型的元素，使我们能更好的构造和理解模型。
小灵：好，我们拿到一个项目时，首先应该考虑什么呢？
老幺：当然是考察用户需求，烹制一些USE CASE喽！
小灵：在分析USE CASE之前，要先分析ACTOR。就是分析我们系统的用户和将与我们的系统交互的外部系统。因为真是它们的需求，才让我们确定 我们的系统要具有什么样的功能。
老幺：在ROSE里，怎么创建ACTOR？
小灵：一般来说，创建模型元素应该在浏览窗口中进行。就是在浏览窗口中选中Use case view
、Logical view、Component view或Deploymentview文件夹，单击右键，选择New菜单，创建所需的模型元素。
老幺：我在USE CASE图里不是也能建ACTOR吗？
小灵：不错。但是我更习惯先在浏览窗口中把模型元素建好，然后再把它们拖到相应的图中。这样更能体现图是模型的可视化表现这个思想。
老幺：我觉得那种方法都可以。
小灵：有了ACTOR之后，我们就可以为每个ACTOR分析它们所要求的系统应该具有的功能，也就是USE CASE。在创建了USE CASE之后，我们需要把 ACTOR和USE CASE拖到USE CASE图中，并用箭头表示它们之间的交互关系。
老幺：画完了USE CASE图之后呢？
小灵：USE CASE分析之后，我们要考虑USE CASE的实例senario的事件流程，这通常使用交互图（包括顺序图和协作图）来描述。在这些图中，我 们用对象和对象之间的消息流来描述senar-io，从而发现要完成USE CASE，系统必须具有哪些对象，以及这些对象应该响应哪些消息。
老幺：这比Coad方法中发现对象的方式更具操作性。
小灵：当我们把这些senario分析完了之后，我们发现了许多对象，下一步，我们就要为这些对象定义相应的类了。
老幺：这些类是在Logical View中定义和显示的喽！
小灵：对，我们在Logical view中定义这些类，然后把它们组织成包。创建类图，把包、类之间的关系绘制在图上，建立起系统的静态模型。这些类将是系统中最稳定的元素。
老幺：go on.
小灵：我们可以为每一个类创建一张（也只能创建一张）状态图。
老幺：怎么操作？
小灵：在浏览窗口中选中一个类，选右键菜单上的state diagram，就可以创建这个类的状态图。状态图描述了这个类的对象在外部事件的影响下的状态改变。
老幺：我们不停的细化和修改这些元素，直到我们可以很容易的实现它们。
小灵：在实现阶段，我们在ROSE的Component view中定义一些实现包。这些包的定义要综合考虑逻辑包的结构和实现环境。在实现包中我们定义一些模块module，模块可以是子系统、子程序、任务等等实现上的划分。然后，我们把逻辑包映射到实现包上，把类映射到模块上。这样就把系统的逻辑结构和实现结构挂上了钩。
小灵：最后，我们还可以为软件系统将要运行的环境定义一张实施图deployment diagram。
老幺：我们把模型建立完了之后，可以使用ROSE的代码自动生成功能为我们自动生成大部分的代码。并且ROSE的双向工程Round-Trip Engineering功能，可以保持代码和模型的一致性。
小灵：怎么样，我学得很快吧？
老幺：不错不错。
小灵：主要是要一步步过一个例子。我觉得有Demo1.mdl、Demo2.mdl、Rosemode.mdl和Wlkthr
_r.htm的例子不错。按照Wlkthr_r.htm的说明 ，一步步做下去，很快就能掌握ROSE的基本操作。我已经把 Wlkthr_r.htm文件翻译成中文了。
老幺：那你还不把它贴到BBS上，让大家共享？
小灵：太大了，而且还是HTML格式的，挺不方便。
老幺：没关系，只要有用就行。
小灵：这样吧，我在BBS上贴一个，再把HTML文档上载到202.197.12.252的目录/incoming/ro-
se_cpp下，名字叫CWlkthr.htm，让大家下载好了。
老幺：太好了。
小灵：我这就做。