我最近在总结一些使用Rose等工具进行系统分析设计的经验，下面是正在写的一篇文字的目录框架初稿，欢迎大家来提提意见和建议！

[青润]

基于Rose的全程建模

——基于Rational工具和RUP发过程的实现




作者:白慧冬



目录
1 摘要 4
2 关键字 4
3 为什么要写这篇文字？ 4
3.1 两个项目简介 4
3.1.1 某集团信息化项目 4
3.1.2 某行业项目 4
3.2 初步结论 5
4 如何建立用例图 5
4.1 分析需求 5
4.2 选择ACTOR（主角） 5
4.3 确定USE CASE（用例） 5
4.3.1 用例间的关系 5
4.3.2 用例的分包 5
4.4 撰写USE CASE SPECIFICATION（用例阐述） 5
5 建立ANALYSIS MODEL（分析模型） 5
5.1 模式的选择与应用 6
5.2 构建分析类 6
5.2.1 边界类 6
5.2.2 控制类 6
5.2.3 模型类 7
5.3 建立时序图 7
5.4 职责分配 7
5.5 一个实例 7
6 建立设计模型 7
6.1 设计模式的选择与应用 7
6.2 设计类的构建 8
6.2.1 如何从分析类生成设计类 8
6.2.2 分析类与设计类的关系 8
6.2.3 设计类的开发 8
6.2.4 状态/活动图 8
6.3 设计模型时序图 8
6.4 一个实例 8
7 代码与模型的一致性 8
7.1 框架代码的生成 8
7.2 维护设计模型 9
7.3 反工 9
8 术语 9


基于Rose的全程建模
1 摘要

2 关键字

3 为什么要写这篇文字？
几个月前有人宣称用Rose不能很好的支持全程建模，而且中国的用户不能很好通过Uml所绘制的图形来理解需求。
为此，最近四个月内，我在所参与的两个较大规模的项目（项目组开发人员数量都超过20人）中进行了试验。在项目的进行过程中，通过调用用户参与的积极性，我们收到了非常好的效果。
3.1 两个项目简介
3.1.1 某集团信息化项目
这是一个集团的信息化项目，整个项目的参与人员将近三十人，包括开发人员和参与的管理者。
在项目前期，我带着九个刚刚接触Uml和Rose平均不超过一个月的开发人员进行需求的分析和设计。另外，该集团一个高级管理者（某上市公司的董事长）作为用户方参与了我们的工作。
该管理者从来没有开发过软件，一直在从事企业的管理工作，对办公软件比较熟悉，不懂任何计算机语言。
经过十二天的需求活动后，在活动中，该管理者参与了我们的评审，当然每次评审前我们都针对一些术语对他进行了简要的讲解和描述。后台，他自己说，他都可以看懂我和我的同伴们（程序员）所绘制的用例图和分析模型的时序图，并认为这个并不是很复杂的。后来，他对我们的分析模型还提出了相当有价值的改进意见。
3.1.2 某行业项目
这个项目当时在做系统的分析和设计，用户方要求设计必须可以导出代码。整个项目在分析设计阶段的参与人员将近四十人。我是在完成前一个项目后，得到通知，决定过去参与这个项目的原型开发。
在南京进行的第二个项目中，用户方技术组经过短暂的交流，已经可以对我们的设计模型进行相应的评审并提出他们的看法。
3.2 初步结论
由此可以看出：中国的用户并不是不能接受Uml所描述的需求或者分析设计的含义，关键看你如何来看待、如何使用它进行描述。

4 如何建立用例图
概要描述如何建立用例图

4.1 分析需求
需求调研、分析的过程
4.2 选择Actor（主角）
如何从需求中创建主角
4.3 确定Use Case（用例）
如何确定Use Case
4.3.1 用例间的关系
要描述include、exclude等关系，体现用例间的关联
4.3.2 用例的分包
关系到将来子系统的划分。
4.4 撰写Use Case Specification（用例阐述）
撰写Use Case阐述
5 建立Analysis Model（分析模型）
因为本文主要侧重于如何使用Rose来进行系统的分析和设计，所以这里省略掉了一个开发过程中至关重要的步骤：选择系统架构和进行架构的评估/预研。
我们将把整篇文章的重点放在如何使用Rose从系统的需求到代码导出的过程和结果上。

