软件工程—研究生复试 (1)-CSDN博客

本文链接：https://blog.csdn.net/2301_81070471/article/details/146908562

软件工程—notebook

一、基本概念

1.软件危机

出现软件危机，为了解决软件危机，提出了软件工程

定义： 在计算机软件的开发和维护过程中所遇到的一系列严重问题（名词解释）

软件危机包含两方面的问题：

如何开发软件，以满足对软件日益增长的需求
如何维护不断膨胀的已有软件

软件危机的典型表现：

对软件开发成本和进度的估计常常很不准确
用户对“已完成的”软件系统不满意的现象经常发生
软件产品的质量往往不佳
软件常常是不可维护的
软件通常没有适合的文档资料
软件成本在计算机系统总成本的所占比例逐年上升 软件价格逐年上涨（✖）

软件开发生产率提高的速度，媛媛跟不上计算机应用迅速普及及深入的趋势

产生软件危机的原因：

一方面与软件本身的特点有关

软件不同于硬件，是计算机系统中的逻辑部件而不是物理部件

规模会越来越大，结构越来越复杂
开发管理很困难，质量和进度难以控制
开发费用不断增加，需要投入大量人力和资源，周期长

另一方面与软件开发与维护的方法不正确有关

软件开发技术，开发工具落后，生产率提高缓慢
开发人员或多或少采用错误的方法和技术
忽视软件需求分析的重要性，轻视维护
忽视软件配置中的文档，数据等

软件=程序+文档+数据

消除软件危机的途径：

首先应该对计算机软件有一个正确的认识-软件=程序+文档+数据
更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好，管理严密，各类人员协调配合，共同完成的工程项目
必须充分吸收和借鉴人类长期从事各种工程项目所积累的行之有效的原理，概念，技术和方法，特别要吸收几十年来人类从事计算机硬件研究和开发的经验教训
应该推广使用在实践中总结出来的开发软件的成功技术和方法，并且研究探索更好更有效的技术和方法
应该开发和使用更好的软件工具

程序是能够完成预定功能和性能的可执行指令序列
数据是程序能够适当的处理信息的数据结构
文档是开发，使用和维护所需要的图文资料

2.软件工程

**定义：**软件工程是指导计算机软件开发和维护的一门工程学科，采用工程化概念，原理，技术和方法来开发和维护软件，把经过时间考验而证明正确的管理(计划,组织,控制,合理配置资源)和当前能够得到的最好的技术(在软件生命周期全过程中使用的一整套技术方法的集合称之为方法学)方法结合起来，以经济的开发出高质量的软件并有效的维护它，这就是软件工程

**如何解决软件危机:**既要有技术措施,又要有必要的组织管理措施,从管理和技术两方面研究如何更好的开发和维护计算机软件

**核心:**保证软件产品的质量和提高开发效率

七大本质特征：

1. 关注于大型程序的构造
2. 中心课题是控制复杂性
3. 软件经常变化
4. 开发软件的效率非常重要
5. 和谐的合作是开发软件的关键
6. 软件必须有效的支持它的用户
7. 在软件工程领域通常是具有一种文化背景的人替具有另一种文化背景的人创造产品

七大基本原理（方法论）：

用分阶段的生命周期计划严格管理
2. 坚持进行阶段评审
* 设计错误占63%，编码错误占37%
3. 实行严格的产品控制
* 不可随意更改需求
4. 采用现代程序设计技术
* 提高效率,保证质量
5. 结果应能清楚地审查
* 提高可读性
6. 开发小组的人员应该小而精
高素质的开发人员的效率是低素质的几倍甚至几十倍
随着人员数量的增加，通信开销相应增加

承认不断改进软件工程实践的重要性

软件工程的经济性原则

早期改动,代价低

中期改动,代价剧增

后期(已完成),更高的代价

3.软件工程方法学

**定义：**在软件生命周期全过程中使用的一整套技术方法的集合称之为方法学也叫范式

**三要素：**方法，工具和过程

1.传统方法学

数据与过程是分离的（面向过程）

采用结构化技术（结构化分析，设计，实现）来完成软件开发的各项任务并使用适当的软件工具或软件工程环境来支持结构化技术的运用。划分阶段并顺序执行每个阶段结束前都要进行技术审查和管理复审,并且交付一份高质量的文档资料,从而保证结束时有一份完整的软件配置

文档的意义（简答）

阶段性的审查，标准是每个阶段都应该交出最新型的高质量的文档资料
文档是通讯的工具，他们能够清楚准确地说明到了这个时候为止，关于该项工程已经知道了什么，同时奠定了下一步工作的基础
也起到备忘录的作用

2.面向对象方法学 === 对象+类+继承+用消息通信==

一个主动的多次反复迭代的演化过程,各项开发活动之间平滑过渡

**vs传统方法学:**降低了软件产品的复杂性,提高了软件的可理解性,简化了软件的开发和维护工作

当软件规模庞大或对软件的需求模糊易变时采用生命周期方法学开发往往不成功

四大要点：对象+类+继承+用消息通信

把对象作为融合数据在数据上的操作行为的统一的软件构件
把所有对象都划分为类（具有相同数据和相同操作的一组相似对象的定义）
按照父类与子类的关系，把若干个相关的类组成一个层级结构的系统
对象彼此之间仅能通过发送消息会想联系

传统方法学	面向对象方法学
系统是过程的集合	系统是交互对象的集合
过程与数据实体交互	对象与人或其他对象交互
过程接受输入并产生输出	对象发送与响应信息

4.软件的生命周期：

一个软件从定义，开发，使用和维护，直到最终被废弃要经历一个漫长的时期，如同一个人要经过婴儿，儿童，青年，中年和老年，直到最终面对死亡的漫长时期一样

三个时期&八个阶段：

软件定义（降低软件成本，提高软件质量的关键）

1. 问题定义
2. 可行性研究
3. 需求分析
- 软件开发
    1. 总体设计
    2. 详细设计
    3. 编码和单元测试
    4. 综合测试
- 软件维护：轻视维护是一个最大的错误

测试的工作量占全部工作量的40%~50%（工作量最大）
编写程序知识软件开发全部工作量的10%~20%
用于软件维护的成本占软件总费用的55%~70%（成本最大）

5.软件维护

软件维护的具体体现：

在程序运行时发现的错误必须设法改正
用户有了新需求时必须对应的修改程序
硬件或操作系统更新时，需要修改程序以适应新的环境

现代维护的费用占软件总费用的55%~70%,软件工程学的一个重要目标就是提高软件的可维护性,减少软件维护的代价

6.软件过程

软件过程是为了开发出高质量的软件产品所需要完成的一系列任务的框架，规定了其各项任务的工作步骤

软件过程是软件工程方法学的三个重要组成部分之一（方法，工具，过程）

瀑布模型
规范的文本驱动方法，但是最终开发的软件产品可能并不是用户真正需要的

阶段间具有顺序性和依赖性
推迟实现的观点(编码越早,耗时越长)尽可能推迟程序的物理实现
保证质量的观点(优质➕高产)
每个阶段都要完成规定的文档,且文档要合格
每个阶段结束前都要对所完成的文档进行审批,以便尽早的发现错误,改正错误

优点

强迫开发人员采用规范的方法
严格的规定了每个阶段必须提交的文档
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
提高软件质量,降低维护成本,缓解软件危机

缺点

在可运行的软件产品交付给用户之前,用户只能通过文档来了解产品是什么样的,很难全面正确的认识动态的软件产品,但是最终开发的软件产品可能并不是用户真正需要的

快速原型模型
克服瀑布模型的缺点，快速构建一个原型系统，用户试用并提供反馈意见，获取用户真实需求需求不确定的软件（就一定要采用快速原型的模型 ) 快速建立一个能反映用户主要需求的原型系统,反复由用户评价,获得最终的修正需求,再规格说明,设计,实现,测试,开发最终产品(六个阶段)

瀑布vs快速原型:获取用户需求的方法不同

快速原型的本质是“快速”，原型的用途是获知用户的真正需求。在确定需求不明确的软件系统的需求的时候，瀑布模型是没办法的，而快速原型模型可以。

优点

