Lecture 7 结构设计

architecture 感觉可以翻译成结构也可以翻译成架构，在这一节当中没有统一

定义：软件的体系结构，包含了软件的元素以及它们之间的关系，以及两者的属性，可以用来推理（reasoning）系统。

没有绝对的好的架构或者坏的架构。相对好的架构应当解决 stakeholder 的需求和担忧；如果不同的 stakeholder 之间有一点冲突，那么就要找到一个平衡点。

重要性：

加强利益相关者（stakeholder）之间的沟通
允许项目经理和架构师来估算成本和进度
定义对实现上的限制
包含最基本层面上的设计决策
为软件创造一个可重用（reusable）的模型
促进系统分析 facilitate system analysis

软件结构是一种抽象（abstraction）。可以在两个抽象层次上设计软件体系结构：

小体系结构（architecture in the small）：关注一个单独的程序的体系结构，即一个程序由什么组件构成，其中每个组件都拥有一定的功能。
大体系结构（architecture in the large）：关注包括其他系统的企业级的系统的体系结构，即这个程序和其他程序一起构成一个大的系统。

结构设计流程

architectural requirements，找出一些 architectural significant 的需求，比如性能要求等
architectural design，相当于把需求翻译成代码框架
architectural documentation，把框架以文档的形式表达出来，也是结构设计的一部分
architectural implementation，实现
architectural evaluation(optional)，看看是否满足 architectural significant 的需求

结构设计的方法

有多种方法。

但是这个图与这一章节的 PPT 几乎是没有任何关联。

体系结构视图：4+1 Views

逻辑视图 logic view，将系统当中关键的抽象显示为对象或者类，可以把需求与类联系起来
进程视图 process view，能体现进程如何构成系统，可以用于判断系统的性能
开发视图 development view，能体现系统如何分解成不同开发人员负责的组件，用于分配任务
物理视图 physical view，体现系统的硬件和软件是如何分布的，可以帮助系统工程师规划部署方案

这四个视图可以通过共同的场景或用况连接到一起。

架构设计文档方法

视图（View），包含结构中的元素以及元素之间的关系。

结构（structure），就是指元素本身的集合，存在于软件中或者硬件中，分三类：

模块结构 Module structure。模块就是指一组代码和数据。那么系统是如何由不同模块构成的？
组件和连接器结构 Component-and-connector structure。组件就是运行时行为，而连接器就是指不同组件之间的交互和通信。不同组件之间是如何连接、交互的？
分配结构 Allocation structure。描述了元素和周围环境当中资源的分配关系。

架构师们（architects）会负责把结构设计出来，并写成文档的形式。所以这个叫做 架构设计文档方法（ADD，Architectural Design Document）

术语：viewpoint & perspective

视角（viewpoint），是用来构建 view 的模式、模板、约定的集合。“A Viewpoint is a collection of patterns, templates, and conventions for constructing one type of view.”

观点（perspective），是架构的活动、策略、引导线的集合，用于确保系统特定的相关质量属性，这些属性要在多个视图当中加以考虑。“An architectural perspective is a collection of architectural activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views.”

课件上写的东西奇奇怪怪的。于是我问了 GPT：

视角（Viewpoint）：视角是构建特定类型视图的模式、模板和约定的集合。在软件架构中，视图（View）是对系统架构的表示，专注于特定的结构方面，并解决了利益相关者的具体关注点。不同的利益相关者可能有不同的视角或关注点，视角提供了如何创建满足这些关注点的视图的指导。

视图（View）：视图表示架构的一个或多个结构方面，并说明架构如何解决利益相关者的关注点。它提供了系统结构和行为的特定视角或表示，突出显示特定的架构元素及其关系。视图帮助利益相关者基于其兴趣和关注点了解架构的不同方面。

架构观点（Architectural Perspective）：架构观点是一组架构活动、策略和准则的集合，旨在确保系统展示出特定相关质量属性的集合。观点关注一组跨多个架构视图的质量属性。它提供了指导，帮助设计、评估和确保系统架构中所需的质量属性得到关注。

总结起来，视角提供了构建特定类型视图的指导，视图表示架构的结构方面并解决利益相关者的关注点，而架构观点则指导跨多个视图考虑相关质量属性。这些概念共同帮助架构师在满足各种利益相关者的关注点和质量要求的同时，有效地进行沟通和设计软件系统。

对于课件上给出的这张图，GPT 说：

视图符合视角（Viewpoint）：视图是根据特定的视角构建的。视角提供了一组模式、模板和约定，指导创建特定类型的视图。视图根据相应视角定义的指导方针和原则进行塑造和结构化。

视角关注问题（Concern）：每个视角都旨在解决利益相关者的特定关注点或兴趣。它提供了一种理解和分析架构的视角或框架，与利益相关者的关注点相吻合。通过使用适当的视角，架构师可以确保所生成的视图有效地解决了预期的关注点。

视图受观点塑造：观点影响视图的创建和结构。观点代表一组架构活动、策略和准则，用于确保系统展示出特定相关质量属性的集合。观点为设计和评估架构提供了指导框架，并塑造视图的构建方式以反映这些质量属性。

