1、表示处理流程的工具
图形工具、表格工具和语言工具。
其中常见的图形工具包括程序流程图、IPO 图、盒图、问题分析图、判定树，
表格工具包括判定表，
语言工具包括过程设计语言
2、用例建模过程
识别参与者、合并需求获得用例、细化用例描述和调整用例模型四个阶段，其中前三个阶段是必需的。
3、用例规约
用例编号、用例名称、参与者、简要说明、
事件流、非功能需求、前置条件和后置条件、
扩展点、优先级等。
4、UML 4+1视图
用系统视图描述系统的组织结构
①逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
②进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
③实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
④部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
⑤用例视图。用例视图是最基本的需求分析模型。
5、企业信息化
企业战略与信息化战略集成的主要方法有业务与IT整合和企业IT架构构建。
6、项目可行性分析
主要从经济、技术、法律、用户使用四个方面分析
1．经济可行性
经济可行性也称为投资收益分析或成本效益分析，主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。多数项目只有建设成本能控制在企业可接受的预算内的时候，项目才有可能被批准执行。而经济收益的考虑则非常广泛，可以分为直接收益和间接收益、有形收益和无形收益，还可以分为一次性收益和非一次性收益、可定量的收益和不可定量的收益等。
2．技术可行性
技术可行性也称为技术风险分析，研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。技术可行性主要通过考虑以下问题来进行论证：
（1）技术：现有的技术能力和信息技术的发展现状是否足以支持系统目标的实现。
（2）资源：现有的资源（例如，掌握技术的员工、企业的技术积累、构件库、软硬件条件等）是否足以支持项目的实施。
（3）目标：由于在可行性研究阶段，项目的目标是比较模糊的，因此技术可行性最好与项目功能、性能和约束的定义同时进行。在可行性研究阶段，调整项目目标和选择可行的技术体系都是可以的，而一旦项目进入开发阶段，任何调整都意味着更多的开销。
3．法律可行性
法律可行性也称为社会可行性，具有比较广泛的内容，它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。例如，所开发的系统与国家法律或政策等相抵触，在政府信息化的领域中使用了未被认可的加密算法，未经许可在产品中使用了其他企业的被保护的技术或构件等，这样的项目在法律可行性上就是行不通的。
4．用户使用可行性
用户使用可行性也称为执行可行性，是从信息系统用户的角度来评估系统的可行性，包括企业的行政管理和工作制度、使用人员的素质和培训要求等，可以细分为管理可行性和运行可行性。
（1）管理可行性。管理可行性是指从企业管理上分析系统建设可行性。主管领导不支持的项目一般会失败，中高层管理人员的抵触情绪很大，就有必要等一等，先积极做好思想工作，创造条件。另外，还要考虑管理方法是否科学，相应的管理制度改革的时机是否成熟，规章制度是否齐全等。
（2）运行可行性。运行可行性也称为操作可行性，是指分析和测定信息系统在确定环境中能够有效工作，并被用户方便使用的程度和能力。例如，ERP系统建成后的数据采集和数据质量问题，企业工作人员没有足够的IT技能等。这些问题虽然与系统本身无关，但如果不经评估，很可能会导致投入巨资建成的信息系统却毫无用处。运行可行性还需要评估系统的各种影响，包括对现有IT设施的影响、对用户组织机构的影响、对现有业务流程的影响、对地点的影响、对经费开支的影响等。如果某项影响会过多改变用户的现状，需要将这些因素作进一步的讨论并和用户沟通，提出建议的解决方法。否则，系统一旦建成，甚至在建设过程中，就会受到用户的竭力反对，甚至会抵制使用系统。
7、IDEF
是一系列建模、分析和仿真方法的统称，
从IDEF0到IDEF14（包括IDEF1X在内）共有16套方法
IDEF0（功能建模）、IDEF1（信息建模）、IDEF1X（数据建模）、IDEF2（仿真建模设计）、IDEF3（过程描述获取）、IDEF4（面向对象设计）
8、耦合与内聚
https://xuancg.blog.csdn.net/article/details/141036437
a. 由于固定资产模块和人员管理模块都需要打印，因此把人员管理模块中需要打印的数据存放在缓冲区后调用固定资产模块完成打印任务；
公共耦合，使用公共缓冲区
b. 在固定资产模块中，要求采购申请经过经办人申请、子公司负责人审批、固定资产管理员审核、行政部门审核、财务部门审核、集团领导审批环节并必须按顺序完成；
顺序内聚
c. 为了方便调试，在固定资产模块的调用中增加了参数以控制执行路径；
控制耦合，
d. 把常见的工具放在同一个模块中，即使没有关联；
偶然内聚，完成一组没有关系的任务
e. 为了使用方便，固定资产管理员可以从固定资产模块跳转到系统管理模块中的账套字典维护功能
内容耦合，因为一个模块不通过正常入口转到另一个模块的内部。
f. 为了加强效率，人员管理模块的入职流程中的各个环节必须在半天之内全部完成。
时间内聚，因为包含的任务必须在同一时间间隔内完成。
9、模块化设计三原则
1、多扇入少扇出
2、模块合适大小适中
3、深度、宽度适当
（1）模块的大小要适中。系统分解时需要考虑模块的规模，过大的模块可能导致系统分解不充分，其内部可能包括不同类型的功能，需要进一步划分，尽见使得各个模块的功能单一；过小的模块将导致系统的复杂度增加，模块之间的调用过于频繁，反而降低了模块的独立性。
（2）模块的扇入和扇出要合理。一个模块的扇出是指该模块直接调用的下级模块的个数；扇出大表示模块的复杂度高，需要控制和协调过多的下级模块。
（3）深度和宽度适当。深度表示软件结构中模块的层数，如果层数过多，则应考虑是否有些模块设计过于简单，看能否适当合并。宽度是软件结构中同一个层次上的模块总数的最大值，一般说来，宽度越大系统越复杂，对宽度影响最大的因素是模块的扇出。
10、局部E-R图三大设计冲突
（1）属性冲突。属性冲突包括属性域冲突和属性取值冲突。属性冲突理论上好解决，只要换成相同的属性就可以了，但实际上需要各部门协商，解决起来并不简单。
（2）命名冲突。命名冲突包括同名异义和异名同义。处理命名冲突通常也像处理属性冲突一样，通过讨论和协商等行政手段加以解决。
（3）结构冲突。结构冲突包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是将属性变换为实体或实体变换为属性，使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部E-R图中属性的并集，再适当调整属性的次序。
11、集群系统分类
分为高性能计算集群、负载均衡集群和高可用性集群。
（1）高性能计算集群以解决复杂的科学计算问题为目的，主要解决大规模科学计算问题和存储和处理海量数据问题，特点是一次只运行一个批处理任务。
（2）负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理，每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡，适合处理在线事务。
（3）高可用性集群采用冗余节点和容错技术以提供不间断的服务。一旦某个节点发生故障，甚至可以把在上面运行中的任务转移到别的节点继续运行。
12、CDN内容分发网络
CDN是内容分发网络技术，目前已经是属于云服务的一个基本件。一个系统配置了CDN以后，当终端用户访问这个系统的时候，可以被调度到离用户网络上最近的边缘节点，从而大大减低核心节点的资源损耗，还能提高用户访问的响应速度。
在本系统的情况中，占用大量网络带宽，可以提前把课件资源缓存到边缘节点，从而保护系统核心节点的网络带宽，防止整个系统阻塞。
实时保存学习进度导致大量数据库写操作，可以通过边缘节点的内存数据库暂存学习进度，定期再批量同步到主数据库。
13、微服务架构
微服务架构是一种新型的架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间相互协调、相互配合、为用户提供最终价值。微服务架构中的每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等中。
与传统的单体式系统相比，基于微服务的系统包含以下优势：
（1）模块化。微服务强调模块化的结构，这对大团队来说很重要；
（2）独立部署。简单的服务更容易部署，单个的服务出问题不会导致整个系统的故障；
（3）技术多样性。可以混合使用多种编程语言、开发框架以及数据存储技术。
基于微服务的系统带来的挑战：
（1）分布式特性。分布式系统的编程难度更大，因为远程调用慢，而且总存在失败的风险；
（2）最终一致性。分布式系统的强一致性很难，开发人员需要处理最终一致性的问题；
（3）运维的复杂性。需要成熟的运维团队，管理很多需要重新部署的服务。
14、分布式数据库
1）比集中式数据库的优点
1、节点无单点故障；
2、数据多副本存储
3、水平弹性扩容
4、支持海量数据存储
5、查询任务分节点计算
6、可改善性能。在分布式数据库中可就近分布，使大部分数据可以就近访问，避免了集中式数据库中的瓶颈问题，减少了系统的响应时间，提高了系统的效率，而且降低了通信费用。
7、自治性好。数据可以分散管理，统一协调，即系统中各结点的数据操纵和相互作用是高度自治的，不存在主从控制。
2）分布透明性：
1、分片透明：不考虑表的数据存储采用何种分片算法
2、位置透明：不考虑存储的节点位于哪个机房或主机
3、逻辑透明：不考虑连接的数据节点采用何种数据模型
3）常见的分片算法
水平、垂直、混合、导出
分布式数据库中各局据库应满足集中式数据库的基本需求，除此以外还应保证数据库的全局数据一致性、并发操作的可串行性和故障的全局可恢复性。
15、SDLC与RAD
SDLC（软件开发生命周期）、RAD（快速应用开发）
1）放弃SDLC的原因
(1) 开发时间成为制约软件开发的重要因素。
(2) 不明确的用户需求。
(3) 必须使用不熟悉的开发技术。
2）RAD的优点
(1) 让用户更主动地参与到系统分析、设计和构造活动中来。
(2) 将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、分析员、设计人员和构造人员一同参与。
(3) 通过一种迭代的构造方法加速需求分析和设计阶段。
(4) 让用户提前看到一个可工作的系统。
3）对新技术不熟悉的解决方案
(1 )针对性的培训工作
(2)聘请一个专业顾问来指导项目组使用RAD工具和相关技术。
15、结构化方法
"自顶向下，逐步分解"。适合于数据处理领域的问题，不适合解决大规模的、特别复杂的项目，且难以适应需求的变化。
使用工具：
数据流图（Data Flow Diagram，DFD）、数据字典（Data Dictionary，DD）、结构化语言、判定表、判定树。
系统分析与系统设计
概要设计主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。
16、数据库复制技术
（1） 为了保证数据上传的顺序、稳定、安全、并发、并解决数据库的异构问题，系
统应采用交易中间件技术 。
（2） 为保证分支机构可靠、高效地向数据中心汇总业务数据，避免单点故障，除了
考虑广域网线路采用备份外，在数据中心还应采用
数据中心数据库服务器采用多机集群Cluster；
数据库并行处理技术；
存储设备采用全冗余的SAN结构
（3）数据库复制与触发器技术
采用数据库复制技术，各地需要安装专门的复制服务器，增加成本，维护管理较为复杂，同时，太多分支机构使得中心的数据库复制服务器压力大
采用数据库触发器技术虽然能够实时记录数据库的数据变化，但不能捕获数据表中的TEXT字段的UPDATE动作，并且对于每季度一次的统计报表数据，采用数据库的触发器技术来记录数据库的变化，占用数据库资源太多，可能影响某些机构的日常业务处理。
（4）触发器模式的完善
1、针对多数业务数据的更新，各地数据库采用触发器技术，通过触发器捕获记
录或文字的增删改操作，以标准的SQL命令保存到数据更新日志中；
2、改造各地原有业务系统，当发生数据表TEXT字段修改时，在修改字段的同
一事务中，将该动作增加到数据更新日志中，数据中心根据记录抽取该字段指向的内容；
3、对每季度产生的报表统计数据，改造各地原有业务系统，在数据更新日志中
保存生产数据的条件，数据中心根据记录一次性抽取满足条件的数据。
4、最后，针对个别机构数据库服务器配置较低，采用触发器技术可能造成资源不足的情况，升级该机构的数据库服务器，比如将内存增加到1GB等。
17、信息系统面临的安全威胁
1、物理安全威胁是指对系统所用设备的威胁，如自然灾害、电源故障、数据库故障和设备被盗等造成数据丢失或信息泄漏。
2、通信链路安全威胁是指在传输线路上安装窃听装置或对通信链路进行干扰。
3、网络安全威胁当前主要是指由于因特网的开放性、国际性与无安全管理性，对内部网络形成的严重安全威胁。
4、操作系统安全威胁指的是操作系统本身的后门或安全缺陷，如“木马”和“陷阱门”等。
5、应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁，包括应用系统自身漏洞，也受到“木马”的威胁。
6、管理系统安全威胁指的是人员管理和各种安全管理制度。
18、主要的认证方式
(1) 用户名和口令认证：主要是通过一个客户端与服务器共知的口令(或与口令相关的数据)进行验证。根据处理形式的不同，分为验证数据的明文传送、利用单向散列函数处理验证数据、利用单向散列函数和随机数处理验证数据。
(2) 使用令牌认证：该方式中，进行验证的密钥存储于令牌（U-key），目前的令牌包括安全证书和智能卡等方式。
(3) 生物识别认证：主要是根据认证者的图像、指纹、气味和声音等作为认证数据。
19、授权侵犯
授权侵犯指的是被授权以某一目的使用某一系统或资源的某个人，将此权限用于其他非授权的目的，也称作“内部攻击”。
从系统安全架构设计的角度需要提供抗抵赖框架。
抗抵赖服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。
框架中抗抵赖服务的目的是提供有关特定事件或行为的证据。例如，必须确认数据原发者和接收者的身份和数据完整性，在某些情况下，可能需要涉及上下文关系(如日期、时间、原发者/接收者的地点等)的证据，等等。
20、层次型与SOA架构区别
21、基于SOA的数据整合-信息服务
(1)联邦服务(Federation Service)：提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持XML数据、文本数据和内容数据等非关系型数据。同时，所有的数据仍然按照自己本身的方式管理。
(2)复制服务(Replication Service)：提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
(3)转换服务(Transformation Service)：用于数据源格式到目标格式的转换，可以是批量的或者是基于记录的。
(4)搜索服务(Search Service)：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持如PDF等非结构化数据。
22.1、SOA服务化设计核心
1）服务粒度的控制，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。
2）无状态服务的设计 SOA系统架构中的具体服务应该都是独立的、自包含的请求，服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，最好把它定义成具体的业务流程(BPEL)。
22.2、ESB的主要功能
(1)应用程序的位置透明性
(2)传输协议转换
(3)消息格式转换
(4)消息路由
(5)消息增强
(6)安全支持
(7)监控和管理
22.3、ESB的特点
能够实现灵活的部署结构，包括CS结构、P2P结构等。
待集成系统只需要和总线进行联系，彼此之间不需要互相通信，大大降低了系统的耦合程度。
在加入新的待集成系统时，只需要采用插件的方式实现传输协议和数据格式的适配即可，系统的可扩展性较强。
22.4、集成方式
(1)目前使用的系统设计与开发工具的运行平台和开发语言差异较大，集成框架应无缝集成各个工具的功能，由于需要共享系统的功能，并且系统的运行平台与语言差异较大，
采用面向服务的方式进行功能集成，可以将工具的功能包装为服务，实现跨语言与跨平台访问。
(2)目前使用的系统设计与开发工具所支持的通信协议和数据格式各不相同，集成框架应实现工具之间的灵活通信和数据格式转换，工具所支持的通信协议和数据格式各不相同，并需要实现工具之间的灵活通信协议和数据格式交换，
应该基于消息总线，以协议及数据适配器的方式实现灵活的通信协议和数据格式转换。
(3)集成框架需要根据实际的开发流程灵活、动态地定义系统工具之间的协作关系，集成框架需要根据实际的软件系统开发流程，灵活、动态地定义系统设计与开发工具之间的协作关系，
采用解释器架构风格，引入工作流定义语言及其引擎来动态描述工具之间的协作关系。
(4)集成框架应能集成一些常用的第三方实用工具，如即时通信、邮件系统等
采用界面集成的方法对第三方工具进行集成，绕过工具内部的复杂处理逻辑，实现功能集成。
22.5、实现工具之间数据格式的转换
通常采用适配器设计模式。
即应首先定义一个统一的数据转换接口类，然后针对不同的数据格式转换需求定义对应的实际转换类，实际转换类需要继承数据转换接口类，并实现接口转换类定义的接口
23、数据流图与流程图
1）数据流图作为图形化工具，说明业务处理过程、系统边界内所包含的功能和系统中的数据流
2）流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。
两者的区别主要包括：
(1) 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
(2) 数据流图展现系统的数据流；流程图展现系统的控制流。
(3) 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。
(4) 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。
24、数据流图常见错误
1）一类是语法错误，包括外部实体之间、数据存储之间、外部实体与数据存储之间不经过加工而存在直接数据流；
2）一类是逻辑错误，包括数据黑洞(只有输入没有产生输出)、灰洞(输入不足以产生输出)和（奇迹）无输入有输出。
“分类训练”和“分类处理”加工属于内部加工，“分类规则”数据流属于内部数据流，抽象为“情报分类子系统”加工。其中，“样本数据”、“规则文件”和“配置信息”为输入数据流；“分类结果”为输出数据流
“分类训练”加工属于数据黑洞错误；
“分类处理”加工属于无输入错误；
“规则文件”数据流：外部实体没有经过加工处理，直接到数据存储；
“配置信息”数据流：外部实体之间没有加工处理，存在直接数据流。
25、高质量的数据流图设计三原则
(1) 复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD进行考查。
(2) 接口最小化原则。使得模型中各个元素之间的接口数或连接数最小化。
(3) 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别 是否存在有数据流出但没有相应的数据流入的加工 是否存在有数据流入但没有相应的数据流出的加工。
26、数据库索引
1、索引的创建需要占用一定的存储空间
2、一个表中索引较多，在SQL语句优化分析时，影响数据库对索引的执行产生与预期不一致问题
3、进行增删改操作，都存在对应数据的索引重新构建，影响SQL执行效率
4、对于表字段中数据内容区分不大的字段，设置索引，导致索引不生效；
27、SQL语句优化策略
(1)优化相应的表连接，建立物化视图或尽可能减少多表查询。
(2)以不相干子查询替代相干子查询，即优化嵌套子查询。
(3)只检索需要的列，无须将表中所有的列全部检索，即避免全表的反复查询。
(4)用带IN的条件子句等价替换OR子句。
(5)避免嵌套的游标(Cursor)和多重循环。
(6)经常提交COMMIT，以尽早释放锁等。
28、MVC三层架构
（1）表现层。对应视图(View)。用于为从客户端发来的请求服务的对象及其行为，用于展现数据以及负责View组件实现模式、组件在View显示粒度、页面跳转，以及事件触发等功能。
（2）业务逻辑层。对应控制器(Controller)。用于支持由表现层发起的(某些情况下也可能由持久层直接发起)业务数据的逻辑处理。
（3）持久层。实现持久化存储，对应模型(Model)。用于支持外部资源通信。例如，与数据库交互数据等。
29、Struts2,Spring,Hibernate框架特点
Struts框架的组件在页面中显示的粗粒度，以及框架类的限制，给表示层的开发会带来额外的代码开销。
Spring框架采用依赖注入实现Bean的装配，提供了AOP并据此实现事务管理等，不具备处理应用分布式的能力。
Hibernate是一个开源的O/R Mapping框架，它对JDBC进行了非常轻量级的对象封装，可以应用在任何使用JDBC的场合，完成数据持久化。
30、SSH与EJB框架区别
SSH轻量级框架侧重于减小开发的复杂度，相应的它的处理能力便有所减弱(如事务功能弱、不具备分布式处理能力)，比较适用于开发中小型企业应用。
EJB框架则强调高可用、伸缩性，适用于开发大型企业应用。在EJB体系结构中，一切与基础结构服务相关的问题和底层分配问题都由应用程序容器或服务器来处理，且EJB容器通过减少数据库访问次数及分布式处理等方式提供了专门的系统性能解决方案，能够充分解决系统性能问题。
31、单体应用与集群体系结构区别
