内容


IBM Rational System Architect 工作区使用场景

怎样使用工作区

Comments
下载 Rational® Software Architect 试用版  |   在线试用 Rational® System Architect
获取免费的 Rational 软件工具包系列,下载更多的 Rational 软件试用版

开始使用工作区

这一部分讨论了工作区的基本概念,以及本文中所包含的信息。

描述

工作区的概念是在 IBM® Rational® System Architect 11.3 版本中引入的,作为使用 Rational System Architect 来支持模型发展的协作性,创造性和迭代性本质的技术。

工作区的表现和外观就像是一个正常的百科全书,除了多种工作区可以位于任意一个给定的百科全书之外。当工作区可以当做不同的条目时,高级工作区变量会随着模型内容的发展而会聚和发散。不同的工作区之间可以共享,追踪和恢复内容。

使用单独的百科全书取得相似的效果是可能的,而工作区的使用使得不同状态之间的模型发展具有追踪性,再使用性,并且管理起来更加方便。

工作区的目的是什么?

工作区会处理管理企业结构版本的需要,促进发展状态和结构变量的构建。

您可以使用工作区来再使用模型内容,执行具体的追踪性,差异(比较)内容,合并或者提取工作区之间的内容。

本文的写作目的是什么?

本文的写作目的是,向您展示一些建议的逻辑性工作流程模式,您可以在工作区的实际应用中应用这些模式。文中还涉及到了工作区潜在发生的误用方式。

文中并没有涉及到管理性的过程。如果您想要得到更多信息的话,那么您应该查看 参考资料 部分以得到补充性的指南。

工作区概况

工作区就是:

管理结构版本的方式,这样您就可以:

  • 创建并冻结结构基线作为工作区
  • 分离但仍然相关工作区版本中的工作
  • 合并或者提取工作区之间的内容
  • 追踪目标:
    • 从一个公共的源
    • 到一个下级的目标
    • 从一个公共的源在不同的工作区之间
  • 管理一个结构的版本,而不用复制整个的百科全书
  • 管理结构的版本,而不用分类外部性的百科全书

工作区的潜在性使用包括您可以使用它们来:

  • 创建沙箱版本以尝试项目中的思想,评价场景或者替代性的结构
  • 为评价,选择和开发创建结构变量场景
  • 使用 Rational System Architect Compare 功能来在工作区之间进行比较,使用比较图来识别差异
  • 代表:
    • 项目
    • 场景
    • 方案
    • 替代

工作区并不是:

  • 筛选到文件夹的方法
  • 将许多各种各样的百科全书带入到一个百科全书中的方法
  • 名字区域的方案(这就是说,它们是用作对象的名字标识符的)

工作区概念性概述

您可以按照下面的几种方式来使用工作区,管理企业结构:

  • 创建企业结构的 版本 。您可以处理已存在的信息,并进行删除,变更操作,以创建它的新版本,这样就可以直接返回至原始的结构了。
  • 创建端到端的 沙箱 ,每一个都提供了前一个结构的版本。您可以创建当前的结构,该结构可以与其他的结构相比较。

默认条件下,百科全书会被看做是一个工作区。您可以一直在 Rational System Architect 中操作,就像您从来没有打开工作区特性一样。在您打开工作区特性之后,多个工作区都可以在相同的百科全书中独立地共存。第一个工作区会被引用为

您可能要为一个工作区建立基线,因此使其在储存库中成为只读版本:此时结构的一个快照。基线通常是在重要的阶段或者结构开发的关键时期创建的。该基线化的工作区会成为多个 子 工作区 的公共基底。

然后可以为基线化的工作区创建一个或者多个 工作区,如图 1 所示。这些子工作区包含了 基线化的工作区拥有的一切内容。当您打开一个储存库(或者 Rational System Architect 中的百科全书),您要选择打开哪一个工作区。

