【架构师】软件架构评估例题

请详细阅读有关软件架构评估方面的说明，在答题纸上回答问题1至问题2
【说明】某电子商务公司拟升级目前正在使用的在线交易系统，以提高客户网上购物时在线支付环节的效率和安全性。公司研发部门在需求分析的基础上，给出了在线交易系统的架构设计。公司组织相关人员召开了针对架构设计的评估会议，会上用户提出的需求、架构师识别的关键质量属性场景和评价估专家的意见等内容部分列举如下：
a)在正常负载情况下，系统必须在0.5秒内响应用户的交易请求；
(b)用户的信用卡支付必须保证99.999%的安全性
(c)系统升级后用户名要求至少包含8个字符号
(d)网络失效后，系统需要在2分钟内发现错误并启用备用系统…题目过长已省略部分信息
💡解答

问题 1：请分析上述说明中所涉及的关键质量属性场景，并进行分类。

关键质量属性场景分类如下：

性能：

在正常负载情况下，系统必须在 0.5 秒内响应用户的交易请求。
在高峰负载情况下，用户发起支付请求后系统必须在 10 秒内完成支付功能。

安全性：

用户的信用卡支付必须保证 99.999%的安全性。
系统拟采用新的加密算法，这会提高系统安全性，但同时会降低系统的性能。
用户信息数据库授权必须保证 99.999%可用。

可用性：

网络失效后，系统需要在 2 分钟内发现错误并启用备用系统。
主站点断电后，需要在 3 秒内将访问请求重定向到备用站点。

可修改性：

现有架构设计中的支付部分与第三方支付平台紧耦合，当系统需要支持新的支付平台时，这种设计会导致支付部分代码的修改，影响系统的可修改性。

可扩展性：

系统需要为后端工程师提供远程调试接口，并支持远程调试。

开发期质量属性：

需要在 30 人月内为系统添加公司新购买的事务处理中间件。
系统需要对 Web 界面风格进行修改，修改工作必须在 4 人月内完成。

理由：根据关键质量属性场景的常见分类，将上述需求分别归类到性能、安全性、可用性、可修改性、可扩展性和开发期质量属性等类别中，以便更清晰地理解和分析系统的质量要求。

问题 2：请根据上述说明，指出可能影响系统架构设计的因素。

可能影响系统架构设计的因素有：

性能方面的要求，如在正常和高峰负载下的响应时间限制，这会影响系统的硬件配置、软件算法和数据结构的设计。
安全性方面的高要求，如信用卡支付和用户信息数据库授权的安全性，可能需要采用更复杂的加密技术和安全机制，影响系统的架构和模块设计。
可用性方面的要求，如网络失效和主站点断电后的快速响应和切换，需要设计可靠的备份和恢复机制。
可修改性方面，支付部分与第三方支付平台的紧耦合会限制系统对新支付平台的支持，需要重新设计支付模块的架构以提高可修改性。
开发期的时间限制，如添加事务处理中间件和修改 Web 界面风格的人月限制，会影响开发进度和资源分配。

理由：这些因素直接关系到系统的功能实现、性能表现、稳定性和可维护性等方面，对系统架构的设计决策具有重要影响。在进行架构设计时，需要充分考虑这些因素，以确保系统能够满足各项质量属性的要求。

阅读以下关于软件架构风格的说明，在答题纸上回答问题1和问题2。
【说明】某软件公司为其新推出的字处理软件设计了一种脚本语言，专门用于开发该字处理软件的附加功能插件，为高该语言的编程效率，公司组织软件工具开发部门为脚本语言研制一套集成开发环境，软件工具开发部门根据字处开的特点，对集成开发环境进行了需求分析，总结出以下3项核心需求：
(1)集成开发环境需要提供对脚本语言的编辑、语法检查、解释、执行和调试等功能的支持，并要实现各种功能的灵历性配置与替换.
(2)集成开发环境需要提供一组可视化的编程界面，用户通过对界面元素拖拽和代码填充的方式就可以完成功能插件核务流程的编写与组织.
(3)在代…题目过长已省略部分信息
💡解答

问题 1：请分析采用以数据存储为中心的架构风格的原因。

