如果某个协作中的各个类只是在相互之间进行交互，并且可生成一组定义明确的结果，就应将该协作和它的类封装在一个子系统中。
这一规则同样适用于协作的子集。可以对协作的任何部分或全部进行封装和简化，这将会使设计更易于理解。
提示
一旦将类组织成子系统，就要相应地更新用例实现。
记录子系统：
一旦创建了子系统：供一个名称和一段简短说明。 如果工具支持包但不支持子系统，可以用包来记录子系统；在此环境中应使用包构造型表示子系统。 应将原始分析类的职责转移给新建的子系统，并使用该子系统的说明来记录职责。
子系统和构件：
构件属于实施范畴；为了在设计中表示构件，可以将子系统用作构件的代理。
系统的每个部分都应尽可能独立于系统的其他部分。 从理论上说，应该可以用新的部分替换系统的任何部分，但前提是新部分必须支持相同的接口。 应该可以使系统的不同部分独立地演进，而不受系统其他部分的影响。 为此，设计子系统提供了一种在设计模型中表示构件的理想方法：它们是用来封装许多类的行为的设计元素（就象构件封装许多类实例的行为一样），并且只能通过它们所实现的接口访问它们的行为（构件就是这样）。
代表现有产品的子系统
如果现有产品是用来导出接口（即操作，也许会导出接收）的产品，但却隐藏了实施的所有细节，就可以在逻辑视图中将该产品建模为子系统。您可以用子系统表示系统所使用的产品，例如：
通信软件（中间件）。 数据库访问支持（RDBMS 映射支持）。 应用程序专用产品。 某些现有的产品，如类型集合和数据结构（例如，栈、列表、队列）最好用包来表示，因为它们所展示的不仅仅是行为。既重要又有用的是包中的特定内容，而不是包本身，包不过是一个容器而已。
对于常用的实用程序（如数学库），如果它们只导出接口，就可以将其表示成子系统，但这是否有必要或有意义，还要取决于设计人员对建模对象性质的判断。子系统是面向对象的构造，它们不仅是分类器，还是包：子系统可以具有实例（如果设计人员作出这样的指定）。通过 UML，也可以在作为构造型类的实用程序（该实用程序没有实例）中建立多组全局变量和过程的模型。
当定义子系统来代表产品时，还要定义一个或多个接口来表示产品接口。
子系统依赖关系限制：
子系统与包在语义上具有差异：子系统是一种通过一个或多个它所实现的接口来提供行为的包。包并不提供行为；它们只不过是用来容纳提供行为的对象的容器。