二十年,专注于中国最专业的模型驱动解决方案(UML、MBSE、SYSML、BPMN、体系结构设计、需求管理、DoDAF等)
模型驱动的研发管理一站式解决方案   Trufun QQ:344593239   咨询热线:3379288210  

美国国防部体系架构框架(DoDAF)


时间: 2020-10-12    来源: 楚凡科技

  DoDAF用于构建复杂系统要求具有了解并管理复杂关系的特别能力。
帮助用户彻底地了解企业架构,对有效的设计、实现、部署和演进系统的维护是至关重要的。
一个完整的与该架构相符的模型是对该理解的关键 ——并且对于减少风险及管理系统的复杂性是必要的。

DoDAF
内容为我们提供了一个观察在增量地定义系统时所利用的体系结构的“窗口”。

已生成的符合 DoDAF的报告支持对主要的面向任务的系统的赞助及筹款的搜索。然而,通过在系统生命周期的早期描述系统架构,系统工程团队可以从该投资中了解到更加多的价值。例如,您越早识别出集成挑战和运作依赖,您就会更有效地达成关键的决策。

Trufun 体系结构设计系统用集成产品的方式全面支持DoDAF,这些产品是证实了的系统工程过程(Rational Unified Process® for Systems Engineering,或称 TUP-SE),和设计用来简化发现、描述、实现,和演进多种与 DoD运作任务相关的复杂企业架构的功能。

Trufun 体系结构设计系统明显地符合 DoDAF的规范,建立在 Trufun UML建模工具的基于 Eclipse
的建模解决方案上,包括Trufun Plato®、Trufun Bacon®,和Trufun Kant等。整个系统开发团队能够使用用于需求管理的Trufun Baco®、用于配置管理的 CVS、git、vss等
、用于变更管理的 IBM Rational ClearQuest®
,及其他Trufun产品。所提供的扩展功能和插件进一步增强了 Systems Modeling Language (SysML)建模和基于状态机的可执行模型的能力。

遵守 DoDAF的最佳途径不需要系统开发的主要工作之外的工作。Trufun体系结构设计系统方法将 DoDAF产品与整个体系结构建模工作合并起来,让 DoDAF视图来表示一个演进的企业架构,该架构是与实现此架构的系统相符合且起源于这个系统的。

如同任何复杂的活动一样,学习利用 DoDAF创建并维护企业架构需要对系统工程的原则,及有关 DoDAF知识的熟练运用。Trufun科技能够很好的提供服务,并优化您的工作。

下面我们向您详细介绍DoDAF
并举例说明如何在描述企业体系结构的情况下满足符合 DoDAF的需求。

关键的 DoDAF要素


DoDAF着重于对运作企业的重要架构要素之间的关系进行建模。符合 DoDAF模型的核心要素是节点(nodes)需求线(needlines)服务(services),以及信息交换(information exchanges)。总的来说,这些实体描述了运作企业中重要活动的结构和分配。

·        


节点 ——系统、参与者,和工作人员

DoDAF的本质要素是节点,表示逻辑或物理实体(工作人员、系统,或子系统),在企业的内部或外部运行,其任务是以某种方式与一个或多个企业要素交互。节点是组成运作企业的复杂系统架构和设计的基础。架构将更着重于节点之间的关系,而设计更多地处理单个节点的结构和行为。因此,DoDAF
的主要目标 ——以及对运作企业的架构建模的好处 ——是描述节点可以通过其进行协作以完成任务的一种方式。在 DoDAF中,我们处理三种节点:在运作视图(OV)中所描述的并表现参与者、工作人员,和系统的联合的运作节点(operational nodes)、作为实现运作节点行为的逻辑要素的系统(systems),及表示贮存逻辑系统或子系统的物理要素或位置的系统节点(system nodes)


需求线 ——关系及依赖

在 DoDAF中,协作的运作节点之间的关系表示为需求线(needlines)。每一条需求线都表示出一个节点向另一个节点提供一个或多个在运行上必要的服务和相关信息的需求。需求线是抽象的,因为它们可能表示单个的服务或信息交换,或者一组服务或信息交换。不论在哪种情况下,需求线都举例说明了,一个运作节点依赖于另一个节点来获得服务或信息,并指定了服务或信息流动的方向。



服务 ——重要的运作功能

服务表示一个节点给予另一个节点的一个或多个可运行的重要功能。每种服务还隐式或显式地表示节点之间的信息传递,并且可能被描述为一个消息或运作。



