软件工程导论笔记(同步更新)

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.2快速原型模型

为了解决过晚用户看到原型
在计算机快速建立一个可以运行的程序
阶段：快速原型-规格说明-设计-编码-综合测试-维护

与瀑布模型不同的是，最先做一个原型
优点：简单易用，少返工
工具：HTML，python，鲁比
适用场合：没做过这个项目，需求不明确，用户参与多

1.4.3增量模型

为了缩短瀑布模型开发周期，出现了渐增模型，分成了很多模块
每次只开发软件的一部分
过程：需求分析->规格说明->概要设计->对构件设计，编码，集成，测试
优点：避免一次性投入过大
适用：前期对用户把握不准，市场风险较大，期限要求比较严格，先开发一两个构件，发布一些简单的功能试水，例如：微信

风险更大的增量模型：

1.4.4螺旋模型

为了体改软件的质量
在快速原型的基础上每步骤都加了风险分析

1.4.5喷泉模型

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

1.4.6Rational统一过程（RUP）

RUP是由Ration公司推出的一种完整的软件过程

RUP总结了6条最有效的开发经验：
迭代式开发，管理需求，使用基于构件的体系结构，可视化建模，验证软件质量，控制软件变更

RUP开发周期：
RUP软件开发生命周期：
迭代四项：
初始，精化，构建，移交

1.4.7敏捷过程与极限编程

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

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


用户故事是非形式化的。

1.4.8微软过程

就比较瀑布，快速原型法

1.5软件结构图

2.3系统流程图

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

2.3.3分层

系统很大，有很多系统流程图，可以分层分模块地来描述。用高层次的系统流程图描绘总体概貌（总图），表明关键功能，然后把每个关键功能再扩展详细（子图）。

2.4数据流图

2.4.1符号

基本符号

1. 正方形：数据的源点或终点
2. 圆角矩形：变换数据的处理
3. 开口矩形：数据存储
4. 箭头：数据的流动方向

2.5数据字典

3需求分析

笑死我了，先存图。
需求分析基本任务是准确的回答“系统要做什么”，不是怎么做。
准则

1. 理解并描述问题的信息域，根据这条准则应该建立数据模型。（清楚涉及到哪些数据，没有这个信息系统之前，怎么完成这件事的。）
2. 必须定义软件完成的功能，建立功能模型。
3. 描述作为外部事件结果的软件行为，建立行为模型。（根据一个事件，系统做出什么反应）
4. 对信息、功能、行为的模型进行分解，用层次的方式展示细节。

需求分析最后得到的是数据流图。

3.1需求分析的任务

如何建立需求？

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

1. 功能需求
   指定系统必须提供的服务，系统必须完成的所有任务。
2. 性能需求
   指定系统必须满足的定时约束或容量约束，包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的要求。
3. 可靠性和可用性要求
   可靠性：定量的指定系统的可靠性（计算器的准确率是多少，稳定长时间运行）
   可用性：量化了用户可以使用系统的程度（用户容不容易上手）
4. 出错处理需求
   说明系统对环境错误应该怎么响应。比如它接收到从另一个系统发来的违反协议格式的消息，应该做什么。
5. 接口需求
   描述系统与它环境通信的格式，常见的有：用户接口，硬件接口，软件接口，通信接口
6. 约束
   描述设计和实现系统时应遵循的限制条件，比如：精度，工具和语言约束，应该使用的标准，应该使用的硬件平台。
7. 逆向需求
   不应该做什么
8. 潜在需求
   将来可能会提出来的需求

3.1.2分析系统的数据要求（分析）

数据字典：名称 编号 类型
数据结构：用图表示数据字典

3.1.3导出系统的逻辑模型（定义、建模）

导出详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型

3.1.4验证

3.2结构化的分析模型

结构化的分析是建模技术，建立的模型如下

3.3功能建模

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

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

3.3.1数据流图

多个数据流之间的关系

3.3.2 环境图

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

1. 学校首先公布招生条件，考生根据自己的条件报名，之后系统进行资格审查，并给出资格审查信息；
2. 对于资格审查合格的考生可以参加答卷，系统根据学校提供的试题及答案进行自动判卷，并给出分数及答题信息，供考生查询；
3. 最后系统根据学校的录取分数线进行录取，并将录取信息发送给考生。

