casue usb kb 找不到驱动程序_现代软件架构中的架构驱动程序

与玛丽合作

> Picture by Lance Anderson on Unsplash.com

在谈论设计过程的体系结构驱动程序时，人们可能会很快对该术语的实际含义感到困惑，因为在搜索该主题时通常还会使用诸如软件需求之类的其他术语。

本文的目的是使您对体系结构驱动程序及其在软件体系结构设计过程中的作用有广泛的了解。 稍后，将通过一个真实的示例来支持这些解释，以使您更好地了解在软件项目的初始阶段架构驱动程序的重要性。

什么是架构驱动程序？

理解"架构驱动程序"一词的最简单方法是从字面上进行思考。 架构驱动程序是许多早期制定的决策，它们可以驱动设计过程并为最终的软件体系结构找平道路。 您还可以将它们视为准则，每个软件架构师在考虑所有可能的设计替代方案时应仔细考虑。

在我们继续解释不同类型的体系结构驱动程序之前，重要的是要知道为您的软件体系结构选择正确的驱动程序没有黄金法则。 支持或反对某种体系结构驱动程序的每个决定都会对最终的软件系统及其质量产生重大影响。 几乎所有驱动程序都以一种或另一种方式链接，因此优先考虑一个驱动程序常常会导致另一个驱动程序或一组其他驱动程序的短缺。 不幸的是，这些折衷是不可避免的，您将在后面看到。

这也是为什么本文不被视为完整指南的完全原因，该指南仅需逐步遵循说明，以最终形成完美的软件体系结构。 选择体系结构驱动程序的行为始终在很大程度上取决于上下文，因此，对于不同的目标及其关系，每个决策都应经过深思熟虑。 或者，正如Kamil Grzybek在他的博客中所说的那样：

"我们的每项决定都是在给定的背景下做出的。 每个项目都是不同的(它来自项目定义)，因此每个上下文都是不同的。 这意味着在一种情况下做出的相同决定可以带来巨大的结果，而在另一种情况下则可能导致毁灭性的失败。 因此，在没有批判性思维的情况下使用他人/公司的方法可能会造成很多痛苦，浪费金钱，并最终导致项目结束。"

功能要求，质量属性，约束？ 关于非功能性需求呢？

如前所述，您可能已经在许多其他情况下听说过需求和需求工程的学科。 通常，需求仅分为功能需求和非功能需求。 但是，在体系结构驱动程序的上下文中，这种区分是不幸的，因为人们倾向于将所有发现无法使用的需求都抛弃在一个列表中，而无需三思而后行。 为了能够在设计决策和相关权衡方面做出最佳选择，应该根据以下四个组来讨论体系结构驱动因素：

· 技术约束

· 业务限制

· 功能要求

· 质量属性

> The four groups of architectural drivers

处理项目的约束

约束不属于功能或非功能需求的"经典"类别，但是对于软件体系结构设计过程而言，它们极为重要。 约束为您的项目设置了边界，它们代表了在任何情况下都必须遵守的流程不可谈判的规则。

形象地说，它们一旦被构建，就可以被视为您软件系统的基础。 在项目的生命周期中，您可以决定要实施其他功能而无需付出太多额外的努力，但是以后挑战已建立的框架或编程语言将需要您从头开始重建整个系统。 要了解从一开始就遵守约束的重要性，让我们更深入地研究与设计过程相关的两种不同形式的约束：

1.技术约束

技术约束主要表示开发团队在项目后期执行的非自愿设计选择，这些选择是固定的和不可逆的。 它们通常由内部或外部利益相关者提出，甚至可能被设置为公司中每个项目的公司标准。

以下是一些常见的技术限制示例：

· 编程语言：出于多种原因，可能会决定所选择的编程语言。 这些内容可能包括客户的期望，开发团队的经验或知识，或者贵公司内部对软件许可的受限访问。

· 对特定平台的支持：这些约束通常由客户端自己设置。 如果要求您构建将在Windows或iOS操作系统上分发的软件，则该软件当然必须在这些给定的平台上运行。

· 使用特定的库或框架：您的公司可能会要求您在项目中使用一组特定的开源库或框架，例如 在开发过程中确保与现有IT基础结构的兼容性。 尽管这些约束是由业务利益相关者设置的，但它们对项目的影响具有技术性质。

2.业务约束

就像技术约束一样，业务约束表示影响项目业务方面的不可协商的边界。 示例包括：

· 时间：软件项目通常有固定的时间表，用于定义何时应完成开发阶段或需要将特定工件交付给客户。 基于此设定的时间框架，您只有有限的时间可用于辩论权衡决策或替代方案。

