软工复习（一）

（来自一个垃圾的瞎瘠薄整理,跪求大佬帮忙指点江山）

第一章 软件工程概述

1.UML

1）功能概述：可视化，规格说明，构造，文档化

2）模型：用例图，活动图，类图，对象图（哭了），顺序图，通信图，时序图，交互概括图，组成结构图，组件图，包图，状态图，部署图

2.软件开发方法

a 面向对象方法：动态的思想，模拟人的思维习惯，方便重用，多次迭代，按类进行划分

b 面向过程方法：静态的思想，缺少灵活性，维护困难，增加系统成本（据说面过比面对快）

c 切片（不考，只是放这里做个对比，相对于面过有了一定的提升）

第二章 模型对比

1. 瀑布模型：每一阶段都明确本阶段要做的事情 ，能够提前发现问题和缺陷。使用与大项目（文档驱动，推迟实现 ）

2. 快速原型模型：快速构造一个软件模型，反复评价和改进模型

3. 喷泉模型：相对于瀑布模型，没有明显的界限，工程中重叠部分很多，同步开发；但工程需要大量人员，加大管理难度和操作难度（迭代，无缝）

4. 螺旋模型：将瀑布模型和快速原型模型结合起来，进行若干次迭代（降低风险）

5. 敏捷生命周期模型：通过增量和迭代过程，让用户使用体验系统，获得有价值的反馈，按顺序和其他需求变化到一起（精确，质量，速度，丰厚的投资回 率，高效的自我管理团队）

1） 增量交付：将程序分成不同组件挨个完成（可以理解为滚雪球）

2） 迭代开发：将程序分为不同程度开发（逐步求精【相当于画画】）

3）极限编程（XP）：注重实践，引入一系列优秀的软件开发方法最为开发时间的指导，并将他们发挥到极致

4）Scrum：注重过程，需求被定义为产品需求积压，分为多个冲刺阶段

5）DevOps：由开发（development）和运维（operations）俩词组成促进开发，技术运营和质量保证部门之间的沟通，协作和整合

第三章 需求分析

1 用例图：知识在书p30，看图说话吧

用例椭圆表示，涉众画人

1）涉众：与目标系统相关的一切人和物，会对目标系统产生影响

2 用例规约：看书p33，没啥东西（懒得抄）

插一个嘴：一个业务用例描述的是业务过程—— 而不是软件系统的过程，一个业务用例为涉众创造价值，业务用例可以超越系统的边界

1）用例提炼：

a 包含关系：

通过构造型《include》 关系与依赖它的主用例相连
被包含 用例 也可 使用构造型《secondary》

c 两者的对比

1. 一般来说被包含用例属于无条件发生的用例，而扩展用例属于有条件发生的用例
2. 被包含用例提供的是间接服务，扩展用例提供的是直接服务
3. 而且扩展用例在用例规约中一般作为基本事件的备选流而存在

2）用例优化

a 每个用例图中的用例数目一般要避免超过15 个

b 同一用例图中的用例应尽量具有相同的业务粒度水平以及处于同一抽象级别（就是别鸡蛋里面混恐龙蛋）

3 过程建模：

a 控制点：在合并加入新的流程时，总是伴随着要补充一个控制点的菱形

c 基本事件流

1.如果这个动作比较复杂，可以对应使用几个动作来对它进行表示，或者使用另外一个单独的活动图对其进行细化
2.逐步补充每个备选流的动作，同时注意每个动作是否需要进一步的细化

4 功能性需求

a 沟通障碍的体现：

1.隐含的假设 2.笼统的注释 3.模糊的概括 4.迷惑的命名

b 三种需求类型：

1. 系统功能 ：系统自身应完成的功能需求
2. 交互 ：提供给特定用户交互性的功能
3. 外部接口：提供给第三方的外部访问接口

5 数据流图（传统功能分析）

a 四种基本符 ：

数据的源点或终点；变换数据的处理；数据存储；数据流
数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。

c 数据流图画法

1. 从基本系统模型高的抽象层次开始画数据流图
2. 把基本系统模型细化，描绘系统主要功能
3. 在图中给处理和数据存储加编 ，便于引用和追踪
4. 分层细化时保持 信息连续性

命名规则：
5. 应代表整个数据流额内容，而不是某一部分
6. 不要用空洞的，缺乏意义的（如“数据”，“输入”等）
7. 最好是一个具体的及物动词（例如：出入库数据 ， 而不是数据出入库）