软件工程基础知识软件开发生命周期软件定义时期：问题定义、可行性研究、需求分析。软件开发时期：概要设计、详细设计、编码

软件开发生命周期

软件定义时期：问题定义、可行性研究、需求分析。
软件开发时期：概要设计、详细设计、编码、测试。
软件运行和维护：软件产品移交给用户使用。

软件系统的文档

用户文档：描述系统功能、使用方法。
系统文档：描述系统设计、实现、测试。

软件系统工具

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

软件工程过程：包括4个方面活动

P（Plan）-- 软件规格说明。规定软件的功能及其运行时的限制。
D（Do）-- 软件开发。开发出满足规格说明的软件。
C（Check）-- 软件确认。确认开发的软件能够满足用户的需求。
A（Action）-- 软件演进。在运行过程中不断改进以满足客户新的需求。

软件设计的4个活动

数据设计
架构设计（体系结构设计）
人机界面设计（接口设计）
过程设计

一

软件过程模型

****瀑布模型

是一个严格串行化的过程模型，因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。每一个阶段工作完成后，都伴随着一个里程碑，对该阶段的工作进行审查和确认。

严格的顺序限制了开发的灵活性。
不适应需求变化，难以快速响应变化。
风险管理困难。
缺乏客户参与，用户在开发过程中的反馈和意见很难被及时纳入。
过程不可逆，导致后期发现问题时，无法及时修正。

****原型模型

根据用户提出的软件系统的定义，快速的开发一个原型，该原型包含目标系统的关键问题、反映目标系统的大致面貌。

水平原型（行为原型）：只是功能的导航，主要用在界面上。
垂直原型（结构化原型）：实现了部分功能，主要用在复杂的算法实现上。
抛弃原型：在需求确认后，原型被抛弃不用。
演化原型：在需求确认后，不断补充和完善原型，直至形成一个完整的产品。

螺旋模型

在快速原型的基础上扩展而成，支持大型软件开发，适用于具有高风险的系统。

目标设定：需求分析，指定对过程和产品的约束，制订详细的管理计划。
风险分析：对可选方案进行风险识别、制订解决办法，采取措施避免风险。
开发和有效性验证：实施工程，开发原型，开发软件产品。
评审：客户评估，对项目进行评审，制订下阶段计划。

总结：为了使软件生命周期中的各项任务能够有序的按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型称为软件过程模型。

二

敏捷模型

敏捷方法的特点

适应性，而非预设性。
面向人的，而非面向过程的。

敏捷方法的核心思想

适应性，而非可预测。
以人为本，而非以过程为本。
迭代增量式的开发过程。

主要敏捷方法

1. 极限编程XP

是一种近螺旋式的开发方法，提倡测试先行，将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈、简单、勇气，开发人员和客户可以非常清楚开发进度、变化、待解决的问题、潜在的困难等，并根据实际情况及时的调整开发过程。

在执行交付计划之前，极限编程要求团队对系统的架构做一次预研（架构穿刺），当架构的初始方案确定后，就可以进入每次小版本的交付，每个小版本交付又被划分为多个周期相同的迭代，在迭代过程中，要求执行一些必须的活动，如编写用户故事、故事点估算、验收测试等。

2. 水晶系列方法

提倡“机动性”的方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。

3. 并列争求scrum

侧重于项目管理，是迭代式增量软件开发过程，包括了一系列实践和预定义角色的过程骨架。在scrum中使用Product Backlog来管理产品的需求，Product Backlog是一个按照商业价值排序的需求列表。根据Backlog的内容，将整个开发过程分为若干个短的迭代周期（sprint）。在spring中，scrum团队从Product Backlog中挑选最高优先级的需求组成Spring backlog。在每个迭代结束时，scrum团队将递交潜在可交付的产品增量。当所有spring结束时，提交最终的软件产品。

角色

产品负责人- product owner职责：把方向 — 做正确的事

PO是利益相关方的代表，从业务角度出发，对需求按权重排序，合理调整产品功能和迭代顺序。

