1、概念模型记录了系统中存在（或者将存在）的领域实体以及他们与系统中其他领域实体的关系，概念层的建模是利用业务领域的术语来完成的，应该是技术无关的。系统的逻辑视图利用了概念模型中创造的概念，建立起关键抽象和机制的意义，并确定系统的架构和整体设计。系统的物理模型描述了系统实现的具体软件和硬件构成，显然，物理模型是技术相关的。
2、包图的主要元素使包、它们的可见性和它们的依赖关系。包为它包含的元素提供了命名空间。具有公有可见性的元素被认为是这个包的接口的一部分，因为这些元素可以被其他元素看见。具有私有可见性的元素对包外元素不可见。
3、UML元素（包括包）之间的依赖关系是用一个虚拟的开房间头来表示的，箭头的尾部位于具有依赖性的元素（客户），箭头位于支持这种依赖的元素（提供者）。如果两个包之间存在多个包容元素依赖关系，这些依赖关系会聚合为包层面的依赖关系。用包分组的元素通常应该在某种意义上时相关的，如它们是系统中的一个子系统、是系统某个方面的相关用例或者是一些协作类，提供系统功能的一个子集。好的分包是松耦合高内聚的，即，应看到包内元素有更多的交互，包间元素有更少的交互，应当尽量不要让泛华层次结构或者聚合关系跨越包的边界。
4、导入是一种公有的包导入，而访问是一种私有的包导入。执行导入的包将被导入元素的名称添加到了它的命名空间中（导入包已经有同名元素的情形除外）。
5、组件图代表了一块可复用的软件，它提供了某种有意义的功能集。从最低的层面而言，组件图是一组类，它们本身是内聚的，与其他类的耦合相对较松。系统中的每个类要么处于一个组件中，要么处于系统的最顶层。组件也可以包含其他组件。组件是一种结构化的分类器，组件间的协作和内部结构可以利用组件图来表示。组件与组件之间通过定义良好的接口进行协作，从而提供系统的功能，组件本身也可以有一些协作的组件组成，提供它自己的功能。因此我们可以组件分层地解构一个系统，并表示它的逻辑架构。组件图中的基本元素是组件、它们的接口和实现。
6、部署图用于展示在系统的物理设计中，工件在节点上的分布情况。部署图有三个基本元素：工件、节点和它们的连接。工件是物理上存在的一件东西，它实现了一部分的软件设计。它通常是软件代码（可执行）、但也可能是一个源文件、一份文档或者与软件代码相关的其他文件。节点是一种计算资源，通常包含存储和计算能力，工件部署在它上面执行。
7、约束：是必须保持的某些语义条件的表达式。换而言之，约束是类或者关系中的不变式，当系统处于稳定状态时必须保持。强调是“稳定状态”，因为可能存在系统改变的瞬间（因此暂时处于内部不一致的状态），在这些瞬间无法保持系统的约束，只有当系统状态稳定时，约束才是保证适用的。
8、分析关注的是行为而不是形式。在分析时尝试对世界进行建模，从问题域的词汇表来确定它元素，并描述它们的角色、责任和协作。在分析过程中。追求表示或实现问题是不恰当的，分析必须说明系统做什么，而不是系统如何做。分析就是要更好地理解待解决的问题。
9、架构主要考虑的是系统各个组件之间的关系，以及它们的责任、接口和协作。相反，系统组件的分析和设计关注的是这些组件的内部以及它们如何满足需求，这些需求是架构的分析和设计要求组件实现的。
10、软件开发过程的框架可以分为两方面：总体软件开发生命周期（宏观过程）以及分析和设计（微观过程）。微观过程的目的是以宏观过程提供的需求作为输入（也可能是前一次微观过程迭代得到的分析和设计规格说明），得到分析和设计规格说明，再返给宏观过程。最后，微观过程将得到规格说明，让宏观过程中的实现阶段去构建、测试和部署。
11、微观过程由4项关键活动组成（识别元素、确定元素协作、确定元素关系、细化元素语义）。微观过程的每次迭代都会针对某个抽象上的一组行为需求，经历这些活动组成的迭代。基本的步骤和得到的产品对于所有的抽象层来说都是一样的，区别之处就在于细节的层次（更低的抽象层次将得到更详细的产品）。
12、具有良好架构的系统是具有概念完整性的系统。在某种程度上，系统的架构基本上与系统的最终用户无关，但是对于构建可理解、可扩展、可重新组织、可维护和可测试的系统而言，拥有“清晰的内部结构”是很关键的。只有对系统架构有清晰的感觉，才能发现共同的抽象和机制。研究这种共性最终使得系统的构建变得更简单。
13、好的软件架构通常具有以下一些共性：1）它们由定义良好的抽象层构成，每层代表了一种内聚的抽象，提供了定义良好的、受控的接口，并且建立在同样定义良好的、受控的底层抽象设施之上。2）在每一层的接口和实现之间有清晰的分离关注，以确保我们能够改变一个层的实现而不用破坏它的客户对它的假定。3）架构很简单：共同的行为是通过共同的抽象和共同的机制来实现的。