信息交换 ——所传递信息的特征

信息交换与一组功能性的和非功能性的需求相关,表现出获取、传递或使用信息所受的约束的特征。

复杂系统开发的最佳实践

通过把所需的 DoDAF内容的生产与精心设计企业架构及其相关需求的整个过程无缝地合并在一起,您可以有效地去除复杂系统开发中可感知到的遵从 DoDAF所带来的负担。此外,您可以利用在 DoDAF产品中获得的非常宝贵的工程信息来减少系统开发中成本和进度安排的风险。

详细设计架构的结构和行为的Trufun方法是基于已证实的原则的。“系统工程的六条原则”是一些实用的指导方针,它们为很好地管理系统的演进提供了基础。它们强调了开发复杂系统的组织应该关注的关键领域。它们还使组织能够评估难题,并分析其原因。


分解系统,而不是需求

在进入下一更低层之前,开发一个抽象层次。明确地精心设计用例及所获得的行为。务必不仅考虑逻辑架构,还要考虑架构的物理或面向位置的方面。为所描述的每个抽象层次查明并编制逻辑和物理架构之间的关系。对下一个更低抽象层重复操作,直至架构能足以满足开发组织的需求。



即要分离又要集成

为所描述的每个抽象层分析黑盒及白盒视图。争取平衡两种观点以避免某一方向上的过度行为。分离太多会导致功能分解和相关的集成问题,太过强调集成,您会有错过重要功能问题的危险。


系统和组件应协作,开发团队也应该这样

需要协作的组件和系统/子系统的开发人员依赖于全面的相关性知识。开发人员如果不协作,您就会增加集成失败的风险。


规范贯穿架构中

应该了解每个抽象层上的需求,并利用它们导出在每个抽象层上协作的要素功能。


在生命周期中要减少风险并增加价值

当各种资源可以用来实现此原则时,就能减少成功的障碍。


开发组织应该考虑产品架构

开发团队技能的最佳实践要求在整个迭代过程中将责任从一个角色移到另一个角色。组织具有多重互补技能的团队提供了更多的管理灵活性,并且为组织增加了全面的个人能力。

风险管理推进了企业架构开发的整个过程。严格地应用迭代过程,并使用标准的符号,如统一建模语言(Unified Modeling Language,UML)会形成在连续的更低层抽象层次上的对系统结果和行为的多种观点的全面可视化表示。循环地对子系统定义层和内部设计应用这些原则可形成一个完整、一致的架构工程模型。而这又为复杂系统的设计、实现、开发、管理,和受控的演进提供了基础。

符合 DoDAF模型的组织结构


DoDAF构成了视图周围的架构信息。全视图(AV)

产品的目的是提供在运作企业环境中的主题系统的全景透视图,并说明了拱型的关系,如 Concept of Operation (CONOPS)和关键任务目标及策略,以及架构上的重要术语的整合的词典。

运作视图 (OV)


着重于主题系统的表面上可见的结构和行为。此视图描述了运作节点及其关系,并确定反映任务需求的依赖,因而为企业定义和演进提供全部的环境。

认识到内部结构和行为是 系统视图(SV)的焦点,它将功能和非功能需求(来自运作视图)的严格分配合并到逻辑和物理系统要素和接口上。

技术标准视图 (TV)


中反映出对企业的运作架构的标准约束,并描述了系统的当前和未来状态。


DoDAF视图内及之间的一致性是关键的。
DoDAF视图的最佳推导要求多重抽象层次(即,系统分解)之间建模的一致性。当我们深入到架构模型中,向企业的连续抽象层次中循环地应用严格的系统架构发现过程时,我们对要素有了更多的了解,并可能使用其他方法来表示其特征。例如,最初我们可能用用例或环境图的方式来表示满足用户需求的复杂系统。当我们对所支持的活动(系统白盒行为)有更多的了解时,我们可能增加类、活动,和/或序列图来反映额外的细节。在一个图中作为参与者进行描述的节点(nodes)在其它图中可能更适合表示为类或对象。组成子系统的类运作的集合可能实现服务(services)

在确定对每个核心 DoDAF
要素建模有多好时,您必须首先了解该要素下的必要语义,以及所有可应用的约束条件,然后在给定的整个工程工作环境中应用恰当的表示法。此环境包括建模工作的风险、复杂性、工具、表示法,和目标。

