工作区简介

基本概念

通过实施工作区，您可以在 IBM® Rational® System Architect 之中建模架构的多个版本。您可以为以下的场景创建不同版本的架构：

• 实施一个企业架构
• 实施一个当期以及未来的架构
• 集成系统的系统架构
• 执行交易分析

工作区的概念非常简单。工作区在概念上与词典非常类似。实施工作区使得您可以打开不同版本的词典。一个工作区的更改不会影响到其他的工作区。这提供了追踪性，原始的和后续的词典版本之间的比较，以及工作区合并（查看 参考资料 部分以得到怎样实施工作区的指示）。

它们工作的方式也很简单：

1. 创建了一个只读模式的基线，它包含了不会变化的信息（例如，一个公司名的列表）。
2. 然后在创建工作区时，来自基线的信息会拷贝到工作区之中。

您可以更改或者细化工作区之内的信息，而且您可以在工作区内或者跨工作区内进行报告，以进行分析。

记住与工作区相关的以下信息，这一点非常重要：

• 一个词典只有一个根（基线）工作区。
• 从根工作区创建的所有工作区都继承了父类的基线；因此，它们继承了所有的图表与定义。
• 您可以查看一个词典基线，但是您不能编辑它，因为它是只读的。
• 用户一次只能打开一个工作区。当您更改档案工作区时，活动工作区之中所有打开的项目都会关闭掉。
• 多个用户可以在相同的工作区内建模。

您还考虑以下的这些工作区限制：

• 不想要使用多个词典，并将它们放到伪文件架构下的词典之中
• 不支持在单个的词典中不同的属性设置（所有的工作区使用相同的 usrprops 文件）
• 不要为对象使用 包裹 或者 名字区域（支持超过一个对象拥有相同的名字）
• 不支持在更高层次上访问控制分组
• 不要用于解决正交性的问题

回页首

为工作区开发规范以及非规范的 DoDAF 2 架构

本文中的场景基于 规范 以及 非规范 架构的概念，以及那些架构中所包含的内容，如 DoDAF 2 标准所述。这一部分提供了关于规范架构层以及非规范架构层的信息，并描述了使用工作区建模架构的常用方法。

在 DoDAF 2.0 之中定义有三种规范的架构层：

1. 开发架构 为其他的两层提供了治理功能。它是在机构性层次或者联合员工层次上开发的，例如，它可以是整个美国海岸警卫队或者只是海岸警卫队一个部门，例如后勤部门的架构。它应该包含全局信息格以及 DoD Information 企业架构，以确定低层的架构也考虑了需求与其附属。部门层次的架构就是定义的视图与任务。
2. 功能或者部门架构 描述了以下领域特定功能的使用：
   • 业务（例如，后勤部门开发员如何执行日常任务）。
   • 获取（需要获得什么构件或者服务来满足后勤部门分配的功能）。
   • 战术操作 （例如，定义一个架构以描述后勤部门是怎样为国家安全支持执行操作的）。该架构介绍了日常的业务是如何完成的，对于特定的机构单元，或者特定的环境（例如在伊拉克进行一场战争）。
3. 构件架构 查看特定的需要（例如，什么时候为国家安全执行操作，后勤部门需要什么系统或者服务）。这就是为操作性环境支持技术和服务定义的地方。构件架构显示了需要什么新型服务和技术来支持操作，或者当期使用什么服务和技术。这就是传统的“项目”架构，或者 方案 架构。

这三个层次有助于控制架构之中的模型元素，以创建对术语的标准使用。例如，机构性单元是在部门层次上定义的。当您在创建一个功能层次架构时，它应该重复使用部门层次已经定义的机构性单元。这可以加速建模，并使得它变得更加精确。它还为决策制定者提供了部门层次上的功能，以查询多个功能或者方案架构中使用的一般数据。优势在于，例如，如果您要重命名一个机构性单元，删除，或者重新组织，那么影响可以在整个企业的范围内进行评价，而不像今天常见的那样，一个部门中发生变化时，另外一个部门却不会有回应。

在用于定义的 DoDAF 2 中有四个 规范性 架构层，在每一个规范层中，创建什么类型的架构。

1. 操作性 架构描述了业务和战术性操作，并关注于功能视图，项目视图，以及操作性视图。
2. 系统 架构描述了系统视图和标准视图上的系统，网络，以及交流功能。它应该基于操作性架构。
3. 服务 架构描述了内部性和外部性服务功能，关注于服务视图和标准视图。它应该建立在操作性架构的基础之上。
4. 方案 架构查看的是已存在的架构，并决定将来作出什么更改。它使用所有需要的视图来定义方案。

