软件工程读书笔记
《软件工程》-重点考试知识点,简答
第一章1、软件概念：由计算机程序，数据，软件文档组成软件的特点：无法直接观察它的物理形态，只能通过观察他的是实际运行情况来了解他的功能特性和质量等；人们在分析设计开发测试过程以及软件开发项目的管理过程中渗透了大量的人类的脑力劳动；不存在磨损和老化但存在缺陷维护和技术更新的问题；开发运行依赖一定的计算机系统环境；具有可复用性软件的分类：按功能分：系统支撑应用软件；按服务对象：通用定制软件；按规模：大中小型软件；按工作方式：实时分时交互式批处理2、软件危机：是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件的开发与维护过程中出现一系列严重问题的现象。
主要表现：●开发人员开发的软件产品不能完全满足用户的需求；●软件产品的质量难以得到保障；●开发周期开发经费和维护费用很难被准确估计从而给项目的管理带来很多麻烦；●随着技术的更新，用户的扩大，已有的软件产品不能灵活地适应环境的改变；●软件文档不完备并且存在文档内容与软件产品不符的情况。
原因：①软件开发是一项复杂的工程，需要用科学的工程化思想来组织和指导软件开发的各个阶段②没有完善的质量保证体系③软件文档的重要性没有得到软件开发人员和用户的足够重视④从事软件开发的专业人员对这个产业认识不够充分缺乏经验⑤软件独有的特点也给软件的开发和维护带来困难3、软件工程是指应用计算机科学与技术，数学和管理学的原理，运用工程学理论方法和技术，研究和指导软件开发和演化的一门交叉学科。
软件工程的目标：●使软件开发的成本控制在预计的合理范围内；●使软件产品的各项功能和性能能够满足用户需求；●提高软件产品的可靠性；●使生产出来的软件产品易于移植维护升级和使用；●使软件产品的开发周期能够控制在预计的合理时间范围内。
软件工程学科内容：●软件工程原理过程方法模型管理度量环境应用。
软件工程的基本原则：●将软件的生命周期划分为多个阶段，对各个阶段实施严格的项目管理；●坚持阶段评审制度已确保软件产品的质量；●实施严格的产品控制以适应软件规格的变更；●采用现代程序设计技术；开发出来的产品应该能够清楚地被审查；●合理地安排软件开发小组人员并且开发小组的人员要少而精；●不断改进软件工程的实践。
软工复习心得总结
软工复习心得总结在软件工程专业的学习过程中，经历了大量的理论学习和实践实验，对于软件工程的相关知识和技能有了更深入的了解。
通过本次复习，我进一步总结了软件工程的核心概念和方法，并为将来的工作和研究打下了坚实的基础。
以下是我对软工复习的心得总结。
一、需求工程需求工程是软件开发的首要步骤，准确理解和表达用户需求对于软件项目的成功至关重要。
在复习中，我通过学习需求获取、分析、建模和验证的方法，掌握了如何识别和组织需求，并通过合理的需求管理保证项目的顺利进行。
同时，我也学到了如何准确地与用户交流，以确保需求的准确性和一致性。
二、软件设计软件设计是软件开发的核心环节，通过将需求转化为具体实施方案，设计出高质量的软件架构和模块。
在复习中，我重点学习了软件设计原则、设计模式和架构风格等，通过合理的模块划分和接口设计实现了软件的高内聚低耦合。
同时，我也了解了如何进行软件质量评估和设计重构，以保证软件设计的可维护性和可扩展性。
三、软件开发软件开发阶段是将软件设计方案转化为可执行的代码，实现软件的具体功能。
在复习中，我回顾了各种编程语言和开发工具的使用方法，并加深了对软件开发的敏捷方法和迭代开发的理解。
通过复习，我进一步提高了代码编写和调试技巧，学会了如何优化代码和进行单元测试，以确保软件的正确性和鲁棒性。
四、软件测试软件测试是确保软件质量的关键环节，通过有效的测试方法和工具，发现和修复软件中的缺陷和漏洞。
在复习中，我重点学习了软件测试的基本原理和各种测试技巧，了解了如何进行测试需求分析和测试用例设计。
通过自动化测试和持续集成等技术手段，提高了测试效率和软件质量。
五、软件项目管理软件项目管理是组织和协调软件开发过程，确保项目按时、按质量完成的关键环节。
在复习中，我深入学习了软件项目管理的各个方面，包括项目计划、风险管理、团队协作和质量控制等。
通过项目管理的学习与实践，我提高了自己的组织和协调能力，更好地理解了软件项目的全局性和复杂性。
《编程卓越之道(卷3)：软件工程化》读书笔记模板
9系统文档 10需求文档
11软件设计描述文档 12软件测试文档
9.1系统文档类型 9.2可追溯性 9.3确认、验证和审查 9.4通过文档降低开发成本 9.5获取更多信息
10.1需求的来源和可追溯性 10.2设计目标 10.3系统需求规范文档 10.4软件需求规范文档 10.5创建需求 10.6用例 10.7根据用例创建DAQ软件需求 10.8 （从SRS中选择的）DAQ软件需求 10.9用需求信息更新可追溯性矩阵
11.1 IEEE Std 1016-1998和IEEE Std 1016-2009 11.2 IEEE 1016-2009的概念模型 11.3 SDD所需内容 11.4 SDD的可追溯性和标签 11.5建议的SDD大纲 11.6 SDD文档示例 11.7用设计信息更新可追溯性矩阵 11.8创建软件设计 11.9获取更多信息
12.1 Std 829中的软件测试文档 12.2测试计划 12.3软件审查列表文档 12.4软件测试用例文档 12.5软件测试过程文档 12.6级别测试日志 12.7异常报告 12.8测试报告 12.9你真的需要这些吗
读书笔记
这是《编程卓越之道（卷3）：软件工程化》的读书笔记模板，可以替换为自己的心得。
5.1 UML活动状态符号 5.2扩展UML活动图 5.3获取更多信息
6.1 UML中的面向对象分析与设计 6.2类图中的可见性 6.3类属性 6.4类操作 6.5 UML的类关系 6.6对象 6.7获取更多信息
7.1时序图 7.2协作图 7.3获取更多信息
8.1组件图 8.2包图 8.3部署图 8.4合成结构图 8.5状态图 8.6关于UML的更多信息 8.7获取更多信息
3.1软件开发生命周期 3.2软件开发模型 3.3软件开发方法论 3.4卓越程序员的模型和方法论 3.5获取更多信息
自考软件工程02333 笔记
自考软件工程02333 笔记一、概述软件工程作为一门新兴的学科，旨在指导和管理软件开发过程中的各种活动，以便按时、按质、按成本地完成软件工程项目。
本课程通过系统地介绍软件工程的基本理论、基本方法、基本技术和实践应用，以培养学生的软件工程思维和实际操作能力。
二、课程要求1. 了解软件工程的基本概念、基本原理和基本方法；2. 掌握软件工程项目的开发过程和管理过程；3. 掌握软件工程开发过程中的基本工具和技术；4. 了解软件工程应用领域的发展趋势与前沿技术。
三、课程内容1. 软件工程概述软件工程的定义、历史、发展、意义、主要任务等；2. 软件生命周期软件生命周期模型、活动、任务、文档、质量保证；3. 需求工程需求获取、需求分析、需求规格说明、需求验证等；4. 软件设计结构化设计、面向对象设计、界面设计、数据库设计等；5. 软件构建编码规范、程序设计、测试、集成等；6. 软件测试测试基本概念、测试方法、测试工具、测试用例设计等；7. 软件维护软件维护的类型、需求、过程、技术等；8. 软件质量管理质量计划、质量保证、缺陷管理、度量与分析等；9. 项目管理项目计划、进度管理、成本管理、风险管理等；10. 软件工程发展趋势软件工程的前沿技术、新兴趋势及应用领域。
四、学习方法1. 认真听课，理清教学内容；2. 多做习题，巩固理论知识；3. 积极参与讨论，提升理论水平；4. 关注实践应用，培养实际操作能力；5. 及时总结，形成完整的软件工程知识体系。
五、考试重点1. 考试内容：对软件工程的基本概念、基本原理、基本方法和实践应用的掌握程度；2. 考试形式：闭卷考试，以选择题、简答题、计算题形式出题；3. 考试要求：理论与实践相结合，注重分析和解决实际问题的能力。
六、学习建议1. 认真学习课本内容，了解软件工程的基本理论和方法；2. 多参加实验课和讨论班，加强理论与实践的结合；3. 多做习题，熟悉考试题型和内容要点；4. 关注软件工程的发展趋势，了解前沿技术和新兴应用。
软件工程读书笔记
软件工程读书笔记【篇一：软件工程读书笔记】1.软件危机在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2.软件危机的表现–软件成本日益增长–开发进度难以控制–软件质量差–软件维护困难–软件开发速度跟不上计算机发展速度3.软件危机的原因–技术原因? 软件规模越来越大? 软件复杂度越来越高–管理原因? 软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性? 对用户需求没有完整准确的认识，就匆忙着手编写程序4.软件工程1) 将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护。
2) 对1)中方法的理论研究。
5.生命周期软件生命周期由软件定义、软件开发和运行维护三个时期组成，每个时期又可进一步划分成若干个阶段，每个阶段有各自的任务。
?????? 问题定义可行性分析需求分析概要设计详细设计编码和单元测试? 综合测试? 维护6.软件过程生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。
7.瀑布模型：? 阶段间具有顺序性和依赖性?? 推迟实现的观点质量保证的观点，文档驱动优点：文档驱动的规范坏，每个阶段的仔细验证。
缺点：通过文档与客户沟通，最终产品可能不能真正满足客户需求。
8.快速原型模型：? 快速建立起可以运行的程序，其功能往往是最终产品功能的子集。
特点：通过原型系统获取客户要求，一旦需求确定，原型将被抛弃。
9.增量模型：? 把软件产品作为一系列增量构件来设计、编码、集成和测试。
优点：能在最早的时间把最新的功能提交给客户；减少客户对全新软件的冲击。
缺点：开发困难，设计阶段必需有一个好的体系结构10.螺旋模型：? 在每个阶段之前都增加了风险分析过程的快速原型模型。
优点：对可选方案和约束条件的强调有利于已有软件的重用；减少了过多测试或测试不足带来的风险；维护只是一个周期；风险驱动。
11.瀑布模型：面向对象迭代无缝可行性分析1. 可行性分析任务? 技术可行性? 经济可行性? 操作可行性? 法律可行性2. 可行性分析过程???????3.复查系统规模和目标研究目前正在使用的系统导出新系统的高层逻辑模型进一步定义问题导出和评价供选择的解法推荐行动方针草拟开发计划 ? 书写文档提交审查系统流程图–概括描绘物理系统的传统工具–用图形符号，以黑盒子形式描述组成系统的每个部件–程序、文档、数据库、人工过程3. 数据流图(dfd)描绘信息流和数据从输入移动到输出的过程中所经受的变换。
软件工程重点总结（5篇）
软件工程重点总结（5篇）第一篇：软件工程重点总结软件的定义：软件是计算机系统中与硬件相互依存的另一部分，软件包括程序、数据及其相关文档的完整集合。
在结构化程序设计时代，程序的最小单位是向对象程序设计时代，程序的最小单位是类，在类中封装了相关的数据及指令代码。
软件的特性：形态特性、智能特性、开发特特性、维护特性、废弃特性、应用特性。
软件的分类：系统软件、应用软件、支撑软软件危机的表现：软件开发周期长、成本高、软件危机发生的原因：（1）缺乏软件开发的工作的计划很难制定。
（2）软件人员与用户的交流存在障碍。
（3）软件开发过程不规范，缺少方法论和规范的指导，开发人员各自为战，缺少整体的规划和配合，不重视文字资料工作，软件难以维护。
（4）随着软件规模的增大，其复杂性往往会呈指数级升高。
（5）缺少有效的软件测评手段，提高用户的软件质量差，在运行中暴露出大量的问题，轻者影响系统的正常使用，重者发生事故，甚至造成生命财产的重大损失。
首次提出“软件工程”的概念的时间是1968年。
按工程化的原则和方法组织软件开发工作是软件工程的定义：软件工程是指导软件开发和维护的工程性学科，它以计算机科学理论和其他相关学科的理论为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，以较少的代价获得高质量的软件并维护它。
软件工程的目标是运用先进的软件开发技术衡量软件的质量的六个特性：功能性、可靠软件生存期的三个时期：软件定义、软件开定义时期的主要任务是解决“做什么”的问地满足用户的需要。
开发过程中的典型文档包括：软件需求规格计说明书、用户手册。
各个阶段所要完成的基本任务：问题定义与可行性研究、需求分析、软件设计、程序编码和单元测试、集成测试和系统测试、软件运行和维护。
典型的软件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等（喷泉模型）。
瀑布模型的特点：1）阶段间具有顺序性和依赖性。
软件工程知识点汇总
软件工程知识点汇总1. 软件工程简介软件工程是运用系统化、规范化和可管理的方法进行软件开发、运行和维护的学科。
它涵盖了软件生命周期的各个阶段，包括需求分析、设计、编码、测试、发布和维护等。
2. 软件工程流程模型常见的软件工程流程模型包括瀑布模型、迭代模型、增量模型、螺旋模型等。
不同的模型适用于不同的项目需求和开发环境，每个模型都有其优缺点。
3. 软件需求工程软件需求工程是确定软件系统应该如何工作的过程。
它包括需求获取、需求分析、需求规格和需求验证等活动。
良好的需求工程能够确保软件系统满足客户的需求和预期。
4. 软件设计软件设计是将软件需求转化为可执行的程序设计的过程。
它包括系统架构设计、模块设计、接口设计和数据库设计等活动。
良好的软件设计能够提高软件的可维护性和可扩展性。
5. 软件开发软件开发是按照软件设计规范进行编码和测试的过程。
开发人员应该具备良好的编程技能和测试能力，并遵循编码规范和测试流程。
6. 软件测试软件测试是为了发现软件中的错误和缺陷，保证软件的质量和可靠性。
测试方法包括功能测试、性能测试、压力测试和安全测试等。
高质量的测试能够提高软件的稳定性和用户满意度。
7. 软件配置管理软件配置管理是对软件开发过程中所的各类工作产品进行控制、记录、审计和追踪的过程。
配置管理包括版本管理、变更管理、发布管理和文档管理等活动。
8. 软件项目管理软件项目管理是对软件开发项目进行规划、组织、指导和控制的过程。
它包括项目需求分析、项目计划制定、项目资源分配和进度控制等活动。
有效的项目管理能够提高软件开发效率和项目成功率。
9. 软件质量管理软件质量管理是在软件开发过程中对质量进行全面管理的过程。
它包括质量计划、质量控制和质量保证等活动。
良好的质量管理能够提高软件的可靠性和用户满意度。
10. 软件维护与迭代软件维护是在软件发布后对其进行修复bug、优化性能和添加新功能的过程。
软件迭代是对软件系统进行增量式的开发和发布，不断提高软件质量和功能。
《软件工程》学习心得
课程（学习心得）课程名称：软件工程题目：学习心得院系：信息技术学院班级：11级计算机科学与技术3班姓名：学号：教师：赵卿昆明学院《软件工程》学习心得一、软件工程的定义软件工程 (Software Engineering，简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。
在现代社会中，软件应用于多个方面。
典型的软件比如有电子邮件，嵌入式系统，人机界面，办公套件，操作系统，编译器，数据库，游戏等。
同时，各个行业几乎都有计算机软件的应用，比如工业，农业，银行，航空，政府部门等。
这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。
二、软件工程的目标在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并且满足用户需求的软件产品。
三、软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
软件工程的原则有以下四项基本原则：1）选取适宜开发范型；2）采用合适的设计方法；3）提供高质量的工程支持；4）重视开发过程的管理。
四、软件工程的由来据说上个世纪60年代的程序员都是天才，写程式就像写日记一样，吃过晚饭没事干随手就可以写几个出来玩，第二天还可以拿去卖钱。
所以那时候程序员在大家眼中，跟那些搞美术，音乐的是一类的，被称为“艺术家”。
但事过境迁，就像任何人都不会嫌钱多一样，永远都不会有人嫌CPU快的。
于是，随之而来的就是硬件的迅猛发展和越来越变态的软件。
记得以前常去同学家拷游戏，通常几张软盘就可以搞定，而现在的游戏，两三张CD-ROM都算少的了。
像如此庞大复杂的怪物，就算你是如何的天才，一个人肯定是搞不定的，否则，等你把程式写出来，人家Intel连奔腾N都开发出来了。
既要开发大型的软件还要追求速度（这样才能赚钱），于是很自然地，合作的概念被提了出来。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程读书笔记专业：软件工程硕士A班学生姓名：丁浩宸学号：13214020二〇一④年八月The impact of imperfect change rules on framework API evolution identification:an empirical study实证研究：框架API更新辨别的不完善变化规则的影响Wei Wu·Adrien Serveaux·Yann-Ga¨el Gu´eh´eneuc·Giuliano Antoniol摘要:软件框架在持续更新。
程序员保持他们的客户端代码更新很费时。
而且不是所有的框架都有着更新的文档说明。
因此许多处理方法被提出以减少没有更新文档的影响，这些方法依靠通过辨别软件两个发行版本的改变规则。
但是这些改变规则是不完善的，即不是100%正确的。
在我们的知识范围内，并没有展示这些非完善改变规则的可用性的实证研究。
因此我们设计并实施了一个实验来评价非完善规则的影响。
在实验中，实验人员必须在三个不同的发行版本中找到21处丢失了的方法的替换。
三个版本分别依靠1）全部正确的改变规则，2）不完善的改变规则，3）无改变规则。
统计分析结果表明实验人员在三个不同的发行版本中找到的替换的精度有着显著差异。
其中依赖全部正确的改变规则的结果精度是最高的，没有改变规则的精度是最低的，不完善的改变规则在两者中间。
不完善改变规则和没有改变规则的精度差的效应值是巨大的，不完善改变规则和完全正确改变规则的精度差的效应值是适度的。
研究结果表明框架API更新方法总结出的改变规则确实可以帮助开发者，即使这些规则并不是一直正确的。
非完善改变规则可以帮助开发者在文档不可用时更新他们的代码，或者作为部分文档的补充。
完全正确和不完善改变规律间适度的差异表明提高改变规则的精度依然可以帮助开发者。
关键词软件维护·可用性·框架API更新·变化规则1背景介绍软件框架和函数库库广泛应用于软件开发以降低成本。
实际上,开发人员发展框架不断修正错误,补丁安全漏洞,满足新的需求。
从理论上说,应用程序接口(API)的新版本的框架应该是与以前的版本向后兼容的,从而可以使使用之前框架的程序在新的框架下可以继续运作。
然而,由于API的变化，升级到新版本的框架需要大量的努力。
开发人员必须深入研究文档和以前版本框架的源代码来理解他们的差异，来使他们的程序与新版本兼容。
他们推迟升级的时间越长,就需要越多的时间,因为会有更多的变化。
为适应新版本的框架的API变化,开发人员通常执行四个任务:(1)找到丢失的API的可能替代,(2)如果他们无法找到替代品，就要找到丢失的API的变通,(3)实现替代或变通,(4)测试实现。
一个有效的方法来帮助找到合适的替代品是文档。
然而,许多框架并没有足够的文档,特别是当涉及到更改版本和规则之间适应程序从一个老版本发布到一个新的。
一般情况下,很少有公司明确文档API的变化或提供这些信息给公众。
因此,许多方法已经被开发来找到丢失API的替代。
有些方法要求框架开发人员做额外的工作。
然而,开发人员可能无法或不愿意手动建立改变规则或使用特定的工具。
因此,为了避免框架开发人员的额外工作,其他方法自动识别描述目标之间的匹配方法的变化规则。
这些方法所产生的变化规律并不都是正确的。
他们的精度在不同的框架分析中有差异。
然而,使用这些方法变化规则所产生的升级文档,开发人员不知道变化规律是否是正确的,直到他们修改使用客户端程序。
我们设计并进行实验评估框架的有效性API演化改变规则。
在这项实验中,实验人员找到替代的目标方法借助完全正确的改变规则,不完善的改变规则,没有改变规则。
然后,我们测量实验人员的精度和发现替代方法的时间。
实验结果统计分析表明,完全正确的，不完善的,没有改变规则发现的替代品的精度有着明显不同，平均值分别为82%,71%和57%。
没有改变方法和不完善的变化规则之间的效应差很大,完全正确的改变方法和不完善的变化规则之间的效应差是适中的。
找到替代方法用不同的平均时间为24，23，25分钟(1413、1338和1413秒)。
这些结果表明改变规则框架API生成的进化方法是有用的,即使一些变化的规则是不正确的。
然而,正如所料,更高精度的变化规律会为他们提供更多的帮助。
因此,不完善变化规律可以作为替代不可用文档或作为部分文档的补充。
框架的开发人员也可以使用它们作为起点建立升级文档。
结果中不完善和完全正确改变规则是适中的。
因此,提高精度变化规律仍将帮助开发人员提高工作效率。
2相关工作2.1框架API进展方法2.1.1输入现有捕捉数字变化的方法需要框架开发人员手动输入的变化规则或使用一个特定IDE自动记录变化。
Chow和Notkin(1996)提出了一个方法,要求框架开发者提供新版本的变化规律。
CatchUP!(Henkel and Diwan2005)和JBuilder((Kemper and Overbeck2005)记录在一个版本的重构操作然后在另一个版本上重复它们。
MolhadoRef(Dig et al.2007年)也雇佣了一个record-and-replay技术处理API 级合并程序版本的变化。
这些方法因为框架的开发人员的参与可以提供准确的变化规律。
2.1.2特性框架API演化是使用从输入中提取具体的信息特征,如call-dependency关系或文本相似度。
捕捉API级别变换的特征(Chow and Notkin1996;HenkelandDiwan2005;Kemper and Overbeck2005;Dig et al.2007)是不同的手动添加或自动捕获改变规则。
这些方法对每个目标方法和它的替代品有一个特定的模型。
Godfrey and Zou’s(2005)和S.Kimetal(2005)使用文本相似密度,软件度量,并调用依赖关系描述方法和他们的目标更换。
Xing和Stroulia(2007)使用词汇和结构相似的逻辑设计模型提取的两个版本之间的差异,包括文本相似度,继承关系,使用依赖关系和关联关系。
Kim et al.’s(2007)计算目标方法和它的替代测量之间的LCS来区别他们。
SemDiff(Dagenais and Robillard2011),Sch¨afer et al.(2008),和AURA(Wu et al.2010)使用call-dependency关系来衡量信心值和各种预处理文本相似。
HiMa(Meng et al.2012)使用call-dependency关系和连续犯错的自然语言分析过虑评论。
2.1.3匹配技术捕捉API级别的数字变化方法只需要简单匹配与目标方法收集到的变化规律的匹配技术,但需要的开发者的参与可能不可用。
Godfrey、Zou(2005)和Kimetal(2005)的匹配技术是基于起源分析技术。
前者是半自动的而后者是自动的。
Diff-CatchUp(Xing和Stroulia2007)定义三组启发类、方法和字段，分别排列可能的替代方法。
SemDiff(Dagenais和Robillard 2011)和Sch¨afer(2008)第一次使用信心值来预选可能的替代方法,然后使用文本相似度给他们排序。
他们之间的区别是,前者着重于框架如何适应他们自己的改变而后者发现使用客户机代码的更改。
Kim等(2007)的分类器利用系统的重命名旧模式使用文本相似度来匹配老api和新api。
AURA(Wu et al.2010)使用多迭代器算法相结合call-dependency和文本相似性分析。
HiMa’s(Meng et al.2012)使用修改评论生成最初改变规则,然后使用call-dependency分析改进它们。
2.2对程序理解的实证研究另一个与这个工作相关的领域是对程序理解的实证研究。
Lawrie等进行了实证研究来调查的标识符对程序理解(Lawrie et al.2007)的影响。
Sharif et al.(2010)和Sharafi et al.(2012)使用追踪系统比较“骆峰式”和下划线标识符风格。
前者使开发人员识别标识符，注重准确性和速度而后者从性别的角度理解研究标识符。
一些研究集中在对图的理解,例如UML。
Cepeda和Gu´eh´eneuc 评估的三个基于设计模式理解追踪系统的视觉展示的影响。
Yusuf等人做了一个实验来研究影响项目理解的UML类图的特性(Yusuf et al.2007)。
Soh等人进行了一项实验来评专业状态和专业知识对UML类图理解的角色。
还有其他对程序理解的实证研究。
Abbes等人进行了一项实验来评估的影响两个反模式(Blob和Spaghett代码)对程序理解(Abbes et al。
2011)。
Ali等人使用追踪系统开发人员的首选实体排名,如类名、方法名(Ali et al.2012)。
3文章动机据我们所知,,尽管实证研究在软件工程的研究中很普及，但是没有实证研究显示进化框架API方法生成的变化规律的可用性,即如果不完善变化规则可以帮助开发人员识别更准确或更快的识别替代方法。
因此,我们设计并进行了这项研究。
4实验定义4.1实验问题我们期望实验结果能回答这两个研究问题:-RQ1:分别通过完全正确,不完善,没有改变规则发现的目标方法的替代方法的精度是否存在差异?-RQ2:分别通过完全正确,不完善,没有改变规则发现的目标方法的替代方法的时间是否存在差异?在这个实验中,虽然我们没有给出执行任务的任何时间约束,我们不能指望所有实验人员都能够或可以结束。
因此,我们采取计算答案的时间和精度两种方案。
4.2实验对象我们实验的对象是用JAVA编写的两个版本的三个框架的源代码.我们选择三种大小适中的方案作为我们的实验对象。
这三个方案是：JEDIT v4.1-v4.2，JFreeChart v0.9.11-v0.9.12和JHotDraw v5.2-v5.3。
JEDIT是一个文本编辑器。
在2000年和2013年间它有37个发行版本。
它的V4.1和V4.2之间的API和实现有着巨大的变化。
JFreeChart是一个图表库。
有2000年和2013年间有着54个发行版本，其v0.9.11和v0.9.12之间的API也改变了很多，并且有很多在v0.9.12用着非常相似的名称API。
在这两个方案的巨大变化对于开发人员和方法来识别API的变化是巨大的挑战。
JHotDraw是一个GUI framework，由Gamma等人开发的。
与前两个节目相比不活跃，2001年和2011年之间只有12个版本发型，V5.2和V5.3之间，他们有几个API变化。