面向对象软件工程-学习笔记

面向对象软件工程笔记

该笔记为复习东北大学软件学院复试时整理

第一章 面向对象软件工程概述及范畴

0.软件：软件是计算机系统中与硬件相互依存的控一部分，它是包括程序，数据及其相关文档的完整集合。

1.软件危机：是指软件开发和维护过程中存在的周期长、成本高、质量低的问题，包括两点：

1）如何开发软件，以满足对软件日益增长的需求。

2）如何维护数量不断膨胀的已有软件。

2.软件工程：是以质量为核心，为了经济的开发满足客户需求的软件而研究、建立和应用的系统化的、有规则的、可度量的和可控制的工程原则、方法，设计软件过程、项目管理、开发方法、开发工具，甚至企业文化等各个方面。

3.历史方面：29%的项目是成功完成的，18%的项目在完成之前被取消或者根本没有实现，53%的项目虽然完成但是不是超出预算就是延期交付，或者是缺少功能和特性。

4.经济方面：使用新技术会导致两个问题：第一个是将新技术引入一个软件组织的花费，第二个是维护问题。

5.生命周期模型：对开发一个软件产品所需要步骤的描述

6.生命周期：从概念开发到最终退役，所需完成的一系列实际步骤，三个阶段八个步骤

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EnJJGCfv-1647774618652)(E:\思维导图\传统软件生命周期.bmp)]

7.没有计划阶段的原因：计划活动贯穿整个生命周期

8.没有测试阶段的原因：应该对一个软件产品持续检查。伴随软件开发和维护的每一个阶段。

​ 应由软件质量保证（SQA）小组保证交付的产品就是客户所需要的，产品一直是以正确的方式打造的。

9.没有文档阶段的原因：文档活动应该和软件产品构造的所有其他活动一起进行

10.面向对象泛型：面向对象泛型将属性和操作视为同等重要的实体。

​ 面向对象泛型的主要优势包括：

1. 面向对象泛型支持信息隐藏，极大的减少了回归错误

   ArrayList list = new ArrayList(); list.add(1); obj = get(index)

2. 使开发变得更容易

3. 有良好设计的对象是一个独立的单元

4. 降低复杂度

5. 面向对象提倡重用

11.内部软件开发：客户和开发者属于同一组织

​ 合同软件：客户和开发者可能是完全独立的组织

​ 商用现货软件：软件制造商通过大规模销售分担成本

第二章 软件生命周期模型

迭代-增量模型优点：

1. 可多次验证产品的正确性

2. 在生命周期中，能相对较早的确定底层体系结构的鲁棒性

​ 鲁棒性：处理扩展和改变而不致溃败的特性

3. 迭代增量能尽早降低风险

4. 任何时候都能获得软件的工作版本

5. 有采用迭代增量生命周期模型的实验证据

软件生命周期模型比较

第三章 软件过程

1. 如今主流面向对象方法学是统一过程

2. 模型是一组UML图，表示待开发软件产品的一个或多个方面

3. 开发团队的首要任务是从根本上理解应用领域

4. 软件开发的一个红药方面是业务模型文档

5. 有时把对客户需求的初步调查称为概念设计

6. 分析工作流的目标是分析并精化需求，以理解软件正确开发和易于维护所必须的需求细节

7. 为防止产生混淆，解决方法是采用两个独立的工作流

   1）.需求工作流按客户的语言来表达

   2）.分析工作流则采用更为精确的语言，以确保设计和实现工作流的正确实施。

   另外，在实施分析工作流时，添加更多细节，对开发人员十分重要。

8. 规格说明不能包含不严密的用语或者听起来明确但是实际上含糊的术语

9. 软件项目管理计划的主要部分包括：

   1. 交付能力（客户将得到的产品）
   2. 里程碑（客户得到产品的时间）
   3. 预算（将花费的成本）

10. 计划最为详尽的描述软件过程，包含：将采用的生命周期模型，开发组织的组织结构，项目责任，管理目标和优先级，将使用的技术和CASE工具，以及详细的进度、预算和资源分配。整个计划的基础是持续时间和成本估算。

11. 设计工作流的目标是精化分析工作流的制品，直至呗程序员用某种方式实现。

    设计工作流另一个重要方面是选择合适的算法。

12. 设计团队必须精确记录所做决定，因为：

    1. 设计时有时会进入死胡同，需要回溯

    2. 有助于未来改进

13. 实现工作流的目标是用所选定的实现语言实现目标软件产品

    一个大系统可能会被分成几个小的子系统，由多个团队完成，每个子系统都由代码制品组成。

14. 测试工作流的部分任务是验证设计正确性

    两个需要测试的主要方面：

    1. 每个人员都由责任确保其工作正确性，因此软件专业人员必须反复测试自己所开发和维护的产品

    2. 一旦软件专业人员确信某一产品的正确性，就将其提交给软件质量保证小组进行独立测试。

    测试工作流一个重要特性是可追溯性。

15. 如果在软件产品的整个生命周期中，可以对需求制品进行测试，则它们必须包含的一个属性就是可追溯性。

16. 已提交软件中的错误的主要来源是规格说明错误。

    效验分析制品的一种极佳方式是评审会议。

    评审的目的是判断分析产品的正确性。

    走查和审查是评审的两种类型。

17. 可测试性的一个重要方面是可追溯性

18. 设计评审需要管制的错误类型包括

    逻辑错误、接口错误、缺少异常处理，以及与规格说明不一致（最重要）