如图 2 所示，非规范架构存在于每一个规范化架构层上。

工作区有助于确定架构之内的稳定性，并遵循命名规则以及其他的架构性治理需求。

使用工作区实施规范性和非规范性架构

规范性架构：

• 部门架构（基线）
• 功能或者部门架构（工作区）
• 构件架构（功能作为基线，构件作为工作区，可以被开发周期划分）

非规范性架构

• 操作性（基线）
• 系统（基线）
• 服务（基线）
• 方案（工作区）

回页首

使用工作区的场景

本文所展示场景基于处理项目的真实世界经验，但是这并不意味着只有一种方法去建模这些类型的项目，也不意味着特定的模型也在基线之中。

场景 1：企业架构的实施

企业架构在大多数的 DoD 构件之内实施。通常出现的一个问题是，怎样在 System Architect 中记录规范架构的层次，以及怎样管理更改。

例如，美国海岸警卫队实施了一个企业架构。它们拥有一个部门架构之内活动，系统，以及公司的标准列表。这些标准被业务行使用，以开发功能或者部门架构（例如，后勤或者金融）。这可以确保每一行的业务都使用相同的术语。它还可以帮助业务行理解它们的交流点（例如，后勤部门怎样与金融部门相交流）。

使用工作区，可以创建企业层次的图表与定义，它限制了低层次架构的开发。例如，这可以确保在所有的架构项目之中，都稳定地使用系统名。它还支持在多个架构之间的报告，因为相同的名字在公司之间得到了使用（例如，创建一个报告以查看消除或者自动化一个角色的效果）。

企业架构可以创建一个或者两个方法，以开发标准企业工件的列表。最佳用例场景就是在部门层次架构之上创建该架构元素（系统列表，公司名，等等），该架构在功能/部门层次以及方案层次上得到了扩展。在有些情况下，定义方案或者功能/部门层次，然后从不同的架构中筛选一般的元素变得更加轻松了（范例：从三个功能/部门架构中得到系统的列表，并在部门架构之中创建一个完整的列表）。

出于简便性的考虑，该范例假设一种底到顶的方法。

企业架构（EA）项目之内的基线根工作区（部门层次）应该包含以下的内容：

• CV-1（整个公司可用功能的列表）
• OV-4（整个公司的机构性聊天）
• OV-5a/b（公司执行的高层次活动）
• DIV-2（公司之间实体的企业范围内数据模型）
• 系统与技术的列表（Technical Reference Model）

基线还应该包含架构元素或者图表，它们有低层次的架构。例如，如果部门必须遵循 Federal Enterprise Architecture Framework（FEAF），那么 FEAF 数据元素应该包含到基线之中。另外一个范例是其他公司限制的公司，比如美国海岸警卫队和国家安全局。应该包含两个架构之间稳定的元素（例如，使用美国国家安全局的企业数据模型）。

工作区由功能/部门架构组成，它应该在基线可用的信息上展开。例如，一个功能可能向企业数据模型添加其他的实体，以处理特定的需求。

功能/部门架构工作区应该包含：

• AV-1（解释创建架构的观点，例如，后勤功能）
• OV-1（描述什么功能或者部门必须操作）
• OV-2（功能或者部门内执行者之间的资源流程）
• OV-5a/b 分解（采取基线的高层次活动，并提供具体的细节）
• SV-1（描述支持功能或者部门系统之间的资源流程 -- 系统应该基于来自基线系统的列表）
• SV-2（描述 SV-1 中系统之间的物理学界面-- 系统应该基于来自基线系统的列表）
• DIV-2（改进企业数据模型）
• DIV-3（反映功能/部门之内使用的物理学数据库）

在功能或者片段架构完成和批准之后，对部门架构做出需要的更改，然后片段架构的功能被分解为多个方案架构，而功能或者片段作为一个基线。

使用工作区来定义企业架构的优势

• 在机构内部会稳定地使用相同的术语，消除混乱，并支持在公司之间的部门层次上进行报告。
• 架构开发将会非常快捷，因为每一个低层次的架构都会使用预定义的定义和图表实现。
• 报告可以在工作区之间完成，以确保稳定性（例如，确保系统名不会发生变动）。
• 使用企业范围的数据实现一个新的词典（例如，一个新型的功能/部门词典）非常简单，只需要创建一个新的工作区。
• 更好地集成系统，因为潜在的数据元素拥有相同的名字与数据格式。
• 系统功能降低了重复性，并且对已存在的系统功能进行了再使用

