软件开发前沿技术.docx
《软件开发前沿技术.docx》由会员分享，可在线阅读，更多相关《软件开发前沿技术.docx（55页珍藏版）》请在冰豆网上搜索。
软件开发前沿技术
软件工程前沿开发技术
经过近四十年的发展，软件工程在支持软件系统工程化开发方面取得了令人瞩目的成
绩，提出了大量的理论、方法、技术和工具，但是近年来的研究和实践表明软件危机依然存
在，软件开发仍然存在成本高、质量得不到保证、进度和成本难以控制等方面的问题，许多软件项目被迫延期甚至取消。
与此同时，随着网络技术（尤其是Internet技术）的不断发展，部署在网络基础上的软件系统的规模和复杂性越来越高，并表现出诸如持续性、自适应性、交互性、动态性、开放性、异构性等特点。
因此，如何支持这类复杂系统的开发、缓解和消除现阶段的软件危机是当前软件工程面临的一项重要挑战。
为了迎接上述挑战，近年来软件工程领域的一些学者提出了许多新的方法和技术，包括：
敏捷软件开发（AgileSoftwareDevelopment）、极限编程（ExtremeProgramming，XP）、测试驱动的开发（Test-DrivenDevelopment，TDD）、面向Agent的软件开发（Agent-OrientedDevelopment）、面向方面的编程（Aspect-OrientedProgramming，AOP）、模型驱动体系结构（Model-DrivenArchitecture，MDA）等等。
与传统的软件工程方法相比较，这些方法和技术为软件工程实践提供了新的思路，已在许多软件工程实践中取得了积极的效果。
1敏捷软件开发
软件工程一直以来都面临着一个共同的问题，即如何迅速、高效地开发软件系统，适应
用户需求的快速变化，确保软件系统的质量，控制软件开发成本。
传统软件开发方法强调软
件开发需遵循严格的过程模型以及以此为基础的开发计划，并且在软件开发过程中需产生大
量的规范化文档，这一思想和方法很难应对快速、灵活和低成本软件开发所带来的一系列问
题。
自二十世纪九十年代以来，软件工程领域涌现出了一批新的软件开发方法。
这些方法主
张软件开发只编写少量文档、以用户为中心、主动适应需求变化。
这些方法被称为敏捷软件开发，其代表性的成果是极限编程。
1.1敏捷思想
至今人们已提出了几十种软件开发方法，根据这些方法在对软件开发所提出的要求和约
束等方面的差异，现有的软件开发方法大致可分为两类：
重型软件开发方法和轻型软件开发
方法。
重型软件开发方法一般具有严格和详尽的软件开发过程，软件开发需产生大量的文档。
轻型软件开发方法则强调软件开发过程的简洁性和灵活性，软件开发只需编写少量的文档。
敏捷软件开发是一类轻型的软件开发方法，它提供了一组思想和策略来指导软件系统的快速开发并响应用户需求的变化。
不同于已有的其它软件开发方法，该方法对软件开发具有以下四个方面的基本认识：
（1）较之于过程和工具，应更加重视人和交互的价值；
（2）较之于面面俱到的文档，应更加重视可运行软件的价值；（3）较之于合同谈判，应更加重视客户合作的价值；（4）较之于遵循计划，应更加重视响应用户需求变化的价值[1][2]。
敏捷软件开发方法认为人是软件开发中最为重要的因素，软件开发应坚持以人为本；优秀的软件开发团队离不开人员之间良好的沟通与合作，相比较而言团队的合作与沟通能力比单纯的编程能力更为重要，改善人员之间的交流与合作将有助于提升团队的软件开发水平；应根据软件开发团队的特点选择合适的软件开发过程；在软件开发工具的选择方面，敏捷软件开发主张从使用小工具开始，只有当小工具不能满足要求时才考虑选择和使用功能强大的工具。
一直以来，人们将文档视为是对软件开发各个阶段成果进行记录、促进人员之间进行交流的重要媒介和工具，也是软件开发和维护的主要依据。
然而，编制过多的文档不仅会耗费大量时间和精力，而且当用户需求变化时难以实现文档与代码的同步，这势必会影响软件系统的开发和维护。
敏捷软件开发方法提倡在软件开发过程中只编写少量短小精炼的文档。
成功的软件开发不应单纯依赖于合同条款和工作说明，而应将用户和软件开发团队紧密地结合在一起，让用户积极参与软件开发并提供持续不断、频繁的反馈信息。
在软件开发过程中，用户需求总会发生变化，这是由于用户需求难以一次性完全捕获，开发人员和用户对于需求的认识会不断地调整。
此外，用户的业务本身也可能会动态地发生变化。
在复杂软件系统的开发过程中，响应用户需求变化的能力常常决定着软件项目的成败。
为了适应用户需求的变化，敏捷软件开发认为软件开发计划不应考虑的太远，不要进行过于周密、详细的计划，只应覆盖短期的工作任务，对于中长期的任务只需有一个粗略的规划即可，要保留计划的充分灵活性，并根据需求的变化适时地调整计划。
在上述思想的指导下，敏捷软件开发提出了以下十二条原则来指导软件系统的开发[1]。
（1）尽早和持续地交付有价值的软件，以使用户满意。
敏捷软件开发最关心的是软件系统的交付。
诸多软件工程实践表明，初期交付软件系统
中包含的功能越少，最终交付软件系统的质量就越高；软件产品交付的越频繁，最终软件产
品的质量就越高。
尽早的交付可以让软件开发团队尽快获得成就感，提升软件开发团队的激
情和效率，尽早从用户处获取对需求、过程、产品等反馈信息。
持续性的交付可以让软件开
发团队保持胜利感和成就感，持续获取用户的反馈信息，及时调整项目实施的方向和优先级。
该原则主张迭代性的软件开发，并强调每一次迭代都选择对用户最有价值的功能作为本
次迭代的任务，迭代周期不宜太长。
每次迭代结束以后，就向用户交付一个可运行的、实现部分需求的软件产品。
（2）即使到了软件开发后期，也欢迎用户需求的变化。
需求不断变化和调整是软件工程化开发的一个重要特点。
敏捷软件开发方法的实践者不
应惧怕变化，而应适应用户需求的变化，从而为用户创造竞争优势。
为了支持用户需求的变
化，敏捷软件开发所生成的软件结构应具有足够的灵活性，以便在需求变化时能以最小的代
价迅速地做出调整。
因此，敏捷软件开发主张采用模式、迭代和重构等技术，以适应用户需求的变化，获得软件结构的灵活性。
（3）不断交付可运行的软件系统，交付周期可以从几周到几个月。
敏捷软件开发主张软件开发团队应经常性地向用户交付可运行的软件系统，而不是大
量的文档或者计划。
交付的周期要适宜，太长易使用户失去耐性，软件开发团队也无法从用户处及时获得反馈信息；过短会使用户难以接受持续不断的软件产品版本。
（4）在整个软件项目开发期间，用户和开发人员最好能每天一起工作。
为了使软件开发过程保持“敏捷”性，开发人员应及时从用户处获得各种反馈信息，因此需要用户与软件开发人员一起工作，以便在需要的时候及时给予反馈。
（5）由积极主动的人来承担项目开发，给他们提供所需环境和支持，信任他们的能力。
在影响软件项目的诸多因素中，人是其中最为重要的因素。
因此参与软件项目的人应积极主动，并要为它们参与软件开发创造良好的环境和条件。
（6）团队内部最有效的信息传递方式是面对面的交谈。
敏捷软件开发主张软件开发团队人员之间采用面对面交谈的方式来进行沟通，文档不作为人员之间交流的默认方式，只有在万不得已的情况下，才去编写文档。
（7）将可运行的软件作为衡量软件开发进度的首要衡量标准。
所谓可运行的软件是指完成了用户的部分或全部需求，并经过测试，可在目标环境下
运行的软件系统。
不同于其它的软件开发方法，敏捷软件开发不是根据所处的软件开发阶
段、已编写的文档数目或者已完成的代码数量来衡量软件开发进度，而是基于可运行的软件系统实现了多少软件需求来衡量软件开发进度。
（8）可持续性的开发，出资方、开发方和用户方应当保持长期、恒定的开发速度。
对于许多软件项目而言，软件开发是一个长期的过程。
敏捷软件开发主张软件开发团队
根据自身的特点选择合适、恒定的软件开发速度。
不应盲目追求高速，软件开发速度过快可能使软件开发人员陷入疲惫状态，可能会出现一些短期行为，以致于给软件项目留下隐患。
（9）关注优秀的技能和良好的设计会增强敏捷性。
敏捷的一个重要体现是响应变化的能力。
良好的设计是提高软件系统应变能力的关键。
因此，软件开发人员必须从一开始就努力做好设计，并在整个项目开发期间不断审查和改进
设计。
所有的软件开发人员都应致力于编写高质量的代码，不要为了追求短期目标而降低工作质量，将改进的工作留到以后再做。
（10）简单化。
这里所说的简单化是指软件开发工作应着眼于当前欲解决的问题，不要把问题想的太
复杂（如去预测将来可能出现的问题），并采用最为简单的方法去解决它，不要试图去构建那些华而不实的系统。
（11）最好的架构、需求和设计出自于自组织的团队。
敏捷团队应当是自组织的，以适应需求的变化。
软件开发任务不是从外部直接分配到团
队成员，而是交给软件开发团队，然后再由团队自行决定任务应当怎样完成。
软件项目开
发不是划分成若干部分然后交给相应的成员全权负责，所有成员对于软件项目的所有部分都有权参与。
（12）软件开发团队应定期就如何提高工作效率的问题进行反思，并进行相应的调整。
敏捷软件开发方法不是一成不变的，敏捷本身即含有适时调整的意思。
随着项目的推
进，软件开发团队应不断地对其组织方式、规则、关系等方面进行反思，并对这些方面进行调整，以便不断优化团队结构、提高软件开发效率。
1.2敏捷软件开发特点
敏捷思想对软件开发提出了新的理解和认识。
它没有深奥的理论，也没有引入新的概念
和特有的技术，只是将经过数十年检验的一组软件工程准则有机地结合在一起，确保这些软件工程准则相互支持并能够得到有效执行，从而促进当前软件工程所面临的问题的解决。
敏捷意味着轻盈、灵巧、无过多的负担、能够迅速响应变化。
根据敏捷软件开发的指导思想和实践原则，敏捷软件开发具有以下几个方面的特点。
−小
敏捷软件开发主张软件开发过程只需生成少量的软件文档，每个文档的规模要小；软件
开发应该迭代进行，每次迭代要实现的软件功能需求的数量和规模要小，从而确保每次迭代的周期要小。
−简
敏捷软件开发建议软件开发过程中所采用的技术、所使用的工具以及每次迭代要解决
的问题要尽可能的简单；软件开发人员在每次迭代中只关注当前欲实现的功能需求，而不要考虑将来的问题，从而使得软件开发人员能够聚焦关注点，简化问题的解决。
−快
为了快速响应变化、尽快从用户处获得反馈信息，敏捷软件开发要求软件开发人员尽
快地给用户提交有价值的软件产品，快速地对软件产品进行迭代和更新，以向用户持续地
交付不断完善的软件产品。
这里所说的软件产品是指可运行的软件系统，而不是软件文档。
−变
敏捷软件开发允许用户需求的动态变化，主张要以变应变，尤其是开发团队应该是自
组织的，软件系统的设计应能够有效地支持用户需求的变化，在整个软件开发过程中项目
开发团队应不断检讨软件开发方法、技术、管理和工具等方面的不足和局限，以便对它们进行不断的改进和优化。
−体
按照敏捷软件开发思想，软件开发人员和用户应融为一体，形成一个团队；敏捷软件开发非常强调构成团队的各个成员的素质，包括能力、技能、工作的积极性和主动性；此外敏捷软件开发还鼓励个体之间的交流，并强调这种交流是以交谈为主，而不是以文档为媒介。
从总体上看，敏捷软件开发方法与其它一些重型的软件开发方法有以下三个方面的本质
差别。
首先，敏捷软件开发强调方法本身的适应性，针对变化不断进行优化和调整，主动适
应变化；而重型软件开发方法以预测性和计划性为主，倾向于预先制定详细的计划，通过该
计划来指导软件项目的实施，并期望软件开发过程与计划之间的偏差越少越好。
其次，敏捷
软件开发强调以人为本，认为软件开发是面向人的而不是面向过程的，要求让软件开发所需
的各种方法、技术、工具和过程等适应人，而不是让人去适应它们；而重型软件开发方法试
图定义一种广泛适用的软件开发过程并通过团队来执行该软件开发过程，从而来指导软件系
统的开发。
第三，敏捷软件开发重点关注和强调可运行的软件系统，弱化了文档在软件开发中的作用；而重型软件开发方法则非常重视软件文档的撰写和管理。
敏捷软件开发的上述特点使得它更加适合于小规模软件开发团队，因为过多的软件开发人员势必会使得软件开发人员之间的交流变得非常复杂；同时也使它更加适合于需求易变的软件系统的开发，从而充分发挥该方法的技术优势。
1.3支持敏捷软件开发的技术和管理手段
敏捷软件开发的基本思想和实践原则为软件系统的开发提供了一组高层的策略，它们明确了实现敏捷软件开发的目标和要求，因而需要相应技术和管理手段的支持。
从技术的角度来看，敏捷思想和原则对软件系统的开发提出了以下一组要求：
尽快开
发出可运行的软件系统；当用户需求改变时应迅速地响应变化；获得良好的软件设计，以便
当需求变化时对软件设计进行不断的调整和优化；保证软件系统的质量；提高敏捷软件开发
的效率等等。
现阶段软件工程领域有以下一组技术可以有效地满足上述要求，支持敏捷软件开发。
−测试驱动开发
测试驱动开发要求软件开发人员在编写程序代码之前，先确定和编写好测试。
或者
说，软件开发人员首先要思考如何对某个功能进行测试，设计好相应的测试用例，编写好
相关的测试代码，然后编写相应的程序代码以通过软件测试。
这一技术支持软件系统功能的逐步实现，有助于保证任何程序代码都是可测试的，从而确保软件系统的质量。
本章7.2节将详细介绍测试驱动开发技术。
−敏捷设计
敏捷软件开发对软件系统的设计提出了更高的要求。
为了支持用户需求的动态变化以及
由此而引发的对软件设计的持续调整和优化，软件系统的设计应易于改动和调整，具有稳固性、可理解性、简单性、干净性和简洁性等特点。
针对这一要求，RobertC.Martin提出一组支持敏捷软件开发的设计原则[3]，包括：
（1）单一职责原则，要求每个模块只承担一个职责，减少引起模块变化的因素，提高模块的内聚度；
（2）开放封闭原则，扩展时无需更改模块的源代码和可执行代码，要尽可能利用抽象类，以体现软件设计的灵活性和可重用性；（3）依赖倒置原则，抽象不应该依赖细节，细节应依赖于抽象；（4）接口隔离原则，接口中的方法都是有意义的，否则就要相互分离等等。
−模式运用
充分利用各种模式，包括体系结构模式和设计模式来进行软件系统的设计，以支持软件系统的可重用性和应对用户需求的变化。
−快速原型技术快速原型技术有助于迅速生成软件系统的原型，并以此为媒介支持软件开发人员和用户之间的交流和沟通，促使软件开发人员关注于用户的需求，适应用户需求的动态变化，帮助软件开发人员尽快从用户处及时获得反馈信息。
−MDAMDA
强调将软件系统的功能规约与实现这些功能的技术和平台相分离，它区分两类不同的软件系统模型：
平台无关的模型和平台相关的模型，并通过模型映射在不同模型之间建立桥梁，从而有助于保护用户的业务模型，促进软件系统的快速开发和部署。
−CASE工具
目前已有许多支持敏捷软件开发的软件工具，包括由Microtool公司研发的ActifExetreme，它支持敏捷过程管理；由Ideogramic公司开发的IdeogramicUML，它支持针对敏捷过程的UML建模；由Borland公司开发的TogetherToolSet，它支持敏捷开发和极限编程中的诸多活动等等。
从管理的角度来看，敏捷思想和原则对软件系统的开发提出了以下一组要求：
管理好用户的需求；确保软件过程支持持续性的交付软件系统；管理好软件开发团队；支持软件开发人员和用户之间的交流、合作以及问题的及时反馈；以人为本，充分发挥人的积极性和主动性；保证软件开发速度的稳定性和持续性；不断改进和优化软件开发团队等等。
为了应对这些要求，基于敏捷软件开发方法的软件项目应遵循以下的管理方法。
−软件过程模型的选择
基于敏捷软件开发方法的软件项目组应选择那些支持渐进、迭代开发的软件过程模型，如迭代模型、螺旋模型、Rup和快速原型等。
−团队建设
基于敏捷软件开发方法的软件项目开发团队应充分发挥人的主体作用，将用户作为软件
开发团队中的成员，并与软件开发人员一起工作和交流；为软件开发团队提供良好的交流环
境，如拥有共同的办公区间和时间，基于网络的虚拟环境；支持团队成员，尤其是开发人员和用户之间的双向交流和沟通。
−需求管理
尽管用户需求在整个软件开发过程中是动态变化的，但是每次迭代欲实现的用户需求
应该是稳定的，所生成的需求文档应处于受控状态，与项目计划、产品和活动相一致，并作
为开展软件开发工作的基础。
软件开发人员通过和用户的充分和持续性交流，支持需求确认和评审。
−软件项目计划
软件开发人员和用户一起参与计划的制定，包括估算规模和进度、确定人员分工；项目
计划的制定者应参照用户需求来制定软件项目计划，包括系统应当满足哪些需求、应当首先
满足哪些需求、每次发布的版本应完成多少功能才会对用户的业务有所改善等等。
软件项目
计划不应过细，应保留一定的灵活性。
同时每次迭代要量力而行，确保要实现的系统功能不
要太多。
多个迭代欲实现的系统功能和迭代周期要大致相当，防止软件开发周期的剧烈变
化，支持稳定和可持续的软件开发。
此外，每次迭代的软件开发周期要适中，不宜过长否则用户会失去耐心，无法及时得到反馈；也不宜过短，否则用户难以消化，同样影响反馈。
−跟踪监督
在对敏捷软件开发项目的跟踪和监督过程中，软件项目管理人员要特别关注以下的软件风险：
（1）对规模和工作量的估算过于乐观，该软件风险将影响项目的周期性迭代；
（2）软件开发人员和用户之间的沟通不善，该软件风险将可能导致软件需求得不到用户的认可和确认；（3）需求定义不清晰和不明确，该软件风险将可能导致需求不清，所开发的软件系统和用户要求不一致；（4）项目组成员不能有效地在一起工作，该软件风险将可能导致软件开发效率和软件项目组敏捷度的下降；（5）任务的分配和人员的技能不匹配，该软件风险将导致软件开发不能做到以人为本；（6）软件设计低劣，该软件风险将可能导致所开发的软件系统无法适应用户需求的不断变化和调整等等。
1.4极限编程
极限编程是由KentBeck提出的一种特殊的敏捷软件开发方法[3][4][5]，它提出了更加具体和实际的指导方法以支持软件系统的敏捷开发。
极限编程将其核心思想归结为四条：
（1）交流，极限编程强调交流对于软件系统开发的重要性，但是它侧重于基于口头（而不是文档、报表和计划）的交流；
（2）反馈，极限编程主张通过持续、明确的反馈来获得软件的状态，它对于软件项目的成功实施是至关重要的；（3）简单，极限编程主张用最简单的技术来解决当前的问题；（4）勇气，极限编程强调快速开发并在必要时具有重新进行开发的信心。
在此基础上，极限编程定义了五条指导性原则和十二条必须遵循的核心准则。
按照极限编程创始人KentBeck的观点，极限编程并没有引入任何新的概念，它的创新之处在于：
将经过数十年检验的准则结合在一起，确保这些准则相互支持并能够得到有效执行。
n指导原则极限编程的四条价值观构成了整个方法学的基础，在此基础上极限编程引出了五条原则作为行为与实践的指南。
1.快速反馈极限编程要求软件开发人员从用户处迅速得到有关软件系统的反馈情况，比如软件开发
人员通过小步迭代迅速了解用户的反应，以确认当前所做的开发工作是否满足用户的需求，通过经常性的自动化测试和集成迅速了解软件系统的运行状况。
2.简单性假设极限编程要求软件开发人员只考虑当前迭代所面临的问题，无需考虑将来（如下一次迭代）所面临的问题，并且用简单的方法和技术来解决问题。
3.逐步更改极限编程要求通过一系列细微的修改来逐步解决问题和完善系统，不要期望一次迭代就开发出一个完整的软件系统。
4.支持变化极限编程要求在软件开发过程欢迎用户改变需求，支持用户需求的动态变化。
5.高质量的工作
极限编程要求采用诸如测试驱动开发等技术高质量地开展工作，确保所开发软件系统的质量。
n核心准则极限编程总结出了十二项核心准则以指导软件系统的开发。
这些实践在日常的软件工程
化开发大多为人们所采用，然而单独采用某些准则却有可能会导致混乱，极限编程的独特之处在于将这些核心准则有机结合在起来以达到最佳效用。
（1）计划游戏（PlanningGame）计划游戏旨在帮助软件开发团队快速制定下一次迭代的软件开发计划。
参与计划游戏
的人员包括软件开发人员和业务人员。
业务人员在计划游戏中的职责包括：
确定范围即系
统应当满足哪些需求、规定需求的优先级即应当首先满足哪些需求、划分版本即每一次发布
的版本应当完成那些功能才会对用户的业务有所改善、规定发布日期等等。
业务人员的计划
决策需要得到软件开发人员的反馈和支持。
软件开发人员在计划游戏中的职责包括：
估算
实现每项功能所需的时间、解释业务人员的决策在技术上的影响如数据库的选择对软件的影响、制定日程安排、分配工作等等。
（2）隐喻（Metaphor）隐喻是指使用一组与业务相关的术语来描述用户需求，促使软件开发人员和业务人员
对系统达成共同和一致的理解。
由于软件开发人员、业务人员及用户之间使用业务术语（而
不是技术术语）进行交流，因此该准则有助于加强他们之间的沟通和合作，及时从用户处获
得反馈并支持用户更好地参与到软件项目之中。
采用隐喻对软件开发人员而言也存在挑
战，即如何将用业务相关的术语所描述的用户需求转换成为软件所应俱备的功能。
隐喻的选择应该仔细、恰当，不好的隐喻不仅无益于软件系统的开发，而且还会带来负面影响。
（3）小型发布经常性地给用户发布能给他带来业务价值的可运行软件系统，每次发布的软件系统仅提供少量的功能。
小型发布不仅有助于缩短软件开发周期，提高软件开发小组对软件开发进度的估算能力和精度，而且由于每个小型发布包含了对用户最有价值的核心功能，因而有助于从用户处获得对软件系统使用情况的真实反馈信息。
（4）简单设计所谓简单是指程序代码能够运行所有的测试、没有重复的逻辑、清晰地反映程序的意图、
包含尽可能少的类和方法。
与大多数传统软件开发方法不同的是，极限编程要求只为当前
的需求做设计，而不必考虑将来可能的需求。
这样做是基于以下几个方面的考虑。
首先，对
未知的需求考虑过多势必会影响软件开发人员当前的工作，增加软件系统开发的复杂度。
其次，未来的需求是不确定的，因此过多考虑未来需求将可能导致所开发的软件系统包含用户不需要的功能，增加了不必要的成本和开销。
（5）测试极限编程要求测试应在编写代码之前进行，而不是等到开发结束后再安排一个专门的
阶段对软件系统进行测试。
在简单设计之后，程序员首先编写测试程序，当测试程序完成之
后再正式编写待开发软件系统的程序代码。
测试程序是对代码进行重构的基础，通过运行
测试程序，可以检查重构是否引入了新的错误。
在软件测试过程中，每发现一个错误，就
增加一项新的测试，因而测试程序是不断增长的。
实践表明，采用极限编程的这种测试方法能使软件系统的质量不断得到提高。
（6）重构重构是指在不改变程序代码功能的前提下，改进程序代码的设计，使程序代码更加简
单，更易于扩展。
极限编程通过重构使软件系统具有灵活的结构，易于接受变化。
重构是一个持续的简化过程，适用于代码的设计和测试，甚至对极限编程本身也可进行重构。
（7）结对编程结对编程是指两名程序员同时在一台计算机上共同开展编程工作。
极限编程要求所有
程序代码都通过结对编程来完成。
这种编程方式有以下几个方面的优点。
首先，软件开发过
程中的每一项决定都至少由两个人来共同完成，对系统的每一部分至少有两个人熟悉，这
可以降低人员流动带来的软件风险。
其次，在进行结对编程过程中，
升级会员 