| 本文来自于 Rational Edge：是有三个部分的系列文章中的第二篇，本文详述了在高端打印系统的实例环境中，模型驱动系统开发（model-driven systems development，MDSD）的过程。作者识别了角色及其系统交互，列举系统用例和服务，并示范在过程中使用 UML 进行可视化建模。本系列从系统的角度探究联合的硬件或软件产品开发，并提供一个用于优化功能分配的普遍的模型驱动开发（MDSD）方法。它应用技术并利用结合 Rational Unified Process for Systems Engineering（Rational Unified Process for Systems Engineering，RUP-SE）的当前版本的框架要素，RUP-SE 是一个扩展 IBM Rational Unified Process?，或称 RUP ?的已证明的 MDSD 框架。这些工件在 IBM Rational Method Composer（2005 年 12 月出版）的当前版本中可用，该版本为裁剪方法和过程提供一个灵活的框架，以及最佳实践和用于参与 MDSD 的产品开发团队的在线指导。 本文的第 1 部分 讨论了硬件或软件联合开发的独特的挑战，以及传统系统工程方法的限制。我们介绍了一种基于带有 RUP-SE 扩展的 RUP 框架的模型驱动系统开发方法。我们还介绍了 Rational 的六个系统工程原则，并描述了它们与 MDSD 如何关联。 在第 2 部分中，我们将通过略述一个实例打印系统的体系结构推导开始阐述我们的 MDSD 方法。我们将确定打印系统的环境，识别角色，及角色和打印系统之间的协作，用以满足风险承担者的需要。将需要列为系统用例，并描述完成预定结果所必需的服务。此活动是处于环境级的分析。在此过程中，我们将示范 UML 序列图画法，并可视化地建立环境级的逻辑和物理视图模型。 在第 3 部分中，我们将继续回到示例打印系统的结构分解上，说明系统体系结构开发的分析级上的活动。在此我们确定候选的子系统（逻辑要素）和位置（物理要素），它们的交互将满足可以从系统级用例中看到的服务。我们将举例说明，利用 MDSD 方法接合实现跨越硬件和软件边界的需求及多个观点。我们还将讨论从环境和分析层模型中所包含的抽象转移到硬件、软件、固件和工人协作下的系统实现的技术。我们将进行总结，叙述此方法如何提供一个有效的硬件或软件联合开发的过程（该过程简化了多个学科的团队间和内部的适当的协作），并指导项目和程序管理层，帮助确保在产品生命周期内风险承担者的价值是优化的。 在讨论模型之前，我们将简要介绍现代打印系统的历史，帮助您了解对健壮的打印系统体系结构，以及模型形式的体系结构表示的需要。 直到 70 年代中，打印系统都是面向线型的，并且几乎是专门基于打印链的。1 在输入或输出服务（input/output service，IOS）、作业调度（例如，MVS 调度器）、作业执行和处置（作业入口子系统 —— JES），和系统附件（SYSGEN）方面，每个新的打印系统都要求对支持的操作系统进行大范围变更。 由于技术的进步使得打印系统不仅能够处理数据行，还能处理页，所以打印系统的复杂度变得非常大，随着复杂度的增大，70 年代后期世界开始改变了。 这个变化的催化剂是电子照相技术（激光打印机之后的打印技术），此技术将一个页面分割成一个可编址的单元（打印机元素，或象素）组成的大型矩阵。突然间，点群逻辑上形成了印刷人物、图像、徽标，和打印操作员更熟悉的其他单元。 70 年代流行的打印数据流2不能伸缩到以支持这个新方法。软件和硬件工程师遇到了一个挑战 —— 开发足够宽的体系结构，用于处理硬件、微指令，和软件需求，然后设计、开发，并在提供支持的操作系统平台上集成各种打印系统组件。 此外，要确保与现有的打印应用程序、打印数据流，和操作系统组件的兼容性，这样就允许逐渐将这些新的打印系统引入到客户环境中。 注意到，很有趣的是打印系统的原始设备制造商采用了三个不同的方法： Xerox 设计了一个包含所有打印机硬件的自主打印系统，支持在一个单独的物理设备上的打印服务器软件和打印资源。此系统既能够接受来自主机系统的行式数据，又能接受直接依附到打印系统，并在其上进行处理的行式数据带。每个打印系统都有其自己的操作控制台和独有的打印资源。 到了 90 年代，技术再一次成为促进打印系统体系结构和实现变化的催化剂。这次的催化剂是个人计算机的普及及高性能的工作站硬件。 80 年代的打印系统很大程度上根据 70 年代的技术而变化。产品开发的主要限制，以及快速革新的抑制剂是将大部分主要打印系统功能直接构建在硬件中的需求（带有专用内容的多重电路板）。 PC 改变了这一切。代替高度复杂且昂贵的专用板，大多数的打印系统功能都由软件实现，由广泛应用的操作系统（如 AIX 和 Microsoft Windows）支持，并寄存在 PC 机或工作站上。除了降低成本并提高可靠性，该变更还提供了可伸缩性和组件重用。 这种变更带我们来到了现在。市场上有非常多种类的打印系统。高端打印系统仍旧需要 PC 机和 UNIX 机作为物理打印系统单元，但低端打印系统全都是“卡上系统”，由内嵌主机驱动（基于嵌入式操作系统，如 Wind River 的 VxWorks）。而典型的系统的确是一个系统的系统，带有各种协同工作的通用的和专用的系统，执行打印系统的任务。 由此展望，慢速的打印系统开始看起来像市场中许多其他的系统的系统了 —— 汽车、飞机，和通信网络，这里只举出一些。 变更是不可避免的，技术发展的快速步伐要求不仅要重视变更，还要计划将变更作为以加速的进度成功地引入产品的手段。 系统描述 首先我们确定打印系统环境的范围，包括将与打印系统交互完成任务的交互系统和其他角色，我们通过这个操作开始推导出打印系统的模型。 最初这些工作由一组系统级用例进行描述。这些将用于帮助您以最少的逻辑和物理观点导出环境和分析级视图。随着我们开始将打印系统分解为组件和子组件，我们还需要根据系统级用例中确定的服务将系统级用例分解为子系统级用例。 这个过程 —— 随着模型改进的需要而在层次间上上下下 —— 使我们能够将负责的关系分割为更易于管理的部分（通过着重于具体的观点，如过程、数据，或物理），并在适当的时候，将所有的单元重新集成为一个复合的整体。 它还帮助您更清晰地看到产品开发的典型设计和开发阶段，并且在系统开发团队中联系了硬件、软件、微指令，和其他传统垂直域。 系统范围 我们将依据上面描述的第二种方法（IBM 的系统的协作系统设计），开始描述打印系统的直接环境。在我们限制系统环境时，我们可能还需要注意系统边界之外的角色、系统，和商业因素，这将向整个讨论中加入相关的内容，也许甚至要引入一些会影响到系统设计的补充需求（在可扩展性、可伸缩性、可靠性，和性能等领域）。3 在第二个打印系统设计方法（在 IBM 中使用的时间超过十年）中，系统开发者（也是 IBM）实际上超过了一个系统集成者。当 IBM 开发重要内容时，它从其他公司购买物理打印系统部件。有时候保持部件的原样，在其他情况下，IBM 与某些原始设备制造商合作，定制符合 IBM 规范的部件。 除了紧密集成到打印系统中的部件以外，打印系统还有潜力包含松散耦合的部件，这些部件能够增强底层系统所执行的服务。这些松散耦合的部件可以作为底层系统的一部分加载上去，或者由客户分别获取。由于这些松散耦合的部件所执行的功能从整体上看是打印系统的一部分，所以我们必须在体系结构上解释它们，并将它们包含入系统开发生命周期的所有工作中。 这里我们选择例举一个包含，例如，不断滚动的 Web 新闻的高端打印系统。根据这些系统的大小和成本，它们主要用于大容量的打印需要并需要专门的操作员。这些系统出现在数据中心，并且用于处理支票、金融帐目、保险单，公共事业票据，并用于印刷书籍。 在这样的打印系统所达到的速度和容量上，企业和签约的维护商就需要共同进行常规的维护，用以确保系统能够满足由企业和维护商共同协定的服务等级。此外，相关的速度要求使用附加的设备来保持纸张通过底层系统一次要持续几个小时，并且要以与打印系统的速度和容量相一致的速率进行有效的打印输出后置处理。 一个典型的打印中心一周最少运作五天，每天八小时，一周最多七天，每天二十四小时（在这里，打印系统只在常规的预防性的维护时才断线）。不必说，这些打印系统具有高可用性和高吞吐量的需求。连续的打印操作预期达到最大能力的 70％。 已知上面的内容，并且知道了第二个设计方法将打印服务器（提供处理打印系统的文档并监视打印过程的所有电子方面）和打印系统分离了，我们最初的系统环境包括以下内容： 系统 打印系统 打印系统：确实是一个系统，不仅仅是一个打印机。在最简单的情况下，打印系统是一个单个的自主式的，含有内嵌的打印系统控制单元、网络硬件和软件、纸盒，及打印引擎（将文档要素实际传输到纸张上）的设备。 在一般的情况下，打印系统由离散的组件构成 —— 每个组件执行生成最终输出文档（可以是报告、简单的邮件，或装订的书籍）所需要的操作子集。这些组件可能是松散耦合或紧密集成的。 松散耦合意思是组件在物理上是分离的，而通过一个简单的接口通信，指示其是否准备好了（称为 Type I）。 紧耦合意思是组件在物理上是分离的，而通过一个智能的接口通信，允许打印系统控制单元管理组件的打印活动的子集。例如，将文档中的专色与主要的黑色印刷合并起来的一种方法是将用于黑色元素的打印命令和数据与用于专色元素的分离。将黑色元素送到打印系统的打印引擎那里，并利用更健壮的接口（称为 Type II）将专色元素送到适当的后置处理器上。 在松散和紧耦合的环境中，预先和后置处理组件都有自己的控制单元，这些单元最终负责确保那些组件执行打印过程的子集。 集成的意思是组件作为打印系统的一部分。组件可能在物理上是结合在一起的或分离的，并且将很可能包含内嵌的控制器 —— 执行打印系统控制单元所发出的指令。例如，在一个 Infoprint 4000 全双工打印系统中，有一个单独的打印系统控制单元（物理上位于附装在第二打印引擎上的控制单元装置）和两个打印引擎（一个打印文档的正面，另一个打印文档的背面）。单个的单元（打印系统控制单元和两个打印引擎）对操作员显现为一个单个的集成复合体。 打印服务器（系统角色） 打印服务器是提供文档假脱机、文档变换（从一种格式到另一种），和打印或打印机管理（文档排队、与打印系统的文档或控制通信、打印系统资源管理、错误管理等）的系统。 打印服务器起源于作业假脱机和调度系统（如 JES）。预想最初的打印服务器是将具体的打印服务从作业输入子系统上卸下来。 操作员 操作员是负责打印系统日常运作的企业员工。一个典型的操作员监控并操作一堆打印系统，随着需要在系统间移动，执行安装和维护，或处理设备干预。 关键操作员 关键操作员是主要负责打印系统的企业员工。关键操作员比一大堆“常规的”操作员有更高的控制级别，并且有权访问受限功能（如为与特定格式或作业相关的关键打印引擎操作控制器设置参数值）。 客户工程师 客户工程师通常是针对提供打印系统的供应商的员工。客户工程师负责确保打印系统处于最优的操作环境中并且能够按照服务厂商和企业之间的服务级协议中指定的来使用。 打印管理员 打印管理员负责企业中打印的业务和技术管理方面。打印管理员将追踪并审阅打印规格，包括用品的使用、操作员效率、每页的成本等等。 很明显地，打印系统的主要用例是处理并打印文档。这将是提供企业价值的主要服务。有许多其他的关键用例值得考虑，部分基于上面所描述的内容。首先必须要准备环境并且执行打印系统的安装，这是使用任何产品化的系统的前期工作。 根据高可用性需求，我们需要一个描述系统维护的用例。还有其他实际操作的方面要考虑，如启动或关闭系统，配置及重新配置系统、执行安装（例如处理需要不同媒介的文档）、响应系统事件（尤其是那些要求操作员进行一些操作，将打印系统返回到可操作状态）等。 我们将立刻首次浏览一下系统级用例，同时要知道，用例清单可能稍微精简了，因为决定将一些用例作为其他用例的备选流程，不要真的拘泥于它们自己。在开始之前，让我们来展开系统的范围，用以更好地了解环境。 扩展的系统范围 在真实世界中，这是常有的事，必须要考虑接近的事件和条件，或者已定义的系统边界，因为它们帮助理解系统，并为了确保系统设计的健壮而提供基础（最少，在可扩展性和可伸缩性方面）。这里举出两个实例： 很明显的，我们的打印系统必须处理文档。我么已经表明，打印服务器是负责选择要处理的文档和管理打印系统的。而首先，这些文档来自于什么地方？而如何格式化数据，以便系统中的打印服务器或打印系统能够成功地处理这些数据？我们怎能保证可以引入新的打印功能（可能需要对应用程序和打印机数据流进行体系结构的变更）并且企业能够利用这些功能（需要修改打印应用程序）？ 我们了解打印活动本身不向企业提供重要价值。当恰当地完成了文档，为了分布而绑定，并传送给预期的文档用户（例如，公用事业客户）时，才体现出价值。 如果我们为公用事业客户设想一个典型的邮件，我们可以推断，原始的文档（可能将数千张单个的公用事业票据作为单一集合处理）必须要打印，由客户分割为单个的票据，加入规章和销售材料，扎入信封中或其他包中，盖上邮戳（也许按 ZIP 编码排序，以获得有利的邮费比率），并等着分发。因此公用事业企业，虽然对跟踪文档感兴趣，但在它们经过刚描述的各种阶段时对跟踪个别的邮件更感兴趣。 虽然这些很好地扩展了打印，但是企业一定会参与业务过程及打印/邮政室操作的整个系统集成。 知道了这些内容后，让我们列出从打印系统的环境中去掉的一步的重要系统单元： 系统 打印应用程序（打印服务器的系统角色） 打印应用程序是一个负责创建符合打印服务器和/或打印系统处理格式的文档的软件。 典型的格式（打印数据流）是 IBM 的 MO：DCA-P、Adobe 的 Postscript，和 HP 的 PCL。文档包含数据和格式编排，以及隐式的（被调用的）或显示的（包含在输出文档中）打印系统资源。 打印应用程序总是打印服务器的角色，但是是从示例打印系统模型的角色中去掉的一步，因为这里例举的打印系统不接受直接由打印应用程序（最初的假设）而来的打印作业。 最终用户 最终用户是拥有需要打印的材料的企业员工。他们从个人工作站或终端（依附到某种类型的主机上）提交打印作业。该提交内容可以是直接的（文档已经是打印系统可以接受的格式）或间接的（文档不是最终格式，而是以文档格式化应用程序所需的某种中间格式存在的）。 在第一种情况下，最终用户可以直接把文档提交给打印服务器（通过网络连接）。 在第二种情况下，最终用户利用打印应用程序来格式化（然后发送）文档到打印服务器中。 示例打印系统模型中没有显示最终用户，因为正在讨论的打印系统需要一个 IPDS 打印服务器来管理打印作业（另一个初始的约束）。换句话说，最终用户是从打印系统中（它们是打印服务器的角色，向打印服务器发送文档和打印请求）去掉的一步。 确定了系统范围和角色，并且调查了系统的精确环境之外的重要单元之后，我们现在着重于识别并突出完整的用例（已知到目前为止所收集的信息）。 简要的系统用例描述 注意： 以下内容是打印系统的系统用例的简要描述。随着对用例流程的了解和对备用流程的描述（在许多情况下，要处理潜在的错误情况），这些描述渐渐详细了。我们将更详细地描述启动和文档打印用例，将此作为阐述联合实现技术的基础。 安装打印系统：IBM 客户工程师将打开打印系统部件的包装，组合打印系统，并运行内部测试。当内部测试完成时，将打印系统转到客户那里做最终配置。 诊断打印系统：响应客户的调用请求，并执行诊断，查出问题。根据错误条件，可能在线（连接到打印服务器上的打印系统）或脱机（从网络和可能的打印服务器上隔离的打印系统）执行诊断。 诊断需要确定操作的后继过程，这将导致打印系统回到操作状态。 修理打印系统：执行维护操作，将打印系统返回到正常的（并且有希望最佳的！）运行状态。该维护可以是预防性的（根据系统使用计数器安排的操作，和为预防不定期的停机而设计的操作）或反应性的（响应客户服务请求）。在后一种情况下，这里的维护操作是逻辑的继续的诊断活动。 在某些情况下，诊断之后立即修复（例如，打印引擎单元的物理调整）。在其他情况下，在诊断之后的时间进行修复（例如，当需要修复时，必须从非现场的来源获得错误条件）。 配置打印系统：配置打印系统（包括所有附属的预先和后置处理设备）。配置包括规定打印服务器的打印系统附件，为特定格式或打印作业设定打印引擎参数，并且规定各种操作员能够执行的服务是什么。在打印系统安装之后完成最初的配置 —— 通常由客户工程师和关键操作员共同执行。 启动打印系统：此用例描述了与启动系统有关的事件 —— 从硬停机或软停机启动。硬停机意思是整个系统都已经断电（打印系统控制单元和所有打印引擎）。从硬停机启动的过程比软停机（见下面描述）涉及的更广，因为必须启动并初始化打印系统控制单元和所有受管理的打印引擎。 软停机意思是打印系统控制单元停机，但打印引擎仍旧有电，并且可用。存在两种软停机状态： 注意： 上面的用例描述实际地讲述了示例打印系统的预期的物理组件（局部性）。这在实践中出现很正常。本实例中的系统设计人员或集成人员实际上没有设计或制造打印引擎：这些是由打印机原始设备制造商那里获得的。所以初始的系统体系结构决策成为先决条件。我们之后将看到，随着用例的发展，该初始规范将导致更深一层的设计决策。 打印文档：这是主要的打印系统用例 —— 打印文档所涉及的活动。在 IBM 中层和高端 IPDS 打印环境中，打印服务器，与打印系统协作，管理文档假脱机、打印，和并发的后置打印操作。 设置打印系统：设置打印系统包括加载纸张（或者切纸式打印系统输入箱中的多种规格）、启动适当的打印系统装备（由打印服务器请求），并确保恰当地加载纸张，进行正确的打印。一旦设置完成了，操作员将打印系统设为就绪（让打印服务器得知打印系统可以进行工作）。 这个过程可以同步（作为“正常的”流程的一部分）或异步完成（并行进行的正常流程）。 重新配置打印系统：一些（不是全部）打印系统有多样的物理配置（例如，一台由两个连续纸打印引擎组成的全双工打印系统有高达四种不同的配置：全双工、双向单工、引擎一，及引擎二）。 还可以利用各种预处理和后处理设备，以不同的组合及排列构成系统。 所以重新配置打印系统的用例涵盖了操作员所执行的，将一种物理配置切换到另一种的活动。其涉及了变更打印系统控制单元中的配置设置。一些是良性的，可以在不需要对打印系统控制单元组件进行主要的配置变更的情况下完成。其他的是非常棘手的（如将全双工重新配置成双向单工），必须将打印系统控制单元停机，并重新启动，用以支持重新配置。 停止打印系统：该用例描述了与关闭打印系统有关的事件。存在两种主要的停机顺序：停机和重启。 在停机的情况下，存在多样的场景： 完全停止打印系统控制单元和所有打印引擎 可能还有可选的顺序，停止一个或多个打印引擎，和/或预先/后置处理器，并且/或者启动一个或多个打印引擎，和/或预先/后置处理器。 审核打印系统：打印系统的审核涉及到有规则地收集来自打印系统的统计数据。 打印管理员而后将执行数据简化及分析，用以确定打印系统对企业的价值量度。 提交文档：打印作业的提交对打印系统的实际操作来说是异步的活动。对打印系统来说，为了执行丰富的工作，打印服务器上必须处理打印作业。 操作员（连同关键操作员或客户工程师）、打印管理员，和企业最终用户都可以提交打印作业，要么向打印系统的广义集合（例如，使用打印类）提交，要么向具体的目的地（向打印系统池中的唯一确定的打印系统提交打印作业）提交。 示例打印系统的系统级用例视图如图 1 所示。 图 1：初始的系统级用例图 大部分用例都分配给打印系统的操作员，他负责打印系统的日常运转。最重要的是打印文档。毕竟，这是打印系统向企业提供价值的方式，它产生出企业的内部和外部客户要使用的文档。 环境级视图 就打印系统和实现其使命（将电子数据变换成充分组合且可靠的物理文档）所需要的高级服务的内容而言，我们已经简要地介绍了足够的细节，到现在要清晰地说明逻辑和物理环境模型视图。 不指定详细的需求，让我们快速略述一下（不以特定的顺序）上面确定的交互（协作）、接口，和工件（资源、消息等）： 打印服务器和打印系统显然是截然不同的两个物理实体。它们之间一定存在有接口，使它们之间流动消息、命令和数据。 环境级逻辑图
上面显示了逻辑环境中的打印系统。 两个主要的角色是操作员（普遍化为关键操作员和客户工程师）和打印服务器。 打印服务器为打印系统提供电子管理，包括分配打印系统所要处理的工作。 操作员提供打印系统的物理管理，经常使用打印服务器上的界面来安排工作。 在系统级用例图中首次确定了打印系统及其角色。在此环境视图中，我么第一次看到打印系统及其角色之间传输的主要 I/O 实体。 I/O 实体 系统状态 —— 在打印系统和操作员/客户工程师/关键操作员之间 系统状态（最小化）显示在操作员控制台上。也许还有与打印系统的物理单元相关的附加显示器和控制台。例如，除了连续纸全双工打印系统上的操作员控制台，打印引擎（临近打印引擎纸张加载的地方）前面和打印引擎侧面（打印引擎出纸的地方）会有最小化的操作员显示器。 系统状态分为以下几类： 初始化（在软启动或硬启动之后） 系统状态也可能包含供应层信息，热滚温度，和其他打印系统的环境参数。 配置设置 —— 在打印系统和关键操作员/客户工程师之间 有很多客户工程师可用的配置设置（在较小的程度，关键操作员和操作员）。最初的配置设置在打印系统安装后立即做好了。出于以下几个主要的原因，在安装之后可能会出现变更： 硬件配置变更了（例如，添加了新功能）。 控制消息 —— 在打印服务器和打印系统之间 控制消息（命令和查询） 发送控制消息，初始化打印服务器和打印系统间的通信，为打印当前准备处理的文档队列中第一个文档建立适当的环境，跟踪打印过程的状态，管理错误恢复，再同步打印系统和打印服务器，并管理打印系统中的资源和数据。 一些控制消息要求同步且立即的响应，而其他的允许异步响应（或者根本不响应）。 打印资源 —— 在打印服务器和打印系统之间 两种 MO:DCA-P 打印资源（页面定义和格式定义）不是以原始的形式发送到打印系统的，但由打印服务器使用，辅助创建最终形式的数据块和格式化指令。 数据块 —— 在打印服务器和打印系统之间 数据块由实际的文档数据，以及在表格中安置数据并分配属性（如字体大小和颜色及打印方向）所必需的格式化命令组成的。 在 IBM AFP 领域里，应用程序数据和打印系统数据间有一个重要的差别。前者是独立于打印系统和打印服务器的（MO:DCA-P），而后者是具体到打印系统的（IPDS）。打印服务器负责将独立于打印系统的数据转变为具体到打印系统的格式。 打印系统响应和返回代码 —— 在打印系统和打印服务器之间 打印系统同步或异步地将打印系统响应和返回代码发送到打印服务器上。 它们还受请求（打印服务器发送一个请求立即响应的消息）或自发地（例如，当打印系统遇到错误或某类干预请求）发送。 返回代码通常导致打印服务器的某类响应。例如，如果打印系统完成了打印并“堆积”有错误信息的文档（换句话说，将文档移动到可靠的检索位置），打印服务器会开始一个过程，将文档从活动队列中去除，然而要么从存储区清除已完成的文档，要么将其标记为完成，并将其保留已知的一段时间（由系统或最终用户定义）。 举第二个实例，打印系统对关于文档资源的打印服务器查询的消极响应会导致打印服务器搜索缺少的资源，以及向打印系统的后继的传输。 打印系统日志 基本上有两类打印系统日志对打印管理员是可用的。第一种是打印服务器（在与打印系统通信中）创建的审核日志。第二种是利用 SNMP（基于 TCP/IP 的网络管理协议）直接从打印系统中析取出来的日志（或更恰当地称为，数据）。 打印系统收集打印系统统计数据，并将其存储在符合行业标准的打印机管理信息中心内（MIBs）。打印管理员能够利用查询程序检索来自打印系统的打印机
MIB 信息，并运行统计程序来分析数据。 文档：文档是打印系统的主要操作单元。文档包含内容（最小程度）和格式控制（与内容相关的属性 —— 例如，字体类型、大小，或颜色，及内容定位值）。 文档还可能包含隐式或显示的打印资源。显示的资源完全包含于文档本身中，而隐式的资源在使用时才调用，用以满足格式化命令。 隐式资源可以由打印服务器或打印系统贮存。一个单一的资源存在于文档中、打印服务器上，及打印系统中是可能的。
图 3：环境级物理视图 今天实现了许多物理打印系统配置。 当决定所期望的物理配置时，通常做出有意识的决定，这些决定经常响应许多对稳定的和行为的需求的竞争。 在 IBM 中层到高端打印系统环境中，物理配置显示在此视图中。 在环境级，打印系统作为一个连贯的整体。随着我们开始深入地挖掘，我们需要在系统分隔方面做更进一步的决策。 支持系统 打印服务器主机（一个或多个） —— 物理上代表打印服务器角色 打印服务器主机是打印服务器软件寄存的物理单元。多个打印服务器可以存在一个主机上，而典型地，打印服务器和打印服务器主机之间存在一对一的关系。 在某些情况下，从技术上看，实际上将打印服务器贮存在打印系统（在打印系统控制单元硬件上）上是可能的。这里进行的体系结构推导假设打印服务器主机物理上与打印系统分离。这是一般行业用法中的标准体系结构实现（尽管许多 Xerox 高端切纸式打印系统实现将打印服务器嵌入到打印系统中）。打印应用程序一般存储在最终用户工作站上（当今创建文档最普遍的方法）。因而，应用程序主机和打印服务器主机之间存在多对一或多对多的关系是很正常的。 对于中型到大型企业，在一台单一的主机上创建并管理打印相当多的文档也是正常的。这是拥有大型 IBM 主机（mainframe）和中程系统（iSeries 和 zSeries）的企业的情况。对于这些以数据中心为中心的打印操作，典型的打印系统会有单个的主机存储打印应用程序和打印服务器。打印服务器可能会管理若干打印系统。 随着处理技术的发展和改善，打印服务器已经从大型主机和中程系统迁移到工作站和一般用途的 PC 上了。在许多异类的客户环境中，这导致了多个打印服务器管理着一对多的打印系统。 打印应用程序主机（零个或更多，因为打印服务器主机也可以作为打印应用程序主机） 应用程序主机是承载打印应用程序运行的物理单元。它们实际上是从打印系统环境中去掉的一步，因为在此处的体系结构实现中，我们集中于需要打印服务器的打印系统（换句话说，不能将打印应用程序生成的文档直接发送到打印系统）。 在这种情况下，应用程序主机和打印系统之间不存在直接的联系，因为打印服务器将所有文档假脱机（排列）并进行管理。很明显这是一个实现选择，因为逻辑打印服务器的确能够集成到打印服务器本身中（这是对于低端到中程个人及部门打印系统的情况）。
在一些系统中，打印应用程序将文档通过某类型的网络传输器（PC 串口、PC 并口、PC USB，或网络 TCP/IP）进行发送，在打印系统中排队，并处理。 打印系统实例需求 我们的需求是根据广泛接受的对拥有 NGCU（下一代控制单元）打印系统控制单元的连续纸、全双工单色打印系统的需求而来的。 功能需求 基础需求： 支持平台 最小的打印系统控制单元配置 打印系统控制单元微指令应封装在一个 RS/6000 Model 75 或更高的系统中，2 GB 主存、4.5 GHz 的 Power5 处理器，2200 GB 200 MB/sec SCSI 驱动，及二维的千兆位以太网附件。最小的操作系统是 AIX 5.2。 可用性 纸张自动加载 当最开始加载的时候，打印系统应向操作员提供机械的且可视化的辅助。新培训的操作员应能够通过引擎加载格式，并在五分钟或更少时间内将打印系统转入“就绪”状态。 可访问性 操作员命令输入 打印系统应通过触摸屏和（任选的）键盘和鼠标向操作员提供命令入口。如果时间允许，语音命令是非常令人想要的特性。 需要操作员干预的警报 对于必需干预的情况，打印系统应提供听觉和视觉上的警报。 性能 打印系统应支持额定打印速度，单工打印模式至少每分钟 550 2-up 8.5 乘 11 英寸的印刷品，双向单工或双工操作模式至少每分钟 1,100 2-up 8.5 乘 11 英寸的印刷品。（注意：用在本打印系统中的 Lightspeed 家族系列的打印引擎以每秒 53 英寸<每分钟 260 英尺>的速度让纸张从系统中通过，这将双向单工或双工模式转化为 1,135 2-up 8.5 乘 11 英寸的印刷品。） 遗留标准的性能 打印系统应能够运行整套遗留标准应用程序，至少比 Lightspeed 300D（高达额定打印速度）快 10％。 软件复用及组件化 打印系统控制单元微指令 打印系统控制单元微指令是基于用于 Lightspeed 派生产品的 NGCU 微指令 7.3 版。现在需要对新的 FS50
压缩图像格式提供支持。 我们还没有例举由深入的用例分析而产生的关键工件集和用顺序表示的工作流以及任选的活动图。当用文字编制用例时，我们同时在开发中的系统模型中将文字转换为图形表示。 实际上这样做满足了许多目标。在建立序列图时，确定了服务、交互和消息。这些从模型中获取并反映到系统单元上。执行用例并确定所需的通信、协作和实现预期结果所需的服务的过程是持续的系统测试形式。 此时，我们不谈及代码验证，而是重复的建模决策验证。随着系统不断的成型，很可能我们会发现未预料到的需求、可复用的单元，及要求系统重新分配的，在模型中可能出现的不足。 该工作给系统工程的六条规则中增加了两条，即规范要在体系结构间上下流动并且 and 在生命周期中减少风险并增加价值。 有一组实例将帮助您说明该过程和结果的工件。让我们依次考虑启动和打印文档系统用例。 启动打印系统 以下是更详细的启动打印系统用例的文字描述： 先决条件 打印系统（打印系统控制单元和/或打印引擎）处于停机状态。 特殊的需求 TBD 基本流程 {打开打印系统} {初始化完成} {已确认的操作员} {处于运作就绪状态的打印系统} 启动失败（打印引擎或打印系统控制单元上没有出现电力指示器） 打印系统处于已经启动，准备接收命令（来自操作员或打印服务器）的状态。
关于以上序列图的一些注意： 实箭头代表打印系统执行的服务（UML 中的操作），作为系统级启动用例的一部分。当我们转移到下一个系统模型层时，我们将说明下一层系统模型单元（在这种情况下，是逻辑子系统和物理位置）必须如何协作，用以满足刚刚确定的系统级服务（那时，我们将确定子系统级服务）。我们将通过必要多的系统层次循环继续此过程，用以足够清晰地描述系统单元和服务，简化将模型的抽象单元从逻辑上和物理上分隔成设计和实现级硬件、软件、固件和员工单元的工作。 让我们转到下面的打印文档系统用来上来： 先决条件 打印系统（打印系统控制单元和/或打印引擎）已经启动并处于就绪状态。打印系统当前没连接到打印服务器上。打印服务器上至少有一个排队的打印文档。 {启用打印系统} 打印服务器进行检查，看看打印系统是否连接上并能够通信。 打印系统进行检查，确保其处于“可以开始 IPDS 会话”的状态。 打印系统确实响应打印服务器。 打印服务器查询打印系统，用例了解其功能。 打印系统将其功能和配置返回给打印服务器。 打印服务器存储打印系统所提供的在打印文档的选择和对操作员的状态响应中使用的响应。 打印服务器向操作员报告打印系统可用并且工作就绪。 {启用的打印系统} {选择打印文档} 操作员在打印服务器上将一个或多个打印文档标记为准备处理。 打印服务器扫描排队的文档，核查是否有等待处理的，匹配当前的打印系统设置和其他确定的选择标准的文档。 当找到了适当的文档时，打印服务器更新打印系统状态信息，指示所选择的文档正在处理。 {初始化打印文档环境} 打印服务器向打印系统发送打印文档初始化信息，包括打印文档级打印系统资源。 打印系统向操作员指示正在接收数据，并执行打印文档初始化。 当接收并处理数据时，打印系统不时地向打印服务器发送对打印服务器请求的响应，以指示状态及数据被适当的接收。 {打印文档初始化完成} {传送打印文档} 打印服务器向打印系统发送页面级文档数据、资源，和命令。 打印系统处理页面级文档数据并且数字化地将数据印刷到物理媒介上（在此情况下用连续的纸张）。 打印系统按请求的间隔向打印服务器发送状态。状态包括侧面物理上位于打印系统的什么位置。此信息用于验证，文档什么时候堆积，且可靠的。它还用于确定如何在打印过程中从故障中恢复并重新返回打印系统。（注释： 在 Lightspeed 系列的打印系统中，印刷在侧面完成，这可能包含来自打印文档的高达八张逻辑页。） 当物理打印正在进行时，打印系统向操作员指示正在打印。 当物理打印正在进行时，打印服务器还向操作员指示打印状态（处理的页面）。 一旦所有的数据在打印系统上处理并印刷了，打印系统执行必要的清理（例如，确保其他文档不能访问到可靠的打印资源）。 打印系统向打印服务器指示完成了文档的处理和打印。 打印服务器更新文档状态，指示处理完成了。现在打印服务器上开始进行所有确定的后置打印服务（我们在此处不进行描述）。 打印系统返回就绪状态并向操作员指示。 {打印文档处理完成} 用例完成。 打印服务器不能与打印系统通信。 打印文档已经数字化地印刷到打印系统上，且打印系统返回到就绪状态。 图 5 中的序列图显示打印文档用例基本流程。
如我们对启动系统用例基本流程所提出的注意事项，在用例文档中揭示出通信、协作，和服务，并且从示例打印系统模型的序列图中获得这些内容。 有两点值得提到的额外内容： 为了整体的明确性，常常有必要分析那些由已知用例描述的满足相关风险承担者需求所要求的角色之间的交互。在打印文档用例中，我们看到操作员必须与打印服务器交互，为了建立适当的环境，用以简化与打印系统的具体的交互。在这种情况下，发现打印服务器必须执行的，准备与打印服务器交互的服务。 虽然我们不关注这些服务，和这些服务最终在打印服务器中的子系统上实现的需求，但是这些服务明显应为我们的用例而存在，用以实现计划的结果。如果我们上到打印系统之上的一层，并且改为关注打印室，在此处打印服务器和打印系统是截然不同的打印室单元，我们绝对会对获取打印服务器和打印系统所执行的服务感兴趣。 换句话说，我们推荐的方法不论是对于在考虑中的系统的大小或意识到的环境都能使用。对打印室、打印系统、打印引擎，或打印引擎的一个组件，都可以进行相同的结构分解。 对系统体系结构的价值和具体化存在重大的争论。有些方法提倡“抛弃模型”，例如，在餐巾背面绘出的体系结构模型，用于鼓励讨论并建立导致立刻进行系统构建的高级指导方针，然后废除。 虽然此方法对非常简单的系统（其体系结构模型中可能只包含若干子系统）可能足够了，但是当引入重大的复杂性时（数千个需求、系统中的系统，数百个非功能需求，或在硬件、软件、固件和员工划分上非常灵活的系统），该方法肯定不行。 如我们之前所看到的，在我们的建模工具中很容易向模型中加入相关的系统属性。在描述启动和打印文档系统用例的基本流程的过程中，我们确定出许多系统级服务，一些是打印系统必须提供的，其他是打印服务器必须执行的。确定这些服务的举动将为模型增加清晰度和信息。 图 6 提供了打印系统模型的另一个环境级逻辑视图，用以观察通过序列图获取的额外信息。 图 6：随着系统额外方面的模型化，在各种视图中可以获得更详细的信息。 在本文的第二部分中，我们例举了在环境级推导系统体系结构所涉及的主要活动。我们开始确定系统的环境，寻找系统进行交互的对象，识别潜在的通信、协作和接口。第一步建立了系统范围的边界。我们还看到系统边界以外，这帮助提供含有其他企业单元的环境中的系统的更大范围的视图。我们表明，这个扩展了的视图可以提供对影响到系统可扩展性和可伸缩性的设计考虑的有价值的洞察，而潜在地使开发团队得益于可复用的组件、共享的服务，和处于更宽的企业环境中的可能。 然后我们开始将系统功能初始划分为用例，其描述了系统执行的服务，导致为企业和/或其客户带来切实的价值。 我们更近一步，为启动和打印文档用例提供更多细节，用文字编制基本流程，而后在序列图中描述该流程。这样做揭示了系统级的服务（在建模工具中通常指“操作”），其作为结构上划分（导出系统模型分析级的子系统和位置）下一阶段的输入。 最终，我们用逻辑和物理的透视图可视化地表示环境级的打印系统。结果的视图不仅获取了打印系统、角色，和系统级交互，还获取了系统用例序列图中揭示的系统属性和扩展的系统服务（操作）。 这些活动试图通过以不同的（但有价值的）观点分析系统，来澄清固有系统的复杂性。在真实世界中，联合的硬件/软件和单纯的软件系统都需要来自另外的透视图（如信息透视图，在此生成了数据模型）的分析。 此时，系统仍旧是一个黑盒子，但是我们已经收集了关于系统、环境，及其服务的相当多的信息。 我们看到，随着对系统级用例分析的进行，包含于环境级逻辑和物理视图中的系统单元反映出重要的决策（确定系统需要执行的服务，或者包含于分散的 I/O 实体中的数据要素）。我们下一步将可以对打印系统进行白盒分析（用以识别候选逻辑子系统和物理位置）。我们将在即将出版的 Rational Edge 中的本文的最后，第三部分中继续分析。 注释 1 在本文中“面向行式”指打印应用程序将数据格式化、传送到打印系统，并最终由打印系统处理的方式。每个行记录包含要打印的字符的 EBCDIC 或 ASCII 编码表示，并带有指示纸张上的行布局（行间距、跳行，跳到新一页）的可选控制。当时的打印系统包括一个打印单元（序列、链，或带），打印出单一字体、样式、大小，和深浅度的完整格式的字符。这种物理约束限制打印系统只能生成文字的文档（没有徽标、图像、图形，甚至在一个文档中不能超过一种字体）。 2 打印数据流是文档内容的电子表述。它是由运行在主机、工作站，或个人计算机上的打印应用程序生成的，并通过某种数据连接传输到打印系统中进行处理。如上面所提到的，当时的打印系统受限于面向行式的打印，还作为 3270 行式数据。现今使用的普通打印数据流包括 Adobe PostScript、Hewlett-Packard PCL，和 IBM 的 MO:DCA-P（通常为 AFPDS）。 参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文。 |
