常见的软件质量属性有多种，例如性能（Performance)、可用性（Availability)、可靠性（Reliability)、健壮性（Robustness)、安全性（Security)、可修改性（Modification)、可变性(Changeability)、易用性(Usability)、可测试性(Testability)、功能性(Functionality) 和互操作性（Inter-operation)等。
这些质量属性的具体含义是：
(1) 性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。
(2) 可用性是系统能够正常运行的时间比例。
(3) 可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。
(4) 健壮性是指在处理或环境中，系统能够承受压力或变更的能力。
(5) 安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
(6) 可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。
(7) 可变性是指体系结构经扩充或变更成为新体系结构的能力。
(8) 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
(9) 可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。
(10) 功能性是系统所能完成所期望工作的能力。
(11) 互操作性是指系统与外界或系统与系统之间的相互作用能力。
数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。
两者的区别主要包括：
(1) 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
(2) 数据流图展现系统的数据流；流程图展现系统的控制流。
(3) 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。
(4) 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。
数据流图中存在的错误有以下4种：
(1) "分类训练"加工：只有输入没有输出，产生数据黑洞；
(2) "分类处理"加工：只有输出没有输入，无中生有；
(3) "规则文件"数据流：外部实体没有经过加工处理，直接到数据存储;
(4) "配置信息"数据流：外部实体之间没有加工处理，存在直接数据流。
高质量数据流图设计时应考虑的三个原则：
(1)复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考查每一个DFD。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD进行考査。
(2) 接口最小化原则。接口最小化是复杂性最小化的一种具体规则，在设计模型时，应使得模型中各个元素之间的接口数或连接数最小化。
(3) 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工？
面向对象架构风格的特征是将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身表示的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程。
控制环路架构风格是将过程输出的指定属性维护在一个特定的参考值（设定点）。控制环路风格包括过程变量、被控变量'、输入变量、操纵变量和设定点等构件，通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态。
适合面向对象架构风格的应用场景：
(1) 用户刹车，立即退出巡航控制系统。理由：这是一个典型的事件驱动的场景，适合于面向对象风格。
(2) 系统对突发事件的处理，如某些部件失灵等。理由：当发生突发事件时，系统会同时产生数据和事件，这种情况用对象建模较为恰当。
适合面向控制环路架构风格的应用场景：
(1) 在达到期望速度后，系统维持恒定速度行驶。理由：这是一个典型的闭环控制的情景，系统需要在外界情况不断发生变化的情况下进行调整，使得系统状态尽可能接近期望状态。
(2) 用户改变期望速度后，系统不断进行调整，直至到达恒定速度。理由：这是一个闭环控制情景，当用户设定期望速度值后，系统需要在不断获取当前速度和外界条件的情况下对系统状态持续调整，使得系统状态尽可能接近这个新的期望状态。
信息系统面临的安全威胁来自于物理环境、通信链路、网络系统、操作系统、应用系统以及管理等多个方面。
物理安全威胁是指对系统所用设备的威胁，如自然灾害、电源故障、数据库故障和设备被盗等造成数据丢失或信息泄漏。
通信链路安全威胁是指在传输线路上安装窃听装置或对通信链路进行干扰。
网络安全威胁当前主要是指由于因特网的开放性、国际性与无安全管理性，对内部网络形成的严重安全威胁。
操作系统安全威胁指的是操作系统本身的后门或安全缺陷，如"木马"和"陷阱 门"等。
应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁，包括应用系统自身漏洞，也受到"木马"的威胁。
管理系统安全威胁指的是人员管理和各种安全管理制度。
目前主要的认证方式有三类：
(1) 用户名和口令认证：主要是通过一个客户端与服务器知的口令（或与口令相关的数据）进行验证。根据处理形式的不同，分为验证数据的明文传送、利用单向散列函数处理验证数据、利用单向散列函数和随机数处理验证数据。
(2) 使用令牌认证：该方式中，进行验证的密钥存储于令牌中，目前的令牌包括安全证书和智能卡等方式。
(3)生物识别认证：主要是根据认证者的图像、指纹、气味和声音等作为认证数据。根据该企业的业务特征，采用令牌认证较为合适。
授权侵犯指的是被授权以某一目的使用某一系统或资源的某个人，将此权限用于其他非授权的目的，也称作"内部攻击"。
针对王工的建议，从系统安全架构设计的角度需要提供抗抵赖框架。
抗抵赖服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。
框架中抗抵赖服务的目的是提供有关特定事件或行为的证据。例如，必须确认数据原发者和接收者的身份和数据完整性，在某些情况下，可能需要涉及上下文关系（如曰期、时间、原发者/接收者的地点等）的证据，等等。
软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。
主程序-子程序架构风格中，所有的计算构件作为子程序协作工作，并由一个主程序 顺序地调用这些子程序，构件通过共享存储区交换数据。
管道-过滤器架构风格中，每个构件都有一组输入和输出，构件接受数据输入，经过内部处理，然后产生数据输出。这里的构件称为过滤器，构件之间的连接件称为数据流传输的管道。
(1)张工提出的集中式数据架构是由一个处理器、与它相关联的数据存储设备以及其他外围设备组成，它被物理地定义到单个位置。系统提供数据处理能力，用户可以在同样的站点上操作，也可以在地理位置隔开的其他站点上通过远程终端来操作。系统及其数据管理被某个或中心站点集中控制。
(2)刘工提出的分布式数据架构使用多个计算机系统上的多个局部数据库系统构成，数据可以在多个不同的局部数据库中进行传送，由不同的数据库管理系统软件班行管理，运行在多种不同的计算机上，支持多种不同的操作系统。这些机器位于（或分布在）不同的地理位置并通过多种通信网络连接在一起。企业数据可以分布在不同的计算机上，一个应用程序可以操作位于不同地理位置的机器上的数据。
读写分离架构利用了数据库的复制技术，将数据的读和写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。
CRSS的分布式数据库系统需要由多个局部数据库系统、多个热备份数据库系统和多个数据缓存组成。局部数据库负责数据的写入，多个热备份数据库系统用以解决单点故障的问题，数据缓存负责为应用提供所读取的数据。
(1) 读取数据：应用访问缓存，如果命中则返回，否则从局部数据库系统中读取数据并将数据加载到缓存后返回。
(2) 添加数据：采用延迟加载策略，应用将数据直接写入局部数据库。
(3) 更改数据：应用更改局部数据库中的数据，将缓存中的数据标记为失效。
(4) 删除数据：应用删除局部数据库中的数据，将缓存中的数据标记为失效。
张工提出的集中式数据架构通过向上扩展（Scale Up)提升系统的可扩展性。具体的实现方式包括硬件扩容（增加CPU数ft、内存容童、磁盘数量）和硬件升级（更换为高端主机或高速磁盘等)。
刘工提出的分布式数据架构通过向外扩展（Scale Out)提升系统的可扩展性。具体的实现方式包括数据复制、数据垂直切分或/和水平切分、缓存和全文搜索。
ESB 的主要功能包括：
(1) 应用程序的位置透明性
(2) 传输协议转换
(3) 消息格式转换
(4) 消息路由
(5) 消息增强
(6) 安全支持
(7) 监控和管理
采用ESB作为集成框架，能够实现灵活的部署结构，包括CS结构、P2P结构等。采用ESB作为集成框架，待集成系统只需要和总线进行联系，彼此之间不需要互相通信，这样就大大降低了系统的耦合程度。
采用ESB作为集成框架，在加入新的待集成系统时，只需要采用插件的方式实现传输协议和数据格式的适配即可，系统的可扩展性较强。
对于需求（1）来说，由于需要共享系统的功能，并且系统的运行平台与语言差异较大，应该采用面向服务的方式进行功能集成，可以将工具的功能包装为服务，实现跨语言与跨平台访问。
对于需求（2）来说，工具所支持的通信协议和数据格式各不相同，并需要卖现工具之间的灵活通信协议和数据格式交换，因此应该基于消息总线，以协议及数据适配器的方式实现灵活的通信协议和数据格式转换。
对于需求（3）来说，集成框架需要根据实际的软件系统开发流程，灵活、动态地定义系统设计与开发工具之间的协作关系，因此应该引入工作流定义语言及其引擎来动态描述工具之间的协作关系。
对于需求（4）来说，应该采用界面集成的方法对第三方工具进行集成，绕过工具内部的复杂处理逻辑。
在实现工具之间数据格式的灵活转换时，通常采用适配器设计模式。即应首先定义一个统一的数据转换接口类，然后针对不同的数据格式转换需求定义对应的实际转换类，实际转换类需要继承数据转换接口类，并实现接口转换类定义的接口。
可靠度就是系统在规定的条件下、规定的时间内不发生失效的概率。
失效率又称风险函数，也可以称为条件失效强度，是指运行至此刻系统未出现失效的情况下，单位时间系统出现失效的概率。
动态冗余又称为主动冗余，它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来替代它并重新运行。各备用模块在其待机时，可与主模块一样工作，也可以不工作。前者叫热备份系统（双重系统），后者叫冷备份系统（双工系统、双份系统)。N版本程序设计是一种静态的故障屏蔽技术，其设计思想是用N个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。其中N个版本的程序必须由不同的人独立设计，使用不同的方法、设计语言、开发环境和工具来实现，目的是减少N个版本的程序在表决点上相关错误的概率。
检错技术实现的代价一般低于容错技术和冗余技术，但有一个明显的缺点，就是不能自动解决故障，出现故障后如果不进行人工干预，将最终导致软件系统不能正常运行。
检错技术常见的实现方式：最直接的一种实现方式是判断返回结果，如果返回结果 超出正常范围，则进行异常处理；计算运行时间也是一种常用技术，如果某个模块或函数运行时间超过预期时间，可以判断出现故障；还有置状态标志位等多种方法，自检的实现方式需要根据实际情况来选用。
检错技术的处理方式，大多数都采用"査出故障-停止软件运行-报警"的处理方式。 但根据故障的不同情况，也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。
系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
敏感点是指为了实现某种特定的质量属性，一个或多个系统组件所具有的特性。
权衡点是指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。
规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法叫做反规范化技术。反规范化设计允许保留或者新增一些冗余数据，从而减少数据查询中表连接的数目或简化计算过程，提高数据访问效率。
采用反规范化技术的益处：能够减少数据库查询时SQL连接的数目，从而减少磁盘I/O数据量，提高查询效率。
可能带来的问题：数据的重复存储，浪费了磁盘空间；为了保障数据的一致性，增加了数据维护的复杂性。
常见的反规范化技术包括：
(1) 增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作；
(2) 增加派生列：在表中增加可以由本表或其他表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数；
(3) 表水平分割：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用；
(4) 表垂直分割：对表进行分割，将主键与部分列放到一个表中，主键与其他列放到另一个表中，在查询时减少I/O次数。
REST从资源的角度来定义整个网络系统结构，分布在各处的资源由统一资源标识符（URI)确定，客户端应用程序通过URI获取资源的表现，并通过获得资源表现使得其状态发生改变。
REST中将资源、资源的表现和获取资源的动作三者进行分离。
对称加密策略：
机密性：发送者利用对称密钥对要发送的数据进行加密，只有拥有正确相同密钥的接收者才能将数据正确解密，从而提供机密性。
完整性：发送者根据要发送的数据生成消息认证码（或消息摘要），利用对称密钥对消息认证码进行加密并附加到数据上发送；接收者使用相同密钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。
公钥加密策略：
机密性：发送者利用接收者的公钥对要发送的数据进行加密，只有拥有对应私钥的接收者才能将数据正确解密，从而提供机密性。
完整性：发送者根据要发送的数据生成消息认证码（或消息摘要），利用自己的私钥对消息认证码进行加密并附加到数据上发送；接收者利用对方的公钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。
采用王工方案是因为基于角色的访问控制与XACML相结合的机制具有以下优势： 授权的可管理性：RBAC将用户与权限分离，相比MAC减小了授权管理的复杂性, 更适合于大型企业级系统的安全管理：
细粒度访问控制的支持：XACML提供了统一的访问控制策略描述语言，策略表达能力强，可用来描述各种复杂的和细粒度的访问控制安全需求，更适合企业复杂业务功能的访问控制要求；
分布式环境的支持：XACML的标准性便于各子系统的协作交互，各子系统或企业业务部门可以分布管理访问控制权限，而MAC则通常需要对访问控制权限集中管理， 不太适合企业基于SOA集成后的分布式系统。
软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。
从集成开发环境与用户的交互方式看，用户通常采用交互式的方式对脚本语言进行编辑、解释执行与调试。在这种情况下，采用以数据存储为中心的架构风格能够很好地支持交互式数据处理，而管道-过滤器架构风格则对用户的交互式数据处理支持有限。
从集成开发环境的扩展性来看，系统核心需求要求实现各种编辑、语法检查、解释执行等多种功能的灵活组织、配置与替换。在这种情况下，采用以数据存储为中心的架构风格，以数据格式解耦各种功能之间的依赖关系，并可以灵活定义功能之间的逻辑顺序。管道-过滤器架构风格同样以数据格式解耦数据处理过程之间的依赖关系，但其在数据处理逻辑关系的灵活定义方面较差。
从集成开发环境的数据管理来看，集成开发环境需要支持脚本语言、语法树（用于检查语法错误)、可视化模型、调试信息等多种数据类型，并需要支持数据格式的转换。 以数据存储为中心的架构将数据存储在统一的中心存储器中，中心存储器能够表示多种数据格式，并能够为数据格式转换提供各种支持。管道-过滤器架构风格通常只能支持有限度的数据格式，并且在数据格式转换方面的灵活性较差。
分布式基础设施为构建分布式系统所提供的基本支撑
(1) 构件管理支持：现有分布式基础设施一般通过构件容器为构件提供基本的运行环境；具体功能一般包括管理构件的实例及其生命周期、管理构件的元信息等。
(2) 互操作支持：现有分布式基础设施均提供了高层通信协议以屏蔽节点的物理特性以及各节点在处理器、操作系统、程序设计语言等方面的异构性；基于互操作支持，开发人员在开发与调用分布式对象时，均不需自己编写处理底层通信的代码。
(3) 公共服务支持：现有分布式基础设施通常将针对分布式软件的通用支持集成于一身，以公共服务的形式提供给应用程序；其提供的常见公共服务包括命名服务、事务 服务、安全服务、持久性服务等。
一次远程调用的过程如下：
①客户程序将调用请求发送给客户端桩，对于客户程序来说，桩就是服务程序在客户端的代理。
②客户端桩负责将远程调用请求进行编组并发送给通信总线。
③调用请求经通信总线传送到服务端框架。
④服务端框架将调用请求解组并分派给真正的远程对象实现（服务程序)。
⑤服务程序完成客户端的调用请求，将结果返冋给服务端框架。
⑥服务端框架将调用结果编组并发送给通信总线。
⑦调用结果经通信总线传送到客户端桩。
⑧客户端桩将调用结果解组并返回给客户程序，客户程序得到调用结果。
开放架构应具有以下4个基本特点：
①可移植性。各种计算机应用系统可在具有开放架构特性的各种计算机系统间进行移植，不论这些计算机是否同种型号、同种机型。
②可互操作性。如计算机网络中的各结点机都具有开放架构的特性，则该网上各结点机间可相互操作和资源共享。
③可剪裁性。如某个计算机系统是具有开放架构特性的，则在该系统的低档机上运行的应用系统应能在高档机上运行，原在高档机上运行的应用系统经剪裁后也可在低档机上运行。
④易获得性。在具有开放架构特性的机器上所运行的软件环境易于从多方获得，不受某个来源所控制。
创建型模式主要用于创建对象，为设计类实例化新对象提供指南。
结构型模式主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。 .
行为型模式主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南。
(1) 策略模式
解决方案：在具有公共接口的独立类中定义每个计算。可以利用该模式创建各种促销类，它们从同一个超类继承。每个类都有相同名称的标准接口方法，用于根据订单编号计算将要折扣的金额总数。计算每个促销的内部代码对促销类来说完全不同（3分)。
(2) 适配器模式
解决方案：增加一个类作为适配器，转换类的接口到客户端类期望的另一个接口。实现一个适配器类，这个类为系统的其他部分提供了一个不变的方法供调用，为了集成不同商品供应商提供的税率计算类，编写一个适配器类的子类，包含调用购买类所需的代码。该子类将系统的调用映射到某个供应商的税率计算类。如果要更换供应商，那么只需要写一个新的适配器子类，其他保持不变。
(1) 用户响应时间慢。大型社交网络系统要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强可以， 但是应付上万次SQL写数据请求，硬盘I/O就已经无法承受了。特别是涉及到多表连接 操作，会导致响应变慢。
(2) 数据格式变化。大型社交网络系统随着用户的使用，会不断地增加新的功能，导致原有数据格式发生变化，甚至出现新的数据格式。但关系数据库中采用元组方式组织数据，难以使用新型数据格式，难以维护。
(3) 数据容量超过设计上限。对于大型社交网络系统，往往会在很短时间内产生海量数据。关系数据库多采用中央数据存储，使得数据容量受限于前期设计的上限，很难实现数据容量的横向扩展。
(4) 系统可用性差：关系数据库采用中央数据存储，容易成为系统的性能瓶颈，单点故障很容易导致系统崩溃，负载过高往往导致系统出现宕机现象。
针对问题（1），NoSQL数据库支持高并发数据访问，性能较高。
针对问题（2），NoSQL数据库的数据存储结构松散，能够灵活支持多种类型的数据格式。
针对问题（3），NoSQL数据库能够支持海量数据的存储，且易于横向扩展。
针对问题（4），NoSQL数据库基于分布式数据存储，不存在单点故障和性能瓶颈，系统可用性高。
该系统采用NoSQL数据库时可能存在的问题有：
(1) NoSQL数据库的现有产品不够成熟，大多数产品处于初创期。
(2) NoSQL数据库并未形成一定的标准，产品种类繁多，缺乏官方支持。
(3) NoSQL数据库不提供对SQL的支持，学习和应用迁移成本较高。
(4) NoSQL数据库支持的特性不够丰富，现有产品提供的功能比较有限。
企业服务总线（Enterprise Service Bus,ESB)是传统中间件技术与XML、Web服务等技术结合的产物，主要支持异构系统集成。ESB基于内容的路由和过滤，具备复杂数据的传输能力，并可以提供一系列的标准接口。
ESB的主要功能有：
(1) 服务位置透明性；
(2) 传输协议转换；
(3) 消息格式转换；
(4) 消息路由；
(5) 消息增强；
(6) 安全性；
(7) 监控与管理。
王工在接到任务后开始项目计划的编制工作，编制的计划应包括：
(1) 项目总计划（包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划及费用计划）
(2) 项目辅助计划（质量计划、沟通计划、人力资源计划、风险计划、采购计划）。
MVC模式对该个人银行系统的作用：
(1) 允许多种界面的扩展，视图的变更与增加，与模型无关；
(2) 易于维护，控制器和视图随着模型的扩展而扩展，只要保持公共接口，控制器和视图的旧版本可以继续使用；
(3) 可支持功能强大的用户界面。
从设计模式的角度来说，整个XML表现层解析的机制是一种策略模式。在调用显示GUI时，不是直接调用特定的表现技术的API,而是装载GUI对应的XML配置文件，然后根据特定的表现技术的解析器解析XML，得到GUI视图实例对象。这样，对于GUI开发人员来说，GUI视图只需要维护一套XML文件即可。
基于XML的界面管理技术可以实现灵活的界面配置、界面动态生成和界面定制。其思路是用XML生成配置文件及界面所需的元数据，按照不同需求生成界面元素和软件界面。
(1) 基于口令的认证方式实现简单，但由于口令复杂度及管理方面的原因，易受到认证攻击；而在基于公钥体系的认证方式中，由于其密钥机制的复杂性，同时在认证过程中私钥不在网络上传输，因此可以有效防止认证攻击，与基于口令的认证方式相比更为安全。
(2) 按照需求描述，在完成用户身份鉴别后，需依据用户身份进一步对业务数据进行安全保护，且受保护数据中包含用户私有的终端机数据文件，在基于口令的认证方式中，用户口令为用户和认证服务器共享，没有用户独有的直接秘密信息，而在基于公钥的认证方式中，可基于用户私钥对私有数据进行加密保护，实现更加简便。
(3) 基于公钥体系的认证方式协议和计算更加复杂，因此其计算复杂度要高？基于口令的认证方式，但业务环境的总用户数在100人以内，用户规模不大，运行环境又为局域网环境，因此基于公钥体系的认证方式可满足平台效率要求。
应采用流加密方式。因为需求中提及"单个敏感数据文件可能会达到数百兆的规模"，文件数据量较大，使用流加密方式可以获得更高的加解密效率。
数据加密与解密过程如下：
其加密过程为：首先生成一个对称密钥，使用用户公钥加密这个对称密钥后存储在文件头，然后用生成的对称密钥加密文件数据存储；
其解密过程为：用户首先使用自己的私钥解密被加密的对称密钥，再用该对称密钥解密出数据原文。
目前数据库管理系统提供的基本数据加密支持主要有以下两种：
(1) 加解密API:数据库管理系统提供可在SQL语句中调用的加解密API,应用可以利用这些API构建自己的基础架构，对数据进行加密保护。
(2) 透明加密：安全管理员为数据库敏感字段选择加密方式及密钥强度，应用访问受保护数据时只需使用口令打开或关闭密钥表，对数据的加密和解密由数据库管理系统自动完成。
加解密API方式的灵活性强，但构建和管理复杂；而透明加密方式管理简单，应用程序负担轻，但灵活性较差。用户要求尽可能减少安全管理与应用程序的负担，因此应选择透明加密方式。
MVC架构风格最初是Smalltalk-80中用来构建用户界面时采用的架构设计风格。其中M代表模型（Model)，V代表视图（View)，C代表控制器（Controller)。在该风格中，模型表示待展示的对象，视图表示模型的展示，控制器负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映自身的变化。
在本系统中，模型（M）代表监控组件、视图（V）代表控制终端、控制器（C）代表管理模块。
数据流图（Data Flow Diagram)从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。为了表达数据处理过程的数据加工情况，用一个数据流图往往是不够的。层次结构的数据流图按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。
本问题考查数据流图中包含的元素及其作用。
数据流图通过外部代理（实体）描述系统与外界之间的数据交互关系，内部的活动通过处理（加工）表示，用数据流描述系统中不同活动之间的数据传输内容和方向，需要持久化存储的数据用数据存储表示，一般用文件系统或者数据库表存储数据-数据流图中所包含的四种元素：
(1) 外部实体（External Agent)定义位于项目范围之外，但与正在被研发的系统有交互关系的人、部门、外部系统或组织；
(2) 加工（Process)在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作；
(3) 数据存储（Data Store)描述静止的数据，表示系统中需要保存的数据；
(4) 数据流（Data Flow)描述运动中的数据，表示到一个过程的数据输入，或者来自一个过程的数据输出。
数据流图四种错误：
(1) D1到A2：缺少移动数据流的加工。
(2) P5.3：没有输出数据流，输入输出不平衡。
(3) P5.4：没有输入数据流，输入输出不平衡。
(4) D2：数据存储没有输出的数据流。
两种机制的基本原理：
基于DNS的负载均衡机制通过DNS服务器实现，通常通过循环复用具有同一域名的多个主机地址的服务器实现负载均衡。
反向代理负载均衡则是将来自Internet的连接请求以反向代理的方式动态转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
(1)本系统中应主要使用水平分区机制。根据已知信息，系统数据库中存储的主要数据为以用户标识为索引的社交网络数据，采用水平分区机制可根据用户标识将用户数据进行水平分割，用户操作时先将请求分发到不同数据库分区，再进行具体数据库操作，以提高数据库访问效率。
(2) 引入主从复制机制所带来的好处：
①避免数据库单点故障：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。
②提高査询效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等写操作，而从数据库则专门用来进行数据査询操作，从而将査询操作分担到不同的从服务器以提高数据库访问效率。
使用Memcached代替数据库查询缓存的原因：
(1) 缓存架构：数据库查询缓存通常每个数据库只有一个实例，因此存储内容受数据库服务器可用内存限制，可缓存数据有限。而Memcached可采用高速分布式缓存服务器结构，不受数据库服务器约束，可扩展性更好。
(2) 缓存有效性：数据库查询缓存只要在发生写操作时就会失效，即使更新的是数据库中的其他行。而Memcached可通过键值将数据进行散列缓存，有效降低缓存的更新频率，从而提高缓存的有效性。
(3) 缓存数据类型：数据库查询缓存只能缓存数据库行，对社交网站好友动态显示等典型业务所需要的组合数据缓存缺乏有效支持，而Memcached理论上可缓存任何内容。因此可以将分散在数据库中的关系或者列表组合后进行缓存，以提高缓存数据的针对性和效率。
状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。
活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。
两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。
系统可靠性定义：系统在规定的时间内及规定的环境条件下，完成规定功能的能力，就是系统无故障运行的概率。
系统可靠性包括：成熟性、容错性、易恢复性和可靠性的依从性4个子特性。
提高系统可靠性一般采用以下4类技术：
(1) 冗余技术；
(2) 软件容错技术；
(3) 双机容错技术；
(4) 集群技术。
关系型数据库管理系统和文件系统两种数据存储方式
(1) 数据结构需要符合关系模式，设计难度较大
(2) 可能在多个文件中复制相同的数据属性，数据冗余较大
(3) 以应用系统为中心组织、管理数据
(4) 数据独立于应用系统，很容易在不同的应用系统之间共享数据
SQL语句设计时，影响查询效率的设计原则是：
•查询时尽量不要返回不需要的行、列；
•需要进行多表连接査询时，尽量使用连接查询，避免使用子查询结构；
•尽量避免采用NOTIN、NOTEXIST、LIKE等使用全表查询的操作；
•尽量避免使用DISTINCT关键字
数据持久层是根据分层思想，通过建立逻辑数据操作接口，采取一定的对象/关系映射策略，隐藏数据库访问代码细节，向业务开发人员提供透明的对象持久化操作机制。能够为项目开发带来的好处：
(1) 分离业务逻辑层和数据层，降低两者之间的耦合；
(2) 通过对象/关系映射向业务逻辑提供面向对象的数据访问；
(3) 简化数据层访问，隐藏数据库连接、数据读写命令和事务管理细节。
项目组应该采用Hibernate框架。
原因：
(1) Hibernate支持多种不同类型数据库，满足项目组数据库移植需求；
(2) Hibernate相对于iBatis减少了SQL语句开发的工作量；
(3) iBatis生成的PO是扁平化的，无法像Hibernate---样支持对象的继承和聚合等立体化关系。
原有基于Web服务器的脚本语言的解决方案，其实质是在Web服务器端放入一个通用的脚本语言解释器，负责脚本语言的解释执行。其存在的不足有：
1.脚本语言嵌入在HTML文件中，使得I/O、业务逻辑、数据处理等程序代码混杂在一起，使得开发、维护困难；
2.系统采用Web服务器实现业务逻辑，系统的扩展性差，并发能力差，系统一旦繁忙，缺乏有效的手段进行扩充；
3.系统缺乏有效的维护、管理工具。
应用服务器是指通过各种协议把商业逻辑暴露给客户端的程序。它提供了访问商业逻辑的途径以供客户端应用程序使用。应用服务器为实现Web应用程序和系统资源的访问机制提供了一种简单、可管理的方式。它是一个开发、部署、运行、管理和维护的平台，可以提供软件"集群"功能，让多个不同的异构服务器协同工作、相互备份，满足企业级应用所需要的可用性、高性能、可靠性和伸缩性。
应用服务器通过分布式体系来保障系统在大负荷和长时间运行下的稳定性以及可扩展性：
（1）当系统处理能力不够时，通过简单增加硬件来解决，提供水平可扩展性；
（2）动态调整不同主机间的负载可以最大限度地利用资源，提供单机稳定性；
（3）动态调整主机工作职能，没有单点故障。
J2EE是针对Web Service、业务对象、数据访问和消息传送的一组规范。这组应用编程接口确定了Web应用与驻留它们的服务器之间的通信方式。J2EE注重两件事，一是建立标准，使Web应用的部署与服务器无关；二是使服务器能控制构件的生命周期和其他资源，以便能够处理扩展、并发、事务处理管理和安全性问题。J2EE规范定义了以下几种构件：应用客户端、EJB构件、Servlets和JSP、Applet构件。J2EE采用的是多层分布式应用模型，意味着应用逻辑将根据功能分成几个部分，用户可以在相同或不同的服务器上安装不同应用构件组成J2EE应用。
MVC架构包含的三种元素是：模型、视图、控制器。模型负责提供操作数据对象; 视图负责提供用户操作界面；控制器负责按照输入指令和业务逻辑操作数据对象，并产生输出。
EJB构件中的Bean分为：
（1）Session Bean (会话构件）负责处理客户与服务端交互的业务逻辑；
（2）Entity Bean (实体构件）表示数据库中存在的业务实体；
（3）Message Driven Bean (消息驱动构件）用于接收异步JMS消息。
在线访问方式：在程序中通过数据库提供的程序接口直接访问数据。其优点是灵活，性能高。缺点是需要程序员对数据库有较深了解，同时数据模型的变更会导致相应程序的变更，数据库迁移困难。
ORM方式：是一种工具或平台，能够提供应用程序中的数据与关系数据库中的记录之间的相互转换，使得程序无须考虑记录，仅考虑对象。优点是简化程序开发，降低了对程序员关于数据库的知识要求，使得程序员可以仅关注于业务逻辑；缺点是不太容易处理复杂查询语句，性能比直接使用SQL要差。
根据题干说明，原电子商务平台功能简单，没有复杂业务功能，数据访问仅需要提供基本功能即可；软件企业的程序开发人员缺乏数据库开发经验；ORM的方式的数据接口简单清晰，开发周期短，因此采用ORM方式是较好的选择。
工厂设计模式定义了创建对象的接口，允许子类决定实例化哪个类，而且允许请求者无须知道要被实例化的特定类，这样可以在不修改代码的情况下引入新类。
优点是（1）没有了将应用程序类绑定到代码中的要求，可以使用任何实现了接口的类；（2）允许子类提供对象的扩展版本。
工厂设计模式的应用场景有：（1）类不能预料它必须创建的对象的类；（2）类希望其子类指定它要创建的对象。
在数据访问层定义采用工程模式，定义统一的操纵数据库的接口，然后根据数据库的不同，由类工厂来决定实例化哪个类。在具体类中实现特定的数据库访问类。这样，就可以实现由客户端指定或根据配置文件来选择访问不同的数据库，从而实现应用程序与数据库无关。
响应式Web设计(Responsive Web design)的理念是：页面的设计与开发应当根据用户行为以及设备环境（系统平台、屏幕尺寸、屏幕定向等）进行相应的响应和调整。无论用户正在使用笔记本还是iPad，页面都应该能够自动切换分辨率、图片尺寸及相关脚本功能等，以适应不同设备；即页面应该有能力去自动响应用户的设备环境。响应式网页设计就是一个网站能够兼容多个终端，而不是为每个终端做一个特定的版本。减小为不断到来的新设备做专门的版本设计和开发的工作量。
响应式Web设计具体的实现方式包括媒体查询（media query)、流式布局（弹性布局、动态布局）、液态图片（弹性图片）等。
避免数据库单点故障：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。
提高查询效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等写操作，而从数据库则专门用来进行数据查询操作，从而将查询操作分担到不同的从服务器以提高数据库访问效率。
(1) 操作性需求：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
(2) 性能需求：针对系统性能要求的指标，如吞吐率、响应时间和容量等。
(3) 安全性需求：指为防止系统崩溃和保证数据安全所需要采取的保护措施的要求，为系统提供合理的预防措施。
(4) 文化需求：指使用本系统的不同用户群体对系统提出的特有要求。
(1) 信息工程方法中的"实体"描述的是数据以及该数据的相关属性。面向对象方法中的"类"是数据和行为的封装体。
(2) Essential Use Cases和Real Use Cases是按照开发阶段来进行划分的。Essential Use Cases是在面向对象分析阶段使用的，Real Use Cases是在面向对象设计阶段使用的。
Essential Use Cases描述的是用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。
MemCache无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。Redis支持数据的持久化。因此李工的方案存在数据可靠性和一致性问题，而刘工的方案解决了该问题。
刘工的方案中，采用Redis作为缓存，使得一份数据同时存储在缓存和关系数据库中，因此必须给出一个数据同步的方案。刘工的方案中，保留原有关系数据库，将Redis仅作为缓存，即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中。由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方 案的基本操作如下。
-
读操作。读缓存Redis,如果数据不存在，从原关系数据库中读数据，并将读取后的数据值写入到Redis;
-
写操作。写原关系数据库，写成功后，更新或者失效掉缓存Redis中的值。
Redis分布式存储的常见方案有：
-
主从（Master/Slave)模式；
-
哨兵（Sentinel)模式；
-
集群（Cluster)模式。
Redis集群切片的常见方式有：
-
客户端实现分片。分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
-
中间件实现分片。在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
-
客户端服务端协作分片。Redis Cluster模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务。
面向服务的体系架构（SOA)是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA能帮助企业系统架构设计者以更迅速、更可靠、更高重用性设计整个业务系统架构，基于SOA的系统能够更加从容地面对业务的急剧变化。
企业服务总线（ESB)是由中间件技术实现的全面支持面向服务架构的基础软件平台，支持异构环境中的服务以及基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。
用户级别与折扣规则管理功能更适合采用基于规则的架构风格。
(1)将用户级别、折扣规则等描述为可动态改变的规则数据；
(2)加入新的用户级别和折扣规则时需要重新定义新的对象，并需要重启系统；
(3)用户级别和折扣规则已经在系统内编码，可直接运行，性能较好。
(1)数据流图中的处理过程可并行；系统流程图在某个时间点只能处于一个处理过程。
(2)数据流图展现系统的数据流；系统流程图展现系统的控制流。
(3)数据流图展现全局的处理过程，过程之间遵循不同的计时标准；系统流程图中 处理过程遵循一致的计时标准。
信息物理系统（Cyber Physical Systems,CPS)作为计算进程和物理进程的统一体，是集计算、通信与控制于一体的下一代智能系统。信息物理系统通过人机交互接口实现和物理进程的交互，使用网络化空间，以远程的、可靠的、实时的、安全的、协作的方式操控一个物理实体。
感知层：主要由传感器、控制器和采集器等设备组成，它属于信息物理系统中的末端设备。
网络层：主要是连接信息世界和物理世界的桥梁，实现的是数据传输，为系统提供实时的网络服务，保证网络分组传输的实时可靠。
控制层：主要是根据认知结果及物理设备传回来的数据进行相应的分析，将相应的结果返回给客户端。
(1)感知层安全威胁：感知数据破坏、信息窃听、节点捕获。
(2)网络层安全威胁：拒绝服务攻击、选择性转发、方向误导攻击。
(3)控制层安全威胁：用户隐私泄露、恶意代码、非授权访问。
存在双写不一致问题，在写数据时，可能存在缓存写成功，数据库写失败，或者反之，从而造成数据不一致。当多个请求发生时，也可能产生读写冲突的并发问题。
(a)从数据库中读取数据或读数据库
(b)更新缓存中key值或更新缓存
(c)数据库
(d)删除缓存key或使缓存key失效或更新缓存（key值）
存在问题：不在系统中的key值是无限的，如果均设置key值为空，会造成内存资源的极大浪费，引起性能急剧下降。
解决思路：查询缓存之前，对key值进行过滤，只允许系统中存在的key进行后续操作（例如采用key的bitmap进行过滤)。
思路1:缓存失效后，通过加排它锁或者队列方式控制数据库写缓存的线程数量，使得缓存更新串行化；
思路2:给不同key设置随机或不同的失效时间，使失效时间的分布尽量均匀；
思路3:设置两级或多级缓存，避免访问数据库服务器。
抵御SQL注入攻击：
1.使用正则表达式；
2.使用参数化的过滤性语句；
3.检査用户输入的合法性；
4.用户相关数据加密处理；
5.存储过程来执行所有的查询；
6.使用专业的漏洞扫描工具。
该系统更适合采用仓库架构风格。
(1)数据存储在中心仓库，处理流程独立，支持交互式处理。
(2)数据与处理紧密关联，调整处理流程需要系统重新启动。
(3)数据与处理分离，需要加载数据，性能降低。
(4)数据处理组件之间一般无依赖关系，可并发调用，提高性能。
逻辑数据模型设计过程包含的任务：
(1)构建系统上下文数据模型，包含实体及实体之间的联系；
(2)绘制基于主键的数据模型，为每个实体添加主键属性；
(3)构建全属性数据模型，为每个实体添加非主键属性；
(4)利用规范化技术建立系统规范化数据模型。
包裹单的逻辑数据模型中包含的实体：
(1)收件人（主键：电话)；
(2)寄件人（主键：电话)；
(3)包裹单（主键：编号）。
超类实体是将多个实体中相同的属性组合起来构造出的新实体。
用户（姓名、电话、单位名称、详细地址）
Redis基本数据类型
(1)STRING类型：常规的key/value缓存应用，常规计数如粉丝数等；
(2)LIST类型：各类列表应用，如关注列表、好友列表、订阅列表等；
(3)SET类型：与LIST类似，但提供去重操作，也提供集合操作，可实现共同关注、共同喜好、共同好友等功能；
(4)HASH类型：存储部分变更数据，如用户数据等；
(5)ZSET类型：类似SET但提供自动排序，也可实现带权重的队列，勿各类排行榜等。
磁盘更新频率：AOF比RDB文件更新频率高。
数据安全：AOF比RDB更安全。
数据一致性：RDB间隔一段时间存储，可能发生数据丢失和不一致；AOF通过append模式写文件，即使发生服务器岩机，也可通过redis-check-aof工具解决数据一致性问题。
重启性能:RDB性能比AOF好。
数据文件大小：AOF文件比RDB文件大。
综合上述五个方面的比较，考虑在系统出现宕机等故障时，需要在最短时间内通过重启等方式重新建立服务，因此开发团队最终选择了RDB方式。
失效场景：如果"定期删除"没删除KEY,也没即时去请求KEY,也就是说"惰性删除"也没生效。这样，Redis默认的"定期删除+惰性删除"策略就失效了。
对此，可采用内存淘汰机制解决：
(1)从已设置过期时间的数据集最近最少使用的数据淘汰。
(2)从已设置过期时间的数据集将要过期的数据淘汰。
(3)从已设置过期时间的数据集任意选择数据淘汰。
(4)从数据集最近最少使用的数据淘汰。
(5)从数据集任意选择数据淘汰。
该工业设备检测系统需与不同设备进行数据交互，采用标准的数据访问机制可以在硬件供应商和软件开发商之间建立一套完整的规则。只要遵循这套规则，数据交互对两者来说都是透明的，硬件供应商只需考虑应用程序的多种需求和传输协议，软件开发商也不必了解硬件的实质和操作过程，实现对设备数据采集的统一管理。
解释器：机器学习流程定义的灵活性高，可扩展能力强，因为解释器风格可以通过自定义流程规则及配套流程解释引擎开发，做到用户层面的流程完全定义，而不需要修改代码，所以无论是修改已有的业务流程，还是要扩展不同的角色，创建新角色的流程都非常便利。
管道过滤器：机器学习流程定义的灵活性较低，可扩展能力较弱，因为管道过滤器是把数据处理职能做成过滤器，把数据传递做成管道，此时如果流程不发生变化，是可以通过这种方式实现的，但一旦流程变化，或是扩展功能，需要对过滤器进行修改调整，或是流程在程序层面重建，此时必须修改代码完成任务。
隐式调用：机器学习流程定义的灵活性一般，可扩展能力一般，隐式调用强调的是通过间接方式进行调用，如采用事件机制，要完成某个动作时先触发事件，事件与相关动作关联，以提升灵活度，本题中可把角色执行业务的流程用事件触发。这种做法比管道过滤器强，但弱于完全自定义的解释器。
常见的反规范化技术包括：
（1）增加冗余列：增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。
（2）增加派生列：增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。
（3）重新组表：重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
（4）分割表：有时对表做分割可以提高性能。
用户查询商品信息应该采用：增加冗余列。
用户查询商品信息时，需要显示药品信息（药品表中），供应商信息（供应商表），库存信息（库存表中），此时查询的是药品表，但表中缺了供应商的信息和库存信息，可以通过增加冗余列的方式把这些信息并过来。以避免连接操作带来的查询性能下降。
针对反规范化数据不一致问题，可采用的解决方案包括：
1、触发器数据同步
2、应用程序数据同步
3、物化视图
Redis和MySQL数据实时同步问题的常见方案
1、实时同步方案，先查缓存，查不到再从DB查询，并保存到缓存；更新缓存时先更新数据库，再将缓存设置过期。
2、异步队列方式同步，可采用消息中间件处理。
3、通过数据库插件完成数据同步。
4、利用触发器进行缓存同步。
对象模型描述了系统的静态结构，一般使用对象图来建模。对象模型是整个体系中最基础，最核心的部分。
动态模型描述了系统的交互次序，一般使用状态图来建模。
功能模型描述 了系统的数据变换，一般使用数据流图来建模。
相互关系：
对象模型描述了动态模型和功能模型所操作的数据结构，对象模型中的操作对应于动态模型中事件和功能模型中的函数；
动态模型描述了对象模型的控制结构，告诉我们哪些决策是依赖于对象值，哪些引起对象的变化，并激活功能；
功能模型描述了由对象模型中操作和动态模型中动作所激活的功能，而功能模型作用在对象模型说明的数据上，同时还表示了对对象值的约束。
网关管理：云平台更强，可以实现远程网关管理，可以对不同地点的多种设备进行统一管理，管理能力更强。
数据处理：数据一般经由网关传递到云上数据库中，再进行处理，这样对数据进行分析、挖掘更便利，同时存储在云端，数据更安全，有容灾能力。
系统性能：数据存在云上数据库中，通信效率更高，同时云也有更强的数据处理能力，所以会更高效。
TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP之所以可靠，是因为建立连接时有3次握手，通信时有回应机制，所以丢了包，能重传以保障通信可靠性。
UDP是一种面向无连接的传输层通信协议，丢了包不会重传，所以不能保障通信可靠性。
可修改性:
面向对象风格通过编写新的规则实现代码，并通过应用重启或热加载添加规则，可修改性稍差;解释器风格通过编写新的规则文件，并通过导入资源文件或外部配置添加规则，可修改性较好。
灵活性:
面向对象风格通过策略模式定义规则对象，规则以程序逻辑实现，灵活性较差，解释器风格可灵活定义规则计算表达式，灵活性更好。
性能:
面向对象风格以编译后代码运算规则，性能好;而虚拟机风格需要加载规则，解析规则，规则运算,再得出结果，性能较差。
从项目关注点来看，系统性能不做过多考虑，则王工建议的解释器风格较为合适;但根据项目需求来看，规则系统风格更加合适该项目。
层间平衡:数据流个数一致，方向一致
图内平衡:有输入无输出的黑洞，有输出无输入的奇迹，输入不足的灰洞
在分析阶段:
数据流图用于界定系统上下文范围和建立业务流程的加工说明，自顶向下对系统进行功能分解;指明数据在系统内移动变换;描述功能及加工规约。
数据字典用于建立业务概念有组织的集合，是模型核心库,有组织的系统相关数据元素列表，使涉众对模型中元素有共同的理解。
在设计阶段
结构化设计根据不同的数据流图类别分别做变换和事务映射来初始化系统结构图;根据数据字典中的数据存储描述来建立数据库存储设计。
李工同步方案思路:
更新数据时在同一事务内依此完成删除缓存，更新数据库，再写入缓存。
张工异步准实时方案思路:
更新数据时在同一事务内首先通过消息队列发布待更新数据的消息给缓存更新服务，再更新数据库;缓存更新服务订阅消息队列，待收到更新事件执行缓存更新。
项目数据量极大，且性能要求高，较适合采用张工提出的异步准实时方案较好。
李工同步方案思路:
更新数据时在同一事务内依此完成删除缓存，更新数据库，再写入缓存。
张工异步准实时方案思路:
更新数据时在同一事务内首先通过消息队列发布待更新数据的消息给缓存更新服务，再更新数据库;缓存更新服务订阅消息队列，待收到更新事件执行缓存更新。
项目数据量极大，且性能要求高，较适合采用张工提出的异步准实时方案较好。
布隆过滤器的原理是当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，只要看看这些点是不是都是1就大概知道集合中有没有它了;如果这些点有任何一个0，则被检元素一定不在;如果都是1，则被检元素很可能在。
优点:
1.增加和查询元素的时间复杂度为:O(K),(K为哈希函数的个数，一般比较小)，与数据量大小无关
2.哈希函数相互之间没有关系，方便硬件并行运算
3.布隆过滤器不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势
4.在能够承受一定的误判时，布隆过滤器比其他数据结构有这很大的空间优势
5.数据量很大时，布隆过滤器可以表示全集,其他数据结构不能6.使用同一组散列函数的布隆过滤器可以进行交、并、差运算缺点:
1.有误判率
2.不能获取元素本身
3.---般情况下不能从布隆过滤器中删除元素
4.如果采用计数方式删除,可能会存在计数回绕问题
MQTT是一个物联网传输协议，它被设计用于轻量级的发布/订阅式消息传输，旨在为低带宽和不稳定的网络环境中的物联网设备提供可靠的网络服务。MQTT是专门针对物联网开发的轻量级传输协议。MQTT协议针对低带宽网络，低计算能力的设备，做了特殊的优化，使得其能适应各种物联网应用场景。
速度:如果使用边缘计算，则物联网设备将在边缘数据中心或本地处理数据。因此,数据无需传输回中央服务器，速度优势明显;
安全:边缘计算将在不同的数据中心和设备之间分配数据处理工作。黑客无法通过攻击一台设备来影响整个网络;
可扩展性:通过购买具有足够计算能力的设备来扩展边缘网络。企业无需为其数据需求建立自己的私有或集中式数据中心;
可靠性:所有的边缘数据中心和物联网设备都位于用户附近。因此，网络中断的可能性非常小。
数据流图：
特点：通过系统内数据的流动来描述系统功能的一种方法。强调系统中的数据流动。由：数据流，外部实体，加工，数据存储。
适用场景：结构化需求分析，为系统做功能建模。
活动图：
特点：与流程图类似，但可以表现并行执行。
适用场景：面向对象分析与设计建模。
流程图：
特点：能清晰展现业务执行的流程顺序。强调控制流。
适用场景：结构化需求分析与结构化设计，为系统梳理业务流程。
1、两阶段提交协议2PC经常用来管理分布式事务。
（1）2PC包含协调者和参与者两类站点，只有协调者才拥有提交或撤销事务的决定权，而其他参与者各自负责在其本地数据库中执行写操作，并向协调者提出撤销或提交事务的意向。
（2）2PC分为两个阶段：表决阶段和执行阶段。
①表决阶段，目的是形成一个共同的决定。协调者给所有参与者发送"准备提交"消息，并进入等待状态，所有参与者给与回复"建议提交"或"建议撤销"。只要有一个结点选择撤销，则整体事务撤销，否则，执行该事务。
②执行阶段，目的是实现这个协调者的决定。根据协调者的指令，参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。
2、两阶段提交协议2PC不能解决当前问题。
（1）分布式数据库遵循的是CAP原则，会在一定程度上牺牲一致性。
（2）大多数NoSQL数据库并不支持2PC。
（3）分布式两阶段提交协议2PC一般针对的对象在逻辑上是一个整体，对某一个整体事务需要在多个物理节点上执行时，进行表决和执行，对多个数据库的不同服务并不是很合适。
去中心化和开放性是区块链的重要特征
1、去中心化
区块链采用了分布式计算和存储，不存在中心化的硬件或管理机构，因此使得任意节点的权利和义务都是均等的。
2、开放性
区块链的系统的一个开放性质的，除了交易各方的私有信息被加密外，区块链的数据对所有人公开的。
分析类图与设计类图的差异
（1）两者产生的阶段不同:分析类图在需求分析阶段产生,设计类图在系统设计阶段产生。
（2）两者的表达重点不同:分析类图用于表达领域（问题域）的概念，设计类图重点描述类与类之间的接口关系。
（3）两者的详细程度不同:分析类图主要是从业务领域获取信息的,在描述上更多使用了业务领域的语言和词汇，不关心类的属性和方法的细节。设计类图是从编程实现角度设计类图，通常是在分析类图的基础上进行细化和改进，更多的是考虑类编码的实现，需要包括类的名称、类属性的可见性、类属性的名称、类属性的数据类型，还要包括类方法的返回值、方法的英文名称和方法的传入参数等细节信息。
边界类主要用于描述外部参与者与系统之间的交互。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式(例如接口)中的变更。
实体类主要是作为数据管理和业务逻辑处理层面上存在的类。实体类的主要职责是存储和管理系统内部的信息,它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。
控制类用于描述一个用例所具有的事件流控制行为，控制一个用例中的事件顺序。控制类是控制其他类工作的类。每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。其他类通常并不向控制类发送消息，而是由控制类发出消息。
组合（composition）:是整体与部分的关系，但部分不能离开整体而单独存在。
继承（inheritance）:表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。
关联（association）:是一种拥有的关系，它使一个类知道另一个类的属性和方法。
聚合（aggregation）:是整体与部分的关系，且部分可以离开整体而单独存在。
依赖（dependency）:是一种使用的关系，即一个类的实现需要另一个类的协助。
组合和继承关系的优缺点:
（1）从封装性方面看，组合关系不破坏封装性，整体类与局部类之间松耦合，彼此互相独立;继承关系破坏封装性，子类与父类之间紧密耦合，子类依赖于父类的实现，子类缺乏独立性。
（2）从动态组合方面看，组合关系支持动态组合，在运行时整体对象可以选择不同的局部对象;继承关系不支持动态继承，在运行时，子类无法选择不同的父类。
（3）从创建对象的方便性方面看，组合关系在创建整体类的对象时，需要创建所有局部类对象;继承关系在创建子类对象时,无须单独创建父类的对象。
主题数据库的设计要求和基本特征
设计要求:为了加速应用系统的开发，主题数据库的逻辑结构应独立于当前的计算机硬件和软件的实现过程,应设计得尽可能稳定。
基本特征:
（1）面向业务主题:主题数据库是面向业务主题来组织的数据存储;（2）信息共享:主题数据库是不同应用系统共建共用的共享数据库;
（3）一次一处输入系统:数据就地采集,就地处理、使用和存储,以及必要的传输、汇总和集中存储;
（4）由基本表组成:主题数据库由多个达到基本规范化要求的数据实体构成。
该方案未满足本项目核心目标的原因
主要的原因在于:
（1）服务粒度的问题:服务是对原有系统功能的包装,通常是粗粒度的，很难实现真正意义上的细粒度、松耦合的服务。
（2）服务编排:由于粗粒度的服务，难以进行真正意义上灵活的服务编排。
云数据库以及云数据库特点
云数据库是指被优化或部署到一个虚拟计算环境中的数据库,具有按需付费、按需扩展、高可用性以及存储整合等能力。
云数据库的特点有:实例创建快速、支持只读实例、读写分离、故障自动切换、数据备份、Binlog备份、SQL审计、访问白名单、监控与消息通知等。
实体对象、控制对象和接口对象的含义
(1)实体对象：用来表示业务域的事实数据并需要持久化存储的对象类型；
(2)控制对象：用来表示业务系统中应用逻辑和业务规则的对象类型；
(3)接口对象：用来表示用户与系统之间交互方式的对象类型。
面向对象系统分析与建模中，从潜在候选对象中筛选系统业务对象的原则
(1)去除相同含义的对象；
(2)去除不属于系统范围内的对象；
(3)去除没有特定独立行为的对象；
(4)去除含义解释不清楚的对象；
(5)去除属于另一个对象属性或行为的对象。
数据流图（Data Flow Diagram, DFD）的主要作用如下：
(1)DFD是理解和表达用户需求的工具，是需求分析的手段。
(2)DFD概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
(3)DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
流程图和活动图有如下三个主要区别：
(1)流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系。而活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。
(2)流程图只能表达顺序执行过程，活动图则可以表达并发执行过程。
(3)活动图可以有多个结束状态，而流程图只能有一个结束状态。
索引过多的副作用有：
(1)过多的索引会占用大量的存储空间；
(2)更新开销，更新语句会引起相应的索引更新；
(3)过多索引会导致查询优化器需要评估的组合增多；
(4)每个索引都有对应的统计信息，索引越多则需要的统计信息越多；
(5)聚集索引的变化会导致非聚集索引的同步变化。
主从复制的基本步骤：
(1)主服务器将所做修改通过自己的I/O线程，保存在本地二进制日志中；
(2)从服务器上的I/O线程读取主服务器上面的二进制日志，然后写入从服务器本地的中继日志;
(3)从服务器上同时开启一个SQL thread，定时检查中继日志，如果发现有更新则立即把更新的内容在本机的数据库上面执行一遍。
在基于消息队列的点对点模式中，消息生产者生产消息并发送到消息队列（Queue)中， 然后消息消费者从Queue中取出并且消费消息。消息被消费以后，Queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只有一个消费者可以消费。
如需求描述，任何一个外卖配送订单（消息）都只能被一个配送员（消费者）接单，所以，应该采用基于消息队列的点对点模式。