scrum主管 - scrum master 职责：找方法 — 正确的做事

SM负责提高团队效率，确保所有的障碍backlog中的问题都已分配并可以得到解决，开发思想得到利益相关方的理解和支持，让利益相关方获得最大化的投资回报。

开发团队：职责：执行 — 把事情做正确

尽一切可能去完成任务，发布产品，充分理解PO的产品愿景，合作完成冲刺中的每一个目标，更好的支持可能需要进一步开发的产品发布。

工件

product backlog：按照商业价值排序的需求列表。

2. spring backlog：从Product Backlog中挑选最高优先级的需求。

3. 产品增量 increment：每个迭代结束时交付给客户的内容。

燃尽图：显示当前冲刺中未完成的任务数目，描述随着时间的推移而剩余的工作量，可用于表示工作进展。

活动

每个迭代召开“四会”：计划会、站立会、评审会、回顾会。

冲刺计划会：在每个冲刺之初，由PO讲解需求
每日站立会：每天进行沟通的内部短会。

会议由SM主持，团队成员把注意力集中在回答关键问题上，把已完成的任务从"处理中"状态转为"已完成"。会议结果：更新后的燃尽图、障碍backlog、冲刺backlog。

冲刺评审会：在冲刺结束前给PO演示并接受评价的会议。

开发进度通过实际已完成的产品的功能审核来进行控制。开发团队演示这个spring中完成的功能，由PO断定实际所发布的功能是否与既定的spring目标一致。会议结果：对当前冲刺的结果和整个产品的开发状态达成共识。

冲刺回顾会：在冲刺结束后召开的关于持续演进的会议。

分析冲刺的成功经验、所遇到的障碍、改进目标。

4. 特性驱动开发方法FDD

是一个迭代的开发模型，FDD认为有效的软件开发需要3个要素：人、过程、技术。6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员、领域专家。

5个核心过程

开发整体对象模型
构造特征列表
计划特征开发
特征设计
特征构建

三

统一过程模型 RUP

RUP描述了如何有效的利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线指导者，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。RUP软件开发生命周期是一个二维的软件开发模型，有9个核心工作流。**
**

9个核心工作流

业务建模

理解待开发系统所在的机构及其商业运作，评估待开发系统对所在机构的影响。

需求

定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。

3.分析与设计

把需求分析的结果转化为分析与设计模型。

实现

把设计模型转化为实现结果，对开发的代码做单元测试，将不同的模块集成为可执行系统。

测试

检查各个子系统之间的交互、集成，验证所有需求是否被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。

部署

打包、分发、安装软件，培训用户，提供技术支持。

配置和变更管理

跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。

项目管理

为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。

环境

提供软件开发环境，提供过程管理和工具支持。

RUP生命周期的4个阶段

初始：定义最终产品视图和业务模型，确定系统范围。
细化：设计及确定系统的体系结构，制订工作计划及资源要求。
构建：构造产品，继续演进需求、体系结构、计划直至产品提交。
移交：把产品提交给用户使用。

核心概念

角色：描述人或小组的行为与职责。who
活动：有明确目的的独立工作单元。how
制品：是活动生产、创建、修改的一段信息。what
工作流：描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。when

RUP的特点

用例驱动
以体系结构为中心：软件的体系结构是一个多维的结构。
迭代与增量

RUP采用“4+1”视图模型来描述软件系统的体系结构。

用例视图：分析人员和测试人员关注系统的行为，描述系统的功能需求。2. 逻辑视图：最终用户关注系统的功能，描述系统的静态结构。
进程视图：系统集成人员关注并发和同步特征，描述线程间的并发和同步。
实现视图：程序员关注模块之间的依赖关系, 描述系统代码构件组织和模块。
物理视图：系统工程师关注系统的部署、安装。定义软件到硬件的映射。

四

能力成熟度模型

能力成熟度模型CMM

初始级：杂乱无章，没有明确定义的步骤。
可重复级：基本的项目管理过程和实践，可跟踪，必要的过程准则。
已定义级：软件过程已经文档化、标准化、标准软件过程。
已管理级：详细度量标准、对软件过程和产品质量有定量的理解和控制。
优化级：不断持续改进。

