Notes

1.1 系统工程

mindmap
  root((系统工程与信息系统))
    1.系统工程
      1.1系统工程概念
      1.2系统工程方法
        1.2.1霍尔三维结构
        1.2.2切克兰德方法
        1.2.3并行工程方法
        1.2.4综合集成方法
        1.2.5WSR系统方法
      1.3生命周期阶段及方法
        遗留系统演化策略
    2.信息系统基础
    3.企业应用集成EAI
    4.企业信息化
    5.信息系统战略规划
    6.新技术

系统工程

系统工程在上个世纪中后期发展起来的一门新兴学科。它最早约产生于20世纪40年代的美国，时至今日，系统工程已经成为现代社会高速发展不可或缺的一部分。

概念及特点

系统工程利用计算机作为工具，对系统的结构、要素、信息和反馈等进行分析，以达到最优规划、最优设计、最优管理和最优控制的目的
从整体出发、从系统观念出发，以求整体最优

方法

霍尔三维结构
霍尔三维结构是由逻辑维、时间维和知识维组成的立体空间结构。
应用场景：组织和管理大型工程建设项目
1、逻辑维 (解决问题的逻辑过程)：运用系统工程方法解决某一大型工程项目时，一般可分为七个步骤：
- （1）明确问题
- （2）确定目标：建立价值体系或评价体系
- （3）系统综合
- （4）系统分析
- （5）优化：系统方案的优化选择
- （6）系统决策：决策就是管理，决策就是决定
- （7）实施计划：制定计划有了决策就要付诸实施，实施就要依靠严格的有效的计划。
2、时间维（事物和工作推进发生的顺序）对于一个具体的工作项目，从制定规划起一直到更新为止，全部过程可分为七个阶段：
- （1）规划阶段：即调研、程序设计阶段，目的在于谋求活动的规划与战略；
- （2）拟定方案：提出具体的计划方案。
- （3）研制阶段：作出研制方案及生产计划。
- （4）生产阶段：生产出系统的零部件及整个系统，并提出安装计划。
- （5）安装阶段：将系统安装完毕，并完成系统的运行计划。
- （6）运行阶段：系统按照预期的用途开展服务。
- （7）更新阶段：即为了提高系统功能，取消旧系统而代之以新系统，或改进原有系统，使之更加有效地工作。

3、知识维（了解事物需要的专业科学知识）系统工程除了要求为完成上述各步骤、各阶段所需的某些共性知识外，还需要其他学科的知识和各种专业技术，霍尔把这些知识分为工程、医药、建筑、商业、法律、管理、社会科学和艺术等。各类系统工程，如军事系统工程、经济系统工程、信息系统工程等。都需要使用其它相应的专业基础知识。

切克兰德方法

也被称为“软科学”方法，核心不是“最优化”，而是“比较”和“探寻”
7步骤：认识问题、根底定义、建立概念模型、比较及探寻、选择、设计与实施、评估与反馈

并行工程方法（Concurrent Engineering, CE）

“制造过程”与“支持过程”并行。
强调三个方面：产品设计开发期间，最快速度按质完成；各项工作问题协调解决；适当的信息系统工具。

综合集成方法

钱学森命名以解决大规模、多方面和高度复杂的问题
四原则：整体论原则、相互联系原则、有序性原则、动态原则

WSR系统方法

吴敬琏提出，它被认为是解决复杂社会、经济问题的一种实践导向的系统分析方法。WSR代表“物”、“事”、“人”，这三个字分别触及了系统方法应用中需要考虑的三个关键维度：技术层面（物理）、管理层面（事理）和人文层面（人理）。

遗留系统演化策略

把对遗留系统的评价结果分列在坐标的4个象限内。对处在不同象限的遗留系统采取不同的演化策略。

quadrantChart
    title The strategy of Remaining System
    x-axis Low Value --> High Value
    y-axis Low Tech --> High Tech
    quadrant-1 Modify
    quadrant-2 Integrate
    quadrant-3 Drop
    quadrant-4 Inherit

淘汰策略。低水平、低价值象限即遗留系统的技术含量较低，且具有较低的业务价值。对这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。完全淘汰是一种极端性策略，一般是企业的业务产生了根本变化，遗留系统已经基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上考虑更合算。
继承策略。低水平、高价值象限即遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。称这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。
改造策略。高水平、高价值象限即遗留系统的技术含量较高，本身还有强大的生命力。系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，称这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。
集成策略。高水平、低价值象限即遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门(或子公司)的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。

1.2 信息系统

mindmap
  root((系统工程与信息系统))
    1.系统工程
    2.信息系统基础
      2.1信息系统生命周期
      2.2信息系统建设原则
        2.2.1结构法方法
        2.2.2面相对象方法
        2.2.3面相服务方法
        2.2.4其他方法
          2.2.4.1形式化方法
          2.2.4.2统一过程方法UP
          2.2.4.3敏捷方法
          2.2.4.4基于架构的开发方法
      2.3信息系统开发方法
      2.4信息系统的分类
    3.企业应用集成EAI
    4.企业信息化
    5.信息系统战略规划
    6.新技术

信息系统

信息系统开发方法

原型法

结构化方法，面向对象方法，面向服务方法都属于原型法

结构化方法
- 自顶向下，逐步求精
- 应变能力差
结构化方法也称为生命周期法,是一种传统的信息系统开发方法,由结构化分析(Structured Analysis, SA)、结构化设计(Structured Design, SD)和结构化程序设计(Structured Programming,SP)三部分有机组合而成,
- 在结构化分析中，主要进行三个方面的建模:功能建模、行为建模和数据建模。功能建模一般采用数据流图DFD，行为建模一般采用状态转换图，数据建模一般采用ER图
- 结构化设计中， NS盒图、HIPO图、程序流程图均属于结构化设计工具;
  - N-S盒图在流程图中完全去掉流程线，全部算法写在一个知形阵内，在框内还可以包含其他框的流程图形式。即由一些基本的框组成一个大的框，这种流程图又称为N-S结构流程图(以两个人的名字的头一个字母组成)。N-S图包括顺序、选择和循环三种基本结构。
  - HIPO 图由层次结构图和IPO 图两部分构成，层次图描述整个系统的设计结构以及各类模块之间的关系，IPO图描述某个特定模块内部的处理过程和输入输出关系。HIPO 图一般由一张总的层次化模块结构图和若干张具体模块内部展开的IPO 图组成。其精髓是自顶向下、逐步求精和模块化设计。
面相对象方法
- 自底向上
- 符合人类思维习惯
面向对象(Object-Oriented, OO)方法认为,客观世界是由各种"对象"组成的,任何事物都是对象,每一个对象都有自己的运动规律和内部状态,都属于某个对象“类”,是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成,不同对象的组合及相互作用就构成了系统。OO方法是当前的主流开发方法,拥有很多不同的分支体系,主要包括OMT (Object Model Technology,对象建模技术)方法、Coad/Yourdon方法、OOSE(Object-Oriented Software Engineering, 面向对象的软件工程)方法和Booch方法等,而OMT、OOSE和Booch已经统一成为UML (United Model Language,统一建模语言)。
- 面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成;
- 设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
面相服务方法
- 粗粒度，松耦合
- 标准化
- 构件化
面向服务的方法SO方法有三个主要的抽象级别,分别是操作、服务和业务流程。位于最低层的操作代表单个逻辑单元的事物,执行操作通常会导致读、写或修改一个或多个持久性数据。服务的操作类似于对象的方法,它们都有特定的结构化接口,并且返回结构化的响应;位于第二层的服务代表操作的逻辑分组;最高层的业务流程则是为了实现特定业务目标而执行的一组长期运行的动作或活动,包括依据一组业务规则按照有序序列执行的一系列操作。其中操作的排序、选择和执行成为服务或流程的编排,典型的情况是调用已编排的服务来响应业务事件。
其他方法
- 4.1 形式化方法
  形式化开发方法是应用数学和逻辑的严格技术，以确保软件或系统设计的正确性和一致性。
- 4.2 统一过程方法（Unified Process, UP）
  统一过程方法是一个迭代和增量的软件开发框架，旨在通过结构化的阶段和多个迭代来逐步细化和完善软件产品。
- 4.3 敏捷方法
- 4.4 原型化方法
  原型化方法也称为快速原型法,或者简称为原型法。它是一种根据用户初步需求,利用系统开发工具,快速地建立一个系统模型展示给用户,在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。原型法的优点主要在于能更有效地确认用户需求。从直观上来看,原型法适用于那些需求不明确的系统开发。事实上,对于分析层面难度大、技术层面难度不大的系统,适合于原型法开发;而对于技术层面的困难远大于其分析层面的系统,则不宜用原型法。
- 4.5 基于架构的开发方法（Architecture Based Software Development, ABSD)
  基于软件架构的设计ABSD强调由商业、质量和功能需求的组合来驱动软件架构设计。他强调采用视角和视图来描述软件架构，采用用例和 质量属性场景 来描述需求。ABSD方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
  基于架构的软件设计ABSD方法有三个基础，分别是对系统进行功能分解、采用架构风格实现质量属性与商业需求、采用软件模板设计软件结构。
  ABSD把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。
  绝大部分的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员都实现架构，还必须得把架构进行文档化。
  文档是在系统眼花的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计所预先分析的基础。
  架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。
  生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
  在考虑软件架构时，重要的时从不同的视角（perspective）来检查，这促使软件设计师考虑架构的不同属性。
  例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。选择的特定视角或视图也就是逻辑视图，进程视图，实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统的角色，这些角色包括功能，性能等。（配置视图=物理视图=部署视图 其实是同一个东西在不同时期的叫法）

自顶向下开发方法的优点是: 1、可为企业或机构的重要决策和任务实现提供信息。 2、支持企业信息系统的整体性规划，并对系统的各子系统的协调和通信提供保证。3、方法的实践有利于提高企业人员整体观察问题的能力，从而有利于寻找到改进企业组织的途径。自顶向下开发方法的缺点是: 1、对系统分析和设计人员的要求较高。 2、开发周期长，系统复杂，一般属于一种高成本、大投资的工程。 3、对于大系统而言自上而下的规划对于下层系统的实施往往缺乏约束力。 4、从经济角度来看，很难说自顶向下的做法在经济上是合算的。

信息系统的分类

业务处理系统
管理信息系统
决策支持系统

商业智能系统的处理过程包括四个主要阶段：
1. 数据预处理通过数据抽取、转换和装载实现企业原始数据的初步整合；
2. 建立数据仓库是后续数据处理的基础；
3. 数据分析是体现系统智能的关键，主要采用联机分析处理OLAP和数据挖掘技术，前者能够实现数据的上卷、下钻和旋转分析，后者利用隐藏的知识，通过建立分析模型预测企业未来发展趋势；

数据展现主要完成数据处理结果的可化。
专家系统
办公自动化系统
企业资源计划

Case 论决策支持系统的开发与应用

Question

决策支持系统(Decision Support Systems，DSS)是以管理科学、运筹学、控制论和行为科学为基础，以计算机技术、仿真技术和信息技术为手段，以人机交互方式进行半结构化和非结构化决策的信息系统。它调用各种信息资源，并提供各种分析工具，为决策者提供分析问题、建立模型、模拟决策过程和方案的环境，帮助决策者提高决策水平和质量。决策支持系统在许多领域得到了广泛的应用，己成为许多行业经营管理中一个不可缺少的现代化支持工具。请围绕“决策支持系统的开发与应用”论题，依次从以下三个方面进行论述。

概要叙述你参与管理和开发的决策支持系统项目以及在其中所担任的主要工作。
简要叙述决策支持系统包含的典型组成部件及对应的基本功能。说明在建立决策支持系统时需解决的一般关键问题。
说明你所参与管理和开发的决策支持系统的应用场合以及对决策结果的要求，具体阐述在开发过程中所采用的关键技术、实施过程和实际应用的效果。

Answer

简要叙述所参与管理和开发的决策支持系统项目，并明确指出在其中承担的主要任务和开展的主要工作。
决策支持系统包括如下典型组件：
- (1)接口部分，即输入/输出的界面，是人机交互的窗口。
- (2)模型管理子系统，具有存储、动态建模的功能。目前模型管理的实现是通过模型库系统来完成的。
- (3)知识管理子系统，集中管理决策问题领域的知识(规则和事实)，包括知识的获取、表达、管理等功能。
- (4)数据管理子系统，DSS的数据库通常包括在数据仓库中。数据仓库是集成的、面向主题的数据库集合。数据仓库通常从内部和外部数据源中抽取。内部数据主要来自于组织的交易处理系统。外部数据包括行业数据、市场调查数据等。
- (5)用户，用户可看作系统的一部分。DSS的用户主要是企业各层次的管理者和商业分析人员。在建立决策支持系统时，主要有以下几个关键问题：
- 5.1 建立数据仓库系统数据仓库系统必须为决策支持的分析处理提供以下服务：
  - (1)根据主题需要，从OLTP数据库中抽取分析用的数据。为此在抽取过程中要对原始数据进行分类、求和、统计等处理，抽取的过程实际上是数据的再组织
  - (2)在抽取过程中，完成数据净化，即去掉不合格的原始数据，必要时还必须对缺损的数据加以补充。
  - (3)在改变分析决策的主题时，可以按主题进行数据查询和访问。
  - (4)采用多级存储模式，解决数据量巨大及按照主题、粒度划分的数据组织问题。
- 5.2模型、方法和知识管理系统采用数据仓库和多维数据库技术的数据管理子系统将数据进行整理(预处理)和净化之后，形成可靠的易于进行决策的“数据源”(即数据仓库或多维数据库)，这个“数据源”的结构与形式和决策支持系统所采用的模型与知识有关。决策粗略地分为结构化决策支持、非结构化决策支持、半结构化决策支持。一个较好的决策支持系统必须完成这三方面的决策支持。模型、方法和知识的管理是决策支持系统的核心，它对依据问题建立的模型库、方法库和知识库进行管理。
  - (1)对模型库、方法库和知识库进行维护。模型、方法和知识管理系统必须有对三库的维护界面；可根据问题的需要对模型、方法和知识库进行增加、删除和修改，并保证三库的一致性：一是系统运行过程调用每个库时不发生矛盾，特别是对知识库的维护更为复杂；二是每种模型、方法和知识都能调用到。
  - (2)模型、方法和知识管理系统根据用户的要求和数据仓库提供的数据，能有效地选择模型、方法和知识，经系统运行得到相应的结果，并将结果送给交互环境进行输出。智能决策支持系统一般是在模型、方法和知识管理系统的基础上增加专家系统和数据采掘与知识发现技术。智能决策支持系统(Intelligence Decision Support System，IDSS)的主要任务包括：
    - (1)分析和识别问题；
    - (2)描述决策问题和决策知识；
    - (3)形成候选的决策方案(目标、规划、方法和途径等)；
    - (4)构造决策问题的求解模型(如数学模型、运筹学模型、程序模型、经验模型等)；
    - (5)建立评价决策问题的各种准则(如价值准则、科学准则、效益准则等)；
    - (6)多方案、多目标、多准则情况下的比较和优化；
    - (7)综合分析，包括决策结果或方案对实际问题可能产生的作用和影响的分析，以及各种环境因素、变量对决策方案或结果的影响程序分析等。
- 5.3)用户交互环境用户交互环境是决策者或决策部门与决策支持系统打交道的界面，它负责接收用户发出的各种命令，根据这些命令调用不同的子系统，并获得处理结果，最后再将这些结果输出给用户。交互环境的好坏直接影响着用户对系统的使用。一个好的交互环境，其输入应当简单、易学、易用。其输出应当做到内容丰富、形式活泼。3．考生需结合自身参与项目的实际状况，指出其参与管理和开发的决策支持系统的应用行业或领域，选择一个关键问题说明其设计、实现的具体过程、方法以及对实际应用效果的分析。

Warning

Urgent info that needs immediate user attention to avoid problems.

软件体系结构

在软件体系结构的建模和描述中，多视图是一种描述软件体系结构的重要途径，其体现了关注点分离的思想。其中， 4 + 1模型师描述软件体系结构的常用型，在该模型中，“1”指的是统一场景

架构风格

仓库系统体系结构风格是一种通过共享数据的方式进行构件间通信的架构模式。在这种架构中，中央数据结构是共享数据存储的核心，用于记录和反映当前数据的状态，所有的操作都围绕它进行。
黑板架构风格：黑板架构是一种特殊的仓库体系结构，用于支持多种知识源的协作，但更注重动态推理和解决问题的过程，而不是单纯记录数据状态。适合用于设计求解的正确结果不止一个，求解过程比较复杂，需要通过专家知识和反馈逐步得到正确结果的系统
隐式调用风格
规则系统根据外部事件进行响应的场景，以自身状态为基础自动进行处理和动作。属于虚拟机架构的一种。
解释器业务功能灵活组合，形成新的业务功能，属于自定义类型的业务，需要采用虚拟机架构。解释器结构风格属于虚拟机架构的一种。

架构设计是一个迭代的过程，在建立软件架构的初期，选择一个合适的架构风格是首要的；在此基础上，开发人员通过架构模型，可以获得关于软件架构属性的理解，为将来的架构实现与演化过程建立目标

架构风格有哪些？

架构模型有哪些？