软件产品的开发基本时线性顺序进行的
开发人员已经通过建立原型系统知道了系统不该干什么,减少了后期设计编码的错误
确定需求上优于瀑布模型(通过原型和用户交互)
有的软件原型可以成为最终产品的一部分

缺点

快速建立的系统加上连续的修改,可能导致产品的质量低下,

原型系统的内部结构可能不好

增量模型
把软件产品作为一系列增量构件来设计，编码，集成和测试（加拓展包）
能够在较短的时间向用户提交可完成部分工作的产品，逐步增加产品功能。

优点：

能在短时间内向用户提交可完成部分工作的产品。
逐步增加产品功能可以使用户有充裕的学习和适用产品。
软件结构必须开放，方便向现有产品加入新构件。

缺点:

第三点很难做到

在把每个新的增量构件集成到现有软件体系结构中时，必须
不能破坏原来已经开发出的产品

螺旋模型
螺旋模型将瀑布模型与原型（演化）模型结合起来，并且加入两种模型均忽略了的风险分析，弥补了两者的不足。看成每个阶段之前都增加了风险分析过程的快速原型模型
软件重用，减少风险，软件维护和软件开发没有明显区别

优点：

对可选方案和约束条件的强调有利于已有软件的重用，
有助于把软件质量作为软件开发的一个重要目标。
减少了过多测试或测试不足所带来的风险。
在螺旋模型中，维护只是模型的另一个周期，在维护和开发之间没有本质区别。主要适用于内部开发的大规模软件项目

缺点：

软件开发人员需要丰富的风险评估的经验和这方面的专门知识
契约开发时，通常需要事先指定过程模型（指定非螺线模型的过程模型）和发布产
品。普及不如前述模型

它加入了风险分析，大型软件项目风险是很高的。
笛卡尔坐标四象限表达四方面活动：
制定计划：确定目标，选定方案，设定约束条件。
风险分析：评估方案，识别和消除风险。
实施工程：软件开发。（这里像瀑布模型）
客户评估：评价开发工作，计划下一阶段工作
沿螺线自内向外每旋转一圈开发出更完善新版本。

喷泉模型 ()面向对象生命周期模型)
体现了迭代（求精），无缝（分析设计编码没有明显边界)的特性

优点：无缝，可同步开发，提高开发效率，节省开发时间，适应面向
对象软件

rational统一过程RUP 特别适用于大型软件团队开发大型项目。由rational软件公司推出的一种软件过程，该过程强调以迭代和渐增方式开发软件。整个项目多次迭代，每个阶段也多次迭代。(4个阶段，初始，精化，构建，移交)

迭代方式开发软件

> 迭代式开发允许在每次迭代过程中需求都可以有
> 变化，这种开发方法通过一系列细化来加深对问题的理解，因
> 此能更容易的容纳需求的变更。

全过程管理需求
基于构件
建立软件产品可视化视图

RUP和UML联系一起，在开发过程中建立软件系统的可视化模型，提高管理软件复制性的能力

全过程严格验证质量
控制变更

优点：它是不断的迭代来完成一个软件开发的，不断的版本发布成为一种团队日常工作的真正驱动力。将发现问题，制定方案和解决过程集成到下一次迭代。迭代开发，降低风险。

敏捷过程与极限编程
极限编程XP是最著名的敏捷过程优点：具有对变化和不确定的更快捷，更敏捷的反应特性，在快速的同时仍然能保持开发速度

四大价值观：

开发人员素质及交互与协作比过程和工具更重要

软件比文档更重要
合作比合同谈判更重要
及时响应比遵循计划更重要

很适合商业竞争环境下对小型项目提出的有限资源，有限开发时间的约束

微软过程
每个生命周期发布一个递进的软件版本，各个生命周期持续快速的迭代循环

课后题

软件工程是一门工程性的学科

20世纪60年代提出了软件工程的概念

软件工程学科所要研究的基本内容：目标，原理，过程

CASE（Computer-Aided Software Engineering，计算机辅助软件工程）用于辅助软件开发，维护，测试过程中的软件开发工具

二、结构化分析

1.可行性研究

**目的：**用最小的代价在尽可能的短的时间研究并确定客户提出的问题时候有行得通的解决办法

技术可行性
经济可行性
操作可行性

2.需求分析的任务

核心思想：

分解化简问题
物理与逻辑表示分开
进行数据与逻辑抽象

确定对系统的综合要求（发现需求）

功能\性能\可靠性和可用性\出错处理\接口\约束\逆向需求\将来可能的要求

分析系统的数据要求 (求精)
导出系统的逻辑模型（建模）
修正系统开发计划（复审）

模型

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

3.具体步骤

模型核心：数据字典

描述软件使用和产生的所有数据对象。

数据模型：E-R图

描述数据对象间关系，图中数据对象属性用“数据对象描述”表达。

功能模型：DFD图（数据流图）

描绘数据在软件中移动、变换及相应功能，图中功能用“处理规格说明”表达。

行为模型：状态转换图

描绘系统状态和在不同状态间转换方式。图中软件控制附加信息用“控制规格说明”表达。

规格说明：

书写软件需求规格说明，作为分析阶段最终成果。

复审

4.实体联系图

描述了从用户角度看到的数据

实体（矩形）、关系（菱形）、属性（椭圆形）

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5.数据流图

描述数据在软件系统内从输入移动到输出过程中所经受的变换，描绘做什么，而不考虑怎么做

数据的源点和终点（正方形）、变换数据的处理（圆角矩形）、数据存储（开口矩形）、数据流（箭头线）

数据存储是处于静止的数据，数据流是运动状态的数据

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

步骤

从问题描述提取数据流图四种成分

先考虑源点和终点
再考虑处理
最后考虑数据流和数据存储

着手画数据流图的基本系统模型。
把基本系统模型细化，描绘系统主要功能
主要功能进一步细化
结束、进一步分解涉及如何具体实现功能时，不应再分解

案例：
工厂采购部采购员每天需一张订货报表，按零件编号排序列出所需定货零件。对定货零件列下述数据：零件编号、名称、定货数量、目前价格，主次要供应者等。零件入库或出库称事务，通过仓库终端把事务报告定货系统。零件库存量少于库存临界值需订货

**源点:**仓库管理员 **终点:**采购员 **处理:处理事务、**产生报表等 **数据流：事务、订货信息、**订货报表等 **数据存储：订货信息、**库存信息

6.数据字典

对数据流图中包含元素的定义的集合，提供关于数据的描述信息

1.定义方法

数据流
数据元素

数据元素名: ** **
类型:数字（离散值、连续值），文字（编码类型）
**** 长度: **
**** 取值范围:
相关的数据元素及数据结构：

例如

数据元素名：学号
类型：数字（离散）， 12位表示分院、34位表示专业
56位表示年级、78位表示班级、910位表示序号
长度：10位
取值范围：0000000000~9999999999
相关的数据元素及数据结构：购书单、发票、领书单

数据存储

数据存储名：

简述：存放的是什么数据。

输入数据😗*

输出数据😗*

数据文件组成:数据结构。

存储方式:顺序，直接，关键码。

存取频率😗*

例如

数据存储名：各班学生用书表
简述：各班学生用书信息
输入（输出）数据：各班学生用书信息
数据文件组成：班级编号+书号+用量
存储方式：按班级编号从小到大排列

处理

处理名:
处理编号:反映该处理的层次
简要描述:加工逻辑及功能简述
输入数据流:
输出数据流:
加工逻辑：简述加工程序、加工顺序

2.定义符号

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

7.状态转换图

描绘系统**状态及引起系统状态转换的事件来表示系统的行为**

状态外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

事件箭头+事件名

行为状态框内——do：行为名

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

三、结构化设计

概要设计：

将软件需求转化为数据结构和软件系统结构。

详细设计：

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

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

1.概念和原理

数据设计：

数据模型及核心数据字典转变为数据结构。

体系结构设计：

功能模型中数据流图转变成计算机模块框架。

接口设计：

功能模型中数据流图转变成软件内部、软件与协作系统间、软件与用户间通信方式。

过程设计：

行为模型及功能模型中的“处理规格说明”转换成软件构件过程描述。