场景 2：当前架构以及未来架构的实施

DoD 对查看公司的当前状态并不感兴趣。它们还必须为未来制定计划，以确保未来的功能得到识别和预算，这样这些功能才会得到开发。计划的时间线通常是 1，5，10，或者 20 年。

一个典型的案例就是美国航天部门的空间侦查监视项目。功能，例如更强大的处理和改进的收集能力，在满足这些功能的技术就绪之前就得到了规划。当技术就位之后（更好的相机，以及发射更大卫星的能力），项目按计划进行以实施新的功能，并且在 30 多年间，空间项目的需求都没有发生更改。

工作区使得这种类型的规划变得简单起来，在词典中的每一个工作区，都可以代表未来的某段时间。因为更改一个工作区内的定义或者图表，都不会影响到其他工作区内相同名字的定义或者图表。在每段时间内都可以作出更改和更新，而报告将会识别工作区内的更改。

基线架构一般是功能/部门架构，因为计划是在该层次上执行的（假设功能/部门映射到一个公司内部的构件，例如美国海岸警卫队的后勤部门）。它应该包括当前的（现在的）模型：

• AV-1
• CV-1
• OV-1
• OV-2
• OV-4
• OV-5
• SV-1
• SV-2
• SV-4
• DIV-2
• DIV-3

工作区基于未来的时间线。工作区中将会编辑到的产品包括：

• CV-1（添加未来的功能）
• OV-1（使用新功能描述新的操作）
• OV-2（显示需要的其他执行者和资源流程；执行者和资源流程可能也被删除掉）
• OV-4（显示随着时间的变化执行者或者人员的重新组织，退出以及添加）
• OV-5（其他的低层次活动可能得到添加，但是 OV-5 中的大多数更改都是为活动产生和使用的数据准备的）
• SV-1（它会显示系统界面随着时间的变化，以及系统的添加或者删除）
• SV-2（这将会显示执行者或者系统之间物理交流的更改）
• SV-4（其他的系统功能可能得到添加，以满足一个新的功能，或者利用新型的技术）
• DIV-2（新型功能所需要的其他条目与属性）
• DIV-3（数据库技术改进时物理数据库实施的潜在性更改）

使用现状架构以及将来架构工作区的优势

• 在性能评价中追踪一项更改（例如：86% 可用性在未来的五年间增加到 95%）
• 在系统界面中追踪一项更改
• 追踪系统的替换情况
• 分析一项新执行者或者角色消除或者引入的影响
• 更好地进行预算
• 识别满足一项新功能所需要的新资源

场景 3：系统集成架构

大型的项目，或者 系统的系统，通常会被分解为小型的，更好管理的项目。这些项目一般是由一个或者更多的承包商接手的，这些承包商在开发系统构件时有较强的专业性。但是所有的项目最终都会得到集成，以让整个系统变得可以交互操作。

新窗格的开发就是这种类型系统的一个范例。一个承包商可以构建引擎，另一个窗格主体，另一个分析器，等等。所有这些系统都需要引入到集成的系统之中。通过按照标准的方法记录子系统，并提供高层次的集成计划，系统的集成需要更少的重复劳动，并且更容易实现。

基线架构一般是构件架构，它会识别将会被构建的系统或者系统的系统。它应该包含高层次的设计模型：

• AV-1
• CV-1
• OV-1
• OV-2
• OV-4
• OV-5
• SV-1
• SV-2
• SV-4
• DIV-2
• DIV-3

工作区可以是子系统，并且由子承包商分解。基线模型将会得到进一步的分解，以显示子系统设计。在工作区内将会得到编辑的模型包括：

• OV-2（显示子系统所需要的其他执行者和资源流程；基线 OV-2 只会在高层次上详细显示）
• OV-5（如果分配给子承包商的活动需要时，可以添加其他低层次的活动）
• SV-1（显示特定子系统和资源流程的其他细节）
• SV-2（这将会向子系统之内使用的物理交流显示详细信息）
• SV-4（可以分解系统功能，以识别子系统低层次系统功能之间的内部性资源流程）
• DIV-2（需要其他的条目与属性，以提供子系统所需要数据的详细信息）
• DIV-3（子系统的物理数据库实施）