能力成熟度模型集成CMMI

1. 初始级

过程通常是随意且混乱的。

2. 已管理级

确保策划、文档化、执行、监督、控制项目级的过程。

为过程建立明确的目标，能实现成本、进度、质量目标。

3. 已定义级

企业能够根据自身的特殊情况定义适合企业和项目的标准流程，将这套管理体系与流程予以制度化，同时企业开始进行项目积累，企业资产的收集。

4. 量化管理级

建立了产品质量、服务质量、过程性能的定量目标，对过程性能的可预测。

**
**

5. 优化级

通过增量式、创新式的过程与技术改进，不断改进过程性能。

3 需求工程

软件需求的3个不同层次

业务需求：客户对系统高层次的目标要求。
用户需求：用户要求系统必须能完成的任务。
功能需求：开发人员必须实现的软件功能。

需求工程的活动主要被划分为5个阶段

需求获取
需求分析
形成需求规格（需求文档化）
需求确认与验证
需求管理

需求开发

需求获取
需求分析
需求定义：需求规格说明书，严格定义 or 原型方法
需求确认与验证：需求评审 + 需求测试

需求管理

变更控制
版本控制
需求跟踪
需求状态跟踪

需求获取的基本步骤

开发高层的业务模型
定义项目范围和高层需求：描述系统的边界
识别用户角色和用户代表
获取具体的需求
确定目标系统的业务工作流
需求整理与总结

需求获取方法

用户面谈
需求专题讨论会
问卷调查
现场观察
原型化方法
头脑风暴法

需求管理的主要活动

变更控制
版本控制
需求跟踪
需求状态跟踪

变更控制过程

问题分析和变更描述
变更分析和成本计算
变更实现

变更策略

必须遵循变更控制过程。
由变更控制委员会CCB决定。
绝不能删除或修改原始文档。
未获得批准的变更不允许设计和实现。
项目风险承担者应该了解变更的内容。
变更保持水平可追踪性。

需求跟踪

正向跟踪 ：检查《需求规格说明书》中的每个需求是否都能在后继工作成功中找到对应点。
逆向跟踪：检查设计文档、代码、测试用例等工作成功是否都能在《需求规格说明书》中找到出处。

需求跟踪矩阵：保存了需求与后继工作成果的对应关系。

4 系统分析与设计

一. 结构化方法****

面向功能、面向数据流。

****结构化分析 SA

分析的步骤

分析业务情况，做出反映当前物理模型的数据流图DFD。
推导出等价的逻辑模型的DFD。
设计新的逻辑系统，生成数据字典和基元描述。
建立人机接口，提出可供选择的目标系统物理模型的DFD。
确定各种方案的成本和风险等级，据此对各种方案进行分析。
选择一种方案。
建立完整的需求规约。

分析的结果

功能模型：数据流图DFD，描述系统的功能需求（过程建模 / 功能建模）。
行为模型：状态转换图STD，描述系统的状态和引起状态转换的事件和条件。
数据模型：实体联系图E-R，描述系统中各个实体之间的关系。
数据字典：对DFD中的各个元素做出详细的定义和说明。

数据流图DFD

功能建模、过程建模。

核心：数据流

目的：描述系统的功能需求

DFD的4种基本元素

数据流：描述数据的流向。
加工：表示对数据进行的加工/处理和转换。
数据存储：表示用数据库形式存储的数据。
外部实体：描述系统数据的提供者、或数据的使用者。

DFD的建模过程

明确目标，确定系统范围。
建立顶层DFD图。
构建第一层DFD分解图。
开发DFD层次结构图。
检查确认DFD图。

数据流图DFD的作用

从数据传递和加工的角度，利用图形符号，通过逐层细分，描述系统内各个部件的功能、数据在各功能模块之间传递的情况，是需求分析的手段。

2. 描述系统的功能需求，为系统建立功能模型，是结构化分析方法中理解和表达用户需求的重要工具。

