rose怎么画业务流程图_如何用Rational rose创建类图

UML中各种图形概要：

图名

对照

说明

用例图

use case diagram

用例图表明系统做什么,与谁交互。用例是系统提供的功能，参与者是系统与谁交互,参与者可以是人、系统或其他实体。一个系统可以创建一个或多个用例图。

用例

use case

参考者

actor

关联关系

unidirectional association

泛化关系(继承)

generalization

活动图

activity diagram

活动图显示了从活动到活动的流。活动图可以在分析系统业务时用来淙业务流，也可以在收集系统需求的时候显示一个用例中的事件流。活动图显示了系统中某个业务或者某个用例中，要经历哪些活动，这些活动按什么顺序发生。

泳道

swimlane

活动

activity

state transition

同步

synchronization

决策点

decision

类图

class diagram

类图显示系统之中类与类之间的交互

类

class

方法

Operation

属性

Attribute

序列图

sequence diagram

序列图显示用例中的功能流程

协作图

collaboration diagram

状态图

statechart diagram

构件图

component diagram

构件图显示模型的物理视图，也显示系统中的软件构件及其相互关系，模型中的每个类映射代码构件 ，一旦创建构件，就加进构件图中，然后画出构件之间的相关性。构件间的相关性包括编译相关性和运行相关性。

实施图

deployment diagram

实施图是显示网络的物理布局，系统中涉及的处理器、设备、连接和过程。一个项目中有一个实施图。

Rose模型(包括所有框图、对象和其他模型元素)都保存在一个扩展名为.mdl的文件中。

1.环境简介

1.1 Rational Rose可视化环境组成

Rose界面的五大部分是浏览器、文档工具、工具栏、框图窗口和日志。

1、浏览器：用于在模型中迅速漫游。

2、文档工具：用于查看或更新模型元素的文档。

3、工具栏：用于迅速访问常用命令。

4、框图窗口：用于显示和编辑一个或几个UML框图。

5、日志：用于查看错误信息和报告各个命令的结果。

1.2浏览器和视图

浏览器是层次结构，用于在Rose模型中迅速漫游。在浏览器中显示了模型中增加的一切，如参与者、用例、类、组件等等。Rose浏览器见图1-2。

浏览器中包含四个视图：Use Case视图、Logical视图、Component视图和Deployment视图。点击每个视图的右键，选择new就可以看到这个视图所包含的一些模型元素。

1.3框图窗口

我们可以浏览模型中的一个或几个UML框图。改变框图中的元素时，Rose自动更新浏览器。同样用浏览器改变元素时，Rose自动更新相应框图。这样，Rose就可以保证模型的一致性。

2.UML各类框图的建立

2. 1建立用例图use case diagram

从用例图中我们可以看到系统干什么，与谁交互。用例是系统提供的功能，参与者是系统与谁交互，参与者可以是人、系统或其他实体。一个系统可以创建一个或多个用例图。

------------------------------------------USE CASE 图-----------------------------------------------------------

用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成，用画图的方法来完成。

1、参与者

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。

因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。

参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

参与者的画法：

2、用例

是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义。

我们可以简单的理解为：用例是参与者想要系统做的事情。

3、系统边界

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

4、箭头

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。

箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

USE CASE图的作用

主要的作用有三个:(1)获取需求;(2)指导测试;(3)还可在整个过程中的其它工作流起到指导作用。

use case图中的关系：

用例图中包含的元素除了系统边界、角色和用例，另外就是关系。

关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。

1、角色之间的关系

由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，

泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

2、用例之间的关系:

包含关系:基本用例图的行为包含了另一个用例的行为。

基本用例描述在多个用例中都有的公共行为。

包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系

3、泛化关系:

代表一般与特殊的关系。

它的意思和面向对象程序设计中的继承的概念是类似的。

不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

4、扩展关系：

扩展关系的基本含义和泛化关系类似，但在扩展USE CASE图关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

5、用例的泛化、包含、扩展关系的比较：

一般来说可以使用"is a"和"has a"来判断使用那种关系。

泛化和扩展关系表示用例之间是"is a"关系，包含关系表示用例之间是"has a"关系。

扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。

在扩展关系中基本用例是独立存在。

在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以USE CASE图在基本用例中设置扩展点，使用扩展关系。

扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。

通常先获得基本用例，针对这个用例中的每一个行为提问:该步骤会出什么差错?该步骤有不同的情况工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，

而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。

6、用例