什么关系？

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程成为软件生存周期。一个完整的软件生存周期是以需求为出发点，从提出软件开发计划的那一刻开始，直到软件在实际应用中完全报废为止。软件生存周期的提出了是为了更好地管理、维护和升级软件，其中更大的意义在于管理软件开发的步骤和方法。软件生存周期模型又称软件开发模型(software develop model)或软件过程模型(software process model)，它是从某个特定角度提出的软件过程的简化描述。软件生存周期模型主要有瀑布模型、演化模型、原型模型、螺旋模型喷泉模型和基于可重用构件的模型等。瀑布模型是最早使用的软件生存周期模型之一。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。或者说，每一个阶段都是建立在前一个阶段的正确结果之上，前一个阶段的错误和疏漏会隐蔽地带入后一个阶段。这种错误有时甚至可能是灾难性的，因此每一个阶段工作完成后，都要进行审查和确认。演化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助引导出高质量的产品要求。其主要缺点是，如果不控制地让用户接触开发中尚未稳定的功能，可能对开发人员及用户都会产生负面的影响。

1.3 企业信息化&应用集成

mindmap
  root((系统工程与信息系统))
    1.系统工程
    2.信息系统基础
    3.企业应用集成EAI
      3.1 是什么
      3.2 为什么要集成
      3.3 如何集成
    4.企业信息化
      4.1 目的
      4.2 需求
      4.3 方法
    5.信息系统战略规划
      5.1 三阶段
    6.新技术

企业信息化

企业信息化涉及对企业管理理念的创新，管理流程的优化，管理团队的重组和管理手段的革新。管理创新是按照市场发展的要求，对企业现有的管理流程重新整合，从作为管理核心的财务、物料管理，转向技术、物资、人力资源的管理，并延伸到企业技术创新、工艺设计、产品设计、生产制造过程的管理，进而还要扩展到客户关系管理、供应链管理乃至发展到电子商务。

目的

企业信息化旨在提高企业的竞争力

信息化需求

战略需求：提升组织的竞争能力
运作需求：实现信息化战略目标、运作策略、人才培养的需要
技术需要：信息技术层面上对系统的完善、升级、及集成

信息化方法

不是重点

信息化三流

信息流
需求信息流：客户订单，生产计划，采购合同
供应信息流：如入库单，完工报告单，库存记录，提货发运单
资金流
物流

缩写

MIS，Management Information System 管理信息系统
ERP，Enterprise Resource Planning 企业资源计划
主要包括：财会管理、物流管理、生产控制管理、人力资源管理等四个主要功能模块
MRP, Material Requirement Planning 物料需求计划
CRM, Customer Relationship Management 客户关系管理
核心是客户价值管理，其目的是与客户建立长期和有效的业务关系，最大限度地增加利润。市场营销和客户服务时CRM的支柱性功能，是客户与企业产生联系的主要方面。
客户关系管理(CRM) 系统将市场营销的科学管理理念通过信息技术的手段集成在软件上,能够帮助企业构建良好的客户关系。在客户管理系统中,销售自动化是其中最为基本的模块,营销自动化作为销售自动化的补充,包括营销计划的编制和执行、计划结果分析等功能。客户服务与支持是CRM系统的重要功能。目前,客户服务与支持的主要手段有两种,分别是呼叫中心和互联网。CRM系统能够与ERP系统在财务、制造、库存等环节进行连接,两者之间虽然关系比较独立,但由于两者之间具有一定的关系,因此会形成一定的闭环反馈结构。
CRM是一套先进的管理思想及技术手段，它通过将人力资源、业务流程与专业技术进行有效的整合，最终为企业涉及的客户或者消费者的各个领域提供了完美的集成，使得企业可以更低成本、更高效率地满足客户的需求，并与客户建立起基于学习性关系基础上的一对一营销模式，从而让企业可以最大程度提高客户满意度和忠诚度。 CRM系统的主要模块包括销售自动化、营销自动化、客户服务与支持、商业智能。
SCM，Supply Chain Management 供应链管理
整合优化“信息化的三流”，打通企业间“信息孤岛”严格的数据交换标准
BPR，Business Process Reconstruction 业务流程重组
遵循的原则：以流程为中心的原则，以客户为导向的原则，以人为本的原则
BPM，Business Process Management业务流程管理

客户关系管理系统

客户关系管理系统的核心是客户价值管理,而不是客户信息管理。CRM的价值包括:提高工作效率,节省开支、提高客户满意度、提高客户的忠诚度。所谓供应链就有供应商、制造商、分销商、零售商等等所供成的物流的网络,那么同一个企业就可能处在这个网络当中的一个节点,所以SCM他是一种集成的管理思想和方法,从单一的企业角度来看,SCM他是通过改善上下游的关系,整合和优化供应链当中的物流、信息流、资金流,来获得企业的竞争的优势,所以整个供应链的内容大概就包括了计划、采购、制造、配送和退货这五个方面的基本内容,所以整个供应链应该理解为从源头的供应商开始,到最终的消费者的集成的业务整个流程,不仅对消费者带来有价值的消费和服务,而且还能为顾客带来一些有用的信息,在整个SCM当中,他的关键问题,就是配送网络的重构问题以及配送的战略问题,另外一个就是供应链集成与战略伙伴的关系。SCM包括计划、采购、制造、配送、退货五大基本内容。

计划:这是SCM的策略性部分。企业需要有一个策略来管理所有的资源,以满足客户对产品的需求。好的计划是建立一系列的方法监控供应链,使它能够有效、低成本地为顾客递送高质量和高价值的产品或服务。
采购:选择能为企业提供产品和服务的供应商,与供应商建立一套定价、配送和付款流程,并监控和改善管理。
制造:安排生产、测试、打包和准备送货所需的活动,是供应链中测量内容最多的部分,包括质量水平、产品产量和工人的生产效率等的测量。
配送:也称为物流,是调整用户的订单收据、建立仓库网络、派递送人员提货并送货到顾客手中、建立产品计价系统、接收付款。
退货:这是供应链中的问题处理部分。建立网络接收客户退回的次品和多余产品,并在客户应用产品出问题时提供支持。

企业门户

企业门户是一个信息技术平台,这个平台可以提供个性化的信息服务,为企业提供一个单一的访问企业各种信息资源和应用程序的入口。现有的企业门户大致可以分为企业信息门户、企业知识门户和企业应用门户三种。其中企业信息门户重点强调为访问结构数据和无结构数据提供统一入口,实现收集、访问、管理和无缝集成。企业知识门户提供了一个创造、搜集和传播企业知识的平台,通过企业知识门户,员工可以与工作团队中的其他成员取得联系,寻找能够提供帮助的专家。企业应用门户是一个用来提高企业的集中贸易能力、协同能力和信息管理能力的平台。它以商业流程和企业应用为核心,将商业流程中功能不同的应用模块通过门户集成在一起,提高公司的集中贸易能力、协同能力和信息管理能力。

某大型公司欲开发一个门户系统,该系统为访问结构数据和无结构数据提供统一入口,实现收集访问、管理和无缝集成。根据这种需求,采用企业信息门户解决方案最为合适

信息系统战略规划 ISSP

企业战略规划是评价环境和企业现状，进而选择和确定企业的总体和长远目标，指定和选择实现目标的行动方案。信息系统战略规划关注如何通过信息系统来支撑业务流程的运作，进而实现企业的关键业务目标。

第一阶段：以数据处理为核心围绕职能部门需求

关键成功因素法CSF：抓主要矛盾

战略集合转化法SST: 将整个过程看成一个“信息集合”，并将组织的战略目标转成管理信息系统MIS的战略目标

企业系统规划法BSP：通过自伤而下的识别企业目标、企业过程和数据，然后对数据进行分析，自下而上地设计信息系统

第二阶段：以企业内部信息管理系统MIS为核心，围绕企业整体需求进行的信息系统规划
战略数据规划法SDP 信息工程法战略栅格法SGR
第三阶段：综合考虑企业内外环境以集成为核心，围绕企业的战略需求进行的信息系统规划
价值链分析法VCA 战略一致性模型SAM

企业战略数据模型分为数据库模型和数据仓库模型，

数据库模型用来描述日常事务处理中的数据及其关系;
数据仓库模型则描述企业高层管理决策者所需信息及其关系。

在企业信息化过程中，数据库模型是基础，一个好的数据库模型应该客观地反映企业生产经营的内在联系。数据库是办公自动化、计算机辅助管理系统、开发与设计自动化、生产过程自动化、Intranet的基础和环境。

企业应用集成

EAI（企业应用集成）是一种通过系统架构和技术手段，实现企业内部多个系统间数据交换和协作的解决方案。在数据集成方面，EAI主要包括以下方式：

数据复制：将数据从一个系统复制到另一个系统，适合于静态数据或更新频率较低的数据。
基于接口的数据集成：通过定义系统间的数据接口，实现动态数据交换。
数据联邦：通过联邦机制，使多个数据源看起来像一个虚拟数据库，适合实时性要求较高的场景。

EAI技术是将进程、软件、标准和硬件联合起来,在两个或更多的企业信息系统之间实现无缝集成,使它们就像一个整体一样。EAI提供4个层次的服务,从下至上依次为通讯服务、信息传递与转化服务、应用连接服务、流程控制服务,最上层是流程控制服务。

为什么要集成

解决数据孤岛

怎么集成

企业集成通常包括以下五个主要层次：（由易到难）

界面集成，(表示集成), 统一入口，产生整体的感觉，最小代价实现一体化操作
数据集成，将不同来源的数据逻辑或者物理上“集中”，为企业提供全面的数据共享，是其他后续集成方法的基础
控制集成，调用其他系统已有的方法，达到集成效果
过程集成，（物业流程集成），跨企业，或优化流程而非直接调用，企业必须对各种业务信息的交换进行定义、授权和管理，对企业之间的信息共享能力提出了要求
门户集成，将内部系统对接到互联网上

信息资源管理

集成管理是企业信息资源管理的主要内容之一。实行企业信息资源集成的前提是对企业历史上形成的企业信息功能的集成，其核心是对企业内部和外部信息流的集成，其实施的基础是各种信息手段的集成。通过集成管理实现企业信息系统各要素的优化组合，使信息系统各要素之间形成强大的协同作用，从而最大限度地放大企业信息的功能实现企业可持续发展的目的。

企业应用集成

“业务系统的运行平台和开发语言差异较大，而且系统所使用的通信协议和数据格式各不相同”。在这种情况下需要采用总线技术对传输协议和数据格式进行转换与适配。当需要集成并灵活定义系统功能之间的协作关系时，应该采用基于工作流的功能关系定义方式。

企业信息化程度是国家信息化建设的基础和关键，企业信息化方法不包括组织机构变革。

本题考查企业信息化的基本方法。企业信息化程度是国家信息化建设的基础和关键，企业信息化就是企业利用现代信息技术，通过信息咨源的深入开发和广泛利用，实现企业生产过程的自动化、管理方式的网络化、决策支持的智能化和商务运营的电子化，不断提高生产、经营、管理、决策的效率和水平，进而提高企业经济效益和企业竞争力的过程。企业信息化方法主要包括业务流程重构、核心业务应用、信息系统建设、主题数据库、资源管理和人力资本投资方法。企业战略规划是指依据企业外部环境和自身条件的状况及其变化来制定和实施战略，并根据对实施过程与结果的评价和反馈来调整，制定新战略的过程。而供应链管理的简称为(SCM)，属于资源管理方法，是企业信息化方法中的一种。所以答案选B选项

1.4 新技术

数字化

数字化是新一代信息技术，真正推动整个商业模式的变革，推动产业链的重构，推动改进企业与消费者之间的关系，以及企业与合作伙伴之间的关系。

企业数字化转型的五个发展阶段

初始级：数码化：信息的数字化，记录、存储
单元级：数量化：提升单项业务的运行规范性和效率
流程级：数字化：关键业务流程及关键业务与设备设施、软硬件、行为活动等要素件的集成优化
网络级：数模化：企业级数字化和产业互联网网络化，实现一数据位驱动的业务模式创新。
生态级：数用化：生态级数字化和泛在物联网话，推动与生态合作伙伴间资源、业务、能力等要素的开放共享和协同合作。

商业智能

商业智能主要关注如何从业务数据中提取有用的信息，然后根据这些信息采取相应的行动，其核心是构建数据仓库

智能制造

智能制造体系中,5个系统层级主要关注内容如下所述。【设备层】传感器、仪器仪表、机器、装置等。【单元层】企业内处理信息、实现监测和控制物理流程的层级。【车间层】面向工厂或车间的生产管理的层级。【企业层】面向企业经营管理的层级。【协同层】其内部和外部信息互联和共享,实现跨企业间业务协同的层级。

2.1 软件工程-需求工程

mindmap
  root((软件工程))
    1.开发模型
    2.需求工程
      2.1 需求获取
      2.2 需求分析
      2.3 需求定义
      2.4 需求验证
      2.5 需求管理
    3.软件设计
    4.维护
    5.测试

按照传统的软件生命周期方法学，可以把软件生命周期划分为软件定义、软件开发、软件运行与维护3个阶段。其主要活动阶段包括:可行性分析与计划制订、需求分析、软件设计(概要设计和详细设计)、软件实现(编码).测试、维护等活动，其中软件开发阶段包括软件设计、实现与测试。

需求获取

JRP是一种相对来说成本较高的需求获取方法(而非需求分析与验证的方法),但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。通常该会议的参与人数为6~~18人,召开时间为1~~5小时。JRP的主要意图是收集需求,而不是对需求进行分析和验证。实施JRP时应把握以下主要原则:

在JRP实施之前,应制订详细的议程,并严格遵照议程进行。
按照既定的时间安排进行。
尽量完整地记录会议期间的内容。
在讨论期间尽量避免使用专业术语。
充分运用解决冲突的技能。
会议期间应设置充分的间歇时间。
鼓励团队取得一致意见。
保证参加JRP的所有人员能够遵守事先约定的规则。

JRP将会起到群策群力的效果,对于一些问题最有歧义的时候、对需求最不清晰的领域都是十分有用的一种方法。这种方法最大的难度是会议的组织和相关人员的能力,要做到言之有物,气氛开放。否则,将难以达到预想的效果。

需求分析

结构化需求分析
面向对象分析

需求定义

需求变更

在需求管理过程中需求的变更是受严格管控的,其流程为:

问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议,以检查它的有效性,从而产生一个更明确的需求变更提议。
变更分析和成本计算。使用可追溯性信息和系统需求的一般知识,对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且确认,应该进行是否执行这一变更的决策。
变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更,然后再修改需求文档,这几乎不可避免地会出现需求文档和程序的不一致。

需求管理

需求管理的主要活动包括：变更控制、版本控制、需求跟踪、需求状态跟踪

需求跟踪

需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪,这些元素包括各种类型的需求、业务规则、系统架构和构件、源代码、测试用例,以及帮助文件等。需求跟踪一般采用需求跟踪矩阵做跟进工作,跟踪矩阵将从需求源头一直跟进到最终的软件产品。

需求跟踪时,是分层次进行的,首先需要确认从用户方获取的需求,是否与软件需求能一一对应,然后再看软件需求到下一级工作产品之间是否存在 – 对应的关系。这样层层传递的方式,可以尽量避免开发不需要的功能,以及遗漏该开发的内容。

UML

为实现对象重用，COM支持两种形式的对象组装，在包含重用形式下，一个外部对象拥有指向一个内部对象的唯一引用，外部对象只是把请求转发给内部对象;在聚集重用形式下，直接把内部对象的接口引用传给外部对象的客户，而不再转发请求。 COM不支持任何形式的实现继承 COM支持两种形式的对象组装:包含(Containment)和聚集(Aggregation)。包含是一个对象拥有指向另一个对象的唯一引用。外部对象只是把请求转发给内部对象，所谓转发就是调用内部对象的方法包含能重用内含于其他构件的实现，是完全透明的。如果包含层次较深，或者被转发的方法本身相对简单，包含会存在性能上的问题因此 COM定义第二类重用形式，聚集。聚集直接把内部对象接口引用传给外部对象的客户，而不是再转发请求、保持透明性是很重要的，因为外部对象的客户无法辨别哪个特定接口是从内部对象聚集而来的。

需求跟踪能力链

利用需求跟踪能力链(traceability link)可以跟踪一个需求使用的全过程,也就是从初始需求到实现的前后生存期。需求跟踪能力链有4类

概要设计

软件概要设计将软件需求转化为软件设计的数据结构和软件的系统结构

详细设计

过程设计，通过对结果细化，得到软件详细数据结构和算法

2.2 软件工程-开发模型

mindmap
  root((软件工程))
    1.开发模型
      1.1 瀑布模型
      1.2 原型模型
      1.3 V模型
      1.4 迭代与增量
      1.5 螺旋模型
      1.6 基于构件的开发模型CBSD
      1.7 既有构件的软件工程CBSE
      1.8 快速应用开发RAD
      1.9 统一过程UP/RUP
      1.10 敏捷方法
      1.11 逆向工程
      1.12 净室软件工程
    2.需求工程
    3.软件设计
    4.维护
    5.测试

软件过程模型的基本概念:软件过程是制作软件产品的一组活动以及结果,这些活动主要由软件人员来完成,软件活动主要有:

(1) 软件描述。必须定义软件功能以及使用的限制。
(2) 软件开发。也就是软件的设计和实现,软件工程人员制作出能满足描述的软件。
(3) 软件有效性验证。软件必须经过严格的验证,以保证能够满足客户的需求。
(4) 软件进化。软件随着客户需求的变化不断地改进。

