用户用来与内容管理系统交互的应用程序集是系统最外围的可见部分。虽然几乎全部的系统功能都是由后端组件提供的，但是正是这一部分应用程序集才使得用户可以对系统进行访问。因此，内容管理系统提供的应用程序集能最大限度地支持用户的需求以及与内容管理相关的工作流程，这一点是非常重要的。构建一套全面综合的用户应用程序集需要仔细考虑所有不同的过程和步骤。
理想的用户应用程序是为了跟目标用户组进行密切协作而开发的。它们将提供功能需求和操作需求方面的重要数据输入，而这些需求应该引导应用程序的设计。用户的输入也包括例如人机工程学应用这种因专注于技术问题而被轻易忽略的方面。理论上的需求研究不足以使我们能够完全获知用户的实际需求，目前仍停留在非常抽象的阶段，不能为我们提供任何实际可见的系统经验。因此，为了了解用户，我们应该采取一种可以用来提取用户需求的方法，即产生各种不同的原型。最初的原型是通过对当前工作流及用于具体工作环境的工具的研究而产生。
本章中所列的应用程序都是经过这种方法考虑并开发出来的，它们是大量的研究和主要媒体制作及传播公司商业项目运作的结果。然而，这些研究与合作所得到的一个重要的结论是：灵活性和可配置性是关键成功因素。几乎所有组织单元都会有非常专门的需求，例如应用程序的布局格式、操作，甚至部分地考虑到功能。除了考虑用户需求，也要考虑整体的基础设施。许多系统被整合起来，内容管理应用系统可能成为别的系统的一部分。因此，不仅要能单独提供一个基本应用程序集，还要能根据用户和整体系统需求提供一个能够整合和灵活配置的应用程序模块的可选集，这一点是至关重要的。基于组件的方法可以理想地满足这些需求。这样的应用程序组件示例将在本章讨论。
但是仅仅讨论应用程序控件太过抽象，不能够为第2章所讨论的应用程序捕获工作流提供足够的细节。因此，本章还将介绍支持具体工作流的应用程序示例。这些示例一般是从应用于广播和媒体生产环境的应用程序示例中派生出来的。大量不同的工作流，范围从深度存档、新闻加工到检索，都被考虑到了。其他的应用程序领域可能针对不同的客户而有所改变，但是基本的功能都是相同的。在这样的环境下如何配置应用程序模块集合，取决于基于一个接一个项目评估所获得的专门需求。
9.1应用程序设计原则
应用程序的设计和开发这些年一直在不断变化。过去一个系统只有一个用户界面，通过此界面用户与该系统进行交互，实现该系统的功能，其接口与系统功能部分是缠绕在一起的，整个系统的结构就是为了这些功能的应用。在过去的10年中，这种情况发生了改变。最初，客户机-服务器系统的出现消除了用户界面与实际运行环境之间的紧密偶合。分布式系统的出现取代了单独在主机上运行的应用程序。分布式系统的发展与基于窗口的应用程序的发展一起产生了一个交互性更强，对用户更为友善的应用程序环境。下一个改变用户与应用程序交互方式的主要发展是互联网的出现，用户界面以网页浏览器的形式出现。信息交换只需通过标准的脚本语言，而不需要安装除网页浏览器以外的任何其他专门的应用程序。用户界面的外观由网页设计者决定。网页应用程序越来越成熟和完善，目前已经能够支持可以在浏览器环境下运行的可下载应用组件。许多用户都已习惯于这种在网页环境下运行的交互方式。
在内容管理系统的设计过程中，我们必须考虑这些发展。另外，还有一些方面，如与实际用户需求同样重要的技术和功能需求。然而，对于怎样设计和实现应用程序没有什么一成不变的蓝图。但我们需要建立某些原则，这些原则有利于设计应用程序并将应用程序与系统或其他系统组件进行整合。
9.1.1应用程序和用户需求
一直以来，推动应用程序设计和界面发展的2个主要因素是：（1）为实现新的应用程序和交互模式而服务的技术；（2）应用程序要实现的用户需求。还有第3个因素，那就是用户、技术支持和维护，这在大规模应用环境的情况下非常重要。对于一个内容管理系统来说，能够轻松安装、配置和更新应用程序是很重要的。大量潜在的拥有不同角色和权限的用户，他们对内容有不同的认识，考虑到这些方面，内容管理系统必须能够支持个人应用需求。
与其他应用程序组件之间的互用性和整合性也是十分重要的因素，也就是说，在其他应用环境下这些组件也应该能够运行。内容管理系统要能够提供这样的一个宿主环境。为了使这些组件与用户整合后仍具有透明性，内容管理系统的外观应较容易适应各种不同的应用程序布局格式。
在设计应用程序界面的过程中，应考虑用户的需求。这些需求涵盖了所有的操作特性，包括功能方面和非功能方面的特性。工作流分析是一种建立需求的方法。进一步说，在应用和人机工程方面的操作处理是必须建立的一种系统设计参数。能准确获取这些需求，以确保用户能够在一个稳定、持续的基础上高效地操作系统并与系统交互是至关重要的。
就开发应用而言，这些不同的需求可以按照它们的来源和如何确定来进行区分：
·功能需求针对应用程序的特征和特征集合。它们主要是通过考察现有的或潜在的工作流而得到的。功能需求只是用来说明某个特定的应用组件所提供的功能类型，但并不规定如何展示这些功能类型。
·操作需求描述了应用程序的操作和使用。相对于功能需求，操作需求所处理的是应用程序运行中的一些动态需求。操作需求可被进一步分成：
（1）用户-应用程序交互描述了发生于用户和应用程序之间的实际交互。这其中包括在不同的应用环境下完成一个具体任务所涉及的各种不同的动作和步骤，其目的是尽可能高效地实现某个目标。在这种情形下，就要考虑到人机工程学了。
（2）应用程序的支持和维护涵盖关于在大规模多媒体内容组织中对应用程序进行安装、支持、更新和维护的所有需求。
·系统需求从应用程序存在的系统环境中得到。包括用来控制特定系统组件的具体（系统和用户）界面的定义。进一步说，源于某个具体的系统配置的应用程序之上的所有需求都是系统需求的一部分。这也包括与现有系统的整合及与第三方系统的整合。
尽管在产品整个生命周期内，核心功能需求集的进一步发展相对稳定、持续，但组织与组织间的操作需求却不尽相同，有时甚至在同一个组织的不同部门之间的需求也有所不同。因此应用组件可以使基于个人用户需求的应用配置简捷方便。
用户方代表应该从最初的设计过程阶段就参与进来并一直跟随工作，这包括初始应用程序设计，还有更为重要的是项目中的应用程序引入和配置。
总的说来，应用程序应该构筑于灵活的、可配置的组件之上，这些组件适用于项目实施阶段。应用程序的配置允许按照使用限制和用户需求来定制应用。在应用组件的设计过程中要考虑到功能和操作的需求。
9.1.1.1访问权限和用户角色
在内容管理系统这样的大规模分布式系统中，访问权限具有特殊的作用，它限制了特殊用户或用户组的读取、检索以及更改信息的种类和数量。访问权限不是一个二选一的概念（例如一个用户要么可以访问应用程序和数据条目，要么不可以），而是可以详细地规定哪些内容对象可以由谁访问，访问者被授予了何种访问权限（读、写或二者都授权）。与内容对象交互的类型和形式也是由访问权限决定的，例如某个用户或许获准访问某一内容对象的预览版，但是这个权限不足以使他访问该内容对象的详细资料。不仅可以对单个用户分配权限，还可以将权限分配给用户所属的组。在一家新闻工作室内，某个办公室的所有成员都被赋予权限可观看某个系列节目的原始资料，但是其他办公室的成员则无此权限。因此对于每一个内容对象，单个用户的访问权限和用户组的访问权限都要考虑到。访问控制列表（ACL）就是控制访问数据和资源的传统方式。在内容管理系统的应用环境中，访问控制列表能够得到扩展并且以一种灵活的方式来表述系统中不同成员的权限。
用户在组织中的角色不仅决定其访问权限而且决定其应用环境的配置，例如记者或编辑的应用环境不同于编目员的应用环境。通常情况下，应用程序是安装在确定的机器上的，但是将来大多数应用程序和它们的具体设置应该能够被同一组织中的任何一台计算机访问到，除非该应用程序需要特殊的硬件和装置支持。
因此，权限与用户在组织中的角色有关。用户的角色和权限取决于其信息访问和应用的环境。用户登录文件可用于指定在一个应用环境下的用户角色和权限。在这样的一个用户登录文件中，所有关于用户的相关信息都以计算机可处理的形式保存。用户登录文件中的数据控制着应用表现和信息访问。
扮演多重角色（例如管理员和编目员）的用户需要给予特殊对待。在这种情况下，就要决定用户应该以哪一种具体的角色登录，权限和应用环境应该与不同用户的登录文件相对应。
9.1.2基于组件的应用程序设计
运用模块方式，我们所需要的灵活性和整合性可以达到最佳效果。在这样的系统中，每一个模块都代表着一个具体的功能。在一个应用框架中，模块整合能够构建一种应用。模块的大小和功能是由模块所支持的任务及该模块上所建立的某些第三方组件决定的，例如模块可以是一个VCR控件，用于对视音频的回放进行控制。这样的模块可以用于所有需要对视音频回放进行控制的情况下。它在应用程序中的位置是由应用环境、功能和操作需求决定。但通常我们不可能去定义一个独立的VCR控件模块。例如，如果采用了将VCR控件与播放器相集成的第三方产品，那么它的布局和外观就不能够再更改了。基于组件的设计不仅允许有更好的可配置性，也支持在不同应用程序中模块的可重用性。
模块封装设计的好坏依赖于不同模块在其他应用环境下重用所采用的方法及应用程序配置的灵活程度。此外，不同的模块之间必须产生交互进而形成一个应用程序，例如像信息交换这样的交互。因此，需要在灵活性、可配置性和系统整体性能之间考虑平衡。
近年来脱离功能块或模块来建立系统的思想越来越普遍，大量的技术支持这种所谓的组件式软件的方法。
9.1.2.1内容管理系统应用程序和组件式软件
模块应用设计原理与组件思想密切相关。最初的组件思想是通过将预制的一些组件组合起来提供完整的功能来建立软件系统。在此情形下重要的是组件所具有的功能、它的行为和用来与其他组件交互的接口。组件能够提供一个或多个接口（输出接口）给其他组件，也能够使用其他组件提供的接口（所谓的输入接口）。在系统中组件所具有的不同类型接口之间的接合，定义和规定了组件间的交互和系统的功能。通过在兼容的输入和输出接口之间建立的连接，可建立一个系统（或应用程序）。连接类型通常是静态的，它在开发和整合阶段被确定，在运行期间不会改变。
然而，运用组件和基于组件的方法也不是没有问题。例如，整合过程不总是一帆风顺的，有时要经过复杂的装配工作才能创建一个操作系统。因此，如果组件不能与系统环境很好的结合，在这种情况下创建应用程序是有一定危险性的。我们必须维护庞大的库集合，而且对于集合组件整体系统的一般维护也是一个问题。为了实现组件式方法的灵活性，又避免产生出过于庞大的软件，必须严格控制每一组件的开发进程，按照整体系统的创建计划来执行开发。因此，相对于传统的开发方式，在这些组件的开发过程中，按照用户需求来创建的合适的应用程序所具有的灵活性，或许需要进行更为严格的控制。
许多开发工具和基础设施支持组件式软件的开发方式（比如OCX控件和Java类）。支持模块化应用程序开发的技术有CORBA、ActiveX或JavaBeans。4.5所讨论的那些协议（如SOAP和MOS）也可被用于支持基于组件的应用程序开发。利用Web技术或Web服务来进行可重用模块的创建是一种非常好的方式，如HTML或动态HTML。以这种方式创建的模块集成在应用程序和网页中，无需在客户端进行任何安装。
