逻辑架构模型开发的目的和过程方法-电子发烧友网

1.目的

逻辑架构模型开发的目的是定义、选择、和集成系统的逻辑架构模型提供了一个框架,来验证一个对未来的系统将满足所有操作场景的系统需求,在权衡系统需求可以探索开发这样的系统。

流程的通用输入包括系统需求、架构师识别并用于回答需求的通用架构模式、系统分析过程的结果，以及来自系统验证和确认过程的反馈。根据所选择的生命周期模型，这些输入和输出以及它们之间的关系将在整个过程中演进和变更(请参阅应用生命周期过程)。

流程的一般输出要么是单个逻辑架构模型，要么是一组候选逻辑架构模型，以及所选的独立逻辑架构模型及其选择的基本原理。它们至少包括视图和模型。这些包括功能、行为和时间视图，逻辑架构模型要素和系统需求之间的可跟踪矩阵。

2.过程的活动

在此过程中执行的主要活动和任务包括:

识别和分析功能和行为要素:

通过分析功能、接口和操作需求，从系统需求中识别功能、输入-输出流、操作模式、模式转换和操作场景。

为每个功能和输出定义必要的输入和控制(能量、材料和数据流)，从而推论出使用、转换、移动和生成输入-输出流所需的功能。

将系统需求分配到功能和行为要素:

通过对性能、有效性和约束需求的分配，正式地描述功能表达式及其属性。特别是，研究时间方面的需求，以分配持续时间，响应时间，和频率的功能。

通过接口、有效性、操作性、时间和约束需求的分配，正式地描述输入、输出和控制流表达式及其属性。

在系统需求和这些功能和行为要素之间建立可追溯性。

为每个候选项定义候选逻辑架构模型:

根据系统需求(如果有的话)分析操作模式，并/或使用先前定义的要素来建模操作模式的序列和模式的转换。最终将模式分解为子模式，然后为每个操作模式建立一个或多个功能识别和/或使用相关的通用行为模式的场景。

集成这些功能场景，以获得系统的行为架构模型(动态行为的完整描述)。

根据需要分解前面定义的逻辑要素，以查看实现。

为之前定义的逻辑要素分配和合并时间约束，如时间周期、持续时间、频率、响应时间、超时、停止条件等。

为与决策级别相对应的功能定义多个级别的执行频率，以便监控系统操作，在这个时间基础上对处理进行优先级排序，并在这些执行频率级别之间共享功能，以获得一个当前架构模型。

执行功能失效模式和效果分析，并根据需要更新逻辑架构要素。

使用模拟器执行模型(如果可能的话)，并调整这些模型以获得预期的特性。

集成选择的独立逻辑架构模型:

通过根据评估标准(与系统需求相关)评估候选逻辑架构模型并对它们进行比较，选择逻辑架构，使用系统分析过程来执行评估和选择的决策管理过程(参见系统分析和决策管理主题)。这种选定的逻辑架构模型称为独立逻辑架构模型，因为它尽可能地独立于实现决策。

识别和定义为设计的必要性而创建的与派生的系统需求相对应的派生的逻辑架构模型要素。将这些需求分配给适当的系统(当前研究的系统或外部系统)。

验证并验证所选择的逻辑架构模型(尽可能使用可执行的模型)，根据需要进行修正，并建立系统需求和逻辑架构模型要素之间的可追溯性。

反馈逻辑架构模型开发和系统需求。此活动在物理架构模型开发过程之后执行:

如果可能的话，将分配的逻辑架构建模到系统和系统要素，并根据需要添加任何功能、行为和时间要素来同步功能和处理。

定义或合并由所选逻辑和物理架构模型产生的派生逻辑和物理要素。定义相应的派生需求，并将它们分配到适当的逻辑和物理架构要素。将这些派生的需求合并到受影响系统的需求基线中。

3.工件、方法和建模技术

逻辑架构描述使用分组在下列模型类型下的建模技术。已经开发了几种方法来支持这些类型的模型(有些是可执行模型):