5.1 模式的选择与应用
在进行一个用例的分析中，一般情况下，我们要考虑一些具体的分析模式的应用。当然，我们也可以考虑按照我们的方式或者一些习惯来进行这个用例的分析。
在这里，我一般选择的都是最通用的一个模式：MVC模式。当然，有些人说：这是一种设计模式！其实分析和设计是很难清晰地划分开来的，很多分析的方法如果进一步的细化的话，那就是在做设计。
不过在这里，我认为分析和设计是不同的，我所认同的定义是：分析是对需求的一种深入的实现性描述，这种描述要比原来自然语言的描述要深入一些，它要求要采用计算机的部分专业术语进行描述整个需求流程。但不需要进行更深入的细化，下一步的细化就是设计。

5.2 构建分析类
如何构建分析类，分析类的描述
采用MVC的模式进行分析模型设计时，我们一般要初步规划出三个类：边界类、控制类和模型类（或者也可以成为数据类）。

5.2.1 边界类
——命名为FormAnalysis
这是一个边界类，是表现与用户交互的直接界面。在进行设计的时候，对应于B/S结构中的浏览器展示的页面部分，如果在用Java开发的系统中，它对应的就是JSP部分。

5.2.2 控制类
——ControlAnalysis
这是一个控制类，是完成整个流程控制与业务处理的部分。
这个类将成为整个系统实现的核心，所有的业务实现和逻辑处理都放在这里。
5.2.3 模型类
——EntityAnalysis
这是一个数据/模型类，在后台如果用Java实现，可以使用EJB来实现也可以直接写一个数据管理的类。一般来说，对应于Ejb中的Entity Bean。当整个Ejb只是完成一个数据处理功能的时候，它可能对于整个Ejb层。

5.3 建立时序图
构建分析模型时序图
下面我们就要开始构建分析模型的时序图了。在构建分析模型的时序图时，我们应该注意的是：分析模型的目的是要比较高级的用户也能够看懂的。
我这里对分析模型的定义就是：将用例阐述通过Uml的时序图表示出来。只要我们做到了这一点，那这个分析模型的最终目标就达到了。更为深入的事情，就交给设计人员去完成吧。
5.4 职责分配
在进行这项工作的时候，建议由需求人员进行绘制，设计人员参与讨论——主要是为了让设计人员明白需求的一些问题。如果一个公司的职能划分足够明确，这个时候，分析模型就只需要有需求人员来绘制，设计人员只负责开发设计模型就可以了。

5.5 一个实例

6 建立设计模型

6.1 设计模式的选择与应用

6.2 设计类的构建

6.2.1 如何从分析类生成设计类
如何根据模式来讲分析类细化成设计类；
6.2.2 分析类与设计类的关系

6.2.3 设计类的开发


6.2.4 状态/活动图

6.3 设计模型时序图

6.4 一个实例

7 代码与模型的一致性
这部分将描述如何从设计模型导出代码，如果在实际开发中保持设计模型的实用性，保持设计模型与代码的一致性。
7.1 框架代码的生成

7.2 维护设计模型

7.3 反工


8 术语
Rose：
Uml：Unified Model Language，统一建模语言
全程建模：
需求：Requirement
用例图：Use Case Diagram
分析模型：Analysis Diagram
时序图：Sequence Diagram
设计模型：Design Model

[l_cheng]

