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

　　本文是根据发表在 ROAD 1995 年 5-6 月期的由 Ivar Jacobson、Karin Palmkvist 和 Susanne Dyrhage 合著的 "Systems of Interconnected Systems" 进行撰写的。本文吸收了数个大规模系统开发项目的宝贵经验，并有意将它们与 Rational 统一过程(RUP) 和统一建模语言结合起来。

　　互连系统构成的系统

　　开发大规模系统时，其复杂程度将大大增加。它不但要求您能够理解一套更为复杂的工作产物，并且由于需要管理更多的一组资源，您为此还要负担额外的开销。本文描述了一个构架模式，它用于帮助管理新增的复杂性开销。该构架模式在 [4] 的其他地方讨论时被称为互连系统构成的系统。

　　在构建诸如命令和控制系统等大型复杂系统或高度集成的 IT 解决方案时，这种构架模式是很有用的。这些类型的“超大系统”在大多数情况下分成几个不同的部分，每个部分作为单独的系统独立开发。超大系统通过一组互连系统实现，而互连系统之间相互通信，履行超大系统的职责。其中一个系统体现整体性能，我们称之为上级系统。其余系统代表整体的一个部分，我们称之为从属系统。上级系统与实现它的从属系统截然不同。不同类型系统之间的关系泾渭分明：从上级系统的角度来看，从属系统是子系统，请参见图 1。

　　图 1. 上级系统的规约由一个互连系统构成的系统来实施，其中系统 A、B 和 C 分别是上级系统的子系统 a、b 和 c 的实施。

　　区分上级系统及其从属系统有几个好处：

• 从属系统在生命周期内的所有活动中都可以单独管理，其中包括销售和交付。
• 通过把从属系统插入到由互连系统构成的其它系统，就很容易使用从属系统来实施其他上级系统。

　　在开始构建系统的时候，并不总是知道它是不是一个由互连系统构成的系统。您可以从“简单的”系统视图开始，在生命周期的晚期再决定是否需要应用由互连系统构成的系统模式。

　　您不必开发新版本的上级系统，就可对从属系统进行内部变更。只有在主要功能变更时才要求开发上级系统的新版本。

　　每个从属系统都有一组相关的工作产物，工作产物之间有清晰的可追踪性关系。从从属系统的工作产物集到上级系统的相应工作产物集，它们之间也有可追踪性。

　　每个从属系统可以作为独立的开发项目进行管理，它们都有自己的生命周期阶段：初始阶段、细化阶段、构建阶段、转化阶段。

　　如果正在构建的“超级系统”规模很大，可能需要进一步划分从属系统，从而将其作为一个由互连系统构成的系统。

　　软件开发生命周期

　　在 Rational 统一过程(RUP)中，开发生命周期从两个角度进行介绍和讨论：管理角度和开发角度，请参见图 2。

　　从管理角度来看，开发一个系统或者开发新一代的系统都要经历四个生命周期阶段。

　　从开发角度看，您以迭代方式开发日趋完善的系统版本。迭代过程中执行的活动在 Rational 统一过程(RUP)分成一组核心工作流程。每个核心工作流程着重描述系统的某个方面，最终形成一个系统模型或文档集。

　　图 2. 迭代模型

　　将其推广到互连系统构成的系统，上级系统及其每一个从属系统都要经历自己的生命周期，并且它们经常被当作单独的项目。

　　图3. 每个系统，包括上级系统和从属系统，都要经历自己的生命周期。

　　当然，生命周期确实存在依赖关系。如何正确管理依赖关系是开发由互连系统构成的系统所面临的难题之一。依赖关系有以下类型：