瀑布模型

严格区分各阶段，每个阶段因果关系紧密
只适合需求明确的项目

flowchart LR
    A[需求分析] --> B[软件设计]
    B --> C[程序设计]
    C --> D[编码实现]
    D --> E[单元测试]
    E --> F[集成测试]
    F --> G[系统测试]
    G --> H[运行维护]

瀑布模型可以说是最早使用的软件生存周期模型之一。由于这个模型描述了软件生存的一些基本过程活动,所以它被称为软件生存周期模型。这些活动从一个阶段到另一个阶段逐次下降,形式上很像瀑布。瀑布模型的特点是因果关系紧密相连,前一个阶段工作的结果是后一个阶段工作的输入。

原型模型

适合需求不明确的项目
原型模型两个阶段：
- 原型开发阶段
- 目标软件开发阶段

flowchart LR
    A{原型开发} --> |T| B[需求分析]
    A --> |T| I[软件设计]
    A --> |T| C[程序设计]
    B --> I[软件设计]
    I --> C[程序设计]
    C --> D[编码实现]
    D --> E[单元测试]
    E --> F[集成测试]
    F --> G[系统测试]
    G --> H[运行维护]

原型开发分两大类:快速原型法(又称抛弃式原型法)和演化式原型法。其中快速原型法是快速开发出一个原型,利用该原型获取用户需求,然后将该原型抛弃。而演化式原型法是将原型逐步进化为最终的目标系统

V模型

测试贯穿于始终
测试分阶段，测试计划提前
需求分析->验收测试与系统测试；概要设计对应集成测试，详细设计对应单元测试。

flowchart LR
    A[需求分析] --> B[概要设计]
    B --> C[详细设计]
    C --> D[编码]
    D --> |V模型|E[单元测试]
    E --> F[集成测试]
    F --> G[系统测试]
    G --> H[验收测试]

迭代与增量

螺旋模型

以快速原型为基础 + 瀑布模型，也有说他是 原型 + 生命周期模型
考虑了风险问题

螺旋模型将整个软件开发过程分为多个阶段，每个阶段都由目标设定、风险分析、开发和有效性验证以及评审4个部分组成。螺旋模型是在快速原型的基础上扩展而成的一种生存周期模型。这种模型将整个软件开发流程分成多个阶段，每个阶段都由4部分组成，它们是：

指定计划目标。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。
风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险。
实施工程。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。
客户评估。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。

螺旋模型的软件开发过程实际是上述4个部分的迭代过程，每迭代一次，螺旋线就增加一周，软件系统就生成一个新版本，这个新版本实际上是对目标系统的一个逼近。经过若干次的迭代后，系统应该尽快地收敛到用户允许或可以接受的目标范围内，否则也可能中途夭折。

基于构件的开发模型

优点: 易扩展、易重用、降低成本、安排任务更灵活。
缺点：构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其他指标、第三方构件质量难控制

