图 9 － 带有过程分配的小型 PABX 物理架构

图10－显示了过程分配的大型PABX物理蓝图

    场景

    综合所有的视图

    四种视图的元素通过数量比较少的一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。正如 Rubin 和 Goldberg 所描述的那样6。

    在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示4。

    该视图是其他视图的冗余（因此"＋1"），但它起到了两个作用：

    作为一项驱动因素来发现架构设计过程中的架构元素，这一点将在下文中讨论。

    作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明又作为架构原型测试的出发点。

    场景的表示法

    场景表示法与组件逻辑视图非常相似（请对照图 2），但它使用过程视图的连接符来表示对象之间的交互（请对照图 4），注意对象实例使用实线来表达。至于逻辑蓝图，我们使用 Rational Rose 来捕获并管理对象场景。

    场景的例子

    图 11 显示了小型 PABX 的场景片段。相应的脚本是：

    1. Joe的电话控制器检测和校验摘机状态的变换,并发送消息唤醒相应的终端对象。

    2. 终端分配一些资源，并要求控制器发出拨号音。

    3. 控制器接受拨号并传递给终端。

    4. 终端使用拨号方案来分析数字流。

    5. 有效的数字序列被键入,终端开始会话。

      图 11 － 本地呼叫的初期场景――阶段选择

    视图之间的对应性

    各种视图并不是完全是正交的或独立的。视图的元素根据某种设计规则和启发式方法与其他视图中的元素相关联。

    从逻辑视图到过程视图

    我们发现逻辑视架构有几项重要特性：

    自主性：对象是主动的、被动的还是被保护的？

    主动对象享有调用其他对象或其自身操作的主动权，并且当其他对象对其进行调用时，具有对其自身操作的完全控制权。

    被动对象不能主动调用任何操作，对其他对象调用自身的操作没有控制。

    被保护对象不能主动调用任何操作。但对自身的操作有一定的控制功能。

    持久化：对象是暂时的还是持久化的？它们是否会导致过程或处理器的终止？

    依赖性：对象的存在或持久化是否依赖于另一个对象？

    分布性：对象的状态或操作是否能被物理架构中的许多节点所访问？或是被进程架构中的几个进程所访问？

    在逻辑视图中，我们认为每个对象均是主动的，具有潜在的"并发性"，即与其他对象具有"平行的"行为，我们并不考虑所要达到的确切并发程度。因此，逻辑结构所考虑的仅是需求的功能性方面。

    然而，当我们定义进程架构时，由于巨大的开销，为每个对象实施各自的控制线程（例如，Unix 进程或 Ada 任务），在目前的技术状况下是不现实的。此外，如果对象是并发的，那么必须以某种抽象形式来调用它们的操作。

    另一方面，由于以下几种原因需要多个控制线程。

    为了快速响应某类外部触发，包括与时间相关的事件。

    为了在一个节点中利用多个 CPU，或者在一个分布式系统中利用多个节点。

    为了提高 CPU 的利用率，在某些控制线程被挂起，等待其他活动结束的时候（例如，访问外部对象其他活动对象时），为其他的活动分配 CPU。

    为了划分活动的优先级（提高潜在的响应能力）。

    为了支持系统的可伸缩性（借助于共享负载的其他过程）。

    为了在软件的不同领域分离关注点。

    为了提高系统的可用性（通过 Backup 过程）。