Architectural Design，如何组织一个软件系统以及设计该系统的整体结构的过程
软件架构重要性
架构方法
Principled Methods
属性驱动
Attribute-Driven Design (ADD)
没看懂，回头再补
选择要分解的模块 (module)
从具体的质量场景，选择构架驱动因素
实例化模块，根据用例分配功能 (allocation)，使用多个视图 (view)，把它们连接在一起 (component-and-connector)
视角透视
Viewpoint and perspective method
视图
View shows how the architecture addresses concerns held by its stakeholders
架构的结构方面的表示，展示了架构如何解决利益相关者所持有的关注点。
- 上下文视角（Context viewpoint）：描述系统与其环境之间的关系、依赖和交互。
- 功能视角（Functional viewpoint）：描述系统的功能元素、它们的责任、接口和交互。
- 信息视角（Information viewpoint）：描述系统如何存储、操作、管理和分发信息。
- 并发视角（Concurrency viewpoint）：描述系统的并发结构，将功能元素映射到并发单元。
- 开发视角（Development viewpoint）：描述支持软件开发过程的架构。
- 部署视角（Deployment viewpoint）：描述系统在其操作环境中的安装和部署方式以及相关的依赖关系。
- 运行视角（Operational viewpoint）：描述系统的运行、管理和支持方式。
透视
Perspective, a collection of architectural activities, tactics, and guidelines that are used to ensure that a system exhibits a set of quality properties that require consideration across a number of the system’s architectural views.
一组架构活动、策略和指南的集合，用于确保系统展现出一组相关的质量属性，这些属性需要在系统的多个架构视图中考虑。
4+1 视图
A Scenario is used to illustrate and validate the 4 views.
逻辑视图
Logical View
描述系统的功能逻辑，关注系统的类、接口和其之间的关系，以及它们如何实现系统的需求。
- show the key abstractions in the system as objects or object classes.
物理视图
Physical View
描述系统的部署和物理结构，关注系统的物理组件、服务器、网络拓扑和资源分配。
- show how the system is composed of interacting processes at run time.
开发视图
Development View
描述系统的软件开发，关注软件的构建、集成和测试过程。
- show how the software is decomposed for development.
进程视图
Process View
描述系统的交互性，关注系统的并发处理、进程和线程之间的通信和同步。
- show how the system is composed of interacting processes at run time.
架构模式
Architectural Patterns
客户端-服务端
Client Server Architecture， C/S（Client/Server）架构，用户需要在自己的计算机上安装专门的客户端软件来访问服务。
- 存在一些共享的资源和服务，我们希望不同分布的客户端可以同时访问它们，因此通过集中控制这些资源和服务，将其多个物理服务器上，提高可扩展性和可用性。
🔔 B/S 架构即 Browser/Server，用户只需要一个浏览器即可访问和使用应用程序，不需要安装其他客户端软件。
约束
- 客户端和服务器连接需要通过请求/响应
- 一个服务器组件也应该可以作为其他服务器的客户端
优点
- 服务器可以分布在网络中的不同位置
Servers can be distributed across a network.
- 所有客户端都可以获得服务端的通用服务
General functionalities can be made available to all clients.
弱点
- 服务器可能成为性能瓶颈 (performance bottleneck) 和单点故障 (a single point of failure)
- 在系统构建完成后，对于如何定位客户端或服务器的决策往往复杂且成本高昂。
分层架构
Layered Architecture
所有复杂系统都需要独立开发和演进系统的部分。因此，系统的开发人员需要明确且良好记录的关注点分离，以便系统的模块的维护。
因此软件需要被分割，并且各部分之间的相互作用很小，支持可移植性、可修改性和重用性。
层次结构模式将软件划分为称为层的单元。相似功能的组件被关联到同一水平层面，层之间通过公共接口暴露和连接。
约束
- 每个软件部分都被分配到且只能属于一个层。
- 必须至少存在两个层（通常是三个或更多）。
- 允许使用的关系不应该是循环的（即较低的层不应该使用位于其上层的层）。
优点
- 如果保持接口不变，可以替换整个层。
- 每个层可以提供冗余设施 (redundant facilities)，增加系统的可靠性。
缺点
- 添加层会增加系统的前期成本和复杂性。
- 层会对系统的性能产生负面影响。
模型-视图-控制器
Model-View-Controller (MVC) Architecture
一种解决用户界面功能分离的问题的解决方案。
用户界面通常是交互应用程序中经常修改的部分，用户经常希望从不同的角度查看数据。当底层应用程序数据发生变化时，它能创建、维护和协调用户界面的多个视图。
约束
- 必须至少存在一个模型、一个视图和一个控制器的实例。
- 模型组件不应直接与控制器交互。
优点
- 允许数据独立于其表示方式进行更改，从而支持以不同方式呈现相同的数据
- Allows the data to change independently of its representation.
- Supports presentation of the same data in different ways.
缺点
- 对于简单的用户界面，这种模型过于复杂，不值得使用。
- The complexity may not be worth it for simple user interfaces.
参考架构
经验法则
Rules of Thumb，指在特定领域或情境中，基于经验和常识所形成的一套简单、可应用的指导原则。
- 软件架构应该是单个架构师或一个小组架构师的产物。
- better conceptual integrity and technical consistency.
- 架构师应该基于一个有优先级的、明确定义的质量属性需求列表来设计架构。
- base the architecture on a prioritized list of well defined quality attribute requirements.
- 架构应该经过评估，以确保其能够满足系统的重要质量属性。
- 架构不应依赖于特定版本的商业产品或工具。
- 一个好的架构是能够成功解决利益相关者的关切，并在这些关切存在冲突时以一种对利益相关者可接受的方式进行平衡。
- 不存在本质上好或坏 (inherently good or bad) 的架构。架构要么更适合某个特定目的，要么不太适合 (more or less fit for some purpose)。