各个元素之间的交互作用  

    一个分解级别最本质的方面就是它所暴露和隐藏的交互作用。由于一个分解级别中的每一个元素都是从黑盒的角度被考虑的，所以显示出来的只是它们同系统参与者之间的交互作用。这些元素内部子元素之间的交互作用则被隐藏起来。

    一个有趣的例子来自近期一组人员建模一个商业航行器。在分解的一个特定层级上，航行器表现为一个元素，并且被描述为包括机身、所有板上系统以及机组人员。由于所有这些都被包括在黑盒指定的航行器中，在这个层级上该模型不需要指明任何内部事物。在描述乘客如何开始他们旅行的时候，该模型描述如下：乘客被问候，并且被引导到他们的座位上。虽然听起来很奇怪，但是这是描述这一行为的唯一方法。由于机组人员被看作是航行器的一部分，所以机组人员问候乘客就必须被描述为航行器问候乘客。实际上，这是一种有价值的方法，因为究竟是让乘务员问候乘客还是让自动检票器问候乘客的设计决定，在这个分解层级上并没有做出。

    与此同时，一个分解层级上被强调的内容就是被识别元素之间的交互作用。在上面的例子中，就是乘客和飞行器之间的交互作用。那一个交互作用是重要的将成为决定使用什么分解层级的一个主要因素。将飞行员引入到我们的商业飞行器中。飞行员是属于飞行器系统的一部分呢，还是系统之外的一部分？这两种选择都是对系统建模的完全有效的方法，但是到底选择那一个，取决于那一种交互作用是重要的。如果重要的是飞行员如何同飞行器交互——也就是将飞行器当作一个黑盒，使用整个飞行器的接口——那么在这个层级上就把飞行员当作一个独立的实体为好。这将允许我们描述飞行员和作为黑盒的飞行器之间的交互作用。另一方面，也可以将飞行员和航行器合在一起作为一个系统元素——因而强调控制塔和包括飞行员在内的航行器元素之间的交互作用。出于某些原因，这可能是一种更好的方法。如果我们在设计航行器，那么我们可能对航行器作为一个整体（包括机组人员），如何同诸如控制塔、乘客等外部元素进行交互作用更加感兴趣。

    这可能会考虑让飞行员同航行器内部的元素或者子系统进行交互，而不是同整个航行器进行交互。因此，我们将飞行员作为这个较低分解层级上的独立元素，最为许多独立元素中的一员。

    实践中，判断在您的体系结构中将其设置为什么元素主要取决于所在领域中的经验。选择这些元素是设计系统体系结构的一个关键部分。

    与 RUP 的集成

    MDSD 尚没有作为一个独立的规程被添加到 RUP 之中，它强调团队的统一本性，以及过程的统一本性。

    没有 MDSD 插件程序的 RUP 是软件工程的一种方法。具备 MDSD 插件程序的 RUP 是系统工程的一种方法，它用于软件工程（通过 RUP），然后成为一个子集。

    默认的 RUP 规程（业务建模、需求、分析和设计、实现、测试、配置）和支持性规程（配置和变化管理、项目管理、环境）在系统工程中有着同软件工程一样多的结构部分。MDSD 添加了新的任务、产物和活动，并且修改了某些已经存在的地方，从而为生命周期开发的更广范围和系统工程的额外关注提供支持。

    系统工程在 RUP 网站上并没有被明显描绘成一个独立的规程。然而，包含现有 RUP 的 MDSD 规程是系统工程生命周期的一个过程。

    理解 MDSD 插件程序被连接到 RUP 其余部分的方式同样非常重要。MDSD 期望系统由子系统组成，子系统再由更小的子系统组成。系统，在 MDSD 的上下文中，被定义为和用于处理系统的系统。

    具备 MDSD 扩展的 RUP 可适用于层次系统中的任何层级上，包括最低层级，在这一层级上，至少对于软件而言，子系统的行为是通过软件对象（和链接）的协作被实现的。请注意，从开发人员层级的角度来看，子系统的开发努力就像整个系统开发的过程需要：也就是说，它需要一个启始阶段、精化阶段，等等。所以，如果您查看整个系统的开发计划，您将发现 RUP 阶段顺序，然后看“进去”的话，您将发现许多 RUP 的发展或者生命周期，为每个子系统都提供一个。

    顶层活动是从各个低层级累积得到的。在每一个层级上都有需求、设计和其他活动，并且伴随着独立的逻辑计划。这样做允许我们简单的描述过程，但是仍然能够通过 RUP 生命周期的递归程序，建造十分复杂的计划。然后在任何一个层级上，您可以为您的目的选择活动、任务和任务中的各个步骤。