图 1. 工作区层级结构
带有两个工作区的锁定基线
带有两个工作区的锁定基线

当您打开一个工作区时,您在工作区之中的事实对于您来说,是透明的,唯一的差异在于您可以编辑子对象,但是您不能编辑父对象。您所知道的就是您在处理结构。工作区的名字会显示在储存库的标题栏上以便引用,如图 2 所示。

图 2. 工具中显示的工作区
工作区名可见的标题
工作区名可见的标题

图 2 的大图

子工作区中的操作并不会影响到父工作区或者平级的工作区。对子工作区所作的变更会只向该工作区添加变更。如果您删除了一个子工作区,那它只会删除该工作区中所作的变更。另一方面,如果您删除了一个基线工作区,那么这将会破坏所有的子工作区,因为没有了上级工作区,那么它们的内容就没有背景了。

工作区场景

接下来的场景代表了怎样使用工作区的一些典型工作流程。它们并不是很详尽,因为可能还有其他的变量及操作性变量。

在接下来的场景之中,包含有工作区的百科全书的图形代表被忽略了,因为工作区只能位于一个百科全书之中。

版本发展

问题

在结构开发的生命周期期间,您应该怎样管理百科全书的发展版本呢?

方案

创建并维护工作区的迭代性线性发展,工作区代表了企业结构项目,方案,或者特定的场景。

随着对工作区操作操作的继续,在内容开发中您可以建立一个基线。这使得工作区变成只读模式,并创建一个子工作区。开发效果会在子工作区上继续,直到您达到另一个重大的进展为止,此时您创建了另一个子工作区,如图 3 所示。整个过程会重复,直到达到工作区的结论为止。

图 3. 工作区发展图
子 WS1 到子 WS2 的根
子 WS1 到子 WS2 的根

范例

  1. 激活工作区的百科全书,而根工作区会填充上结构模型。
  2. 在特定时刻基线根工作区。
  3. 创建一个子工作区(版本 1)并进一步地开发它。
  4. 为子工作区(版本 1)创建基线,并创建子工作区的新版本。按照这种方式来重复性地开发子工作区,创建新的基线和版本。

替换性的结构评价

Issue

您应该怎么样使用 Workspaces 来促进 Enterprise Architecture Workspace 对于项目,方案或者场景的评价呢?

方案

在这种方法中,Workspace 路径代表了替代性的项目,方案或者场景,如图 4 所示。每一个路径都正在完成当中。在这里,替代性的结构会对其适用性进行评价。您要使用 Rational System Architect 功能,例如 Explorer 图,报告,分析,协作和报告工具,以及对 Simulator III,IBM® Rational® Focal Point™ 之类的 Rational Systems Architect 相集成,来完成这一点。您选择最佳的工作区,并进一步根据需要进行开发。对其他工作区的后续处理将会暂停。您可以删除掉该工作区,但是保留它以作为评价替代性记录是最佳的实践方式。该操作还支持为什么没有选中它以进行进一步开发原因的知识。

图 4. 替代性选项图
根分支成 2 个替代性 WS
根分支成 2 个替代性 WS

范例

  1. 为工作区激活一个百科全书,那么根百科全书自然就会使用结构模型初始化。
  2. 基线根工作区。
  3. 从根工作区那里创建替代性的子工作区 1,2…n(等等)。
  4. 实现,分析并开发每一个工作区到一定的成熟度,以促进使用 Rational System Architect 功能和集成的有意义评价(如前面描述的那样)。
  5. 评价替代性的子工作区(1,2…n),并选择一个或者多个替代性的子工作区以便进一步的开发。

当前的状态结构转移以及未来的状态结构转移

问题

您应该怎样定义未来的状态结构,然后转移当前的状态结构以实现未来的状态结构呢?这里所描述的方法适用于企业结构和特定项目的结构。

方案

