软件架构与设计简介
系统架构描述了其主要组件、它们之间的关系(结构)以及它们如何相互作用。软件架构与设计包括多种因素,例如业务战略、质量属性、人员动态、设计和 IT 环境。

我们可以将软件架构与设计分为两个不同的阶段:软件架构和软件设计。在架构中,非功能性决策由功能需求决定和分离。在设计中,功能需求得以实现。
软件架构
架构是系统的蓝图。它提供了一种抽象来管理系统复杂性并在组件之间建立通信和协调机制。
它定义了一个结构化解决方案来满足所有技术和操作要求,同时优化性能和安全性等常见质量属性。
此外,它涉及一系列与软件开发相关的组织重要决策,每个决策都会对最终产品的质量、可维护性、性能和整体成功产生相当大的影响。这些决策包括 −
选择组成系统的结构元素及其接口。
这些元素之间协作中指定的行为。
将这些结构和行为元素组合成大型子系统。
架构决策与业务目标保持一致。
架构风格指导组织。
软件设计
软件设计提供了一个设计计划,描述了系统的各个元素、它们如何组合以及如何协同工作以满足系统的要求。制定设计计划的目标如下 −
与客户、营销和管理人员协商系统要求并设定期望。
在开发过程中充当蓝图。
指导实施任务,包括详细设计、编码、集成和测试。
它位于详细设计、编码、集成和测试之前,领域分析、需求分析和风险分析之后。

架构的目标
架构的主要目标是确定影响应用程序结构的需求。精心设计的架构可降低与构建技术解决方案相关的业务风险,并在业务和技术需求之间架起桥梁。
其他一些目标如下 −
公开系统结构,但隐藏其实施细节。
实现所有用例和场景。
尝试满足各种利益相关者的要求。
处理功能和质量要求。
减少所有权目标并提高组织的市场地位。
提高系统提供的质量和功能。
提高外部对组织或系统的信心。
局限性
软件架构仍然是软件工程中一门新兴学科。它具有以下局限性 −
缺乏表示架构的工具和标准化方法。
缺乏分析方法来预测架构是否会导致满足要求的实现。
缺乏对架构设计对软件开发重要性的认识。
缺乏对软件架构师角色的理解,利益相关者之间的沟通不畅。
缺乏对设计过程、设计经验和设计评估的理解。
软件架构师的角色
软件架构师提供技术团队可以为整个应用程序创建和设计的解决方案。软件架构师应具备以下领域的专业知识 −
设计专业知识
精通软件设计,包括面向对象设计、事件驱动设计等多种方法和方式。
领导开发团队并协调开发工作以确保设计的完整性。
应能够审查设计方案并进行权衡。
领域专业知识
精通正在开发的系统并规划软件演进。
协助需求调查过程,确保完整性和一致性。
协调正在开发的系统的领域模型定义。
技术专业知识
精通有助于系统实施的可用技术。
协调编程语言、框架、平台、数据库等的选择。
方法专业知识
精通可能在 SDLC(软件开发生命周期)期间采用的软件开发方法。
选择适当的开发方法,帮助整个团队。
软件架构师的隐藏角色
促进团队成员之间的技术工作并加强团队中的信任关系。
分享知识并拥有丰富经验的信息专家。
保护团队成员免受外部力量的干扰,这些力量会分散他们的注意力并降低项目的价值。
架构师的可交付成果
一套清晰、完整、一致且可实现的功能目标
系统的功能描述,至少有两层分解
系统的概念
系统形式的设计,至少有两层分解
时间概念、操作员属性以及实施和操作计划
确保遵循功能分解并控制接口形式的文档或流程
质量属性
质量是衡量卓越性或没有缺陷或瑕疵的状态的标准。质量属性是独立于系统功能的系统属性。
实施质量属性可以更轻松地区分好系统和坏系统。属性是影响运行时行为、系统设计和用户体验的总体因素。
它们可以归类为 −
静态质量属性
反映系统和组织的结构,与架构、设计和源代码直接相关。它们对最终用户不可见,但会影响开发和维护成本,例如:模块化、可测试性、可维护性等。
动态质量属性
反映系统在执行过程中的行为。它们与系统的架构、设计、源代码、配置、部署参数、环境和平台直接相关。
它们对最终用户可见,并且在运行时存在,例如吞吐量、稳健性、可扩展性等。
质量场景
质量场景指定如何防止故障成为故障。它们可以根据其属性规范分为六个部分 −
来源 − 产生刺激的内部或外部实体,例如人员、硬件、软件或物理基础设施。
刺激 − 到达系统时需要考虑的条件。
环境 −刺激在特定条件下发生。
工件 − 整个系统或其某个部分,如处理器、通信通道、持久存储、进程等。
响应 − 刺激到达后进行的活动,如检测故障、从故障中恢复、禁用事件源等。
响应测量 − 应测量发生的响应,以便测试需求。
常见质量属性
下表列出了软件架构必须具备的常见质量属性 −
类别 | 质量属性 | 描述 |
---|---|---|
设计质量 | 概念完整性 | 定义整体设计的一致性和连贯性。这包括组件或模块的设计方式。 |
可维护性 | 系统轻松进行更改的能力。 | |
可重用性 | 定义组件和子系统适合用于其他应用程序的能力。 | |
运行时质量 | 互操作性 | 系统或不同系统通过与外部方编写和运行的其他外部系统进行通信和交换信息而成功运行的能力。 |
可管理性 | 定义系统管理员管理应用程序。 | |
可靠性 | 系统持续运行的能力。 | |
可扩展性 | 系统在不影响系统性能的情况下处理负载增加的能力,或随时扩大的能力。 | |
安全性 | 系统防止超出设计用途的恶意或意外行为的能力。 | |
性能 | 指示系统在给定时间间隔内执行任何操作的响应能力。 | |
Availability | 定义系统功能正常且运行的时间比例。它可以作为预定义时间段内系统总停机时间的百分比来衡量。 | |
系统质量 | 可支持性 | 系统在无法正常工作时提供有助于识别和解决问题的信息的能力。 |
可测试性 | 衡量为系统及其组件创建测试标准的难易程度。 | |
用户质量 | 可用性 | 通过直观性定义应用程序满足用户和消费者要求的程度。 |
架构质量 | 正确性 | 负责满足系统的所有要求。 |
非运行时质量 | 可移植性 | 系统在不同计算环境下运行的能力。 |
完整性 | 使单独开发的系统组件能够正确地协同工作。 | |
可修改性 | 每个软件系统适应其软件变化的难易程度。 | |
业务质量属性 | 成本和时间表 | 系统成本与上市时间、预期项目寿命和遗留系统的利用率有关。 |
市场营销性 | 系统使用与市场竞争有关。 |