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"关系。
扩展与泛化相比多了扩展点,扩展用例只能在基本用例的扩展点上进行扩展。
在扩展关系中基本用例是独立存在。
在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系,实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当