2.4 软件架构设计的鸟瞰

2.4软件架构设计的鸟瞰

正如在引言中已经解释的那样，需求工程和架构设计是成功软件开发的两个关键因素。在这些领域中，出现不理想的开发结果的风险特别高，这就是为什么它们也为风险最小化和整体优化提供了最大的潜力。 孤立地处理这两个领域是不够的。相反，如果需求工程和架构设计要相互产生积极影响，确保它们的一致集成是至关重要的。所谓的双峰模型（参见[Nus01]）强调了这种关系，并要求需求工程和架构设计进行迭代协作，如图 2 - 14 所示。

图2-14双峰模型[Nus01]

只有当有了初始的高级架构设计时，才能实际评估需求所涉及的工作量的影响。如果基于高级架构设计评估的工作量呈现给客户，他们放弃某些需求的情况并不少见。然而，现有的设计替代方案可以向负责指定需求的人员表明，这些需求定义得不够精确（另见[HM + 07]）。

2.4.1软件架构设计的目标和功能

软件架构设计的核心任务是找到一种设计方法，通过该方法，需求工程定义的功能和非功能需求在完全设计的解决方案中得以实现。然而，正如图 2 - 14 所示的双峰模型所表明的，这种方法并非是一条单行道。

相反，这个过程涉及到需求工程的“需求列表”和软件架构师现有的解决方案、构建模块和其他架构工件库存之间的持续妥协。如图 2 - 15 所示，这种方法意味着软件架构师与相关的利益相关者（如需求工程师、客户、用户、开发人员、测试人员或管理员）协调制定软件系统的构建计划。

图2-15The软件架构师的长征

由于新系统或系统增强不应孤立地处理，还必须考虑到与其他系统的接口、受影响的组织、执行平台和实现基础设施。架构师必须考虑并共同设计来自四个相邻区域（见图 2 - 13）的接口、需求和约束。

架构师还必须考虑上述系统和相邻区域的整个生命周期。架构总是意味着对支持元素进行投资，以便在其他地方实现灵活性和可扩展性。然而，这需要考虑相应的生命周期；否则，这些投资可能不安全。

2.4.2软件架构设计概述

软件架构不是闭门造车开发出来的，需要项目中涉及的众多方面进行团队合作。因此，有必要在当前项目及其周边环境中就软件架构的组成部分和非组成部分达成共识。这包括对“接口”或“构建模块”等最重要术语的通用命名法。

如图 2 - 13 所示，架构师不仅要考虑与需求工程的接口，还要考虑与软件开发中涉及的其他学科和角色的接口。软件架构师从这些周边区域的条件、约束和需求出发设计架构，从而定义解决方案的关键方面，如构建模块结构和交互模式。孤立地看，架构设计过程不是顺序进行的。甚至“迭代方法”这个术语也不足以充分描述架构设计过程的性质。该过程中涉及的各个任务无法有意义地排成线性序列。相反，如图 2 - 16 所示，我们将架构设计细分为四个同等权重的活动：

图2-16软件架构设计中所涉及的迭代和增量步骤

• 需求和约束的分析 架构分析的核心任务是在其他周边区域（参考图 2 - 13）的背景下，分析来自需求工程的目标、约束和功能（特别是非功能需求）。这必须包括对需求的质量、灵活性（利益相关者对变更持开放态度）和易变性（由于外部影响随时间的变化）的分析。必须识别需求中的差距（见[HNS99]）。特别是对于非功能需求，通常有改进的空间，因为负责指定需求的人往往认为它们是不言而喻的。项目中所有相关方——尤其是设计师和开发人员——必须对架构风格和技术基础设施有初步的理解。这是系统的核心架构隐喻。

• 架构视图和技术概念的开发 在这里，架构会被更详细地开发。特别是不同架构级别（功能和技术级别——见图 2 - 13）的基于视图的描述也在此进行。目标是将功能需求分解到相应的功能架构级别，并在技术架构级别为非功能需求的相关方面设计和记录适当的横切解决方案构建模块（也见第 4 章）。同时，必须考虑架构风格和技术基础设施所给出的基本解决方案框架。

• 架构和设计决策的评估 开发的架构必须进行质量保证。这里可以使用各种方法，从各种审查技术到技术原型和测试，再到分析和评估。这里的关键方面是从需求中推导特定场景，以确保所得架构的质量（也见第 5 章）。

• 实施支持和审查 软件架构向项目中所有相关方的沟通的重要性常常被低估。只有当所有相关方——从开发人员到客户——都理解并接受了软件架构，它才能成功实现并达到预期效果。软件架构的沟通方式当然必须让接收者能够理解。这意味着向客户解释架构的详细程度与向开发人员解释的不同。这个过程不是单向的，而是一个相互学习和理解的过程。在实现过程中，继续与项目相关方讨论架构，并继续识别任何未解决的问题、改进的潜力、错误和失误以及进一步发展的方法。