flowchart LR
    A[需求分析和定义] --> B[设计构件组装]
    B --> C[建立构件库]
    C --> D[构建应用软件]
    D --> E[测试和发布]
    I["CORBA
    Sun的J2EE"] --> F[/构件标准\]
    F --> C
    C --> H[(构件库)]
    J[构件获取] --> H
    K[构件管理] --> H

基于构件的开发模型的优点如下:

(1)构件的自包容性让系统的扩展变得更加容易。
(2)设计良好的构件更容易被重用,降低软件开发成本。
(3)构件的粒度较整个系统更小,因此安排开发任务更加灵活,可以将开发团队分成若干组,并行地独立开发构件。

在基于构件的软件开发中,逻辑构件模型用功能包描述系统的抽象设计,用接口描述每个服务集合,以及功能之间如何交互以满足用户需求,它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模型用技术设施产品、硬件分布和拓扑结构、以及用于绑定的网络和通信协议描述系统的物理设计,这种架构用于了解系统的性能、吞吐率等许多非功能性属性。

基于构件的开发模型利用模块化方法将整个系统模块化,并在一定构件模型的支持下复用构件库中的一个或多个软件构件,通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征,本质上是演化形的,开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。

基于构件的软件工程

体现了购买而不是重新构造的哲学

快速应用开发RAD

flowchart LR
    A[瀑布模型] --> B[快速应用开发RAD]
    C[基于构件CBSD] --> B
    B --> D["
    √ 业务建模
    √ 数据建模
    √ 过程建模
    √ 应用生成
    √ 测试与交付
    "]

快速应用开发利用了基本构件开发模型的思想,大量采用现成的构件进行系统的开发,所以速度很快。但这种开发,要求系统模块化程度高,因为只有这样,才能更好利用现有的构件。

快速应用开发(Rapid Application Development, RAD)是一种比传统生存周期法快得多的开发方法,它强调极短的开发周期。RAD模型是瀑布模型的一个高速变种,通过使用基于构件的开发方法获得快速开发。如果需求理解得很好,且约束了项目范围,利用这种模型可以很快地开发出功能完善的信息系统。但是RAD也具有以下局限性:

并非所有应用都适合RAD。RAD对模块化要求比较高,如果有哪一项功能不能被模块化,那么RAD所需要的构建就会有问题;如果高性能是一个指标,且该指标必须通过调整接口使其适应系统构件才能获得,则RAD也有可能不能奏效。
开发者和客户必须在很短的时间完成一系列的需求分析,任何一方配合不当,都会导致RAD项目失败。
RAD只能用于管理信息系统的开发,不适合技术风险很高的情况。例如,当一个新系统要采用很多新技术,或当新系统与现有系统有较高的互操作性时,就不适合使用RAD。

统一过程UP/RUP

统一软件开发过程是一种基于面向对象技术的软件开发过程，其特点是用例驱动，以架构为核心，迭代并增量。统一软件开发过程定义了四种通用的开发阶段，它们按照过程顺序分别是：初始阶段、细化阶段、构建阶段和 移交阶段。

初始阶段：
- 定义最终产品视图和业务模型
- 确定系统范围
细化阶段：
- 设计及确定系统架构
- 制定工作计划及资源要求
构造阶段：
- 开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试
移交阶段：
- 确保软件对最终用户是可用的，进行β测试，制作产品发布版本
9个核心工作流
1. 业务建模
2. 需求
3. 分析与设计
4. 实现
5. 测试
6. 部署
7. 配置与变更管理
8. 项目管理
9. 环境

统一过程（UP）定义了初启阶段、精化阶段、构建阶段、移交阶段和产生阶段，每个阶段达到某个里程碑时结束。其中初启阶段的里程碑是生命周期目标，精化阶段的里程碑是生命周期架构，构建阶段的里程碑是初始运作功能，移交阶段的里程碑是产品发布。

统一过程适合于大、中型项目的开发，可以分为4个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和移交阶段。

初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。

细化阶段的任务是分析问题领域，建立健全的架构基础，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。

在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件做好准备。在构建阶段，开发团队的工作可以实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现并行开发。

当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，如进行调试、性能或可用性的增强等。根据产品的种类，交付阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版本可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。交付阶段结束时也要进行技术评审，评审目标是否实现，是否应该开始演化过程，用户对交付的产品是否满意等。

分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；最终用户关心的是系统的功能，因此会侧重于逻辑视图；程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图；系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。

flowchart LR
    A[初始] --> B[细化]
    B --> C[构造]
    C --> D[移交]
    D --> A

优点： 1、降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。 2、降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。 3、加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。 4、由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

敏捷方法

强调个体和交互胜过过程和工具
以人为本
增量迭代，小步快跑
适合小型项目
面向对象

敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷方法中,软件项目的构建被切分成多个子项目, 各个子项目成果都经过测试,具备集成和可运行的特征。在敏捷方法中,从开发者的角度来看,主要的关注点有短平快的会议、小版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整和结对编程;从管理者的角度来看,主要的关注点有测试驱动开发、持续集成和重构。

具体方法

极限编程XP：强调面对面沟通、不过度设计、及时反馈、接受变更
水晶方法：Cockburn的水晶系列方法,水晶系列方法是由Alistair Cockburn提出的。它与XP方法一样,都有以人为中心的理念,但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程,因此,与XP的高度纪律性不同,Alistair探索了用最少纪律约束而仍能成功的方法,从而在产出效率与易于运作上达到一种平衡。也就是说,虽然水晶系列不如XP那样的产出效率,但会有更多的人能够接受并遵循它。
迭代式增量软件开发过程SCRUM：侧重于项目管理；SCRUM已经出现很久了,像前面所论及的方法一样,该方法强调这样一个事实,即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中,为明确定义了的可重复的人员所用,去解决明确定义了的可重复的问题。
特征驱动开发方法FDD: 认为有效的软件开发需要三要素：【人、过程、技术】，定义了6中关键角色：项目经理、首席架构设计、开发经理、主程序员、程序员和领域专家
开放式源码：这里提到的开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处,就是程序开发人员在地域上分布很广,这使得它和其他敏捷方法不同,因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障(debug)的高度并行性,任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库。
ASD方法,ASD (Adaptive Software Development) 方法由Jim Highsmith提出,其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。

逆向工程

逆向工程是设计的回复过程，包括以下4个等级：

实现级：包括程序的抽象语法树、符号表、过程的设计表示
结构级：包括反应程序分量之间相互依赖部分的信息，例如调用图、结构图、程序和数据结构
功能级：包括反应程序段功能及程序段之间关系的信息，例如数据和控制流模型
领域级：包括反应程序分量或程序等实体与应用领域概念之间对应关系的信息，例如实体关系图

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。 (1)重构(restructuring)。重构是指在同一抽象级别上转换系统描述形式。 (2)设计恢复(designrecovery)。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。 (3)逆向工程(reverseengineering):逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。 (4)正向工程(forwardengineering)。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。 (5)再工程(re-engineering)。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

净室软件工程

软件设计

软件设计包括体系结构设计、接口设计、数据设计和过程设计，

（体系）结构设计:定义软件系统各主要部件之间的关系。
数据设计:将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性
接口设计(人机界面设计):软件内部，软件和操作系统之间以及软件和人之间如何通信。
过程设计:系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。

2.3 软件工程-软件测试

mindmap
  root((软件工程))
    1.开发模型
    2.需求工程
      2.1 需求获取
      2.2 需求分析
      2.3 需求定义
      2.4 需求验证
      2.5 需求管理
    3.软件设计
    4.维护
    5.测试

测试与调试

测试是为了发现软件中存在的错误，调试是为了定位并修正错误。

测试以已知条件开始，使用预先定义的程序，且有预知的结果;调试一般是以不可知的内部条件开始，没有预先定义的过程，除统计性调试外，结果是不可预见的
测试是有计划的，需要进行测试设计;调试是一个推理的过程，需要调试者去解释，去发现产生的原因，没有实现设计。
软件测试可以描述过程或持续时间，软件测试过程主要有:分析需求文档、测试用例设计、测试执行过程、测试结果分析、形成测试报告。而软件测试周期并行与软件生命周期，存在于软件生命周期的各个阶段

测试种类

单元测试也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类(统称为模中的功能、性能、接口和其他设计约束等条件，发现模块内块)，其目的是检查每个模块能否正确地实现设计中的功能、性能、接口和其他设计约束等条件，发现模块内可能存在的各种差错。单元测试的技术依据是软件详细设计说明书。
集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。集成测试的技术依据是软件概要设计文档。集成视试是根据软件概要设计文档来进行测试，因为概要设计文档中涉及了功能信息的相关信息及要求.
系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和件开发合同规定的要求。系统测试的技术依据是用户需求或开发合同，除应满足一般测试的准入条件外，在进行系统测试前，还应确认被测系统的所有配置项已通过测试对需要固化运行的软件还应提供固件。
回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能回其他规定的要求的不损害性。

软件单元测试

在单元测试中，驱动模块用来调用北侧模块，自顶向下的单元测试中不需要另外编写驱动模块

软件集成测试

软件集成测试将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。从组装策略而言，可以分为一次性组装和增量式组装。集成测试计划通常是在软件概要设计阶段完成，集成测试一般采用黑盒测试方法。

软件确认测试

软件确认测试也成有效性测试，主要验证软件功能、性能及其他特性是否与用户需求一致。确认测试计划通畅是在需求分析阶段完成的。根绝用户的参与程度不同，软件确认测试通常包括内部测试、Alpha、Beta和验收测试

测试目的

根据测试目的不同，性能测试主要包括压力测试、负载测试、并发测试和可靠性测试等。

强度测试:是在系统资源特别低的情况下考查软件系统极限运行情况。
负载测试:用于测试超负荷环境中程序是否能够承担，确定在各种工作负载下系统的性能，测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试:通过确定系统的瓶颈或不能接收的性能点，来获得系统能够提供的最大服务级别的测试。负载测试和压力测试可以结合进行，统称为负载压力测试。
容量测试:并发测试也称为容量测试，主要用于测试系统可同时处理的在线最大用户数量。
并发测试：也称为容量测试

自动化测试

自动化测试工具主要使用脚本技术来生成测试用例，测试脚本不仅可以在功能测试上模拟用户的操作，比较分析,而且可以用在性能测试、负载测试上。虚拟用户可以同时进行相同的、不同的操作，给被测软件施加足够的数据和操作，检查系统的响应速度和数据吞吐能力。线性脚本，是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。结构化脚本，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。也允许其他脚本调用。共享脚本可以在不同主机、不同共享脚本，共享脚本是指可以被多个测试用例使用的脚本，系统之间共享，也可以在同一主机、同一系统之间共享。数据驱动脚本，将测试输入存储在独立的(数据)文件中，而不是存储在脚本中。可以针对不同数据输入实现多个测试用例。关键字驱动脚本，关键字驱动脚本是数据驱动脚本的逻辑扩展。它将数据文件变成测试用例的描述，采用一些关键字指定要执行的任务。

静动态测试

静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试采用桌前检查（Desk Checking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误。与之对应的动态测试是利用计算机运行得到测试结果的方式进行测试。

测试工具根据工作原理不同可分为静态测试工具和动态测试工具。其中静态测试工具是对代码进行语法扫描，找到不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。它直接对代码进行分析，不需要运行代码，也不需要对代码编译链接和生成可执行文件，静态测试工具可用于对软件需求、结构设计、详细设计和代码进行评审、走审和审查，也可用于对软件的复杂度分析、数据流分析、控制流分析和接口分析提供支持;动态测试工具与静态测试工具不同，它需要运行被测试系统，并设置探针，向代码生成的可执行文件中插入检测代码，可用于软件的覆盖分析和性能分析，也可用于软件的模拟、仿真测试和变异测试等。静态分析通过解析程序文本从而识别出程序语句的各个部分，审查出可能的缺陷和异常之处，静态分析包括五个阶段:控制流分析阶段找出并突出显示那些带有多重出口或入口的循环以及不可达到的代码段;数据使用分析阶段突出程序中变量的使用情况:接口分析阶段检查子程序和过程说明及它们使用的一致性;信息流分析阶段找出输入变量和输出变量之间的依赖关系;路径分析阶段找出程序中所有可能的路径并画在此路径中执行的语句。

动态测试是通过运行程序发现错误，包括黑盒测试（等价类划分、边界值分析法、错误推测法）与白盒测试（各种类型的覆盖测试）。黑盒测试不关注程序的内部结构，只从程序块的功能、输入、输出角度分析问题，设计测试用例并展开测试工作。

黑盒测试也称为功能测试，主要用于集成测试，确认测试和系统测试阶段。黑盒测试根据软件需求规格说明所规定般包括功能分解、等价类划分、边界值分析、判定表、因果图、状态图、随机测试、错的功能来设计测试用例，一误推测和正交试验法等。确认测试中，需要“确认”的，是用户需求。所以这种测试有一个显著的特点，就是测试必须要有用户的参与。在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对每一个输入条件确定若干个有效等价类和若干个无效等价类，分别设计覆盖有效等价类和无效等价类的测试用例。
无效等价类是用来测试非正常的输入数据的，所以要为每个无效等价类设计一个测试用例。
边界值分析通过选择等价类边界作为测试用例，不仅重视输入条件边界，而且也必须考虑输出域边界。在实际测试工作中，将等价类划分法和边界值分析结合使用，能更有效地发现软件中的错误。
因果图方法是从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出或程序状态的改变)，可以通过因果图转换为判定表。
正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率，

驱动模块与桩模块

驱动模块是用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启用被测模块，并打印出相应的结果。
桩模块(Stub)是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。主模块作为驱动模块，与之直接相连的模块用桩模块代替。在集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接收或传递被测模块的数据，这些专供测试用的"假"模块称为被测模块的桩模块

静态分析

静态分析(static analysis)是一种对代码的机械性的、程式化的特性分析方法。静态分析一般常用软件工具进行，包括控制流分析、数据流分析、接口分析、表达式分析。

用数据流图来分析数据处理的异常现象(数据异常)，这些异常包括初始化、赋值、或引用数据等的序列的异常。
使用控制流图系统地检查程序的控制结构。按照结构化程序规则和程序结构的基本要求进行检查。控制流图描述了程序元素和它们的执行顺序之间的联系。一个程序元素通常是一个条件、一个简单的语句，或者一块语句(多个连续语句)
接口分析涉及子程序以及函数之间的接口一致性，包括检查形参与实参类型、个数、维数、顺序的一致性。当子程序之间的数据或控制传递使用公共变量块或全局变量时，也应检查它们的一致性。
表达式分析:括号不匹配、数组引用越界、除数为零

AB测试

Alpha测试(a测试)是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员(有的地方又说可以让测试人员进行)完成。
Beta测试(B测试)是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。

系统测试

系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统方案说明书来设计测试例子的，常见的系统测试主要有以下内容:

恢复测试:恢复测试监测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统是否按照要求能从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。如果系统的恢复是自动的(由系统自动完成)，需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。
安全性测试:系统的安全性测试是检测系统的安全机制、保密措施是否完善，主要是为了检验系统的防范能力。测试的方法是测试人员模拟非法入侵者，采用各种方法冲破防线。系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大，此时非法入侵已无利可图。
强度测试:是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行时，性能下降的幅度是否在允许的范围内。因此，强度测试要求系统在非正常数量、频率或容量的情况下运行。强度测试主要是为了发现在有效的输入数据中可能引起不稳定或不正确的数据组合。例如，运行使系统处理超过设计能力的最大允许值的测试例子；使系统传输超过设计最大能力的数据，包括内存的写入和读出等。
性能测试:检查系统是否满足系统设计方案说明书对性能的要求。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分所有都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞叶量、处理精度等方面来检测。
可靠性测试:通常使用以下两个指标来衡量系统的可靠性:平均失效间隔时间MTBF(mean time betweenfailures)是否超过了规定的时限，因故障而停机时间MTTR(mean time torepairs)在一年中不应超过多少时间。
安装测试:在安装软件系统时，会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否容易操作等。主要监测系统的每一个部分是否齐全，硬件的配置是否合理，安装中需要产生的文件和数据库是否已产生，其内容是否正确等。

测试准确性

真实程序、核心程序、小型基准程序和合成基准程序，其评测准确程度依次递减。合成基准程序覆盖面广了，但是毕竟不是全覆盖，造成了系统的不确定或者说增加了跟真实系统偏离的概率，所以相对单个的小型基准程序来说更不准确，

基准程序

在实际应用中，用户通常依靠评价程序来测试系统的性能。以下评价程序中，合成基准程序的评测准确程度最低。事务处理性能委员会(Transaction Processing Performance Counci, TPC)是制定商务应用基准程序(benchmark)标准规范、性能和价格度量，并管理测试结果发布的非营利组织，其发布的TPC-C是 在线事务处理 的基准程序。

软件维护的类型

软件维护的类型包括:改正性维护(正确性维护)、适应性维护、完善性维护、预防性维护。

改正性维护:在软件交付使用后，必然会有一部分隐藏的错误被带到运行阶段来。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误使用，应当进行的诊断和改正错误的过程，就叫作改正性维护。
适应性维护:随着计算机的飞速发展，外部环境(新的硬、软件配置)或数据环境(数据库、数据格式、数据输入输出方式、数据存储介质)可能发生变化，为了使软件适应这种变化，而去修改软件的过程就叫作适应性维护。完善性维护:在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫作完善性维护。
预防性维护:为了提高软件的可维护性、可靠性等而提出的一种维护类型，它为以后进一步改进软件打下良好基础。通常，预防性维护定义为:“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。

2.4 软件工程-UML

mindmap
  root((软件工程))
    1.开发模型
    2.需求工程
      2.1 需求获取
      2.2 需求分析
      2.3 需求定义
      2.4 需求验证
      2.5 需求管理
    3.软件设计
    4.维护
    5.测试

结构式建模图

类图

类图是一个静态图，它是用来模拟一个系统的静态视图，也被认为是类图作为基础组件图和部署图类图不仅用于可视化系统的静态视图，但它们也可用于构建可执行代码的任何系统中的前向和反向工程UML图一般不直接映射到任何面向对象的编程语言，但在类图是一个例外。类图清楚地显示了映射面向对象语言，如ava，C++等，因此，从实际经验的类图通常用于构建用途,因此类图可以用来:

描述系统的静态视图，
显示静态视图中的元素之间的协作,
由系统执行的功能的描述，
构建软件应用面向对象的语言，

对象图

对象图可以被想象成正在运行的系统在某一时刻的快照。我们可以举一个例子来描述它:一个正在运行的列车。现在，如果运行一个单元列车运行，那么会发现它具有以下静态图片:

这是一个特别的运行状态
一个特定的乘客数量。如果捕捉在不同的时间，这将在不断改变所以，在这里我们可以想像的列车运行的管理单元是一个对象，具有上述值。任何现实生活中的简单或复杂的系统而目的确如此,对象图可用于:

使一个系统的原型，
逆向工程。
造型复杂的数据结构。
从实用的角度了解系统。
捕捉实例和链接。
详细描述瞬态图,

包图

组件图

部署图

复合结构图

行为式建模图

活动图

活动图是适用于该系统的活动流程建模。应用程序可以有多个系统。活动图也抓住了这些系统，并介绍了流程从一个系统到另一个。在其他图中，这个特定的用法，不提供。这些系统可以是数据库，外部队列或任何其他系统。现在，我们将看看活动图到实际应用。从上面的讨论，很显然，活动图是来自一个非常高的级别。因此，它给出了一个系统的高级视图，这种高层次的观点主要是针对企业用户或任何其他人而不是一个技术人员，以下是活动图的主要用途:

使用业务建模工作流程,
建模的业务需求。
高层次的理解系统的功能。
调查在后一阶段的业务需求,

状态图

UML 状态图可以捕获对象、子系统和系统的生命周期，可以告知一个对象可以拥有的状态，并且事件(如消息的接收，时间的流逝、错误、条件为真等)会怎样随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标志状态和复杂行为的类;该图可以确定类的行为以及该行为如何根据当前的状态而变化，也可以展示哪些事件将会改变类的对象的状态。状态图主要是为了模拟响应系统, 以下是使用状态图的主要目的:

为了模拟系统的动态环节，
反应系统模型生命周期。
一个对象来描述不同的状态，在其生命周期的时间，
定义一个状态机模型状态的对象，

用例图

要了解一个系统的动态，我们需要使用不同类型的图表。用例图就是其中之一，其具体目的是收集系统的的需求和参与者。用例图指定系统的事件和他们的流向。但从未用例图描述了他们是如何实现的。可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。在这些图中使用的设计在一个非常高的水平，那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。一个结构良好的用例还介绍了前置条件，后置条件和例外。而这些多余的元素在执行测试时被用来制造测试的情况下。用例都不是正向和反向工程，但他们仍然使用略有不同的方式。同样是真实的逆向工程，仍用例图的使用方式不同，使其逆向工程的一个候选,在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节,所以下面的地方使用用例图:

需求分析和高水平的设计。
模拟系统的上下文,
逆向工程。
Forward engineering.

通信图

交互图

UML 交互图包括两种：序列图和协作图。

时序图
协作图

UML 2.0

时间图

3. 项目管理

mindmap
  root((项目管理))
    1.盈亏平衡分析
    2.进度管理
        2.1 工作分解WBS
        2.2 进度管理
    3.软件配置管理
    4.软件质量管理
        4.1 质量保证的主要目标
        4.2 软件能力成熟度模型集成CMMI

工作分解WBS

基本要求：

WBS的工作包是可控和可管理的，不能过于复杂
任务分解不能过细，一般原则WBS的属性结构不超过6层
每个工作包都要有一个交付成果
每个任务必须有明确定义的完成标准
WBS必须有利于责任分配

项目时间管理

进度管理：是为了确保项目按期完成所需要的管理过程。主要包括：

活动定义
活动排序
活动资源估算
活动历时估算
指定进度计划
进度控制

活动定义的常用工具包括: 1:分解采用分解技术来定义活动，就是要把项目工作包分解成更小的、更易于管理的组成部分，即活动–为完成工作包而必须开展的工作。定义活动过程最终输出的是活动，而非可交付成果。可交付成果是创建工作分解结构过程的输H。 WBS、WBS 词典与活动清单，既可依次编制，也可同时编制。WBS和WBS 词典是制定最终活动清单的依据。WBS 中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。让团队成员参与分解，有助于得到更好、更准确的结果。 2.滚动式规划滚动式规划是一种渐进明细的规划方式，即对近期要完成的工作进行详细规划，而对远期工作则暂时只在WBS 的较高层次上进行粗略规划。因此，在项目生命周期的不同阶段，工作分解的详细程度会有所不同。例如，在早期的战略规划阶段，信息尚不够明确，工作包也许只能分解到里程碑的水平;而后，随着了解到更多的信息，近期即将实施的工作包就可以分解成具体的活动。 3.模板标准活动清单或以往项目的部分活动清单，经常可用作新项目的模板。模板中的活动属性信息，也有助于定义活动。模板还可用来识别典型的进度里程碑。 4，专家判断富有经验并擅长制定详细项目范围说明书、工作分解结构和项目进度计划的项目团队成员或其他专家，可以为定义活动提供专业知识。

软件配置管理

配置管理是通过技术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。信息系统开发过程中的变更以及相应的返工会对产品的质量有很大的影向。产品配置是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项(Configuration ltem，Cl)，配置项主要有两大类:

属于产品组成部分的工作成果，如需求文档、设计文档、源代码、测试用例等。
属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。

软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的; 系统文档描述系统设计、实现和测试等各方面的内容。

配置项

基线配置项: 需求文档、设计文档、源代码、可执行代码测试用例、运行软件所需的数据等
非基线配置项：各类计划（项目管理计划、进度管理计划）、各类报告
配置项状态：草稿、正式发布、正在修改

版本控制

软件工具

软件开发工具
软件维护工具
软件管理和软件支持工具

软件质量管理

质量控制是实时控制项目的具体结果，以判断他们是否符合相关质量标准，指定有效方案，以消除产生质量问题的原因。 质量保证一般是每隔一定时间进行的，主要通过系统的质量审计和过程分析来保证的质量。独特工具包括：质量审计的过程分析。

质量保证的主要目标

事前预防工作
尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一阶段
作用于过程而不是最终产品
贯穿于所有活动之中，而不是只集中于一点。

软件质量属性 (质量效用树)

“用变互修，全靠性能”

flowchart LR
    A[软件质量属性] --> B(可用性)
    A --> C(可变性)
    A --> D(互操作性)
    A --> E(可修改性)
    A --> F(安全性)
    A --> G(可靠性)
    A --> H(性能)
    A --> I(功能性)
    G --> J(容错性)
    G --> K(健壮性)
    E --> L(可维护性)
    E --> M(可扩展性)
    E --> N(结构重构)
    E --> O(可移植性)

质量属性场景中，使用六元素来描述题目中可用性的两个场景。

六元素:

刺激源:某个生成该刺激的实体(人，计算机，其它任何刺激器)
刺激:指当刺激达到系统时需要考虑的条件;
环境：指该刺激在某些条件哪发生;
制品:某个制品被激励，可能是整个系统，也可能是系统的一部分；
响应:指在激励达到后所采取的行动:
响应度量:当响应发生时，应当能够以某种方式对其进行度量。

软件能力成熟度模型集成CMMI

初始级L1：随意且混乱，组织成功依赖于个人能力
已管理级L2: 项目级可重复 –》建立了项目级的控制过程
已定义级L3：组织级，文档化标准化
定量管理级L4：量化式管理-》过程性能可预测
优化级L5：持续优化

信息隐藏

信息隐藏是提高可修改性的典型设计策略,又因为信息隐藏可以有一定保密作用,所以也可以提高安全性。不过信息隐蔽从一定程度上说可以提升安全性,但是相对提升可修改性、可测试性和可移植性来说没有那么显著,

信息隐蔽是开发整体程序结构时使用的法则,即将每个程序的成分隐蔽或封装在一个单一的设计模块中,并且尽可能少地暴露其内部的处理过程。通常会将困难的决策、可能修改的决策、数据结构的内部连接,以及对它们所做的操作细节、内部特征码、与计算机硬件有关的细节等隐蔽起来。通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性,它也是现代软件设计的一个关键性原则。常考质量属性及相应设计策略如下:

性能性能(performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。
- 代表参数:响应时间、吞吐量
- 设计策略:优先级队列、资源调度、引入并发、维持数据或计算的多个副本、增加可用资源、控制采样频度、限制执行时间、固定优先级调度等。
可用性可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系統能够恢复正常的速度来表示。
- 代表参数:故障间隔时间
- 设计策略:冗余、心跳线、命令/响应机制、心跳机制、异常处理机制、冗余机制等。
安全性安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
- 设计策略:追踪审计、身份认证、限制访问、检测攻击、维护完整性等
可修改性可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考察这些变更的代价衡量可修改性。
- 主要策略:信息隐藏
可靠性可靠性(reliability)是软件系统在应用或系統错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面:容错、健壮性。
- 代表参数:MTTF、MTBF
- 设计策略:冗余、心跳线

可修改性

可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考查这些变更的代价衡量可修改性。可修改性包含四个方面。

可维护性(maintainability)。这主要体现在问题的修复上:在错误发生后“修复“软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
可扩展性(extendibility)。这一点关注的是使用新特性来扩展软件系统,以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性,软件系统需要松散耦合的构件。其目标是实现一种体系结构,它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
结构重构(reassemble)。这一点处理的是重新组织软件系统的构件及构件间的关系,例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组,软件系统需要精心设计构件之间的关系。理想情况下,它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
可移植性(portability)。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植,需要按照硬件无关的方式组织软件系统,其他软件系统和环境被提取出。可移植性是系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件,也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时,系统是可移植的。如果移植到新的系统需要做些更改,则可移植性就是一种特殊的可修改性。

架构权衡 (Architecture Tradeoff Analysis Method)

架构权衡分析方法是一种系统架构评估方法,主要在系统开发之前,针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。

ATAM可以分为4个主要的活动阶段,包括需求收集、架构视图描述、属性模型构造和分析、架构决策与折中,整个评估过程强调以属性作为架构评估的核心概念。某软件公司采用ATAM进行软件架构评估,在评估过程中识别出了多个关于质量属性的描述。其中,系統在进行文件保存操作时,应该与Windows系统的操作方式保持一致。这是一种减轻用户记忆负担,降低学习成本的做法,这有利于提高系统的易用性。“系统应该提供一个开放的API接口,支持远程对系统的行为进行控制与调试”,在此处,我们注意到描述的核心落在“支持远程对系统的行为进行控制与调试”上了,而调试是在测试之后精确定位系统错误的一种机制,所以这种做法有利于提高系统的可测试性。在识别出上述描述后,通常采用效用树对质量属性的描述进行刻画与排序。在评估过程中,权衡点是一个会影响多个质量属性的架构设计决策。

ATAM是软件体系结构评估中的一种方法，主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计实现和测试之前的阶段工作，因此评估不涉及系统的实现代码和测试，因为评估是考查软件体系结构是否能够合适地解决软件系统的需求，并不对软件需求自身是否准确进行核实，而软件需求是否准确是需求评审阶段的工作。 ATAM并不是一种精确的评估方法，该方法表现的主要形式是评审会议。

成本预算

在项目的成本管理中，成本预算是将总的成本估算分配到各项活动和工作包上的过程，以此来建立一个成本的基线。成本预算是成本管理的一个关键步骤，它涉及将项目的总体成本估算细分为各个工作包或活动的成本估算，为项目的成本控制提供了基准。

配置管理是PMBOK、ISO9000和CMMI中的重要组成元素，它在产品开发的生命周期中，提供了结构化的、有序化的、产品化的管理方法，是项目管理的基础工作。

产品配置

用户文档

用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象。用户文档至少应该包括下述5方面的内容:

(1)功能描述:说明系统能做什么;
(2)安装文档:说明怎样安装这个系统以及怎样使系统适应特定的硬件配置;
(3)使用手册:简要说明如何着手使用这个系统(通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误时怎样恢复和重新启动);
(4)参考手册:详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术);
(5)操作员指南(如果需要有系统操作员的话):说明操作员应如何处理使用中出现的各种情况。系统文档所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

变更控制

变更控制委员会可以由一个小组担任，也可以由多个不同的组担任。变更控制委员会的成员应能代表变更涉及的团体。变更控制委员会可能包括如下方面的代表: (1)产品或计划管理部门; (2)项目管理部门; (3)开发部门; (4)测试或质量保证部门; (5)市场部或客户代表; (6)制作用户文档的部门; (7)技术支持部门; (8)帮助桌面或用户支持热线部门; (9)配置管理部门。

4.1 软件架构设计[Main]

mindmap
  root((软件架构设计))
    1.软件架构概念
    2.软件架构风格
        2.1 数据流风格
        2.2 调用/返回风格
        2.3 独立构件风格
        2.4 虚拟机风格
        2.5 仓库风格
        2.6 过程控制架构
        2.7 C2风格
    3.基于架构的开发方法ABSD
    4.软件架构评估
    5.特定领域软件架构
    6.构件与中间件技术
    7.软件产品线

软件架构概念

架构的本质

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

软件架构设计主要关注软件组件的结构，属性和交互作用。结构指的是组件之间的组织方式，属性定义了组件的特性和行为，而交互作用则是指组件之间如何相互作用以完成系统的整体功能。

从本质上看，需求和软件架构设计面临的是不同的对象:一个是问题空间;另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。从软件需求模型向SA模型的转换主要关注两个问题:
如何根据需求模型构建软件架构模型
如何保证模型转换的可追踪性。

架构的作用
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系
软件系统架构是关于软件系统的结构、行为和属性的高级抽象。在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件之间的交互关系。在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定了软件系统的组织结构和拓扑结构，而且显示了系统需求和构成组件之间的对应关系，包括设计决策的基本方法和基本原理
架构所处的位置
- 软件架构=软件体系结构
- 架构设计就是需求分配，即将满足需求的职责分配到组件上。
- 软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个选代的过程，在建立软件架构的初期，一般需要选择一个合适的架构风格，并将架构分析阶段已标识的构件映射到架构中，并分析这些构件之间的关系，一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审。一般来说，软件架构设计活动将已标识构件集成到软件架构中，设计这些构件，但不予以实现。
- 软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域;设计阶段主要将需求转换为软件架构模型;软件实现阶段主要关注将架构设计转换为实际的代码;软件部署阶段主要通过组装软件组件提高系统的实现效率，其中设计与实现阶段在软件架构上的工作最多，也最重要因此关注力度最大。
架构发展历程
- 无架构阶段-汇编语言
- 萌芽阶段-程序结构设计
- 初级阶段-统一建模语言
- 高级阶段-4+1视图
  1. 逻辑视图：关注系统的功能性需求；描述系统的功能如何被软件的各个模块和组件实现，通常使用类图，包图表示；逻辑视图帮助开发者理解系统的业务功能和各部分之间的关系。
  2. 开发视图，也称实现视图，描述了软件模块的组织与管理
  3. 进程视图，描述系统的动态方面，如并发和同步机制，关注系统如何运行，使用活动图或者顺序图来表示。
  4. 物理视图，描述软件部件如何映射到硬件上，常用部署图来表示。
  5. 场景，用来展示系统的具体用例或者用户故事，通过用例图和序列图来描述用户如何与系统交互。
架构描述语言ADL
ADL即架构描述语言，其基本构成要素包括:组件、组件接口、连接件、架构配置。组件(构件)是一个计算单元或数据存储。也就是说，组件是计算与状态存在的场所。
- 是一种形式化语言
- 有三个基本元素
  1. 构件：计算或数据存储单元, 一个构件可能小到只有一个过程或大到整个应用程序
  2. 连接件：用于构件之间交互建模的体系结构构造块及其支配只写交互的规则
  3. 架构配置：描述体系结构的构件与连接件的连接图。

软件架构风格

数据流风格
- 1.1 批处理：大量整体数据、无需用户交互
- 1.2 管道过滤器：流式数据、弱用户交互
  管道过滤器风格的完整流程为：「读端口」获取需要处理的信息，通过管道传递给过滤器链，每个过滤器自行判断是否需要对信息进行处理，一个过滤器处理完后通过管道将消息传递给下一个或多个过滤器，直到所有的过滤器全部处理完毕，通过「写端口」，将处理完成的信息写出到目标位置。而传统编译器（包括词法分析、语法分析、语义分析和代码生成）一个阶段的输出是另一个阶段的输入，符合管道过滤器风格的特点。
调用/返回风格
- 2.1 主程序/子程序：面向过程
- 2.2 面向对象：对象方法的调用
- 2.3 分层架构：层与层之间的方法调用，可扩展性好，对层次结构抽象要求高
  e.g. 物联网系统
独立构件风格
- 3.1 进程通信：
- 3.2 隐式调用：
  推荐系统
虚拟机风格
- 4.1 解释器：
  在运行时，能提供系统行为定义与改变的能力
- 4.2 规则系统
  规则系统比较适合根据外部事件，以自身状态为基础自动进行处理和动作的场景
仓库风格
过程控制架构
适合嵌入式系统，用于解决简单闭环控制问题其特点是，不断采集系统当前状态，并与系统中的设定状态进行比对，通过对比进行控制
C2风格
以数据为中心
现代编译器的集成开发环境一般采用数据仓储(即以数据为中心的架构风格)架构风格进行开发，其中心数据就是程序的语法树。

基于架构的开发方法ABSD

参考信息系统-信息系统开发方法-其他方法-基于架构的开发方法ABSD

基于软件架构的设计ABSD强调由商业、质量和功能需求的组合来驱动软件架构设计。他强调采用视角和视图来描述软件架构，采用用例和 质量属性场景 来描述需求。进一步来说，用例描述的功能需求，质量属性场景描述的事质量需求（侧重于非功能需求）

ABSD方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

基于架构的软件设计ABSD方法有三个基础，分别是对系统进行功能分解、采用架构风格实现质量属性与商业需求、采用软件模板设计软件结构。

ABSD把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。

绝大部分的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员都实现架构，还必须得把架构进行文档化。

文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计所预先分析的基础。

架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。

软件架构文档是对软件架构的一种描述,帮助程序员使用特定的程序设计语言实现软件架构。软件架构文档的写作应该遵循一定的原则,这些原则包括:文档要从使用者的角度进行编写;必须分发给所有与系统有关的开发人员;应该保持架构文档的即时更新,但更新不要过于频繁;架构文档中描述应该尽量避免不必要的重复;每次架构文档修改都应该记录进行修改的原则。

生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。

以架构为核心的软件系统开发方法。在该方法中，架构用来激发和调整设计策略，不同的视图用来表达与质量目标有关的信息。架构设计是一个选代过程，在建立软件架构的初期，选择一个合适的架构风格是首要的，在此基础上，开发人员通过架构模型，可以获得关于软件架构属性的理解，为将来的架构实现与演化过程建立了目标。

软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件二步。软件架构需求并不应该包括设计构件的过程

体系结构需求:需求过程主要是获取用户需求,标识系统中所要用到的构件。体系结构设计:体系结构设计是一个迭代过程,如果要开发的系统能够从已有的系统中导出大部分,则可以使用已有系统的设计过程。体系结构文档化:绝大多数的体系结构都是抽象的,由一些概念上的构件组成,因此要去实现体系结构,还必须得把体系结构文档化。体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这2个文档。体系结构复审:体系结构设计、文档化和复审是一个迭代过程。复审的目的是表示潜在的风险,及早发现体系结构设计中的缺陷和错误,包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件划分是否合理、文档表达是否明确、构件设计是否满足功能与性能的要求等。体系结构实现:所谓“实现”就是要用实体显示出一个软件体系结构,即要符合体系结构描述的结构性设计决策,分割成规定的构件,按规定的方式互相交互。整个实现过程是以复审后的文档化的体系结构说明书为基础的,每个构件必须满足软件体系结构中说明的对其他构件的责任。最后一步是测试,包括单个构件的功能性测试和被组装应用的整体功能和性能测试。体系结构演化:在构件开发过程中,用户的需求可能还有变动。在软件开发完毕,正常运行后,由一个单位移植到另一个单位,需求也会发生变化。在这两种情况下,就必须相应地修改软件体系结构,以适应新的变化了的软件需求。体系结构演化是使用系统演化步骤去修改应用,以满足新的需求。

在考虑软件架构时，重要的时从不同的视角（perspective）来检查，这促使软件设计师考虑架构的不同属性。
例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。选择的特定视角或视图也就是逻辑视图，进程视图，实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统的角色，这些角色包括功能，性能等。（配置视图=物理视图=部署视图 其实是同一个东西在不同时期的叫法）例如:展示功能组织的静态视角能判断质量特性,展示并发行为的动态视角能判断系统行为特性。在ABSD(基于架构的软件设计)方法中,使用不同的视角来观察设计元素,一个子系统并不总是一个静态的架构元素,而是可以从动态和静态视角观察的架构元素。将选择的特定视角或视图与Kruchten提出的类似,也就是逻辑视图、进程视图、实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口,设计元素的功能定义了它本身在系统中的角色,这些角色包括功能性能等。进程视图也称为并发视图,使用并发视图来检查系统多用户的并发行为。使用“并发“来代替“进程”,是为了强调没有对进程或线程进行任何操作,一旦执行这些操作,则并发视图就演化为进程视图。使用的最后一个视图是配置视图,配置视图代表了计算机网络中的节点,也就是系统的物理结构。

架构复审

架构复审一词来自于ABSD。在ABSD中,架构设计、文档化和复审是一个迭代过程。从这个方面来说,在一个主版本的软件架构分析之后,要安排一次由外部人员(用户代表和领域专家)参加的复审。复审的目的是标识潜在的风险,及早发现架构设计中的缺陷和错误,包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等等。由外部人员进行复审的目的是保证架构的设计能够公正地进行检验,使组织的管理者能够决定正式实现架构。

在架构神父过程中，主要有用户代表和领域专家决定架构是否满足需求、质量需求是否在设计中得到体现。

软件建构评估

软件质量属性
asdasdas
1. 性能
2. 可靠性
3. 可用性：系统能够正常运行的时间比例
4. 安全性：系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或者拒绝服务的能力
  - 4.1. 机密性
  - 4.2. 完整性
  - 4.3. 不可否认性
  - 4.4. 可控性
5. 可修改性：能够快速地以较高的性价比对系统进行变更的能力
6. 功能性
7. 可变性
8. 互操作性
敏感点权衡点风险点与非风险点
架构评估方法
asdasdsad
1. 场景评估方法
2. 基于场景的评估方法
  - 2.1 软件架构分析法SAAM：最初关注可修改性，后扩充到可移植性、可扩展性等
  - 2.2 架构权衡分析法ATAM：从SAAM发展而来，主要针对：性能、实用性、安全性和可修改性
  - 2.3 成本效益分析法CBAM: 在ATAM基础上建立的，软件的“经济”模型

架构标准 ANSI/IEEE 1471-2000

ANSI/IEEE 1471-2000是描述软件架构的第一个标准，其中要素的关系如下: 第一层:mission 第二层:Environment.System,Architecture 第二层:StakeholderArchitectural Description.Rationale 第四层:Concem,Viewpoint.View 第五层:Library Viewpoint,Model

Mission: 任务，使命。也就是为什么我们要做这个系统。可能的原因是为了更大的赢利，市场占有率更高，完善产品系列等等。
System: 系统。具体的定义是:一系列组件，组织在一起，相互作用从而完成一个或者一些特殊的功能。
Model: 模型。就是用来表达视图的方法。直白地说，就是系统中各种元素是如何组织在一起发挥作用。用图形化的表示把看到的东西表达出来。
Architecture: 系统架构。每个系统有一个架构。是对所有利益相关人的关注点(Concern)的响应和回答，通过架构描述(Architecture Description)来说明。

在ANSIIEEE 1471-2000标准中，系统是为了达成利益相关人(Stakeholder)的某些使命(Mission)，在特定环境(Enviroment)中构建的。每一个系统都有一个架构(Architecture)。架构(Architecture)是对所有利益相关人的关注点(Concem)的响应和回答，通过架构描述(Architecture Descrintion)来说明，每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。架构描述(Architecture Description)本质上是多视图的。每一个视图(View)是从一个特定的视角(Viewpoint)来表述架构的某一个独立的方面。试图用一个单一的视图来夏盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角(Viewpoint)的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图(View)包括一个或者多个架构模型(Model)，一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。

ANSIIEEE 1471-2000是对软件密集型系统的架构进行描述的标准。在该标准中，视图这一概念主要用于描述软件架构模型。在此基础上，通常采用视角描述基个利益相关人(Siakenolder)所关注架构模型的某一方面。架构则是对所有利益相关人关注点的响应和回答。

4.2 软件架构设计[Rest]

mindmap
  root((软件架构设计))
    1.软件架构概念
    2.软件架构风格
    3.基于架构的开发方法
    4.软件架构评估
    5.特定领域软件架构
    6.构件与中间件技术
        6.1 软件复用
        6.2 构件复用
        6.3 构件概念
        6.4 中间件
        6.5 构件标准
    7.软件产品线

特定领域软件架构

构件与中间件技术

软件复用

软件复用是多次不同的软件开发过程中重复使用的相同或者相似软件元素的过程
Details
软件元素指：需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识

水平复用（横向）：不分行业领域，通用；指在不同的应用领域或系统之间对通用软件元素（如数据结构、算法、人机界面组件等）的重用。它强调跨领域的广泛适用性，常用于工具类库或框架的设计。
垂直复用（纵向）：分行业领域，专用；指在相同或相似的应用领域中对特定功能或模块的重用。它强调在特定领域内深度挖掘和复用，如垂直行业解决方案。

构件复用

构件组装的三种方式

1. 基于功能的组装
1. 基于数据的组装
1. 面向对象的组装

资产复用

在软件开发中，可复用资产的生命周期通常包括几个关键步骤，这些步骤确保资产可以被有效地创建、管理和使用。

1. 分析可复用资产：确定哪些资产可以被复用，以及它们在不同项目中的潜在用途。
过程：分析现有的代码、组件、设计模式等，评估它们的通用性和可复用性。这一步是基础，因为只有了解了资产的特性和适用范围，才能决定如何构造和使用它们。
1. 构造/获取可复用资产：创建或获取符合复用标准的资产。
过程：根据分析结果，开发新的可复用组件或模块，或者从外部获取已经存在的可复用资产。这一步需要考虑资产的设计质量、接口一致性等因素，以确保它们能够被方便地集成到不同的项目中。
1. 管理可复用资产：维护和更新可复用资产，确保它们的质量和适用性。
过程：建立资产库，对资产进行分类、存储和版本控制。定期检查资产的使用情况和反馈，进行必要的维护和改进。有效的管理有助于提高资产的可用性和可靠性，使其能够长期为开发团队服务。
1. 使用可复用资产：在实际项目中应用可复用资产，提高开发效率和产品质量。
过程：根据项目需求，从资产库中选择合适的资产进行集成和使用。在使用过程中，记录资产的表现和问题，为后续的管理提供反馈。这一步是实现资产价值的关键环节，通过复用可以减少重复开发工作，加快项目进度。

架构复用

软件架构复用的类型包括机会复用和系统复用。

机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。
系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

构件

构件是一组通常需要同时部署的原子构件。

构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独部署。一个模块是不带单独资源的原子构件（在这个严格定义下，Java 包不是模块–在 Java 中部署的原子单元是类文件。一个单独的包被编译成多个单独的类文件–每个公共类都有一个）。模块是一组类和可能的非面向对象的结构体，比如过程或者函数。

构件与对象的区别：构件的特性是:(1) 独立部署单元; (2) 作为第三方的组装单元;(3)没有(外部的)可见状态。一个构件可以包含多个类元素,但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。对象的特性是:(1) 一个实例单元,具有唯一的标志。(2)可能具有状态,此状态外部可见。 (3)封装了自己的状态和行为。

在构件组装过程中需要检测并解决架构失配问题。其中构件失配主要包括由于系统对构件基础设施、控制模型和数据模型的假设存在冲突引起的失配。 连接子 失配包括由于系统对构件交互协议、构件连接时数据格式的假设存在冲突引起的失配。

软件架构设计主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

中间件

中间件是一类构件
中间件是一类系统软件

软件产品线

构件标准

CORBA
1. CORBA构件模型中，对象适配器（Object Adapter）的主要作用是在底层传输平台与接收调用并返回结果的对象实现之间进行协调，目前采用的对象适配器规范是POA（可移植对象适配器），它替代了传统的BOA（基本对象适配器 Basic Object Adapter）。POA是对象实现与ORB其它组件之间的中介，它将客户请求传送到伺服对象，按需创建子POA，提供管理伺服对象的策略。
2. CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的，是因为并没有硬性规定CORBA对象的实现机制。
3. 一个CORBA对象的引用又称可互操作的对象引用（Interoperable Object Reference）。从客户程序的角度看，IOR中包含了对象的标识、接口类型及其他信息以查找对象实现。
4. 伺服对象（servant）是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。
5. 在一个CORBA对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。对象标识（Object ID）是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一性。
6. 对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
7. 对象管理组织(OMG)基于CORBA基础设施定义了四种构件标准。实体(Entity)构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。加工(Process)构件同样需要容器管理其持久化，但没有客户端可访问的主键。会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。服务(Service)构件是无状态的。
8. POA是对象实现与ORB其他组件之间的中介,它将客户请求传送到伺服对象,按需创建子POA,提供管理伺服对象的策略。CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的,是因为并没有硬性规定CORBA对象的实现机制。由于独立于程序设计语言和特定ORB产品,一个CORBA对象的引用又称可互操作的对象引用(Interoperable Object Reference)。从客户程序的角度看,IOR中包含了对象的标识、接口类型及其他信息以查找对象实现。伺服对象(Servant)是指具体程序设计语言的对象或实体,通常存在于一个服务程序进程之中。客户程序通过对象引用发出的请求经过ORB担当中介角色,转换为对特定的伺服对象的调用。在一个CORBA对象的生命期中,它可能与多个伺服对象相关联,因而对该对象的请求可能被发送到不同的伺服对象。对象标识(Object ID) 是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派,也可由对象适配器自动分配,这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一性。
J2EE
DNA 2000

软件产品线

前趋图

PV操作

公共数据单元Tj是一个临界资源，最多允许1个终端进程使用，因此需要设置一个互斥信号量S，初值等于1。

面向构件编程COP

面向构件的编程需要下列基本的支持：

多态性（可替代性）；
模块封装性（高层次信息的隐藏）；
后期的绑定和装载（部署独立性）；
安全性（类型和模块安全性）。

C/S架构

三层C/S体系结构是将应用功能分成表示层、功能层和数据层三个部分，

表示层表示层是应用的用户接口部分担负与应用逻辑间的对话功能。它用于用户从工作站输入的数据，并显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户界面(GUI)，在变更用户界面时，只需改写显示控制和数据检查程序，而不影响业务逻辑。
功能层功能层是应用的本体，它负责具体的业务处理逻辑，例如在制作订购合同时要计算合同金额。表示层和功能层之间的数据互交要尽可能简洁。例如，用户检索数据时，要将有关检索要求的信息一次性地传送给功能层，检索结果数据也由功能层一次性地传送给表示层。
数据层数据层通常是数据库管理系统，负麦管理对数据库数据的读写。数据库系统必须能迅速执行大量数据的更新和检来。三层C/S的解决方案对这三层进行明确分割，不同层构件相互独立，层间的接口简洁，适合复杂事务处理

5. 系统可靠性分析与设计

mindmap
  root((系统可靠性分析与设计))
    1.可靠性相关基本概念
        1.1 可靠性与可用性区别
        1.2 可靠性指标
    2.系统可靠性分析
    3.软件可靠性设计

可靠性与可用性区别

可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
可用性是系统能够正常运行的时间比例。

可靠性指标

平均无故障时间
平均故障修复时间
平均故障间隔时间
系统可用性

系统可靠性分析

软件可靠性设计技术

1. N版本程序设计

2. 恢复块设计

3. 防卫式程序设计

6. 信息安全技术基础

mindmap
  root((信息安全技术基础))
    1.信息安全基础
    2.信息加解密技术
    3.访问控制及数字签名技术
    4.信息安全的保障体系
    5.秘钥管理技术

信息安全基础

5个基本要素
安全漏洞
1. 物理安全性
2. 软件安全漏洞
3. 不兼容使用安全漏洞
4. 选择合适的安全哲理
网络完全威胁
1. 非授权访问
2. 信息泄露或丢失
3. 破坏诗句完整性
4. 拒绝服务攻击
5. 利用网络传播病毒
安全措施的目标
1. 访问控制
2. 认证
3. 完整性
4. 审计
5. 保密

信息加解密技术

访问控制及数字签名技术

访问控制技术
- 访问控制的基本模型
- 访问控制实现技术
  1. 矩阵
  2. 访问控制列表
数字签名技术
- 信息摘要
  - 单向散列函数，不可逆，可以防止篡改，固定长度的散列值
  - 常用算法MD5,SHA等；SHA因为秘钥长度较长，所以安全性更高，但是速度更慢
- 数字签名过程分析
  - 加密：接收方公钥加密 –》接收方私钥解密
  - 签名：发送方私钥加密 –》发送方公钥解密

信息安全的保障体系

计算机信息系统安全保护等级包括：

用户自主保护级
系统审计保护级
安全标记保护级
架构华保护级
访问验证保护级

军用不对外公开的信息系统的安全等级至少应该属于三级及三级以上

7. 安全架构设计

mindmap
  root((安全架构设计理论与实践))
    1.安全架构概述
        1.1 信息安全锁面临的威胁
        1.2 被动攻击与主动攻击
    2.安全模型
        2.1 BLP模型
        2.2 Biba模型
        2.3 Chinese Wall模型
        2.4 WPDRRC模型
    3.网络安全体系架构设计
        3.1 开放系统互联安全体系结构
        3.2 安全服务于安全机制的对应关系
        3.3 安全框架
    4.区块链技术
    5.特定领域软件架构
    6.构件与中间件技术
    7.软件产品线

安全架构概述

安全模型

BLP模型 -》机密性模型：下读上写
- 简单安全规则：安全级别低的主体不能读安全级别高的客体
- 星属性安全规则：安全级别高的主体不能往级别低的客体写
- 强星属性安全规则：不允许对另一级别进行读写
- 自主安全规则：使用访问控制矩阵来定义说明自由存取控制
Biba模型 -》完整性模型：上读下写
- 星完整性规则：安全级别低的主体不能写安全级别高的客体
- 简单完整性规则：安全级别高的主体不能从级别低的客体读数据
- 调用属性规则：一个完整性级别低的主题不能从级别高的客体调用程序或服务
Chinese Wall模型
- 与主题曾经访问过的信息属于同一个公司集合的信息
WPDRRC模型（Warn, Protect, Detect, Response, Restore, Control）
包括6个环节和3大要素
- 6个环节：预警、保护、检测、相应、恢复和反击
- 3大要素：人员、策略和技术

网络安全体系架构设计

开放系统互联安全体系结构
安全服务于安全机制的对应关系
安全框架
- 认证框架：防止其他实体占用和独立操作被鉴别实体的身份
- 访问控制框架：访问控制决定开发系统环境中允许使用那些资源，在什么地方适合组织未授权访问的过程
- 机密性框架：确保信息仅仅是对被授权者可用
- 完整性框架：通过组织威胁或探测威胁，保护可能遭到不同方式危害的数据完整性和数据相关属性完整性
- 抗抵赖框架：抗抵赖服务包括证据的生成，验证和记录，以及在解决纠纷是随机进行的证据恢复和再次验证。

区块链技术

8. 计算机系统基础知识

mindmap
  root((计算机系统基础知识))
    1.计算机系统概述
        1.1 流水线
    2.存储系统
        2.1 层次化存储结构
        2.2 Cache
        2.3 磁盘管理
    3.操作系统
        3.1 操作系统概述
        3.2 进程管理
        3.3 存储管理
        3.4 文件管理
    4.系统性能
        4.1 性能指标
        4.2 性能调整
        4.3 性能评价方法
        4.4 Web服务器性能测试                                                                                                                                                                                                                      
        4.5 系统监视

计算机系统概述

流水线流水线是指在程序执行时多条指令重叠进行操作的一种准并行处理实现技术。各种部件同时处理是针对不同指令而言的，它们可同时为多条指令的不同部分进行工作，以提高各部件的利用率和指令的平均执行速度

flowchart LR
    A[取指] --> B(分析)
    B --> C[执行]

流水线周期 △t = Max（T_取指,T_分析,T_执行)