19. 质量保证小组在程序员测试结束后测试各个组件，叫做单元测试

    集成测试的目标是检测组件是否正确组合而得到满足规格说明的产品

    在集成测试时要格外注意测试组件接口

    完成集成测试后，SQA小组开始产品测试

    不仅要测试产品的正确性也要测试产品的鲁棒性。

    集成测试最后一个方面是验收测试—用实际数据进行测试。

    回归测试：维护期间，如果程序员判定预期的修改已经实现，必须使用先前的测试用例对产品再次进行测试，以保证产品其他方面的功能性未受影响。

20. 交付后维护的一个常见问题在于文档化，或者是缺少文档

21. 统一过程的阶段

    软件开发通常包含四个阶段

    初始阶段，细化阶段，构造阶段，移交阶段

    1. 初始阶段

    a) 初始阶段的目标是判定是否值得开发目标软件产品

    b) 第一步是获取领域知识，第二步是准确理解客户组织如何在领域内工作

    c) 初始阶段结束时，开发人员必须回答三个问题

    ​ i. 所提议软件产品的成本效率是否合算

    ​ ii. 所提议的软件产品能及时交付吗

    ​ iii. 软件产品开发有哪些风险？如何降低风险？

    d) 下一步是风险识别，主要包括三种主要风险

    ​ i. 技术风险

    ​ ii. 缺少正确需求

    ​ iii. 缺少正确体系结构

    2. 细化阶段

    a) 细化阶段的目标是精化最初的需求、精化体系结构、监控风险并精化风险的属性、精化业务用例，以及制定软件项目管理计划。

    b) 细化阶段的成功包括：

    ​ i. 完全的领域模型

    ​ ii. 完全的业务模型

    ​ iii. 完全的需求制品

    ​ iv. 完全的分析制品

    ​ v. 更新后的体系结构版本

    ​ vi. 更新后的风险清单

    ​ vii. 软件项目管理计划

    ​ viii. 完全的业务用例

    3. 构造阶段

    a) 构造阶段的目标是开发软件产品的第一个可操作版本

    b) 构造阶段的成果包括

    ​ i. 适当的初始用户手册及其他手册

    ​ ii. 所有制品

    ​ iii. 完全的体系结构

    ​ iv. 更新后的风险清单

    ​ v. 软件项目管理计划

    ​ vi. 更新后的业务用例（如果有必要）

    4. 移交阶段

    a) 移交阶段的目标是确保客户需求已真正得到满足

    b) 移交阶段的成果

    ​ i. 所有制品

    ​ ii. 完全手册

22. 能力成熟度模型是不考虑实际使用的生命周期模型而改进软件过程的一组相关策略

    能力成熟度模型SW-CMM

    1. 基于观点：新软件技术的使用本身并不能引起生产力和利润的提高，因为问题的本质在于如何管理软件过程。

    2. 定义了五个成熟度

    a) 初始级

    ​ i. 处于这一等级的组织必然不具备良好的软件工程管理时间。只能在一个特定的基础上完成每一项工作。

    b) 可重复级

    ​ i. 采用了基本的软件项目管理措施。计划和管理方面的技术来源于相似产品的开发经验。

    c) 已定义级

    ​ i. 软件生产过程完全文档化。

    d) 已管理级

    ​ i. 组织为每个项目设置质量与生产力目标

    e) 优化级

    ​ i. 目标是不断进行过程改进。

    ​ ii. 采用统计定量与过程控制技术来对组织进行指导。

    

第四章 软件团队

1. 团队组织

   Brook法则：给一个进度已经落后的团队增加成员，可能会使进度更加落后

2. 民主团队方式

   民主团队的基本原则是无我编程

   每个程序员都必须鼓励团队的其他成员为其找出代码中的错误

   民主团队：由多达10个的无我程序员组成的团队，没有单一领导者

   优点：查找错误积极，高效

   缺点：管理层难以接受

3. 主程序员团队方式

   1. 主程序员既是一位成功的管理者，也是一位娴熟的程序员，负责设计体系结构以及程序中任何重要或者复杂的部分。在主程序员的指导下，其他团队成员负责详细的设计以及编码工作。

   2. 后援程序员需要了解项目和主程序员一样。并完成黑盒测试用例的设计，以及其他独立于设计过程的任务。

   3. 秘书是最娴熟、高薪的重要程序员。编程木梳负责维护项目产品库以及项目文档。这包括

      源代码清单、JCL以及测试数据。程序员提交他们的源代码给编程秘书，编程秘书负责吧代码转换成机器可读的形式，变异、链接、加载、执行以及运行测试用例

   4. 程序员只需要负责编程。

4. 超越主程序员和民主团队

   

5. 同步-稳定团队

   优点：保证了单个程序员的创造性和创新性

   ​ 每天的同步措施确保了几百个开发人员为同一开发目标而合作，而不需要主程序员团队的沟通与协同特性

6. 敏捷过程团队

   所有代码由团队完成，团队中两个程序员共用一台计算机

7. 开源编程团队

   通常是无偿志愿者

8. 人力资源能力成熟度模型

   刻画了一个组织中人力资源管理和开发的最佳实践

   一个组织需要通过五个成熟度等级逐级进步

   每个成熟度等级都有自己的关键过程域

