基于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