· 预算：类似于时间限制，项目团队通常受合同约束于特定的预算，这限制了可以投资的驱动因素的数量，因此必须做出折衷。

· 团队组成：团队成员和参与者包括的组可以根据项目利益相关者的期望来确定。 出于培训目的而必须包括的实习生。

尽管某些约束的影响可能很明显，但值得注意的是，决不能轻率地决定是否将需求视为项目的约束。 事先问问自己：这是否真的构成了项目的不可商议的约束，还是仅仅是一个非常重要的要求？

在解决此问题时，Michael Keeling在他的博客中提供了另一个非常有用的技巧：

将给定的约束与给自己的约束分开。

该建议应帮助您将实际中不可更改的约束与项目过程中可能遇到的约束区分开来。 后者实际上可能不是约束，而是功能或非功能需求。 您可以在Michael Keeling的这篇博客文章中了解有关约束的更多信息。

3.功能要求

功能需求可能是最成熟的体系结构驱动程序，因为它们的目的最容易掌握。 每个软件都是为了完成特定工作而创建的，功能要求定义了执行预期流程所需的功能。 有很多众所周知的方式和格式来收集有关软件应提供给最终用户的功能的信息，例如用户故事或用例。 但是，尽管绝对有必要了解利益相关者期望的功能，但是在需求工程过程中，许多软件项目对软件体系结构的这种单方面观点给予了过分的重视。 功能是必不可少的，但实际上并不能以任何方式决定软件的架构。

实际上，如果功能是您唯一关心的问题，那么实际上将有无限多种可能的体系结构设计可供选择。 您甚至可以大加小心，将所有代码放入一个单独的整体软件块中。 但是，尽管这种架构(或者说缺乏架构)可能仅从功能的角度完成工作，但该软件如此缓慢，不安全或笨拙以至于无法满足最终用户和您的需求的可能性不大 利益相关者。 更不用说重构没有内部结构的软件的绝对麻烦了，这将使您的维护成本大打折扣。 这就是为什么在当今软件产品变得越来越复杂的数字时代，在系统生命周期中增加的大部分成本通常可以归因于软件发布后进行维护活动的需要。

因此，仅确保软件能够完成预期的工作还不够。 相反，您应该根据不同的设计方案对利益相关者对系统质量的期望的支持程度来进行比较。

4.质量属性

这就是质量属性发挥作用的地方。 顾名思义，它们描述了软件的适用性或质量，因此可能会对体系结构设计产生重大影响。 就像功能需求在软件体系结构规划期间永远不应成为您的单一信息源一样，质量属性也不能独立讨论：它们总是在执行方面始终引用特定的系统功能。

例如，桌面应用程序所需的功能可能是用户单击按钮后对话框的外观。 然后，质量属性将说明对此功能的量化要求，例如"用户单击按钮后，对话框应在两秒钟内出现。"

此示例还显示质量属性应始终可测量并尽可能精确地指定，不留任何解释空间。 诸如"我们的系统应该快速"或"我们希望我们的软件对用户友好"之类的模糊陈述完全是主观的，因此无法评估系统的功能。

> The most prominent quality attributes

如何引出并指定它们

如果您是应该构建新软件或改编现有软件系统的软件架构师，那么如果您的客户只给您列出所有相关质量属性并进行整齐排列并描述的列表，那么显然可以使您的工作变得容易得多 彻底 但是，经验表明，尽管经常详细描述功能需求，但许多客户要么不清楚哪个质量属性与其特定领域最相关，要么对系统应具备的所有质量只有模糊，高度不切实际的概念 。 因此，软件架构师必须积极与不同的利益相关者团体进行对话，以探索最重要的属性，并尝试将其视为没有技术背景的人的视角。

使这项任务变得更加苛刻的原因是，并非每个客户似乎都意识到所有质量属性都会相互影响这一事实，而要避免折衷几乎是不可能的。 在安全性被视为最重要原则的处理敏感个人数据的系统中，很可能会遭受广泛的保护措施，从而对系统的性能产生负面影响。 但是，如果您直接问客户他们对系统质量的期望是什么样的，那么对话很可能是这样的：

架构师："您对系统可用性有什么期望？"

客户端："哦，系统应该运行24/7。 我们无法让用户尝试访问该站点都无济于事。"

架构师："好的，关于软件的安全性，您需要什么样的结构来保护用户数据？"

客户："请全部。"