9. 选择合适的团队组织

   团队组织方式	优点	缺点
   民主团队	积极查找粗欧文而得到高质量代码 特别适用于解决难问题	有经验成员反感新手的评价不可外部加强
   经典主程序员团队.	纽约时报项目的巨大成功之处	不切实际
   改进的主程序员团队	许多成功案例	没有可比于纽约时报项目的成功案例
   现代层级式编程团队	茶瓯拍卖行团队经理、团队主管结构，不需要主程序员 可扩展 必要时支持分散决策	团队经理和团队主管的责任不明确时，容易产生问题
   同步-稳定团队	鼓励创造性 确保大量开发人员为共同目标协作	微软公司意外尚无该方法的应用案例
   敏捷团队过程	程序员不需要测试自己的代码 如果一个程序员离开不会有致使损失 缺少经验的程序员可以向他人学习 代码归小组所有	几乎没有关于绩效的依据
   开源团队	少数几个项目非常成功	应用范围很窄 必须有一个出色的策动者 需要高水平参与者

第五章 软件工程工具

1. 逐步求精

   逐步求精可以定义为一种方式：尽量延迟细节的确定，以便集中精力考虑重要问题

2. 成本效益分析法

   投资回收分析发和净资金现值法

   投资回收分析：是一个决定新系统所产生的经济效益超过它的开发费用所用时间长度的技术。回收期=投资额/年平均收益

3. 净资金现值法：一个方案的净资金现值定义为所得经济效益的现值之和减去该项目的投资的现值。

4. 成本/效益比较：净资金现值系数=净资金现值/投资额

5. 软件度量

   度量可以作为对潜在问题的早期警告系统

   代码行数LOC是一种度量产品规模的方法。

   对于每个工作流，可以用每人月来度量效率

   产品度量：用来描述产品本身某些方面。例如大小与可靠性

   过程度量：开发者用这些度量来推断关于软件开发过程的信息

6. CASE

   典型的操作包括估计资源需求、制作规格说明文档、执行集成测试，以及写用户手册

7. CASE的分类

   CASE最简单的形式是软件工具，它是有助于软件生产的某一个方面的软件产品。

   早期工作流（需求、分析、设计）中帮助开发者的CASE工具有时候称为高端CASE或者前端工具

   有助于实现工作流和交付后维护的称为低端CASE或者后端工具。

   CASE工具中重要的一类是数据字典，它是在产品中定义的所有数据的计算机化列表。

   每个数据字典记录的重要部分是对该项目的描述。

   数据字典与一致性检查器结合在一起会增强其功能。一致性检查器是一个工具，用来检查规格说明文档中的每个数据项是否都反映在设计中。

   数据字典的另一个用途是为报表生成器和屏幕生成器提供数据。报表生成器是用来产生生产报表所需的代码。屏幕生成器用来帮助软件开发者用于屏幕上数据定位所需的代码。

8. CASE的范围

   使用CASE技术的一个主要原因就是能够随时拥有精确的和实时更新的文档。

   程序员也需要在线文档和电子数据表和文字处理器。

   编辑工具指的是诸如文字编辑器、调试器和灵巧打印机等CASE工具。

   结构编辑器是一个懂得实现语言的文字编辑器。

9. 软件版本

   产品必须至少有两个版本：旧版本和新版本

   必须保存修订版n，因为不是所有人都能安装n+1，如果n有错误报告，需要分析新错误。

   操作系统必须同时包括两个变体

   变体是用来共存的

10. 配置控制

    每个制品的代码以三种形式存在

    1. 源代码

    2. 目标代码，由编译源代码得到，也称编译后代码

    3. 可执行加载镜像

    解决版本问题首先需要版本控制工具

    版本控制中使用的一个通用技术是每个文件的名字都是由两部分组成：文件名本身和修订版号码

11. 交付后维护期间的配置控制

    团队需要的是一种一次只允许一个使用者改变制品的机制

12. 基线

    维护管理者必须设置一条基线，即产品中所有制品的配置（版本集）。

    当尝试找到错误时，维护程序员将任何需要的制品的拷贝放到其个人空间。

    一旦决定了修改哪个制品以修正错误，程序员便冻结将要改变的制品的当前版本。

13. 产品开发过程中的配置控制

    一旦一个制品编码完成，它应该立即有其程序员来进行非正规测试

    配置控制不只在交付后维护中需要，在实现中也需要。

14. 建造工具 如果一个软件组织不打算购买全套的配置控制工具，那么至少要同时使用一个版本控制工具和一个建造工具。

第六章 测试

1. 软件系统中的差错是由开发人员的过错导致的

2. 故障是在软件运行中观察到的不正确的行为，它是差错的结果。错误是不正确结果的累积

3. 专业软件工程开发人员的任务是随时保证高质量的软件产品，换句话说，每一个参与项目的开发人员和维护人员都应该对他们应完成的任务负有检查和核对的责任

4. SQA小组的职责之一是确保开发者的产品是正确的

   SQA在软件开发的整个流程中都应该发挥作用

5. 在开发小组与SQA小组之间保持管理独立性是非常重要的

6. 设置一个管理独立的SQA小组的额外成本与它带来的收益相比是微不足道的。

7. 在软件公司非常小的情况下，最好1的做噶就是确保分析产品由不负责生产这些产品的某个人来检查，对于设计产品，编码产品等也要进行类似的处理

8. 测试软件而不运行测试用例称为基于非执行的测试。

   基于非执行的测试方法的例子包括：评审软件（仔细地读代码）和用数学方法分析软件

9. 检查文档应有非原作者的多为检察人员完成，并且应由一组具有不同技能北京的软件专业人员来共同检验，一位内这些专家具有的不同制式北京，这回极大的增加发现错误的概率。此外，一组由经验的人在一起工作通常会产生一种相互促进的效果

10. 走查和审查是两种类型的评审。

    走查比审查步骤少，而且没那么正式