模块化

把软件划分为一个个较小的、相关而又相对独立的模块

模块划分导致单个模块成本下降的同时，接口模块也会迅速增加

抽象：抽出事物的本质特性，暂不考虑细节。

逐步求精：求精在设计过程中揭示底层细节。

信息隐蔽=封装

**模块独立 **高内聚低耦合

2.模块独立

耦合：软件结构中不同模块间互连程度度量

尽量使用数据耦合，少用控制耦合，限制公共环境耦合，完全不用内容耦合。

内聚： 模块内各元素彼此结合紧密程度

数据耦合 两模块通过参数交换数据信息**。**

控制耦合 两模块通过参数交换控制信息（包括数字形式）

公共环境耦合 两个或多个模块通过一公共数据环境作用

内容耦合

（1）一模块访问另一模块内部数据；

（2）一模块不通过正常入口转到另一模块内部；

（3）两模块有部分程序代码重叠（汇编程序）；

（4）一模块有多个入口。

从上到下内聚程度逐渐下降

功能内聚
一模块中各部分是完成某一功能必不可少组成部分。
顺序内聚
模块内处理元素同某功能密切相关，顺序执行。
通信内聚：

一模块内各功能部分都使用相同输入数据，或产生相同输出数据。

过程内聚

模块内处理元素相关，特定次序执行。如把流程图中循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。

时间内聚

多为多功能模块，要求所有功能在同一时间内执行。如初始化模块和终止模块及紧急故障处理模块。

逻辑内聚

一模块完成功能在逻辑上属相同相似一类。

偶然内聚

启发规则

改进软件结构提高模块独立性 初步结构分解或合并，降低耦合提高内聚。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

模块规模应该适中
深度、宽度、扇出和扇入应适当深度：软件结构控制层数，标志一系统大小和复杂程度。宽度：软件结构同一层模块数最大值，越大系统越复杂。扇入：被上级模块调用的个数 _扇入越大，表明该模块被复用的次数越多，模块的通用性和利用率越高_扇出：调用下级模块的个数 扇出过大可能导致模块承担过多协调职责，增加维护难度；扇出过小则可能表示调用层次冗余

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

模块作用域应在控制域内作用域：受该模块内判定影响的所有模块集合。判定域应该尽量上移控制域：模块本身及所有直接或间接从属它的模块集合。若模块作用域不在控制域内，会增大模块间控制耦合。
降低模块接口复杂程度
**设计单入口、单出口模块 **避免内容耦合。
模块功能可预测

3.面向数据流设计

三、UML（统一建模语言）

UML的核心是由视图，图，模型元素，和通用机制组成

UML构成

UML 的核心由三类基础元素构成：

结构元素（Structural Elements）
描述系统的静态部分（事物本身）。
包括：
类（Class）：对象的属性和方法。
接口（Interface）：定义行为规范。
用例（Use Case）：系统的功能需求。
组件（Component）：可重用的模块。
节点（Node）：物理设备或运行时环境（如服务器）。

行为元素（Behavioral Elements）
描述系统的动态行为（事物如何变化或交互）。
包括：
交互（Interaction）：对象间的消息传递（如方法调用）。
状态机（State Machine）：对象的状态变化（如订单状态流转）。
活动（Activity）：流程化的步骤（如业务流程）。

关系元素（Relationship Elements）
定义元素之间的连接关系。
包括：
关联（Association）：对象间的逻辑连接（如学生选课）。
依赖（Dependency）：一个元素的变化影响另一个元素（如类A使用类B）。
泛化（Generalization）：继承关系（如子类继承父类）。
实现（Realization）：接口与实现类的关系。

**视图：**视图是表达系统的某个方面特征的UML建模元素的子集，它并不是具体的图，而是由一个或多个图组成对系统某个角度的抽象。建造完整系统时，通过定义多个反映系统不同方面的视图，才能做出完整，精确的描述。

UML中的视图大致可以分5种：

用例视图:由用例图描述
逻辑视图:
- 静态结构: 类图和对象图,包图
- 动态模型: 状态图，顺序图，协作图，活动图
并发视图: 状态图，协作图，活动图
组件视图: 组件图
部署视图: 部署图

**图：**图由各种图片组成，用于描述一个视图内容，图并不仅仅是一个图片，而是在某个抽象层上对建模系统的抽象表示。UML中共定义了9种基本图，结合这些图可以描述系统所有的视图。

UML中9种图

1. 静态建模（Static Modeling）

对应面向对象建模：结构建模 + 功能建模。
核心图表：
结构建模：类图、组件图、部署图、包图。
功能建模：用例图（静态描述系统功能范围）。

作用：
描述系统的“骨架”和功能边界。
不涉及时间或流程，仅聚焦“是什么”（What）。

2. 动态建模（Dynamic Modeling）

对应面向对象建模：行为建模。
核心图表：时序图、状态图、活动图、协作图。
作用：
描述系统的“行为”和“流程”，即“如何工作”（How）。
分析对象协作、状态流转和业务流程

1.建模的必要性

捕获商业流程

促进沟通

管理复杂性

定义软件架构

促进软件复用

2.RUP统一过程

Rational Unified Process（RUP） 是一种基于迭代和增量开发的软件工程过程框架，由Rational公司（现属IBM）提出，结合了统一建模语言（UML）和最佳实践，适用于中大型复杂项目的全生命周期管理。

一、 核心特点

迭代与增量开发
将项目分解为多个迭代周期（通常2-6周），每个迭代交付部分功能。

用例驱动
以用户需求（用例）为核心驱动设计和开发。

架构为中心
强调早期定义系统架构以降低技术风险。

风险优先
高风险需求在早期迭代中优先处理。

可配置性
支持根据项目规模裁剪流程（如敏捷化轻量版本）。

二、 四个阶段

每个阶段包含多个迭代，最终产出物为 里程碑文档 和 可运行版本。

三、 六大核心工作流

RUP 在每个阶段中贯穿以下工作流（Activities），确保全面覆盖开发活动：

业务建模（Business Modeling）
分析业务流程，确保系统与业务目标对齐。

需求（Requirements）
捕获和管理用户需求（用例、非功能性需求）。

分析与设计（Analysis & Design）
将需求转化为系统架构和详细设计（UML类图、时序图）。

实现（Implementation）
编码、单元测试和持续集成。

测试（Test）
系统测试（性能、安全、功能）和缺陷跟踪。

部署（Deployment）
安装、配置和交付产品，支持用户迁移。

四、 优缺点

五、 适用场景

大型企业系统（如ERP、金融核心系统）。
高可靠性要求的领域（航空航天、医疗设备）。
需要严格合规性（如政府或军工项目）。

六、 RUP 与敏捷开发对比

七、总结

RUP 通过分阶段迭代和架构优先的策略，为复杂项目提供了系统化的管理框架。尽管其流程复杂度较高，但在需要高可靠性和严格控制的场景中仍具有不可替代性。对于追求灵活性的团队，可结合敏捷实践（如 OpenUP 或 敏捷 RUP）实现平衡。

阶段	目标	关键活动
初始阶段 (Inception)	明确项目范围和可行性	- 定义业务需求 - 识别核心用例 - 制定初步商业案例和风险评估。
细化阶段 (Elaboration)	建立系统架构和解决高风险问题	- 细化需求（80%用例） - 设计可扩展架构 - 验证技术方案。
构建阶段 (Construction)	完成系统开发并达到可部署状态	- 迭代开发剩余功能 - 持续集成与测试 - 准备用户文档。
交付阶段 (Transition)	确保系统顺利交付并投入使用	- 用户验收测试（UAT） - 修复缺陷 - 培训用户和部署上线。

优点	缺点
1. 降低风险（早期验证架构和需求）。	1. 流程复杂，文档量较大（不适合小型项目）。
2. 高可预测性（阶段和迭代清晰）。	2. 对团队经验和纪律性要求较高。
3. 支持大规模团队协作。	3. 迭代周期可能较长（需严格评审）。