DFD概括描述了系统的内部逻辑过程，是需求分析结果的表达工具。
DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
DFD的顶层图定义了系统与外部实体间的界限和接口，清晰界定出系统的范围。

数据流图DFD中的常见错误

错误1：黑洞 --- 加工只有输入，没输出。错误2：奇迹 --- 加工只有输出，没有输入。错误3：灰洞 --- 加工的输入不足以产生输出，两者不对称。错误4：加工没有编号。
错误5：数据的流向没有经过加工。数据流的流向必须经过加工。错误6：数据流没有方向箭头。错误7：数据流没有名称。

数据字典DD

数据字典：是系统中使用的所有数据元素定义的集合，目的是对DFD中出现的所有元素都加以定义和详细说明，使得每个图形元素的名字都有一个确切的解释。

数据字典的组成**
**

数据项
数据结构
数据流
数据存储
处理过程

数据字典的作用

按各种要求列表，列出所有数据条目，保证系统设计时不会遗漏。
互相参照，便于系统修改。
由描述内容检索名称。
一致性检验和完整性检验。

****结构化设计 SD

SD是面向数据流的设计方法，以SRS和SA阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精、模块化的过程。

SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构。

概要设计：主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口、模块之间的调用关系，形成系统结构图SC。

详细设计：主要任务是为每个模块设计实现的细节，每个模块的实现算法、所需的局部数据结构。

信息隐藏与抽象：采用封装技术，将模块的实现细节隐藏起来。

模块化：功能--做什么，逻辑--怎么做，状态--使用的环境和条件。

模块的外部特性：模块名、参数表、影响。

模块的内部特性：完成其功能的代码、仅供模块内部使用的数据。

非直接耦合
数据耦合：传递简单数据。
标记耦合：传递记录等复杂信息、数据结构。
控制耦合：传递的信息中包含用于控制模块内部逻辑的信息。
通信耦合：共享了输入或输出。
公共耦合：公共的数据环境，全局数据结构。
内容耦合：一个模块直接访问另一个模块的内部数据。
功能内聚：完成一个单一功能，各个部分协同工作，缺一不可。
顺序内聚：必须顺序执行。
通信内聚：所有处理元素集中在一个数据结构的区域上。
过程内聚：必须按特定的次序执行。
时间内聚：必须在同一时间间隔内执行。
逻辑内聚：完成逻辑上相关的一组任务。
偶然内聚

系统结构图SC：模块结构图，反映了系统的总体结构，各模块之间的层次结构。

详细设计的基本步骤

分析并确定输入/输出数据的逻辑结构。
找出输入数据结构和输出数据结构中有对应关系的数据单元。
按一定的规则由输入、输出的数据结构导出程序结构。
列出基本操作与条件，并把它们分配到程序结构图的适当位置。
用伪码写出程序。

详细设计的工具

1. 图形工具：业务流图、程序流程图、PAD图、NS盒图、IPO图。

流程图：只能描述执行过程，不能描述有关的数据。

PAD图：问题分析图，既表示逻辑，也描述数据结构，支持自顶向下的过程，可自动转化成高级语言程序，更直观，结构更清晰。

NS盒图：功能域明确，容易表示嵌套和层次关系，具有强烈的结构化特征，不能任意转移控制，不适合复杂程序设计。

2. 表格工具：一张表描述过程的细节。

3. 语言工具：PDL伪代码，描述模块内部的具体算法，可作为注释直接插在源码中，也可由PDL自动生成代码。

结构化编程 SP

结构化程序设计采用自顶向下、逐步求精的方法。

各个模块通过“循序、选择、循环”的控制结构进行连接，并且只有一个入口和一个出口。

程序 = 算法 + 数据结构

**
**

二. 面向对象方法****

面向对象方法是以用例驱动、以体系结构为中心、迭代的、渐增式的开发过程。

****面向对象分析 OOA

OOA模型的5个层次

主题层
对象类层
结构层
属性层
服务层

OOA的5个活动

标识对象类
标识结构
定义主题
定义属性
定义服务

