摘要
本文主要介绍了几种软件架构设计相关的概念和方法。包括C2架构风格的规则，模型驱动架构（MDA）的起源、目标、核心模型及各模型之间的关系；软件架构复用的概念、历史发展、维度、类型及相关过程；特定领域架构（DSSA）的定义、基本活动及产出物、类型等。
1. 软件架构概念
架构的本质
- 软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
- 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
架构的作用
- 软件架构是项目干系人进行交流的手段。
- 软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
- 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构设计是【降低成本】、【改进质量】、【按时和按需交付产品】的关键因素。架构设计就是需求分配，即将满足需求的职责分配到组件上。
2. 软件架构设计与生命周期
2.1. 软件设计中4+1 视图是哪些？
2.1.1. 逻辑视图（Logical View）
- 目的：描述系统的功能需求和静态结构，关注“系统做什么”。
- 核心内容：
-
- 类图（Class Diagram）
- 用例图（Use Case Diagram）
- 对象图（Object Diagram）
- 应用场景：定义模块划分、类职责、接口设计等。例如，在电商系统中，定义用户、订单、商品等核心类及其关系。
- 示例：（用户类与订单类关联，订单类包含商品列表）
2.1.2. 开发视图（Development View）
- 目的：描述系统的代码结构，关注“开发者如何组织代码”。
- 核心内容：
-
- 组件图（Component Diagram）
- 包图（Package Diagram）
- 构建工具链（如 Maven/Gradle 配置）
- 应用场景：划分模块边界、依赖管理、代码复用。例如，将电商系统分为用户服务、订单服务、支付服务等独立模块。
- 示例：（用户服务模块依赖数据库访问模块）
2.1.3. 进程视图（Process View）
- 目的：描述系统的运行时行为，关注“系统如何动态协作”。
- 核心内容：
-
- 活动图（Activity Diagram）
- 状态图（State Diagram）
- 线程/进程交互图
- 应用场景：分析并发、同步、通信机制。例如，电商系统下单时的库存扣减与支付异步处理流程。
- 示例：（用户下单后触发库存检查进程和支付进程并行执行）
2.1.4. 物理视图（Physical View）
- 目的：描述系统的物理部署和硬件拓扑，关注“系统如何运行在真实环境中”。
- 核心内容：
-
- 部署图（Deployment Diagram）
- 网络拓扑图
- 服务器配置（如负载均衡、数据库集群）
- 应用场景：
设计服务器架构、数据库分片、缓存策略。例如，电商系统部署在 AWS 上，使用 RDS 数据库和 CDN 加速静态资源。 - 示例：（用户请求通过负载均衡器分发到多台 Web 服务器）
2.1.5. +1 场景视图（Use Case View）
- 目的：通过典型场景串联其他视图，关注“系统如何应对用户需求”。
- 核心内容：
-
- 用例图（Use Case Diagram）
- 用户故事（User Story）
- 场景描述（Scenario Description）
- 应用场景：验证架构设计是否满足关键业务场景。例如，电商系统的“下单支付”场景需覆盖库存扣减、支付成功回调等流程。
- 示例：（用户登录→选择商品→提交订单→支付→生成订单）
2.2. 架构描述语言ADL（）
3. 基于架构的软件开发方法（ABSD）
- ABSD方法是架构驱动，即强调由业务【商业】、质量和功能需求的组合驱动架构设计。
- ABSD方法有三个基础。
-
- 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；
- 第二个基础是通过选择架构风格来实现质量和业务需求；
- 第三个基础是软件模板的使用。
- 视角与视图：从不同的视角来检查，所以会有不同的视图。
- 用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。
4. 软件风格（五大架构风格）
4.1. 数据流风格
4.2. 返回调用风格
4.3. 独立构建风格
4.4. 虚拟机风格
4.5. 数据为中心风格
4.6. 闭环控制架构
4.7. C2风格
5. 模型驱动架构（MDA）
6. 软件架构复用（机会复用、系统复用）
垂直式重用指在同一应用领域或行业内重用软件组件，专注于解决特定领域的问题。这类组件通常针对某一行业的共性需求设计，例如金融、医疗、制造业等。
水平式重用指在不同应用领域间共享通用组件，强调跨行业的普适性。这类组件不依赖特定业务逻辑，可被广泛复用。
7. 特定领域架构（DSSA）
DSSA的基本活动包括：
- 领域分析：捕获领域需求和约束。
- 领域设计：开发领域架构。
- 领域实现：构建可重用资产（如代码、文档）。
- 领域评估：验证架构的可行性和优化。
选项中的“领域建模”和“架构设计”属于领域设计的一部分，而非独立活动。
8. 软件架构评估（质量属性）
功能性指软件系统满足用户显性需求和隐性需求的能力，即“软件是否做了正确的事”。它是软件的基础能力，直接体现软件的核心价值。
可变性（也称可修改性）指软件系统适应需求变化或环境变化的能力，即“软件能否低成本、高效地被修改”。它是软件长期维护和演进的关键。
互操作性指软件与其他系统、组件或设备协同工作的能力，即“软件能否与外界有效交互”。
9. 软件架构评估（敏感点、权衡点、风险点）
敏感点指架构中对某一质量属性（如性能、安全性）影响最大的设计决策。修改敏感点会显著改变系统的某项属性表现。核心作用：定位对特定质量属性敏感的模块或组件，便于针对性优化。
例子
- 性能敏感点：数据库查询模块（若设计不当会导致响应延迟）。
- 安全性敏感点：身份认证模块（漏洞可能引发系统级安全风险）。
实际应用
- 在性能优化时，优先重构数据库查询模块（敏感点）。
- 安全审计时，重点检查认证模块的漏洞。
权衡点指架构中需要牺牲某一质量属性以提升另一属性的设计决策。这类决策通常涉及多目标矛盾，需通过权衡选择最优方案。核心作用：帮助团队在竞争性需求间做出合理取舍。
- 性能 vs 安全性：使用加密通信会降低传输速度，需权衡安全需求与性能要求。
- 可扩展性 vs 开发成本：微服务架构提高扩展性，但增加部署和维护成本。
实际应用
- 在电商系统中，选择缓存策略时需权衡数据一致性（性能）与实时性（功能）。
- 在物联网场景中，权衡边缘计算（低延迟）与云端集中处理（统一管理）。
风险点指架构中存在潜在技术或实施风险的模块或决策，可能引发失败或额外成本。核心作用：提前识别高风险环节，制定缓解措施。
- 技术风险：采用未经验证的新框架（如实验性数据库技术）。
- 集成风险：第三方服务依赖（如支付网关接口不稳定）。
- 对实验性技术进行原型验证（POC）。
- 制定第三方服务的降级预案（如熔断机制）。
非风险点指架构中已充分验证、技术成熟或风险极低的模块或决策，通常无需额外关注。
核心作用：减少评估冗余，聚焦关键问题。
- 使用成熟的关系型数据库（如MySQL）存储交易数据。
- 采用标准化的RESTful API进行内部服务通信。
- 优先复用已有稳定组件（如企业级中间件）。
- 避免对低风险模块过度设计。
10. 基于场景的评估方法（SAAM、ATAM、CBAM）
ATAM（架构权衡分析方法）是一种架构评估方法，关注高层设计决策（如非功能需求、架构风格等），而非具体的代码实现或代码质量评估。
ATAM的核心目标是评估架构对需求（尤其是非功能需求）的满足程度及权衡分析，而非验证需求本身的准确性。需求准确性通常属于需求工程范畴。
ATAM通过场景分析、架构决策评估和利益相关者讨论等方式进行，不涉及系统测试（如功能测试或性能测试）。
ATAM是一种定性分析方法，依赖专家经验和主观判断，缺乏定量指标，因此不是一种精确的工具，更适合用于权衡和沟通而非绝对评估。
11. 构件与中间件技术
12. 层次架构换设计与理论实践
12.1. MVC 架构风格
12.2. MVP架构风格
12.3. MVVM 架构风格
12.4. RIA 架构风格
13. 物联网分层
14. 微服务
15. 云计算
16. 云原生
17. 大型网站架构演化
扫一扫
9232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