在这个生命周期内,有单个的工作区域,代表了当前的状态结构,并要开发成能够代表未来的状态结构。但是,因为未来的状态结构(由单独的工作区域代表)本身可能需要进行开发,当前的状态结构,在转化时,已经接近未来的状态机器了。通过决定当前状态和未来状态之间的交集,确定转变状态所需要做的变更就是可能的了,如图 5 所示。

图 5. 并发工作区进展图
当前状态和未来状态交集的合并
当前状态和未来状态交集的合并
  1. 支持工作区和基线的百科全书作为根版本。注意根工作区来自于当前的状态结构,或者工件的一般分类。这就有助于开始建模,而您可以使用它来鼓励工作的一般方式。但是这可能是不必要的。单独的团队可能同时开始工作。
  2. 从根工作区创建两个工作区域:一个是为当前状态创建的,一个是为未来状态机器创建。
  3. 您可以建模当前的状态机器和未来的状态机器,并使得人们可以使用它(例如,分别是版本“a”和“x”)。
  4. 您可以识别当前状态机器和未来状态机器之间的交集,这些差异驱动当前的状态版本“a”转化,以交付当前状态版本“b”的下一个阶段。
  5. 您的团队可能想要继续操作,并开发未来状态“b”的下一个版本,这样当前状态版本“b”和未来状态版本“y”之间的交集,就可以促使创建当前的状态版本“c”。
  6. 上面的步骤会在企业练习的过程中进行重复。

当前的状态和未来的状态会随着变更基线的需要而转变

问题

企业结构(EA)并不是软件代码。软件代码精确地反映了构建时的软件:它就是软件。但是,EA 效果就是已存在公司的集成式模型。实际上它并不是 100% 完成的。它可能甚至并不是 100% 精确的。您可能想要返回,并变更基线,因为您在后来会意识到它不能精确地反映您公司的需求。您可能想要变更具体的内容,或者只是简单地修复一个问题。

因为这一点,所以变更基线的能力就显得非常重要,对未来结构所作的变更会建立在该基线的基础之上。这并不是十分容易完成的,因为未来的结构可能按照很多种方式来改变:项目可能从未来结构的一个分支中删除掉,其他的分支则步删除。对工件的关系可能也会发生变更。例如,您没有记录到基线之中的业务进程可能在一个,或者多个,或者全部的目标结构中发生变更。所以如果您可以将其添加至基线时,您可能不想要填充目标结构。另一方面,它可能是由基线中的特定程序来服务的,但是程序可以在目标结构中发生变动(不是在另一个目标中变动)。

一个企业结构,就是一系列拥有复杂联系的工件。如果您变更了这个联系网的一部分,那么对未来结构自动推广该变更,就非常困难了,因为未来结构的联系网具有微小的差异。由于这一点,手动干预的评价,由工具自动化支持,就是必要的了。

方案

创建一个可写基线化的工作区的技术,就是创建基线的一个子工作区,Baseline V1,如图 6 所示。在一个完美的世界中,Baseline V1 从来不会变化。但是,正如上面所描述的那样,您会经常发现基线拥有需要矫正的缺陷。这种方式的结构化工作区,向您提供了一个 Baseline V1,您可以在发现它们后应用这种变更。在这里您不能编辑基线,因为它是只读的,您可以对 Baseline V1 作出变更。然后您可以向工作区建立原始的基线,再将这些变更合并到目标结构之中。

图 6. 工作区层级结构
带有基线 V1 的 Baseline
带有基线 V1 的 Baseline

范例

  1. 为工作区和基线激活一个百科全书,并将其作为根版本的基线。
  2. 创建三个子工作区:两个为未来状态结构的替代版本创建,一个为当前基线结构的可写版本创建。
  3. 开发未来状态的结构。您随后会意识到您需要对基线结构作出调整,这样它就能精确反映此时的组织了。您需要对当前基线化的结构的可写版本作出变更。
  4. 当可写基线结构更新完成时,您就可以为该工作区创建基线了,以及一个新的子类,创建可写的基线,以及两个新的未来状态子工作区。将基线项目中的选择变更合并到未来状态的子工作区,如图 7 所示。