11. 走查

    一个分析走查小组应该至少包含以下人员：一位负责攥写规格说明的小组代表，一位负责分析工作流的管理者，一个客户代表，以为即将进行下一个开发流程的小组的代表，以及一位SQA小组的代表

    每位评审者都应仔细阅读材料，并制作两个清单：一份评审者不明白的事项列表，另一份是这位审查者认为有错误的地方的清单

12. 管理走查

    改正错误不是走查小组的任务，他们只是把错误记录下来以备修改，原因如下：

    1.在走查的时间限制内，由委员会进行修改在质量上可能不如由受过必要技术训练的个人进行修改

    2.由5个人组成的走查小组进行修改与1个人修改的时间相同，且花费五倍资金

    3.并不是所有标记为错误的地方都有真正的错误。

    4.走查没有足够的时间来检测和修正错误

13. 实施走查的方式

    参与者驱动的方法

    文档驱动的方法

14. 走查工作负责人的主要任务是引出问题和鼓励讨论

15. 审查

    主要用于测试设计和代码

    审查比走查更加深入

    审查有五个正式步骤

    1.由负责生成文档的人提供待审查的文档的概要。在概要部分结束时，将文档分发给参加者。

    2.在准备阶段，每位参与者都试图去详细理解发放的文档。

    3.当审查工作开始时，首先一位参与者与审查小组的所有人一起通读整个文档，并且保证涉及了文档中的每个细节和分支。然后开始查找错误。

    ​ 审查的主要目的也仅仅是朝招错误。

    4.在修订阶段，负责文档的人员修正所有审查报告中提到的问题和错误。

    5.在跟踪阶段，主持者必须保证所有提到的问题都已经很好地解决了，或者这修正原先的文档，或者进一步澄清被误当成错误的事项。所有改动过的内容都应当再次检查，避免引入新的错误。如果送审材料中5%以上的篇幅重新修改了，那么就必须要重新召集审查小组进行审查。

16. 审查工作小组包括一位主持者、一位设计者、一位实现者和一位测试人员

17. 审查工作的一个重要的组成部分是一份潜在错误的清单

18. 审查工作的另一个重要成果是错误统计记录

19. 走查和审查的对比

    走查过程：准备，以及随后整个小组对文档进行分析。

    审查过程：概要，准备，审查，修订和跟踪，而且对于每一个步骤都由形式化的、严格的规定

    审查要比走查花更多的时间

20. 评审的优缺点

    评审是走查和审查方法的总称，并且有两个明显的优点。

    首先，评审是找出错误的一个有效途径

    其次，在软件开发的早期发现错误，就避免了在后期修正错误将要花费的昂贵成本

    然而，如果软件开发不是按照规范的流程进行的话，评审方法的有效性就会下降

21. 审查的度量方法

    审查速率：审查规格说明和设计文档时，记录下每小时审查的椰树；审查代码时，可以记录每小时审阅的行数。

    差错密度：检查每页和每千行代码能够发现多少错误。这个标准可以细化为主要错误密度和次要错误密度两种。

    差错检测率：每小时的审查工作检测到的主要和次要错误数。

    差错检测效率：每个人每小时检测到的主要和次要错误数。

22. 基于执行的测试：基于或部分基于在一直环境下用经过选择的输入执行产品得到的结果推断某产品的特定行为特性的过程

    这个定义有三个令人困扰的含义：

    1.首先，这个定义把测试看成一种推断的过程

    2.这个定义在谈到“已知环境”时也存在问题

    3.另一个有问题的地方是在这个定义所提到的“用经过选择的输入“

23. 如何测试这些实时系统

    使用仿真器

    仿真器是产品即将投放的运行环境的一个工作模型

24. 实用性是规格说明学科的范围内使用正确的产品时，用户满足需求的程度。

    实用性指出了软件在规格说明许可的输入下能否得到正确的输出。

25. 可靠性是对软件出现故障的频率和严重程度的度量

26. 健壮性基本上是一系列因素（如运行条件的范围、有效输入带来错误输出的可能性以及产品的输入无效时结构的可接受性）的函数

27. 性能是软件测试中必须关注的另外一个方面

28. 正确性是指当软件在规格说明许可的条件下运行时，其输出结果符合规格说明的要求，而与使用的计算资源无关。

29. 正确性证明是证明产品正确的一种数学技术。该技术有时被称为验证。

    正确性证明的一个重要方面是它应与设计和编程相伴而行

30. 测试工作实质上是破坏性的工作

31. 系统测试不应该由程序员自己来完成

32. 独立测试应该由SQA小组来完成

33. 当一个软件产品呗彻底废除的时候，对于它的测试工作才能够停止。

第七章 从模块到对象

1. 内聚

   

2. 耦合

   

3. 耦合的重要性：耦合越强，发生错误的倾向越大

4. 数据封装是抽象的一个例子。

5. 抽象后的基本理论概念仍然需要逐步求精

   1. 产品的设计基于高层次概念
   2. 根据数据结构以及咋子数据结构上执行的操作来设计低层次的组件

6. 从维护的角度考虑数据封装，一个基本问题是确定产品的哪些方面可能需要修改并设计产品，使将来修改产品的影响最小化。

7. 数据封装通过建华维护、降低回归错误发生概率的方式来支持数据抽象的实现

8. 一个数据类型以及在该数据类型实例上所进行的操作，这样的构造叫抽象数据类型

9. 抽象数据类型同时支持数据抽象和过程抽象。