如果发生这种情况，则需要确保客户端了解不同的质量属性组合如何相互影响。 要求他们使用MoSCoW方法或简单的高/中/低比例来优先考虑捕获的需求。 他们可能很难区分必要属性和"必须具备"类别的属性，因此请尝试从项目业务方面入手。 举例来说，要提到一个系统，该系统在99.999％的时间内可用，而可用性稍低的情况下，它将增加项目成本。 然后，他们可能会意识到这种质量并不是真正的优先事项。

一段时间后，您应该对在设计软件体系结构时需要优先考虑的质量属性有更好的了解。

> Possible trade-off between two quality attributes

情境

您现在应该做的是以一种可以使您衡量并随后测试系统满足这些要求的程度的方式对它们进行形式化。 描述软件系统中质量属性的一种好方法是使用由以下元素组成的方案：

· 刺激：这个术语是指由系统触发特定反应的事件。 常见的示例是传入的用户请求，甚至是攻击，尽管在开发团队内部发生的更多抽象事件(例如项目阶段的完成)可能会引发有关软件质量的特定操作。

· 刺激源：传入事件的来源通常决定系统如何处理它。 可信的，经过身份验证的用户的请求将不会与未经认证的来源发出的响应相同。

· 环境：就像刺激的来源一样，其到达的环境有时会影响系统的响应，因此需要在场景激发期间加以考虑。 处于修复模式的软件可能更容易受到攻击，因此更有可能关闭以保护其数据，而在正常操作模式下对系统的防御可能更具弹性。

· 工件：在某些情况下，质量要求不会影响整个系统，而是会影响整个系统的一部分，如果要确保可以对系统进行准确评估，则需要指定质量要求。

· 响应：这指定系统应如何应对新的刺激。

· 响应措施：如前所述，对质量属性的需求需要进行量化，以便能够相应地评估系统的功能。 系统在执行预定响应时满足这些限制(例如反应时间或特定吞吐量)的能力决定了该软件是否适合使用，并符合利益相关者的期望。

> General scenario structure

为了让您对软件系统需要满足的可能要求有更实际的了解，我们将介绍六个最突出的质量属性。 当然，该列表并不详尽，其中包含更多相关子类别和其他质量属性，对于您的特定业务环境和系统类型可能需要考虑这些属性，但是这些代表了大多数软件系统所遵循的基本驱动程序 或其他。 Bass等人在《实践中的软件体系结构》一书中对质量属性的方案进行了更详细的描述。

性能

性能的质量属性与系统通过响应诸如传入请求或用户输入之类的事件来满足时序要求的能力有关。 从历史上看，这种要求在很长一段时间以来一直主导着架构设计的非功能性方面，尽管功能强大的硬件的价格不断下降使公司可以专注于其他同样重要的质量方面。 然而，性能仍然是关键的质量属性，其缺点可能会对整个系统及其用户的感知产生负面影响。 衡量性能要求的常用方法包括：

· 延迟：刺激到达与可观察到的系统响应之间的延迟。

· 吞吐量：在指定时间范围内可以处理的交易数量。

互通性

当系统应该与一个或多个系统通信时，需要互操作性。 它既需要交换数据的能力(语法互操作性)，又需要正确解释信息并从中提取含义的能力(语义互操作性)。 我始终不需要通过检查特定的使用环境并相应地设计架构来评估所需的互操作性。 有完善的标准和外部API供您选择，尽管它们并不能始终保证多个系统的长期完美集成：挑战涉及从隐私或安全性方面的法律问题到新软件版本创建后的昂贵维护成本 系统通讯中的问题。

可维护性

成为成功的软件架构师的一个不可或缺的部分是，认识到变更是不可避免的。 开发过程不会随着系统的发布而结束，在许多情况下，这是真正的工作开始累积的时候。 需要包括错误修复，新的功能要求或技术更新，因此，一个结构合理且简洁的系统可以支持将来的更改，这使适应设计变得更加容易，尤其是如果您的团队中不熟悉实际的新手 码。 为了允许在不降低质量的情况下修改软件系统，通常建议创建较小的，松散耦合的模块，并具有强大的凝聚力。

易用性

可用性是最重要的质量属性之一，因为它直接影响用户满意度，最终可能会决定用户是否会坚持使用您的系统或感到沮丧，并在其他地方寻找替代方案。 它描述了系统设计在多大程度上允许用户有效地实现其目标以及在浏览软件时带来的主观用户体验。 因此，有许多策略可以使系统变得更加用户友好，包括：

· 可学习性：系统的设计方式应使不熟悉该软件的人能够快速直观地学习如何使用该软件，而有经验的用户则应轻松选择新功能。

· 视觉设计：简洁，一致的布局使用其颜色或字体，不仅可以提高可读性，而且可以大大简化成功使用系统的过程。