图 7. 基线变更图
2 个基线会合并到版本化的项目工作区
2 个基线会合并到版本化的项目工作区

项目合并

问题

您应该怎样控制结构的版本,以让多种并发的开发可以在多种工作区中发生?

方案

主工作区,它反映了结构的发布版本,包含了内容的基线,基线来自和合并自并发工作区中包含的开发工作,如图 8 所示。这些基线会成为发布的结构,或者 当前的状态。Master Project Workspace 的提取拷贝可以用作大量用户使用的单独百科全书。

项目子工作区包含了您正在处理的,例如,对于处理不同项目的不同项目团队,场景,方案,或者结构的不同子部分结构。

图 8. 项目合并图
3 个项目合并为一个流程
3 个项目合并为一个流程

范例

  1. 激活工作区的百科全书,并将其基线用作根版本。
  2. 将该基线看做结构的版本,并使得公众也可以使用它。
  3. 假设您的团队现在希望移到下一个版本之中,这样您就可以从该基线中创建一些新的子工作区 1,2,..n,包括成为 Master Project Workspace 版本 1 的工作区。
  4. 项目子工作区会像沙箱区域那样使用,以支持团队处理原始性的结果,而不用影响发布的版本。
    您还可以选择,创建子工作区,并将它们完全提取到离线工作的单独百科全书之中。然后您可以合并这些离线工作区,到扩展的子类中。
  5. 您在评审和接受项目子工作区中的内容后,可以将它们部分或者全体合并到 Master Project Workspace 版本 1 中。
  6. 然后您可以基线 Master Project Workspace 版本 1,并使之成为结构的下一个版本。
  7. 重复上述的步骤,并创建 Master Project Workspace 版本 2。这种方法支持结构的稳定版本,以及版本之间的具体追踪性。

基础结构

问题

在大型的公司内,当结构性的实践方式随着时间不断成熟时,就可以识别结构性的模式了。您可以获得这些模式,并将它们用作建模私人领域的业务。模式本身也就是 结构性基础,而且您可以将其用作进一步具体建模的模板。这里面对的一项挑战就是,怎样稳定且高效地管理企业基础模型。

方案

您可以在单独的百科全书中管理基础模型。从基础模型中提取内容,并使用它来作为特定项目结构开发的基础。您可以按照自己的需要,来向基础结构引入新的版本。如果您发现了基础结构中值得加入的新模式和对象,那么您可以将其当做基础结构候选对象。

图 9. 基础结构图
合并百科全书之间的工作区
合并百科全书之间的工作区

范例

  1. 创建一个基础结构性百科全书,并激活它对工作区的支持。基线该百科全书作为根基础结构工作区版本。
  2. 将其考虑成基础结构的一个发布版本,并且使其他人也能使用它。
  3. 团队可以从基础结构中追踪选中的模式和对象内容,以将后续的项目开发效果集成到单独的百科全书之中。
  4. 开发并修改相关百科全书之内的基础结构,这些基础结构会与使用它们的项目一起运行。
  5. 基线基础结构的新版本,并传播它们以让更多的项目也可以使用它们。
  6. 对于发展之中的项目,合并它们,并根据需要,从结构性基础百科全书中使用新的对象及编辑的对象和模式。
  7. 在项目开发期间,如果您识别了基础结构中值得加入的新模式和对象,那么您可以将其看做候选对象。如果它们被接受了,那么您可以使用它们,并将它们合并到基础结构性百科全书。
  8. 按照并发处理的模式,来继续处理基础结构性百科全书和项目工作区。

工作区机制

工作区是如何发挥作用的?

为了更好地理解工作区的工作方式,您最好先了解一下开发以支持它的机制。工作区之外的百科全书包含了代表它的全部模型和数据。当您激活工作区支持,并只有一个根工作区时,工作区就会按照没有激活工作区支持功能时的那样进行操作。