逐层分解直到容易实现，先将招生系统进行第一层分解

3.3.3 数据流图的分层

举例

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

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

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

一层中的处理存款、处理取款，再细化

3.4数据建模

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

3.4.1实体-关系模型：ER图

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

关系：
关联数量的表示

关系也可以有属性，用菱形表示

举例
银行储蓄系统的ER图

3.5行为建模

3.5.1状态转换图：状态图

状态转换图（状态图）：系统的状态及引起系统状态转换
初态：
终态：
中间态：

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

3.6数据字典

举例

3.6.1Warnier图

3.7加工规格说明

3.8需求规格说明

5.1 设计

4，5，6是重点
可以从数据流图入手

5.2设计原理

模块是用一个名字就能调用的程序。
模块化： 每个系统都是由模块组成的。每个模块完成不同的功能，组合起来就是一个项目。

交互耦合

框架

他会问你这个架构是什么

架构

1. 物理结构

物理结构图/配置图

2.逻辑架构

逻辑结构图

3.用例

用例图是动态图，是功能模型，是站在用户的角度,用例图是

用例图转化为类图

用例图：9.4.3

类的设计原则

开闭原则

替换原则

父类能飞，子类都要能飞

依赖原则

跟接口打交道

单一职责原则

接口分离原则

图书馆管理系统

1.物理系统




概要做完了


时序图上面的类一定要是设计好的类，不是自己想象的

然后设计实体类

数据流图转化程序结构图

例子：

https://www.cnblogs.com/123456xu/p/5478986.html

变换型数据流



例子

事务性数据流

8.1什么是面向对象分析

1.研究问题域
2.考虑系统边界
3.舍弃无用的类

4.简化

9 面向对象方法学引论

9.1面向对象方法学概述

模拟现实系统的方法。
oo=objects+class+inheritance+message
面向对象方法学=对象+类+继承+消息
优点：

1. 以人类习惯的思维方法一致
   • 以对象为核心
   • 基本原理：使用现实世界的概念抽象地思考问题，自然的解决问题
   • 基本原则：按照人类习惯的思维模型建立问题域的模型
2. 稳定性好
   根据问题领域的模型建立起来，而不是基于对系统应完成的功能的分解（ 不是把自己想象成一个计算机，而是站在问题域建立起来的）
3. 可重用性好（对象是可重用的软件成分）
4. 较易开发大型软件产品
5. 可维护性好

9.2面向对象的概念

9.2.1对象

对象是对属性值和操作值的封装
特点：
2. 以数据为中心
3. 对象是主动的
4. 实现了数据封装
5. 本质具有并行性：不同对象独立处理自身的数据，对象间通过发消息完成通信
6. 模块独立性好：对象之间的耦合比较松，对其他对象依赖较少

9.2.2类，实例，消息，方法，属性，封装，继承，多态，重载

• 类：

• 实例：某个特定的类所描述的一个具体的对象
  类不能实例化，只有对象才能实例化
  对象可以泛指也可以具体而实例只有一个具体

• 消息：（就是对外公开的成员函数）
  一定有消息的调用者和实现者

• 方法：对象所能执行的操作，也就是类中所定义的服务

• 属性：类中定义的数据

• 封装：把数据和实现操作的代码集中起来放在对象内部
  条件：

  1. 有一个清晰的边界（对象的名字）
  2. 有确定的接口（协议）
  3. 受保护的内部实现（封装就是信息隐藏）

• 继承：（软件复用的方法）子类自动的共享基类中定义的数据和方法机制（ps:就是标准化偷懒hh）

  1. 传递性
  2. 当类的等级为树形结构时，类的继承是单继承（java）
  3. 派生类可以调用基类方法，在此基础上增加代码，当完全想改变原有算法，在派生类

• 多态
  问：什么是多态？
  答：不同对象接受同一个消息，但表现出来的行为不一样。
  好处：减少信息冗余，显著提高了软件的可重用性和可扩充性

• 重载
  不同的方法使用相同的函数名,但是方法的参数列表不同

