山东大学软件工程期末复习知识点总结

山大软院软件工程期末复习知识点总结，根据任课老师所给提纲及课件等资料进行整理。
考试范围全覆盖。

文档电子版下载地址

目录

• • 第一章
  • • 1.1软件工程（SE）的定义、目的、方法、作用：
    • //1.2开发模式：
    • 1.3说明错误、缺陷和失败的含义及联系（并举例）：
    • 1.4软件质量应从哪几个方面衡量，论述之：
    • //1.5软件系统的系统组成（系统的要素有哪些）： 对象（实体）+ 活动 + 关系 + 系统边界
    • 1.6现代软件工程大致包含几个阶段及各个阶段的文档：
    • //1.7使现代软件工程实践发生变化的关键因素是什么/li>
    • 1.8什么是软件过程件过程的重要性是什么含几个阶段/li>
    • 1.9什么是重用、抽象等现代软件工程主要概念/li>
  • 第二章
  • • 2.1什么叫过程（生命周期）/li>
    • 2.2什么是软件过程件过程的重要性是什么件生命周期/li>
    • 2.3瀑布模型及各阶段文档，优缺点
    • 2.4什么是原型途/li>
    • 2.5论述分阶段（阶段化）开发模型的含义、其基本分类和特点（运行系统和开发系统的概念）
    • 2.6螺旋模型的含义、目的、四个象限的任务及四重迭代（四重循环）的含义
    • 2.7什么是UP、 RUP、进化式迭代等市场流行的过程模型
  • 第三章
  • • 3.1什么是项目进度动程碑目成本/li>
    • 3.2如何计算软件项目活动图的关键路径习题2，3）冗余时间早和最迟开始时间（课堂习题讲解）（见智库P24－25
    • //3.3软件人员应该具备的能力是什么/li>
    • 3.4软件项目团队组织的基本结构
    • //3.5专家估算法的大致含义：
    • //3.6算式估算法的大致含义：
    • 3.7试述COCOMO模型的三个阶段基本工作原理或含义：
    • 3.8什么是软件风险了解主要风险管理活动几种降低风险的策略/li>
    • 3.9弄懂活动图基本原理（参考课本），找出课后练习题图3.23和3.24的关键路径。
  • 第四章
  • • 4.1需求的含义是什么/li>
    • 4.2需求阶段作为一个工程，确定需求的过程（获取需求的过程）是什么/li>
    • 4.3举例说明获取需求时，若有冲突发生，如何考虑根据优先级进行需求分类/li>
    • //4.4如何使需求变得可测试/li>
    • 4.5需求文档分为哪两类/li>
    • 4.6什么是功能需求和非功能需求（质量需求）
    • 4.7什么是设计约束和过程约束何区分/li>
    • //4.8需求的特征：
    • //4.9在原型化需求方面，什么是抛弃式原型，什么是进化式原型/li>
    • 4.10 了解 DFD 图的构成及画法
  • 第五章
  • • 5.1什么是软件体系结构计模式计公约计/li>
    • //5.2什么是概念设计么是技术设计/li>
    • 5.3软件设计过程模型的几个阶段
    • //5.4三种设计层及其关系
    • //5.5什么是模块化么是抽象/li>
    • 5.6论述设计用户界面应考虑的问题
    • 5.7 5.5节—-模块独立性—-耦合与内聚的概念及各个层次划分/li>
    • 5.8软件过程中复审的概念，设计复审的重要性
  • 第六章
  • • 6.1什么是设计模式
    • 6.2了解OO 设计的基本原则
    • 6.3了解OO开发有何优势/li>
    • 6.4OO开发过程有几个步骤/li>
    • 掌握用例图的组成和画法，用例的几个要素的含义
    • 掌握用例图的实例解析方法，如何辨识和确定一个用例/li>
    • 用例模型相关建模步骤是什么/li>
    • 用例图、类图等针对面向对象的项目开发的意义是什么/li>
    • 熟悉类图中各个类之间的基本关系分类及其含义。 //状态图的含义及用途。
    • 绘制类图最常用的方法及步骤是什么/li>
    • 绘制类图的步骤：确定类和属性、确定行为、绘制
    • 熟悉用例图、类图、状态图的组成和画法。
    • 了解UML其他图示结构的基本用途。
  • 第七章
  • • //7.1为什么说编码工作纷繁复杂甚至令人气馁/li>
    • 7.2一般性的编程原则应该从哪三个方面考虑/li>
    • //7.3论述编码阶段实现某种算法时说涉及的问题。
    • 7.4在编程程序内部文档时，除了ＨＣＢ外，还应添加什么注释信息意什么/li>
    • 7.5敏捷方法的大致思想/li>
    • 7.6什么是极限编程（Extreme Programming，ＸＰ）/li>
    • 7.7什么是派对编程(Pair Programming)/li>
  • 第八章
  • • 8.1.了解 产生软件缺陷的原因/li>
    • //8.2将软件缺陷进行分类的理由：
    • 8.3几种主要的故障类型：
    • 8.4什么是正交缺陷分类/li>
    • 8.5测试的各个阶段及其任务及的文档图8.3）
    • //8.6测试的态度问题（为什么要独立设置测试团队
    • 8.7掌握测试的方法——黑盒、白盒的概念/li>
    • 8.8什么是单元测试/li>
    • //8.9什么是走查和检查/li>
    • 8.10黑盒、白盒方法各自的分类试用例的设计和给出方法。
    • 8.11如何面对一个命题，设计和给出测试用例的问题。（课件）
    • 8.12集成测试及其主要方法的分类驱动模块、桩模块的概念）
    • 8.13传统测试和OO测试有何不同O测试有何困难/li>
    • // 8.14测试计划涉及的几个步骤（了解）
  • 第九章
  • • 9.1系统测试的主要步骤及各自含义图9.2）
    • // 什么是系统配置件配置管理// 基线或见课件）
    • 9.2什么是回归测试/li>
    • 9.3功能测试的含义极其作用/li>
    • 9.4功能测试的基本指导原则/li>
    • 9.5性能测试的含义与作用/li>
    • 9.6性能测试的主要分类/li>
    • // 什么是可靠性、可用性和可维护性/li>
    • 9.7.确认测试概念，确认测试分类基准测试和引导测试）
    • 9.8.什么是alpha测试测试/li>
    • 9.9.什么是安装测试/li>