功能模型——包括结构化分析设计技术(SADT/IDEF0)、系统分析与实时(SA-RT)、增强功能流框图(eFFBD)和功能分析系统技术(FAST)等模型。

语义模型——包括实体关系图、类图和数据流图等模型。

动态模型——包括状态转换图、状态图、eFFBDs、状态机等模型

图(SysML)、活动图(SysML) (OMG 2010)和petri网。

根据领域的类型(如防御、企业)，架构框架提供了可以帮助表示架构的其他方面/视图的描述——参见企业系统工程关键概念中的“企业架构框架和方法论”一节。参见使用与ISO/IEC/IEEE 42010 (ISO 2011)相关的通用模板的实用方法。

4.实际考虑

如上所述，逻辑架构模型的目的是提供系统必须能够做什么来满足所述需求的描述。这将有助于确保所有利益攸关方的需求和/或关注点都能通过任何解决方案得到解决，并且能够考虑创新的解决方案，以及基于当前解决方案技术的解决方案。在实践中，问题利益攸关方推动他们自己的议程，解决方案架构师或设计师提供他们熟悉的解决方案，这是人的本性。如果逻辑架构模型在选择的生命周期中没有得到适当的执行，那么问题和解决方案利益攸关方很容易忽略它，并恢复到他们自己的偏见(参见第5部分:启用系统工程)。如果逻辑架构模型成为其自身权利的终点，或者与主要生命周期活动断开连接，这种情况就会加剧。这可以通过使用抽象语言或符号、细节级别、花费的时间或过于复杂的最终架构来实现，而最终架构与创建它的目的并不匹配。如果架构的语言、范围和及时性与问题利益攸关方或解决方案提供者不匹配，他们就很容易忽略它。下面两部分将描述有助于避免与逻辑架构模型相关的问题的关键缺陷和良好实践。

4.1陷阱

表1提供了在开发逻辑架构时遇到的一些关键缺陷。

表1。逻辑架构开发的缺陷。

陷阱	描述
问题的相关性	逻辑架构模型应该与任务分析产生的操作场景相关联。
架构模型的输入	包括一组系统需求和实例，在这些需求和实例中，它们没有解决正确的架构级别。其结果是，架构师允许将需求放在一边，并使用他或她通过输入理解的内容来发明解决方案。
分解太深	许多架构初学者经常犯的一个错误是:将功能分解得太深，或者在场景中或当前的功能架构模型中有太多的功能和输入/输出流系统的块。
没有将输入和输出与功能一起考虑	一个常见的错误是只考虑功能支持的操作并分解它们，而忘记了输入和输出，或者考虑它们太晚了。输入和输出是一个功能不可分割的部分。
只考虑功能的静态分解	静态功能分解是最小的功能架构模型任务，并回答了基本问题，“这是如何完成的?”静态分解的目的是为了方便对功能列表的管理或导航。只有在场景已经创建并且逻辑架构接近完成时，才应该建立静态分解。
混合治理、管理和操作	治理(策略监控)、管理(战术监控)和基本操作通常混合在复杂系统中。逻辑架构模型应该处理行为架构模型和当前架构模型。

4.2实践证明

表2提供了从参考资料中收集的一些经过验证的实践。

表2。经过验证的逻辑架构开发实践。

实践	描述
构成功能场景	在构成功能分解树之前，必须对系统的行为建模，建立功能场景，并将功能分解为子功能场景。
分析与合成循环	当面对一个包含大量功能的系统时，应该尝试在标准的帮助下将功能集成为更高的功能抽象级别。不要只进行分析;相反，进行小的分析(分解)和合成周期。使用场景的技术包括这种设计实践。
交替的功能和行为视图	功能(动作动词;如。“移动”)及其执行状态/操作模式(例如:“移动”)是两个相似和称赞的观点。利用这一点来考虑系统的行为视图，该视图允许从一种操作模式转换到另一种操作模式。
创建一个场景的顺序功能	在创建功能场景时，首先建立功能的(控制)流，然后添加输入和输出流，最后添加用于同步的触发器或信号，这样效率更高。