10. 对象的重要性在于其具有信息隐藏、抽象数据类型、数据封装、高内聚低耦合模块、模块所拥有的一切特性，还具有本身的一些额外特性。

11. 对象是抽象数据类型的实例。也就是说，产品按照抽象数据类型进行设计，产品的变量是抽象数据类型的实例。但是定义对象为抽象数据类型的实例过于简单，还需要更多的东西，即继承

12. 信息隐藏技术能用来避免公共耦合

13. 把对象与合适的方法关联起来的行为称为动态绑定

14. 两种看待软件产品的方式：

    1. 只考虑数据，包括局部和全局的变量、参数、动态数据结构和文件
    2. 只考虑数据上执行的操作，即过程和函数

15. 面向对象和面向操作方法的缺点是：数据和操作是统一事务的两个方面，数据项不能改变，除非一个操作作用于该数据项。同样，与数据无关的操作毫无意义，即过程和函数。

16. 第一次做任何新事物花费的时间比后面的要多，有事称为这个最初阶段为学习曲线

17. 继承产生的问题

    1. 使用继承的一个主要原因是为了创建一个新的自雷，这个子类与它的父类差别很小，而且不会影响到它的父类或者继承层次结构中的其他祖先类。反之，一旦实现一个产品，任何对已存在类的改变都会直接影响到继承层次结构中它的所有子孙，脆弱的基类问题
    2. 第二个问题产生于继承的随意使用。除非明确阻止，否则子类继承它的父类们所有属性。从而导致一类结构变得巨大，产生存储上的问题。在任何适当的地方使用集成。
    3. 源自多态和动态绑定
    4. 使用任何语言都可能写出坏的代码。然而，因为面向对象语言支持各种构造，所以用面向对象语言比用传统语言更容易写出坏的代码。使用不当时，会给软件产品增加不必要的复杂性。因此，当时用面向对象泛型时，需要格外小心以确保代码有最高的质量。

第八章 可复用性和可移植性

1. 复用是指使用一个产品的组件来简化另一个功能不同的产品的开发

2. 复用两种类型机会复用（偶然复用）和有意复用（系统复用）

   1. 如果新产品的开发者意识到，先前开发的产品中有一个组件能用在新产品中，就是机会复用
   2. 如果专门为将来的可能复用构造软件组件的话，就叫系统复用

3. 有意复用的优点是：专门为以后产品的使用所构造的组件的副总可能会更容易更安全，因为这些组件通常是健壮的、文档说明完善并且经过全面测试的。另外它们通常风格一致，维护更容易。

4. 有意复用的缺点是：昂贵，花费时间，不一定呗复用，可能得不到回报。

5. 复用的障碍：

   1. 别人不愿意使用-非我发明
   2. 复用是昂贵的。建造可复用组件的成本、复用组件的成本以及定义和实现一个复用过程的成本。
   3. 复用商业现货供应组件时，很难获得源代码，限制了可扩展性和可修改性。

6. 模块本质上是一个对象

7. 库复用的一个问题是，库通常以一组可复用代码制品集合的形式存在，而不是可复用设计。

8. 应用架构包含了设计的控制逻辑

9. 特定应用操作插入的地方称为热点

10. 架构通常只一个面向对象的应用架构

11. 复用一个架构进行产品开发比复用一个工具包快

    原因如下：

    1. 多数设计随架构一起复用，因此，需要从头开始设计的部分更少。
    2. 与操作相比，在架构中被复用的设计部分通常更难设计，因此最终设计的质量也可能比复用工具包高。

12. 软件体系架构领域面临各种设计问题，包括基于组件的产品组织、产品及的控制结构、通信和同步问题、数据库和数据访问、组件的物理分布、性能自己设计选择等。

13. 软件体系结构包含建造系统的要素的描述及要素之间的相互作用、指导要素进行组合的模式以及对这些模式的约束。

14. 体系结构模式是实现体系结构复用的另一种方法。一个流行的体系结构模式是模型-试图-控制器（MVC）体系结构模式。另一个是三层体系结构：表示逻辑层接受用户的输入并产生输出，与GUI对应；业务逻辑层包含业务规则处理；数据访问逻辑层与底层数据库进行通信。

15. 基于组件的软件工程的目标是构造一个可复用组件的集合。

16. 适配器设计模式

    

17. 桥接设计模式

    目的：把抽象和实现相分离，使其中一个的改变独立于顶一个。桥接模式有时称为驱动。

    桥接模式可看做是通过封装来实现信息隐藏的一种方法。

    

18. 迭代器设计模式

    一个聚集对象是包含由其他对象所组成的单元的对象。

    一个迭代器是一个程序结构。能进行访问和遍历操作。

    

19. 抽象工厂设计模式

    

20. 设计模式范畴

    

21. 设计模式优点：

    1. 促进复用
    2. 能提供高水平文档
    3. 存在许多设计模式的实现
    4. 容易理解

22. 设计模式缺点：

    1. 程序员可能会被暗示当前语言不够强大
    2. 没有系统的方法来确定何时以及如何应用设计模式
    3. 需要使用多种交互模式
    4. 对已经使用传统反省构造的软件进行维护时，不能在本质上改进类和对象

23. 使用复用的理由：

    1. 缩短开发过程
    2. 减少维护产品的时间和费用

24. 移植遇到的问题：

    1. 硬件不兼容
    2. 操作系统不兼容
    3. 数值计算软件不兼容
    4. 编译器不兼容

25. 可移植的系统软件两种技术：

    1. 对任何依赖于实现的相关部分进行隔离
    2. 使用抽象层次