还应基于这些概念建立有效的工具支持。这确保了对软件架构设计所涉及的各个活动领域的最佳支持——例如，需求的分析和管理、架构模型和文档的处理、质量保证以及沟通。对于这些单独的任务领域，已经存在自主的工具解决方案（见第 6 章）。这些独立的工具必须尽可能无缝地集成，以确保架构师能够有效地使用它们。由于设计过程不是顺序的，而是迭代的、增量的（甚至是并发的），因此弥合各个工具之间的差距尤为重要。

2.4.3设计中活动和抽象层次之间的相互作用

正如已经解释过的，软件架构设计过程中所涉及的各个活动不能线性排列。它们同等重要，软件架构师必须根据当前项目情况给予足够的关注。架构设计是图 2 - 16 中所示活动之间的持续相互作用，这些活动包括： • 需求和约束的分析 • 架构视图和技术概念的开发 • 架构和设计决策的评估 • 实施支持和审查

在架构设计过程中，软件架构师按照适合项目需求和背景的顺序开展这四个活动。这种迭代和增量的活动相互作用与图 2 - 13 中所示的自上而下和自下而上的抽象级别和视角的变化相关： • 周边区域的要求和约束 • 具有抽象层次的软件架构，例如: o 架构风格和技术基础设施 o 功能和技术架构级别 • 程序设计与实现

这样，我们可以从周边区域的条件、约束和需求的最高抽象级别，通过软件架构中的抽象级别（架构风格和技术基础设施，加上功能和技术架构级别），切换到最底层的抽象级别，即软件程序本身、程序的设计及其实现。因此，架构设计过程是抽象级别内连续的自上而下和自下而上的流动，以及互动和增量执行的活动的持续变化。这在图 2 - 17 中有所说明。

在这个过程中，项目设置和约束定义了架构的约束条件。反过来，架构设计提供有关技术项目风险的数据和规划信息。

需求工程描述了来自对系统负责的人员的架构设计的功能性和非功能性需求。如上所述，这不是单向的，架构设计也提供关于实现需求的可行性及其对需求工程的影响的反馈。

在架构设计过程中，部分或完全可用的技术基础设施（例如服务器基础设施、操作系统、编程语言的要求和运营组织）也必须被考虑到。特别是与运营的接口经常被忽视，这可能会在系统部署期间导致重大问题。而且，这再次不是单向的。架构设计可以产生新的技术基础设施需求，例如服务器环境的进一步扩展或额外中间件的集成。

最后，架构设计为详细设计和编程提供规范。然而，这里也需要信息的回流。在软件架构的实现过程中可能会出现意外问题，如果这些问题没有传达给软件架构师，而是实施了一个所谓的简单解决方案，这可能会破坏整个架构。因此，与软件架构师讨论这些问题，并共同开发一个可能导致架构更改的解决方案是很重要的。

图2-17软件架构设计过程概述

2.4.4A软件架构师的任务和与其他角色的关系

架构师的任务是根据功能性和非功能性需求，并考虑周边区域的需求和约束，为系统开发一个蓝图。随后的实现、维护、支持和增强都基于这个蓝图。这需要开发一个完整且简洁的架构描述。架构描述一方面作为沟通和讨论的平台，另一方面作为设计和实施计划。如图 2 - 18 所示，架构师必须为软件开发项目中几乎所有涉及的角色提供大量接口。

图2-18The软件架构师与邻近的角色

• 交流和讨论平台 基于架构，架构师向需求工程师、客户，可能还有用户展示需求的可行性。在此过程中，架构师通过关联、确定优先级和反思功能性和非功能性需求提供支持。他能识别矛盾和差异，最终确保需求能够实现。架构师确定整合现有解决方案和系统的方式，并使需求与现有系统架构和硬件对齐。他开发、评估和评估替代解决方案。最后，基于软件架构，架构师为项目经理提供项目和迭代规划的建议，并支持风险分析和缓解，从而为工作结构和任务的定义提供支持。

• 设计和实施计划 架构师是系统开发人员的中心联络点。他定义系统的构建块以及它们的接口和交互模式。他必须鼓励整合新技术和创新的解决方案，并与开发人员讨论。他负责开发、引入、培训和审查编程指南。他协助开发人员开发原型和示例解决方案，并加速现有（部分）实现的重用。他解释架构，提供开发规范，传递经验，并进行代码审查。他还支持测试人员。在理想情况下，他甚至为测试特定架构目标定义测试条件和具体测试用例。他协助定义测试序列和依赖关系。最后，他是与架构相关的故障和错误报告的联络点。他也是运营人员、安全专家等组织角色的中心联络点。