软件工程导论笔记(同步更新)（已结束更新）

软件工程导论笔记

• • 1.1软件危机
  • 1.2软件工程
  • 1.4软件过程
  • • 1.4.1瀑布模型
    • 1.4.2快速原型模型
    • 1.4.3增量模型
    • 1.4.4螺旋模型
    • 1.4.5喷泉模型
    • 1.4.6Rational统一过程（RUP）
    • 1.4.7敏捷过程与极限编程
    • 1.4.8微软过程
  • 1.5软件结构图
  • 2.3系统流程图
  • • 2.3.3分层
  • 2.4数据流图
  • • 2.4.1符
  • 2.5数据字典
• 3需求分析
• • 3.1需求分析的任务
  • • 3.1.1确定系统的要求（获取需求）
    • 3.1.2分析系统的数据要求（分析）
    • 3.1.3导出系统的逻辑模型（定义、建模）
    • 3.1.4验证
  • 3.2结构化的分析模型
  • 3.3功能建模
  • • 3.3.1数据流图
    • 3.3.2 环境图
    • 3.3.3 数据流图的分层
  • 3.4数据建模
  • • 3.4.1实体-关系模型：ER图
  • 3.5行为建模
  • • 3.5.1状态转换图：状态图
  • 3.6数据字典
  • • 3.6.1Warnier图
  • 3.7加工规格说明
  • 3.8需求规格说明
  • 5.1 设计
  • 5.2设计原理
  • • 框架
    • 架构
    • • 1. 物理结构
      • • 物理结构图/配置图
      • 2.逻辑架构
      • • 逻辑结构图
      • 3.用例
      • • 用例图转化为类图
    • 类的设计原则
    • • 开闭原则
      • 替换原则
      • 依赖原则
      • 单一职责原则
      • 接口分离原则
  • 图书馆管理系统
  • • 数据流图转化程序结构图
  • 8.1什么是面向对象分析
• 9 面向对象方法学引论
• • 9.1面向对象方法学概述
  • 9.2面向对象的概念
  • • 9.2.1对象
    • 9.2.2类，实例，消息，方法，属性，封装，继承，多态，重载
  • 9.3面向对象建模
  • 9.4对象模型
  • • 9.4.1 类图的基本符
    • 9.4.2表示关系的符
    • • 9.4.2.1依赖
      • 9.4.2.2关联
      • 9.4.2.3聚集
      • 9.4.2.4泛化
      • 9.4.2.5.实现
    • 9.4.3用例图
    • • 9.4.3.1用例泛化
      • 9.4.3.1用例包含
      • 9.4.3.2用例扩展
  • 10.1面向对象分析的基本过程
  • 10.2需求陈述
  • 10.3建立对象模型
  • 10.3.1确定类与对象
  • 10.3.2确定关联
  • • 10.3.3划分主题
    • 10.3.4确定属性
    • 10.3.5识别继承关系
  • 10.4建立动态模型
  • • 10.4.3.画事件跟踪图
    • 10.4.4画状态图
  • 10.5 建立功能模型
  • 10.6定义服务

1.1软件危机

软件危机：软件开发和维护中遇到的一系列严重问题。
软件危机的典型表现：

1. 软件开发的成本和进度常估计不准确
2. 用户经常不满意已完成的软件
3. 软件产品的质量常靠不住
4. 软件常不可维护
5. 没有文档
6. 软件成本在计算机系统总成本中所占的比例逐年上升
7. 软件开发生产效率提高的速度，跟不上计算机应用迅速普及深入的趋势。

软件危机产生的原因：
与软件本身特点有关

1. 软件不同于硬件，管理和控制软件开发过程相当困难。
2. 软件在运行过程中不会因为使用过长而被“用坏”。如果运行中发现了错误，很可能是遇到了一个在开发时期引入的、在测试阶段没能检测出来的错误。
3. 软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
4. 事实上，对用户要求没有准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。
5. 目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念。在实践过程中或多或上地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
6. 错误的认识和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。
   软件开发与维护的方法不正确有关
7. 只重视程序而忽视软件配置其余成分的糊涂观念。
8. 软件开发人员在定义时期没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完成符合用户的需要。
9. 严重的问题是在软件开发的不同阶段进行修改需要付出的代价是很不相同的。

1.2软件工程

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

软件三要素：程序加数据，文档
软件工程三要素：方法，工具，过程，

1.4软件过程

模型示意图要会画

1.4.1瀑布模型

传统瀑布模型：需求分析->规格说明->设计->编码->测试->维护
特点
a.阶段间具有顺序性和依赖性
b.推迟实现：编码在步骤的后面
c.质量保证：每个阶段都要完成文档，每个阶段结束前都要对文档进行评审
实际瀑布模型：在后面阶段发现前面阶段的错误时，需要返回前面的阶段

1.4.3增量模型

为了缩短瀑布模型开发周期，出现了渐增模型，分成了很多模块
每次只开发软件的一部分
过程：需求分析->规格说明->概要设计->对构件设计，编码，集成，测试

风险更大的增量模型：

1.4.5喷泉模型

为了解决瀑布模型交付时间过长的问题
与增量模型不同，它是每次都开发完整，但质量不高，通过迭代逐步完善。
是一个典型的循环迭代的过程。
迭代

1.4.7敏捷过程与极限编程

对传统软件过程反思，不应该过多的关注文档，应该回归软件本身
敏捷宣言：
1.个体和交互胜过过程和工具：个体是关注程序员的能力的提高，交互是合作
2.可以工作的软件胜过面面俱到的文档：没有人是通过看文档学会玩手机的，软件比文档更重要
3.客户合作胜过合同谈判：传统开发中不允许客户更改需求（需求冻结），但现在用户需求总在变化，要适用于时代的变化
4.响应变化胜过遵循计划

极限编程：把好的开发时间用到极致

2.3系统流程图

系统流程图是概括描述物理系统的传统工具，描述数据在系统间流动的过程。
符 ：

3.1.1确定系统的要求（获取需求）

3.3功能建模

站在计算机的角度，输入数据，如何进行数据传递

功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。功能模型用数据流图来描述。

3.3.1数据流图

3.3.2 环境图

顶层数据流图，包括与哪些外部实体打交道，输入什么信息，输出什么信息。

银行储蓄系统的业务流程：

1. 储户填写的存款单或取款单由业务员键入系统；
2. 如果是存款则系统记录存款人姓名、住址（或电话 码）、身份证 码、存款类型、存款日期、到期日期、利率、密码（可选）等信息，并印出存单给储户；
3. 如果是取款而且开户时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。

(1)外部实体，输入，输出数据流
外部实体：储户、业务员
输入：如果需要储户输入密码，储户才直接与系统进行交互。储户填写的存款或取款信息通过业务员键入系统，可以将存款及取款信息抽象为事务。
输出：存单，利息清单
(2)环境图

3.4数据建模

使用实体-关系模型（ER图）进行数据建模。
这种技术是在较高的抽象层次（概念层）上对数据库结构进行建模的流行技术。

3.4.1实体-关系模型：ER图

ER图中仅包含3种相互关联的元素：数据对象（实体）、描述数据对象的属性、数据对象彼此间相互连接的关系。
数据对象：用矩形表示，可以是外部实体、事物、角色、行为或事件、组织单位、地点或结构
属性：对象的特质

箭头线：状态转换，线上写事件，如果没写就是内源性自发的。
状态转换：

3.6数据字典

3.6.1Warnier图

框架

架构

2.逻辑架构

逻辑结构图

3.用例

用例图转化为类图

用例图：9.4.3