利用 Rational 统一过程开发大规模系统

　　由互连系统构成的系统中的每个系统，包括上级系统和从属系统，都应该有自己的设计模型。设计模型按以下方式相关：

• 上级系统设计模型中的子系统定义了从属系统的边界。
• 为上级系统子系统定义的操作是定义从属系统接口的输入。

　　对上级系统设计模型的描述不如描述从属设计模型详细。描述对象包括：

• 子系统，简要说明。

　　用例实现，利用子系统协作方式描述。记录这些高级用例实现的一般方法是绘制序列图。通过绘制这些图形，您可以定义在从属系统上的高级用例的“分块”，请参见图 13。

• 子系统的操作。
• 子系统的接口定义。

　　图 13. 实现上级用例 A 的序列图。

　　在互连系统构成的系统中的信息集

　　大多数组织在理解如何管理工作产物以及如何正确理解它们的依赖关系等方面都投入大量精力。我们在上一节特别讨论了上级用例模型和设计模型与从属用例模型和设计模型之间的依赖关系。另外还要考虑一些一般性的依赖关系问题。

　　系统经过生命周期的某个关口后，将产生可组织成信息集的工作产物，请参见图 14。这些信息集按“共同”演进的工作产物进行组织。

　　根据正在构建的应用程序类型，可以定制每个集合的确切内容，但集合保持不变。

　　您需要理解集合之间的依赖关系，这样才能有效地维护工作产物之间的可追踪性。

　　图 14. 系统的生命周期将产生信息集。

　　在互连系统构成的系统中，上级系统和每个从属系统将产生各自的信息集，请参见图 15。

　　从属信息集对相应的上级信息集有依赖关系。

　　由于应用程序类型不同，上级系统之间的相应信息集的内容类型也可能不同。

　　相关的从属信息集应该是独立的，只是它们服从于上级系统定义的相同子系统接口。

　　在维护上级系统与从属系统工作产物之间可追踪性上投入的精力应该尽量要少。应确定维护系统内的可追踪性的优先顺序。

　　图 15. 在互连系统构成的系统中的每个系统将生成自己的信息集。

　　互连系统构成的系统之构架

　　由互连系统构成的系统中的每个系统，包括上级系统和从属系统，都应该定义自己的构架。

　　对于上级系统，构架文档应包括以下方面：

• 上级系统的关键用例或场景。
• 对互连系统构成的系统的分层。
• 如何处理从属系统之间的复用以及复用内容。
• 所有从属系统都能使用的通用关键机制及其实施。

　　例如，所有从属系统都应该使用通用的通信、错误报告、容错管理机制，否则上级系统不会表现为同类系统。

　　对于从属系统，构架文档应该澄清以下问题：

• 从属系统在互连系统构成的系统内的角色。
• 从属系统的关键用例或场景。
• 从属系统如何使用为由互连系统构成的系统定义的分层结构。换句话说，就是定义从属系统如何履行在互连系统构成的系统的分层结构中为它定义的职责。
• 使用哪些通用的关键机制、如何使用用以及添加哪些应用程序专用的关键机制。
• 如何复用。确切地说，哪些子系统是两个或多个从属系统公有的，需要建立哪些机制来允许从属系统进行通信。

　　系统之间的关系

　　您已经看到，常用的系统开发活动也可应用于通过互连系统构成的系统实施的系统。这是非常有利的，因为它意味着你不必用一种与其他系统大相径庭的方式处理此类系统。您还可以很好地将上级系统与其以其他从属系统形式进行的实施分离。在互连系统构成的系统中的每个系统都有自己的生命周期。既然每个系统可能有不同的特点，您可以使用不同的开发流程来生成系统。依据 Rational统一过程 (RUP)，每个系统将有一个不同的开发案例。

　　最后注意在互连系统构成的系统中所涉及系统之间的独立性：

• 首先，查看一下从属系统。在上级系统的设计模型中，每个从属系统实施一个子系统。子系统依赖于彼此的接口，但相互之间不直接依赖，请参见图 12。因此，可以用新版本替换其中的一个子系统，只要新的子系统使用同样的接口，就不会影响其他子系统。您将在从属系统之间得到完全相同的关系。每个从属系统都将其周围环境看作一个接口集。这意味着您可以更换系统，只要新系统对其他系统扮演的角色相同就可以，例如新系统可以用相同的接口集来表示。系统相互引用各自的接口，这是由上级模型中子系统和接口之间的对应关系指定的。
• 在从属系统的用例模型中，与之交互的其他从属系统的接口表示为主角。可以说，从属系统把另一个系统的接口看作是由相关主角提供的，因此永远不必直接引用其他系统，请参见图 16。注意在图 12 中，有几处地方出现了接口 B，说明接口 B 是上级系统中的子系统和相应从属系统实际引用的同一个接口。

　　图 16. 上级系统的子系统仅仅通过接口相互依赖。因此实施从属系统就得到了同样的独立性。在上级系统的模型中，子系统 B 提供与其他子系统连接的接口 B。因而，相应的从属系统 B 也需向其他从属系统提供相同的接口 B。

　　那上级系统情形又如何呢?它与从属系统有什么关系?从以下方面讲，它独立于其实施系统：每个这类的系统仅仅是上级系统模型中所指定内容的一个实施，并不属于上级规约的一部分。出于实际原因，为了追踪需求，您需要定义不同级别上系统之间的可追踪性链接，而最“简洁”的方法就是只在接口之间定义此类链接，请参见图 11。事实上，甚至可以说从属系统只不过是提供了上级模型中所定义接口的实施。

