系统架构 活动的目的是根据逻辑上相互关联和一致的原则、概念和属性来定义一个全面的解决方案。 解决方案架构具有尽可能满足由一组系统需求(可追溯至任务/业务和利益相关者需求)和生命周期概念(例如,运营、支持)所表达的问题或机会的特性、属性和特性并且可以通过技术实现(例如,机械、电子、液压、软件、服务、程序、人类活动)。
系统架构是抽象的、面向概念化的、全局性的,并且专注于实现系统的任务和生命周期概念。 它还侧重于系统和系统元素的高级结构。 它解决了利益系统的架构原则、概念、属性和特征。 它也可以应用于一个以上的系统,在某些情况下,形成了类似或相关系统的类或族的通用结构、模式和一组要求。
一般概念和原则
结构的概念
SEBoK认为系统工程涵盖了系统创建的所有方面,包括系统架构。
系统架构的大多数解释都是基于结构的相当无形的概念(即元素之间的关系)。一些作者限制了建筑结构的类型;例如,限制自己的功能和物理结构。最近的实践已经扩展了对结构的考虑,包括行为、时间和其他维度。
ISO/IEC/IEEE 42010系统和软件工程——体系结构描述(ISO 2011)提供了一个有用的体系结构描述,它考虑了涉众的关注点、体系结构观点、体系结构视图、体系结构模型、体系结构描述以及整个生命周期的体系结构。
关于系统架构特性的讨论可以在(Maier和Rechtin 2009)中找到。
INCOSE英国建筑工作组(Wilkinson et al. 2010, Wilkinson 2010)描述了一种试图开发和应用系统方法来表征系统工程中的建筑信仰系统的尝试。
系统架构描述
架构框架包含标准化的视点、视图模板、元模型 、模型模板等,这些有助于开发系统架构的视图(参见 架构框架的示例)。 ISO/IEC/IEEE 42010 (ISO 2011) 规定了与架构描述相关的架构框架、视点和视图的规范性特征。 一个观点解决了一个特定的利益相关者关注点(或一组密切相关的关注点)。 视点指定了用于开发系统架构以解决该关注点(或关注点集)的模型类型,模型应该生成的方式,以及模型如何关联并用于组成视图。
逻辑和物理模型(或视图)通常用于表示系统架构的基本方面。 必须使用其他互补的观点和观点来表示系统架构如何解决利益相关者的关注,例如成本模型、流程模型、规则模型、本体模型、信念模型、项目模型、能力模型、数据模型等。
原则和启发式分类
工程师和建筑师混合使用数学原理 和 启发式方法(启发式方法是从经验中吸取的教训,但未经数学证明)。 当通过系统要求识别和定义问题时,原则和启发式方法可能会也可能不会解决它。 系统视图/模型中使用的原则和启发式可以根据使用这些系统视图/模型的域进行分类,如下所示:
- 静态域 涉及分解为系统和系统元素的 SoI 的物理结构或组织。 它处理分区系统、系统元素和物理接口。
- 动态域 涉及逻辑架构模型,特别是系统行为的表示。 它包括对功能(即输入流到输出流的转换)和系统功能之间以及外部对象或系统功能之间的相互作用的描述。 它考虑了对启动或停止系统功能执行的事件的反应。 它还涉及系统的有效性(即性能、操作条件)。
- 时域 涉及系统功能执行的时间不变性水平。 这意味着每个功能都根据循环或同步特性执行。 它包括决策级别,这些决策级别是某些功能行为的异步特征。
- 环境领域 涉及促成因素(生产、后勤支持等),还涉及 系统对自然灾害或威胁作出反应的生存能力,以及系统对内部潜在危险作出反应的完整性 。 这包括,例如,气候、机械、电磁和生物方面。
可以在 (Maier and Rechtin 2009) 中找到更详细的启发式分类。
从系统需求过渡到逻辑和物理架构模型
该方法的目的是从系统需求(从供应商/设计人员的角度表示问题,尽可能独立于技术)通过逻辑架构的中间模型将 逻辑 构模型的元素分配给系统元素候选物理架构模型。
(系统需求和逻辑架构模型有许多共同点,因为它们都是按功能线组织的,独立于实现。一些作者(Stevens 等人,1998)甚至将两者混为一谈,这简化了同时处理多个意见。是否采用这种方法取决于开发组织的具体实践以及合同边界的划分位置。)
根据性能标准和非功能性要求选择设计决策和技术解决方案,例如运行条件和生命周期约束(例如,环境条件、维护约束、实现约束等),如图 1 所示。 创建中间模型,例如逻辑架构模型,有助于根据系统要求验证系统的功能、行为和时间属性,这些要求在系统、物理接口或技术层的生命周期内没有重大技术影响,无需完全质疑系统的逻辑功能。
图 1. 在架构和设计期间使用中间逻辑架构模型(Faisandie 2012)。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。
逻辑和物理架构模型开发之间的迭代
正如系统需求中所讨论的,综合解决方案所采用的确切方法 通常取决于系统是已了解的产品或服务的演变,还是新的和前所未有的解决方案(请参阅综合可能的解决方案)。
无论采用何种方法,架构活动都需要在逻辑架构模型开发和物理架构模型开发之间进行多次迭代,直到逻辑和物理架构模型一致并提供必要的详细程度。 最初的架构活动之一是创建基于 (功能的)名义场景的逻辑架构模型。物理架构模型用于确定可以执行系统功能的主要系统元素并对其进行组织。
随后的逻辑架构模型迭代可以考虑到系统元素的功能分配以及来自物理解决方案选择的派生功能。 它还通过引入以前未考虑的其他场景、故障分析和操作要求来补充初始逻辑架构模型。 派生功能分配给系统元素; 反过来,这会影响物理架构模型。
其他迭代的重点是生成解决方案的完整且一致的逻辑和物理视图。
在系统设计期间,技术选择可能会带来新的功能、新的输入/输出和控制流以及新的物理接口。 这些新元素可以导致创建新的系统需求,称为 派生需求。
接口的概念
接口的概念 是定义系统架构时要考虑的最重要的概念之一。 接口的基本方面是功能性的,并被定义为功能的输入和输出。 由于功能由物理元素(系统元素)执行,功能的输入/输出也由物理元素承载; 这些被称为物理接口。 因此,在接口的概念中考虑了功能和物理方面。 对接口的详细分析显示,功能 “发送”位于一个系统元素中,功能 “接收”位于另一个系统元素中,功能 “携带”由支持输入/输出流的物理接口执行(参见图 2)。
图 2. 完整的界面表示(Faisandie 2012)。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。
在系统元素之间复杂交换的背景下,特别是在软件密集型系统中,协议被视为承载数据交换的物理接口。 然而,输入/输出流可以包括除数据之外的许多其他交换,例如能量。
新兴属性
系统的总体架构可能具有设计属性或操作效果,这些属性或操作效果来自 系统元素之间的排列和交互,但它们可能不是任何单个元素的属性,也可能不是针对整个系统的属性。
工程系统 的元素 在它们之间相互作用,可以产生理想或不理想的现象,例如抑制、干扰、共振或任何特性的增强。系统的定义包括对系统元素 之间相互作用的分析, 以防止不良属性并加强所需属性。
从系统中产生的属性可以有多种来源,从单个系统元素到多个元素之间的相互作用(Thome,B. 1993)。 一些作者使用术语 紧急属性来识别从系统中出现的任何属性,而其他人可能将此称为协同作用和保留紧急属性,以解释在系统开发期间未充分考虑但在运行期间出现的意外属性或属性。 SEBoK 第 2 部分讨论了涌现的系统概念(请参阅涌现 )。
表 1. 属性和紧急属性。 (SEBoK 原创)
广泛的属性类别 | 描述和示例 |
本地财产 |
该属性位于单个系统元素中——例如,容器的容量就是系统的容量。 |
累积系统属性 |
该属性位于多个系统元素中,并通过元素属性的简单求和获得 - 例如,系统的权重来自其系统元素的权重之和。 |
由架构和/或交互修改的紧急属性。 |
该属性存在于多个系统元素中,并通过它们的相互作用进行修改——例如,系统的可靠性/安全性取决于每个系统元素的可靠性/安全性以及它们的组织方式。 架构步骤通常对于满足系统要求至关重要。 |
由交互创建的紧急属性 |
该属性不存在于系统元素中,仅来自它们的相互作用——例如机电界面、电磁、静电等。 |
受控紧急财产 |
在离开系统之前控制或抑制属性——例如:通过添加负载消除不平衡; 减振器减振。 |
物理架构设计将包括识别可能的协同作用和紧急属性,并在逻辑或物理架构模型中包含派生的功能、组件、安排和/或环境约束,以在可接受的范围内避免、减轻或限制它们。 当相应的 派生需求影响利益的系统 (SoI) 时,应将它们添加到系统需求基线中。 这可以通过系统工程师的知识和经验或通过应用统模式来实现. 然而,在架构开发过程中,通常不可能预测、避免或控制所有出现的属性。 只有通过系统定义、 系统实现和系统部署和使用 之间的迭代,才能充分处理突发事件的后果(Hitchins,2008)
在架构和设计过程中应用了涌现的概念,以突出必要的派生功能; 此外,内部涌现通常与复杂性的概念相关联。 复杂自适应系统 (CAS) 就是这种情况,其中各个元素独立行动,但根据共同的约束和目标共同行动(Flood 和 Carson 1993)。 CAS 的例子包括:一个国家或国家集团内的全球宏观经济网络、股票市场、复杂的跨境控股公司网络、制造企业、地缘政治组织等(Holland, J. 1999 和 2006)。
系统元素的重用
系统工程师经常利用现有的系统元素。 这种重用约束必须被识别为系统需求,并在架构和设计过程中仔细考虑。 可以区分涉及系统元素重用的三种一般情况,如表 2 所示。
表 2. 系统元素重用案例(Faisandie 2012)。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。
重用案例 | 操作和评论 |
案例 1: 系统元素的要求是最新的,无需修改即可重复使用。 |
- 要定义的系统架构必须适应重用系统元素的边界、接口、功能、有效性和行为。
- 如果系统元素不适应,成本、复杂性和风险可能会增加。
|
案例 2: 系统元素的要求是最新的,将在可能的修改后重新使用。 |
- 要定义的系统架构足够灵活,以适应重用系统元素的边界、接口、功能、有效性和行为。
- 重用系统元素的设计,包括其测试报告和其他文档,将被评估并可能重新设计。
|
案例 3: 需求不是最新的或不存在。 |
- 有必要对系统元素进行逆向工程,以识别其边界、接口、功能、性能和行为。 这是一项困难的活动,因为重用系统元素的现有文档可能不可用或不充分。
- 逆向工程在时间和金钱方面都很昂贵,并带来了更大的风险。
|
有一个普遍的想法是重用是 免费的; 但是,如果没有正确处理,重用可能会带来对项目来说可能很重要的风险(成本、期限、复杂性)。
过程方法
目的
系统架构过程的目的是生成系统架构备选方案,选择一个或多个能够构建利益相关者关注点并满足系统要求的备选方案,并在一组一致的视图中表达这一点。 (ISO 2015)。
应该注意的是,下面的架构活动与系统定义和概念定义活动重叠。 特别是,运营和业务环境的关键方面,以及因此的某些利益相关者的需求,强烈影响着架构开发和描述所采用的方法。 此外,架构活动将推动选择并适应已选择 的任何解决方案综合方法。
进程的活动
在此过程中执行的主要活动和任务包括:
1.初始化系统架构的定义
- 了解需要系统的环境/使用环境,以便深入了解利益相关者的关注点。 为此,分析相关的市场、行业、利益相关者、企业、业务、运营、使命、法律和其他有助于理解可以指导系统架构视图和模型定义的观点的信息。
- 捕获跨越系统生命周期阶段的利益相关者关注点(即期望或约束)。 这些关注点通常与与阶段相关的系统的关键特征有关; 应将它们转化为或纳入系统要求。
- 标记处理会影响架构元素定义的操作条件(例如,安全、安保、可靠性、人为因素、接口、环境条件)和生命周期约束(例如,维护、处置、部署)的系统需求。
- 建立架构路线图和策略,其中应包括方法、建模技术、工具、对任何支持系统、产品或服务的需求、过程要求(例如,测量方法和方法)、评估过程(例如,审查和标准)。
- 计划支持产品或服务的获取(需求、要求、采购)。
2. 定义必要的架构观点
- 根据确定的利益相关者关注点,确定可能支持模型和视图开发的相关架构观点和架构框架。
3. 开发候选架构模型和视图
- 使用相关的建模技术和工具,并结合相关利益者需求和需求过程以及系统需求过程,确定利益的系统上下文,包括与外部环境元素的边界。 该任务包括识别利益系统与外部元素的关系、接口或连接、交换和交互。 该任务能够定义或理解其使用环境中的预期操作场景和/或系统行为。
- 定义架构实体(例如,功能、输入/输出流、系统元素、物理接口、架构特征、信息/数据元素、容器、节点、链接、通信资源等),以解决不同类型的系统需求(例如、功能要求、接口要求、环境要求、运行条件[可靠性、人为因素等]、约束[物理尺寸、生产、维护、处置])。
- 将架构实体与与利益系统架构的决策相关的概念、属性、特征、行为、功能和/或约束相关联。 这产生了架构特性(例如,通用性、模块化、可操作性、效率、简单性)。
- 选择、调整或开发系统候选架构的模型,例如逻辑和物理模型(请参阅 逻辑架构模型开发和 物理架构模型开发)。 有时使用逻辑模型和物理模型既没有必要也不够。 要使用的模型是最能解决关键利益相关者关注的模型。
- 从候选架构的模型中,组成与利益相关者关注点和关键或重要要求相关的视图。
- 定义由架构实体的必要实例(例如,功能、接口)和结构配置(例如,约束、操作条件)引起的派生系统需求。 使用系统需求定义过程来定义和形式化它们。
- 检查模型和视图的一致性并解决任何已识别的问题。 ISO/IEC/IEEE 42010, 2011 可用于此。
- 如果建模技术和工具允许,通过执行或仿真来验证和验证模型。 在可能的情况下,使用设计工具检查可行性和有效性,和/或实施部分模型,或使用可执行架构原型或模拟器。
4. 将系统架构与系统设计联系起来
- 定义反映架构特征的系统元素(当架构旨在与设计无关时,这些系统元素在设计发展之前可能是概念性的)。 为此,对系统元素进行分区、对齐和分配体系结构特征和系统要求。 建立系统设计和演进的指导原则。 有时,使用这些概念系统元素创建“参考架构”作为传达架构意图和检查设计可行性的手段。
- 为架构的详细程度和理解所必需的接口定义接口。 这包括系统元素之间的内部接口和与其他系统的外部接口。
- 确定适用于系统元素的设计属性 以满足架构特性。
- 对于构成系统的每个系统元素,开发与设计属性和系统要求对系统元素的分配、对齐和划分相对应的要求。 为此,请使用相关利益者需求和需求定义流程以及系统需求定义流程。
5. 评估架构候选并选择一个
- 使用架构评估标准评估候选架构。 这是通过应用系统分析、测量和 风险管理 流程来完成的。
- 选择首选架构。 这是通过应用决策管理 过程来完成的。
6. 管理选定的架构
- 建立并维护架构、架构框架、观点、模型类型和架构模型的备选方案和决策之间的所有选择的基本原理。
- 管理架构描述的维护和演变,包括模型和视图。 这包括一致性、完整性、环境或上下文变化引起的变化,以及技术、实施和操作经验。 分配和可追溯性矩阵用于分析对架构的影响。 本过程在系统演进发生的任何时候执行。
- 建立架构治理的方法。 治理包括角色、职责、权限和其他控制功能。
- 协调对架构的审查以达成利益相关者的一致意见。 利益相关者需求和系统需求可以作为参考。
工件、方法和建模技术
这个过程可能会创建几个工件,例如系统架构描述文档和系统论证文档(可追溯性矩阵和架构选择)。
这些工件的内容、格式、布局和所有权可能会因创建它们的人和使用它们的域而异。 过程活动的输出应涵盖本文第一部分中确定的信息。
实际考虑
缺陷
表 3 提供了在规划和执行系统架构时遇到的一些关键缺陷。
表 3. 系统架构定义的缺陷。 (SEBoK 原创)
缺陷 | 描述 |
问题相关性 |
如果在没有利益相关者关注的情况下开发架构,或者无法理解并与他们的问题相关联,则可能会失去利益相关者社区的投资。 |
系统元素的重用 |
在某些项目中,出于工业目的,现有产品或服务很早就被强加于利益相关者需求或系统需求中的架构/设计约束,而没有充分注意它们也包含在系统使用的新环境. 最好从一开始就朝着正确的方向努力。 首先定义系统,注意其他要求,然后查看是否有任何合适的非开发项目 (NDI) 可用。 不要从一开始就强加一个系统元素,这会减少交易空间。 正确的重用过程包括在每个使用上下文中定义可重用的系统元素。 |
成熟的实践
表 4 提供了从参考文献中收集到的一些经过验证的实践。
表 4. 系统架构定义的成熟实践。 (SEBoK 原创)
实践 | 描述 |
新兴物业 |
控制系统或系统元素之间交互的涌现属性; 获得所需的协同特性并控制或避免不良行为(振动、噪音、不稳定性、共振等)。 |
|