26. 已知数据最安全的方法是构造一个非结构化的文件，它最容易移植到目标机器

27. 基于Web的应用程序能获得很高的可移植性

第九章 计划与估算

1. 与软件开发有关的成本有两种

   1. 内部成本（开发成本）----开发团队、项目管理人员和项目相关的支持人员的薪水；开发产品的软硬件成本；一般的管理费用，如水电费、租金和高管的薪水。
   2. 外部成本：报给客户的价格

2. 产品规模的衡量标准：

   1. 代码行数LOC
   2. 千行交付的源代码指令

3. 产品规模S=给定其文件数量Fi+信息流数量Fl+过程数量Pr

4. 成本估算技术

   1. 基于类比的专家决策

   2. 自底向上的估算方法：把整个产品分成较小的组件。先对每个组件单独进行周期和成本进行估算，在组合起来得到一个整体的数字

   3. 算法化成本估算模型：需要一个衡量指标。估算着计算度量指标的值，然后使用该模型计算出周期和成本。优于专家们的观点

   4. 中级COCOMO

      1. 使用中级COCOMO计算开发时间由两个阶段完成
      2. 首先给出一个开发工作量的大致估算，这是必须先估算两个参数：以KDSI计的产品长度和产品的开发模式。有三种模式：有组织的，半分离的，嵌入式的
      3. 由这两个参数计算出额定工作量

   5. COCOMO Ⅱ可以处理现代润建工程技术

   6. 两者区别

      1. 中级COCOMO包含基于代码行数的一个总模型

         COCOMO 2由三个模型组成

         1. 应用组合模型-基于对象
         2. 早期设计模型-基于功能点
         3. 后架构模型-使用功能点或者代码行数

      2. 工作量=ax（规模）的b次方

         1. b之前是固定三个值后为1.01-1.26浮动

      3. 前者假设复用带来的节省与复用数量成比例，后者考虑到对复用软件进行小修改会产生不成比例的答得开销的情况

      4. 成本驱动的乘法因子不同

   7. 产品开发中，实际的开发工作量必须持续与预测值进行比较。

   8. 一个软件项目管理计划分三部分：要做的工作、做工作需要的资源以及为此支付的所有金钱。

   9. 软件开发所需要的资源。需要的主要资源是开发软件的人、运行软件的硬件和支持软件（操作系统、文本编辑器和版本控制器）

   10. 测试代码模块的一个重要方法是黑盒测试，即按照规格说明的测试用例去运行代码

第十章 需求工作流

1. 需求工作流的真正目标是确定什么样的软件是客户所需的
2. 问题是许多客户不知道他们需要什么，可能不了解自己的企业正在做什么
3. 需求工作流的第一步是理解应用域，即目标产品进行操作的特定环境。
4. 发现客户的需求的过程叫需求引出
5. 处理术语问题的一种方法是捡了一张术语表
6. 业务模型是对一个机构的业务过程的描述
7. 访谈有两种基本类型：程式化的和非程式化的
   1. 程式化访谈中，会提出一些特定的，预先计划好的问题，这些问题一般是封闭式的
   2. 非程式化访谈中，会从1-2个准备好的问题开始，后续问题根据受访谈对象的回答提出
8. 一种获得关于客户公司活动信息的方式是给客户公司相关成员发放调查问卷
9. 另一种是检查客户在业务上使用的各种表格
10. 还有一种是直接观察—花费时间长
11. 需求是动态的
12. 需求分为功能性需求和非功能性需求
    1. 功能性需求制定了目标产品必须能够执行的行为。功能性需求通常用输入和输出表示，给定一个特定的输入，功能性需求规定输出必须是什么样的。
    2. 非功能性需求制定了目标产品本身的特性（平台约束、响应时间、可靠性）
13. 功能性需求在需求工作流和分析工作流进行时进行处理，而一些非功能性需求需要到设计工作流再处理
14. 一个快速原型是一个展现目标产品关键功能的快速建立的软件
15. 用户友好性是指人与软件产品沟通的容易性
16. 需求阶段的一个关键特定是需求小组怎样能快速确定客户的真正需求，所以这一阶段的一个有用度量是测量需求变更率，另一个度量标准是软件开发过程的其余工作流中需求改变的数量
17. 需求工作流的挑战
    1. 让目标产品的潜在用户能够同心同德的合作
    2. 协商的能力
    3. 拥有需求小组需要明确的信息的人，没有时间见面进行深入讨论
18. 灵活性和客观性对需求获取也是必不可少的

第十一章 分析工作流

1. 规格说明文档是客户和开发人员之间的合约

2. 规格说明文档的一个至关重要的部分是验收标准集

3. 解决策略是建构产品的一种通用的办法

4. 分析工作流的两个目的

   1. 跟深刻的理解需求
   2. 采用一种可使设计和实现更易于继续进行的方式来描述需求

5. 统一过程包含三种类型的类：实体类、边界类、控制类。

   1. 实体类是对持久的信息进行建模
   2. 边界类是对软件产品和它的参与者之间的交互进行建模
   3. 控制类是对复杂的计算和算法建模
   4. 

6. 实体类的提取包括三个迭代和增量式执行的步骤

   1. 功能建模：给出所有用例的场景
   2. 实体类建模：确定实体类和它们的属性。然后，确定实体类之间的联系和交互行为，用类图表示这些信息
   3. 动态建模：确定每个实体类或其自雷执行或对之执行的操作，用状态图来表示这些信息。

7. 用例描述待构件的软件产品与参与者之间的交互

