包图是UML中用类似于文件夹的符号表示的模型元素的组合，系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中，使用包图可将相关元素归入一个系统，一个包中包含附属包、图表或单个元素。简单的来说，我们可以直接将包理解为命名空间，文件夹，是用来组织图形的封装，包图可以用来表述功能组命名空间的组织层次

      那么为什么会出现“包”这个概念呢？我们知道，在面向对象软件开发的视角中，类显然是构件整个系统的基本构造块，但是对于庞大的应用系统而言，其包含的类不计其数，再加上类之间阡陌交通的关联关系、多重性等，必然大大超出我们可以处理的复杂度，所以“包”由此而来。今天我们一起来学习一下包图的相关知识，首先，我们来看一下包图的主要内容：

        

      对包图的主要内容有了一个整体的感知，接下来，我们一起来看看包图的简介以及包与包之间有着怎样微妙的关系呢：

     

      我们来看看包与包之间的关系，首先，我们来看依赖关系，如下图

      

        我们看看上述的图例，首先包与包之间的依赖关系跟我们平常所说的类的继承关系是不同的，包括包的访问域不能继承，用于在一个包中，引入另一个包输出的元素，因此A依赖B，包A引入包B中的B方法，B这里的访问权限是公共的，A中的方法是保护的。根据已学的知识，我们知道包和包之间也存在泛化关系，包与包之间的泛化关系，是体现在类与类的关系上，包之间不能画泛化关系，画依赖即可。接下来一张图，我们一起来了解一下包的访问限制：

      

      我们知道了类图的基本概念，以及类图之间的关系，那么包图究竟有着怎样的目的，以及画包图又具有着怎样的准则呢：

      

      了解了包图的目的以及准则，我们再来一起学习一下包图存在的问题以及包图的解决方法：

      

     包图的基本知识就介绍到这里，现在以机房收费系统为例，在具体的系统当中，我们的包图又是如何得到应用的呢：

       

       包是用来封装元素的通用机制，包不仅有助于建模人员组织模型中的元素，而且也使建模人员能控制对包中内容的访问，接下来我们以订单，结算、顾客、送货为例，画出一个详细的包的示例图：

      

      双向箭头表示的意思，两个包之间互相依赖，箭头指向被依赖的一方，比如说订单依赖结算，订单和顾客相互依赖等等。初次接触包图，我用一个小小的例子这样来理解的，如下：

       比如说，现在我们要搭一个小狗的窝，一个房屋，还有一个大厦，首先，小狗的窝并不复杂，有四面墙，其中一面墙上有一个能让小狗穿过的洞，还有一个顶棚，在搭小狗窝的时候，我们只需要一小堆木材，即可。再次，我们来看房屋，房屋比较复杂，墙、天花板和地板组成了较大的抽象体，称之为房间。甚至可以把这些房间组成更大的组块，如公共区、卧室区、工作区等 ，这些较大的组可能并不表明他们本身就是与物理房屋有关系的任何事物，而可能只是给出的在逻辑上有关的屋中一些房间的名称，当谈论怎样使用这栋房屋时就使用这些名称。最后我们再来看看大厦，大厦相对于小狗窝和房屋来说较复杂，大厦不仅有墙，天花板和地板等基本结构体，而且还有公共区，零售厅和办公区等较大的组块，这样的组块甚至还可能合并成更大的组块，例如出租区和大厦服务区。这些组块与最终的大厦本身无关，而只是用来组织大厦设计的产物。

        所有的系统都是以这种方法组织的，事实上，理解复杂系统的唯一方法就是把抽象组织成更大的组，大多数适度规模的组块如房屋其本身都是像类那样的抽象。再者，如我们上面所说的零售厅，她是纯概念性的，没有实际的实例，他们不是实际系统中明确的对象，而仅仅表示系统本身的视图。

       在UML中，我们把组织模型的组块称之为包，一如我们上面所说的例子当中，大厦所包含墙、天花板、地板、公共区、零售厅、办公区等。包是用来把元素组织成组的通用机制，包有助于组织模型中的元素，使得更容易理解。UML之旅，未完，待续......