对一个较复杂的系统建模，需要使用大量的模型元素，这就有必要对这些元素进行有效组织。
实现在UML的建模机制中，模型的组织是通过包(Package)来实现的。包可以把所建立的各种模型组织起来，形成各种功能或用途的模块，并可以控制包中元素的可见性以及描述包之间的依赖关系。
作用方便在高层(按照模块的方式)把握系统的结构。
系统结构对于系统模型的内部组织结构而言，通常采用先分层、再细分成包的方式。
分层一般是按系统架构，常用的一种方式是三层架构：
用户界面层（UserInterfaceLayer，UIL，也称为表示层PL）：代表与用户进行交互的界面，既可以是Form窗口，也可以是Web界面(网页)；不处理任何业务，负责显示与实时更新。
业务逻辑层（BusinessLogicLayer，BLL）：负责系统的业务流程，处理数据访问层传送的数据，并实现业务逻辑。【例如：界面login.html，业务login(input1,input2)，数据访问getData(uid,pwd)】
数据访问层（DataAccessLayer,DAL）：与数据库进行交互，负责将底层数据传送到业务逻辑层。
MVC设计模式——Model、View、Controller
模型层是对系统应用功能的抽象，代表了数据和业务规则；包中的类通常用于封装系统的数据及数据的存取操作。
视图层是对系统数据表达的抽象，代表了系统界面内容的显示；在包中的各个类对用户的数据进行表达，并维护数据的一致性。
控制器层是对用户与系统交互事件的抽象，协调Model与View；通常负责从视图读取数据，控制用户输入，并向模型发送数据。
注意：
包是对模型元素进行分组的机制，它不能执行。
所有的UML模型元素都能用包来进行组织，但一个元素只能属于一个包。
作用包是UML中最重要的分组事物，用来组织模型中的元素。具体作用如下：
提供封装的命名空间。同一个包中，元素不能重名，其元素的名称必须惟一。
提供配置管理单元。例如，以包为单位，对软件进行安装和配置。
在设计时，提供并行工作的单元。例如，在设计阶段，多个设计小组，可以同时对几个相互独立包中的类进行详细设计。
注意：包图uml1是非正式图，但是大量使用，uml2是正式图。
定义包图(PackageDiagram)是用来描述模型中的包及其关系的图。
包图的作用包图是一种维护和描述系统总体结构的模型，是表示顶层架构的机制。
在逻辑上把一个复杂的系统模块化：反映系统的高层架构，在逻辑上将系统进行模块化分解；
描述需求的高阶概况：可以通过包来简要描述系统的业务需求；
描述设计的高阶概况：可以通过包来组织系统的业务设计模型和框架模型；
描述源代码的组织方式：在实际应用中，包是组织源代码的方式。
重用等价原则：把类放入包中时，应考虑把包作为可重用的单元，即要求新版本的可重用类容易替换旧版本的可重用类。
共同闭包原则：把可能同时修改、同时维护的类放到一个包中，以便于维护和升级。例如：一个类的改变要求另一个类做相应改变；删除一个类后，另一个类变成多余；两个类间有大量的消息发送。
共同重用原则：通常，一个包中的元素（类）要么都可重用，要么都不可重用。不会一起使用的类，不要放在同一个包中。
“高内聚低耦合”的原则A：包内元素要紧密联系；最大化每个包中private元素的个数。B：包与包尽可能保持独立，最大限度减少包之间的依赖；最小化每个包中public、protected元素的个数。
包的名称包的名称通常是来自模型词汇中的名词或名词短语。
注意
一个包内同一类模型元素的名字必须是唯一的，不能重名；
理论上，一个包中不同类的模型元素可以有相同的名字。(实际上有的、软件支持有的软件不支持)
最好一个包中的所有元素都有唯一的命名
包中可以拥有的元素：在一个包中可以创建所有模型元素，如类、图以及子包等。
每个元素只能属于一个包。
在包图下允许创建的各种模型元素，是根据各种视图下所允许创建的内容决定。
包的嵌套包可以拥有其他包作为包内的元素，这被称为包的嵌套。外围包（容器包）中包含子包，子包又可以拥有自己的子包。注意：
包的嵌套层数没有限制，但是一般以2到3层为宜。
不同的包中模型元素名称可以相同
包内元素的可见性包内元素的可见性，控制了包外部元素访问包内部元素的权限。
UML常见的内置构造型包有不同的构造型，表现为不同的特殊类型的包。
<
<
<
注意：可以自定义构造型。
两个包之间最常见的关系就是依赖关系，是指两个包所包含的模型元素之间存在着一个或多个依赖。
分类：包之间的依赖有四种：use、import、access、trace注意
use关系是一种默认的依赖关系；因此use可以在建图时，不指出构造型
说明客户包中的元素以某种方式使用提供者包的公共元素，也就是说客户包依赖于提供者包。
import关系使命名空间合并，是最常见的依赖关系。
import（引入/导入）关系说明
引入依赖是可以传递的
客户包的元素可以使用简单名引用提供者包的元素，但提供者包的元素不能与客户包的元素同名，否则将会导致命名空间的冲突。
access(访问)关系说明
在客户包中必须使用路径名。
不同点
import关系使命名空间合并，访问依赖包的元素直接使用简单名即可。
access关系不合并命名空间，必须要使用路径名访问依赖的包的元素。
相同点公共命名空间里的模型元素可以被其他包使用，而私有命名空间中的模型元素则不可以。也就说import和access都不能使用其他包的私有属性，他们两个对其他包的内容的访问权限是一样的。
追踪（追溯），表示一个包到另一个包的历史发展，例如不同版本的包。
和其他泛化关系一样，两包是泛化关系意味着：
特殊包继承一般包的特性，使用一般包的地方，可以用特殊包代替。
特殊包继承一般包中公共和受保护可见性的模型元素，此外还可以添加新的元素。
箭头指向：\(特殊包（子包）\to一般包（父包）\)常见使用场景：例如，在系统设计中，对某一个特定的功能有多种实现方法。这时可以定义一些高层次的“抽象包”和实现高层次功能的“实现包”。
注意任何可使用父包的地方都可以使用子包代替
拥有关系是包嵌套时，包之间的一种组成关系，意味着子包被外围包所拥有。
这是包图最常见的用途，它将建模元素组织成组，建模成包，然后对包进行命名。这种策略在对建模大型项目时尤为重要。大多数情况下，用包组织种类相同的元素，也可以组织不同种类的元素。
遵循的策略
找出在概念或语义上接近的元素，组织到一个包中，同时考虑必要的嵌套包。
对每个包确定包内元素的可见性，重点找出应标记为公共的元素，但应尽可能地少。
在包之间建立关系时，初期一般使用默认的<
考虑采用泛化来对特殊包进行建模
体系结构是一个软件系统的核心逻辑结构，是对系统的顶层分解。
例如：三层架构、MVC模式。
实际上：现在绝大部分的UML建模工具的视图结构，都是使用包元素来划分其体系结构视图的。
例如：RUP的“4+1”视图。
遵从的策略：
包图建模的基本过程主要有四个步骤：
根据系统架构需求，确定分包原则
寻找并创建包—分析系统工作流程
确定包之间的关系
标出包内元素及其可见性
创建包图
创建包
设置包中元素向包中添加元素在包中显示包含的元素
创建包的关系
细化包内元素及包间关系
通过把具有很强语义联系的建模元素分组，找出分析包；
包的命名要简单、具有描述性；
应尽量避免包模型中的循环依赖；
良好包结构的关键是包内高内聚、包间低耦合；（包内元素要紧密联系，包与包之间尽可能保持独立，依赖关系要尽可能少）
应尽可能避免嵌套包;
内容要均衡，建议每个包有7±2个内层成分。系统中的各个包彼此相称，既不要太大（必要时可进行分解），也不要过小（必要时可把所处理的元素组合成组）。
1.根据系统架构需求，确定分包原则分析学生信息管理系统，采用MVC架构进行包的划分。