【从 0 开始学架构】学习笔记 Day4 “4+1”视图模型

一、模型

（1）模型

模型，领域“特定”问题的解决方案，是一个系统的完整抽象。

现实世界领域问题繁多，针对功能直接进行开发，不建模，不设计，最后，系统将变得庞大无序，难以开发和维护

（2）软件开发的本质

为了解决某个领域特定问题，从领域问题到计算机系统的映射

模型的关键：抽象

领域模型：对业务（领域问题）中的关键点和关键关系梳理和抽象

设计模型：对系统进行抽象，关键点抽象出来

（3）架构设计

架构师输出架构设计文档，针对利益相关方，统筹协调各自的关注点，进而获得相关方的支持，实现开发、测试、运维等相关工作的落地，直至最终实现系统上线运行

架构设计文档包含架构视图，架构视图体现相关方的关注点

二、4+1视图模型

1）定义

单一视图无法完整表达整体的架构，需要通过完整的视图集进行表达

IBM 的 RUP 将软件架构视图分为“4+1 视图”

软件架构＝{元素，形式，关系/约束}

2）组成

• 场景视图（Scenarios），描述用例场景，场景与所有视图都是相关的
• 逻辑视图（LogicalView），设计的对象模型
• 过程视图（ProcessView），捕捉设计的并发和同步特征
• 物理视图（PhysicalView），描述了软件到硬件的映射，反映了部署特性
• 开发视图（DevelopmentView），描述了在开发环境中软件的静态组织结构

（1）场景视图

本质：执行者通过系统能做什么事情

相关者：用户，设计和开发人员
视角：概括了架构上最重要的场景及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式

应用：用例图

（2）逻辑视图

本质：系统有哪些功能，以及它们的接口、职责和交互是怎么样的

相关方：客户，用户，开发组织管理者
视角：系统的功能元素，以及它们的接口，职责，交互
主要元素：系统，子系统，功能模块，子功能模块，接口
用途：开发组织划分，成本/进度的评估

误解：逻辑视图不是业务流程，逻辑视图的相关方是用户，某种程度上用户不需要知道业务具体如何实现，具体如何流转，只是获取最终结果即可

关键：从用户的视角去理解系统

应用：功能模块图、子系统关系图

功能模块图示例

（3）开发视图

本质：描述系统如何开发实现

相关者：开发相关人员，测试人员
视角：系统如何开发实现
主要元素：描述系统的层次结构，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架
用途：指导开发组织设计和开发实现

关键：从开发人员出发，系统如何落地实现&#x