目录
责任分配 Allocation of Responsibilitie
“在刺激和反应之间，有一个空间。在这个空间中，我们有能力选择我们的反应。我们的成长和自由寄托于我们的反应。” ——维克多·E·弗兰克尔，《人类对意义的追寻》
正如我们在第三章的架构影响周期（Architecture Influence Cycle）中看到的，许多因素决定了系统架构必须具备的质量。这些质量超出了功能性，功能性是系统能力、服务和行为的基本陈述。尽管功能性和其他质量密切相关，但正如您将看到的，功能性在开发计划中往往是首位的。然而，这种偏好是短视的。系统经常重新设计，不是因为它们在功能上有缺陷——替代品通常在功能上是相同的——而是因为它们难以维护、移植或扩展；或者它们运行太慢；或者它们已经被黑客攻破。在第二章中，我们说架构是软件创建中第一个可以解决质量要求的地方。系统功能到软件结构的映射决定了架构对质量的支持。在第5-11章，我们讨论了各种质量是如何通过架构设计决策得到支持的。在第17章，我们展示了如何将所有质量属性决策整合到一个设计中。
到目前为止，我们一直在宽泛地使用“质量属性”这个术语，但现在是时候更仔细地定义它了。质量属性（QA）是一个系统的可测量或可测试属性，用于表示系统满足其利益相关者需求的程度。你可以认为质量属性是沿着利益相关者关心的某个维度衡量产品的“优良”。
在本章中，我们的重点是理解以下内容：
- 如何表达我们希望我们的架构为我们正在构建的系统或系统提供的质量。
- 如何实现这些质量。
- 如何确定我们可能会就这些质量做出的设计决策。
本章为第5-11章中特定质量属性的讨论提供了背景。
架构和需求
系统的需求以各种形式存在：文本需求、模拟、现有系统、用例、用户故事等等。第16章讨论了"具有架构重要性的需求"的概念，以及这类需求在架构中的作用以及如何识别它们。无论信息来源如何，所有的需求都包括以下几个类别：
1. 功能性需求：这些需求说明系统必须做什么，以及在运行时如何行为或对待刺激。
2. 质量属性需求：这些需求是对功能性需求或整体产品的资格要求。对功能性需求的资格要求可以包括函数执行速度或对错误输入的容忍程度等项。对整体产品的资格要求可以包括产品部署时间或运营成本的限制等项。
3. 约束：约束是一个设计决策，没有自由度。也就是说，这是一个已经确定的设计决策。示例包括使用特定的编程语言、重用特定的现有模块的要求，或者管理层决定将系统服务化的命令。这些选择可以说是架构师的职权范围内，但外部因素（比如不能培训员工学习新语言，或者与软件供应商有业务协议，或者推动服务互操作性的业务目标）导致有权力的人决定了这些设计结果。
架构对这些不同类型的需求的响应如下：
1. 功能性需求：通过在设计中分配适当的责任序列来满足功能性需求。正如我们将在本章后面看到的那样，将责任分配给架构元素是一个基本的架构设计决策。
2. 质量属性需求：通过架构中设计的各种结构以及填充这些结构的元素的行为和互动来满足质量属性需求。第17章将更详细地展示这一方法。
3. 约束：通过接受设计决策并将其与其他受影响的设计决策协调一致来满足约束。
功能性
功能性是系统完成其预期工作的能力。在所有的需求中，功能性与架构之间的关系最为奇特。
首先，功能性并不确定架构。也就是说，在给定一组所需的功能性的情况下，可以创建无数种满足这些功能性的架构。至少，您可以以各种方式划分功能性并将子部分分配给不同的架构元素。
事实上，如果仅考虑功能性，您根本不需要将系统划分为各个部分；一个没有内部结构的单一的庞大块就足够了。相反，我们设计我们的系统作为协作的架构元素模块、层、类、服务、数据库、应用程序、线程、对等节点、层次结构等等的结构化集合，以使它们易于理解并支持各种其他用途。这些“其他用途”是我们将在本章的其余部分和第二部分的其余章节中关注的其他质量属性。
虽然功能性独立于任何特定结构，但是通过将责任分配给架构元素来实现功能性，从而产生了最基本的架构结构之一。
尽管责任可以随意分配给任何模块，但在其他质量属性重要的情况下，软件架构会限制此分配。例如，系统通常会被划分为几个部分，以便多人可以协作构建它们。架构师对功能性的兴趣在于它如何与其他质量属性进行交互并对其进行限制。
质量属性考虑
正如系统的功能在没有充分考虑其他质量属性的情况下不能独立存在一样，质量属性也不能孤立存在；它们与系统的功能相关联。如果一个功能性需求是"当用户按下绿色按钮时，选项对话框会出现"，性能质量属性的注释可能会描述对话框出现的速度；可用性质量属性的注释可能会描述这个功能会失败多少次以及修复它需要多长时间；优使性质量属性的注释可能会描述学习这个功能有多容易。
功能性需求
经过超过15年的写作和讨论，关于功能性需求和质量需求之间的区别仍然让我感到困惑。质量属性需求有着清晰的定义：性能涉及系统的时序行为，可修改性涉及系统在初始部署后支持行为或其他质量属性变更的能力，可用性涉及系统在面临故障时的生存能力，等等。
然而，功能性则更加难以捉摸。一个国际标准（ISO 25010）将功能性适用性定义为"软件产品在指定条件下使用时提供满足明示和隐含需求的功能的能力"。也就是说，功能性是提供功能的能力。这个定义的一个解释是，功能性描述系统做什么，而质量描述系统在执行其功能时执行得有多好。也就是说，质量是系统的属性，而功能是系统的目的。
然而，当考虑一些"功能"的性质时，这种区分就会变得模糊不清。如果软件的功能是控制引擎行为，那么在不考虑时序行为的情况下，如何正确实现这个功能呢？通过要求用户名/密码组合来控制访问的能力是否不是一个功能，尽管它不是任何系统的目的？
我更喜欢使用"责任"这个词来描述系统必须执行的计算或操作。诸如"对于这组责任，有哪些时序约束？"、"对于这组责任，预期会有哪些修改？"和"哪个用户类允许执行这组责任？"这样的问题是有意义且可操作的。
质量的实现引起了责任；想想刚提到的用户名/密码的例子。此外，可以将责任与特定的需求集相关联。
那么，这是否意味着术语"功能性需求"不应该被使用？人们对这个术语有一定的理解，但当需要精确性时，我们应该谈论具体责任的集合。
Paul Clements长期以来一直反对不谨慎使用"非功能性"这个术语，现在轮到我反对不谨慎使用"功能性"这个术语了，可能同样没有效果。
质量属性至少自1970年代以来一直受到软件社区的关注。已经出版了各种各样的分类法和定义，其中许多都有自己的研究和从业者社区。从架构师的角度来看，以前关于系统质量属性的讨论存在三个问题：
1. 为属性提供的定义无法进行测试。说一个系统将是"可修改的"是没有意义的。每个系统都可以在某种变更集合方面是可修改的，而在其他方面则不可修改。其他质量属性在这方面也类似：一个系统可能对某些故障具有鲁棒性，但对其他故障则脆弱。等等。
2. 讨论通常集中在特定关注点属于哪种质量属性上。一个系统因拒绝服务攻击而导致的故障是可用性、性能、安全性还是可用性的一部分？这四个属性社区都会声称对拒绝服务攻击导致的系统故障拥有所有权。在某种程度上，他们都是正确的。但这并不能帮助我们作为架构师理解和创建用于管理关注属性的架构解决方案。
3. 每个属性社区都发展了自己的词汇。性能社区有系统中的"事件"，安全社区有系统中的"攻击"，可用性社区有系统的"故障"，优使性社区有"用户输入"。所有这些实际上可能指的是相同的事件，但它们使用不同的术语进行描述。
解决前两个问题（不可测试的定义和重叠关注点）的一个方法是使用质量属性场景来表征质量属性（请参阅下一节）。解决第三个问题的方法是提供有关每个属性的讨论，重点关注其基本关注点，以阐明与该属性社区相关的基本概念。
我们关注的质量属性分为两类。第一类是在运行时描述系统某些属性的属性，如可用性、性能或优使性。第二类是描述系统开发过程中某些属性的属性，如可修改性或可测试性。
在复杂系统中，质量属性永远无法孤立地实现。任何一个质量属性的实现都会对其他质量属性的实现产生影响，有时是积极的，有时是负面的。例如，几乎每个质量属性都会对性能产生负面影响。以可移植性为例。实现可移植软件的主要技术是隔离系统依赖项，这会引入系统执行的开销，通常体现为进程或过程边界，这会损害性能。
确定满足所有质量属性要求的设计部分取决于做出适当的权衡；我们将在第17章讨论设计。我们在这里的目的是为讨论每个质量属性提供背景。特别是，我们关注如何指定质量属性，哪些架构决策将实现特定质量属性的达成，以及关于质量属性的哪些问题将使架构师能够做出正确的设计决策。
规定质量属性需求
质量属性需求应该具有明确性和可测试性。我们使用一种通用形式来规定所有质量属性需求。这有强调所有质量属性之间的共同之处的优点，但有时可能对某些质量属性的某些方面进行强制适应。
我们的通用质量属性表达形式包括以下部分：
1. 刺激（Stimulus）：我们使用术语"刺激"来描述到达系统的事件。刺激可以是性能社区的事件，可用性社区的用户操作，或安全性社区的攻击。我们也使用相同的术语来描述开发性质的激励。因此，可修改性的刺激是请求修改；可测试性的刺激是开发阶段的完成。
2. 刺激源（Stimulus source）：刺激必须有一个来源，它必须来自某个地方。刺激的来源可能会影响系统对其的处理方式。来自受信任用户的请求将不会像来自不受信任用户的请求那样经受同样的审查。
3. 响应（Response）：系统应该如何响应刺激也必须指定。响应包括系统（对于运行时属性）或开发人员（对于开发时属性）应对刺激执行的职责。例如，在性能场景中，事件到达（刺激），系统应该处理该事件并生成响应。在可修改性场景中，请求修改到达（刺激），开发人员应该实施修改而不产生副作用，然后测试和部署修改。
4. 响应度量（Response measure）：通过提供响应度量来确定响应是否令人满意，即是否满足了需求。对于性能，这可以是延迟或吞吐量的度量；对于可修改性，可以是制作、测试和部署修改所需的劳动或墙钟时间的度量。
这些场景的四个特征是我们质量属性规范的核心。但还有两个重要的特征：环境和工件。
5. 环境（Environment）：需求的环境是场景发生的情况集。环境充当刺激的限定条件。例如，在代码已经冻结以发布之前到达的修改请求可能会与在冻结之后到达的请求不同对待。某个组件的第五次连续故障可能会与该组件的第一次故障不同对待。
6. 工件（Artifact）：最后，工件是需求适用的系统部分。通常情况下，这是整个系统，但偶尔也可以特定指定系统的某些部分。数据存储中的故障可能会与元数据存储中的故障不同对待。对用户界面的修改可能比对中间件的修改具有更快的响应时间。
总结我们如何规定质量属性需求，我们将它们正式地捕捉为六部分的场景。尽管在思考质量属性的早期阶段常常会省略其中一项或多项，但知道所有部分都在那里会迫使架构师考虑每个部分是否相关。
总之，这里是六个部分：
1. 刺激的来源 Source of stimulus：生成刺激的实体（人类、计算机系统或其他执行器）。
2. 刺激 Stimulus：刺激是需要在到达系统时产生响应的条件。
3. 环境 Environment：刺激发生在某些条件下。系统可能处于过载状态或正常运行状态，或其他相关状态。对于许多系统，“正常”运行可以指的是多种模式之一。对于这类系统，环境应该指定系统处于哪种模式下执行。
4. 工件 Artifact：某些工件受到刺激。这可以是一组系统、整个系统或其中的一部分或多部分。
5. 响应 Response：响应是作为刺激到达结果而采取的活动。
6. 响应度量 Response measure：响应发生时，应该以某种方式进行度量，以便测试需求。
我们区分一般质量属性场景（我们简称为"一般场景"）-这些场景是与系统无关的，潜在地可以与任何系统相关，与具体的质量属性场景（具体场景）-这些场景特定于正在考虑的特定系统。
我们可以将质量属性描述为一组一般场景的集合。当然，要将这些通用属性描述转化为特定系统的需求，通常需要使一般场景变得与系统相关。这些场景的详细示例将在第5至11章中给出。图4.1显示了我们刚刚讨论的质量属性场景的各个部分。图4.2展示了一个一般场景的示例，这是可用性的一个示例。
通过策略实现质量属性
质量属性要求规定了系统的响应，通过一些幸运和良好的规划，可以实现业务目标。现在，我们将转向架构师可以使用的技术，以实现所需的质量属性。我们称这些技术为架构策略。策略是一种设计决策，影响质量属性响应的实现，策略直接影响系统对某些刺激的响应。策略赋予一个设计可移植性，另一个高性能，第三个可集成性。
不是我的问题
有一次，我在对劳伦斯利物浦国家实验室创建的复杂系统进行架构分析。如果你访问他们的网站（www.llnl.gov）并尝试弄清楚利物浦实验室做什么，你会看到一遍又一遍提到了“安全”这个词。该实验室专注于核安全、国际和国内安全以及环境和能源安全。这是一项严肃的工作。
记住这一重点，我要求他们描述我正在分析的系统的关注的质量属性。我相信你可以想象得出，当时我感到非常惊讶，因为他们一次都没有提到安全这个词！系统的利益相关者提到了性能、可修改性、可演化性、互操作性、可配置性和可移植性，还有一两个，但从他们的嘴里从未提到过安全。作为一个好的分析师，我质疑了这个看似令人震惊和明显的遗漏。他们的回答简单，回顾起来很直接：“我们不关心安全。我们的系统没有连接到任何外部网络，而且我们有带刺铁丝网和持有机枪的警卫。”当然，利物浦实验室的某些人对安全非常感兴趣。但显然不包括软件架构师。
策略的焦点在于单一的质量属性响应。在策略内部，没有考虑权衡。权衡必须由设计师明确考虑和控制。在这方面，策略与架构模式不同，架构模式中的权衡已经内置在模式中。（我们将在第14章中探讨策略与模式之间的关系。第13章解释了如何构建质量属性的一组策略，这是我们在本书中使用的步骤来生成这组策略的。）
系统设计包括一系列决策。其中一些决策有助于控制质量属性的响应；其他决策确保系统功能的实现。我们在图4.3中表示了刺激、策略和响应之间的关系。与设计模式一样，策略是架构师多年来一直在使用的设计技巧。我们的贡献在于将它们分离、编目并描述出来。我们并不是在这里发明策略，而是在捕捉架构师在实践中所做的事情。
为什么要这样做呢？有三个原因：
1. 设计模式往往复杂，通常由一系列设计决策组成。但通常很难直接应用设计模式；架构师需要修改和调整它们。通过了解策略的作用，架构师可以更容易地评估增强现有模式以实现质量属性目标的选项。
2. 如果没有模式来实现架构师的设计目标，策略允许架构师从“第一原理”构建设计片段。策略让架构师了解生成设计片段的特性。
3. 通过编目策略，我们提供了一种在一定限制内使设计更加系统化的方法。我们的策略列表并不提供分类法，只提供分类。策略会有重叠，你通常可以在多个策略中选择来改善特定的质量属性。选择使用哪种策略取决于因素，如在其他质量属性之间的权衡和实施成本。这些考虑超越了讨论特定质量属性的策略。第17章提供了一些选择竞争策略的技巧。
我们提出的策略可以并应该进行进一步的精化。以性能为例：安排资源是一种常见的性能策略。但这个策略需要进一步精化为特定的调度策略，比如最短作业优先、轮转等，用于特定目的。使用中介是一种可修改性策略。但有多种类型的中介（层、代理、代理等），因此设计师会采用一些精化方法来使每种策略具体化。
此外，策略的应用取决于上下文。再次考虑性能：管理采样率在某些实时系统中是相关的，但并不适用于所有实时系统，特别是不适用于数据库系统。
引导质量设计决策
请回想一下，我们可以将架构视为应用一系列设计决策的结果。我们在这里提供的是对这些决策的系统分类，以便架构师可以将注意力集中在可能最麻烦的设计维度上。
设计决策的七个类别包括：
1. 责任分配 Allocation of responsibilities
2. 协调模型 Coordination model
3. 数据模型 Data model
4. 资源管理 Management of resources
5. 架构元素之间的映射 Mapping among architectural eletnents
6. 绑定时间决策 Binding time decisions
7. 技术选择 Choice of technology
这些类别并不是唯一的分类架构设计决策的方式，但它们提供了一种合理的关注分割。这些类别可能会有重叠，但如果某个特定决策存在于两个不同的类别中，也没有关系，因为架构师的关注是确保考虑每个重要的决策。我们对决策的分类部分基于我们对软件架构的定义，因为我们的许多分类与结构的定义以及它们之间的关系相关联。
责任分配 Allocation of Responsibilitie
涉及责任分配的决策包括以下内容：
• 确定重要的责任，包括基本的系统功能、架构基础设施和满足质量属性。
• 确定如何将这些责任分配给非运行时和运行时元素（即模块、组件和连接器）。
制定这些决策的策略包括功能分解、建模真实世界对象、根据系统操作的主要模式进行分组，或根据类似的质量要求进行分组：处理帧速率、安全级别或预期的变化。
在第5至11章中，我们将这些设计决策类别应用于多个重要的质量属性时，我们为责任分配类别提供的检查表是从理解该质量属性的一般情景中列出的刺激和响应系统地导出的。
协调模型 Coordination Model
软件通过使元素通过经过设计的机制相互作用来运行。这些机制统称为协调模型。与协调模型相关的决策包括以下内容：
• 识别必须协调或禁止协调的系统元素。
• 确定协调的属性，如及时性、时效性、完整性、正确性和一致性。
• 选择实现这些属性的通信机制（系统之间、我们的系统与外部实体之间、我们的系统内部元素之间的通信机制）。通信机制的重要属性包括有状态与无状态、同步与异步、保证交付与非保证交付，以及吞吐量和延迟等性能相关属性。
数据模型
每个系统都必须以某种内部方式表示系统范围内感兴趣的数据工件。这些表示的集合以及如何解释它们被称为数据模型。关于数据模型的决策包括以下内容：
• 选择主要的数据抽象、它们的操作和属性。这包括确定数据项如何创建、初始化、访问、持久化、操作、翻译和销毁。
• 编译用于一致解释数据的元数据。
• 组织数据。这包括确定数据是否将存储在关系型数据库、对象集合或两者之中。如果两者都有，那么必须确定数据在这两种不同位置之间的映射关系。
资源管理
架构师可能需要仲裁架构中共享资源的使用。这些资源包括硬资源（例如CPU、内存、电池、硬件缓冲区、系统时钟、I/O端口）和软资源（例如系统锁、软件缓冲区、线程池和非线程安全的代码）。
资源管理的决策包括以下内容：
• 确定必须管理的资源，并确定每个资源的限制。
• 确定哪些系统元素管理每个资源。
• 确定资源的共享方式以及在发生争用时采用的仲裁策略。
• 确定不同资源饱和对性能的影响。例如，当CPU负载较重时，性能通常会逐渐下降。另一方面，当内存不足时，某些时候会开始密集地分页/交换，性能会突然崩溃。
架构元素之间的映射
架构必须提供两种类型的映射。首先，有不同类型架构结构中元素之间的映射，例如从开发单元（模块）到执行单元（线程或进程）的映射。接下来，有软件元素和环境元素之间的映射，例如从进程到将执行这些进程的特定CPU的映射。
有用的映射包括以下内容：
• 模块和运行时元素之间的映射，即从每个模块创建的运行时元素；包含每个运行时元素代码的模块。
• 将运行时元素分配给处理器。
• 将数据模型中的项目分配给数据存储。
• 模块和运行时元素与交付单元的映射。
绑定时间决策
绑定时间决策引入了可接受的变化范围。这种变化可以由不同的实体在软件生命周期的不同阶段进行绑定，从开发者的设计时间到最终用户的运行时。绑定时间决策确定了变化的范围、生命周期中的时间点以及实现变化的机制。
其他六个类别中的决策都与绑定时间决策相关联。此类绑定时间决策的示例包括以下内容：
• 对于责任分配，您可以通过参数化的makefile在构建时选择模块。
• 对于协调模型的选择，您可以设计协议的运行时协商。
• 对于资源管理，您可以设计一个系统，在运行时接受新的外围设备插入，然后系统会自动识别它们并下载并安装正确的驱动程序。
• 对于技术的选择，您可以为智能手机构建一个应用商店，该商店会自动下载适用于购买应用的客户手机的应用版本。
在做出绑定时间决策时，您应考虑实施该决策的成本以及在实施该决策后进行修改的成本。例如，如果您考虑在编码后的某个时刻更改平台，您可以以一定的成本来隔离自己，以抵御将系统移植到另一个平台带来的影响。做出这个决策取决于修改早期绑定所产生的成本与实施晚期绑定所涉及的机制所产生的成本之间的比较。
技术选择
每个架构决策最终都必须使用特定的技术来实现。有时，在有意的架构设计过程开始之前，技术选择是由其他人做出的。在这种情况下，所选择的技术将成为我们七个类别中每个决策的限制条件。在其他情况下，架构师必须选择合适的技术来实现每个类别中的决策。
技术选择决策涉及以下内容：
• 决定哪些技术可用于实现其他类别中所做的决策。
• 确定支持此技术选择的可用工具（IDE、模拟器、测试工具等）是否足以支持开发。
• 确定内部熟悉程度以及外部支持的程度，例如课程、教程、示例以及可以在关键时期提供专业知识的承包商的可用性，并决定是否足以继续。
• 确定选择技术的副作用，例如所需的协调模型或受限的资源管理机会。
• 确定新技术是否与现有技术堆栈兼容。例如，新技术是否可以在现有技术堆栈之上或与之并行运行？新技术是否可以与现有技术堆栈进行通信？新技术是否可以进行监控和管理？
总结
系统的需求分为三类：
1. 功能性。这些需求通过在设计中包括适当的责任集合来满足。
2. 质量属性。这些需求通过架构的结构和行为来满足。
3. 约束。约束是已经做出的设计决策。
为了表达质量属性的需求，我们使用了一个质量属性场景。场景的组成部分包括：
1. 刺激源
2. 刺激
3. 环境
4. 工件
5. 响应
6. 响应度量
架构策略是影响质量属性响应的设计决策。策略的重点是单个质量属性响应。架构模式可以被看作是“策略”的“包裹”。
架构设计决策的七个类别如下：
1. 责任分配
2. 协调模型
3. 数据模型
4. 资源管理
5. 架构元素之间的映射
6. 绑定时间决策
7. 技术选择
进一步阅读
Philippe Kruchten [Kruchten 04] 提供了另一种设计决策的分类方法。
Perra [Perra 87] 使用功能/形式/经济/时间的分类方式来分类设计决策。
绑定时间和实现不同类型绑定时间的机制在[Bachmann 05]中进行了讨论。
关于质量属性的分类法可以在[Boehm 78]、[McCall 77]和[ISO 1 1]中找到。
关于将架构视为与功能基本独立的论点可以在[Shaw 25]中找到。
讨论问题
1. 用例与质量属性场景之间的关系是什么？如果您想向用例添加质量属性信息，该如何做？
用例与质量属性场景之间的关系是可以互补的。用例通常描述了系统的功能性需求，而质量属性场景关注系统在不同刺激下的行为和性能。如果要向用例添加质量属性信息，可以在用例描述中明确提及相关的质量属性场景，以说明在不同情况下系统需要满足的性能和行为要求。
2. 您认为质量属性的策略集是有限的还是无限的？为什么？
质量属性的策略集通常是有限的，因为每个质量属性都有一组已知的策略或技术可以用来改善或维护其性能。然而，这并不意味着策略集是固定不变的，因为随着技术的发展和新的研究成果，新的策略可能会不断出现，使策略集在某种程度上保持动态性。
3. 讨论编程语言选择（技术选择的一个示例）与架构之间的关系，以及与其他六个类别的设计决策的关系。例如，某些编程语言如何可以促进或限制特定协调模型的选择？
编程语言选择与架构之间存在紧密关联。不同的编程语言具有不同的特性和能力，可以影响到架构的设计决策，尤其是在协调模型、资源管理和技术选择等方面。例如，某些编程语言可能更适合实现特定的协调模型，而另一些可能更适合处理多线程或异步通信。此外，编程语言还可以影响系统的性能、可维护性和安全性等方面。
4. 我们将在关于质量属性的章节中一直使用自动取款机作为示例。列举一个自动取款机应该支持的责任集，并提出一个初始设计来适应该责任集。为您的提议提供理由。
自动取款机应该支持的责任集包括：
- 处理账户余额查询和交易请求。
- 确保交易的安全性，包括身份验证和授权。
- 处理现金的存取操作，包括钞票的发放和接收。
- 记录交易日志以供审计和查询。
- 提供用户友好的界面，包括屏幕显示和键盘输入。 初始设计可以包括硬件模块（如钞箱、卡片读卡器、键盘、屏幕）、安全措施（如密码验证、加密通信）、交易处理逻辑和数据库存储等。这个设计可以通过满足功能性、安全性和性能等质量属性需求来保证其合理性。
5. 考虑一下您喜欢的自动取款机使用的屏幕。这些屏幕告诉您关于反映在架构中的绑定时间决策的什么信息？
自动取款机使用的屏幕可以反映绑定时间决策。例如，如果屏幕上显示的信息是静态的，事先确定并硬编码在系统中，那么这属于早期绑定。如果屏幕上的信息是根据用户输入或系统状态动态生成的，那么这属于更晚期的绑定，系统可以根据需要来动态生成和显示信息。
6. 考虑同步和异步通信之间的选择（协调机制类别中的选择）。什么质量属性要求可能会导致您选择其中一个而不是另一个？
在选择同步和异步通信时，需要考虑质量属性要求。同步通信通常更容易管理和调试，但可能会导致性能瓶颈。异步通信可以提高系统的响应性能，但需要更复杂的错误处理和管理机制。因此，根据系统的性能和可维护性要求，可以选择一种通信方式。
7. 考虑有状态和无状态通信之间的选择（协调机制类别中的选择）。什么质量属性要求可能会导致您选择其中一个而不是另一个？
有状态和无状态通信的选择也涉及到质量属性需求。有状态通信可以提供更多的上下文信息，但可能会增加系统的复杂性。无状态通信更简单，但可能会导致一些性能损失，因为每个请求都需要携带完整的上下文信息。选择取决于系统对上下文维护和性能的需求。
8. 大多数点对点架构采用拓扑的后期绑定。这会促进或抑制哪些质量属性？
大多数点对点架构采用后期绑定的拓扑，这有助于提高系统的灵活性和可扩展性。这种架构可以促进负载均衡、容错性和可伸缩性等质量属性。然而，它可能会增加一些复杂性，如网络通信和节点发现，因此需要权衡不同的质量属性需求。
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