为集成式架构使用工作区的优势

• 设计的治理
• 集成的消除，因为集成点得到了清晰的理解
• 分析确保每个子系统的需求都得到了满足
• 集成点风险的识别与管理
• 子承包商系统界限的清晰定义
• 系统界限之间的常用术语
• 如果子系统发生更改，进行影响分析
• 系统集成的时间线可以得到识别，因为系统的附属性得到了清晰的理解

场景 4：Trade-off 分析

DoD 通常需要研究进行潜在方案的交易分析。他们通常做研究，去测试使用新型技术的可能性。

美国空军智能收集项目就是关于它的一个很好的范例。在军事监视的早期历史中，二战之后，兴起了一场关于使用高空飞艇，改进式轰炸机（RB-29），以及改进式战斗机（RF-84）来收集情报的辩论。每一项功能的频率和时间都得到了分析（航程/突破率，可靠性，被探测和俘获的风险性），关于找到什么资源来提供最成功结果的决策也制定了。

通过提供一个操作性场景，然后研究每一种潜在性方案（对于空军来说，使用资源来收集情报），工作区简化了不同潜在性方案的分析。方案的技术现实性成为非常明显的一面，并能够满足操作性需求以及性能评价。可以基于每一个潜在性方案的结果来制定决策。

基线架构一般是构件架构，因为构件架构包含了高层次的操作性需求，方案必须要满足这些需求。该架构可以是当前的（当前），或者是未来的状态（未来）架构。它应该包含未来（未来）模型的当前（现在）状态：

• AV-1
• CV-1
• OV-1
• OV-2
• OV-4
• OV-5
• SV-1
• SV-2
• SV-4
• DIV-2
• DIV-3

工作区基于分析的不同选项。大多数的工程工作都查看不同的系统查看相关的选项；操作性环境之中的信息并不会得到变化。在工作区中将会得到更改的产品包括：

• SV-1（它会显示其他的，或者编辑过的，系统界面）
• SV-2（它将会显示执行者或者系统潜力之间的物理性交流，基于灵活性分析的新技术）
• SV-4（其他的系统功能可以得到添加，以利用新的技术）
• DIV-3（由于添加新功能，对物理数据库实施所造成的潜在性更改）

为交易分析使用工作区的优势

• 报告各种选项成本的能力
• 为各种选项报告性能措施以及相关需求的能力，以避免不合适工程的方案
• 确保操作性环境没有发生变化，以让选项变得更加灵活
• 追踪与不同选项相联系的任务的能力
• 不同选项之间的标准化以便更轻松的分析（定义名保持一致；图表包含稳定的数据）

回页首

工作区分析工具

SA Compare 特性

您可以使用 Rational System Architect SA Compare 设施，来显示工作区之间的变更。例如，SA Compare 可以与 DoDAF 2 架构一起使用，以识别任意的更改：

• 工作区内项目名的变更（例如：根目录下机构名稍后在工作区之中得到了更改）
• 根源与工作区之间的添加与删除（范例：工作区中添加的其他系统功能，或者工作区中系统的删除）
• 随着时间的添加或者删除（如果工作区是基于时间的话）
• 定义内对属性的更改

如果您想要得到更多信息，您可以查看 Rational System Architect 信息中心之中的 SA Compare 部分，见于 参考资料。

IBM Cognos 软件

IBM® Cognos® 业务智能以及性能管理软件支持工作区之间的报告。它还可以用于运行执行计算的报告。使用带有 DoDAF 2 架构的 Cognos 范例包括：

• 活动完整列表的报告包含在两个工作区之内（SA Report Generator 只能报告工作区之内的内容，而不是工作区之间的内容）
• 提供多个工作区之间的最高系统功能列表
• 为所有工作区之间的系统功能和活动提供全部的成本（可以运行报告运行以查看哪个选项是最高成本，哪一个是最低成本）
• 报告一个系统所需要的所有资源流程（可以运行报告的集成操作，以显示创建集成系统所需要的所有资源流程）

如果您想要得到更多信息，您可以查看 Rational System Architect Information Center 中所列出的 SA Compare 文献，它列在 参考资料 之中。

Rational Focal Point 软件

IBM® Rational® Focal Point 软件提供了市场驱动的以及业务驱动的产品，和概述管理。使用带有 DoDAF 的 Focal Point 的范例包括：