对象之间的2种结构

分类结构：一般与特殊
组装结构：整体与部分

OOA的基本原则

抽象：抽取共同的、本质的特征，过程抽象 + 数据抽象。
封装：把对象的属性(数据) 和操作(服务) 结合为一个不可分的系统单位，隐蔽对象的内部细节。
继承：特殊类对一般类的继承，不再重复定义一般类中已定义的属性和方法。
分类：把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。
聚合：多个对象的组装。
关联
消息通信：对象之间只能通过消息进行通信。
粒度控制
行为分析

分析的步骤

确定对象和类：类是多个对象的共同属性和方法的集合。
确定结构：分类结构：泛化-特化、组装结构：整体-部分。
确定主题：指事物的总体概貌、总体分析模型。
确定属性：数据元素，描述对象或分类结构的实例。
确定方法：收到消息后必须进行的一些处理方法。

分析的结果

1. 用例模型：从用户视角分析需求，描述系统的功能需求。

分析模型

静态分析模型：描述系统的基本逻辑结构，展示对象和类如何组成系统。

动态分析模型：描述系统的动态行为，展示对象在系统运行期间不同时刻的通信和交互。

用例建模的步骤

识别参与者
合并需求获得用例
细化用例描述
调整用例模型

建立分析模型的步骤

定义概念类
确定类之间的关系
为类添加职责：类的职责分解为类的属性和方法，属性封装数据，方法封装行为。
建立交互图

图的对比

数据流图：强调系统内数据的流动，描述系统的功能需求，面向数据流。

流程图：面向过程。强调处理过程，各处理过程之间有严格的顺序和时间关系，只能表示顺序执行的过程，不能描述有关的数据.

交互图

顺序图（序列图）

顺序图通常能更精确的描述对象间特定交互过程的详细步骤，着重展现对象之间按时间顺序进行的消息交互，以及这些消息之间的时序关系，强调交互的消息的顺序和时序。

协作图（通信图）

协作图通常表示较高层次的概览性视图，通过对象之间的集合和连接来描述多个对象在一定场景下的交互和协作关系，强调接收和发送消息的对象的结构组织****，着重展现对象之间的协作和通信方式。

定时图（计时图）

强调消息的实际时间。

交互概览图

动态图

活动图

描述用例和对象内部的工作过程，用于捕获动作及动作的结果，是内部处理驱动的流程。可以将一个活动图中的活动进行分组，每个活动都明确属于一个泳道，每一组表示一个特定的对象，负责完成组内的活动。

强调活动间的顺序和控制流，能够表示并发活动的情形。

适用于系统行为建模，关注活动的并发和同步，侧重从行为的动作来描述。

活动图是状态图的一种特殊形式。

状态图

描述一个对象在生命周期内响应事件所经历的状态序列。

状态间的转移需要外部事件的触发且满足指定的条件。

适合用于反应式系统建模，关注对象的状态变化，侧重从行为的结果来描述。

面向对象设计 OOD

分析模型：顶层架构图、用例与用例图、领域概念模型

设计模型：以包图表示的架构图、以交互图表示的用例实现图、完整精确的类图、描述复杂对象的状态图、描述流程化处理过程的活动图。

在OOD中，类分为3种类型

实体类

映射需求中的每个实体，保存需要存储在永久存储体中的信息。

控制类

用于控制用例工作的类，对一个或几个用例所特有的控制行为进行建模。

边界类

用于封装在用例内、外流动的信息或数据流，位于系统与外界的交界处。

面向对象编程 OOP

OOP达到了软件工程的3个主要目标：重用性、灵活性、扩展性。

OOP = 对象 + 类 + 继承 + 多态 + 消息

OOP的基本特点：封装、继承、多态

数据持久化

在面向对象开发方法中，对象只能存在于内存中。
对象持久化：把内存中的对象保存到数据库或可永久保存的存储设备中。
持久层：实现了数据处理层内部的业务逻辑和数据逻辑的解耦。

对象/关系映射ORM：将对象持久化到关系数据库中。

5软件测试