对比项	RUP	敏捷（Scrum/XP）
流程规范性	高度结构化，文档驱动。	轻量级，强调面对面沟通。
迭代目标	每个迭代聚焦架构或功能模块。	每个迭代交付完整用户故事。
适用规模	中大型复杂项目。	中小型快速迭代项目。
变更响应	通过阶段评审控制变更。	拥抱变化，优先级动态调整。

3.拓展机制

构造型（Stereotype）（版型）

定义：为现有 UML 元素赋予新的语义或角色，用 <<stereotype>> 表示。
作用：扩展元素含义，使其适应特定领域（如 <<Service>>、<<API>>）。
示例：

<<Controller>>  
class UserController {  
  + login()  
}

标记值（Tagged Value）

定义：为元素添加自定义属性，格式为 {tag=value}。
作用：补充模型元素的元数据（如版本号、作者、性能要求）。
示例：

class OrderService {  
  {version="1.0", author="Alice"}  
}

约束（Constraint）

定义：定义元素必须满足的规则，用 {constraint} 或 OCL（对象约束语言）表示。
作用：确保模型符合业务逻辑或技术限制。
示例：

class Account {  
  balance: double  
  { balance >= 0 }  
}  //对balance进行约束

用例图

参与者（Actor）
定义：与系统交互的外部角色（人或外部系统），用小人图标表示。
示例：用户、管理员、支付网关、第三方API。

用例（Use Case）
定义：系统提供的具体功能单元，用椭圆形表示。（用户观点）宁粗勿细
示例：用户登录、下单支付、生成报告。

系统边界（System Boundary）
定义：划分系统内部功能和外部参与者的矩形框，框内写系统名称。

关系（Relationships）
关联关系（Association）：参与者与用例之间的直线，表示交互。
包含关系（Include）：用虚线箭头 +<>表示，表示用例必须执行的动作。
示例：支付流程必须包含“验证支付信息”。由基本指向包含

扩展关系（Extend）：用虚线箭头 + <<extend>>** 表示，表示用例的可选分支。由拓展指向基本
示例：用户登录失败时，扩展“找回密码”。

泛化关系（Generalization）：表示参与者或用例的继承关系，用空心箭头表示。
示例：管理员是用户的特殊类型，继承用户的所有用例。由一般指向特殊

绘制步骤：

绘制步骤

识别参与者
谁使用系统？外部系统是否参与交互？硬件设备也是参与者

识别用例
参与者需要完成哪些操作？系统需响应哪些事件？

建立关系
确定用例之间的包含、扩展或泛化关系。

定义系统边界
明确系统内外的功能范围。

类图

类图是 UML 中用于描述系统静态结构的核心图表，主要展示系统中的类、接口、属性、方法以及它们之间的关系。它是面向对象分析和设计（OOAD）的关键工具。

一、 核心元素

1. 类（Class）

表示一类对象的抽象，包含三部分：

类名：首字母大写（如 User）。
属性（Attributes）：对象的特性（如 username: String）。
方法（Operations）：对象的行为（如 login(): Boolean）。

示例：

2. 接口（Interface）

定义行为规范，用 <<interface>> 标记。
示例：

二、 类之间的关系

1. 关联（Association）

定义：类之间的逻辑连接（如用户拥有订单）。
表示：实线箭头（单向）或实线（双向）。可以有方向（拥有关系）也可以只是单纯的关联（朋友）
示例：User ————关联———— Order
**限定关联：**订货（限定产品id）—订货产品线可以修改关联的数量关系

+---------------------+
|       User          |
+---------------------+
| - username: String  |     //-表示static
| - password: String  |     //+表示public
+---------------------+     //#表示protected
| + login(): Boolean  |     //：后面➕返回值类型
| + logout(): void    |
+---------------------+

+---------------------+
| <<interface>>       |
|    Payment          |
+---------------------+
| + pay(amount: double)|
+---------------------+

**关联类：**公司—员工关联类：工作（可以具有属性和方法来介绍）

2. 继承（Generalization）=泛化

定义：父子类的继承关系（如 Admin 继承 User）。
表示：空心三角箭头（从子类指向父类）。
示例：Admin—▷User`

3. 实现（Realization）

定义：类实现接口的行为。
表示：虚线空心三角箭头（从类指向接口）。
示例：CreditCardPayment— - -▷Payment`

4. 依赖（Dependency）

定义：一个类的变化影响另一个类（临时使用，如参数传递）。
表示：虚线箭头（从依赖方指向被依赖方）。
示例：Order — - - -> PaymentService

5. 聚合（Aggregation）

定义：整体与部分的弱关系（部分可独立存在）。
表示：空心菱形箭头（从整体指向部分）。
示例：Department◇————Employee`

6. 组合（Composition）

定义：整体与部分的强关系（部分不能独立存在）。
表示：实心菱形箭头（从整体指向部分）。
示例：Car◆————Engine`

三、 示例场景

电商系统类图片段

关系说明：

User 与 Order 是关联关系（用户创建订单）。
Admin 继承 User（继承关系）。
Order 包含多个 OrderItem（组合关系，订单删除则订单项消失）。
OrderItem 关联 Product（关联关系）。

四、 核心用途

系统设计：明确类之间的职责和交互。
代码生成：可直接转换为面向对象编程语言（如 Java、C#）。
文档化：帮助团队理解系统架构。
需求验证：检查功能是否被完整覆盖。

+----------------+       +----------------+       +----------------+
|     User       |       |     Order      |       |    Product     |
+----------------+       +----------------+       +----------------+
| - userId: int  |       | - orderId: int |       | - productId:int|
| - name: String |       | - total: double|       | - price: double|
+----------------+       +----------------+       +----------------+
| + placeOrder() |       | + calculate()  |       | + getDetails() |
+----------------+       +----------------+       +----------------+
       ▲                       ▲                         ▲
       |                       |                         |
       |                       |          +---------------------+
       |                       +----------|    OrderItem        |
       |                                  +---------------------+
       |                                  | - quantity: int     |
       |                                  +---------------------+
       |                                  | + updateQuantity() |
       |                                  +---------------------+
       |
+-----------------+
|    Admin        |
+-----------------+
| + manageProduct()|
+-----------------+

对象图

对象图是 UML 中用于展示系统在某一时刻的对象实例及其关系的静态结构图，本质上是类图的实例化快照。它通过具体对象的状态和连接，帮助验证类设计的合理性。

一、 核心元素

1. 对象（Object）

定义：类的具体实例，属性具有实际值。
表示：
格式：对象名: 类名（如 user1: User）。
匿名对象可省略对象名（如 :Order）。

示例：

2. 链接（Link）