第一章

1.1软件工程（SE）的定义、目的、方法、作用：

定义：在将有关软件开发与应用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件的理论和技术的工程方法学，一些开发和维护软件的方法、过程、原则。是一个系统工程，既有对技术问题的分析与综合，也有对开发过程和参与者的管理。
目的：以计算机科学理论和计算机功能为基础，通过对要解决问题的本质的了解，采用相应的工具和技术，实现设计方案，推出高质量的软件产品。
在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。
方法：面向对象模式，结构化模式，基于过程的模式等。
作用：付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，开发的软件易于移植，需要较低的维护费用，能按时完成开发工作，及时交付使用。

//1.2开发模式：

表示开发软件时特定的方法或哲学。是软件开发的全部过程，活动和任务的结构框架，它能直观的表达的表达软件开发全过程，明确要完成的主要活动，任务和开发策略。

1.3说明错误、缺陷和失败的含义及联系（并举例）：

错误(error)：是在软件生产过程中人为产生的错误（如：需求说明中的错误，代码中的错误）
缺陷（故障fault）：是在软件功能实现过程中产生的问题；是错误导致的结果，是在软件中一个错误的表现（如：代码写错了导致系统无法启动，一个错误可能产生多个缺陷，静态存在的）
失败(failure)：是相对于系统指定行为的偏离，在运行时，软件系统违背了它应有的行为（如：使用者发现某个计算功能算不出结果，是动态存在的）
联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图， 从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

1.4软件质量应从哪几个方面衡量，论述之：

