UML 结构图之包图 总结
学习UML, 首先要学会UML的13种图形. 而学习图形, 首选要了解图形上的元素.
[注] 本文不是包图的基础教程, 只是包图的图形总结.
学习UML图形推荐阅读<UML参考手册>第2版. http://www.umlchina.com/
荐微软的开发软件设计模型 http://msdn.microsoft.com/zh-cn/library/dd409436.aspx
包图主要用来表现包和它所包含元素的组织, 包图最常用的用途是用来组织用例图和类图, 尽管它不局限于这些UML元素.
〇 概述
包图可使用的工具集(EA工具箱)有:
一 包图元素
1. 包
Package, 图形表示为一个文件夹, 包的版型(StereoType)有:
1) 普通包, 表示为一个文件夹, 如图Package1和Package4
2) 其它包, 表示为一个文件夹+书名号包含的具体版型或特殊符号, 如图Package2和Package3
2. 类
Class, 图形表示为一个实心矩形或圆形(椭圆)[+一系列附加符号], 类的版型(StereoType)有:
1) 普通类, 表示为一个实心矩形, 如图Class1
2) 边界类, 表示为一个实心圆形+实竖线, 如图Class2
3) 实体类, 表示为一个实心圆形+实横线, 如图Class3
4) 控制类, 表示为一个实心圆形+在圆周上的箭头, 如图Class4
5) 其它类, 表示为一个实心矩形或圆形(椭圆)+书名号包含的具体版型或特殊符号, 如图Class 5, 6, 7 ...
[注1] 类图标变化最大, 版型最多, 必须根据所属的视图或图形进行识别, 如Class2在包图和类图中称为边界类, 在活动图中同样的图标应称为边界对象.
[注2] 类图标的矩形表示和Artifact相似, 都是实心矩形, 区别方法是Artifact图标会含有Icon, 而类图标一般几何元素拼凑.
[注3] 类图标的椭圆表示和用例相似, 都是实心椭圆, 但用例不会出现在类图上, 类也不应该出现在用例图上, 因此不会冲突.
[注4] 包图上的类一般引用类图, 类图内部的画法, 参见类图部分. (下同)
3. 接口
Interface, 图形表示为一个实心矩形+书名号包含的interface字样, 接口没有版型(StereoType).
接口是特殊的类, 因此图标和类相同, 书名号包含的interface是其区别与类的唯一方式.
4. 数据类型
DataType, 图形表示为一个实心矩形+书名号包含的datatype(或其它)字样, 数据类型的版型(StereoType)有:
1) 数据类型, 表示为一个实心矩形+书名号包含的interface字样, 如图DataType1
2) 基本类型, 表示为一个实心矩形+书名号包含的interface字样, 如图PrimitiveType1
3) 枚举类型, 表示为一个实心矩形+书名号包含的interface字样, 如图Enumeration1
4) 表格类型, 表示为一个实心矩形+书名号包含的interface字样, 如图Table1
5) 信号类型, 表示为一个实心矩形+书名号包含的interface字样, 如图Signal1
6) 其它类型, 表示为一个实心矩形+书名号包含的其它字样, 如图DataType 2, 3, 4 ...
[注4] 数据类型用来描述形如枚举, 结构, 表格等特殊的数据类型或类, 同样的, 使用不同的版型是为了定义更准确.
5. 关系
5.1 包与包之间的关系
1) 合并 merge, 表示为一条虚线+单向空心箭头+书名号包含的merge字样, 箭头指向被合并的包, 如图Controller合并GenApply
包合并定义了一个包的内容是如何被另一个包扩展的关系(包合并定义了源包元素与目标包同名元素之间的泛化关系).
2) 导入(引入) import/access, 表示为一条虚线+单向空心箭头+书名号包含的import/access字样, 箭头指向被合并的包, 如图Controller导入Interger
包导入是一种允许采用非限定性名称访问来自于另一个命名空间中的元素的关系.
3) 嵌套 nesting, 表示为一条实线+带十字线的实心圆, 圆远离被合并的包, 如图Controller嵌套ConnSeq(即ConnSeq被嵌套)
源包和目标包间的嵌套连接符说明目标包完全包含源包.
5.2 类与类(接口/数据类型)之间的关系
本图中使用的例子来自 http://blog.csdn.net/tianhai110/article/details/6339565
1) 实现 realization, 表示为一条虚线+单向空心箭头, 箭头指向被实现的接口
2) 泛化 generalization, 表示为一条实线+单向空心箭头, 箭头指向被泛化的基(父)类
3) 依赖 dependency, 表示为一条虚线[+单向或双向开口箭头], 单向箭头表示单向依赖
4) ① 关联 association, 表示为一条实线[+单向或双向开口箭头], 单向箭头表示单向关联
4) ② 聚合 association, 表示为一条实线[+单向或双向开口箭头], 单向箭头表示单向关联
4) ③ 组合 association, 表示为一条实线[+单向或双向开口箭头], 单向箭头表示单向关联
[注5] 应避免双向依赖.
[注6] 几种关系所表现出的强弱程度从弱到强依次是: 依赖<关联<聚合<组合(即耦合度: 组合>聚合>关联>依赖).
6. 可见性
6.1 包的可见性
Package Visibility, 使用版型(StereoType)表示, <<import>>表示public, <<access>>表示private
[注] import VS access:
Ordering在import导入Products和Pricing后可直接使用Products和Pricing包内的元素;
Ordering在access导入Storage后仍可直接使用Storage包内的元素;
而当Ordering被其它包引用时, 其它包只能直接使用Products和Pricing包内的元素, 不能直接使用Storage包内的元素; 但仍可采用Storage::Goods这样的限定性名访问Storage包中的元素.
6.2 类(接口/数据类型)的可见性
Class Visibility, 使用 +/-/#/~ 符号表示
1) 公共 public, 用 + 号表示, 如图Storage包内Goods类的GetCount成员
2) 私有 private, 用 - 号表示, 如图Storage包内Goods类的Count属性
3) 保护 protected, 用 # 号表示, 如图Storage包内Goods类的SetCount成员
4) 包 package, 用 ~ 号表示, 代表包内可见, 如图Storage包内Goods类的Test成员
二 UML通用元素
参见UML参考手册中的特性描述部分, 如一些注释元素, 不单只能画到用例图中, 而是通用的可以画到任何UML图形上的.
如图边界右上角的注释元素
三 用例图总结
本节中出现的建议可应用到任何一种UML图的包应用上, 并非只是包图上.
1. 包的命名要简单, 具有描述性
例如Shipping, Customer, Enrollment和Manage, 这样包包含了些什么就非常的清楚了.
2. 应用包是为了简化图
通常在一个图变得笨重, 单一页中打印不下的时候引入包. 换句话说, 遵循通用指南一一把大的图重新组织为较小的图, 你需要对模型使用分而治之的方法.
3. 包应该连贯
你插入包中的任何东西都应该有意义, 都需要考虑包中的其余内容. 为了确定一个包是否连贯, 一个好的经验法则是你是否能够用一个短的, 描述性的名称为包命名.
如果你做不到这一点, 你或许就已经把几个不相关的事务放到包中了.
4. 在包上用版型注明架构层
我们通常会把设计组织到架构层次中, 例如user interface, business/domain, persistence/data和infrastructure/system.
5. 避免包间的循环依赖
包A依赖于包B, 包B依赖于包C, 而包C依赖于包A, 这就形成了循环: A-B-C-A, Knoernschild (2002)建议尽量避免出现这种情况.
因为包之间彼此紧密耦合, 将来的维护和改进将变得困难. 循环依赖是一个很好的信号, 意味着你需要重构一个或多个的包, 把导致循环依赖的因素从包中除掉.
6. 包依赖应该反映内部关系
当一个包依赖于另一个时, 这意味着两个包的内容间存在着一个或多个的关系. 例如: 如果是一个用例包图, 那么就有可能两个用例之间存在includes, extends, 或继承关系, 而两个用例分别处于不同的包中.
总结来自 http://developer.51cto.com/art/201007/209059.htm
相关链接:
UML 结构图之用例图 总结 http://www.cnblogs.com/snowyying/p/UML_UseCase.html