9.3面向对象建模

分析
设计
实现
对象模型动态模型功能模型

9.4对象模型

描述实体的对象，客观世界和实体的关系
对象模型为动态模型和功能模型提供了实质性框架
UML作为面向对象技术的标准建模语言
使用类图建立对象模型

9.4.1 类图的基本符号

类图描述类与类之间的静态关系，是静态模型

1.定义类

命名准则：使用有确切含义的名词，或者名词短语

2.定义属性
语法：可见性 属性名：类型名 = 初值{性质串}
+number:int = “未定”
可见性：public+ private - protected# 没有默认的可见性
初值：如果要加初值，得static
性质串：就是只读，读写等等，抽象

3.定义服务
语法：可见性 操作名(参数表):返回值类型{性质串}
参数表是用逗号分隔,一个参数这样写：
参数名：类型名=默认值

操作的属性
例子：

考试：给你类图，写代码，给代码写类图

9.4.2表示关系的符号

9.4.2.1依赖

类A使用了类B
点画箭头线
使用场景
在ChecksumValidator类中的try—catch语句里使用了InvalidChecksumException类

9.4.2.2关联

1.意思：类A具有一个类B，一般作为成员变量（注意不是在成员函数中使用了这个类）
2.形态：黑实线箭头，线上的是约束
3.代码例子：
翻译：
1.directee被指导，Dos是学生指导者的缩写，学生被导员指导
2.

（1）普通关联
在语义上有语义上的关系，用黑色实线表示
用箭头表示方向
*多
1…*一个到多个
在表示关联

（2）关联的角色
递归关联：自己对自己的引用
一个人与另一个人结婚，一个人必将成为妻子或丈夫，另一个人是丈夫或妻子
限定关联：一对多或多对多，

一个目录里有多个文件，一个文件只能存在于多个目录中，如果是泛化的文件，可以存在多个文件种中
关联类：引入一个关联类把多对多变成一对多
队列这个类，就是关联类。

9.4.2.3聚集

类A包含一个类B，一个类的成员变量

关联的特例
（1）共享聚集(聚合)
如果处于部分方的对象可同时参与多个处于整体方对象的构成，称为共享聚合。
空心菱形
一个课题组包含很多人，但每个人可以是另一个课题组的成员，则课题组和成员之间是共享聚合关系。

部门包含员工

这个课程至少有6个模块，这个模块至少有一个课程

（2）组合聚集（组合）
部分类完全隶属于整体类，整体不存在了部分也失去价值。

例子

1.这个画板上有9个正方形，9个正方形组合在这个板上。

9.4.2.4泛化

也就是继承，比如“一般–特殊”，汽车–卡车，马–白马
语法：空心三角形指向父类

举例

（1）普通泛化
与抽象类相反的是具体类

9.4.2.5.实现

类A实现类B，implement

例子

9.4.3用例图

参与者（用例使用者）和用例（一个需求，概括了功能）通过关联连接。

项目组要针对某种型号的设备开发一套调试系统。用户的基本需求是：设备调试员使用调试系统，可以实时查看设备状态和发送调试命令。设备状态信息由专用的数据采集器实时采集。

9.4.3.1用例泛化

9.4.3.1用例包含

购买物品，首先要登录；追踪包裹，首先要登录
系统有一个参与者：读者；包含三个用例：续借、借书、检查预定，读者可以使用续借和借书功能，在此之前要检查预定。

9.4.3.2用例扩展

特殊情况下才会发生

购买商品，意外的形况下，需要进入日志
有一个参与者：读者；有两个用例：借书和拒绝借阅，读者可以使用借书功能，有特殊情况会拒绝借阅。

10.1面向对象分析的基本过程

10.2需求陈述

例子

10.3建立对象模型

10.3.1确定类与对象

例子
2.筛选

（3）含糊

10.3.2确定关联

给描述，画类图
举例

10.3.3划分主题

就是包图
包和包之间的关系

10.3.4确定属性

10.3.5识别继承关系

10.3.6反复修改

10.4建立动态模型

10.4.3.画事件跟踪图

10.4.4画状态图

10.5 建立功能模型

10.6定义服务