• 生命周期与时间相关。上级系统的生命周期首先开始。一旦上级系统经历过至少一次迭代而且从属系统的接口相对稳定，从属系统的生命周期即可开始。实际上，在上级系统至少经历一次迭代之前，您甚至可能不知道哪一个是从属系统。
• 从属系统的接口一旦稳定，上级系统的生命周期即可进入维护阶段。这意味着不进行主动开发，除非出现问题才要求修改从属系统的接口。
• 从属系统的接口由开发上级系统的人掌握。
• 实现从属系统接口的类由开发从属系统的人所有。

　　系统开发的工作流程和工作产物

　　有一个自然前提，即上级系统和从属系统可以使用相同的工作产物集和通过相同的工作流程来进行开发，这在开发非合成系统时尤为典型。在我们继续说明如何执行这一前提前，需要先引入工作产物和工作流程。在 Rational统一过程 (RUP)中，我们引入了五个核心工作流程，请参见图 4。它们分别是：

• 业务工程 - 目的是评估即将使用该系统的组织，更好地理解通过系统解决的需求和问题。最终结果是得到一个用例模型和业务对象模型。该工作流程是可选的。如果即将部署系统的组织结构过于简单，则工作流程可能不会增值。
• 需求 - 目的在于获取和评估需求，重点放在可用性。其结果是生成一个用例模型，其中主角代表与系统通信的外部单元，用例代表事务序列，为主角提供可测量的结果值。
• 分析设计 - 目的在于调查预期实施环境及其对系统构建的影响。其结果是生成一个对象模型(设计模型)，包括用例实现。这些用例实现说明了对象如何进行通信以执行用例流。该工作流程可能包括类和子系统的接口定义，指定它们在所提供的操作上的责任。这个对象模型还在实施语言、分布等方面进行改造，使之适应实施环境。将分析结果作为一个单独的模型考虑有时很有用，这时该模型称为分析模型。

　　图 4. 每个核心工作流程都与一个特定的模型集相关联。

• 实施 - 目的是在规定的实施环境内实施系统。其结果是生成源代码、可执行代码和文件。
• 测试 - 目的在于保证系统与预期系统相吻合，并且在实施中没有出现错误。它生成一个合格的、准备交付的系统。

　　互连系统构成的系统的开发

　　我们必须完成的工作是确定如何能够将一个系统的职责分布在几个系统之间，每一个系统负责一个明确定义的责任子集。这就是说，主要目标是定义这些从属系统间的接口。实现上述主要目标之后，其余工作就可以根据“分而治之”的原则，由每个从属系统独立完成。因此，除了在实施以后对系统进行测试之外，这就是我们要为系统做的全部工作。

　　分解标准

　　那么如何决定是否将系统分解为由互连系统构成的系统?下面是应值得注意的两个特征：

• 如果系统具有相当的规模和复杂性，则可以把问题分成许多小问题，这样更容易理解。
• 是否正在处理物理上独立的系统?在处理遗留系统或者遗留旧构架时常常会遇到这种情况。

　　分解有助于定义系统各部分之间的自然接口和窄接口。

　　您可以决定使用一些重要的 COTS(现货销售)产品来实施系统的一个部分。分解将有助于明确您打算如何使用 COTS 产品。

　　分区可以最大限度地发挥分布式开发组织的潜力，并且清楚划分在地理上分散的几个团队之间的工作。

　　要考虑以下风险包括：

• 过度分割会导致只见树木不见森林的问题。
• 使用物理上分离的系统或者物理上分离的团队，有扼杀任何形式的复用的危险，最后得到的是一个僵化的系统。
• 组织

　　要降低上述风险，关键是要委派一组人监督整个开发工作。这个小组通常称作构架设计师团队，他们应该重点关注以下问题：

• 定义一个整体构架，并且从属系统遵守该构架。
• 适当关注从属系统之间的复用和经验共享。
• 对生产什么工作产物、从属系统工作产物与上级系统工作产物之间有什么关系有清晰的理解。
• 定义一个有效的变更管理策略，并得到所有团队的遵守。

　　构架设计师团队可以(但不总是)控制上级系统的开发。有关组织方面的更充分讨论。