流水线执行时间公式 SUM（T_取指,T_分析,T_执行）+ （n - 1） △t*

流水线吞吐率

存储系统

层次化存储结构计算机采用分级存储提起的主要目的是为了解决存储的容量、价格和速度之间的矛盾
Cache
- 高速缓存器Cache是对程序员透明的
- Cache的设计思想是在合理的成本下提高命中率
磁盘管理
- 磁盘概念
- 磁盘移臂调度算法
  - 先来先服务FCFS
  - 最短寻道时间优先
  - 扫描算法
  - 循环扫描算法
虚拟存储器 (Virtual Memory)
虚拟存储器是在具有层次结构存储器的计算机系统中，自动实现部分装入和部分替换功能，能从逻辑上为用户提供一个比物理贮存容量大得多、可寻址的“主存储器”。
- 虚拟存储区的容量与物理主存大小无关,而受限于计算机的地址结构和可用磁盘容量。
- 其页面的置换依据相应的页面置换算法进行，当页面失效时，要进行数据交换，此时涉及逻辑地址(虚地址)到辅存物理地址的变换

操作系统

操作系统是管理计算机硬件与软件资源的程序，同时也是硬件与用户之间的接口。
操作系统既提供了与用户交互的接口，也提供了与应用程序交互的接口。
用户可以通过菜单、命令、窗口与操作系统进行交互，而应用程序可以通过系统调用(如调用系统API)来与操作系统交互。