生成 DoDAF视图的全部过程是迭代增量的。随着对架构信息的获取更加广泛与深入,所有视图(AV-1和 AV-2)在进行着演进。将AV-1用作基础,分析运作企业的架构的交互以及主题系统,这导致发现了系统和运作节点之间的高层交互。完全地描述这些高层关系是运作视图的着重点。

只有在您充分了解了外部系统行为(在企业层)之后,您才能继续详细描述系统视图。这是我们开始设计并组织为全面的开发提供基础的内部行为和子系统交互的地方。这里,我们还将协调多种让我们通过联合实现的实践和用例流来处理必要的运作行为的物理逻辑实现的观点。

所有视图产品


下面表格简要地描述了所有视图产品,以及您创建它们的顺序。


产品

 
标题

 
描述

 
表示

 
创建顺序

 
AV-1 概述和总结信息
 
文本文档,描述了主题系统的范围、目的、预计用户,和运作环境。提供对企业性质,以及企业如何与主题系统交互的全面了解。支持对系统使用的战略上的观察。
 
参考模型的文本文档。
 
1
AV-2 整合的字典
 
用于描述架构的所有术语的定义。提供一组标准的参考术语,保持体系结构所有的客户所了解的含义是一致的。
 
存储模型,基于存储库的文本,可导出 XML

 
进行中
 
DoDAF所有视图(AV)


产品概述了在主题系统演进过程中开发、部署,并管理这些系统所处于的环境。这个概述描述了任务目标、策略、运作概念,及运作的一般环境,和相关的专门术语。

AV-1:概述和总结信息

AV-1是对运作环境和要在演进的系统中实现的任务功能的文字概述。其焦点是需要在该环境内建立的主题系统或企业。Relevant Concepts of Operations (CONOPS)和策略在抽象层次上表示出来,适用于执行的领导来简化决策的制定。AV-1的内容表现出获取必要商业驱动的指导或观察,以及正在开发的主题系统的需求。

需求方或开发组织可能准备 AV-1,尽管,同所有 DoDAF视图产品一样,与拥有广泛的运作经验的问题领域专家 (SME)的实质交互是必要的。以此处描述的方法,您可以利用文字处理器生成 AV-1文档并将参考链结与包含可视化 DoDAF产品的模型相关联。


AV-2:整合的字典
AV-2表示一个简单的,但对系统和软件开发很必要的概念。通过建立一个与架构相关的定义和可能模糊的术语的单一集中的词汇表,就可以充分地满足对含义的一致性和清晰性的需求。

Trufun实现
方法将由Trufun的建模工具,所管理的模型存储库中的集成字典的不断演进的版本合并起来。在您生成模型要素时,您可以将要素合并到Trufun建模工具中的工程信息中(您随时都可以从这些信息中提取 AV-2)。所有与 DoDAF原型相关的图形化模型要素可以以此方式自动获取。您需要手动地添加文本参考,或者通过一些其他的工具,如 Trufun Bacon需求管理工具,访问它们。

运作视图产品


DoDAF运作视图是由各种产品组成的,这些产品提供了对整个企业环境中的主题系统的外部结构和行为的多种观点。在这些视图中,我们描述了系统及其角色之间的交互,系统所需的任务目标,及为了实现那些目标的必要依赖和交互。

OV的焦点是影响该任务的那些需求和功能。系统视图 (SV)说明了 OV是如何实现的。下面的表格简要地说明了 OV产品,并建议了一个创建这些产品的顺序。


产品

 
标题

 
描述

 
表示

 
创建顺序

 
OV-1 高级运作概念图
 
运作概念的图形抽象,支持企业的任务。
 
