150h速成软件工程

#开始写的时候就已经没有150h了
这书怎么这么厚

---

$Chapter1$
1.软件的组成
软件=知识+程序+数据+文档

2.生存周期
软件从概念形成、进化、运行到退役的全过程。
需求->设计->编码调试->软件测试->运行维护->退役

3.软件工程定义
将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程和上述方法的研究

4.软件过程模型

1. 瀑布模型：
   也称生存周期模型。可以分解为可行性研究、软件需求、设计、编码与调试、测试、运行与维护、退役几个阶段。
   优点：
   适应单主机计算模式下的软件开发过程
   缺点：
   规模不能太大 需求要明确 上层缺陷会误导下层的开发

2. 增量过程模型：
   开发人员与用户协商将需求分解，划分为一系列增量，并为增量排序，急需的增量摆在前面先开发，不急需的放在后面。
   优点：
   a.软件开发过程中，按照增量持续不断地发布软件新版本，可及时获得客户的反馈，用于调整后续的软件开发策略
   b.由于软件需求是确定的，可先对软件体系结构进行设计，增量开发过程能保持良好的软件体系结构
   缺点：
   a.增量规模不能大
   b.将客户需求分解成增量序列必须对系统需求十分了解
   c.处理实现增量比较困难

3. 原型建造模型：
   根据客户要求快速开发一个原型，征求意见的过程中进一步修改完善

4. 螺旋模型：
   是迭代模型。
   每个回路由四个阶段组成:确定目标 风险分析 开发和验证 制定规划
   优点：
   可以边学习、边建模、边开发、边使用、边改进
   缺点：
   由于需求的不确定性，开发初期无法进行软件体系结构设计，多次迭代会导致软件体系结构变坏，为软件理解和维护带来困难

$Chapter2$
1.UML5类图形机制：

1. 用例视图：
   包括用例图。从外部用户的角度描述系统功能，并指出系统参与者

2. 结构视图：
   包括包图、类图和对象图。从不同层面表示系统的静态结构

3. 行为视图：
   包括交互图、状态图和活动图。从不同侧面刻画系统的动态行为

4. 构件视图：
   包括构件图。描述系统各组成构件、构件的内部结构以及构件之间的依赖关系

5. 部署视图：
   包括部署图、它描述软件系统中的各类工件在物理运行环境中的分布情况

2.RUP的五个阶段：
初始、细化、构造、移交、生产

$Chapter3isskipped$

$Chapter4$
1.用例图：
用例间的三个关系：

1. 包含：如果B是A的子功能，且清楚A对应的动作序列何时调动B 则A包含B
2. 扩展：A与B相似，但A的功能较B多，A的动作序列是通过B的动作序列中的某些执行点上插入附加动作序列而构成的 则A扩展B
3. 继承：A与B相似，但A的动作序列是通过改写B的部分动作或扩展B的部分动作而获得的，则A继承B

2.用例驱动的需求获取模型：

• 定义软件问题
• 创建框架用例
• 精化用例
• 评审用例模型

$Chapter5$
1.顺序图

同步消息：发送者等待消息接收对象将消息处理完成后再继续 用实心三角形箭头
异步消息：发送者在发送完消息后不等待接收方即继续自己的处理 用普通箭头

2.通信图

构成元素：

• 节点是参与交互的对象
• 对象之间的连接称为连接器
• 连接器上可以标示一到多条消息，传递方向用小箭头表示

3.状态图

很少画 盲猜不会考

4.分析类

• 边界类：包括界面控制、外界接口和环境隔离。往往附加<<boundary>>作为标识
• 控制类：控制类作为完成用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能或行为。标识<<control>>
• 实体类：负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问的操作，例如日志、异常事件等。标识<<entity>>

5.分析类图

大致的步骤：

• 创建初始的分析类图：根据概念模型和交互图画出初始的分析类图
• 根据消息确定分析类的职责
• 根据消息传递确定分析类之间的连接
• 根据交互图确定分析类的属性

简单地说，就是给类定性，加上属性，之后用某种线把类连接起来。关于箭头和线条可以看传送门 …只会关联其实也能画个差不多了
6.需求规约
目标：

• 便于利益相关方、需求工程师和软件设计人员进行理解和交流
• 支持目标软件系统的确认
• 控制系统进化过程

主要内容：系统概述、功能需求