好长时间没上CSDN了，一上来就看到青润要出书的消息，看来老兄功力又增进不少，恭喜恭喜。
我的看法：UML只是一个建模工具，它并不能取代在软件开发各阶段所形成的文字文档，它只是是系统开发过程中产生的诸多文档中的一部分。它并不是方法学，而是各方法学统一使用的建模工具。既然你是打算总结使用Rose等工具进行系统分析设计的经验，我建议以某种方法学运用为背景，介绍UML在需求、分析、设计各阶段所起的作用，而且重点谈谈UML与文字文档的配合问题。

[青润]

首先感谢各位朋友的建议和意见！
这篇文字的主要目的只能有一个，所以，可能不会适合所有的朋友来看。只是一些个人经验和看法的总结，希望能起到抛砖引玉的作用，文章不会非常长，会把我在一些具体项目中的感受和遇到问题的解决方法写在里面，给大家一些建议性的提示。
我为了尽量通俗易懂，在文中大量使用了带注释的图片，注释都是我自己添加的，图片是我截取的。
我会把重点放在分析和设计上，比如：如何划分分析类，如何从分析类导出设计类等等。因为个人知识所限，所以文章不可能很全面。所以：l_cheng(大熊猫) 兄的要求基本上是可以满足的。呵呵，lcgong(踏雪)兄的要求，可能这次不能完全满足，如果有可能的话，我会在一些项目中考虑留下这样的记录性文字，然后依次发表出来——就是不知道csdn愿不愿意出？呵呵
这里大家的要求如果这次我不能在文中写出来的话，我会考虑在今后写给大家。
希望大家多提意见。

[zty0707]

通过书目了解到文章重要侧重于分析设计阶段的建模，全过程的RUP思想未充分体现，包括实施阶段和维护阶段的经验。

[jspxnet]

第一次要详细，第二次就代过

[青润]

zty0707(大嘴)兄评价的很对，一篇文章是不可能体现RUP全过程的思想的，这里主要侧重于如何使用Rose进行分析设计的过程。

[fanjun]

up

[jerryxuyu]

up

[l_cheng]

稿费是怎么算的？出版后请大家搓一顿吧

[lcgong]

欢迎欢迎，别忘了加一些技巧性的东西。

如何使用workspace加速装载速度，如何分配control unit进行协作了。
还有一旦发生元素的编号冲突了，和那个rose.ini了，等等。

但我的疑问：
写关于如何使用Rose的内容的文章和书籍可能容易些，但对于如何进行设计和模型组织的思路，我想要写清楚可能就复杂得多了，两三个月我认为不可能完成的，而且这些“抽象”建模的书，现在和一年前比较，有点泛滥了，经典不多，当然经典很难，这是事实。
********************
我的建议，你不妨写成一个开发日记的形式，如：

XX月XX日：打起了mdl的各package的组织结构（参照Rup framework的），但考虑到项目的xxxx，有些调整....
XX月XX日：认为前面的Usecase有点问题,修改后，对于Realization的Sequence diagram要添加几个对象和完成某项Basic Flow.
XX月xx日：为了方便，将XXX package改为control unit，并提交到CVS上。
每日的后面，可以引入一个角色，嗯，比如：“Dr. MyRose”,对一天的工作讲解一下，综述综述。


我向大家（包括初学者）也看得懂，带进厕所里也看得懂（别误会，引述“编辑部的故事”的葛优的一段名言）。

不知，建议可否？

[summerwine]

RUP注重的是整个开发的统一过程的控制，属于管理的范畴，也没必要在这篇文章里全部描述，不然没有主线了。青润兄有空再写一篇RUP的吧（青润兄很敬业哦，^_^）

to 青润兄：赞成你出书,一定抢手的！csdn不出找别家就是了，出版社这么多 :-J

[raysihu]

请青润兄在分析类与设计类上多花功夫啊,我等着新书呢!:)

[青润]

谢谢各位。
根据各位的意见和目前文章写的程度。
我决定把需求部分的砍掉，主要放在分析和设计上。到十分钟前，终于把文章的初稿写完了，呵呵，有点多，一共有两万多字，图片很多，由于没有时间转化图片格式，整个Word文档有21M之大。
很快就可以和大家见面了。

