目录
1、组成结构
2、制品的种类
2.1、部署制品 （deployment artifact）
2.2、工作产品制品 （work product artifact）
2.3、执行制品 （execution artifact）
3、标准元素
4、常用建模技术
4.1、对可执行程序和库建模
4.2、对表、文件和文档建模
4.3、对源代码建模
制品是系统中物理的且可替换的部分，制品是实现平台层次上的物理事物。
对存在于结点上的物理事物（如可执行程序、库、表、文件和文档）进行建模。
制品表示对诸如类、接口和协作等逻辑元素的物理打包。
1、组成结构
制品 （artifact）是存在于实现平台层的系统的物理部分。在图形上，把制品画成带有关键字«artifact»的矩形。
1.1、名称
与类表示形式类似，存在简单名与受限名（用制品所在的包的名字作为前缀）两种
可以用标记值或表示其细节的附加栏来修饰制品。
制品和类都是类目
1）类表示逻辑抽象，而制品表示存在于比特世界中的物理抽象。
2）制品可以存在于结点上，而类不可以。
3）制品表示对在实现平台上的比特的物理打包。
4）类可以拥有属性和操作；制品可以实现类和方法，但是它们自身没有属性或操作。
用表现（manifest）关系显式地表示制品和它所实现的类之间的关系。
2、制品的种类
2.1、部署制品 （deployment artifact）
这类制品是构成一个可执行系统必要而充分的制品，例如动态连接库（DLL）和可执行程序（EXE）。UML的制品定义足以表达典型的对象模型，如.NET、CORBA及Enterprise Java Beans以及其他对象模型，或许还包括动态Web页、数据库表以及使用专用通信机制的可执行程序。
2.2、工作产品制品 （work product artifact）
这类制品本质上是开发过程的产物，由源代码文件、数据文件等用来创建部署制品的事物构成。这些制品并不直接地参加可执行系统，而是开发中的工作产品，用于产生可执行系统。
2.3、执行制品 （execution artifact）
这类制品是作为一个正在执行的系统的结果而被创建的，例如由DLL实例化形成的.NET对象。
3、标准元素
通常可以用标记值扩充制品的性质（如指定一个开发制品的版本），用衍型指定新的制品种类（如特定操作系统的制品）
UML预定义了应用于制品的标准衍型。
（1）可执行程序 （executable） 说明一个可在结点上执行的制品。
（2）库 （library） 说明一个动态或静态对象库。
（3）文件 （file） 说明一个表示文档的制品，其中包含源代码或数据
（4）文档 （document） 说明一个表示文档的制品。
4、常用建模技术
4.1、对可执行程序和库建模
对于大多数系统而言，这些部署制品来源于对如何划分系统的物理实现所做出的决策。
1）技术问题（如对基于制品的操作系统工具的选择）、
2）配置管理问题（如关于系统中哪些部分将随时间而变化的决策）
3）复用问题（即决定复用其他系统的哪些制品以及将哪些制品复用到其他系统中）的影响。
对系统接缝的管理很重要，就要对由一些制品使用并由另一些制品实现的重要接口建模。
上图给出了从个人生产率工具中抽取的一组制品，该工具运行在一台个人计算机上。图中包括一个可执行程序（animator.exe）和四个动态连接库（dlog.dll、wrfrme.dll、render.dll和raytrce.dll），所有这些都分别用UML中关于可执行程序和库的标准元素来表示。图中也给出了这些制品之间的依赖关系。
对于部署在几台计算机上的更大的系统，需要通过表明制品所在的结点来对制品的分布方式建模。
4.2、对表、文件和文档建模
实现中可能包括数据文件、帮助文档、脚本、日志文件、初始化文件及安装/卸载文件等。对这些制品建模是控制你的系统配置的重要部分。
上图展示了围绕在可执行程序animator.exe周围作为被部署系统的组成部分的表、文件及文档。图中包括一个文档（animator.hlp）、一个简单文件（animator.ini）和一个数据库表（shapes.tbl）
4.3、对源代码建模
对源代码的图形化建模特别有助于源代码文件之间编译依赖关系的可视化，也有助于在开发路径分岔或汇合时管理这些文件组的分离与合并。
UML 制品可以是配置管理及版本控制工具的图形界面。
上图展示了用来构造前面例子中的库render.dll的一些源代码文件，图中包括四个头文件（render.h、rengine.h、poly.h和colortab.h），表示某些类规约的源代码。还包括一个实现文件（render.cpp），表示其中一个头文件的实现。
多数情况下，所用的开发工具要把这些组分别放在单独的目录中。在UML中，可以利用包来对这些源代码文件簇建模。