功能主要包括：

进程管理
- 进程与线程的基本概念
- 进程的状态
- 信号量与PV操作
  - P 操作：申请资源
  - V 操作：释放资源
- 前趋图
- 死锁
  - 死锁的预防 -》打破四大条件 -》互斥、占有且等待、不可抢占、循环等待
  - 死锁的算法 -》
    - 有序分配资源法
    - 银行家算法
      - 分配资源的原则：
        当一个进程对资源的最大需求量不超过系统中资源数时可以接纳该进程
        进程可以分期请求资源，但请求的总数不能超过最大需求量
        当系统现有资源不能满足进程还需要的资源数时，对进程的请求可以推迟分配，但总能使进程在有限的时间里获得资源
存储管理
- 页式存储
- 段式存储
- 段页式存储
文件管理
- 索引文件结构
- 位示图
作业管理
设备管理

系统性能

硬件指标
软件指标
性能调整
Amdahl’s law
性能评价方法
- 把应用程序中应用最频繁的那部分核心程序作为评价计算机性能的标准程序，称为核心)基准测试程序
Web服务器测试
- 在Web服务器测试时，反映其性能的指标包括：最大并发连接数、响应延迟 和 吞吐量
- 常见的Web服务器性能测试方法有 基准性能测试、压力测试 和 可靠性测试
系统监视
进行系统监视通畅有3种方式
1. 通过系统本身提供的命令
2. 通过系统记录文件查阅系统在特定时间内的运行状态
3. 使用集成了命令、文件记录和可视化的监控工具

RISC

RISC特点：

使用等长指令，目前典型长度为4个字节寻址方式少且简单，一般为2-3种；
绝不出现存储器间接寻址方式只有取数指令、存数指令访问存储器指令集中的指令数目一般少于100种，指令格式一般少于4种指令功能简单；
控制器多采用硬布线方式，以期更快的执行速度平均而言，所有的指令的执行时间为一个处理时钟周期强调通用寄存器资源的优化使用

DSP （Digital Signal Processing）数字信号处理技术芯片

DSP芯片广泛应用于数字控制、运动控制方面的应用主要有磁盘驱动控制、引擎控制、激光打印机控制、喷绘机控制、马达控制、电力系统控制、机器人控制、高精度伺服系统控制、数控机床等。面向低功耗、手持设备、无线终端的应用主要有：手机、PDA、GPS、数传电台等。

编程DSP芯片是一种具有特殊结构的微处理器，为了达到快速进行数字信号处理的目的，DSP芯片一般都采用特殊的软硬件结构：

哈佛结构。DSP采用了哈佛结构，将存储器空间划分成两个，分别存储程序和数据。它们有两组总线连接到处理器核，允许同时对它们进行访问，每个存储器独立编址，独立访问。这种安排将处理器的数据吞吐率加倍，更重要的是同时为处理器核提供数据与指令。在这种布局下，DSP得以实现单周期的MAC指令。在哈佛结构中，由于程序和数据存储器在两个分开的空间中，因此取指和执行能完全重叠运行。
流水线。与哈佛结构相关，DSP芯片广泛采用2-6级流水线以减少指令执行时间，从而增强了处理器的处理能力。这可使指令执行能完全重叠，每个指令周期内，不同的指令都处于激活状态。
独立的硬件乘法器。在实现多媒体功能及数字信号处理的系统中，算法的实现和数字滤波都是计算密集型的应用。在这些场合，乘法运算是数字处理的重要组部分，是各种算法实现的基本元素之一。乘法的执行速度越快，DSP处理器的性能越高。相比与一般的处理器需要30-40个指令周期，DSP芯片的特征就是有一个专用的硬件乘法器，乘法可以在一个周期内完成。
特殊的DSP指令。DSP的另一特征是采用特殊的指令，专为数字信号处理中的一些常用算法优化。这些特殊指令为一些典型的数字处理提供加速，可以大幅提高处理器的执行效率。使一些高速系统的实时数据处理成为可能。
独立的DMA总线和控制器。有一组或多组独立的DMA总线，与CPU的程序、数据总线并行工作。在不影响CPU工作的条件下，DMA的速度已经达到800MB/S以上。这在需要大数据量进行交换的场合可以减小CPU的开销，提高数据的吞吐率。提高系统的并行执行能力。
多处理器接口。使多个处理器可以很方便的并行或串行工作以提高处理速度。
JTAG（Joint Test Action Group）标准测试接口（IEEE 1149标准接口）。便于对DSP作片上的在线仿真和多DSP条件下的调试。
快速的指令周期。哈佛结构，流水线操作，专用的硬件乘法器，特殊的DSP指令再加上集成电路的优化设计，可是DSP芯片的指令周期在10ns以下。快速的指令周期可以使DSP芯片能够实时实现许多DSP应用。

串行总线

关于串行总线的特点，总结如下：

串行总线有半双工、全双工之分，全双工是一条线发一条线收。
串行总线适宜长距离传输数据。
串行总线按位（bit）发送和接收。尽管比按字节（byte）的并行通信慢，但是串口可以在使用一根线发送数据的同时用另一根线接收数据。它很简单并且能够实现远距离通信。比如IEEE488定义并行通行状态时，规定设备线总长不得超过20米，并且任意两个设备间的长度不得超过2米；而对于串口而言，长度可达1200米。
串口通信最重要的参数是波特率、数据位、停止位和奇偶校验。对于两个进行通行的端口，这些参数必须匹配。串行总线的数据正确性依赖于校验和重传
串行总线的数据发送和接收可以使用多种方式，中断方式与DMA都较为常见。

存取方式

存储器中数据常用的存取方式有顺序存取、直接存取、随机存取和相联存取等4种。

顺序存取：存储器的数据以记录的形式进行组织。对数据的访问必须按特定的线性顺序进行。磁带存储器采用顺序存取的方式。
直接存取：与顺序存取相似，直接存取也使用一个共享的读写装置对所有的数据进行访问。但是，每个数据块都拥有唯一的地址标识，读写装置可以直接移动到目的数据块的所在位置进行访问。存取时间也是可变的。磁盘存储器ROM采用直接存取的方式。
随机存取：存储器的每一个可寻址单元都具有自己唯一的地址和读写装置，系统可以在相同的时间内对任意一个存储单元的数据进行访问，而与先前的访问序列无关。主存储器RAM采用随机存取的方式。
相联存取：相联存取也是一种随机存取的形式，但是选择某一单元进行读写是取决于其内容而不是其地址。与普通的随机存取方式一样，每个单元都有自己的读写装置，读写时间也是一个常数。使用相联存取方式，可以对所有的存储单元的特定位进行比较，选择符合条件的单元进行访问。为了提高地址映射的速度，Cache采取相联存取的方式。

CPU 中断

CPU利用中断方式完成数据的I/O。当I/O系统与外设交换数据时，CPU无需等待也不必去查询I/O的状态，当I/O系统完成了数据传输后则以中断信号通知CPU。然后CPU通过栈保存正在执行程序的现场，转入I/O中断服务程序完成与I/O系统的数据交换。再然后返回原主程序继续执行。与程序控制方式相比，中断方式因为CPU无需等待而提高了效率。

循环冗余校验

循环冗余校验(Cvcic Redundancy Check，CRC)是一种根据网络数据包或电脑文件等数据产生简短固定位数校验码的一种散列函数，主要用来检测或校验数据传输或者保存后可能出现的错误。它是利用除法及余数的原理来作错误侦测的。

若信息码字111000110，生成多项式

$$G(x)=x^5 + x^3 + x + 1$$

则计算出的CRC校验码为：11001

将生成多项式的系数作为除数(101011);
生成多项式的最高幂次数(5)作为检验码的位数。
将信息码左移生成多项式的最高幂次数(5)位，作为被除数。
执行模2除法，即异或操作。
等到(5位)余数即为校验码

9. 嵌入式系统

mindmap
  root((嵌入式系统))
    1.嵌入式系统概述
        1.1 基本概念
        1.2 初始化过程
        1.3 软件组成架构
    2.嵌入式软件开发
        2.1 与传统软件开发的区别
        2.2 在宿主机上开发
        2.3 功耗控制
    3. 嵌入式硬件
      3.1 发展历程
    4. 嵌入式数据库
    5. 嵌入式操作系统

嵌入式系统

嵌入式系统是以应用为中心，以计算机技术为基础，并将可配置与可裁剪的软件集成于一体的专用计算机系统，需要满足应用对功能、可靠性、成本、体积和功耗等方面的严格要求。
从计算机角度看，嵌入式系统是嵌入各种设备及应用产品内部的计算机系统。它主要完成信号控制的功能，体积小、结构紧凑，可作为一个部件埋藏在所控制的装置中。
一般嵌入式系统由嵌入式处理器、相关支撑硬件、嵌入式操作系统、支撑软件及应用软件组成

嵌入式系统初始化过程：
1. 片级初始化
2. 版级初始化
3. 系统级初始化
嵌入式系统软件组成架构
1. 嵌入式微处理器MCU
2. 存储器 RAM/ROM
3. 内外总线逻辑
4. 定时/计数器
5. 看门狗电路：定时器超时则中断，系统复位处理
6. I/O接口（串口、网络、USB、JTAG接口：用来进行CPU调试的常用接口）
7. 外部设备（LED等）
8. 其他部件

嵌入式软件开发

与传统软件开发的区别
在宿主机上开发
功耗控制
1. 软硬件协同设计，即软件的设计要与硬件匹配，考虑硬件因素
2. 编译优化，采用低功耗优化的编译技术。
3. 减少系统的持续运行时间，可以从算法角度进行优化。
4. 用“中断”代替查询。
5. 进行电源的有效管理

嵌入式硬件

发展历程
嵌入式微处理器
AI芯片通常，AI芯片的技术架构包括GPU、FPGA、ASIC三类。

GPU即显卡芯片，拥有成百上千个流处理器，适合做大规模的浮点数计算。多用于神经网络技术。
FPGA可对芯片硬件层进行编程和配置，实现半定制化，针对较为特定的AI场景。
ASIC是专用芯片，针对特定场景进行了深度的定制，特定的计算性能优化。