8. 对于没有用领域专业开发知识的开发人员，一个好的方法是使用下面两个阶段名词提取方法，先提取候选实体类，然后对结果进行细化

   1. 用一段话描述软件产品
   2. 识别名词

9. CRC卡片

   1. 类-职责-协作卡片应用域分析工作流
   2. CRC卡片的优点在于，当开发小组使用它时，小组成员之间的交互可以发现类里面遗漏的或错误的字段。
   3. CRC卡片的缺点在于：除非小组成员在相关应用领域有先当丰富的经验，否则通常不是一个好的方法

10. 动态建模的目标是生成每个类的状态图

11. 状态图包含了状态、事件和行为。

12. 边界类更容易提取

13. 分析工作流的一个主要目标是产生规格说明文档

第十二章 设计工作流

1. 类是有继承属性的抽象数据类型，对象则是类的实例
2. 当使用编程语言不支持继承的时候，解决方法是利用编程语言所能够支持的面向对象设计的内容，即使用抽象数据类型设计
3. 面向对象设计的两个关键步骤是完成类图设计和详细设计
4. 首先应完成类图设计另一重要部分是分配方法（操作的实现）给类
   1. 第二个原则是，如果一个操作被一个对象的不同客户所调用，那么将这个操作实现为该对象的一个方法比在每一个客户中实现它要有意义。
   2. 第三个用于分配操作的原则是使用职责启动设计。
   3. 职责驱动设计是面向对象设计的一个重要方面
5. 面向对象的第二步是细节设计，在这个过程中每个类都将被详细设计
6. 设计工作流的输入是分析工作流的结果
7. 统一过程开发的主要目的是提供一种适用于大型软件开发的方法
8. 将大的工作流划分成相互独立的小的设计工作流的思想也被引入设计工作流中
9. 事务对产品的用户而言就是一个操作，就像“处理一个请求”，当一个产品是面向事务的，设计审查就必须能够反映出事务
10. 严格的事务驱动审查无法检测出哪些规格说明中要求而被设计者忽略的事务实例
11. 实施软件的特点是严格的时间约束
12. 大部分实时系统的特点是它们都通过分布式系统来实现
13. 实时系统中一个更难的问题是同步
14. 详细设计的秩复杂度可以是设计中二元判定的数目加1

第十三章 实现工作流

1. 如何选择合适的编程语言

   1. 成本效益分析法，管理者必须使用当前决定语言耗费的成本，以及现在和将来带来的收益。这个方法要针对每一个可选的语言重复进行，具有最大期望回报的语言，即估计效益和估计成本之差最大的哪个语言。
   2. 采用风险分析，对于考虑的所有语言，列出潜在的风险和解决他们的办法的清单，清单综合最小的语言就是要选择的语言。

2. 良好的编程实践

   1. 使用有意义的变量名
   2. 添加注释
   3. 使用参数
   4. 增加可读性
   5. 避免嵌套多个if
   6. 避免go to

3. 什么事实现后集成，缺点是：

   1. 方法：单独编写和测试每个代码制品，然后链接，最后对产品的整体进行测试
   2. 缺点：
      1. 需要花费大量的精力在构件存根和驱动上，而这些制品在单元测试后都被抛弃
      2. 缺乏错误隔离手段，如果整体测试出现了错误且在某个用例下出现的错误，无法确定位置
      3. 主要设计错误出现延迟
      4. 潜在复用代码制品测试不充分

4. 什么是自顶向下，优缺点

   1. 若代码制品A要发送消息给B，那么A要比B先集成和实现
   2. 优点
      1. 支持错误隔离
      2. 设计错误可以在早期显现
      3. 确保了逻辑制品在操作制品之前实现和集成，因为连通图中，逻辑制品几乎总是操作制品的祖先
   3. 缺点
      1. 可复用代码可能测试不充分，复用了一位测试时对的，结果一错到底
   4. 解决方法：操作制品经常复用，需要多测试，操作制品的测试不够充分，会导致复用的风险

5. 什么是自底向上，优缺点

   1. B发送消息给A，那么B要比A先集成和实现
   2. 优点
      1. 支持错误隔离
      2. 操作制品得到了充分的测试
      3. 测试通过驱动的协助完成，而不是通过错误保护
   3. 缺点
      1. 重大设计错误在后期才会被发现

6. 三明治集成

   1. 并行的：自顶向下的实现和集成逻辑制品；子弟像是的实现和集成操作制品
   2. 测试逻辑制品和操作制品之间的接口
      1. 优点：错误隔离，主要错误早期显现，潜在复用代码制品测试充分

7. 集成管理中的问题以及解决办法

   1. 代码制品不能简单的连接在一起。因为不同制品的程序员谁也不承认自己会错
   2. 解决办法SQA
      

8. 如何构件单元测试

   1. 单元测试可以通过两种基本的方式进行系统的构件
   2. 黑盒测试（规格说明测试、行为、数据驱动）：忽略代码本身，拟定测试用例时使用仅有的信息是规格说明文档
   3. 白盒测试（代码测试、罗技驱动、面向路径）是另一个极端，忽略规格说明文档
   4. 先黑盒再白盒，两者结合
   5. 比如彻底的规格说明测试是不可行的，组合爆炸，有太多的测试用例需要考虑
   6. 彻底的代码测试也是不可行的，因为可能包含的路径的数量太大，因为代码测试要求测试者实验每条路径，但代码测试不可靠

