【IT168 技术文章】

　　ClearQuest MultiSite 主控权的功能就是确保一个 ClearQuest 记录只能够同一时间在一个数据库镜像站点更新。一个登陆到站点的用户如果没有记录的主控权，只能查看记录信息，而不能够对它进行修改。要想进行记录更新，用户必须登陆到拥有主控权的站点。

　　考虑这样一个场景，客户在伦敦，支持代表在班加罗尔，开发人员在罗利，测试人员在北京。如果这个变更请求的确认发生在北京，这也是一个数据库镜像的地点，这个记录所有者可能要从一个站点更换到另一个站点，比如这个记录的状况从活动变更到解决以及修正需要确认的情况。(注意：用户可以登陆到任何一个镜像中来读取信息，但是必须登陆到一个拥有主控权的镜像才能变更这个记录。)

　　乐观锁定

　　当两个人要更新同一个记录时，ClearQuest 就可以利用乐观锁定来处理这种情况。第一个保存记录更新的人——并不是第一个为了更新而打开记录的人——会成功。其它的变更就不会被保存。因此，第二个试图更新记录的人将需要重新得到这个记录并重新进行他或者她的更新。

　　我可以推荐一个减少这些麻烦的技术，因为 IBM Rational 内部也使用它，就是利用一个叫作 Record_Script_Alias 的 ClearQuest scripted Action 类型创建一个记录。这个 Action 在一个远程的或者同时正在进行更新的记录上执行。它可以创建一个新的记录并且在这个带有 Action 记录 ID 的新记录上更新一个新的字段。ClearQuest 然后创建一个从这个新的记录 ID 到这个 Action 记录的 反向引用(back-reference)，不管是否设置了主控权。这两个记录都是对方的相关扩展——直接在当前站点，接下来就镜像到其他站点。这个反向引用确保相连接的记录能够合适地更新。也就是说，当您创建一个记录并更新涉及的字段时，这个反向引用将会更新相关的记录，不管主控权还是乐观锁的争用。

　　这里还有一个更进一步的提示：当创建子记录作为创建父记录的副产品时，使用您创建的父记录的 Commit Event 来创建这个子记录。

　　所有权(Ownership)的角色

　　由于镜像的局限性，对于 ClearQuest 来说不能实时地确定记录是否在更多的站点被创建或者变更。因此，如果记录在多个站点被创建并反向引用，对于用户来说是不可能在事前知道这些情况的。您可以通过分配所有权和确定最有可能执行 Action 的人(或者唯一的人员)来进行限制。这样就缩减了与记录相关的冗余的过程，更有效地创建一个虚拟调度机制。

　　这个方法同时还简化了主控权和乐观锁争用问题的解决。就是说，您即可以象上面所描述的一样来创建一个记录然后用反向引用连接记录，也可以用所有者指派的隐含更新来构建记录。您不必同时使用两种方法。

　　基于角色的用户体验

　　为了设计、实现和管理变更管理系统，ClearQuest 产品支持基于角色的模型 。

　　为了我们的中心目的，同时也为了说明 ClearQuest 文档的目的，IBM Rational 已经确定了三个常见(实际上非常普遍)角色。大多数其它您可能确定的角色都是这三个中的具体实例：用户、管理员，以及方案开发者。

　　用户角色覆盖了所有 ClearQuest 客户端可用的任务，这些任务用来在用户数据库中重新恢复、创建或者修改数据。普通用户任务包括从一个用户数据库中获取信息和对这些记录进行操作，提交变更请求、处理变更请求、修改记录中的信息，以及运行查询。用户可能是提交客户请求的支持代表，也可能是一个开发人员，质量工程师，信息开发人员，或者提交，分配，处理，解决，以及为一个产品特定发布版本进行变更请求确认的管理者。

　　管理员的角色用来对数据库、用户，小组进行管理，同时还包括安全策略的管理。一个管理员的常见任务包括配置和维护数据库、管理用户帐号，以及设置轻量级目录访问协议(LDAP)的授权。

　　方案开发者的角色包括大多数 ClearQuest Designer 中用建立方案的功能，这些方案将定义用户在 ClearQuest 程序用户界面工作的数据库。一个被执行的常见任务包含所有的方案设计以及开发，包括开发状态转变模型、记录、字段和动作类型，以及每个记录类型、字段和动作的行为，包括钩子(hook) 和脚本，同时还为 ClearQuest 客户端的用户开发窗体。

　　在许多变更管理的实现中，可能只有少数的方案开发人员和管理员，但是却有相当多客户端程序的用户——可能有几千的用户。在 IBM Rational 内部开发小组中的确是这样的，然而只有少数方案开发人员和管理员对 RATLC 方案进行支持，并继续进行完善。事实上我们许多客户的开发团队也是这样的。

　　然而，这些角色之间的界限是模糊的。比如，同一个人经常会同时担任着管理员和方案开发者的双重角色。类似地，钩子的编写者或者窗体的设计者也可能是安全策略的设计者或者管理用户组和许可(也叫做用户权限)的管理员。在 IBM Rational 也有这样的情况，可能有些用户有管理员权限可以创建查询并将它们保存到公共文件夹中，另外他们能够管理一些数据库，或者副本，或者用户和团队。