$Chapter6$
1.软件设计的基本原则：

• 抽象与逐步求精
• 强内聚松耦合
• 信息隐藏
• 关注点分离

2.迭代式设计过程模型
第一层含义：针对给定的需求模型，通过多次从策划到总结的设计流程，得出足够精细的设计模型以供软件实现之用
另一层含义：以并不完整的需求模型作为输入，展开前述意义下的迭代式设计，结果模型交由软件实现人员构件目标软件产品的原型或中间产品；每次需求模型更新完成后再次迭代，直到获得最终的目标软件产品。

$Chapter7$
1.体系结构视图

• 逻辑视图
• 开发视图
• 物理视图
• 运行视图
• 数据视图

2,逻辑体系精化过程

• 搜索并选取可用的设计资产
• 设计技术支撑设施
• 确立设计元素
• 整合设计元素

3.软件复用

• 概念：在多次不同的软件开发过程中重复使用相同或者相似软件园速度过程
• 意义：提高软件生产率、改善软件质量

$Chapter8$
1.界面元素：

1. 静态元素：与运行状态无关的文本、图标、图形、图像等
2. 动态元素：因运行状态而异的内容
3. 用户输入元素：可供用户修改或选择
4. 用户命令元素：点击后触发界面后端某动作

$Chapter9$
1.用例设计的子活动：

1. 设计用例实现方案
2. 构造设计类图
3. 整合并优化用例实现方案

2.类间的连接关系：
语义强度由高到低：继承、组合、聚合、（普通）关联、依赖
原则：强内聚、松耦合

$Chapter10$
1.软件实现的定义：通过程序设计及编码的过程，把软件详细设计映照为计算机可以理解并最终运行的代码
2.软件实现的活动：

• 编写代码
• 单元测试
• 集成测试
• 调试
• 确认

$Chapter11$
1.面向数据流的设计流程

1. 确定信息流的类型
2. 划定流界
3. 将数据流图映射为程序结构
4. 提取层次控制结构
5. 通过设计复审和使用启发式策略进一步精华所得到的结构

2.变换流
输入信息流沿传入路径进入系统，同时由外部形式变换为内部形式，经过加工处理作为输出信息流离开系统。
3.事务流
事务由外部形式转化为内部形式，事务中心根据计值结果从若干动作路径中选定一条继续执行
4.数据流图映射成软件结构

简单来说，拆成输入流控制模块、变换流控制模块和输出流控制模块，然后从倒着画出来原来的结构
参考的博客
blog1
blog2
blog3

$Chapter12$
1.软件测试的概念：
使用人工或自动手段运行软件系统的过程，目的在于检验系统是否满足规定的需求，或确定预期结果与实际结果之间的差异
2.软件测试的过程模型：

3.黑盒测试：

1. 等价分类法
2. 边界值分析法
3. 对比测试法

*设计测试用例

4.单元测试过程：
测试用例的设计应当与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类缺陷的可能性。在确定测试用例的同时，应给出对应的期望结果。
驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印相关结果。桩模块用于替代那些真正附属于被测模块的模块，桩模块的界面与其对应的真实模块完全一致，但内部只做少量数据处理，主要任务是打印“进入——退出”的消息。
5.集成测试：
自顶向下、自底向上

$Chapter13$
1.软件维护的分类：

1. 纠错性维护
2. 适应性维护
3. 完善性维护
4. 预防性维护

2.维护的过程：

$Chapter14$
1.持续集成概念：开发者尽早将自己的阶段性新成果集成至目标软件产品的某个版本，以便尽早暴漏项目中存在的缺陷。
2.持续集成的过程：

1. 构件
2. 单元测试
3. 集成测试
4. 代码质量分析
5. 产品发布
6. 部署

可以将其编排为一种线性或准线性(允许跳过某些步骤)的管道

$Chapter15$
1.软件规模度量方法：

1. 代码行度量
2. 功能点的度量
3. 对象点度量
4. 软件复用的度量 *复用：重复使用

$Chapter16$
1.软件项目管理的原则 10条
2.工程制品集的组成：

1. 需求集
2. 设计集
3. 实现集
4. 实施集

3.基线技术：

• 引入原因：为了有效控制变更
• 基线标志开发过程的各个里程碑，通过复审的软件配置项是构成基线的主要内容，它标志开发过程中一个阶段的结束

---

150h真的能速成吗