目录
制品图是对面向对象系统的物理方面进行建模时要用到的两种图之一。制品图展示一组制品之间的组织以及其间依赖关系。
利用制品图可以对系统的静态实现视图建模。这包括对存在于结点上的物理事物的建模，如可执行程序、库、表、文件和文档等。制品图实质上是针对系统制品的类图。
1、对源代码建模
将使用集成化开发环境来分割代码，并将源代码存储到一些文件中。可以使用制品图来为这些文件的配置建模，并设立配置管理系统。这些文件代表了工作产品制品。
建模要求
1）对于较大的系统，利用包来展示对这些源代码文件的分组。
2）给出一个标记值，用它指示源代码文件的版本号、作者和最后修改日期等信息。利用工具管理这个标记的值。
3）用依赖关系对源代码文件之间的编译依赖关系建模。利用工具帮助产生并管理这些依赖关系。
上图中有5个源代码文件。文件signal.h是一个头文件，图中显示了跟踪它从新版到旧版的3个版本，该源代码文件的每一个版本都有一个用来显示它的版本号的标记值。
这个头文件（signal.h）被其他两个文件（interp.cpp和signal.cpp）引用，这两个.cpp文件都是体文件。其中一个文件（interp.cpp）有一个到另一个头文件（irq.h）的编译依赖关系，而device.cpp又有一个到interp.cpp的编译依赖关系。有了这个制品图，跟踪变化的影响就容易多了。例如，源代码文件signal.h 发生了变化将需要重新编译 signal.cpp、interp.cpp以及device.cpp这3个文件。该图也显示出，文件irq.h将不受影响。
2、对可执行程序的发布建模
软件的发布是交付给内部或外部用户的相对完整而且一致的制品系列。在制品的语境中，一个发布注重交付一个运行系统所必需的部分。当用制品图对发布建模时，其实是在对构成软件的物理部分（即部署制品）所做的决策进行可视化、详述和文档化。
上图对一个自主机器人的可执行程序发布的一部分进行了建模。该图注重于与机器人的驱动和计算功能相关的部署制品。其中一个制品（driver.dll）表现了引出接口（IDrive）的构件Driving，而这个接口又由制品（path.dll）表现的构件Path所使用。
在构件Path和Driving间的依赖导致了实现它们的制品path.dll和driver.dll间的一个依赖。图中还有一个制品（collision.dll）也表现了一个构件，但图中省略了这些细节，只显示了path.dll对collision.dll的直接依赖。
3、对物理数据库建模
可以把物理数据库看作模式（schema）在比特世界中的具体实现。实际上，模式提供了对持久信息的应用程序编程接口（API），物理数据库模型表示了这些信息在关系型数据库的表中或者在面向对象数据库的页中的存储。可以用制品图表示这些以及其他种类的物理数据库。
三种映射：
（1）（下推）为每一个类定义一个单独的表。这种方法简单，但存在一些问题，因为当增加新的子类或修改父类时，对数据库的维护是很令人头痛的。
（2）（上拉）压平继承的网格，使任何一个类的所有实例都在一个层次上拥有相同的状态。这种方法的缺点是对许多实例要存储大量无用的信息。
（3）（分割表）将父类和子类的状态存储在不同的表中。这种方法很好地反映了继承网格，但它的缺点是访问数据时需要许多跨表连接。
上图给出了一组从学校的信息系统中提取的数据库表。图中有一个数据库（school.db，用衍型化为database的制品表示），其中包括5个表：学生（student）、班级（class）、指导教师（instructor）、系（department）和课程（course）。在相应的逻辑数据库模式中，由于没有继承，所以直接映射到这种物理数据库设计。
4、对可适应系统建模
某些系统是相对静态的，其制品进入现场、参与执行、然后离开。另一些系统则是较为动态的，其中包括一些为了负载均衡和故障恢复而进行迁移的可移动的代理或制品。可以将制品图与对行为建模的UML的一些图结合起来表示这类系统。
上图表示对图3中的数据库的复制建模。图中包含制品school.db的两个实例，每个实例都是匿名的，但各有一个不同的位置标记值。图中还有一个注解显式地说明哪个实例是另一个实例的副本。