观点关注问题：与视角类似，观点旨在解决与质量属性相关的特定关注点。它们提供了关于如何设计架构以确保实现所需质量属性的指导。通过采用适当的观点，架构师可以解决和优先考虑与该观点所定义的特定质量属性相关的关注点。

总结起来，视角指导视图的创建，解决利益相关者的关注点。观点则指导在多个视图中考虑特定质量属性，解决与这些属性相关的关注点。二者共同为架构师提供了一种结构化的方法，用于设计和评估软件架构，与利益相关者的关注点保持一致，并实现所需的质量属性。

~~感觉还是奇奇怪怪的~~

视角的分类

上下文视角（context），描述系统与环境之间的关系、依赖以及交互
功能视角（functional），描述系统之中元素的功能、职责、接口、交互方式
信息视角（information），描述系统如何存储、操作、管理数据
并发视角（concurrency），描述系统的并发结构
开发视角（development），描述用什么架构才能完成软件开发过程
部署视角（deployment），描述系统在不同环境下，应当如何安装与部署
操作视角（operational），描述系统是如何被操作、管理和支持的

有了视角，就可以作为模板，构造出视图。这些不同种类视图之间的关系如下图所示

体系结构模式 architectural patterns

就是研究不同元素之间应该如何组合、交互，以解决特定问题，有点像设计模式

客户端-服务器体系结构 client-server architecture

应用场景：有大量客户端（分布在不同地方），都希望访问特定的资源或者服务。我们希望对其进行访问或服务质量控制。每个服务都由一个独立的服务器提供。当客户端需要的时候，就向服务器发出请求。

总结的说，客户端-服务器体系结构是指托管、交付和管理客户端请求的大多数资源和服务的系统。“The client-server architecture refers to a system that hosts, delivers, and manages most of the resources and services that the client requests.”

客户端需要一种协议或工具与服务器进行连接
服务器当中的某个组成部分，可能会是其他服务的客户

优点

服务器可以分布在网络上
通用的功能（比如打印服务）可以向所有客户端开放使用

缺点

服务器可能是性能瓶颈（bottleneck）
服务器可能存在单点失效（single point of failure）状况（说白了就是宕机了）
服务器建成之后，如果进行更改，成本比较高

分层体系结构 layered architecture

复杂的大型系统，都是由独立的各个部分构成的。应用分层体系结构，就可以把各个模块分离开来，分别开发和维护。这种方式也让增量开发变得方便（一个开发好之后再开发另一个，一个更改了对另一个没啥影响）。

分层体系结构就是指，把具有类似的功能的模块，划分到同一个层当中。这样一来，每个层都提供特定的功能，层和层之间几乎没有重叠，所以便携性、易修改性、重用性都挺不错的。

最常见的是分三个层：UI 层、业务逻辑层、数据层：

注意箭头表示 allow-to-use，必须是单向的，不能成环。

优点

每个层都提供特定的功能，层和层之间几乎没有重叠，所以便携性、易修改性、重用性都挺不错的。
如果层之间的接口保持不变，则可以在不影响其他层的情况下替换整个层。在对系统进行更改或升级时，这种灵活性非常有用。
通过在每一层内设置冗余（redundant）设施或部件，可以提高系统的可靠性。如果一个组件出现故障，则该层内有备份或替代方案以确保系统的功能。

缺点

在系统中创建一个层，需要比较复杂的工作，会一定程度上增加系统的管理成本。
层数比较多的时候，会影响整体的性能。

模型-视图-控制器模式（MVC）

Context：UI 通常是变化很频繁的。用户经常希望以不同的方式查看数据或与数据交互。

MVC 模式顾名思义，把程序分成了 M、V、C 三个部分：

模型，包含了应用程序的数据以及对数据的操作
视图，基本可以按照 UI 来理解，就是负责显示数据、与用户交互
控制器，相当于模型和视图之间的中介，管理状态变化的通知。

MVC 模式的主要目的是分离数据（模型）、表示（视图）和用户交互（控制器）的关注点，以实现更加模块化和可维护的架构。

MVC 模式可以使用户界面功能与应用功能分开，且同时对用户输入以及应用数据的变化做出响应。

优点

允许数据独立于它的表示形式而更改，也允许数据的表示形式更改而不改变数据本身
支持同一种数据的多种不同表示方式

缺点

假如数据模型和交互都比较简单，MVC 反而可能会让程序变得更复杂
对于某些特殊的 UI toolkits，可能不适用

参考体系结构 Reference Architecture

参考体系结构是为特定类型的应用程序提供整体逻辑结构的蓝图。换句话说就是，参考体系结构为特定类型的情景，提供了高度通用的模板，其中通常会包含 API 等。

比如对于 Web 应用程序（不需要复杂的界面、不需要安装任何客户端软件、注重可移植性、希望尽量减小客户端的资源占用），参考体系结构就很适用。

移动设备上的应用程序，如果需要在线使用，那就相当于上一条（Web）；有时候会遇到离线的情况（比如进入到西藏无人区，手机没信号了），这种时候就要使用离线的功能，参考体系结构为此提供了比较完善的模板，可以直接用。