嵌入式微处理器体系结构
总线总线是一组能为多个部件分时共享的信息传送线，用来连接多个部件并为之提供信息交换的通路（通常为半双工的）特点：
1. 挂接在总线上的多个部件只能分时向总线发送数据，但可以同时从总线接受数据。
2. 通过总线复用方式可以减少总线中信号线的数量，以较少的信号线传输更多的信息。
3. 从功能上来说，总线进行划分数据总线、地址总线和控制总线
4. 从数据传输的方式划分并行总线和串行总线
串行总线vs并行总线
1. 并行总线：将数据字节的各位用多条数据线同时进行传送。（短距离）
2. 串行总线：数据是一位一位地进行传输的，在传输中每一位数据都战局一个固定的时间长度。（长距离，传输波特率可调整，正确性依赖于校验码，数据传输方式可以使用多种）

嵌入式操作系统

实时操作系统
系统调度算法
操作系统内核架构

嵌入式数据库 EDBMS

分类
嵌入式网络数据库

嵌入式系统的数据库系统称为嵌入式数据库系统或嵌入式实时数据库系统，就是在嵌入式设备上使用的DBMS。由于用到EDBMS的嵌入式系统多是移动信息设备，例如，掌上电脑、PDA、车载设备等移动通信设备，位置固定的嵌入式设备很少用到，因此，嵌入式数据库也称为移动数据库或嵌入式移动数据库。EDBMS的作用主要是解决移动计算环境下数据的管理问题，移动数据库是移动计算环境中的分布式数据库。嵌入式数据库管理系统一般只提供本机服务接口且只为前端应用提供基本的数据支持。

嵌入式数据库管理系统一般支持实时数据的管理
嵌入式数据库管理系统一般支持多线程并发操作
嵌入式数据库管理胸一般只提供本机服务接口
嵌入式数据库管理系统一般只为前端应用提供基本的数据支持

并串转化

一般来说，嵌入式系统通常采用接口中的移位寄存器来实现数据的串/并和并/串转换操作。

Soc片上系统

SoC称为片上系统，它是一个产品，是一个有专用目标的集成电路，其中包含完整系统，还有嵌入软件的全部内容。
SoC不是一块处理器芯片。它是一种技术，用以实现从确定系统功能开始，到软/硬件划分，并完成设计的整个过程。
从狭义角度讲，它是信息系统核心的芯片集成，是将系统关键部件集成在一块芯片上;
从广义角度讲，SoC是一个微小型系统，如果说中央处理器(CPU)是大脑，那么SoC就是包括大脑、心脏、眼晴和手的系统。
国内外学术界一般倾向将SoC定义为将微处理器、模拟IP核、数字IP核和存储器(或片外存储控制接口)集成在单一芯片上，它通常是客户定制的，或是面向特定用途的标准产品。

10. 计算机网络

mindmap
  root((计算机网络))
    1.计算机网络技术概述
        1.1 拓扑结构
        1.2 5G技术
    2.组网技术
        2.1 OSI7层模型
        2.2 交换机
        2.3 磁盘管理
    3. 网络规划与设计
        3.1 网络冗余设计
        3.2 网络规划与设计
        3.3 层次化网络设计
    4. TCP/IP协议
        4.1 TCP/IP协议
        4.2 DHCP
        4.3 DNS
        4.4 IPV6

计算机网络技术概述

网络拓扑结构
5G技术 SBA: Service-Based Architecture 服务化架构

组网技术

OSI7层模型
交换机
1. 交换技术
数据在网络中转发通常离不开交换机。交换机的功能包括：集线功能、中继功能、桥接功能、隔离冲突域
1. 基本交换原理
交换机是一种基于MAC地址识别，能完成封装转发数据包功能的网络设备。交换机可以学习MAC地址，并把其存放在内部地址表中，通过在数据的始发者和目标接受者之间建立临时的交换路径，是数据直接由原地址到达目的地址。
1. 需要实现的功能：
- 转发路径学习，根据收到数据中的源MAC地址建立该地址同交换机端口的映射写入MAX地址表中
- 数据转发。如果交换机根据数据中的目的MAC地址在建立好的MAC地址表中查询到了，就向对应端口进行转发。
- 数据泛洪，如果数据中的目的MAC地址不在MAC地址表中，则向所有端口转发也就是泛洪。广播帧和组播帧向所有端口进行转发，不包括原地址
- 链路地址更新， MAC地址表会每隔一定时间更新一次。。

网络规划与设计

网络冗余设计
设计目标有两个：一个是备用路径（一般近在主路径失效时投入使用），一个是负载分担
网络规划与设计
- 流程: 需求分析 -》通信规范分析 -》逻辑网络设计 -》物理网络设计 -》实施阶段
- 逻辑网络设计
- 物理网络设计
层次化网络设计
某企业通过一台路由器上联总部,下联4个分支机构,设计人员分配给下级机构一个连续的地址空间,采用一个子网或者超网段表示。这样做的主要作用是层次化路由选择。
层次化路由的含义是指对网络拓扑结构和配置的了解是局部的,一台路由器不需要知道所有的路由信息,只需要了解其管辖的路由信息,层次化路由选择需要配合层次化的地址编码。而子网或超网就属于层次化地址编码行为。
其中核心层在逻辑上只有一个,它连接多个分布层交换机,通常是一个园区中连接多个建筑物的总交换机的核心网络设备;汇聚层定义的网络的访问策略;接入层提供局域网络接入功能,可以使用集线器代替交换机。A选项错误,核心层只负责高速转发以及出口路由,访问控制列表检查是汇聚层的任务。
进行网络层次化设计时,一般分为核心层、汇聚层、接入层三个层次。为了保证网络的层次性,不能在设计中随意加入额外连接、除去接入层,其他层次应尽量采用模块化方式,模块间的边界应非常清晰。进行层次化网络设计时,应是先从接入层开始设计,然后逐级往核心层走。原因是接入层其实代表了需求,是因为有大量终端设备要接入,并有速度上的要求,才有了汇聚层要达到什么要求,核心层得怎么设计

TCP/IP协议

TCP/IP协议
DHCP 动态主机配置协议
分配方式
- 固定分配
- 动态分配 -》有限期限的IP地址；租期为8天，租约过半时，客户机需要想DHCP申请续约
- 自动分配
DNS
当浏览器输入域名： HOSTs -》本地DNS缓存 -》本地DNS服务器 -》根域名服务器 -》顶级域名服务器 -》权限域名服务器
- 递归查询：服务器必须回答目标IP与域名的映射关系
- 迭代查询：服务器收到一次迭代查询回复一次结果，这个结果不一定是目标IP与域名的映射关系，也可以是其他DNS服务器的地址
- PTR记录是DNS的反向记录，通过IP查询域名
IPV6
- ipv4的头部比ipv6复杂
- IPV6寻址模式分为三种，即单播地址、组播地址和泛播地址。
- 通常一台IPV6主机有多个IPv6地址，即使该主机只有一个单接口。一台IPv6主机可以同时拥有以下几种单点传送地址:每个接口的链路本地地址;每个接口的单播地址(可以是一个站点本地地址和一个或多个可聚集全球地址);回环(loopback)接口的回环地址(::1);此外，每台主机还需要时刻保持收听以下多点传送地址上的信息;节点本地范围内所有节点组播地址(FF01::1);链路本地范围内所有节点组播地址(FF02::1);请求节点(solicited-node)组播地址(如果主机的某个接口加入请求节点组);组播组组播地址(如果主机的某个接口加入任何组播组)。

SNMP

SNMPV3把对网络协议的安全威胁分为主要的和次要的两类。标准规定安全模块必须提供防护的两种主要威胁是:(1)修改信息:就是某些未经授权的实体改变了进来的SNMP报文，企图实施未经授权的管理操作，或者提供虚假的管理对象。 (2)假冒:即未经授权的用户冒充授权用户的标识，企图实施管理操作。必须提供防护的两种次要威胁是:(1)修改报文流:由于SNMP协议通常是基于无连接的传输服务，重新排序报文流、延迟或重放报文的威胁都可能出现。这种威胁的危害性在于通过报文流的修改可能实施非法的管理操作。(2)消息泄露:SNMP引擎之间交换的信息可能被偷听，对于这种威胁的防护应采取局部的策略。不必提供防护的威胁包括: (1)拒绝服务:因为在很多情况下拒绝服务和网络失效无法区别，所以可以由网络管理协议来处理，安全子系统不必采取措施。(2)通信分析:即由第三者分析管理实体之间的通信规律，从而获取需要的信息。由于通常都是由少数管理站来管理整个网络的，所以管理系统的通信模式是可预见的，防护通信分析就没有多大作用了。根据以上分析可以得知，本题应选B。

采用虚拟化技术，能够在一台物理服务器出现故障时迅速将业务迁移到另一台服务器上，从而减少了因硬件故障导致的服务中断时间，提高了业务的连续性和可用性。所以方案二相比方案一的优点是业务的连续性得到了保障

ARP攻击

ARP攻击是针对以太网地址解析协议ARP的一种攻击技术，此种攻击可让攻击者取得局域网上的数据封包甚至可篡改封包，且可让网络上特定计算机或所有计算机无法正常连接。ARP攻击造成网络无法跨网段通信的原因是伪造网关ARP报文使得数据包无法发送到网关。

11. 数据库系统

mindmap
  root((数据库系统))
    1.数据库模式
    2.规范化理论
    3.数据库控制技术
    4.关系代数
    5.逻辑结构设计
    6.概念结构设计-ER图
    7.数据库设计阶段
    8.分布式数据库

数据库模式

内模式
外模式
概念模式

规范化理论

非规范化的关系模式，可能存在的问题包括：数据冗余、更新异常（修改操作一致性问题）、插入异常、删除异常

注意事项：
- 候选键：唯一标识元祖，且无冗余
- 主键：从候选键中任选一个
- 外键，其他关系的主键
主属性与非主属性：组成候选码的数据性就是主属性，其他的就是非主属性。
函数依赖
范式
- 第一范式：在关系模式R中，当且仅当所有域中只含有原子值，即每个属性都是不可再分的数据项
- 第二范式：当且仅当实体E是第一范式，且每一个非主属性完全依赖主键，（不存在部分依赖）
- 第三范式：当且仅当实体E是第二范式，且E中没有非主属性传递依赖于码
- BC范式：设R是一个关系模式，F是他的依赖集，R属于BCNF当且仅当其F中每个依赖的决定因素必定包含R的某个候选码。

数据库控制技术

事物ACID特性
数据库安全
数据库的安全机制中，通过提供存储过程，第三方开发人员调用进行数据更新，从而保证数据库的关系模式不被第三方所获取
数据库备份

关系代数

逻辑结构设计

概念结构设计-ER图

ER图集成时产生的冲突及解决办法:

属性冲突:包括属性域冲突和属性取值冲突。
命名冲突:包括同名异义和异名同义。
结构冲突:包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。

数据库设计阶段

在数据库设计的逻辑设计阶段进行关系规范化
在数据库设计的需求分析阶段应完成包括数据字典，数据流图在内的文档

分布式数据库DDBMS

模式
1. 分片模式：分片模式将数据水平分割成多个部分（分片），每个分片存储在不同的节点上。
2. 全局外模式：全局外模式是用户视角下的数据表示模式，通常用于提供特定用户组的视图，不涉及整个系统数据的整体逻辑视图。
3. 分布模式：分布模式描述了数据在不同物理节点上的分布方式。
4. 全局概念模式：全局概念模式定义了整个分布式数据库的逻辑结构，是一个高层次的概念模型。
两阶段提交协议2PC
- 阶段
  1. 表决阶段，目的是形成一个共同的决定
  2. 执行阶段，目的是实现这个协调者的决定
- 规则
  1. 只要有一个参与者撤销事务，协调者就必须做出全局撤销的决定
  2. 只要所有参与者都同意提交事务，协调者才能做出全局提交决定
特性：
1. 数据独立性
2. 集中于自治共享结合的控制结构
3. 适当增加数据冗余度
4. 全局的一致性
5. 可串行性和可恢复性
组成：
1. 局部数据库管理系统LDBMS: 每个节点的本地数据库的管理模块，负责改节点数据的存储、访问和管理
2. 全局数据库管理系统GDBMS: 用于全局管理整个分布式数据库系统，包括多个节点的协同工作和全局数据的管理与访问
3. 全局数据字典
4. 通信管理CM
结构：
1. 全局控制集中的DDBMS
2. 全局控制分散的DDBMS
3. 全局控制部分分散的DDBMS
分布式透明性
1. 分片透明性
2. 复制透明
3. 位置透明性
4. 局部数据模型透明性（逻辑透明）

数据安全治理

数据安全治理的目标主要有三个:满足合规要求、管理数据安全风险、促进数据开发利用。这些目标旨在确保数据安全与业务发展的双向促进,同时保障组织在数据安全方面的合规性。

12. 数字和经济管理

mindmap
  root((数字和经济管理))
    1.运筹方法
        1.1 线性规划
        1.2 动态规划
        1.3 决策树
    2.随机函数
    3.图论
      3.1 最小生成树
      3.2 最短路径
      3.3 网络与最大流量

关系范式

本题考查电子商务方面的基础知识。电子商务分五个方面，即电子商情广告、电子选购与交易、电子交易凭证的交换、电子支付与结算，以及网上售后服务等。参与电子商务的实体有4类：客户(个人消费者或集团购买)、商户(包括销售商、制造商和储运商)、银行(包括发行和收单行)及认证中心。

电子商务

电子商务模式有多种,某平台通过自己的APP将合作方实体店的团购、打折优惠信息推送给互联网用户,从而将这些用户转换为合作方实体店的客户,这种模式称O2O。

团购这种商务形式中,涉及的电子商务模式其实不止一种。至少包括:B2C和O2O,因为团购平台上提供的服务是商家对个人的,这符合B2C的特性,同时团队是线上线下结合的形式。而本题中,既有B2C的选项,也有O2O的选项,此时我们需要进一步分析题目关注点是什么。题目中强调了APP推送优惠信息,引导到实体店,转化为实体店消费,所以此时强调的是线上营销加线下消费,更符合O2O的特性。

13. 知识产权和标准化

mindmap
  root((知识产权和标准化))
    1.保护范围与对象
        1.1 流水线
    2.保护期限
        2.1 层次化存储结构
        2.2 Cache
        2.3 磁盘管理
    3.侵权判定
    4.知识产权人确定

保护范围与对象

著作权法
- 保护对象：著作权
- 范围：文学、绘画、摄影等作品
- 注意事项：
  1. 不需要申请，作品完成即开始生效
  2. 绘画或摄影作品原件出售或赠与时，著作权归原作者所有，原件拥有者享受：所有权、展览权
软件著作权法
- 保护对象：软件著作权
- 范围：软件产品
- 注意事项：
  1. 不需要申请，作品完成即开始生效
  2. 登记制度便于举证
专利法
- 保护对象：专利权
- 注意事项：
  1. 需要申请，专利权有效期是从申请日开始计算
商标法：
- 保护对象：商标权
- 注意事项：
  1. 需要申请，核准之日起商标受保护
反不正当竞争法：
- 保护对象：商业秘密权
- 注意事项：
  1. 商业秘密包括技术与经营两个方面
  2. 必须有保密措施才能认定商业秘密

保护期限

侵权判定

知识产权人确定

甲公司接受乙公司的委托，开发一个应用软件，双方在没有订立任何书面合同的情况下，甲公司享有该软件的著作权

14 专业英语

The purpose of systems design is to specify a(n)( application architecture ) , which defines the technologies to be used to build the proposed information systems. This task is accomplished by analyzing the data models and process models that were initially created during ( requirements analysis ). The ( physical data flow diagram ) is used to establish physical processes and data stores across a network. To complete this activitly, the analyst may involve a number of system designers and ( system users ), which may be involved in this activity to help address business data, process, and location issues. The key inputs to this task are the facts, recommendations, and opinions that are solicited from various sources and the approved ( system proposal ) from the decision analysis phase.

The objective of ( architecture design ) is to determine what parts of theapplication software will be assigned to what hardware. The major software components of the system being developed have to be identified and then allocated to the various hardware components on which the system will operate. All sofware systems can be divided into four basic functions. The first is ( data storage ). Most information systems require data to be stored and retrieved, whether a small file, such as a memo produced by a word processor, or a large database, such as one that stores an organization’s accounting records. The second function is the ( data access login ), the processing required to access data, which often means database queries in Structured Query Language. The third function is the ( application logic ), which is the logic documented in the DFDs use cases, and functional requirements. The fourth function is the presentation logic, the display of information to the user and the acceptance of the user’s commands. The three primary hardware components of a system are ( clients, server and network ).

Software architecture reconstruction is an interpretive, interactive, and iterative process including many activities. ( Information extration ) involves analyzing a system’s existing design and implementation artifacts to construct a model of it. The result is used in the following activities to construct a view of the system, The database construction activity converts the ( elements and relations ) contained in the view into a standard format for storage in a database. The ( view fusion ) activity involves defining and manipulating the information stored in database to reconcile, augment, and establish connections between the elements. Reconstruction consists of two primary activities （ visualization and interation ）and ( pattern definition and recognition ). The former provides a mechanism for the user to manipulate architectural elements, and the latter provides facilities for architecture reconstruction.

