在今天的系统开发环境中，IBM Rational客户工作的环境时常会包括多个系统的集成。本文阐述了IBM Rational Unified Process for Systems Engineering?（RUP SE?）如何在这些情况下对你有所帮助。 按照定义，一个系统是一个自我包含的实体，包括所有的需要满足其业务目的或任务的资源。这些资源包括硬件、软件、数据和/或人。一个“包括多个系统的系统”是一个大规模的实体，其整合了由许多较小的（被包含的）系统所提供的能力。IBM Rational统一过程，® 或 RUP，®是面向于构建单一系统的。 那么当我们的环境是一个包括多个系统的系统时，我们该做什么呢？使用 RUP SE。RUP SE 扩展了RUP，除了子系统所表现的逻辑方面之外，更加充分地处理系统的物理方面。
在一个由多个系统组成的系统中，通常会有一个逻辑元素（子系统）和物理元素（在RUP SE中被表示为位置或设计节点）之间多对多的映射。然而这并不是一成不变的，而且有时也很难区分出子系统和位置。理解这种区别的最好方式就是，子系统 是逻辑的，但是位置是物理的。在与客户一起工作时，我们提供了一些与他们的领域直接相关的例子，来解释这些差异。虽然如此，他们也时常会很难将这两个概念分开, 特别是如果他们在产生物理系统时，例如一辆汽车 -- 或者更为特殊，在集成如汽车的引擎、刹车和座位这样的物理系统时。 因此我们做了一些研究和分析，以找出客户为什么会在区分子系统和位置方面遇到麻烦。我们发现的原因是，客户习惯于购买不需要开发的现有的物理元素。这些系统都有逻辑性和实际性两方面，但他们仍然被当做一个单一的实体。 举例来说，坐一个汽车坐椅。如果你的环境是车辆，那么座位就是车辆的一个物理元素。然而今天的坐椅已经有了“记住”和调整不同驾驶员位置, 以及打开和关闭座位中的加热装置的功能。这些是逻辑特性。但如果你正在购买这样一个坐椅来装备一个汽车, 物理的坐椅就会和逻辑功能集中到一个包中，作为一个单一的零件号码，那么，为什么你会不断想到要将它们分开呢? 坐椅事实上按其自身来说就是一个系统；车辆装配师可以将其视为一个黑盒子。是什么使得它成为一个系统呢？这要遵循我们开始的定义：系统是一个自我包含的实体，包括所有的需要满足其业务目的或任务的资源。 这是否意味着我们对系统工程学的方法 －－ 其要求逻辑层和物理层分离－－有缺陷呢？一点也不。相反，我们的方法规定如果设计是必需的则要分离逻辑和物理，但是如果并不要求设计是必需的，则允许你将一个实体视为一个黑盒子。RUP SE 是可扩展的和足够强健的，足以进行从整个系统开发－－换句话说，就是当你必须从头设计所有的元素时－－到集成一个多系统组成的系统的系统开发，以及这两者之间的所有事情。 有关在 RUP SE 插件中所描述的活动的所有这些都意味着什么呢? 实际上，这些活动描述提供给你进行任何开发的几乎所有的指导。有关这些活动，在两种观点上有一个主要区别，一种观点是将逻辑和物理分离，而另一种观点是将元素视为一个系统。对于第一种观点，我们将在逻辑系统中定义逻辑功能（服务）；对于第二种观点我们在被包含的系统中直接定义服务（一种表示逻辑和物理的较低级别元素）。只要IBM RUP SE 插件中的指南要求使用一个子系统，你就可以简单地替换包含系统。而且不需要将包含系统分解为逻辑或物理元素；你可以按照你的用途将其视为一个单一的黑盒子。 为了要在你的设计模型中进行这项工作，需要使用 < < System Proxy > > 原型将包含系统视为一个单一类。就像你处理子系统时，你应当将服务看作这个类上的操作一样。并且，正如你对位置的处理一样，你可以捕捉类的标记值中的物理特性（见图2）。
我希望通过这篇简短的论述能够为你考虑你的开发挑战提供一个有用的方法，尤其是如果你正在处理一个由多个系统组成的系统应用时。我的同事和我经常通过我们内部的系统工程实践社区（SE CoP）来交流和分析来自于RUP SE 和其它IBM Rational工具客户的一些信息。如果你有一些系统工程方面的问题或者想与我们共同分享的事情，请通过Rational Edge发送它们。对于有关 IBM RUP SE 和 IBM RUP SE 插件的更多信息，请参见Murray Cantor 发表的Rational Edge文章：
|
