├── 第4章 形式化说明书技术.md ├── 第3章 需求分析.md ├── 第2章 可行性研究.md ├── 第8章 维护.md ├── 第5章 总体设计.md ├── 第6章 详细设计.md ├── 第1章 软件工程学概述.md ├── 第9-12章 面向对象软件工程.md ├── README.md └── 第7章 实现.md /第4章 形式化说明书技术.md: -------------------------------------------------------------------------------- 1 | # 第4章 形式化说明书技术 2 | 3 | 不做考查要求 -------------------------------------------------------------------------------- /第3章 需求分析.md: -------------------------------------------------------------------------------- 1 | # 第3章 需求分析 2 | 3 | ## 结构化分析法SA:分析系统数据流 4 | 5 | - 结构化分析（Structured Analysis，简称SA 法）是面向数据流的需求分析方法 6 | 7 | - 结构化分析方法的基本思想是“分解”和“抽象”。 8 | 9 | 分解：是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。 10 | 11 | ## 需求分析阶段的任务 12 | 13 | - 确定对系统的综合要求 14 | 1. 功能需求 15 | 2. 性能需求 16 | 3. 可靠性和可用性需求 17 | 4. 出错处理需求 18 | 5. 接口需求 19 | 6. 约束 20 | 7. 逆向需求 21 | 8. 将来可能提出的要求 22 | - 分析系统的数据要求 23 | - 导出系统的逻辑模型 24 | - 修正系统开发计划 25 | 26 | ## 与用户沟通获取需求的方法 27 | 28 | - 访谈 29 | - 访谈时最早开始使用的，迄今为止仍然广泛使用的需求分析技术 30 | - 分为正式的和非正式的访谈技术 31 | - 调查大量人员的意见时，分发调查表 32 | - 情景分析技术 33 | 34 | ## 面向过程的分析方法主要是建立三类模型 35 | 36 | - 数据模型（实体-联系图） 37 | - 功能模型（数据流图） 38 | - 行为模型（状态转换图） 39 | 40 | ## 需求分析的产品是什么 41 | 42 | - “通过需求分析除了创建分析模型之外，还应该写出软件**需求规格说明书**，它是需求分析阶段得出的最主要的文档” 43 | 44 | ## 软件需求规格说明书的内容 45 | 46 | - 描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及可能提出的要求。 47 | 48 | ## 常使用的图形工具 49 | 50 | - 实体-联系图 51 | - 状态转换图 52 | - 层次方框图 53 | - Warnier图 54 | - IPO图 55 | 56 | 57 | 58 | -------------------------------------------------------------------------------- /第2章 可行性研究.md: -------------------------------------------------------------------------------- 1 | # 第2章 可行性研究 2 | 3 | ## 可行性研究的目的和内容 4 | 5 | - 目的：用最小的代价在尽可能短的时间内确定问题是否能够解决。 6 | - 内容：从技术、经济、操作三个方面研究解法的可行性； 7 | - 复查系统规模和目标 8 | - 研究目前正在使用的系统 9 | - 导出新系统的高层逻辑模型 10 | - 进一步定义问题 11 | - 导出和评价供选择的解法 12 | - 推荐行动方针 13 | - 草泥开发计划 14 | - 书写文档提交审查 15 | 16 | ## 系统流程图的作用 17 | 18 | - 把设想的新系统的逻辑模型转变成物理模型，描绘其概貌 19 | - 基本思想是以黑盒子形式描绘组成系统的每个部件 20 | 21 | ## 数据流图的概念 22 | 23 | - 数据流图是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程所经受的变换。 24 | 25 | ## 数据流图里面的符号、绘制数据流图 26 | 27 | - 四种基本符号： 28 | - 正方形（或立方体）表示数据的源点或终点； 29 | - 圆角矩形（或圆形）代表变换数据的处理； 30 | - 开扣矩形（或两条平行线）代表数据存储； 31 | - 箭头表示数据流，即特定数据的流动方向 32 | - ![数据流图](https://gitee.com/kevin0401/pic-md1/raw/master/%E6%95%B0%E6%8D%AE%E6%B5%81%E5%9B%BE.png) 33 | 34 | ## 什么是数据字典，以及与数据流图的关系 35 | 36 | - 数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。 37 | - 与数据流图的关系：数据流图和数据字典共同构成系统的逻辑模型，没有数据字典，数据流图就不严格，然而没有数据流图，数据字典也难于发挥作用。只有数据流图和数据字典放在一起，才能共同构成系统的规格说明。 38 | 39 | ## 数据字典的表示方法 40 | 41 | - 数据字典应该由对下列4类元素的定义组成。 42 | - 数据流 43 | - 数据流分量（即数据元素） 44 | - 数据存储 45 | - 数据处理 46 | 47 | ## 成本/效益分析 48 | 49 | 见习题p51 50 | -------------------------------------------------------------------------------- /第8章 维护.md: -------------------------------------------------------------------------------- 1 | # 第8章 维护 2 | 3 | ## 什么是维护，维护的类型 4 | 5 | - 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 6 | - 维护的类型 7 | 1. 为了纠正在使用过程中暴露出来的错误而进行的**改正性维护** 8 | 2. 为了适应外部环境的变化而进行的**适应性维护** 9 | 3. 为了改进原有的软件而进行的**完善性维护** 10 | 4. 为了改进将来的可维护性和可靠性而进行的**预防性维护** 11 | 12 | ## 决定软件可维护性的因素 13 | 14 | - **可理解性** 15 | 16 | 软件可理解性表现为外来读者来理解软件的结构、功能、接口和内部处理过程的难易程度。 17 | 18 | - **可测试性** 19 | 20 | 诊断和测试的容易程度取决于软件容易理解的程度。 21 | 22 | - **可修改性** 23 | 24 | 耦合内聚等属性都影响软件的可修改性 25 | 26 | - **可移植性** 27 | 28 | 把程序从一种计算环境转移到另一种计算环境的难易程度。 29 | 30 | - **可重用性** 31 | 32 | 指同一事物不做修改或稍加改动就在不同环境中多次重复使用。 33 | 34 | ## 文档 35 | 36 | 文档是影响软件可维护性的决定因素。 37 | 38 | 软件系统的文档可以分为**用户文档**和**系统文档**两类。 39 | 40 | 总的来说，软件文档应该满足下述要求 41 | 42 | 1. 必须描述如何使用这个系统 43 | 2. 必须描述怎样安装和管理这个系统 44 | 3. 必须描述系统需求和设计 45 | 4. 必须描述系统的实现和测试，以便使系统成为可维护的 46 | 47 | ### 用户文档 48 | 49 | 用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的； 50 | 51 | ### 系统文档 52 | 53 | 系统文档描述系统设计、实现和测试等各方面的内容。 54 | 55 | ## 维护是软件生命周期中所花费最多的阶段 56 | 57 | 维护时软件生命周期的最后一个阶段，也是持续时间最长、代价最大的一个阶段。 58 | 59 | 软件工程学的主要目的就是提高软件的可维护性，降低维护的代价。 60 | 61 | -------------------------------------------------------------------------------- /第5章 总体设计.md: -------------------------------------------------------------------------------- 1 | # 第5章 总体设计 2 | 3 | ## 总体设计的任务 4 | 5 | 通常由两个主要阶段组成：系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。典型的总体设计包括以下九个步骤： 6 | 7 | 1. 设想供选择的方案 8 | 2. 选取合理的方案 9 | 3. 推荐最佳方案 10 | 4. 功能分解 11 | 5. 设计软件结构 12 | 6. 设计数据库 13 | 7. 制定测试计划 14 | 8. 书写文档 15 | 9. 审查和复查 16 | 17 | ## 模块化思想 18 | 19 | - 按照模块的定义，过程、函数、子程序和宏等，都可作为模块。 20 | - 模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。 21 | 22 | ## 衡量模块独立的标准（内聚和耦合的含义、种类） 23 | 24 | - 内聚衡量一个模块内部各个元素彼此结合的紧密程度； 25 | - 偶然内聚（低内聚）：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。 26 | - 逻辑内聚（低内聚）：如果一个模块完成的任务在逻辑上属于相同或相似的一类，则称为逻辑内聚。 27 | - 时间内聚（低内聚）：如果一个模块包含的任务必须在同一段时间内执行就叫时间内聚。 28 | - 过程内聚（中内聚）：如果一个模块内的处理元素是相关的而且必须以特定次序执行，则称为过程内聚。 29 | - 通信内聚（中内聚）：如果模块中所有元素都使用同一个输入数据和产生同一个输出数据，则称为通信内聚。 30 | - 顺序内聚（高内聚）：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为顺序内聚。 31 | - 功能内聚（高内聚）：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。 32 | - 耦合衡量不同模块彼此间互相依赖（连接）的紧密程度； 33 | - 数据耦合：如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅式数据，那么这种耦合叫做数据耦合。 34 | - 控制耦合：如果传递的信息中有控制信息，则这种耦合称为控制耦合。 35 | 36 | ## 启发式规则 37 | 38 | 下面介绍几条启发式规则： 39 | 40 | - 改进软件结构提高模块独立性 41 | - 模块规模应该适中 42 | - 深度、宽度、扇出和扇入都应适当 43 | - 模块的作用域应该在控制域之内 44 | - 力争降低模块接口的复杂程度 45 | - 设计单入口单出口的模块 46 | - 模块功能应该可以预测 47 | 48 | ## 掌握面向数据流的设计方法 49 | 50 | - 变换分析 51 | - 事务分析 52 | - 设计优化 53 | 54 | -------------------------------------------------------------------------------- /第6章 详细设计.md: -------------------------------------------------------------------------------- 1 | # 第6章 详细设计 2 | 3 | ## 详细设计的基本任务 4 | 5 | - 详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个“蓝图写出实际地程序代码。 6 | 7 | ## 程序的五种控制结构 8 | 9 | - 3种基本控制结构”顺序“、”选择“和”循环“ 10 | - DO_UNTIL和DO_CASE两种控制结构 11 | 12 | ## 详细设计的工具和直接的转换 13 | 14 | 分为图形、表格和语言3类 15 | 16 | - 程序流程图 17 | - 盒图 18 | - PAD图 19 | - 判定表 20 | - 判定树 21 | - 过程设计语言（PDL） 22 | 23 | ## 判定表/判定树的设计 24 | 25 | - 一张判定表由4部分组成，左上列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相应的动作。 26 | 27 | ![判定表](https://gitee.com/kevin0401/pic-md1/raw/master/%E5%88%A4%E5%AE%9A%E8%A1%A8.png) 28 | 29 | 判定表右半部的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。 30 | 31 | - ![判定树](https://gitee.com/kevin0401/pic-md1/raw/master/%E5%88%A4%E5%AE%9A%E6%A0%91.png) 32 | 33 | 判定树更加直观，但是不够简洁。 34 | 35 | ## Jackson方法 36 | 37 | - 分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构。 38 | - 找出输入数据结构和输出数据结构中有对应关系的数据单元。 39 | - 从描绘数据结构的Jackson图导出描绘程序结构的Jackson图 40 | - 列出所有操作和条件（包括分支条件和循环结束条件），并且把它们分配到程序结构图的适当位置。 41 | - 用伪代码表示程序。 42 | 43 | ## McCabe方法计算复杂度 44 | 45 | McCabe方法根据程序控制流的复杂程度定量度量程序的复杂程度，这样度量出的结果称为程序的环形复杂度。 46 | 47 | - 流图中线性无关的区域数等于环形复杂度。 48 | - 流图G的环形复杂度$V(G)=E-N+2$，其中，$E$是流图中边的条数，$N$是结点数。 49 | - 流图G的环形复杂度$V(G)=P+1$，其中,$P$是流图中判定结点的数目。 50 | 51 | ![环形复杂度](https://gitee.com/kevin0401/pic-md1/raw/master/%E7%8E%AF%E5%BD%A2%E5%A4%8D%E6%9D%82%E5%BA%A6%E8%AE%A1%E7%AE%97.png) 52 | 53 | -------------------------------------------------------------------------------- /第1章 软件工程学概述.md: -------------------------------------------------------------------------------- 1 | # 第1章 软件工程学概述 2 | 3 | ## 什么是软件 4 | 5 | - 软件=程序+数据+文档+知识 6 | 7 | ## 软件危机的概念、表现 8 | 9 | - 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 10 | - 软件危机的典型表现有 11 | - 对软件开发成本和进度的估计常常很不准确。 12 | - 用户对“已完成的”软件系统不满意的现象经常发生。 13 | - 软件产品的质量往往靠不住。 14 | - 软件常常是不可维护的。 15 | - 软件通常没有适当的文档资料。 16 | - 软件成本在计算机系统总成本中所占的比例逐年上升。 17 | - 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。 18 | 19 | ## 产生软件危机的原因以及消除危机的途径 20 | 21 | - 原因： 22 | - 软件缺乏“可见性”，开发过程的进展情况较难衡量，软件的质量也较难评价，管理和控制软件开发过程相当困难。 23 | - 软件规模庞大，程序复杂性将随着程序规模的增加而呈指数上升。 24 | - 分工合作困难。 25 | - 轻视维护。 26 | - 消除危机的途径： 27 | - 做好软件定义时期的工作 28 | - 应该推广使用在实践中总结出来的开发软件的成功技术和方法，并且探索更有效的技术和方法。 29 | - 应该开发和使用的更好的软件工具。 30 | - 总之，为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。 31 | 32 | ## 软件工程的概念、本质特性、基本原理 33 | 34 | - 软件工程是指导计算机软件开发和维护的一门工程学科。 35 | - 本质特性： 36 | - 软件工程关注于大型程序的构造 37 | - 软件工程的中心课题是控制复杂性 38 | - 软件经常变化 39 | - 开发软件的效率非常重要 40 | - 和谐地合作是开发软件地关键 41 | - 软件必须有有效地支持它的用户 42 | - 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品 43 | - 基本原理： 44 | 1. 用分阶段的生命周期计划严格管理 45 | 2. 坚持进行阶段评审 46 | 3. 实行严格的产品控制 47 | 4. 采用现代程序设计技术 48 | 5. 结果应该嫩清楚地审查 49 | 6. 开发小组的人员应该少而精 50 | 7. 承认不断改进软件工程实践必要性 51 | 52 | ## 软件工程方法学的三要素 53 | 54 | - 方法、工具和过程 55 | 56 | ## 软件生命周期分成哪三个阶段？各阶段的任务是什么？ 57 | 58 | - 软件定义、软件开发和运行维护 59 | - 主要任务： 60 | - 软件定义：**问题定义**、**可行性研究**和**需求分析** 61 | - 软件开发：**总体设计**、**详细设计**、**编码和单元测试**、**综合测试**。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。 62 | - 运行维护：**软件维护**阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。 63 | 64 | ## 什么是软件过程？瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型的特点 65 | 66 | - 软件过程是为了获得高质量软件所需完成得一系列任务得框架，它规定了完成各项任务的工作步骤。 67 | - 瀑布模型的特点： 68 | - 阶段间具有顺序性和依赖性 69 | - 推迟实现的特点 70 | - 质量保证的观点，每个阶段必须完成规定的阶段文档，且进行文档评审。即**“瀑布模型是由文档驱动的”**。 71 | - 快速原型模型的特点： 72 | - 不带反馈环的，线性顺序进行的 73 | - 软件交付使用后开始维护 74 | - 维护时会返回到任一阶段 75 | - 快速开发、节约开发成本 76 | - 增量模型的特点： 77 | - 软件产品作为一系列的增量构件来设计、编码、集成和测试。 78 | - 较短时间内向用户提交可完成部分工作的产品 79 | - 逐步增加产品功能可以使用户有较为充裕的时间学习和适应新产品 80 | - 软件体系结构开放 81 | - 螺旋模型的特点： 82 | - 风险驱动 83 | - 软件开发过程中必须及时识别和分析风险，构建原型使某种类型的风险降至最低。 84 | - 喷泉模型的特点： 85 | - 面向对象软件开发过程迭代和无缝过渡 -------------------------------------------------------------------------------- /第9-12章 面向对象软件工程.md: -------------------------------------------------------------------------------- 1 | # 第9-12章 面向对象软件工程 2 | 3 | Oriented Object = objects + classes +inheritance + communication with messages 4 | 5 | ## 几个概念：类、对象、继承、消息、封装、属性、实例、多态性、重载 6 | 7 | ### 类class 8 | 9 | 类是**对现实生活中一类具有共同特征的事物的抽象**。 10 | 11 | ### 对象object 12 | 13 | 对象是封装了数据结构及可以施加在这些数据结构上的操作的封装体，这个封装体有可以唯一标识它的名字，而且向外界提供一组服务。 14 | 15 | ### 继承inheritance 16 | 17 | 下层的派生类自动具有和上层的基类相同的特性（包含数据和方法），这种现象称为继承。 18 | 19 | 继承是子类自动地共享基类中定义的数据和方法的机制。 20 | 21 | ### 消息message 22 | 23 | 消息就是要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。 24 | 25 | ### 封装encapsulation 26 | 27 | 把数据和实现操作的代码集中起来放在对象内部。一个对象好像是一个不透明的黑盒子，从外面是不能看见内部的。 28 | 29 | 使用一个封装好的对象时，只需知道它向外界提供的接口方式，无须知道它的数据结构细节和实现操作的算法。 30 | 31 | ### 属性attribute 32 | 33 | 属性就是类中所定义的数据，它是对客观世界实体所具有的性质的抽象。类中的每个实例都有自己特有的属性值。 34 | 35 | ### 实例instance 36 | 37 | 实例就是由某个特定的类所描述的一个具体的对象。 38 | 39 | ### 多态性polymorphism 40 | 41 | 多态性是指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。 42 | 43 | ### 重载overload 44 | 45 | 在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字 46 | 47 | ## 面向对象的方法（4个要素） 48 | 49 | Oriented Object = objects + classes +inheritance + communication with messages 50 | 51 | 1. 软件中任何元素都是对象 52 | 2. 把所有的对象都划分为各种对象类（简称类） 53 | 3. 按照继承关系，把若干个对象类组成一个层次结构的系统 54 | 4. 对象彼此之间仅能通过传递消息相互联系 55 | 56 | ## 面向对象方法的优点 57 | 58 | - 以数据为中心，不设置与这些数据无关的操作 59 | - 模块独立性好，内聚性强，耦合性弱 60 | 61 | ## 面向对象建模的三个模型，以及之间的关系 62 | 63 | ### 对象模型 64 | 65 | 描述系统数据结构 66 | 67 | - 最重要、最基本、最核心 68 | - 对象模型规定了做事情的实体 69 | 70 | ### 动态模型 71 | 72 | 描述系统控制结构 73 | 74 | - 动态模型明确规定了什么时候做 75 | 76 | ### 功能模型 77 | 78 | 描述系统功能 79 | 80 | - 功能模型指明了系统应该做什么 81 | 82 | ### 三者关系 83 | 84 | - 它们使用数据结构（对象模型），执行操作（动态模型），并且完成数据值的变化（功能模型） 85 | 86 | ## 面向对象设计有哪些启发式规则 87 | 88 | - 设计结果应该清晰易懂 89 | - 一般-特殊结构的深度应适当 90 | - 设计简单的类 91 | - 使用简单协议 92 | - 使用简单的服务 93 | - 把设计变动减至最小 94 | 95 | ## CMM等级划分 96 | 97 | capability maturity model能力成熟度模型 98 | 99 | 能力成熟度把软件过程从无序到有序的进化过程分成5个阶段 100 | 101 | 1. 初始级 102 | - 软件过程的特征是无序的，有时甚至是混乱的。 103 | - 几乎没有什么过程是金国定义的 104 | - 项目能否成功完全取决于开发人员的个人能力 105 | 2. 可重复级 106 | - 软件机构建立了基本的项目规范管理过程，可跟踪成本、进度、功能和质量。 107 | 3. 已定义级 108 | - 软件机构已经定义了完整的软件过程，软件过程已经文档化和标准化。 109 | 4. 已管理级 110 | - 软件机构对软件过程和软件铲平都建立定量的质量目标， 111 | - 所有项目的重要的过程活动都是可度量的。 112 | 5. 已优化级 113 | - 软件机构集中精力持续不断地改进软件过程。 114 | - 软件过程是可优化的。 115 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # SoftwareEngineer 2 | * [第1章 软件工程学概述](#第1章-软件工程学概述) 3 | * [什么是软件](#什么是软件) 4 | * [软件危机的概念、表现](#软件危机的概念表现) 5 | * [产生软件危机的原因以及消除危机的途径](#产生软件危机的原因以及消除危机的途径) 6 | * [软件工程的概念、本质特性、基本原理](#软件工程的概念本质特性基本原理) 7 | * [软件工程方法学的三要素](#软件工程方法学的三要素) 8 | * [软件生命周期分成哪三个阶段？各阶段的任务是什么？](#软件生命周期分成哪三个阶段各阶段的任务是什么) 9 | * [什么是软件过程？瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型的特点](#什么是软件过程瀑布模型快速原型模型增量模型螺旋模型喷泉模型的特点) 10 | * [第2章 可行性研究](#第2章-可行性研究) 11 | * [可行性研究的目的和内容](#可行性研究的目的和内容) 12 | * [系统流程图的作用](#系统流程图的作用) 13 | * [数据流图的概念](#数据流图的概念) 14 | * [数据流图里面的符号、绘制数据流图](#数据流图里面的符号绘制数据流图) 15 | * [什么是数据字典，以及与数据流图的关系](#什么是数据字典以及与数据流图的关系) 16 | * [数据字典的表示方法](#数据字典的表示方法) 17 | * [成本/效益分析](#成本效益分析) 18 | * [第3章 需求分析](#第3章-需求分析) 19 | * [结构化分析法SA:分析系统数据流](#结构化分析法sa分析系统数据流) 20 | * [需求分析阶段的任务](#需求分析阶段的任务) 21 | * [与用户沟通获取需求的方法](#与用户沟通获取需求的方法) 22 | * [面向过程的分析方法主要是建立三类模型](#面向过程的分析方法主要是建立三类模型) 23 | * [需求分析的产品是什么](#需求分析的产品是什么) 24 | * [软件需求规格说明书的内容](#软件需求规格说明书的内容) 25 | * [常使用的图形工具](#常使用的图形工具) 26 | * [第4章 形式化说明书技术](#第4章-形式化说明书技术) 27 | * [第5章 总体设计](#第5章-总体设计) 28 | * [总体设计的任务](#总体设计的任务) 29 | * [模块化思想](#模块化思想) 30 | * [衡量模块独立的标准（内聚和耦合的含义、种类）](#衡量模块独立的标准内聚和耦合的含义种类) 31 | * [启发式规则](#启发式规则) 32 | * [掌握面向数据流的设计方法](#掌握面向数据流的设计方法) 33 | * [第6章 详细设计](#第6章-详细设计) 34 | * [详细设计的基本任务](#详细设计的基本任务) 35 | * [程序的五种控制结构](#程序的五种控制结构) 36 | * [详细设计的工具和直接的转换](#详细设计的工具和直接的转换) 37 | * [判定表/判定树的设计](#判定表判定树的设计) 38 | * [Jackson方法](#jackson方法) 39 | * [McCabe方法计算复杂度](#mccabe方法计算复杂度) 40 | * [第7章 实现](#第7章-实现) 41 | * [选择程序设计语言应该考虑哪些元素](#选择程序设计语言应该考虑哪些元素) 42 | * [良好的编程风格包括哪些](#良好的编程风格包括哪些) 43 | * [软件测试的目的](#软件测试的目的) 44 | * [初步测试计划是在哪个阶段制定的](#初步测试计划是在哪个阶段制定的) 45 | * [黑盒测试和白盒测试的概念](#黑盒测试和白盒测试的概念) 46 | * [黑盒测试](#黑盒测试) 47 | * [白盒测试](#白盒测试) 48 | * [测试步骤（5个）以及相关的文档](#测试步骤5个以及相关的文档) 49 | * [测试步骤](#测试步骤) 50 | * [相关的文档](#相关的文档) 51 | * [单元测试的方法](#单元测试的方法) 52 | * [测试重点](#测试重点) 53 | * [代码审查](#代码审查) 54 | * [渐增式与非渐增式的区别](#渐增式与非渐增式的区别) 55 | * [自顶向下、自下而上、以及混合策略的优缺点](#自顶向下自下而上以及混合策略的优缺点) 56 | * [自顶向下](#自顶向下) 57 | * [自下而上](#自下而上) 58 | * [混合策略](#混合策略) 59 | * [确认测试](#确认测试) 60 | * [白盒测试技术（覆盖标准、基本路径）](#白盒测试技术覆盖标准基本路径) 61 | * [覆盖标准](#覆盖标准) 62 | * [基本路径](#基本路径) 63 | * [黑盒测试技术（等价划分、边界值分析）](#黑盒测试技术等价划分边界值分析) 64 | * [等价划分](#等价划分) 65 | * [边界值分析](#边界值分析) 66 | * [软件调试技术有哪些](#软件调试技术有哪些) 67 | * [软件可靠性（可靠性和可用性的含义）](#软件可靠性可靠性和可用性的含义) 68 | * [可靠性](#可靠性) 69 | * [可用性](#可用性) 70 | * [第8章 维护](#第8章-维护) 71 | * [什么是维护，维护的类型](#什么是维护维护的类型) 72 | * [决定软件可维护性的因素](#决定软件可维护性的因素) 73 | * [文档](#文档) 74 | * [用户文档](#用户文档) 75 | * [系统文档](#系统文档) 76 | * [维护是软件生命周期中所花费最多的阶段](#维护是软件生命周期中所花费最多的阶段) 77 | * [第9\-12章 面向对象软件工程](#第9-12章-面向对象软件工程) 78 | * [几个概念：类、对象、继承、消息、封装、属性、实例、多态性、重载](#几个概念类对象继承消息封装属性实例多态性重载) 79 | * [类class](#类class) 80 | * [对象object](#对象object) 81 | * [继承inheritance](#继承inheritance) 82 | * [消息message](#消息message) 83 | * [封装encapsulation](#封装encapsulation) 84 | * [属性attribute](#属性attribute) 85 | * [实例instance](#实例instance) 86 | * [多态性polymorphism](#多态性polymorphism) 87 | * [重载overload](#重载overload) 88 | * [面向对象的方法（4个要素）](#面向对象的方法4个要素) 89 | * [面向对象方法的优点](#面向对象方法的优点) 90 | * [面向对象建模的三个模型，以及之间的关系](#面向对象建模的三个模型以及之间的关系) 91 | * [对象模型](#对象模型) 92 | * [动态模型](#动态模型) 93 | * [功能模型](#功能模型) 94 | * [三者关系](#三者关系) 95 | * [面向对象设计有哪些启发式规则](#面向对象设计有哪些启发式规则) 96 | * [CMM等级划分](#cmm等级划分) 97 | -------------------------------------------------------------------------------- /第7章 实现.md: -------------------------------------------------------------------------------- 1 | # 第7章 实现 2 | 3 | 通常把编码和测试统称为实现 4 | 5 | ## 选择程序设计语言应该考虑哪些元素 6 | 7 | - 系统用户的要求 8 | - 可以使用的编译程序 9 | - 可以得到的软件工具 10 | - 工程规模 11 | - 程序员的知识 12 | - 软件可移植性要求 13 | - 软件的应用领域 14 | 15 | ## 良好的编程风格包括哪些 16 | 17 | - **程序内部的文档**，包括恰当的标识符、适当的注解和程序的视觉组织等 18 | - **数据说明**，标准化的数据说明次序 19 | - **语句构造**，简单而直接 20 | - **输入输出** 21 | - **效率**，时间空间以及输入输出效率，不要牺牲程序的清晰性和可读性来不必要地提高效率 22 | 23 | ## 软件测试的目的 24 | 25 | - 测试是为了发现程序中的错误而执行程序的过程。 26 | - 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。 27 | - 成功的测试是为了发现至今为止尚未发现的错误的测试。 28 | 29 | ## 初步测试计划是在哪个阶段制定的 30 | 31 | - 应该远在测试开始之前就制定出测试计划。实际上，**一旦完成了需求模型就可以着手制定测试计划**，在建立了设计模型之后就可以立即开始设计详细的测试方案。因此，在编码之前就可以对所有测试工作进行计划和设计。 32 | 33 | ## 黑盒测试和白盒测试的概念 34 | 35 | ### 黑盒测试 36 | 37 | - 如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用； 38 | - 黑盒测试把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。 39 | 40 | ### 白盒测试 41 | 42 | - 如果知道产品的内部工作过程，可以通过测验来检验产品内部动作是否按照规格说明书的规定正常进行； 43 | 44 | ## 测试步骤（5个）以及相关的文档 45 | 46 | ### 测试步骤 47 | 48 | 1. 模块测试（又称单元测试） 49 | 2. 子系统测试 50 | 3. 系统测试，与子系统测试通常称为集成测试 51 | 4. 验收测试（又称确认测试） 52 | 5. 平行运行 53 | 54 | ### 相关的文档 55 | 56 | - 需求说明书 57 | - 设计说明书 58 | - 源程序清单 59 | - 测试计划 60 | - 测试方案 61 | 62 | ## 单元测试的方法 63 | 64 | 可以应用人工测试和计算机测试两种不同类型的测试方法，完成单元测试工作 65 | 66 | ### 测试重点 67 | 68 | 从以下5个方面对模块进行测试 69 | 70 | 1. 模块接口 71 | 2. 局部数据结构 72 | 3. 重要的执行通路 73 | 4. 出错处理通路 74 | 5. 边界条件 75 | 76 | ### 代码审查 77 | 78 | 由下述4人组成审查小组，人工测试源程序 79 | 80 | 1. 组长，应该是一个很有能力的程序员，而且没有直接参与这项工程 81 | 2. 程序的设计者 82 | 3. 程序的编写者 83 | 4. 程序的测试者 84 | 85 | ## 渐增式与非渐增式的区别 86 | 87 | 由模块组装成程序时有两种方法。 88 | 89 | 一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非渐增式测试方法； 90 | 91 | 另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个的方法称为渐增式测试。 92 | 93 | - 非渐增式测试一下子把所有模块放在一起，作为一个整体来测试。 94 | - 渐增式测试，把程序划分成小段来构造和测试，易于定位和改正错误。 95 | 96 | ## 自顶向下、自下而上、以及混合策略的优缺点 97 | 98 | 当使用渐增式方式把模块结合到程序去时，有自顶向下和自底向上两种集成策略。 99 | 100 | ### 自顶向下 101 | 102 | - 能够在测试的早期对主要的控制或关键的抉择进行检验。 103 | - 早期证实软件的一个完整的功能，增强开发人员和用户双方的信心。 104 | - 自顶向下的方法在实际使用时可能遇到逻辑上的问题。 105 | 106 | ## 自下而上 107 | 108 | - 总能得到所需的下层模块处理功能，所以不需要存根程序。 109 | 110 | ### 混合策略 111 | 112 | - 如果软件结构的顶部两层用自顶向下方法组装，可以明显减少驱动程序的数目，而且族的结合也将大大简化。 113 | 114 | ## 确认测试 115 | 116 | - 确认测试也成为验收测试，它的目标是验证软件的有效性。 117 | 118 | ## 白盒测试技术（覆盖标准、基本路径） 119 | 120 | ### 覆盖标准 121 | 122 | 1. 语句覆盖 123 | 2. 判定覆盖 124 | 3. 条件覆盖 125 | 4. 判定/条件覆盖 126 | 5. 条件组合覆盖 127 | 6. 点覆盖 128 | 7. 边覆盖 129 | 8. 路径覆盖 130 | 131 | ### 基本路径 132 | 133 | 1. 根据设计结果画出相应的流图 134 | 2. 计算流图的环形复杂度 135 | 3. 确定线性独立路径的基本集合 136 | 4. 设计可强制执行基本集合中每条路径的测试用例。 137 | 138 | ## 黑盒测试技术（等价划分、边界值分析） 139 | 140 | ### 等价划分 141 | 142 | 等价划分是一种黑盒测试技术，这种技术把程序的输入域划分成若干个数据类，据此导出测试用例。 143 | 144 | 几条启发性规则（实际情况千变万化）： 145 | 146 | 1. 输入值的范围 147 | 2. 输入数据的个数 148 | 3. 输入数据的规定允许输入的一组值 149 | 4. 输入数据必须遵循的规则 150 | 5. 输入数据为整形，可以划分出正整数、零和负整数三个有效类 151 | 6. 处理对象是表格 152 | 153 | ### 边界值分析 154 | 155 | 设计程序运行在边界情况附近的测试方案，暴露出程序错误的可能性更大一些。 156 | 157 | ## 软件调试技术有哪些 158 | 159 | 无论采用什么方法，调试的目标都是寻找软件错误的原因并改正错误。一般来说，有下列3种调试途径可以采用。 160 | 161 | 1. 蛮干法 162 | 2. 回溯法 163 | 3. 原因排除法 164 | - 对分查找法 165 | - 归纳法 166 | - 演绎法 167 | 168 | ## 软件可靠性（可靠性和可用性的含义） 169 | 170 | ### 可靠性 171 | 172 | 软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行地概率。 173 | 174 | ### 可用性 175 | 176 | 软件可用性是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。 177 | 178 | - 可靠性和可用性之间的主要差别是，可靠性意味着在0到t时间间隔内系统没有失效性，而可用性只意味着在时刻t，系统是正常运行的。 --------------------------------------------------------------------------------