The software architecture is a set of software conponents, subsystems, relationships, interactions, the properties of each of these elements, and the set of guiding principles that together constitute the fundamental properties and constraints of a software system or set of systems. ( Architectural pattern ) defines a general set of element types and their interactons. The examples include Pipes and Filters,Model-View-Controller, and Reflection. A ( Model ) in software architecture is a resentation used to understand or document one or more aspects of a problem or solution. Architecture is usually used in conjunction with many adjunct terms. The ( business architecture ) defines the key strateges, organization, goals and related processes of the enterprise. At the enterprise level, the ( application architecture ) may be more of a st of guidelines on how the various software archiectures should be constructed consistently across the enterprise. The （ reference architecture ）, which describes the high-level set of elements involved in application from a particular domain along with their interactions, is often used to focus on subsystem definition rather than application process level definition.

其他

在架构模型的指导下，可复用构建可以通过组装的方式，在较高层次上实现系统，并能够提高系统实现的效率。

软件系统工具的种类繁多，很难有统一的分类方法。通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。

软件开发工具：需求分析工具、设计工具、编码与排错工具。
软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

对于开发模型来说，喷泉模型复用好、开发过程无间隙、节省时间。螺旋模型是瀑布与原型（演化）模型结合体，适用于复杂项目。快速应用开发需要用户参与，模块化要求高，不适用新技术。RUP/UP是用例驱动、架构为中心、迭代、增量。

软件开发方法是指软件开发过程所遵循的办法和步骤，从不同的角度可以对软件开发方法进行不同的分类。

形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。形式化方法的主要优越性在于它能够数学地表述和研究应用问题及软件实现。但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难于为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。

净室软件工程(Cleanroom Software Engineering，CSE)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构规约进行分析和建模，并且将正确性验证作为发现和排除错误的主要机制，使用统计测试来获取认证软件可靠性所需要的信息。CSE强调在规约和设计上的严格性，还强调统计质量控制技术，包括基于客户对软件的预期使用测试。

ESB

企业服务总线( ESB )是构建基于面向服务体系结构( SOA )解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。

DCMM

数据管理能力成熟度评估模型DCMM评估内容包括：数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生存周期

DSSA

特定领域软件架构(Domain Specific Software Architecture，DSSA)以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。DSSA的基本活动包括领域分析、领域设计和领域实现。

领域分析
其中领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；
领域设计
领域设计的主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；该活动参加人员中, 领域专家的主要任务是提供关于领城中系统的需求规约和实现的知识
DSSA它通常是一个具有3个层次的系统模型，包括领域开发环境、领域特定应用开发环境和应用执行环境，
其中 应用工程师 主要在领域特定应用开发环境中工作。
领域实现
领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

互联网信息服务管理规定

危害国家安全、泄露国家秘密:这直接违反了国家安全法和保密法,是必须禁止的。
破坏国家宗教政策,宣扬邪教和封建迷信:这违反了国家关于宗教事务和社会管理的相关规定,是非法和有害的。
散布淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪:这些内容对青少年和社会风气有害,必须予以禁止。
侮辱或者诽谤他人,侵害他人合法权益:这侵犯了他人的名誉权和合法权益,是法律所不允许的。
散布谣言,扰乱社会秩序,破坏社会稳定:这会导致社会恐慌和不安定,是必须禁止的。
未经用户同意,擅自修改用户上网信息:虽然这也是不合法的行为,但它更多关联到个人隐私和数据保护,并不直接属于互联网信息服务管理办法中明确禁止的信息内容范畴。因此,在判断本题的选项时,不应将其作为必须包括的要素。

国家信息化

国家信息化体系包括信息技术应用、信息资源、信息网络、信息技术和产业、信息化人才、信息化法规政策和标准规范6个要素。

信息技术应用。信息技术应用是指把信息技术广泛应用于经济和社会各个领域。信息技术应用是信息化体系六要素中的龙头,是国家信息化建设的主阵地。
信息资源。信息资源、材料资源和能源共同构成了国民经济和社会发展的三大战略资源。信息资源的开发利用是国家信息化的核心任务,是国家信息化建设取得实效的关键,也是我国信息化的薄弱环节。
信息网络。信息网络是信息资源开发利用和信息技术应用的基础,是信息传输、交换和共享的必要手段。目前,人们通常将信息网络分为电信网、广播电视网和计算机网。三种网络的发展方向是:互相融通、取长补短、逐步实现三网融合。
信息技术和产业。信息技术和产业是我国进行信息化建设的基础。所以A选项描述错误。
信息化人才。信息化人才是国家信息化成功之本,对其他各要素的发展速度和质量有着决定性的影响,是信息化建设的关键。
信息化政策法规和标准规范。信息化政策法规和标准规范用于规范和协调信息化体系各要素之间关系,是国家信息化快速、持续、有序、健康发展的根本保障

混成系统

混成系统:一般由离散分离组件和连续组件并行或串行组成,组件之间的行为由计算模型进行控制。

SOA

SOA(Service-0riented Architecture)是一种面向服务的软件架构风格，它是一种基于服务的软件设计和开发方法，将应用程序组织为一组松散耦合的、可重用的、自治的服务，这些服务通过标准化的接口进行通信，以实现各种业务流程和功能。在SOA架构中，服务是系统的基本构建块，每个服务都是可独立部署、可重用的、自治的、松散耦合的。服务之间通过标准化的接口进行通信，这些接口可以基于XML、JSON等协议和Web Services、REST等技术实现。这样，SOA架构能够实现不同平台、不同编程语言和不同供应商之间的互操作性。

SOA架构的优点包括:

松散耦合:服务之间松散耦合，服务的修改不会影响到其他服务,
可重用性:服务可以被多个应用程序重复使用,
可扩展性:可以通过添加新的服务来扩展系统功能。
自治性:服务可以独立开发、测试、部署和管理,
标准化接口:服务之间通过标准化接口进行通信，，实现了不同平台、不同编程语言和不同供应商之间的互操作性。

但是，SOA架构也存在一些缺点，例如:

复杂性:SOA架构需要处理分布式系统+的复杂性，例如服务发现、负载均衡+、故障恢复+等
性能问题:由于服务之间需要通过网络通信进行交互，因此可能会影响系统的性能和响应时间
安全问题:由于系统中涉及多个服务，因此需要处理安全和身份认证等问题，增加了系统的安全风险。

soa架构和微服务架构的区别 SOA架构和微服务架构都是面向服务的软件架构风格，但是它们有一些区别。

服务粒度:SOA架构中的服务粒度较大，每个服务可能包含多个子服务，而微服务架构中的服务粒度更小，每个服务都是单一功能的服务。
部署:SOA架构中的服务通常是在一组服务器上部署的，而微服务架构中的服务通常是分布式部署的，每个服务都有自己的独立部署。
通信协议:SOA架构中的服务通常使用SOAP+或RESTful Web Services*进行通信，而微服务架构中的服务通常使用轻量级的RESTfuIAPI进行通信。
数据库:SOA架构中的服务通常共享同一数据库，而微服务架构中的每个服务通常有自己的数据库，服务之间通过API进行交互。
治理:SOA架构中需要使用中央化的治理来管理服务的注册、发现、路由、负载均衡、安全等问题，而微服务架构中的治理更加分散，每个服务都有自己的治理方式。
开发和部署:SOA架构中的服务通常是由大型团队开发和部署的，而微服务架构中的服务通常是由小型团队开发和部署的，每个团队负责自己的服务，

微内核

在设计微内核OS时，采用了面向对象的技术，其中的“封装”，“继承”，“对象类”和“多态性”，以及在对象之间采用消息传递机制等，都十分有利于提高系统的“正确性”、“可靠性”、“易修改性”、“易扩展性”等，而且还能显著地减少开发系统所付出的开销。采用微内核结构的操作系统与传统的操作系统相比，其优点是提高了系统的灵活性、可扩充性，增强了系统的可靠性，提供了对分布式系统的支持。其原因如下:

灵活性和可扩展性:由于微内核OS的许多功能是由相对独立的服务器软件来实现的，当开发了新的硬件和软件时，微内核OS只须在相应的服务器中增加新的功能，或再增加一个专门的服务器。与此同时，也必然改善系统的灵活性，不仅可在操作系统中增加新的功能，还可修改原有功能，以及删除已过时的功能，以形成一个更为精干有效的操作系统。
增强了系统的可靠性和可移植性:由于微内核是出于精心设计和严格测试的，容易保证其正确性;另一方面是它提供了规范而精简的应用程序接口(API)，为微内核外部的程序编制高质量的代码创造了条件。此外，由于所有服务器都是运行在用户态，服务器与服务器之间采用的是消息传递通信机制，因此，当某个服务器出现错误时,不会影响内核，也不会影响其他服务器。另外，由于在微内核结构的操作系统中，所有与特定CPU和I/O设备硬件有关的代码，均放在内核和内核下面的硬件隐藏层中，而操作系统其他绝大部分(即各种服务器)均与硬件平台无关，因而，把操作系统移植到另一个计算机硬件平台上所需作的修改是比较小的。
提供了对分布式系统的支持:由于在微内核OS中，客户和服务器之间以及服务器和服务器之间的通信，是采用消息传递通信机制进行的，致使微内核OS能很好地支持分布式系统和网络系统。事实上，只要在分布式系统中赋予所有进程和服务器唯一的标识符，在微内核中再配罟一张系统映射表即进程和服务器的标识符与它们所驻留的机器之间的对应表)，在进行客户与服务器通信时，只需在所发送的消息中标上发送进程和接收进程的标识符，微内核便可利用系统映射表，将消息发往目标，而无论目标是驻留在哪台机器上。

网络存储

开放系统的直连式存储(DirectAttached Storage，DAS)在服务器上外挂了一组大容量硬盘，存储设备与服务器主机之间采用SCSI通道连接，带宽为10MB/S、20MB/S、40MB/s和80MB/s等，直连式存储直接将存储设备连接到服务器上，这种方法难以扩展存储容量，而且不支持数据容错功能，当服务器出现异常时会造成数据丢失。
网络接入存储(Network Attached Storage，NAS)是将存储设备连接到现有的网络上，提供数据存储和文件访问服务的设备。NAS服务器是在专用主机上安装简化了的瘦操作系统(只具有访问权限控制、数据保护和恢复等功能)的文件服务器。NAS服务器内置了与网络连接所需要的协议，可以直接联网，具有权限的用户都可以通过网络访问NAS服务器中的文件。
存储区域网络(Storage Area NetworK，SAN)是一种连接存储设备和存储管理子系统的专用网络，专门提供数据存储和管理功能。SAN可以被看作是负责数据传输的后端网络，而前端网络(或称为数据网络)则负责正常的TCP/IP传输。也可以把SAN看作是通过特定的互连方式连接的若千台存储服务器组成的单独的数据网络，提供企业级的数据存储服务。

设计模式

mindmap
  root((设计模式))
    1.创建型
        1.1 工厂模式
        1.2 抽象工厂
        1.3 原型模式
        1.4 建造者
        1.5 单例模式
    2.结构型
        2.1 适配器模式
        2.2 桥接模式
        2.3 外观模式
        2.4 享元模式
        2.5 代理模式
        2.6 组合模式
        2.7 装饰器模式
    3.行为型

设计模式是一套可以被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解并且提高代码的可靠性。

设计模式的分类:

(1) 根据目的分类:
- 创建型主要用于创建对象。有工厂方法模式(Factory Method)、抽象工厂模式(Abstract Factory)、建造者模式(Builder)、原型模式(Prototype)、单例模式(Singleton)共5种。
- 结构型主要用于处理类和对象的组合。有适配器模式(Adapter)、桥接模式(Bridge)、组合模式(Composite)、装饰器模式(Decorator)、外观模式(Facade)、享元模式(Flyweight)、代理模式(Proxy)共7种。
- 行为型主要用于描述类或对象怎样交互和怎样分配职责。有职责链模式(Chain of Responsibility)、命令模式(Command)、解释器模式(Interpreter)、迭代器模式(Iterator)、中介者模式(Mediator)、备忘录模式(Memento)、观察者模式(Observer)、状态模式(State)、策略模式(Stratege)、模板方法模式(Template Method)、访问者模式(Visitor)共11种。
(2) 根据作用范围分类: 可分为类模式和对象模式。
- 类模式用于处理类和子类的关系,这种关系通过继承建立,在编译时就确定了,是一种静态关系。
- 对象模式处理对象间的关系,具有动态关系。

原型模式

Prototype (原型模式):用原型实例指定创建对象的类型,并且通过拷贝这个原型来创建新的对象。允许对象在不了解创建对象的确切类以及如何创建细节的情况下创建自定义对象。

抽象工厂模式

Abstract Factory(抽象工厂模式):提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。

建造者模式

Builder (建造者模式):将一个复杂类的表示与其构造相分离,使得相同的构建过程能够得出不同的表示。

单例模式

Singleton (单例模式):保证一个类只有一个实例,并提供一个访问它的全局访问点。

工厂模式

适配器模式

装饰器模式

装饰模式:动态地给一个对象添加一些额外的职责。它提供了用子类扩展功能的一个灵活的替代,比派生一个子类更加灵活。

很据题干描述，可以看出其基础是一个图形界面，并要求为图形界面提供一些定制的特效，例如带滚动条的图形界面，能够显示艺术字体且透明的图形界面等。这要求能够动态地对一个对象进行功能上的扩展，也可以对其子类进行功能上的扩展。装饰模式最符合这一要求。

桥接模式

特点是实现接口与实现的分离

当案例会带来“类爆炸”的问题时，使用桥接模式是合适的。桥接模式的最核心特点便是:将抽象部分与它的实现部分分离,使它们都可以独立地变化。

享元模式

代理模式

外观模式

外观(facade)模式是对象的结构模式,要求外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

组合模式

Composite (组合模式):将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。

访问者模式

某软件公司承接了为某工作流语言开发解释器的工作。该工作流语言由多种活动节点构成，具有类XML的语法结构。用户要求解释器工作时，对每个活动节点进行一系列的处理，包括执行活动、日志记录、调用外部应用程序等，并且要求处理过程具有可扩展能力。针对这种需求，公司采用访问者模式最为恰当。

对某个具有固定结构的活动节点需要多种处理能力，且处理能力可扩展也就是说要求在不改变原来类结构(活动节点)的基础上增加新功能。访问者模式最符合要求。

备忘录模式

解释器模式

解释器(Interpreter)模式。解释器模式属于类的行为型模式,描述了如何为语言定义一个文法,如何在该语言中表示一个句子,以及如何解释这些句子,这里的“语言”是使用规定格式和语法的代码。解释器模式主要用在编译器中,在应用系统开发中很少用到。

策略模式

策略(Strategy) 模式。策略模式是一种对象的行为型模式,定义一系列算法,并将每一个算法封装起来,并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化,其目的是将行为和环境分隔,当出现新的行为时,只需要实现新的策略类。

为了实现图像处理算法的灵活选择与替换，采用策略模式最为合适，因为策略模式定义一系列的算法，把它们封装起来，并且使它们可相互替换，使得算法可独立于使用它的客户而变化。

中介者模式

中介者(Mediator)模式。中介者模式是一种对象的行为型模式,通过一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。中介者对象的存在保证了对象结构上的稳定,也就是说,系统的结构不会因为新对象的引入带来大量的修改工作。

迭代器模式

迭代器(Iterator)模式。迭代器模式是一种对象的行为型模式,提供了一种方法来访问聚合对象,而不用暴露这个对象的内部表示。迭代器模式支持以不同的方式遍历一个聚合对象,复杂的聚合可用多种方法来进行遍历;允许在同一个聚合上可以有多个遍历,每个迭代器保持它自己的遍历状态,因此,可以同时进行多个遍历操作。

责任链模式

Chain of Responsibility(责任链模式):为解除请求的发送者和接收者之间耦合,而使多个对象都有机会处理这个请求。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它。

命令模式

某软件公司一款图像处理软件的需求分析与设计过程，并明确指出采用设计模式实现关键需求对系统灵活性与扩展性的要求。为了支持灵活的撤销与重做等行为，采用命令模式最为合适，因为命令模式可以将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，还可以对请求排队，或记录请求日志，以及支持可撤销的操作。

状态模式

为了封装图像操作与照片特征之间的复杂逻辑关系，采用状态模式最为合适，因为状态模式将每一个条件分支放入一个独立的类中，这样就可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化;

Notes

Subsections of Notes

1.1 系统工程

系统工程

遗留系统演化策略

1.2 信息系统

信息系统

信息系统开发方法

信息系统的分类

Case 论决策支持系统的开发与应用

Question

Answer

软件体系结构

架构风格

1.3 企业信息化&应用集成

企业信息化

目的

信息化需求

信息化方法

信息化三流

缩写

客户关系管理系统

企业门户

信息系统战略规划 ISSP

企业应用集成

为什么要集成

怎么集成

信息资源管理

企业应用集成

1.4 新技术

数字化

企业数字化转型的五个发展阶段

商业智能

智能制造

2.1 软件工程-需求工程

需求获取

需求分析

需求定义

需求变更

需求管理

需求跟踪

UML

需求跟踪能力链

概要设计

详细设计

2.2 软件工程-开发模型

瀑布模型

原型模型

V模型

迭代与增量

螺旋模型

基于构件的开发模型

基于构件的软件工程

快速应用开发RAD

统一过程UP/RUP

敏捷方法

逆向工程

净室软件工程

软件设计

2.3 软件工程-软件测试

测试与调试

测试种类

软件单元测试

软件集成测试

软件确认测试

测试目的

自动化测试

静动态测试

驱动模块与桩模块

静态分析

AB测试

系统测试

测试准确性

基准程序

软件维护的类型

2.4 软件工程-UML

结构式建模图

类图

对象图

包图