不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。
包的内容 在图5中,"系统内部"包由"保险单"包和"客户"包组成。这里称"保险单"包和"客户"包为"系统内部"包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。
包的依赖和继承 图5中"保险单填写界面"包依赖于"保险单"包;整个"系统内部"包依赖于"数据库界面"包。可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。通过"数据库界面"包,"系统内部"包既能够使用Oracle的界面也可使用Sybase的界面。通用包可标记为{abs tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。
(10) 其他模型元素和表示机制
类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。主要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P arameterized Class)也称模板类(Template)、限定关联(Qualified Association)、多维关联(N-ary Association)、多维链(N-ary Link)、派生(Derived)、类型(Type)和注释(Note)等。
(11) 使用类图的几个建议
类图几乎是所有OO方法的支柱。采用标准建模语言UML进行建模时,必须对UML类图引入的各种要素有清晰的理解。以下对使用类图进行建模提出几点建议:
*不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在UML中,有些符号仅用于特殊的场合和方法中,只有当需要时才去使用。
*根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。
*不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关键的图,经常使用并不断更新修改。使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概念层和说明层。如果已经遇到了一些麻烦,可以从以下几个方面来反思你的模型。
*模型是否真实地反映了研究领域的实际。
*模型和模型中的元素是否有清楚的目的和职责(在面向对象方法中,系统功能最终是分配到每个类的操作上实现的,这个机制叫职责分配)。
*模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的,应将其分解成几个相互合作的部分。
(12) 术语比较
下表列出了最常用的四种UML术语,并与其他方法学中相对应的术语进行比较,以帮助读者了解UML与其他建模语言的异同。(未完待续)