可靠性

可靠性与软件系统在预定条件下随着时间的推移继续运行的能力有关。 通常，用于定义系统可靠性的一个重要子类别是可用性，因为软件系统通常由于一个或多个组件的不可访问性而无法运行。 诸如可用性百分比(可用系统时间与总工作时间之比)之类的指标通常在所谓的"服务水平协议"中找到，该协议定义了可以容忍的特定停机时间，可用于计划系统升级，计划维护 或意外故障。 如果系统能够及时掩盖或修复故障，从而不会导致外界可见的崩溃，那么也可以实现正常运行时间。

安全

安全性描述了系统能够保护敏感数据免遭未经授权的访问并处理各种形式的外部攻击的程度。 因此，它是许多业务应用程序(尤其是基于Web的系统)最不可或缺的质量属性之一。 安全措施可以分类如下：

· 机密性：未经授权的系统，人员或流程无法访问数据或服务。

· 完整性：未经授权的系统，人员或流程无法操纵信息。

· 可用性：尽管遭受了诸如拒绝服务之类的攻击，该系统仍保持完好无损并可供合法使用。

通过Web应用程序和Firefox将其整合在一起

在讨论了软件设计过程中体系结构驱动程序的基本概念和原理之后，现在让我们集中在一个真实的示例上，以说明如何在实际软件项目中应用权衡和方案。 由于功能需求和相关技术已经在各种研究和科学著作中进行了广泛讨论，因此我们将本示例仅限于描述质量属性。 同样，约束条件不仅在很大程度上取决于上下文，而且还构成与项目的财务和组织布局有关的相当敏感的数据，这就是为什么从外部角度来看这些约束条件不易获得的原因。 为了使您对质量属性进行设计，我们将探索开源Web浏览器Firefox的安全优先级如何影响其他质量属性，并研究直接源自Firefox安全实践的方案。

安全性及其取舍

因为Web浏览器充当希望导航Internet的用户的载体，所以他们对服务质量的要求在某种程度上反映了使用此基础结构的Web应用程序需要满足的那些要求。 自然，当今网络应用程序的复杂性需要考虑很多质量属性，但是为了使事情简洁，我们将根据最近的研究来研究三个最重要的质量属性，即安全性，可靠性和可用性。

作为主要网络浏览器之间激烈竞争的一个组成部分，安全措施的优先级对Firefox至关重要，尤其是考虑到以下事实：当今，各种商务交易和个人数据都是通过Web处理的，因此需要对其进行保护， 获得用户的信任。 但是，将安全放在设计过程的中心需要进行许多权衡，而其他质量属性也将从此优先级中受益。

后者是关于可靠性的情况：Web应用程序经常受到系统的攻击，试图通过向其泛滥请求来使其服务不可用。 作为Internet上任何类型的Web应用程序的看门人，采用多种安全机制以防止这些拒绝服务攻击的Web浏览器会自动提高其服务的可用性，从而可能减少停机时间。 因此，可以说，对系统安全性进行投资本质上可以满足其可靠性目标。

对于安全性和可用性之间的权衡并不能避免很多折衷。例如，Firefox团队决定实施一个沙箱环​境，该沙箱环境在用户执行任何类型的金融交易时都会被激活。此沙盒环境可保护用户的数据免受恶意攻击或中间人利用，但同时也迫使用户打开一个额外的窗口，该窗口只能用于此操作，需要在会话结束后手动关闭。尽管创建过程是为了提高用户在此过程中的安全性，但缺乏自动化却很麻烦，并且可能会妨碍用户体验。另一个设计选择强调了Firefox如何处理Java插件，该设计选择突出了Firefox如何使所有用户的安全优先于某些人对该服务的满意度。为了保护用户，如果制造商尚未解决该插件的已知问题，Firefox将默认禁用Java插件，从而导致许多网站和应用程序上无法显示内容。

这些示例说明了全面的安全策略对Firefox的业务模型和竞争能力的重要性，接受了权衡取舍的做法，认为这样做有必要减少用户体验，而无需付出太多额外努力即可提高其服务的可靠性。

现在，我们要向您提供两种示例性安全措施，以场景的形式指定Firefox针对此质量属性的内部标准。 如前所述，这些是从Firefox的在线安全实践中获得的(此处有更多信息)。 第一种情况研究了错误修复的组织处理，描述了内部如何处理发现的系统漏洞。 第二种情况从技术层面检查了系统对用户计算机上未遂攻击的反应。

1.方案(安全性)：利用易受攻击的Javascript插件进行ReDoS攻击