[青润]

已经完成的文章目录：
1 摘要 4
2 为什么要写这篇文字？ 4
2.1 两个项目简介 4
2.1.1 某集团信息化项目 4
2.1.2 某行业项目 5
2.2 初步结论 5
3 需求的获取和系统架构选择 5
4 建立分析模型 5
4.1 模式的选择与应用 5
4.2 构建分析类 6
4.2.1 构建一个类的步骤 6
4.2.2 边界类 12
4.2.3 控制类 12
4.2.4 模型类 13
4.3 建立分析模型时序图 13
4.3.1 目的和作用 13
4.3.2 如何绘制时序图 13
4.4 职责分配 16
4.4.1 定义 16
4.4.2 现实状况 17
4.4.3 一些建议 17
5 建立设计模型 17
5.1 设计模式的选择与应用 18
5.1.1 一点看法 18
5.1.2 模式的选择 18
5.1.3 该模式的特点和说明 19
5.2 设计类的构建 20
5.2.1 如何从分析类生成设计类 20
5.2.2 分析类与设计类的关系 21
5.2.3 设计类的开发步骤 21
5.2.4 系统的分包 25
5.2.5 设计类的开发（实例说明） 26
5.2.6 状态/活动图 34
5.3 设计模型时序图 35
5.3.1 目的 35
5.3.2 开发步骤 35
5.4 一个实例 38
5.4.1 某工程项目实例图片断 38
5.5 图5.4.1.1的说明 40
5.5.1 No.1的说明 40
5.5.2 No.2的说明 40
5.5.3 No.3的说明 40
5.5.4 No.4的说明 41
5.5.5 No.5的说明 41
5.5.6 No.6的说明 42
5.5.7 No.7的说明 42
5.5.8 No.8的说明 42
5.5.9 No.9的说明 42
6 代码与模型的一致性 42
6.1 框架代码的生成 42
6.1.1 类的语法检查 42
6.1.2 ClassPath的设置 46
6.1.3 导出代码 50
6.2 维护设计模型 55
6.2.1 目的 55
6.2.2 维护方式 56
6.3 反工 56
6.3.1 作用 56
6.3.2 操作步骤（通过实例说明） 57
6.4 其它需要说明的问题 61
7 后记 62

这里，我已经把需求部分砍掉了，不过给了一些简单的建议，主要精力放在了分析和设计上面。完全可以符合raysihu(九曲黄河) 兄的要求。

[summerwine]

青润楼主真是佩服死你了，周末还在无私奉献
上帝会保佑你拥有愉快的心情、美丽的人生、伟大的前程、温馨的家庭、幸福的生活、充足的钞票……

有个小请求：把文章压缩一下发给我一份拜读好吗？迫不及待的想先睹为快了！^_^
我的公司邮箱没有任何限制的[e-mail]

[青润]

to summerwine(醉生梦死)兄：
实在不好意思，因为这篇文章目前属于约稿性质，所以，我不方便提前把它传出去。

不过，我希望csdn是否可以考虑出一本小册子尽早把这篇文章的全文刊出，但是这也要看杂志社的情况了。
另外，全文有两万多字比较长，我目前还在做一些小的修正。

[raysihu]

青润兄,除了你的新书,也希望你能在论坛里多发发软件过程及过程CUT的文章吔

[fish21cn]

佩服，佩服。
晚生多谢前辈指点。

[青润]

没问题，我一直都在网上回答我能够回答的问题，否则，我也不来当这个版主了，呵呵。:-)
其实，我在那篇文章中写道的很多问题都曾经在这个论坛中给别人做出过回答，当然也有一些无法只用语言描述的问题，这次在文中使用图形和注释做了比较详细的阐述。

[chnking]

什么时候能看到这篇文章？

[青润]

这个可能要看CSDN什么时候可以出版了，你们可以直接问问amone或者其他csdn的负责人吧。