您可能已经意识到了一个百科全书包含了根据 GUID 进行唯一识别的对象。这对于支持工作区的百科全书来说,也是适用的。一个工作区并没有包含其上级内容的拷贝:如果它包含了,那么对象必须拥有独一无二的 GUIDs,而这又将破坏轻松追踪的功能。所以它究竟包含了什么呢?

工作区按照其最简单的方式,可以被理解为变更的历史性记录,这些对对象所作的变更,自从它在其上级基线工作区内创建时一直积累增长。每一个对象都有一个 GUID。

变更是在您做 第一个 基线时开始的。基线的工作区会如此标记,并且成为只读的,所以它不能再被编辑了。没有数据被复制,而百科全书会按照一贯的方式工作,除了是在只读模式下运行外。既然基线 没有 下级,所以该标记可以进行转换。

当您在创建一个子工作区时,仍然没有数据被复制,在数据库中有一个指示符表示可以使用子工作区,而其内容被设置为读/写。当您打开一个激活工作区的百科全书时,您要选择一个工作区。您可以选择根(基线的并且是只读的),或者新子工作区(读/写)。

您在工作区中执行的任意工作,只是应用到该工作区中对象不断累积的变更的日志。这里,理解工作区内的对象是它们来源的根(基线)的相同对象。所以这些工作区内的对象,拥有与根对象相同的 GUID。这里,它们仍然是相同的对象。

怎样添加新的对象?

您可以在子工作区内创建一个新的对象(图表,符号,或者定义),并将其保存。当您执行该操作时会发生什么呢?在子工作区内创建的对象,会保存到子工作区中。因此它只存在于子工作区中。

怎样删除对象?

记住工作区就是对象所应用变更的日志。您在子工作区中所删除的对象,只能在不能得到的该工作区中(就是说,删除了)标记;但是,对象仍然存在于它的上级工作区中。

如果您在子工作区中创建了对象,然后在相同的工作区中将其删除掉了,那么项目就真正地删除了。因为项目是在相同的工作区中创建并破坏的,所以它根本就没有存在的原因。注意如果 Object History 被激活了,那么该删除操作将会在历史日志中显示出来。

怎样创建子工作区的下级呢?

后代的工作区表现非常相似。这就是说,每一个子工作区都显示了一系列的定义,该定义包含了最近的版本。

怎样维护对象历史?

工作区单独提供了追踪了 Rational System Architect 中项目随着一个工作区到另一个工作区变更的历史。您可以使用 Object History 窗格来查看该信息。

但是,有已经存在的特性,也就是所谓的 History,现在可以与工作区一起使用,以提供对百科全书所作变更非常具体的视图。History 通过将原始图表和定义复制到百科全书的历史性区域,并通知谁,什么时候以及为什么(如果还使用了 Synergy Change)变更项目。当伴随而来的还有工作区的实施历史时,您不但能够查看项目是如何随工作区发生变化的,也可以查看项目在一个工作区中是如何变化的。

该 Object History 窗格具有高度的筛选性和分类性,而且有表格使您可以查看报告。您可以将报告保存为几种格式,包括 .csv,这样您就可以控制 Rational System Architect 之外的信息了(例如,在一个扩展表中)。

如果您在历史性表格中选择了多种定义条目,那么您可以在一个新的属性比较窗格中比较属性。这就描述了属性层次之下的变更。您不但能够对相同的项目按照不同的版本进行使用,如图 10 所示,而且可以同时查看不同的项目,如果模型中两个相似的项目可以代表为一个时,这一点非常有用。

图 10. 属性比较窗格
两个定义版本变更的历史
两个定义版本变更的历史

图 10 的大图


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=631788
ArticleTitle=IBM Rational System Architect 工作区使用场景
publish-date=03102011