测试方法

静态测试：代码走查、代码审查、桌前检查。
动态测试：运行被测程序。
黑盒测试：对功能和界面进行测试，不考虑代码结构。（等价类划分、边界值划分、错误推测、因果图）
白盒测试：从程序结构方面对代码逻辑进行测试。（语句覆盖、判定覆盖、条件覆盖、路径覆盖）
灰盒测试：在内部结果出错，但输出结果正确的情况下用该方法测试。
自动化测试：在预先设定的条件下，自动运行被测程序。

测试阶段

单元测试：对软件的模块进行测试，测试依据 -- 详细设计说明书。
集成测试：对已经组装起来的模块同时进行测试，检查模块结构组装的正确性，发现与接口有关的问题，测试依据 --- 概要设计说明书。
系统测试：采用黑盒测试，检查该系统是否符合软件需求。

功能测试、用户界面测试、健壮性测试、可靠性及安全性测试
性能测试：模拟多种正常、峰值、异常负载条件，对各项性能指标测试。
负载测试：测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试：通过确定系统的瓶颈，来获得系统能提供的最大服务级别。

验收测试：用户对要交付的软件进行测试，验证是否满足SRS和签订的合同中的各项要求。

Alpha测试：用户在开发环境下测试。
Beta测试：用户在实际使用环境中测试。

回归测试：测试变更部分的正确性，以及不影响软件原有的功能。

6净室软件工程

净室软件工程CSE：在软件开发过程中，强调在软件中建立正确性的需要。

是一种应用数学与统计学理论，以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程，达到开发中的零缺陷或接近零缺陷。

净室软件工程是一种形式化方法，使用盒结构规约进行分析和设计建模，强调将正确性验证作为发现和消除错误的主要机制。

CSE要求在规约和设计中消除错误，强调在软件中建立正确性的需要，降低软件开发中的风险，以合理的成本开发出高质量的软件。

理论基础

函数理论：完备性、一致性、正确性。2. 抽样理论：对样本进行测试。

技术手段

统计过程控制下的增量式开发增量开发、控制迭代。2. 基于函数的规范与设计盒子结构方法的3种抽象层次
(1) 行为视图：外部行为，黑盒。(2) 状态机视图：状态盒。(3) 过程视图：明盒。盒子结构是基于对象的，满足信息隐藏、实现分离。3. 正确性验证CSE的核心
统计测试和软件认证净室测试方法，采用统计学的基本原理，抽样统计，测试用例是总体的一个随机样本。

缺点

太理论化，需要更多的数学知识，正确性验证的步骤比较困难且比较耗时。
不进行传统的模块测试，这不现实。
带有传统软件工程的一些弊端。

7 基于构件的软件工程

基于构件的软件工程CBSE：是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于已有构件的组装，更快的构造系统。

构件：又称组件，是一个独立可交付的功能单元，向外提供统一的访问接口，构件外部只能通过接口来访问构件。

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

原子构件是部署、版本控制和替换的基本单位，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。

大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。

对象：一个实例单元，封装了自己的状态和行为。
模块：不带单独资源的原子构件。
构件：一个原子构件 = 一个模块 + 一组资源，构件由多个原子构件组成。
服务

构件的特性1. 自包容、可重用。2. 独立部署单元。3. 没有外部的可见状态。4. 作为第三方的组装单元。5. 一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。
对象的特性1. 一个实例单元，具有唯一的标志。2. 可能具有状态，此状态外部可见。3. 封装了自己的状态和行为。
构件模型：接口、使用信息、部署。面向构件的编程COP面向构件的编程需要下列基本的支持：1. 多态性：可替代性。2. 模块封装性：高层次信息的隐藏。3. 后期的绑定和装载：部署独立性。4. 安全性：类型和模块安全性。
构件的组装模型1. 设计构件组装
将系统划分成一组构件的集合，明确构件之间的关系。2. 建立构件库在确定了系统构件后，开发软件构件、重用已有的构件、选用第三方的构件。构件之间通过接口相互协作。3. 构建应用软件构件组装。4. 测试与发布
构件组装模型的优点1. 系统可扩展性良好：构件的自包容使得系统更容易扩展。

