构件图
在UML中是通过构件图和部署图来表示单元的。它们描述了系统实现方面的信息，使系统具有可重用性和可操作性。
构件
在构件图中，将系统中可重用的模块封装成为具有可替代性的物理单元，我们称之为构件，它是独立的，是在一个系统或子系统中的封装单位，提供一个或多个接口，是系统高层的可重用的部件。
构件作为系统中的一个物理实现单元，包括软件代码（包括源代码、二进制代码和可执行文件）或者相应组成部分，例如脚本或命令行文件等，还包括带有身份标识并有物理实体的文件，如运行时的对象、文档、数据库等。
构件作为系统定义良好接口的物理实现单元，它能够不直接依赖于其他构件而仅仅依赖于构件所支持的接口。通过使用被软件或硬件所支持的一个操作集——接口，构件可以避免在系统中与其他构件之间直接发生依赖关系。在这种情况下，系统的一个构件可以被支持正确接口的其他构件替代。
一个构件实例用于表示运行时存在的实现物理单元和在实例节点中的定位，它有两个特征，分别是代码特征和身份特征。构件的代码特征是指它包含和封装了实现系统功能的类或者其他元素的实现代码以及某些构成系统状态的实例对象。构件的身份特征包含有身份和状态，我们称之为有身份的构件。一个有身份的构件是物理实体的物理包容器。
在UML中，标准构件使用一个左边有两个小矩形的长方形表示，构件名称位于矩形的内部。
虚包是一种只包含对其他包所具有的元素的构件。它被用来提供一个包中某些内容的公共视图。虚包不包含任何它自己的模型元素，它的图形表示形式如下图：
系统是组织起来以完成一定目的的连接单元的集合。在系统中，肯定有一个文件用来指定系统的入口，也就是系统程序的根文件，这个文件被称为主程序。它的图形表示形式如下图：
子程序规范和子程序体是用来显示子程序的规范和实现体的。子程序是一个单独处理的元素的包，我们通常用它代指一组子程序集，如下图：
任务规范和任务体用来表示那些拥有独立控制线程的构件的规范和实现体，如下图：
包规范与包体：
在系统实现过程中，构建之所以非常重要，是因为它再功能和概念上都比一个类或者一行代码强。典型地，构件拥有类的一个协作的结构和行为。在一个构件中支持了一系列的实现元素，如实现类，即构件提供元素所需的源代码。构件的操作和接口都是由实现元素实现的，当然一个实现元素可能被多个构件支持。每个构件通常具有明确的功能，它们通常在逻辑上和物理上有粘聚性，能够表示一个更大系统的结构或行为块。
构件图的含义
构件图是用来表示系统中构件与构件之间，以及定义的类或接口与构件之间关系的图。在构件图中，构件和构件之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系。
在UML中，构件与构件之间依赖关系的表示方式与类图中类与类之间依赖关系的表示方式相同，都是使用一个从用户构件指向它所依赖的服务构件的带箭头的虚线表示。如下图所示，其中“ComponentA”为一个用户构件，“ComponentB”为它所依赖的服务构件。
在构件图中，如果一个构件是某一个或一些接口的实现，则可以使用一条实线将接口连接到构件，如下图所示，实现一个接口意味着构件中的实现元素支持接口中的所有操作。
构件和接口之间的依赖关系是指一个构件使用了其他元素的接口，依赖关系可以用带箭头的虚线表示，箭头指向接口符号。
构件图通过显示系统的构件以及接口等之间的接口关系，形成系统的更大的一个设计单元。在以构件为基础的开发（Component Based Development，CBD）中，构件图为架构设计师提供了一个系统解决方案模型的自然形式，并且，它还能够在系统完成后允许一个架构设计师验证系统的必须功能是否由构件来实现的，这样确保了最终系统将会被接收。