采用以数据存储为中心的架构风格的原因主要有以下几点：
首先，需求中提到集成开发环境需要实现各种功能的灵活性配置与替换。以数据存储为中心的架构风格能够将各种功能相关的数据集中存储和管理，便于对功能进行灵活的配置和调整。
其次，需求中要求提供一组可视化的编程界面，用户通过对界面元素拖拽和代码填充的方式完成功能插件核心流程的编写与组织。这种架构风格有利于集中管理和组织编程过程中涉及的数据，更好地支持可视化编程界面的实现。
最后，在代码调试功能方面，需要实现在脚本语言编辑界面中的代码自动定位功能。以数据存储为中心的架构能够更有效地管理和快速定位代码相关的数据，从而满足自动定位的需求。

问题 2：请简述以数据存储为中心的架构风格的特点。

以数据存储为中心的架构风格具有以下特点：
它强调数据的集中存储和管理，数据处于核心地位。
各个组件或模块围绕数据进行交互和协作。
这种架构风格通常具有较高的数据一致性和数据共享性。
对数据的访问和操作相对较为统一和规范，便于管理和维护。
能够较好地支持复杂的数据处理和数据驱动的应用场景。

【问题1】请用200字以内的文字解释什么是软件架构风格，并从集成开发环境与用户的交互方式集成开发环境的扩展性、集成开发环境的数据管理三个方面说明为什么最终采用了李工的设计方案
【问题2】在对软件系统架构进行设计时，要对架构需求进行分析，针对特定需求选择最为合适的架构风格，因此实际的软件系统通常会混合多种软件架构风格。请对核心需求进行分析，说明为了满足需求(2)和(3)，分别应采用何种架构风格，并概要说明采用相应架构风格后的架构设计过程。
💡解答

软件架构风格是指软件系统在设计和组织上的一种模式和特点。

李工的设计方案被采用，可能是因为在与用户的交互方式上更便捷高效，扩展性方面能更好适应未来变化，数据管理上更安全可靠、易于维护。

对于需求（2）和（3），需先明确具体需求内容，再分析其特点。若需求强调灵活性和可扩展性，可能采用微服务架构风格，设计时将系统拆分为多个独立服务。若需求注重性能和数据一致性，可能采用分层架构风格，按层次清晰划分功能模块。

———

需求（2）是否采用解释器架构风格，取决于需求（2）的具体内容和特点。

一般来说，如果需求（2）涉及到需要对特定的语言或规则进行解释和执行，并且对灵活性和动态性有较高要求，那么可能会考虑采用解释器架构风格。

但如果需求（2）更侧重于系统的性能、可扩展性或者数据一致性等方面，可能解释器架构风格就不是最优选择。

所以，不能简单地判定需求（2）一定应该或不应该采用解释器架构风格，要具体问题具体分析。

管道-过滤器架构风格是一种软件架构模式。
在这种风格中，系统被分解为一系列的过滤器组件，每个过滤器独立完成特定的处理功能。
数据通过管道在过滤器之间传递。
过滤器对输入的数据进行处理，并将处理结果通过管道传递给下一个过滤器。
其特点包括：

功能分解明确，每个过滤器专注于一项任务。
易于理解和维护，可独立修改过滤器而不影响其他部分。
支持并发处理，多个过滤器可同时工作。

以数据存储为中心的架构风格，是将数据的存储和管理作为系统的核心。
在这种架构风格中：

数据处于中心地位，系统的各个组件围绕数据展开工作。
数据的一致性和完整性得到高度重视。
数据的访问和操作有严格的规则和控制。
其他组件如处理逻辑和用户界面，主要依赖于对数据的读取、更新和处理。
这种架构风格适用于数据量较大、数据处理复杂且对数据一致性要求高的系统。

富互联网应用RIA：弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下：
RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；
RIA简化并改进了B/S架构的用户交互: 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面.
本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典的如小程序.
💡解答

以下是对这段关于富互联网应用（RIA）的内容的逐步分析和解释：

首先，这段文字开篇指出 RIA 是为了弥补三层 B/S 架构存在的问题而出现的，它是一种特殊的用户接口。

接着，提到 RIA 具有一些优点。它结合了 C/S 架构和 B/S 架构的优势。C/S 架构的优点是反应速度快、交互性强，B/S 架构的优点是传播范围广且容易传播，RIA 把这两者的优点融合在了一起。

然后，强调 RIA 简化并改进了 B/S 架构的用户交互。因为数据能够被缓存在客户端，所以能实现比基于 HTML 的用户界面响应速度更快，并且减少了数据往返服务器的次数。

最后，说明 RIA 本质上还是零客户端，依靠高速网速能快速在本地缓存必要插件，从而增强了对动态页面的支持能力，比如典型的小程序。

总的来说，RIA 是一种在用户接口和交互方面具有优势的技术模式，通过融合不同架构的优点和利用缓存等技术，提升了用户体验和应用的性能。

MVP是把MVC中的Controller换成了Presenter(呈现)，目的就是为了完全切断View跟Model之间的联系，由 Presenter充当桥梁，做到View-Model之间通信的完全隔离。
MVP特点： M、V、P之间双向通信 View与Model不通信，都通过Presenter传递，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里 View非常薄，不部署任何业务逻辑，称为"被动视图"(PassiveView)，即没有任何主动性，而Presenter非常厚、所有逻辑都在那里 Presenter与具体的View是没有直接关联的，而是通过…题目过长已省略部分信息
💡解答

以下是对 MVP 模式中 View、Presenter、Model 关系的逐步解释：

首先，MVP 模式的核心目的是完全切断 View（视图）跟 Model（模型）之间的直接联系。

在这个模式中：

Model（模型）：负责处理数据的获取、存储、更新等操作，是数据的来源和处理中心。
View（视图）：它非常薄，不部署任何业务逻辑，被称为“被动视图”。这意味着 View 没有主动性，只是用于展示数据和接收用户的输入，然后将这些输入传递给 Presenter 处理。
Presenter（呈现器）：起到了关键的桥梁作用。它完全把 Model 和 View 进行了分离，接收来自 View 的用户操作和请求，然后从 Model 中获取相应的数据，经过处理后再将数据传递给 View 进行展示。

View 与 Model 不直接通信，所有的通信都通过 Presenter 来传递。

Presenter 与具体的 View 没有直接关联，而是通过定义好的接口进行交互。这带来的好处是，当需要变更 View 的时候，可以保持 Presenter 不变，从而实现 Presenter 的重用，提高了代码的可维护性和可扩展性。

总的来说，MVP 模式通过 Presenter 有效地隔离了 View 和 Model，使得各部分的职责更加清晰，提高了系统的灵活性和可维护性。

以下是 MVP 和 MVC 架构的比较：

通信方式：

MVP：View 与 Model 不通信，都通过 Presenter 传递。
MVC：View 可以直接与 Model 通信。

View 的角色：

MVP：View 非常薄，是“被动视图”，不部署任何业务逻辑。
MVC：View 相对较厚，可能包含一些简单的逻辑。

Presenter 的作用：

MVP：Presenter 充当 View 和 Model 之间的完全隔离桥梁，所有逻辑都在其中。
MVC：Controller 主要负责协调 View 和 Model 的交互，逻辑相对较少。

代码复用性：

MVP：Presenter 与具体的 View 通过定义好的接口交互，变更 View 时可保持 Presenter 不变，利于复用。
MVC：Controller 与 View 的绑定较紧密，View 变更时可能需要较大调整。

总的来说，MVP 架构通过 Presenter 更彻底地隔离了 View 和 Model，使各部分职责更清晰，提高了系统的灵活性和可维护性；而 MVC 架构相对来说各部分的耦合度稍高。

故障诊断和快速恢复能力是性能需求？

💡解答

故障诊断和快速恢复能力可以被视为性能需求的一部分。

故障诊断能力：能够及时、准确地发现系统中出现的故障或问题，这对于保持系统的稳定运行至关重要。

它需要有效的监测机制和智能的分析工具，以快速定位故障的源头。

快速恢复能力：在发现故障后，能够迅速采取措施使系统恢复到正常状态。

这要求有备份和恢复策略、冗余设计等保障手段。

总之，故障诊断和快速恢复能力对于确保系统的高性能和持续可用性具有重要意义。

软件工程-结构化的分析方法
结构化特点：自顶向下，逐步分解，面向数据。
草三大模型：功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典。
数据字典：数据字典是在DFD的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。
状态转换田(STD) √状态（初态、终态）数据流行为模型数据存储外据出体数据元素 ao 数据结构数据流数据存储功能模型数据汤围（DO）数据模型加工逻辑外部实体
💡解答

同学，下面为您逐步讲解这些内容：

首先，结构化分析方法具有“自顶向下，逐步分解，面向数据”的特点。

“自顶向下”意味着从系统的整体功能出发，逐步细化到各个子功能和模块。这样可以保证系统的整体性和完整性，避免遗漏重要的部分。

“逐步分解”是将复杂的大问题分解为若干个相对简单的小问题，便于理解和处理。

“面向数据”强调在分析过程中重视数据的流动、存储和处理。

接着，三大模型分别是功能模型（数据流图）、行为模型（状态转换图）和数据模型（E-R 图）以及数据字典。

功能模型中的数据流图（DFD）用于描述系统中数据的流动和处理过程。

行为模型里的状态转换图（STD），通过状态（如初态、终态）的转换来展现系统的行为。

数据模型的 E-R 图用于描述系统中的实体、属性以及它们之间的关系。

数据字典则是在 DFD 的基础上，对其中出现的所有命名元素进行定义，让每个图形元素的名字都有清晰确切的解释。DFD 和数据字典相互配合，就能从图形和文字两个方面完整地描述系统的逻辑模型。

———

DFD 即数据流图（Data Flow Diagram）。

它是结构化分析方法中功能模型的重要组成部分。
用于描述系统中数据的流动和处理过程。
以图形的方式展示了系统内数据从输入到输出的流动路径，以及在这个过程中数据的转换和处理。

DFD 能够清晰地呈现系统中各个部分之间的数据交互关系，帮助分析人员理解系统的功能和逻辑。

通过 DFD，可以直观地了解系统的主要功能、数据的来源和去向，以及数据在系统中的处理步骤。这对于系统的设计、分析和优化都具有重要的意义。

最长工期 41天，最短工期27天。

数据库系统-数据库分类
关系型数据库：关系数据库，是建立在关系模型基础上的数据库，借助集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。简单说，关系型数据库是由多张能互相联接的二维行列表格组成的数据库. NoSQL：泛指非关系型的数据库。Non-Relational或者是Not Only SQL，泛指非关系型数据库，区分开关系型数据库，并且不保证关系型数据库的ACID特性。
列式存储数据库：跟传统的关系型数据库一样，数据按行列进行存储，这种类别通常用来应对分布式数据库的存储海量数据，比如HBase 键值对存储数据库：以key-va…题目过长已省略部分信息
💡解答

同学，下面咱们来逐步梳理一下这些数据库分类的重点内容：

首先是关系型数据库：
它建立在关系模型基础上，通过集合代数等数学概念和方法处理数据。在现实世界中，各种实体及它们之间的联系都用关系模型来表示。简单来讲，就是由多张能相互联接的二维行列表格组成。

然后是 NoSQL 数据库：
它泛指非关系型数据库，不保证关系型数据库的 ACID 特性。

接着说列式存储数据库：
和传统关系型数据库一样按行列存储数据，常用来应对分布式数据库中存储海量数据的情况，例如 HBase 。

再看键值对存储数据库：
以 key - value 的形式存储数据，具有简单、容易部署的特点，像 Redis 就是这类。

文档型数据库：
类似于键值对数据库，可视为其升级版，允许嵌套键值，处理复杂数据时比传统键值对存储效率高，比如 MongoDB 。

还有图数据库：
使用灵活的图形模型存储数据，能拓展到多个服务器，适合存储通过图建模的数据，像社交网络、交通网络等，常见产品有 Neo4J 。

NoSQL 的特征包括易拓展、大数据量、高性能、灵活的数据模型和高可用。

NoSQL 适用的场景有：数据模型简单、需要更灵活的系统、对数据性能要求高以及不需要高度的数据一致性。

数据库系统-范式

以下为对这些范式的详细解释和示例：

第一范式（1NF）：

要求表中的所有字段都是不可分割的原子值，不能有小表存在。
例如，“学生信息”表中，“姓名”字段不能再分为“姓”和“名”两个字段来存储，必须作为一个整体的原子值。

第二范式（2NF）：

基于 1NF，每个非主属性完全依赖于某一个候选键。
比如，有一个“订单详情”表，包含“订单号”、“商品号”、“商品数量”、“商品单价”。“订单号”和“商品号”组成联合主键。但“商品单价”只依赖于“商品号”，不满足 2NF。应将其拆分为“商品”表（“商品号”，“商品单价”）和“订单详情”表（“订单号”，“商品号”，“商品数量”）。（这里假设商品价格不变）

第三范式（3NF）：

基于 2NF，每个非主属性不依赖于其它非主属性，只与主键直接相关，不能存在传递依赖。
假设一个“员工”表，有“员工编号”（主键）、“部门编号”、“部门名称”。“部门名称”依赖于“部门编号”，存在传递依赖，不满足 3NF。应将其拆分为“员工”表（“员工编号”，“部门编号”）和“部门”表（“部门编号”，“部门名称”）。

BC 范式（BCNF）：

是 3NF 的补充，要求所有属性都只依赖主键，主属性也不能传递或部分依赖于码。
例如，“课程安排”表，有“课程号”、“教师号”、“教室号”，假设“课程号”和“教师号”共同决定“教室号”，但“教师号”单独不能决定“教室号”，不满足 BCNF。

第四范式（4NF）：

基于 3NF，要求一个表的主键只对应一个多值。
像“学生信息表(学生 ID, 住址, 电话号码)”，住址和电话号码与学生 ID 存在多值依赖关系。可通过程序控制或拆分为“学生信息”表（“学生 ID”）、“学生住址”表（“学生 ID”，“住址”）、“学生电话号码”表（“学生 ID”，“电话号码”）来满足 4NF。

——

BCNF（Boyce-Codd Normal Form，博伊斯-科德范式）是数据库范式理论中的一种范式，它是对第三范式（3NF）的进一步加强。一个关系模式如果处于第三范式，并且它的每一个非平凡函数依赖（non-trivial functional dependency，即非平凡函数依赖是指依赖关系左边的属性不是右边的子集）X → Y，X都是超键（superkey），那么这个关系模式就处于BCNF。
超键：在关系模式中，能够唯一标识每个元组的属性集。
非平凡函数依赖：如果X → Y，则称X是Y的候选确定因素。如果X是属性集合，Y是属性集合，X → Y是非平凡函数依赖，当且仅当X和Y都不是空集，并且X不包含Y。
BCNF的条件：对于关系模式R(U)中的每一个非平凡函数依赖X → A，X必须是超键。
BCNF范式的目的：消除插入异常、更新异常和删除异常。
BCNF范式的优点：

确保数据库表结构的合理性，减少数据冗余。
降低数据操作的复杂性。
减少数据异常的可能性。
BCNF范式的转换：如果一个关系模式不满足BCNF，可以通过分解（decomposition）操作将其转换为BCNF。分解的目的是将原表分解为多个表，使得每个表都满足BCNF。
分解的规则：
找出所有不满足BCNF的非平凡函数依赖。
对于每个不满足BCNF的依赖X → A，将原表分解为两个新表：

一个新表包含属性集X∪{A}。
另一个新表包含原表中剩余的属性。
分解的注意事项：

分解可能会增加表的数量，增加数据操作的复杂性。
分解应该尽量保持数据的局部性，避免过多的表连接操作。
例子：
假设有一个关系模式R(学生ID, 课程号, 教师ID)，并且存在以下函数依赖：
学生ID → 课程号
课程号 → 教师ID
这个关系模式不满足BCNF，因为课程号 → 教师ID中，课程号不是超键（因为学生ID和课程号的组合才能唯一确定记录）。
分解为两个关系模式：
R1(学生ID, 课程号)
R2(课程号, 教师ID)
这样，每个新的关系模式都满足BCNF。
BCNF是数据库设计中的一个重要概念，它有助于设计出结构良好、没有数据冗余和异常的数据库。

——-

下面是1NF（第一范式）、2NF（第二范式）、3NF（第三范式）和BCNF（博伊斯-科德范式）的比较表格：