降低软件开发成本：重用已有的构件。3. 更加灵活：构件的粒度小，可独立开发。
构件组装模型的缺点1. 构件设计不好会降低构件组装模型的重用度。2. 考虑重用度时，可能会对性能等其它方面做出让步。3. 增加了学习成本。4. 第三方构件库的质量难以控制。
商用构件的标准规范1. EJB在J2EE中，EJB是中间层（业务逻辑层）的中间件技术，与JavaBeans不同，它提供了事务处理的能力。会话Bean：维护会话实体Bean：处理事务消息驱动Bean2. COM、DCOM、COM+COM：构件对象模型component object modelDCOM：分布式构件对象模型。主要适合windows平台。3. CORBA公共对象请求代理架构，主要分为3个层次：(1) 对象请求代理 ORB最底层，规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的"软总线"。(2) 公共对象服务在ORB上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等。(3) 公共设施最上层，定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

8 中间件

‍‍中间件：是一类软件，在一个分布式系统环境中，处于操作系统和应用程序之间，提供应用软件与各种操作系统之间使用的标准化编程接口和协议，起到承上启下的作用，使应用软件的开发独立于计算机硬件和操作系统，并能在不同的系统上运行。
中间件分类1. 通信处理中间件（消息中间件）实现分布式系统中可靠的、高效的、实时的跨平台数据传输，可靠的消息传递机制，保证系统能在不同平台之间通信。kafka、RocketMQ。
2. 事务处理中间件（交易中间件）在分布式事务处理系统中，大量事务在多台服务器上实时并发运行，每项事务需要多台服务器上的程序按顺序协调完成。Seata 是一款开源的分布式事务解决方案，包括 AT、TCC、Saga 和 XA 事务模式，可支持多种编程语言和数据存储方案。3. 数据存取管理中间件在分布式系统中，数据服务器中的数据可以是关系型的、复合文档型、各种格式的多媒体型，或者是经过加密、压缩存放的，数据存取管理中间件的作用是便于在网络上虚拟缓冲存取、格式转换、解压。通过一个抽象层访问数据库，从而允许使用相同或相似的代码访问不同的数据库资源，例如JDBC。4. web服务器中间件在web应用程序和服务器之间，用于处理http请求和响应，实现负载均衡。
nginx--反向代理服务器，将客户端请求分发到多个后端服务器上，实现负载均衡，支持多种负载均衡算法。快速、高效的提供静态内容，如html、css、image等。
Tomcat--Java servlet容器，用于运行Java web应用程序。
5. 安全中间件防火墙、加密、认证。
6. 跨平台和架构的中间件架构中间件用于在分布式系统中，集成各结点上的不同系统平台上的构件。CORBA：可以跨任意平台，但过于庞大。JavaBeans：灵活简单，适合用于浏览器，但运行效率有待改善。COM+：主要适合windows平台。7. 专用平台中间件为特定应用领域设计领域参考模型，建立相应架构，配置相应的构件库和中间件。8. 网络中间件网管、接入、网络测试、虚拟社区、虚拟缓冲。

分布式事务模式

1. XA模式

2. TCC模式

3. Saga模式

4. AT模式

5. 基于本地消息的模式

逆向工程

4个级别	包括	完备性	抽象级别
实现级	抽象语法树符号表过程的设计表示	高	低
结构级	结构图调用图程序数据结构	-	-
功能级	数据控制流模型	-	-
领域级	E-R模型	低	高

1. 逆向工程

在比源代码更高抽象层次上建立程序的表示过程。

重构

同一抽象级别上，转换系统描述形式。

设计恢复

从已有程序中抽象出设计。

再工程

在逆向工程所获得信息的基础上，修改或重构已有系统，产生系统的一个新版本，是对现有系统的重新开发过程。

再工程 = 逆向工程 -> 新需求的考虑 ->正向工程

正向工程

恢复设计信息，使用该信息修改或重构已有系统。