1、产品(product)的质量
用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。
2、过程(process)的质量
有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
3、商业(business)环境背景下的质量
(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。
误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

//1.5软件系统的系统组成（系统的要素有哪些）： 对象（实体）+ 活动 + 关系 + 系统边界

活动：活动是发生在系统中的某些事情，通常描述为由某个触发器引发的事件，活动通过改变属性把一个事物变成另一个事物。
对象：活动中涉及的元素称为对象。
关系：是指活动与对象之间的关系。
系统边界：即系统包含的功能与系统不包含的功能之间的界限。

1.6现代软件工程大致包含几个阶段及各个阶段的文档：

（1）需求分析：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格 说明书》】与复审（所有人）。
（2）系统设计：包括用户界面的设计【《SAD》即《软件系统结构图》：如何制作软 件】与复审（开发者与客户）。
（3）程序设计：包括模块功能算法与数据描述设计【相关文档】与复审（开发者）。
（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。
（5）单元测试：模块功能测试与性能测试【测试 告】与复审（测试团队）。
（6）集成测试：按照结构图进行测试【测试 告】与复审（测试团队）。
（7）系统测试：按《SRS》对系统总体功能进行测试与复审（开发者与客户）。
（8）系统提交：交付产品【用户手册和操作手册】与复审。
（9）系统维修：修改软件的过程，为改错或满足新需求【维修 告】与复审（维修团队）。

//1.7使现代软件工程实践发生变化的关键因素是什么/h3>

（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域 和广域
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性

1.8什么是软件过程件过程的重要性是什么含几个阶段/h3>

软件开发活动中的各种组织及规范方法（课件定义）
软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。
（1）它强制活动具有一致性和一定的结构。
（2）过程结构允许我们分析、理解、控制和改进组成过程的活动，并以此来指导我们的活动。
（3）它使我们获取经验并把经验传授给他人。

1.9什么是重用、抽象等现代软件工程主要概念/h3>

第二章

2.1什么叫过程（生命周期）/h3>

过程是一组有序的任务，它涉及活动、约束和资源使用的一系列步骤，用于产生某种想要的输出。
过程不仅仅是步骤，过程是步骤的集合，它将步骤组织起来使人们能够生产满足一系列目标和标准的产品。
我们有时也把涉及产品构建的这种过程称为生命周期。软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

2.2什么是软件过程件过程的重要性是什么件生命周期/h3>

软件过程：将软件开发过程中的一组有序的任务称为软件过程，它涉及活动、约束和资源使用的一系列步骤，用于产生某种想要的输出。
重要性：（1）通用性：它强制活动具有一致性和一定的结构，使程序的集合组合起来以产生满足目标和标准的产品，（2）指导性：过程结构允许我们分析、理解、控制和改进组成过程的活动，并以此来指导我们的行动（3）它能使我们获取经验并把它创收给他人。
软件生命周期：问题定义及规划阶段，需求分析/评审阶段，软件设计阶段，软件编码阶段，软件测试阶段，软件运行维护阶段。 1、需求分析2、系统设计3、程序设计4、软件开发5、单元测试6、集成测试7、系统测试8、系统提交9、维护

2.3瀑布模型及各阶段文档，优缺点

瀑布模型：瀑布模型线性地安排每一个阶段，将开发阶段描述为从一个开发阶段瀑布般地转换到另外一个阶段，一个开发阶段必须在另一个开发阶段开始之前完成。瀑布模型从一种非常高层的角度描述了开发过程中进行的活动，并且提出了要求开发人员经过的时间序列。
瀑布模型的各阶段文档：
需求分析：《SRS》软件需求规格说明书
系统设计：《SAD》系统设计文档
程序设计：模块功能算法和数据描述文档
编码：源程序和注释
单元测试和集成测试：单元测试 告
系统测试：系统测试 告
验收测试：验收测试 告
运行与维护：维护 告
优点：
（1）它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。
（2）每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。
（3）瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。
缺点：
（1）除了一些理解非常充分的问题之外，实际上软件是通过大量的迭代进行开发的。
（2）软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

2.4什么是原型途/h3>

原型是一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。
用途：
1、原型化设计可以使开发者更容易地提高软件质量。
2、原型化设计可以提供多种解决方案供用户选择。

2.5论述分阶段（阶段化）开发模型的含义、其基本分类和特点（运行系统和开发系统的概念）

含义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。
cycle time(循环时间): 软件开发时整理需求文档时间与系统提交时间之差(P55)
production system(产品系统): 用户正在使用的版本
development system(开发系统): 准备代替现有产品系统的下一个版本
分类：（1）增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
（2）迭代开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。
（3）增量式+迭代式结合开发：一个新发布的版本可能包含新功能，并对已有功能做了改进。
特点：（1）即使还缺少某些功能，但在早期的发布中就可以开始培训。
（2）可以及早为那些以前从未提供的功能开拓市场。
（3）当运行系统出现未预料到的问题时，经常性的发布可以使开发人员能全面、快速地修复这些问题
（4）针对不同的发布版本，开发团队将重点放在不同的专业领域技术上。

2.6螺旋模型的含义、目的、四个象限的任务及四重迭代（四重循环）的含义

//含义：螺旋模型将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
//目的：把开发活动和风险管理结合起来，以将风险减到最小并控制风险。
螺旋模型每次迭代有四个任务，依次是（四个象限）：计划、目标/可选方案、风险评估、开发与测试。
螺旋模型共有四次迭代，依次是（每个象限的四重循环），依次是操作概念、软件需求、软件设计、开发与测试。系统实现与执行

每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。当风险确认之后，项目经理必须决定如何消除或最小化风险。

//—— 习题2， 3。
//在所有的软件开发模型中，你认为哪些过程给予你最大的灵活性以应对需求的变更br> 阶段开发模型和螺旋模型

2.7什么是UP、 RUP、进化式迭代等市场流行的过程模型

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。该模型的四个阶段：开始阶段、确立阶段、构建阶段和移交阶段。每个阶段可以进一步划分为多次迭代。该模型的六道核心工序：业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。
补充:统一过程（UP）可以用三句话来表达：它是用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架，它使用对象管理组织（OMG(Object Management Group)）的UML 并与对象管理组织（OMG）的软件过程工程原模型（SPEM（Software Process Engineering Meta-Model ）软件过程工程元模型）等相兼容。
RUP（Rational Unified Process），是IBM提出的提供支持和包装的UP模型。统一软件开发过程，统一软件过程是一个面向对象且基于 络的程序开发方法论。
进化式迭代开发（Iterative development）是统一开发过程(RUP)的关键实践。开发被组织成一系列固定的短期小项目。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试。随着时间和一次次迭代，系统增量式完善。

第三章

3.1什么是项目进度动程碑目成本/h3>

项目进度：是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。
活动：项目的一部分，一般占用项目进度计划中的一段时间
里程碑（Milestone）指特定的时间点，标志着活动的结束，通常伴随着提交物。（如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档）
项目成本(project costs)：为支持软件开发而购买软件和工具的开支,用于支持需求分析,设计,编码,测试,处理需求变更等等,另外加上工作量开支。

3.2如何计算软件项目活动图的关键路径习题2，3）冗余时间早和最迟开始时间（课堂习题讲解）（见智库P24－25

关键路径（Critical Paths）：从起点到终点总花费时间最长的路径，即这个项目的最短完成时间，因为如果这条路径无法完成那么整个项目都不能算完成。所以这条路径上的任务耽误一点都会影响最后项目完成时间。
关键路径法（CPM）：时差=可用时间-真实时间=最晚开始时间-最早开始时间
冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

//3.3软件人员应该具备的能力是什么/h3>

（1）完成工作的能力（2）对工作的兴趣（3）开发类似应用的经验（4）使用类似工具或语言的经验（5）使用类似开发环境的经验（6）使用类似技术的经验（7）培训（8）与其他人交流的能力（9）与其他人共同承担责任的能力（10）管理技能

3.4软件项目团队组织的基本结构

主程序员：总体负责系统的设计和开发，其他小组成员向该主程序员汇 ，主程序员对每一个决定有最终决策权。主程序员监督所有其他小组成员、设计所有程序、把代码开发分配给其他小组成员。
副主程序员（后备程序员）：在必要时替代主程序员。
资料员：负责维护所有的项目文档，编译和链接代码，并对提交的所有模块进行初步测试。
(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇 ，主程序员对每一个决定有绝对决策权。
优势：使交流最小化迅速做出决定
缺点：创造性低；对主程序员要求高，个人主观性强
(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针 对个人的。
一般软件项目的团队组织结构是介于以上两个极端之间的。
(3) 项目组织的结构化
结构化较强的团队：按时完成任务，单工作比较循规蹈矩，项目普通但是功能完备。适合人员较多，项目稳 定性和一致性高，使用较正规的结构。
结构化较弱的团队：不能按时完成任务但是创造性强，涉及大量的不确定性因素时采用较为民主的方法和相关的团队结构

//3.5专家估算法的大致含义：

很多工作量估算方法依赖于专家的判断。使用专家的知识和经验，对软件项目的工作量进行评估，预测的精确性基于估算者的能力、经验、客观性和洞察力。是对构建整个系统或其子系统所需的工作量做出经验性的猜测。
主要有类推法，Delphi技术，Wolwerton模型（该模型受变化和主观性的影响，还受当前数据相关性的影响 ）（x+4y+z）/6对个人估算的规范化

//3.6算式估算法的大致含义：

研究人员已经创建出表示工作量和影响工作量的因素之间关系的模型。这些模型通常用方程式描述，其中工作量是因变量，而其他因素是自变量。大部分模型认为项目规模是方程式中影响最大的因素，表示工作量的方程式是：E = (a + bS^c) m(X)
其中S是系统规模的估算，而a、b、和c是常量。X是从x1到xn的一个成本因素的向量，m是基于这些因素的一个调整因子。

3.7试述COCOMO模型的三个阶段基本工作原理或含义：

COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化， 逐渐准确。E = bSc m(X)
在阶段一，项目通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。这时，人们对正在创建的最终产品可能的规模知之甚少，因此COCOMOⅡ用应用点来估算规模。
在阶段二，即早期设计阶段，已经决定将项目开发向前推进，但是设计人员必须研究几种可选的体系结构和操作的概念。同样，仍然没有足够的信息支持准确的工作量和工期估算，但是远比第一阶段知道的信息要多。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
在阶段三，即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

3.8什么是软件风险了解主要风险管理活动几种降低风险的策略/h3>

概念：软件生产过程中不希望看到的，有负面结果的事件。
方面：风险损失，风险概率（相乘为风险暴露Risk Exposure)，即数学期望）
风险管理活动：
风险评价：风险识别，风险分析，风险优先级分配
风险控制：风险降低，风险管理计划，风险化解。
降低风险的策略：
避免风险（Avoiding the risk）：改变功能和性能需求，使风险没机会发生。比如用 C 语言的程序有内存泄漏的风险改用 Java，避免风险。
转移风险（Transferring the risk）：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。
假设风险（Assuming the risk）：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

3.9弄懂活动图基本原理（参考课本），找出课后练习题图3.23和3.24的关键路径。

(1) Modeling 初始建模:尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构风格
(2) Analysis 分析:分析初步的体系结构，主要关注软件系统的质量属性性能、安全性、可靠性等、各种约束等等。关注系统级别决策
(3) Documentation 文档化:确定各个不同的模型视图。
(4) Review 复审:检查文档是否满足了所有需求。
(5) final output输出文档: SAD:Software Architecture Document 软件体系结构文档， 用来和开发团队中其他人员交流系统级别设计决策的有力工具。

//5.4三种设计层及其关系

设计分三层：体系结构、代码设计和可执行设计
（1）体系结构将需求格式说明中确定的系统能力与实现这些能力的系统构件关联起来。
（2）代码设计包含算法和数据结构
（3）可执行设计在比代码设计的层次还要低的静态层次处理代码设计，讨论内存分配、数据格式、位模式等
关系：自顶向下设计有益的：首先设计体系结构，然后进行代码设计，最后是可执行设计

//5.5什么是模块化么是抽象/h3>

模块化：在模块化的设计中，构件清晰地定义了输入和输出，设计目标明确，功能独立，可以做独立测试。
抽象：对细节的隐藏称为抽象，是基于某种归纳水平的问题描述，是我们集中于问题的关系。

5.6论述设计用户界面应考虑的问题

(1)设计界面要注意解决的要素：
①隐喻：可识别和学习的基本术语、图像和概念等
②思维模型：数据、功能、任务的组织与表示
③模型的导航规则：怎样在数据、功能、活动和角色中移动及切换
④外观：系统向用户传输信息的外观特征
⑤感觉：向用户提供有吸引力的体验的交互技术
(2) 文化问题：需要考虑使用系统的用户的信仰、价值观、道德规范、传统、风俗和传说。两种解决方法：①使用国际设计/无偏见设计，排除特定的文化参考或偏见②采用定制界面，使不同用户看到额界面
(3) 用户偏爱：为具有不同偏好的人选择备选界面

5.7 5.5节—-模块独立性—-耦合与内聚的概念及各个层次划分/h3>

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。
内聚是软件内部组成成分的关联程度。
耦合指的是两个软件间的关联程度。
耦合的概念，如何分类br> 耦合度是指两个软件之间的相互关联程度，耦合程度取决于模块之间的依赖关系的多少，可以划分为紧密耦合、松散耦合和非耦合。模块之间的依赖关系有：一个模块引用另一个模块、模块间传递数据量、某个模块控制其他模块的数量。为了使模块可以独立设计和修改，应尽可能减少耦合度。模块耦合有六个级别，从高到底依次为：
(1) 内容耦合 content：一个模块实际上修改了另一个模块，被修改的模块完全依赖于修改他的模块。可能的情况有：一个模块修改另一个模块内部数据项或代码，或分支转移 到另一个模块。如 goto 语句
(2) 公共耦合 common：不同模块可以从公共数据存储区来访问和修改数据。
(3) 控制耦合 control：一个模块通过传递参数或返回代码来控制另一个模块的活动
(4) 标记/特征耦合 stamp：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制
(5) 数据耦合 data：模块间传递的是数据值，这是最受欢迎的一种耦合。如一个数值被当做参数传递给另一个模块，这个数值在另一个模块中只会参与计算而非控制。
(6) 非耦合 uncoupled：模块相互之间没有信息传递，如两个毫无关系的方法，但是一般完全没有耦合是不现实的。

内聚的概念，如何分类br> 内聚度是指模块内部各组成成分（如数据、功能、内部模块）的关联程度，内聚度越高， 模块各成分间相互联系越密切，与总目标越相关。内聚分为低内聚和高内聚。
(1) 偶然内聚 coincidental：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法
(2) 逻辑内聚 logical：模块中各部分只通过代码的逻辑结构相关联， 会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。比如因为有相同的某一个计算步骤而放在 一起的两个没有关系的计算。
(3) 时间内聚 temporal：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。
(4) 过程内聚 procedurally：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关 活动和针对相关目标，如写数据->检查数据->操作数据这一过程
(5) 通讯内聚 communicational：各部分访问和操作同一数据集，如将来自于同一传感器的所有不相干数据取出这一模块
(6) 顺序内聚 sequential：各部分有输入输出关系，操作统一数据集，并且操作有顺序
(7) 功能内聚 functional：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序
(8) 信息内聚 information：功能内聚的基础上调整为数据抽象化和基于对象的设计

5.8软件过程中复审的概念，设计复审的重要性

复审定义：检查文档是否满足所有功能及质量需求。
两种设计检验的方法：
(1) 验证verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确
(2)确认validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确 性，强调做的东西正确。
(3)验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想 要的一致。
重要性：
(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流。
(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。
重要性：
1、可以和用户一起检查软件的概要设计。
2、可以向开发者呈现并明确软件的技术设计。
3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

概念设计复审：与客户和用户一起审查概念设计
技术设计复审：向开发者介绍技术设计
程序设计复审：程序员在实施前获得对其技术设计的反馈
重要性：加强和鼓励在项目中使用一种共同的编码风格，发现自动测试发现不了的错误

第六章

//什么是面向对象br> 面向对象是一种软件开发方法，它将问题和问题的解决方案组织为离散对象的集合，数据结构和行为都包含在对象的表示中。

//面向对象有什么特征何使用高级语言实现这些基本// 特征br> （1）标识（2）抽象（3）分类（4）封装（5）继承（6）多态（7）持久性
// 掌握并使用高级语言的OO基本编程方法和技巧。

6.1什么是设计模式

是一套被反复使用的（多数人知晓并经过分类编目的）代码设计经验的总结，使用设计模式目的是为了可重用代码、让代码更容易被他人理解并且保证软件质量。
（软件开发方法。一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。）
面向对象设计模式：简单工厂模式。工厂方法模式。抽象工程模式。观察者模式。单例模式。桥梁模式。责任链模式。适配器模式。代理模式。策略模式。

6.2了解OO 设计的基本原则

单一职责原则（SRP）、重用原则、开闭原则（OCP）、里氏替换原则（LSP）、
依赖倒置原则（DIP）、接口分隔原则（ISP）、迪米特法则

6.3了解OO开发有何优势/h3>

（1）语言的一致性。采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案
（2）过程的一致性。全开发过程的一致性：从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

6.4OO开发过程有几个步骤/h3>

OO 需求分析和定义+OO 高层设计+OO 底层设计+OOP+OO 测试
面向对象需求分析、面向对象高层设计、面向对象底层设计、面向对象编程、面向对象测试。

掌握用例图的组成和画法，用例的几个要素的含义

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
用例：描述系统提供的特定功能，用椭圆表示（画法：○）
执行者：和系统交互的实体（用户、设备或其他），用小人表示（画法：小人）
包含：对已定义用例的复用，用以提取公共行为，用带箭头的实线表示（画法：→）
扩展：对一个用例的扩展使用，以说明一个不同的或更深入的观点（画法：→ 下面加个extends）

掌握用例图的实例解析方法，如何辨识和确定一个用例/h3>

用例模型相关建模步骤是什么/h3>

用例图、类图等针对面向对象的项目开发的意义是什么/h3>

对功能的完整描述；便于用户、设计者、测试者之间的交流；是系统分析中更多正是建模的基础。
用例：描述了应该执行或展示的特定功能
用例图：通过建立用户、外部项、其他实体的对话模型，而对系统将要完成的功能进行描述或刻画。
这些表示法每种都显现了系统的某个方面，因此相应地，这种表达也提供了对于问题或解决方案的详细描述。

熟悉类图中各个类之间的基本关系分类及其含义。 //状态图的含义及用途。

泛化：在一个继承关系中，超类泛化子类。
关联：两个类一起出现，并且它们之间的关系必须保持一段时间。
聚合：一个类是另外一个类的一部分。松散的部分与整体的关系。聚合关系中的成员对象是整体对象的一部分，但是成员对象可以脱离整体对象存在（此时不会影响整体对象的定义，
组装：强的部分与整体的关系。组合关系中整体对象可以控制成员对象的生命周期，一旦整体对象不存在，成员对象也将不存在，两者是共生关系。
依赖：一个项的定义发生改变，则会引起另外一个项的改变变化。

绘制类图最常用的方法及步骤是什么/h3>

绘制类图的步骤：确定类和属性、确定行为、绘制

熟悉用例图、类图、状态图的组成和画法。

了解UML其他图示结构的基本用途。

类图的结构
类名：定义一个类
属性：用名称、类型、初始值来描述它
操作：用名称、参数列表、返回类型来描述它
类图中各个类之间的基本关系以及画法
继承：直线 + 空心三角箭头，子类指向超类
包含：直线 + 折线箭头，指向被包含的类（可能是双向的甚至指向本身）
聚合（成员对象可以脱离整体对象存在）：在包含箭头的尾部加一个空心菱形
组合（整体对象不存在时，成员对象也会消失）：在包含箭头的尾部加一个实心菱形
依赖（某个类的方法使用另一个类的对象作为参数）：虚线 + 折线箭头
接口实现：虚线 + 空心三角，类指向接口
UML 图示结构的基本用途
需求过程：
工作流程图：建立对象模型——概念类图
对象图：解释每一个对象
活动图：当一个对象的值发生变化时，显示系统中可能发生的所有活动
状态图：显示一个对象可以采取的所有状态
顺序图：显示信息如何从一个对象流向另一个对象，使需求中的事件的非正式描述正规化
协作图：使用对象和序列信息来显示对象之间的事件流
组件图：反映最终的系统模块和相互依存关系
状态图：寻找主要的状态、确定状态之间的转换，细化状态内的活动与转换，用复合状态来展开细节。
用例图：用函数定义类
执行者：可能使用这些用例的人或外部程序。
用例：对系统提供的功能（或称系统的用途）的一种描述。
类图：描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对 象的类型及对象间的静态关系（关联、子类型等关系）
包图：显示类是如何被划分为模型的。包图也存在类图里面的继承、引用等依赖关系，也包含接口，接口与包之间用带 小圆圈的实线相连。
序列图：序列图中的对象可以是并发执行的，每一个对象有自己运行的线程控制着。这时，需 要通过激活、异步消息、同步控制和活动对象来表示。序列图有两种，一种是描述特定对象 之间生存期中消息通信的所有情节，称作一般序列图；一种是描述消息通信的个别情节的实 例序列图，如果需要描述所有的情节，则需要多个实例序列图。
部署图：部署图描述了系统在运行时的物理结构、配置和关系，涉及处理器、设备、通讯 等硬件单元和软件部件。部署图的描述是基于代表硬件单元的节点之上的。

第七章

//7.1为什么说编码工作纷繁复杂甚至令人气馁/h3>

（1）设计人员可能没有处理平台和编程环境的所有特性。易于用图表描述的结构和关系并不是总能够直截了当的编写成代码
　（2）我们必须以这样一种方式编写代码：不仅要在再次使用代码进行测试的时候便于自己理解，而且当系统随着时间演化时，也便于他人理解
　（3）在创建易于复用的代码的同时，还必须利用这些特征：设计的组织结构、数据结构、编程语言的概念。

7.2一般性的编程原则应该从哪三个方面考虑/h3>

（1）控制结构（程序如何传递数据）：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
　（2）算法（程序如何处理数据）：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
　（3）数据结构（程序如何储存数据）：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

//7.3论述编码阶段实现某种算法时说涉及的问题。

（1）编写更快代码的代价。可能会是代码更加复杂，从而要花费更多的时间编写代码
　（2）测试代码的时间代价。代码的复杂度要求有更多的测试用例或测试数据
　（3）用户理解代码的时间代价。
　（4）需要修改代码时，修改代码的时间代价。

7.4在编程程序内部文档时，除了ＨＣＢ外，还应添加什么注释信息意什么/h3>

需要添加其他程序注释——
（1）解释性注释：本段源代码是在做什么的注释。
（2）分解性注释：通过注释将代码分解成多个段。
（3）版本注释：随着时间进行修改的记录。
注意的问题：
1、分段注释
2、注释和代码要一并更改。
3、注释要有意义。
4、一边写代码一边写注释，不要写完代码回过头来添加注释。

7.5敏捷方法的大致思想/h3>

含义：以人为核心、迭代、循序渐进。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
敏捷宣言四条原则：个体和交互的价值胜过过程和工具（个人的卓越创意），可以工作的软件胜过面面俱到的文档（文档非软件），客户合作胜过合同谈判，响应变化胜过遵循计划。
上述四条原则反映了敏捷方法的软件过程倾向性
特点：（1）规则游戏（2）小的发布（3）隐喻（4）简单设计（5）首先编写测试（6）重构（7）对编程（8）集体所有权（9）持续集成（10）可以忍受的步伐（11）在现场的客户（12）代码标准
目标：通过尽可能早地、持续地交付有价值的软件使客户满意。

7.6什么是极限编程（Extreme Programming，ＸＰ）/h3>

极限编程是敏捷过程的一种具体形式，提供敏捷方法最一般原则的指导方针。
四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则
XP的支持者强调敏捷方法的4个特性（准则）：交流、简单性、勇气以及反馈。
交流是指客户与开发人员之间持续地交换看法；简单性激励开发人员选择最简单的设计或实现来处理客户的需要；勇气体现在今早地和经常交付功能的承诺；在软件开发过程中的各种活动中，都包含反馈循环。例如，程序员一起工作，针对实现设计的最佳方式，相互提供反馈；客户和程序员一起工作时，以完成计划的任务。

7.7什么是派对编程(Pair Programming)/h3>

第八章

8.1.了解 产生软件缺陷的原因/h3>

故障：由错误（error）引起的系统内在问题。
(1)软件本身，系统处理大量的状态，复杂的公式，活动，算法等；
(2)客户不清晰的需求；
(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

//8.2将软件缺陷进行分类的理由：

在编码完程序构件之后，我们通常对代码进行检查，以找出故障并立刻去除它们。当不存在明显的故障时，我们测试程序，通过创造一些条件，是代码不能像计划的那样做出反应，看一看能否发现更多的故障。因此，知道我们正在查找什么类型的故障是很重要的。

8.3几种主要的故障类型：

(1)算法故障(algorithmic fault)：由于处理步骤中的某些错误，使得对于给定的输入，构件的算法或逻辑没有产生适当的输出。
(2)计算故障(computation