　　但是，这仅仅对简单系统成立。接口除了说明在一个特定交互点所发生的事情之外，并未指定任何东西。一个从属系统可能有 100 个接口，每个接口有 10 个操作。在接口说明中，把某个接口的输入与另一个接口的一个或多个输出相关联是不切实际的。这就是为什么需要用例来解释从属系统的语义的原因。

　　可以得出结论，当一个系统由互连系统构成的系统实施时，所涉及的每一个系统都独立于其他系统，但它们严重依赖彼此的接口。这就为您提供了一个很好的从属系统并行开发平台。

　　应用范围

　　互连系统构成的系统的构架和建模技术可以用于多种系统，如：

• 分布式系统
• 很大或者很复杂的系统
• 合并几个业务领域的系统
• 复用其他系统的系统

　　系统的分布式开发

　　情况也可以反过来：从一组现有的系统，通过组装系统来定义由互连系统构成的系统。实际上，在某些情况下，大型系统在演进的早期阶段就是以这种方式发展的。你意识到你有几个可以互连的系统，那么让系统互连可以创建一个“大型”系统，它比两个独立的系统能创造更多价值。

　　I事实上，如果一个系统的不同部分本身可以看作系统，建议把它定义为由互连系统构成的系统。即使现在它还是单个的系统，由于分布式开发、复用或者客户只需购买它的几个部分等原因，以后也会证明把系统分割成几个独立的产品是有必要的，这里仅仅举几个示例。

　　作为结论，我们来认真分析两个可以使用由互连系统构成的系统构架的案例。在每一个示例中，我们将说明讨论中的系统既要作为单个的系统考虑，又要作为分离系统的集合考虑，以此说明它应该作为通过由互连系统构成的系统实施的上级系统来对待。

　　大规模系统

　　电话网络可能是世界上最大的由互连系统构成的系统。这是一个很好的示例，在电话网络中需要管理两个以上系统级别的复杂性。它还作为这类案例的示例：顶层上级系统由一个标准化实体掌握，不同的竞争公司开发一个或几个必须符合该标准的从属系统。这里，我们将讨论移动电话网络 GSM (全球移动电话系统)，说明将大规模系统作为互连系统构成的系统来实施的优势。

　　大规模系统的功能通常包含几个业务领域。例如，GSM 标准包括了从呼叫用户到被呼叫用户的整个系统。换句话说，它既包括移动电话的行为，也包括网络节点的行为。由于系统的不同部分是单独购买的产品本身，甚至是由不同客户购买的，因而它们本身可当作系统。例如，开发完整 GSM 系统的公司向用户销售移动电话，向话务员销售网络节点。这是把 GSM 系统的不同部分当作不同从属系统的一个原因。另一个原因是，把 GSM 这样大型复杂的系统作为单个系统进行开发的时间太长;不同的部分必须由几个开发团队并行开发。

　　另一方面，由于 GSM 标准包括整个系统，因此有理由将系统作为一个整体即上级系统来考虑。这有助于开发人员理解问题领域，以及不同部分是怎样彼此相关的。

　　分布式系统

　　在分布在几个计算机系统的系统中，使用由互连系统构成的系统构架是非常合适的。顾名思义，分布式系统至少由两个部分组成。由于分布式系统中必须有明确定义的接口，因此这些系统也非常适合进行分布式开发，也就是说，几个独立的开发团队并行开发。分布式系统的从属系统本身甚至可以当作产品来销售。因而，将分布式系统视为独立系统的集合是很自然的。

　　分布式系统的需求通常包括整个系统的功能，有时不预先定义不同部分之间的接口。而且，如果对开发者而言问题领域是陌生的，他们首先需要考虑整个系统的功能，而不管它将如何分布。这是把它当作单个系统看待的两个重要原因。

　　遗留系统的复用

　　大型系统常常复用遗留系统。遗留系统可作为从属系统来描述。为了理解遗留系统如何在上级系统的大环境中工作，需要为它“重建”一个用例模型，有时还有一个分析模型。这些重建的模型不必完整，但至少要包含对互连系统构成的系统的其余部分有直接影响的遗留功能，否则需要进行修改。

　　使用预先制作好的软件包

　　系统可以集成和定制两个或多个预先制作好的软件包。企业资源规划 (ERP) 系统就是一个典型示例。许多 ERP 系统是 MRP(材料资源规划)、库存管理、供应链管理等从属系统的组合。其他领域也有类似组合，如人力资源和工资单应用等。它们就像预制系统一样，为了得到一个完整的系统，必须令其专用化并与其他标准包互连。为理解包集合的作用，我们需要上级系统。这是在金融界许多客户所面临的情况。

　　总结

　　本文提出了一种由互连系统构成的系统构架模式。这个构架模式不但允许在一个模型内递归，它还把每个子系统本身作为一个系统考虑，并允许在每个系统所有的工作产物集之间递归。引入的构架用于那些由几个相互通信的系统实施的系统。所涉及的每个系统用它自己的模型集描述，与其他系统的模型分开。

　　采用这种技术的优势是显而易见的：可以处理相当复杂的问题，并使用“分而治之”的原则来理解它们。然而，缺点就是您的开销增大，进度无法同步。我们还考察了几个示例，在这些示例中，组织发现上级系统很难使用迭代式生命周期，从而承担风险被推到上级系统生命周期末尾的危险。您还要注意执行合理而有效的复用策略，以避免开发出一个“僵化”的系统集。

　　本文给出的示例说明了由互连系统构成的系统建模构架可用于许多应用领域。实际上，只要系统的不同部分本身可看作系统，就可以使用本文提出的构架。

查看本文来源