定义：对象之间的临时关系，对应类图中的关联关系。
表示：实线连接对象，可标注角色名（如 customer）。
示例：user1: User——————order1: Order`

二、 对象图 vs 类图

三、 核心作用

验证类图：检查类之间的关系是否合理（如关联是否可实例化）。
调试场景：展示特定操作后的对象状态（如订单支付后的库存变化）。
文档化示例：为复杂类图提供具体实例说明。

四、 示例场景

在线购物系统的对象图片段

说明：

user1 与 order1 存在链接（对应类图中 User 和 Order 的关联）。
order1 包含 item1（组合关系，对应类图中的 Order 和 OrderItem）。
item1 链接到 product1（对应类图中的关联）。

五、 绘制步骤

确定场景：选择一个具体操作或状态（如“用户下单后”）。
实例化对象：为涉及的类创建对象并赋值属性。
建立链接：根据类图的关联关系连接对象。
标注细节：添加属性值和角色名（可选）。

+---------------------+
|   user1: User       |
+---------------------+
| username = "Alice"  |
| password = "*****"  |
+---------------------+

对比项	类图（Class Diagram）	对象图（Object Diagram）
抽象层级	描述抽象类型（类、接口）	描述具体实例（对象及其值）
关系类型	关联、继承、组合等	仅展示对象间的链接（关联的实例化）
时间性	静态结构，不依赖时间	系统在某一时刻的快照
主要用途	设计系统架构	验证类设计、调试或文档化具体场景

+---------------------+       +---------------------+
|   user1: User       |       |   order1: Order     |
+---------------------+       +---------------------+
| username = "Alice"  |       | orderId = 1001     |
| password = "*****"  |       | total = 299.99     |
+---------------------+       +---------------------+
          |                             ▲
          |                             |
          |             +---------------------+
          +-------------|   item1: OrderItem  |
                        +---------------------+
                        | productId = "P123" |
                        | quantity = 2       |
                        +---------------------+
                                  |
                        +---------------------+
                        |   product1: Product |
                        +---------------------+
                        | name = "Laptop"     |
                        | price = 1499.99     |
                        +---------------------+

包图

包图是 UML 中用于描述系统模块化结构的图表，通过“包”（Package）组织相关元素（如类、用例、组件等），展示模块间的依赖关系和层次结构。它适用于管理大型系统的复杂性和模块化设计。

一、 核心元素

1. 包（Package）

定义：逻辑分组容器，包含类、接口、子包等元素。
表示：文件夹图标 + 包名，或直接使用 <>标记。

2. 依赖关系（Dependency）

定义：一个包的变化可能影响另一个包。
表示：虚线箭头（从依赖方指向被依赖方）。
Payment — —> Order

3. 导入关系（Import）

定义：允许一个包直接访问另一个包内的公共元素。
表示：虚线箭头 +<>WebUI — — —> <> Order

4. 合并关系（Merge）

定义：合并两个包的内容，用于版本控制或扩展。
表示：虚线箭头 +<>OrderV2 — — —><> OrderV1

5. 嵌套关系（Nested Package）

定义：包内包含子包，形成层次结构。
表示：父包内直接绘制子包。

二、 核心用途

模块化管理：将系统拆解为高内聚、低耦合的模块。
依赖可视化：明确包之间的调用关系，避免循环依赖。
分层设计：支持分层架构（如 MVC 分层）。
团队协作：划分团队职责（如前端包、后端包）。

三、 示例场景

在线购物系统的包图

说明：

WebUI 包依赖 Order 和 Payment 包。
Order 包依赖 Inventory 包（检查库存）。
Payment 包独立，可复用。

四、 绘制步骤

识别模块：根据功能或职责划分包（如用户管理、订单处理）。
定义依赖：确定包之间的调用关系（如前端依赖后端接口包）。
嵌套子包：复杂模块可进一步拆分为子包（如 Order 包含 Shipping）。
标注关系：添加 <<import>> 或 <<merge>> 等标记。

+-----------------+
|   <<package>>   |
|    Order        |
+-----------------+

+-----------------+
|   <<package>>   |
|    System       |
|  +------------+ |
|  |  Database  | |
|  +------------+ |
+-----------------+

+-----------------+        +-----------------+
|   <<package>>   |        |   <<package>>   |
|    WebUI        |<— — —  |    Order        |
+-----------------+        +-----------------+
       ^                          ^
       |                          |
       |                          |
+-----------------+        +-----------------+
|   <<package>>   |        |   <<package>>   |
|    Payment      |        |    Inventory    |
+-----------------+        +-----------------+

顺序图

顺序图是 UML 中用于描述对象间交互时序的动态行为图，重点展示在特定场景下，对象之间消息传递的时间顺序和流程控制。它是分析系统运行时行为的核心工具。

一、 核心元素

1. 参与者（Actor）

系统外部触发交互的角色（如用户、外部服务），用小人图标表示。

2. 对象（Object）

参与交互的实例，格式为 对象名: 类名（如 user: User）。
匿名对象可省略对象名（如 :OrderService）。

3. 生命线（Lifeline）

对象下方的垂直虚线，表示对象的存活时间。

4. 激活条（Activation Bar）

生命线上的矩形条，表示对象处理消息的时间段。

5. 消息（Message）

对象间的通信内容，分为以下类型：

6. 组合片段（Combined Fragments）

表示条件、循环、并行等逻辑，用方框包裹，左上角标注类型：
alt：条件分支（类似 if-else）。
opt：可选分支（类似 if）。
loop：循环（指定循环次数或条件）。
par：并行执行。
ref：引用其他顺序图片段。

二、 绘制步骤

确定场景：选择一个具体用例或功能流程（如用户登录）。
识别对象：列出参与交互的对象和参与者。
排列对象：水平放置对象，左侧为触发者（如用户）。
添加消息：按时间顺序从上到下绘制消息箭头。
控制流程：使用组合片段处理分支或循环。
优化布局：调整生命线长度和消息对齐。

三、 示例场景

用户登录顺序图

说明：

用户向登录页面发送“输入账号密码”消息（同步）。
登录页面调用认证服务的“验证请求”（同步）。
认证服务返回“验证通过”（返回消息）。
登录页面返回“显示主页”结果（返回消息）。

消息类型	箭头样式	说明
同步消息	实线 + 实心箭头头	发送方等待接收方处理完成
异步消息	实线 + 开放箭头头	发送方不等待接收方响应
返回消息	虚线 + 开放箭头头	表示方法返回值或响应
自关联消息	箭头指向自身生命线	对象调用自身方法
创建消息	虚线箭头 + `<<create>>`	动态创建对象
销毁消息	实线箭头 + `<<destroy>>`	标记对象生命线终止

用户          :登录页面          :认证服务
   |               |                   |
   | 输入账号密码   |                   |
   |-------------->|                   |
   |               | 验证请求          |
   |               |------------------>|
   |               |       验证通过     |
   |               |<------------------|
   | 显示主页       |                   |
   |<--------------|                   |

协作图（通信图）

协作图（现称通信图，Communication Diagram）是 UML 中用于描述对象间动态协作关系的图表，重点关注对象之间的消息传递路径和结构链接。与顺序图不同，协作图更强调对象间的连接结构而非严格的时间顺序。（协作图可以直接由顺序图转换而来）

一、 核心元素

1. 对象（Object）

表示参与交互的实例，格式为 对象名: 类名（如 user: User）。
匿名对象可省略对象名（如 :OrderService）。

2. 链接（Link）

对象间的关联关系，用实线连接（如 user ———— order）。
可标注角色名（如 customer）或关联类型（如 <<association>>）。

3. 消息（Message）

对象间传递的操作请求，包含以下信息：
消息内容（如方法调用、信号传递）。
消息顺序：通过数字序号表示（如 1.1, 1.2）。
消息类型：同步（实心箭头）、异步（开放箭头）、返回（虚线箭头）。

4. 序号（Sequence Number）

表示消息的执行顺序，支持嵌套结构（如 1, 1.1, 1.2）。

二、 协作图 vs 顺序图

三、 核心用途

结构可视化：展示对象间协作的静态连接关系。
消息路径分析：明确消息传递的路径和依赖。
设计验证：检查对象职责分配是否合理。
调试辅助：追踪复杂交互中的消息传递问题。

四、 示例场景

用户登录协作图

说明：

对象包括 用户、登录页面、认证服务、数据库。
消息通过序号 1, 1.1, 1.1.1 表示嵌套调用顺序。

五、 绘制步骤

识别对象：确定参与交互的所有对象。
建立链接：绘制对象间的关联连线。
添加消息：标注消息内容和序号。
优化布局：调整对象位置以清晰展示路径。

对比项	协作图（Communication Diagram）	顺序图（Sequence Diagram）
核心焦点	对象间的连接结构与消息路径	消息传递的时间顺序
布局方式	对象自由排列，链接通过连线表示	对象水平排列，消息垂直分布
适用场景	强调对象协作的拓扑关系	强调流程时序与步骤控制

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

活动图

活动图是 UML 中用于描述业务流程或系统工作流的动态行为图，强调活动之间的流程顺序、并行分支和条件控制。它适用于分析复杂流程的逻辑结构，常用于业务建模和算法设计。

一、 核心元素

1. 节点类型

2. 连接关系

二、 活动图 vs 流程图

三、 核心用途

业务流程建模：分析用户注册、订单支付等场景的完整流程。
并行任务设计：描述多线程或分布式系统中的并发操作。
需求文档化：将非结构化需求转化为可视化流程。
错误处理设计：通过异常路径处理流程中断或失败。

四、 示例场景

用户登录活动图

元素	符号	说明
初始节点	●（实心圆）	表示流程的起点。
活动节点	▒（圆角矩形）	表示一个具体活动（如 `输入密码`）。
判断节点	◇（菱形）	表示条件分支（类似 `if-else`）。
合并节点	◇（菱形，无分支线）	合并多个分支路径。
分叉/汇合节点	─（水平/垂直线条）	分叉表示并行开始（如 `同时处理订单和库存`），汇合表示并行结束。
结束节点	◎（带圆圈的实心圆）	表示流程终止。
对象节点	▭（矩形，标注对象名）	表示流程中使用的数据对象（如 `订单信息`）。
泳道	▯（垂直或水平分区）	按角色或模块划分责任区域（如 `用户`、`系统`）。

关系类型	符号	说明
控制流	→（实线箭头）	表示活动之间的执行顺序。
对象流	⇥（虚线箭头 + 对象节点）	表示活动与数据对象的关系（如 `生成报告 → 报告文件`）。

对比项	活动图	传统流程图
核心目标	描述业务流程的并行、分支和协作	描述算法或程序的线性步骤
并行支持	支持分叉/汇合表示并行	不支持并行
适用场景	业务建模、复杂系统工作流	简单算法、代码逻辑设计
元素丰富度	包含泳道、对象节点、中断等高级元素	仅基础节点（开始、结束、判断、步骤）

●（开始）  
↓  
[输入用户名和密码]  
↓  
◇ 验证是否合法？  
├─ 合法 → [跳转主页] → ◎（结束）  
└─ 不合法 → [显示错误] → ◇  
               ├─ 重试 → 返回[输入用户名和密码]  
               └─ 取消 → ◎（结束）

组件图

组件图是 UML 中用于描述系统模块化物理结构的静态建模图表，聚焦于组件（可独立部署的功能单元）及其接口、依赖关系和协作方式。它适用于微服务架构、分布式系统或软件库的设计。

一、 核心元素与符号

1. 组件（Component）

定义：系统的模块化单元，可独立编译、部署和替换（如微服务、库文件、API 模块）。
符号：
左上角可添加组件图标（双矩形或齿轮符号）。

2. 接口（Interface）

提供接口（Provided Interface）：组件对外暴露的服务，用“棒棒糖”符号（○）表示。
请求接口（Required Interface）：组件依赖的外部服务，用“插座”符号（◉）表示。
示例：

3. 端口（Port）

定义：组件的通信端点，用于连接内部功能与外部接口。
符号：组件边界上的小矩形框。
示例：

4. 依赖关系（Dependency）

符号：虚线箭头（从依赖方指向被依赖方）。
示例：OrderService ·- - - -> InventoryService

5. 组合关系（Composition）

定义：表示组件间的包含关系（如父组件包含子组件）。
符号：实线箭头 + 实心菱形（◆）。
示例：OrderSystem ◆──── OrderService

二、 应用场景

微服务架构设计：
展示服务间的接口协议（如 REST API、gRPC）。
示例：UserService 提供 Auth 接口，OrderService 依赖该接口。

软件库/模块管理：
描述库文件（.jar、.dll）的依赖关系。
示例：Utils 库被 PaymentModule 和 InventoryModule 依赖。

系统部署规划：
结合部署图（Deployment Diagram）明确组件在物理节点上的分布。

三、 示例：电商系统组件图

plaintext

说明：

OrderService 提供 PaymentInterface 接口，PaymentService 实现该接口。
OrderService 依赖 InventoryService 检查库存。

四、 绘制步骤

识别组件：根据功能划分模块（如用户管理、支付、日志）。
定义接口：明确组件提供的服务（API）和依赖的外部服务。
建立关系：连接接口和依赖关系，避免循环依赖。
优化布局：按逻辑分层（如前端组件、后端服务、第三方集成）。

+---------------------+
| <<component>>       |
|    OrderService     |
+---------------------+

OrderService ○── PaymentInterface  
PaymentService ◉── PaymentInterface

+---------------------+
| [port] OrderService |
+---------------------+

+---------------------+          +---------------------+
| <<component>>       |          | <<component>>       |
|   OrderService      ○─────┐    |   PaymentService    |
+---------------------+     │    +---------------------+
  |                         │           ◉
  | 依赖                     │           │ 实现
  ▼                         │           ▼
+---------------------+     │    +---------------------+
| <<component>>       |     └────┤ PaymentInterface   │
|   InventoryService  |          +---------------------+
+---------------------+

案例：学生信息管理系统

总结流程

需求分析：用例图定义功能。
结构设计：类图建模数据关系。
动态建模：时序图/活动图描述流程。
物理架构：部署图/组件图规划部署。

1. 需求阶段：用例图（Use Case Diagram）

目标：明确系统功能范围和用户角色。
示例元素：

参与者：学生、教师、管理员。
用例：
学生：查看成绩、选课。
教师：录入成绩、发布课程。
管理员：管理学生信息、管理课程。

先画总用例图，再根据功能对用例进行细分画子用例图

2. 结构设计：类图（Class Diagram）

目标：定义系统核心类及其关系。
关键类：

Student（学生）：属性包括学号、姓名、班级。
Course（课程）：属性包括课程编号、名称、学分。
Grade（成绩）：关联学生和课程，记录分数。

关系：

学生与课程：多对多（通过选课关联）。
课程与成绩：一对多（一门课程有多个成绩记录）。

3. 动态行为：时序图（Sequence Diagram）

场景：学生查看成绩流程。
对象交互：

学生向系统发起查看成绩请求。
系统验证学生身份。
数据库返回成绩数据。
系统向学生展示成绩列表。

4. 流程逻辑：活动图（Activity Diagram）

场景：学生选课流程。
步骤：

学生登录系统。
浏览可选课程列表。
选择课程并提交。
系统检查课程容量。
选课成功或失败反馈。

5. 系统部署：部署图（Deployment Diagram）

目标：描述系统物理部署结构。
节点：

Web服务器：运行前端和业务逻辑。
数据库服务器：存储学生、课程、成绩数据。
客户端：学生/教师通过浏览器访问。

6. 模块划分：组件图（Component Diagram）

目标：展示系统模块化结构。
组件：

用户界面：处理交互。
认证模块：管理登录和权限。
数据访问层：连接数据库。

学生 —— 查看成绩  
学生 —— 选课  
教师 —— 录入成绩  
教师 —— 发布课程  
管理员 —— 管理学生信息  
管理员 —— 管理课程

+----------------+       +----------------+       +----------------+
|   Student      |       |    Course      |       |    Grade       |
+----------------+       +----------------+       +----------------+
| - studentId    |       | - courseId     |       | - studentId    |
| - name         |       | - name         |       | - courseId     |
| - class        |       | - credit       |       | - score        |
+----------------+       +----------------+       +----------------+
        ▲                         ▲                         ▲
        | 1                       | 1                       | 1
        | *                       | *                       | *
+----------------+       +----------------+       +----------------+
|  Enrollment    |       |  Assignment    |       |  ScoreRecord   |
+----------------+       +----------------+       +----------------+

学生 -> 系统: 查看成绩请求  
系统 -> 认证服务: 验证身份  
认证服务 -> 数据库: 查询学生信息  
数据库 --> 认证服务: 返回结果  
认证服务 --> 系统: 身份有效  
系统 -> 数据库: 查询成绩  
数据库 --> 系统: 返回成绩数据  
系统 --> 学生: 显示成绩列表

● 开始  
↓  
[登录系统]  
↓  
[浏览课程列表]  
↓  
[选择课程] → [提交选课]  
↓  
◇ 课程是否已满？  
├─ 未满 → [选课成功] → ◎ 结束  
└─ 已满 → [选课失败] → ◎ 结束

+----------------+       +----------------+  
|   Web服务器    | <--> | 数据库服务器   |  
+----------------+       +----------------+  
       ↑  
       | HTTP  
       ▼  
+----------------+  
|    客户端      |  
+----------------+

+----------------+       +----------------+  
|  用户界面      | ----> | 认证模块       |  
+----------------+       +----------------+  
       ↓  
+----------------+  
| 数据访问层     |  
+----------------+

四、面向对象方法学

1.基本概念

**对象：**具有相同状态的一组操作的集合（是对属性值和操作的封装）

**类：**具有相同数据和相同操作的一组相似对象的集合。类是支持继承的抽象数据类型，而对象是类的实例

**实例：**由某个特定的类所描述的一个具体的对象

**消息：**要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明

三部分：

接受消息的对象

消息名

零个或者多个变元

例：

MyCircle.Show(GREEN)

**方法：**对象所能执行的操作，类中定义的服务

**属性：**对客观世界实体所具有的性质的抽象，类中所定义的数据

**封装：**把数据和实现操作的代码集中起来放在对象的内部，外界只需知道接口，无需知道细节

**继承：**能够直接获得已有的特质和性质，子类自动的共享基类中定义的数据和方法的机制

**多态：**在类的等级的不同层次中可以共享一个行为的名字，不同层次的每一个类都按照自己的需要来实现这个类

c++中通过虚函数来实现

Java中通过普通的方法重写和抽象方法（基类不做定义，子类必须重新实现）abstract

增加了面向对象软件系统的灵活性，提高了软件的可重用性和可扩展性

**重载：**函数重载：在同一作用域内若干个参数特征不同的函数可以使用相同的函数名字

   运算符重载：同一个运算符可以施加在不同类型的操作数上

2.面向对象建模

结构建模（Structural Modeling）
- 目标：定义系统的静态结构（如类、对象、组件及其关系）。
- 核心工具：类图、对象图、组件图、包图。
- 示例：通过类图描述电商系统的 User、Order、Product 等类的属性和关联。
行为建模（Behavioral Modeling）
- 目标：描述对象间的动态交互和状态变化。
- 核心工具：时序图、状态图、活动图、协作图。
- 示例：用时序图展示用户下单时 User、OrderService、PaymentService 的消息传递顺序。
功能建模（Functional Modeling）
- 目标：定义系统的功能需求和用户交互场景。
- 核心工具：用例图。
- 示例：通过用例图表示用户可执行的操作（如“登录”、“支付”）。

协同关系

步骤示例：
阶段 1（功能建模）：用用例图明确系统功能（如“用户注册”、“商品搜索”）。
阶段 2（结构建模）：用类图设计 User、Product 等类的属性和关系。
阶段 3（行为建模）：用时序图描述“用户注册”流程中对象间的消息调用。

工具协作：
静态模型（用例图、类图）为动态模型（时序图）提供上下文和对象定义。
动态模型 验证静态模型是否满足功能需求（如类的方法是否支持交互流程）。

面向对象建模类型	UML 建模类型	核心 UML 图表	关键目标
结构建模	静态建模	类图、组件图、包图	定义类、组件及其静态关系
功能建模	静态建模	用例图	描述系统功能需求和用户交互场景
行为建模	动态建模	时序图、状态图、活动图	描述对象交互、状态变化和流程逻辑

五、软件测试

1.测试基础

测试目的：

测试是为了发现错误而执行程序的过程
好的测试方案是尽可能的发现迄今为止尚未发现的错误的测试方案
成功的测试是发现了目前为止尚未发现的错误的测试

测试不能证明程序是正确的

测试方法：

黑盒测试：知道了产品应该具有的功能，通过测试是否每个功能都能正常使用

白盒测试：知道了产品的内部工作过程，通过测试来检验产品内部动作是否按照规格说明书的规定正常运行

测试准则：

所有的测试都应该能追溯到用户需求
测试开始之前就应该制定测试计划（尽早的不断的测试，不可视为独立模块，应该贯穿全程）
运用Pareto原理（80%的错误来自于20%的模块）
小规模测试开始逐步到大规模测试
穷举测试是不可能的
为了达到最佳的测试效果，应该由独立的第三方从事测试工作

2.白盒测试

1.逻辑覆盖

语句覆盖
每个可执行语句至少执行一次

语句覆盖只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值时的情况

判定（分支）覆盖

每个判定的结果都至少执行一次（每次只能覆盖到一半的测试用例）

对于两个if语句，需设计至少两个测试用例（如ace和abd路径）覆盖所有分支

条件覆盖

每个语句至少执行一次，判定表达式中的每个条件取不同的结果

一个判定通常包含多个条件

条件覆盖不一定可以实现判定覆盖，判定覆盖也不一定实现条件覆盖

判定-条件覆盖

同时满足判定覆盖和条件覆盖

设计用例覆盖每个条件的取值，并确保每个判定的真假分支均被执行

对条件进行拆分，并保证判定执行结果不一致

条件组合覆盖

每个判定结果的各种组合都至少出现一次（对条件做笛卡尔积）

满足条件组合覆盖的不一定实现路径覆盖

路径覆盖

每条可能路径都至少执行一次

不一定满足条件组合覆盖

2.控制结构测试

基本路径测试

根据过程设计结果画出对应的流图
计算环形复杂度
确定独立路径的集合
设置满足路径集合的用例

计算环形复杂度方法：（将程序流程图映射成流图）

线性无关的区域数
边数—节点数+2
判定节点的数目+1

从开始到结束，每次至少新增一条在定义该路径之前没有使用过的边，规定了集合中数目，有不同的组合

某些独立路径不能以独立的方式测试，必须作为另一个测试的一部分来测试

循环测试

简单循环
跳过循环
循环一次
循环两次
循环m次
循环n-1，n，n+1次

嵌套循环
最内层开始测试，外层设为最小值
逐步向外扩，内层设为常规值，外层设为最小值

串接循环

3.黑盒测试

着重测试软件功能

1.等价类划分

原则

输入条件规定范围，可以划分为一个有效（在范围内），两个无效（不在范围内）
输入条件是boolean，一个有效，一个无效
输入是一组数，每个输入值有一有效等价类，针对这组值有一无效等价类
输入数据遵守规则，一个有效等价类（遵守规则）若干无效等价类（不遵守）
已划分等价类各元素在处理方式上各不相同，可以将等价类进行进一步划分

建立测试用例

建立等价类表，列出所有划分出的等价类

输入条件	有效等价类	无效等价类
…	…	…

为每一个等价类规定唯一的编号
设计测试用例，尽可能多的覆盖有效等价类，直到所有有效等价类被覆盖掉
设计新的测试用例，仅覆盖一个无效等价类，直到所有的无效等价类被覆盖掉

2.边值分析法

处理边界情况最容易发生错误

选取的测试数据应该刚好等于，刚好小于和刚刚大于边界值

3.错误推测法

已经发现的错误数目往往和尚未发现的错误数成正比，进一步测试时要着重测试那些已经发现了较多错误的程序段

等价划分和边界值分析都只孤立的考虑各个输入数据的测试功效，没有考虑多个数据的组合效应，利用判定表和判定树

4.测试策略

1.单元测试

着重测试的五个方面：

模块测试
局部数据结构
重要的执行通路
出错处理通路
边界条件

测试方法：

代码审查
计算机测试必须为每个单元测试开发驱动软件（主程序）和存根软件（虚拟子程序）

2.集成测试

发现接口有关问题

非渐增式对每一个模块进行单元测试，再把所有模块结合起来进行测试
渐增式把程序划分为小段来构造和测试

自顶向下从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来（采用DFS或者BFS）
自底向上测试从原子模块开始组装和测试不需要存根程序，可以明显减少驱动程序的数目，族的结合也将大大简化
混合策略
改进的自顶向下测试方法基本用自顶向下方法，早期用自底向上测试关键模块
混合法软件结构上层模块用自顶向下，下层用自底向上

维度	自顶向下（Top-Down）	自底向上（Bottom-Up
优点	1. 早期验证核心逻辑和接口。 2. 优先暴露高层设计缺陷。 3. 无需驱动模块。	1. 优先验证底层功能。 2. 减少桩模块开发量。 3. 支持并行测试。
缺点	1. 需要大量桩模块模拟下层功能。 2. 底层测试延迟，可能遗漏细节缺陷。	1. 需要驱动模块模拟上层调用。 2. 高层接口验证滞后。
适用场景	1. 核心功能需优先验证。 2. 架构稳定且需求明确。 3. 底层接口未定义或频繁变更。	1. 底层模块成熟度高。 2. 高层接口可能调整。 3. 需要快速迭代底层组件。
工具需求	需开发桩模块（Stub）模拟下层逻辑。	需开发驱动模块（Driver）模拟上层调用逻辑。
故障定位	高层错误易定位，底层错误需依赖桩模块的准确性。	底层错误易定位，高层错误需依赖驱动模块的覆盖性。
进度可见性	早期可见系统整体框架，用户体验流程优先。	系统完整功能需最后阶段验证，底层功能稳定优先。

集成测试后要回归测试

重新执行已作过测试的某子集，保证变化没带来非预期副作用。

3.系统测试

恢复测试
安全性测试
强度测试
性能测试

4.验收（确认）测试

确认测试以需求规格说明书为测试基础；采用黑盒法。

**α测试：**用户对即将上市的软件产品（称α版本）进行测试，开发者坐在用户旁边，随时记下错误情况和使用中问题，是受控环境下测试。目的：评价软件功能、可使用性、可靠性、性能、界面
**β测试：**多个用户在实际使用环境下进行的测试用户与公司签定支持产品预发行合同，使用产品，并返回错误信息。是在开发者无法控制的环境下进行的软件现场应用。目的：产品的支持性。

5.调试

软件调试是在进行了成功的测试之后才开始的工作。

它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。

好的，我现在需要回答用户关于CMM概念和五个级别的问题。首先，我得仔细看看用户提供的搜索结果，从中提取相关信息。

首先，用户的问题是关于CMM（能力成熟度模型）的概念和五个级别。根据搜索结果，网页1、2、3、4、5、6、7、8都提到了相关内容，但需要筛选出最相关的部分。

概念部分：网页1提到CMM是软件过程能力成熟度模型，由卡内基梅隆大学SEI于1986年开始研究，1991年推出1.0版。网页3的定义更详细，指出CMM用于评估和改进软件过程能力，分为五个等级。网页4也给出了类似的定义，强调过程管理和改进。网页6的搜狗百科和网页5的CSDN博客也有相关描述。所以概念部分可以综合这些来源，特别是网页1、3、4、6。

五个级别：各个级别在多个网页中都有详细描述。网页3提到初始级、可重复级、已定义级、已管理级和优化级。网页4详细描述了每个级别的特点，比如初始级无序，可重复级能重复成功经验，已定义级标准化，已管理级量化管理，优化级持续改进。网页6的搜狗百科和网页5也有类似的级别划分，但可能用词略有不同。需要确认每个级别的名称和描述是否一致。例如，网页6提到第五级是优化级，而网页7的CMMI5对应持续优化。需要注意的是，有些网页可能提到的是CMMI，但用户问的是CMM，所以应区分两者。不过，网页4和6明确指出CMM的五个级别，所以可以主要参考这些来源。

此外，网页4还提到每个级别的关键过程域，比如初始级没有KPA，可重复级包括需求管理、项目计划等。但用户问题可能不需要详细到每个级别的KPA，而是需要级别名称和简要描述。因此，在回答时，应简明扼要地列出五个级别及其核心特征，并引用相关网页。

还需要注意时间因素，比如网页3提到CMM的发展历程，包括后续的CMMI，但用户的问题可能更关注原始CMM的五个级别。因此，在回答中应明确说明CMM的五个级别，可能附带提及CMMI作为后续发展，但重点放在CMM本身。

总结下来，概念部分可以整合网页1、3、4、6的信息，五个级别则主要参考网页3、4、6的描述，确保准确性和全面性。同时，注意引用多个网页，避免重复引用同一来源，例如每个级别可以引用不同的网页来支持。

CMM（Capability Maturity Model，能力成熟度模型）是由美国卡内基梅隆大学软件工程研究所（SEI）于1987年提出的软件过程评估与改进框架。其核心目标是通过标准化流程管理，帮助组织提升软件开发能力、控制项目风险并提高产品质量。CMM将软件过程能力划分为五个成熟度级别，每个级别代表组织在过程管理和持续改进方面的不同水平：

五个成熟度级别

初始级（Initial）
• 特点：软件过程无序且不可预测，依赖个人能力而非系统化管理，项目易受危机影响。
• 问题：缺乏文档化流程，进度和成本难以控制，质量波动大。
可重复级（Repeatable）
• 特点：建立基本项目管理流程（如需求管理、计划跟踪），能复用以往成功经验。
• 关键实践：项目计划（PP）、配置管理（CM）、质量保证（QA）等。
已定义级（Defined）
• 特点：组织范围内形成标准化的软件过程（SOP），流程文档化并通过培训统一执行。
• 改进点：集成项目管理（IPM）、需求开发（RD）、技术解决方案（TS）等。
已管理级（Managed）
• 特点：引入量化管理，通过数据（如缺陷率、生产率）控制过程性能并预测结果。
• 核心能力：量化项目管理（QPM）、过程性能分析（OPP）。
优化级（Optimizing）
• 特点：持续改进成为组织文化，通过技术创新和缺陷预防实现过程优化。
• 关键活动：因果分析（CAR）、技术革新管理（OPM）。

CMM的应用与发展

• 应用领域：最初聚焦软件开发，后扩展至IT服务、系统工程、业务流程优化等领域。
• CMMI演进：2000年后，CMM升级为集成化模型CMMI（Capability Maturity Model Integration），融合多学科最佳实践，支持更灵活的过程改进路径。

CMM的五个级别为组织提供了逐步改进的路线图，通过标准化和量化管理，最终实现高效、可预测的软件开发能力。截至2025年，全球已有数千家企业通过CMM/CMMI认证，中国部分企业（如华为、东软）也达到高成熟度级别。

软件工程—研究生复试 (1)

软件工程—notebook

一、基本概念

1.软件危机

2.软件工程

3.软件工程方法学

4.软件的生命周期：

5.软件维护

6.软件过程

课后题

二、结构化分析

1.可行性研究

2.需求分析的任务

3.具体步骤

4.实体联系图

5.数据流图

6.数据字典

1.定义方法

2.定义符号

7.状态转换图

三、结构化设计

1.概念和原理

2.模块独立

3.面向数据流设计

三、UML（统一建模语言）

1. 静态建模（Static Modeling）

2. 动态建模（Dynamic Modeling）

1.建模的必要性

2.RUP统一过程

一、 核心特点

二、 四个阶段

三、 六大核心工作流

四、 优缺点

五、 适用场景

六、 RUP 与敏捷开发对比

七、 总结

3.拓展机制

用例图

绘制步骤

类图

一、 核心元素

1. 类（Class）

2. 接口（Interface）

二、 类之间的关系

1. 关联（Association）

2. 继承（Generalization）=泛化

3. 实现（Realization）

4. 依赖（Dependency）

5. 聚合（Aggregation）

6. 组合（Composition）

三、 示例场景

电商系统类图片段

四、 核心用途

对象图

一、 核心元素

1. 对象（Object）

2. 链接（Link）

二、 对象图 vs 类图

三、 核心作用

四、 示例场景

在线购物系统的对象图片段

五、 绘制步骤

包图

一、 核心元素

1. 包（Package）

2. 依赖关系（Dependency）

3. 导入关系（Import）

4. 合并关系（Merge）

5. 嵌套关系（Nested Package）

二、 核心用途

三、 示例场景

在线购物系统的包图

四、 绘制步骤

顺序图

一、 核心元素

1. 参与者（Actor）

2. 对象（Object）

3. 生命线（Lifeline）

4. 激活条（Activation Bar）

5. 消息（Message）

一、核心特点

二、四个阶段

三、六大核心工作流

四、优缺点

五、适用场景

七、总结

一、核心元素

二、类之间的关系

三、示例场景

四、核心用途

一、核心元素

二、对象图 vs 类图

三、核心作用

四、示例场景

五、绘制步骤

一、核心元素

二、核心用途

三、示例场景

四、绘制步骤

一、核心元素

二、绘制步骤

三、示例场景

一、核心元素

二、协作图 vs 顺序图

三、核心用途

四、示例场景

五、绘制步骤

一、核心元素

二、活动图 vs 流程图

三、核心用途

四、示例场景

一、核心元素与符号

二、应用场景

三、示例：电商系统组件图

四、绘制步骤