　　上级系统的生命周期

　　首先，可以选择执行业务工程，以便更好地理解系统的环境。在以下情况中，它可以创造价值：

• 开发人员需要更好地理解组织，
• 组织本身的业务运作方式存在不同类型，术语和流程需要统一，或者软件工程与业务重建工程一同完成。

　　该工作将产生一个业务用例模型和一个业务对象模型。另一种方法是，选择执行有限的业务工程，只关注业务领域的关键概念，并在业务模型对象中将其记录下来。这种方法通常称为领域建模。

　　一旦对业务模型集采取了措施，您需要开始获取整个系统的需求。我们对由互连系统构成的系统的需求建模要求与其他系统一样。用例模型是一种非常自然的表示结果的方法，请参见 [7]。考虑该上级用例模型最直截了当的方式就是假定它完全获取了系统的行为需求。然而情况可能很少如此。既然我们需要用其他系统来实施该系统，整体系统很可能相当复杂。因此，在这个级别上钻牛角尖就不是一个好主意。因而，上级用例模型通常给出一个完整但经过简化的系统功能需求图。在该级别上没必要过于详细，因为详细建模将在每个从属系统中进行。而且，许多需求在分成几个子系统的上级用例中并不一定看得见，这也是事实。此类需求可以说是子系统的“局部”需求。

　　分析设计的目的是为了获得一个强壮的系统构架，当然这对由互连系统构成的系统是极其重要的。上级系统的开发人员必须获得一个强壮的从属系统结构，但他们根本不必为内部结构劳心费力。因此我们将使用子系统的概念对系统划分进行建模，将系统分成许多更小的部分。为了得到正确的子系统集，并得到如何在这些子系统之间分配上级系统的职责的初步构思，我们开发了一个分析模型。在执行高级用例时，分析类应该表现系统内的事务所承担的角色。因此，分析模型与高级用例模型类似，给出了完整对象结构的一个简化视图。

　　将功能相关的分析类进行组合，分到不同的子系统中。因而，我们得到的子系统结构从它仅仅基于功能标准的意义上看是理想的，例如，我们并未考虑任何需求分布。遗留系统的存在通常是一个影响巨大的因素。遗留系统可能执行一些或者许多在分析模型中定义的职责。这些系统的存在还可能引起对分析中发现的职责再进行划分，以便能最大限度地复用现有的能力。

　　设计结果可能是一个子系统结构，它与分析过程中基于功能标准所定义的结构差别很大。因此我们最后得到了一个设计子系统结构，每一个子系统将通过一个从属系统进行实施(请参见图 5)。为了能够继续每个此类系统各自的开发工作，我们为每个子系统定义了接口。实际上，定义接口是在上级系统级别执行的最重要活动，因为接口提供了开发从属系统的规则。不需要定义设计类，唯一要做的事情就是定义设计子系统的接口。

　　实施无需作为上级系统生命周期的部分来进行，而只执行一些原型设计工作，研究系统特定方面的技术。

　　最后的工作流程是测试，这里指的是组装不同从属系统时的集成测试，并还测试每个上级用例是否根据其规约通过互连系统协作获得执行。

　　图 5. 上级系统通过一个模型集来描述，其中高级设计模型定义的子系统将通过从属系统实施。从属系统的接口归上级系统所有。

　　为说明如何使用上级系统，下面给出了几个迭代计划样本;一个是上级系统生命周期先启阶段的迭代计划，另一个是精化阶段的迭代计划。我们使用活动图来描述迭代计划。这些图中的动作状态对应 Rational统一过程 (RUP)定义的工作流程明细。

　　图 6. 描述上级系统先启阶段迭代计划示例的一个活动图。

　　图7. 描述上级系统精化阶段迭代计划的一个活动图。由于您为了研究系统的有关技术方面执行了有限的原型实施，这里出现了动作状态“实施类”。