高级的抽象图形,企业环境图(Enterprise Context Diagram
),企业用例图(Enterprise Use-Case Diagram

 
1*
OV-2 运作节点连接描述
 
运作节点、活动、连通性,和信息流。
 
带有需求线和 IO
实体的企业环境图

 
4**
OV-3 运作信息交换矩阵
 
节点间交换的信息及信息的属性。
 
贮存模型的文本矩阵,可导出 XML
 
4**
OV-4 命令关系图表
 
命令、控制,和运作组织之间的协调关系。
 
带有组织要素的自由形式的图
 
2**
OV-5 活动模型
 
活动、活动间的关系、I/O
、约束条件,及执行活动的机制。

 
针对每个企业用例的活动图
 
2**
OV-6a 运作规则模型
 
识别影响运作活动的业务规则和过程约束条件。
 
模型约束(OCL/SysML
),参考模型的功能及非功能的需求

 
2**
OV-6b 运作状态转换描述
 
识别事件和运作序列之间的关系。
 
状态转移图
 
4**
OV-6c 运作事件/
跟踪描述

 
识别追溯到场景或关键活动的外部可视的运作序列和动作。
 
序列图
 
3
OV-7 逻辑数据模型
 
结构化的数据关系,支持信息的运作交换。
 
指示 IO
实体及其关系的类图

 
5
* OV-1的内容首先开始,但到 OV-2完成时才能完成 OV-1的图形。
**这些产品不是连续地相依赖的,可以按别的顺序创建,否则这些产品将是相互依赖的且要共同地开发。
***状态转移图是可选地用于构建对需要特殊处理的复杂事件的关键的实时响应。




OV-1:高级运作概念图


OV-1简明扼要地传达了运作企业环境中的主题系统的范围。OV-1图形描述是出自画家之手的产品,反映来自多个源的内容。OV-1的主要信息来源是 AV-1概要和总结(Overview and Summary)文档,即运作环境图(OperationalContext Diagram),和企业用例图(Enterprise Use-Case Diagram)。我们以主题系统开始绘制企业用例图,并确定所有与该系统交互的外部系统和组织实体。我们将这些交互要素描绘为参与者或角色。然而,为每个归就于参与者的运作目标向图中加入用例。在适当的位置加入 UML «通信»原型的关联。

许多参与者或角色在组织要素中协作,为了满足任务的需求。向组织要素聚集参与者或角色可以使得识别出运作节点,利用类图来获取,即指定的运作环境图。系统架构师和其他 SME与图形画家合作绘制出 OV-1图中的运作环境图,为适合执行层的观众。由于此图与在开发的系统有关,所以它为运作企业的外部可视架构的构建提供了基础。该图的内容会随着获取的更多信息及生成的额外的 DoDAF产品而演进的。


在多个参与者表示运作节点中的过程的地方,您可能需要将与那些参与者相关的角色集合到一起。随后由运作节点(参与者集合)和该系统之间集合的交互,或需求线来表示参与者与主题系统之间的交互。与那些参与者相关的 IO
实体也与指定的运作节点关联起来。

OV-2:运作节点连接描述


OV-2确定并为运作节点之间的运作依赖建模。DoDAF将这些依赖定义为需求线(needlines)。有两种主要的确定需求线的方法:

1.     确定企业用例图中每个«通信»关联中所表现出来的依赖的本质,并指定相应的需求线。给需求线一个定向的组件,使其能从消费者(对于该关系)导航到服务或信息的提供者。

2.     等到您开始详述用例流和场景并在OV-6c


注意:

UML 2.0
引入了新的分类器,协作(Collaboration)。与协作相关的语义为您提供了更有力地描述关系的潜能。您可以指定关联任务、模式、模板和相关参数。您还可以将与协作相关的信息例示为协作事件,进一步指定每个可能的 IER。增大带有类和复合结构图(分别参照协作集协作事件)的 DoDAF表示的极小集是值得的。

对这些 UML要素进行了全面的讨论。

OV-3:运作信息交换矩阵

OV-3是共同地表示 OV-2的需求线的 IER矩阵。通过参考 OV-6c的内容,可以利用Trufun 体系结构系统进行设计和开发,工具可自动地生成 OV-3。
OV-3矩阵中的每一行表示一个 IER,由在 OV-6c

序列图的交互中的角色和对象间转移的数据的特征组成。矩阵为每组交互并交换信息的对象或角色确定截然不同的 IER。具体的 IER特征与非功能需求或设计约束相关。每个 IER的内容都表示 OV-6c IO实体类(见下)的实例,在此,属性表示 DoDAF需要的数据特征。因此,矩阵中的每个信息要素都应该追溯到逻辑数据模型(Logical
Data Model),即 OV-7。

OV-3强调架构中交换的信息的逻辑和运作特性。它不打算极力地获取信息交换的所有细节,而是作为一种帮助您了解重要交换的重要方面的机制。

此内容要追溯到补充的或非功能的需求。


需求线标识符

 
IER

标识符


 
信息要素描述

 
生产者

 
消费者

 
    信息要素名称和标识符

内容

范围

精度

语言

 
通过节点名称和标识符发送通过活动名称和标识符发送
 
通过节点名称和标识符接收通过活动名称和标识符接收
 

需求线标识符


分享到: