• 点击跳转专栏=>Unity3D特效百例
• 点击跳转专栏=>案例项目实战源码
• 点击跳转专栏=>游戏脚本-辅助自动化
• 点击跳转专栏=>Android控件全解手册
• 点击跳转专栏=>Scratch编程案例
• 点击跳转=>软考全系列

👉关于作者

专注于Android/Unity和各种游戏开发技巧，以及各种资源分享（网站、工具、素材、源码、游戏等）
有什么需要欢迎底部卡片私我，获取更多支持，交流让学习不再孤单。

👉实践过程

需要所有整理的文档可底部卡片联系我，直接发压缩包。

软件架构风格

软件架构风格是描述某一类特定应用领域中软件系统组织方式和惯用方式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

面向对象架构风格的特征是将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身表示的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程。

控制环路架构风格是将过程输出的指定属性维护在一个特定的参考值（设定点）。控制环路风格包括过程变量、被控变量、输入变量、操纵变量和设定点等构件，通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态。

主程序-子程序架构风格中，所有的计算构件作为子程序协作工作，并由一个主程序 顺序地调用这些子程序，构件通过共享存储区交换数据。

管道-过滤器架构风格中，每个构件都有一组输入和输出，构件接受数据输入，经过内部处理，然后产生数据输出。这里的构件称为过滤器，构件之间的连接件称为数据流传输的管道。

比较因素	管道-过滤器风格	数据仓储风格
交互方式	顺序结构或有限的循环结构	星型
数据结构	数据流	文件或模型
控制结构	数据流驱动	业务功能驱动
扩展方法	接口适配	模型适配

软件质量属性

常见的软件质量属性有多种，例如性能（Performance)、可用性（Availability)、可 靠性（Reliability)、健壮性（Robustness)、安全性（Security)、可修改性（Modification)、可变性(Changeability)、易用性(Usability)、可测试性(Testability)、功能性(Functionality) 和互操作性（Inter-operation)等。

这些质量属性的具体含义是：

(1) 性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。

(2) 可用性是系统能够正常运行的时间比例。

(3) 可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。

(4) 健壮性是指在处理或环境中，系统能够承受压力或变更的能力。

(5) 安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。

(6) 可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。

(7) 可变性是指体系结构经扩充或变更成为新体系结构的能力。

(8) 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。

(9) 可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。

(10) 功能性是系统所能完成所期望工作的能力。

(11) 互操作性是指系统与外界或系统与系统之间的相互作用能力。

质量属性的架构设计策略△

(1) 在线交易平台必须在Is内完成客户的交易请求。该要求主要对应性能，可以采用的架构设计策略有增加计算资源、改善资源需求（减少计算复杂度等)、资源管理（并发、数据复制等）和资源调度（先进先出队列、优先级队列等）。

(2) 该平台必须严格保证客户个人信息和交易信息的保密性和安全性。该要求主要对应安全性，可以采用的架构设计策略有抵御攻击（授权、认证和限制访问等)、攻击检测（入侵检测等)、从攻击中恢复（部分可用性策略）和信息审计等。

(3) 当发生故障时，该平台的平均故障恢复时间必须小于10s。该要求主要对应可用性，可以采用的架构设计策略有Ping/Edio、心跳、异常和主动冗余等。

(4) 由于企业业务发展较快，需要经常为该平台添加新功能或进行硬件升级。添加新功能或进行平台升级必须在6小时内完成。该要求主要对应可修改性，可以采用的架构设计策略有软件模块泛化、限制模块之间通信、使用中介和延迟绑定等。

系统架构设计中的非功能性需求

系统性能需求（Performance Requirements）：指响应时间、吞吐量、准确性、有效性、资源利用率等与系统完成任务效率相关的指标。可靠性、可用性等指标归为此类。

安全性需求（Security Requirements）：系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。

操作性需求（Operational Requirements）:与用户操作使用系统相关的一些需求。

文化需求（Cultural Requirements）：带有文化背景因素的系统需求。

系统架构风险、敏感点和权衡点的定义

系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

敏感点是指为了实现某种特定的质量属性，一个或多个系统组件所具有的特性。权衡点是指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。

质量效用树（utility tree）

在架构评估过程中，质量属性效用树（utility tree)是对系统质量属性进行识别和优先级排序的重要工具。效用树主要关注性能、可修改性、可用性和安全4个方面

系统可靠性△

系统在规定的时间内及规定的环境条件下，完成规定功能的能力，就是系统无故障运行的概率。

根据国家标准《软件工程产品质量第1部分：质量模型》(GB/T16260.1—2006)的规定，系统可靠性包括：成熟性、容错性、易恢复性和可靠性的依从性4个子特性。

提高系统可靠性一般采用以下4类技术：

(1) 冗余技术；

(2) 软件容错技术；

(3) 双机容错技术；

(4) 集群技术。

**软件的可靠性设计主要包括了恢复块和N版本程序设计两种方法。**恢复块方法是一种反向恢复的方法，其核心原理是：对于可靠性要求高的软件，在程序运行的某时刻，将数据或程序进行备份，一旦发现主程序块有异常发生时，可将已备份的数据或程序进行恢复，保证程序的正确性。

1. 恢复块方法：

(1) 主块

(2) 验证测试

(3) 输出正确结果

(4) 异常处理

2. 恢复块方法与N版本程序设计的比较

(5) 表决

(6) 反向恢复

(7) 差

(8) 好

动态冗余和N版本程序设计技术

动态冗余又称为主动冗余，它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来替代它并重新运行。各备用模块在其待机时，可与主模块一样工作，也可以不工作。前者叫热备份系统（双重系统），后者叫冷备份系统（双工系统、双份系统)。N版本程序设计是一种静态的故障屏蔽技术，其设计思想是用N个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。其中N个版本的程序必须由不同的人独立设计，使用不同的方法、设计语言、开发环境和工具来实现，目的是减少N个版本的程序在表决点上相关错误的概率。

M2采用动态冗余后的可靠度为：R=1- (1-0.99) 3 = 0.999999

李工给出的方案同时采用了串联和并联方式，其计算方法为首先计算出中间M2和M3两个并联系统的可靠度，再按照串联系统的计算方法计算出整个系统的可靠度。

R = 0.99 * 0.999999 * 0.999999 * 0.99 = 0.98

检错技术的优缺点，常见的实现方式和处理方式。

检错技术实现的代价一般低于容错技术和冗余技术，但有一个明显的缺点，就是不能自动解决故障，出现故障后如果不进行人工干预，将最终导致软件系统不能正常运行。

检错技术常见的实现方式：最直接的一种实现方式是判断返回结果，如果返回结果 超出正常范围，则进行异常处理；计算运行时间也是一种常用技术，如果某个模块或函数运行时间超过预期时间，可以判断出现故障；还有置状态标志位等多种方法，自检的实现方式需要根据实际情况来选用。

检错技术的处理方式，大多数都采用“査出故障-停止软件运行-报警”的处理方式。 但根据故障的不同情况，也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。

可靠性是实时系统的关键特性之一，区分软件的错误(Error)、缺陷（Defect）、故障(Fault)和失效(Failure)概念是软件可靠性设计工作的基础。请简要说明错误、缺陷、故障和失效的定义

软件错误：软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。

软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。

软件故障：软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。

软件失效：软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。

设计模式△

创建型模式主要用于创建对象，为设计类实例化新对象提供指南。

1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
3. 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
4. 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

结构型模式主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。

1. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。

2. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。

3. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。

4. 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。

5. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。

6. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。

7. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

   行为型模式主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南。

8. 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

9. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。

10. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。

11. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

12. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。

13. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。

14. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。

15. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

16. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

17. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

18. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

(1) 策略模式

解决方案：在具有公共接口的独立类中定义每个计算。可以利用该模式创建各种促销类，它们从同一个超类继承。每个类都有相同名称的标准接口方法，用于根据订单编号计算将要折扣的金额总数。

(2) 适配器模式

解决方案：增加一个类作为适配器，转换类的接口到客户端类期望的另一个接口。实现一个适配器类，这个类为系统的其他部分提供了一个不变的方法供调用，为了集成不同商品供应商提供的税率计算类，编写一个适配器类的子类，包含调用购买类所需的代码。该子类将系统的调用映射到某个供应商的税率计算类。如果要更换供应商，那么只需要写一个新的适配器子类，其他保持不变。

工厂设计模式的优点和应用场景，在数据访问层中的应用。

工厂模式分抽象工厂与工厂方法，题目中的场景适合采用抽象工厂设计模式。

抽象工厂设计模式提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。其优点是可以非常方便的创建一系列的对象，其使用场景也是创建系列对象的情况。在本题中，可以针对Oracle、MySQL、SQLServer分别建立抽象工厂，若指定当前工厂为Oracle工厂，则创建出来的数据库连接，数据集等一系列的对象都是符合Oracle操作要求的。这样便于数据库之间的切换。

MVC模式△

软件体系结构设计中，层次设计是一种常见的架构设计方法，使设计的系统结构清晰，便于提高复用能力和产品维护能力。

MVC是一种目前广泛流行的软件设计模式。MVC强制性地将一个应用处理流程按照模型、视图、控制的方式进行分离，形成了控制器、模型、视图三个核心模块。

(1) 控制器：接受用户的输入并调用模型和视图去完成用户的请求。一方面接受视图的输入，将其转为对模型特定方法的调用；一方面处理来自模型的事件，调用适当的视图反馈给用户。

(2) 模型：应用程序的主体部分，表示业务数据和业务逻辑，可以为多个视图提供数据。

(3) 、见图：用户看到并与之交互的界面。视图可以向模型查询业务状态，接收模型的数据更新事件，同步更新界面。

三者协作关系如图4-3所示。

使用MVC设计表现层，具有以下优点：

(1) 允许多种用户界面的扩展。在MVC模式中，视图与模型没有必然的联系，都是通过控制器发生联系，如果增加新类型的用户界面，只需修改响应的控制器和视图即可，模型无需变动；

(2) 易于维护。控制器和视图随着模型的扩展而扩展，只要保持公共接口，控制器和视图的旧版本可以继续使用；

(3) 支持功能强大的用户界面。用户界面与模型方法调用组合起来，使程序的使用更清晰，可将友好的界面发布给用户。

MVC架构风格最初是Smalltalk-80中用来构建用户界面时采用的架构设计风格。其中M代表模型（Model)，V代表视图（View)，C代表控制器（Controller)。在该风格中，模型表示待展示的对象，视图表示模型的展示，控制器负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映自身的变化。

视图（View）：视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。

控制器（Controller）：控制器接受用户的输入并调用模型和视图去完成用户的需求。该部分是用户界面与Model的接口。一方面它解释来自于视图的输入，将其解释成为系统能够理解的对象，同时它也识别用户动作，并将其解释为对模型特定方法的调用；另一方面，它处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

模型（Model）：模型是应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。

请从设计模式的角度，简要说明设计方案采用XML作为GUI描述语言的机制。

从设计模式的角度来说，整个XML表现层解柝的机制是一种策略模式。在调用显示GUI时，不是直接调用特定的表现技术的API,而是装载GUI对应的XML配置文件，然后根据特定的表现技术的解析器解析XML，得到GUI视图实例对象。这样，对于GUI开发人员来说，GUI视图只需要维护一套XML文件即可。

界面定制是对用户界面的动态修改过程，在软件运行过程中，用户可按照需求和使用习惯，对界面元素的属性进行修改。软件运行结束后，界面定制的结果被保存。

界面动态生成是系统通过DOMAPI读取XML配置文件的表示层信息，通过数据存取类读取数据库中的数据层信息，运行时由界面元素动态生成界面。界面配置和定制模块在软件运行前后修改配置文件、更改界面内容。

界面配置是对用户界面的静态定义，通过读取配置文件的初始值对界面配置。由界面配置对软件功能进行裁剪、重组和扩充，以实现特殊需求。

基于XML的界面管理技术实现的管理信息系统实现了用户界面描述信息与功能实现代码的分离，可针对不同用户需求进行界面配置和定制，能适应一定程度的数据结构改动。只需要对XML文件稍加修改，即可实现系统的移植。

数据库分区

数据分区是一种物理数据库的设计技术，它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。

分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介子中，实际上还是一张表。另外，分区可以做到将表的数据均衡到不同的地方，提高数据检索的效率，降低数据库的频繁IO压力值，分区的优点如下：

1、相对于单个文件系统或是硬盘，分区可以存储更多的数据；

2、数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可；

3、精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；

4、可跨多个分区磁盘查询，来提高查询的吞吐量；

5、在涉及聚合函数查询时，可以很容易进行数据的合并；

采用水平分区机制可根据用户标识将用户数据进行水平分割，用户操作时先将请求分发到不同数据库分区，再进行具体数据库操作，以提高数据库访问效率。

垂直分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。

主从复制机制的好处。

①避免数据库单点故障：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。

②提高査询效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等写操作，而从数据库则专门用来进行数据査询操作，从而将査询操作分担到不同的从服务器以提高数据库访问效率。

引入Memcached后系统访问数据库的基本过程为：

系统需要读取后台数据时，先检査数据是否存在于Memcached中，若存在则直接从Memcached中读取，或不存在则从数据库中读取并保存在Memcached中；当系统数据库中数据发生更新时，需要将更新后的内容同步到Memcached缓存实例中。

与MySQL查询缓存相比，使用Memcached机制存在以下优势：

(1) 缓存架构：数据库查询缓存通常每个数据库只有一个实例，因此存储内容受数据库服务器可用内存限制，可缓存数据有限；而Memcached可采用高速分布式缓存服务器结构，不受数据库服务器约束，可扩展性更好。

(2) 缓存有效性：数据库查询缓存只要在发生写操作时就会失效，即使更新的是数据库中的其他行；而Memcached可通过键值将数据进行散列缓存，有效降低缓存的更新频率，从而提高缓存的有效性。

(3) 缓存数据类型：数据库杏询缓存只能缓存数据库行，对社交网站好友动态显示等典型业务所需要的组合数据缓存缺乏有效支持，而Memcached理论上可缓存任何内容，因此可以将分散在数据库中的关系或者列表组合后进行缓存，以提高缓存数据的针对性和效率。

关系型数据库管理系统和文件系统

文件系统具有以下特点：

•针对特定应用系统设计，难度较小；

•数据冗余较大，可能在多个文件中复制相同的数据属性；

•以应用系统为中心组织、管理数据；

•符合特定应用系统要求的文件数据很难在不同的应用系统之间共享。

关系型数据库具有以下特点。

•数据结构需要符合关系模式，设计难度较大；

•遵守数据库范式，数据冗余较少；

•以数据库为中心组织、管理数据；

•数据独立于应用系统，很容易在不同的应用系统之间共享数据。

内存数据库和关系数据库

SQL语句设计时，影响查询效率的设计原则是：

•查询时尽量不要返回不需要的行、列；

•需要进行多表连接査询时，尽量使用连接查询，避免使用子查询结构；

•尽量避免采用NOTIN、NOTEXIST、LIKE等使用全表查询的操作；

•尽量避免使用DISTINCT关键字。

增加数据访问层的原因：

（1）由于涉及到多种异构数据库平台，数据访问复杂性增加，不宜与业务逻辑混合在一起

（2）数据管理变复杂之后，需要使用的代码量增加，分单独层次有利于让逻辑更清晰。

（3）业务逻辑应以相同的方式应对异构的数据库，此时需要单独的数据访问层屏蔽差异性。

什么是数据持久层，使用数据持久层能够为项目开发带来哪些好处？

数据持久层是根据分层思想，通过建立逻辑数据操作接口，采取一定的对象/关系映射策略，隐藏数据库访问代码细节，向业务开发人员提供透明的对象持久化操作机制。能够为项目开发带来的好处：

(1)分离业务逻辑层和数据层，降低两者之间的耦合；

(2) 通过对象/关系映射向业务逻辑提供面向对象的数据访问；

(3) 简化数据层访问，隐藏数据库链接、数据读写命令和事务管理细节。

Hibernate和iBatis是轻量级JavaEE框架中两种数据持久层技术，两者都是优秀的开源项目。iBatis相对简单易学而且更灵活，但开发工作量较大，数据之间是关联关系；Hibernate框架相对复杂，所生成的持久化对象能够表达面向对象中的继承和聚合等关系，开发工作量较小，Hibernate使用更广泛更成熟，能够适应目前所有主流的关系型数据库。

项目组应该采用Hibernate框架的原因：

(1) Hibernate支持多种不同类型数据库，满足项目组数据库移植需求；

(2) Hibernate相对于iBatis减少了SQL语句开发的工作量；

(3) iBatis生成的P0是扁平化的，无法像Hibernate—样支持对象的继承和聚合等立体化关系。

数据库程序在线访问方式和ORM方式的优缺点

数据库程序在线访问方式优点：

1、性能比直接SQL好

2、可以处理复杂查询语句

数据库程序在线访问方式缺点：

1、要求程序员懂SQL语句

2、修改与维护相对困难

ORM优点：

1、使用ORM可以大大降低学习和开发成本。

2、程序员不用再写SQL来进行数据库操作。

3、减少程序的代码量。

4、降低由于SQL代码质量差而带来的影响。

ORM缺点

1、不太容易处理复杂查询语句。

2、性能较直接用SQL差。

本题中的场景之所以选择ORM，主要考虑的是程序缺数据库开发经验，这样SQL语句质量有很大风险。同时学习成本很高。此外应用简单，不也担心ORM对性能的影响。

(a) Web 应用层

(b) 界面层

© 负载均衡层

(d) CDN 内容分发

(e) 主数据库

(f) 缓存服务器集群

(g) 从数据库

(h) 写操作

(i) 读操作

(j) 文件服务器集群

（1）（d）

（2）（c）

（3）（f）

（4）（a）

（5）（6）（e）（h）

（7）（8）（g）（i）

引入主从复制机制好处

1、提升性能

交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。

2、可扩展性更优

如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。

3、提升可用性

一主多从，一台从服务器出现故障不影响整个系统正常工作。

4、相当于负载均衡

一主多从分担任务，相当于负载均衡

5、提升数据安全性

系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。

	Memcache	Redis
数据类型	简单key/value结构	key/value，list，set，hash，sorted
持久性	不支持	支持
分布式存储	不支持	多种方式、主从、Sentinel、Cluster
多线程支持	支持	不支持
内存管理	有	无
事务支持	不支持	有限支持

（1）Memcache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。

（2）Memcache不支持事务，所以操作过程中可能产生数据的不一致性。

同步方案：读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据，写回时，写入到原数据库中，并同步更新至Redis中。

Redis分布式存储的2种常见方案：

1.主从

2.Cluster

Redis集群切片的常见方式：

1.客户端切片，即在客户端就通过key的hash值对应到不同的服务器。

2.对数据根据key散列到不同的slot上，不同的slot对应到不同服务器。

数据库建模中的反规范化技术，优缺点。

规范化设计后，数据库设计者希望牺牲部分规范化来提髙性能，这种从规范化设计的回退方法叫做反规范化技术。反规范化设计允许保留或者新增一些冗余数据，从而减少数据查询中表连接的数目或简化计算过程，提高数据访问效率。

采用反规范化技术的益处：能够减少数据库查询时SQL连接的数目，从而减少磁盘I/O数据量，提高查询效率。

可能带来的问题：数据的重复存储，浪费了磁盘空间；为了保障数据的一致性，增加了数据维护的复杂性。

常见的反规范化技术有哪些。

常见的反规范化技术包括：

(1) 增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作；

(2) 增加派生列：在表中增加可以由本表或其他表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数；

(3) 表水平分割：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用；

(4) 表垂直分割：对表进行分割，将主键与部分列放到一个表中，主键与其他列放到另一个表中，在查询时减少I/O次数。

从数据获取方式、数据交互方式和数据访问的上下文无关性三个方面对王工和李工的方案进行比较，并用500字以内的文字说明为什么没有采用王工的方案。

（公司的架构师王工提出采用面向服务的系统架构，首先将各种待集成的第三方软件和异构数据源统一进行包装，然后将数据访问功能以标准Web服务接口的形式对外暴露，从而支持系统进行数据的分析与处理，前端则采用CSS等技术实现浏览器数据的渲染与展示。架构师李工则认为该系统的核心在于数据的定位、汇聚与转换，更适合采用面向资源的架构，即首先为每种数据元素确定地址，然后将各种数据格式统一转换为JSON格式，通过对JSON数据的组合支 持数据的分析与处理任务，处理结果经过渲染后在浏览器的环境中进行展示。在架构评估会议上，专家对这两种方案进行综合评价，最终采用了李工的方案。）

从数据获取方式看，王工的方案需要将现有的多个系统和异构的数据源包装为服务，采用Web服务暴露数据接口，客户端需要通过服务调用获取数据，这种方法工作量大，复杂度较高。李工的方案则绕开了复杂的功能封装，只需要明确数据的位置与标识， 通过特定的网络协议直接使用标识定位并获取数据，与王工的方案相比工作量小，实现简单。

从数据交互方式看，王工的方案采用远程过程调用和异步XML消息等模式实现数据交互，这种方式适合于系统之间功能调用时进行的少量数据传输，而在进行单纯的数据访问时效率不高，稳定性也较差。李工的方案则以数据资源为核心，在对数据资源进行标识的基础上，通过标识符直接对数据资源进行访问与交互，实现简单且效率较高。

从数据访问的上下文无关性看，王工的方案中数据访问是与上下文有关的，具体表现在每次客户端进行数据请求都需要附加唯一的请求标识，并且服务端需要区分不同的客户端请求，效率较低。李工的方案中数据访问是与上下文无关的，客户端通过全局唯一的统一资源标识符（URI)请求对应的数据资源，服务端不需要区分不同的客户端请求。

用例

用例建模用来描述待开发系统的功能需求，主要元素是用例和参与者。请根据题目所述需求，说明教学服务系统中有哪些参与者。

参与者是指系统以外的，需要使用系统或与系统交互的事物，包括：人或组织、设备、外部系统等。在本题中，较为容易识别的参与者包括：学生、教师、管理员，比较隐晦的参与者包括：时间、打印机。

用例之间的关系包括：包含、扩展、泛化。

类图主要用来描述系统的静态结构，是组件图和配置图的基础。

类之间的关系有哪几种类型？

类之间的关系包括：关联、聚合、组合、依赖、泛化、实现（可写可不写，因为实现是接口与类之间的关系，而接口是一种特殊的类）。

类University与类Student之间的关系是：聚合关系。

类University与类Department之间的关系是：组合关系。

类Student与类Course之间的关系是：关联关系。

依赖关系：一个事物发生变化影响另一个事物。

泛化关系：特殊/一般关系。

关联关系：描述了一组链，链是对象之间的连接。

聚合关系：整体与部分生命周期不同。

组合关系：整体与部分生命周期相同。

实现关系：接口与类之间的关系。

在面向对象方法中通常采用用例（Use Case）来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的Essential Use Cases 和 Real Use Cases 有哪些区别? Essential Use Cases 可翻译为抽象用例，而Real Use Cases可翻译为基础用例。他们是区别在于：基础用例是实实在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的，而抽象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用例。

流程图与数据流图的含义及其区别

数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。

流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。

两者的区别主要包括：

(1) 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。

(2) 数据流图展现系统的数据流；流程图展现系统的控制流。

(3) 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。

(4) 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。

数据流图中常见的错误分为两种类型：一类是语法错误，包括外部实体之间、数据存储之间或外部实体与数据存储之间不经过加工而存在直接数据流；另一类是逻辑错误，包括数据黑洞（只有输入没有产生输出）、灰洞（输入不足以产生输出）和无输入。

髙质量数据流图设计时应考虑的三个原则：

(1) 复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考查每一个DFD。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD进行考査。

(2) 接口最小化原则。接口最小化是复杂性最小化的一种具体规则，在设计模型时，应使得模型中各个元素之间的接口数或连接数最小化。

(3) 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工？

状态图和活动图的含义及其区别。

状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。

活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。

两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。

👉其他

📢作者：小空和小芝中的小空
📢转载说明-务必注明来源：https://zhima.blog.csdn.net/
📢这位道友请留步☁️，我观你气度不凡，谈吐间隐隐有王者霸气💚，日后定有一番大作为📝！！！旁边有点赞👍收藏🌟今日传你，点了吧，未来你成功☀️，我分文不取，若不成功⚡️，也好回来找我。

温馨提示：点击下方卡片获取更多意想不到的资源。