9. 一个成功的测试意味着什么

   1. 测试在于设计一个较小的容易管理的测试用例集，是发现错误的几率最大化，同时使多个测试用例发现同一个错误而浪费测试用例的几率最小化，所选的每一个测试用例必能发现前面没有检出的错误

10. 黑盒测试中的等价类技术

    1. 1-100位一个等价类，等价类划分位<1,1-100,>100

11. 黑盒测试中的边界值分析

    1. 成功的测试用例可以找到以前没有找到的错误，要使发现错误的机会最大化，边界值分析法也是一种可靠的技术
    2. 选择处于或接近等价类边界的测试用例时，发现错误的可能性增大

12. 功能测试

    1. 黑盒测试的一种替代形式是基于代码段的功能性而选择测试数据。功能测试是对代码制品实现的方法进行测试，其对每个方法单独设计测试数据

13. 白盒测试中的语句覆盖和分支覆盖

    1. 语句覆盖：即运行一系列测试用例，期间每条语句至少执行一次。缺点：不能保证覆盖所有的语句分支都得到了恰当的测试
    2. 分支覆盖：即运行一系列测试，确保所有分支至少被测试一次

14. 全定义路径覆盖，优缺点

    1. 路径覆盖测试所有路径
    2. 全定义路径覆盖是指标出变量的定义和定义的使用之间的全部路径，最后为每条路径建立一个测试用例
    3. 优点：通过相对较少的测试用例往往可以发现大量错误
    4. 缺点：全定义使用路径覆盖需要的测试用例通常比理论的上届小很多。

15. 路径覆盖优点

    1. 使用结构测试是，测试者可能没有提出检查某一语句，分支或路径的测试用例，代码制品中也许存在不可行的路径，即对任何输入数据都不可能执行到的路径。但使用语句覆盖可以很快发现。

16. 评审优点以及相比于执行测试的优势

    1. 优点：错误检测快速，彻底和提前：因为集成阶段出现的错误较少而提高生产率；降低维护成本；代码审查本身成本低
    2. 相比于执行的测试节省时间，在软件生命周期的早期检查出错误并纠正

17. 面向对象泛型降低了对测试的需求

18. 如何管理单元测试

    1. 成本效益分析法：目的：在代码制品的测试要花费多少时间和资金；比价附加的测试用例的成本和由不足的测试引起的可交付产品故障的成本；可靠性分析技术：提供一流错误数的统计估计。决定是否继续测试还是认为错误已经全部排除了

19. 何时重写：看最大错误数

20. 集成测试：每个新代码在加入到已集成的模块中都必须进行集成测试，先单元测试新的代码制品，然后检查这部分产品的其余部分的行为是否和集成这个新代码制品之前一样

21. 关于产品测试，目的，方法

    1. 集成测试完成后，软件产品作为整体进行测试：为了确保验收测试的成功；
    2. 方法：
       1. 必须对产品整体运行黑盒测试用例，目前已经建立了基于各个代码制品或者类的测试用例，以确保每个代码制品和类满足规格说明；
       2. 必须对整个软件的健壮性进行测试，集成器件已经测试了单个代码制品的健壮性，现在必须测试整个产品的健壮性
       3. 必须对软件产品是否满足所有约束进行预测
       4. 必须坚持需要交付给客户的文档

22. 验收测试

    1. 开发者保证各个方面都正确后，交给用户去测试
    2. 目的：确定产品是否确实具有开发者在规格说明中生成的功能。包括：正确性测试；健壮性测试；性能测试；文档测试

23. 实现工作流面临的挑战

    1. 代码复用是降低软件成本和缩短交付时间的一个有效途径，然而如果延迟到实现工作流才做这个工作，就很难实现代码复用
    2. 如果复用的代码段不能很好的适合设计，代码段的复用也无意义
    3. 代码复用还需要结合在需求、分析、设计流中，因为对代码的复用必须在设计文档中提出复用哪些代码段
    4. 技术人员
    5. 对需求、分析、设计流要求很好的完成任务
    6. 管理

第十四章 交付后维护

1. 交付后维护的必要性
   1. 错误需要改正，无论是分析错误、编码错误、文档错误还是其他错误。这称为纠错性维护
   2. 代码修改为了提高产品的有效性，可维护性，这称为完善性维护
   3. 为适应产品运行环境的变化对产品所做的修改，这成为适应性维护
2. 交付后维护程序员应具备什么
   1. 调适能力
   2. 防止引入回归错误
   3. 设计测试用例用于回归测试
   4. 先判断是否存在错误，修复并记录
   5. 必须是分析、设计、编程方面的专家
   6. 设计合适的测试用例及编写文档能力
   7. 经验充足
3. 交付后维护的技能
   1. 确定故障原因的能力
   2. 在没有充足文档下有效的工作能力
   3. 分析、设计、实现、测试有关的技能
4. 关于交付后维护的管理的缺陷报告
   1. 缺陷报告：必须包括足够的信息，以是的程序员可以重视该问题，程序员可应该给出问题的严重性
   2. 授权对产品的修改：修改产品，回归测试，记录文档
   3. 确保可维护性：不能削弱从一开始建立的软件的可维护性，软件需要一直交付维护
   4. 反复诶胡的问题：移动目标问题
5. 对象为什么容易维护
   1. 概念独立性意味着容易发现产品的那一部分需要进行修改以达到某个特定的维护目标
   2. 信息隐藏技术确保对象本身的修改不会对对象意外造成影响，回归错误的数量也在下降。
6. 逆向工程：从源代码开始，试图重新创建设计文档甚至规格说明
7. 重组：在不改变产品功能的前提下万婵产品