• 特定工作区或者跨工作区的操作板，有助于管理项目风险，日程安排，以及成本
• 使用目标性信息，来做出基于定量分析的设计决策，而不是猜测哪一种是最节省成本，以及最低风险的方法
• 获取客户需要的优先级，这样架构就反映了最高优先级的功能。
• 路线图以及规划功能，以分析未来的发展趋势

如果想要得到更多信息，您可以查看 参考资料 之中所列出的 Rational Focal Point 概述引用。

Rational DOORS 软件

IBM® Rational® DOORS 是一种工具，它提供了一种综合性的需求管理环境。需求可以从 Department Level 联系至 Component Level，以显示构件架构满足 Capability 与 Department 所有高层次的需求。范例使用带有 DoDAF 2 架构的 DOORS 包括：

• 图表上的图像指示符有一个相应的需求
• 报告显示没有相关需求的架构元素，以及没有与架构相联系的需求（遗忘的需求）。
• 3 个规范性架构层层次需求的管理，以及层次之间的追踪性。
• 架构上的标准和治理可以位于 DOORS 上，并且与架构相联系。
• 架构变更或者需求变更的影响分析可以使用报告轻松完成。

如果您想要得到更多信息，您可以查看 参考资料 中所列出的 Rational DOORS 概述页面。

参考资料

学习

• 其他有关工作空间的信息：
  • 配置 SA 工作空间
  • 如何使用IBM Rational System Architect 工作空间场景进行工作，Ian Hancock，Jog Raj 和 Ed Vail 作（developerWorks，2010 年 11 月）
  • 演示：使用 Rational System Architect 工作空间，Jason A. Green 作（developerWorks，2009 年 11 月）
  • developerWorks 技术文档库中的 Rational System Architect 的相关资源
  
  
• 在本文中提到的有关 IBM Rational 软件的信息：
  • DeveloperWorks web 页面上的 Rational System Architect 和 在线示例，以及信息中心的 SA Compare 文档
  • DeveloperWorks 上的 Rational Focal Point 产品专题 页面和 概述 页面
  • DeveloperWorks 上的 Rational DOORS 产品专题 页面和 概述 页面
  
  
• 访问 developerWorks 上的 Rational 专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
  
  
• 时刻关注 developerWorks 技术事件和 Web 广播，包括各种 IBM 产品和 IT 行业主题。
  • 参见 developerWorksLive! 技术讲座，快速了解 IBM 产品和工具，以及 IT 行业趋势。
  • 观看 developerWorks 演示中心，从初学者的产品安装和配置演示，到面向有经验开发人员的高级功能。
  
  
• 改善您的技能。查看 Rational 培训和认证 目录，其包含了许多广泛议题的课程类型。您可以在任何地方，任何时间学习它们，许多“启动”课程是免费的。
  
  

获得产品和技术

• 在线试用免费的、包含全部功能的 Rational System Architect 试用版。
  
  
• 按照最适合您的方式IBM 产品评估试用版软件：下载进行试用，可以在线进行，在云环境中使用，或者在 IBM SOA 人员沙箱 中花一些时间了解如何有效实施面向服务架构。
  
  

讨论

• 有关 Rational System Architect，请加入 developerWorks 上的 企业架构和业务架构讨论区，以及 LinkedIn 上的 Rational System Architect 用户组。
  
  
• 通过 撰写一篇 developerWorks 文章 共享您的知识，并帮助那些使用 Rational 软件的人员。您将获得全球范围展示，RSS 企业联合组织，署名和建立，以及 developerWorks Rational web 网站专业编辑和出版的益处。查找 如何编写一篇好的 developerWorks ，以及如何进行。
  
  
• 跟随 Facebook，Twitter (@ibmrational) 和 YouTube 上的 Rational 软件，并添加您的注释和请求。
  
  
• 加入 Rational 讨论区，cafés 和 wikis，询问并回答问题，增加您的专业技能。
  
  
• 通过加入 developerWorks 中文社区，与其他人员联系，分享您的兴趣爱好，并响应 开发人员驱动的博客。
  
  

关于作者

Franki Schafrik 有 17 年和全球国防行业客户使用 Rational System Architect 和 DoDAF 的经验。她在国际间进行 DoDAF 的咨询和培训。

为本文评分

评论

回页首

内容

• 工作区简介
• 为工作区开发规范以及非规范的 DoDAF 2 架构
• 使用工作区的场景
• 工作区分析工具
• 参考资料
• 关于作者
• 评论