英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
敏捷软件工程的双重应用模型
摘要：
传统的软件工程和敏捷软件开发都存在着一些问题。本文提出了一种被称为敏捷软件工程的新方法，该方法结合了传统的软件工程和敏捷软件开发的优点，同时，本文将描述该方法的一个方面。双重应用程序模型涉及到逻辑软件应用程序和物理软件应用程序的开发，前者侧重于捕获功能性需求，后者侧重于转换逻辑应用程序以满足非功能性需求。和所有的软件开发方法一样，该方法拥有自己的优点和缺点，但是它满足敏捷软件工程中提出的两个原则。本文提出了支持双重应用程序模型的框架和工具，但它们对于该方法而言并不是必需的。该方法在领域解决方案/软件问题的定义说明(通过代码)和实现软件解决方案以满足非功能性需求之间提供了一个几乎完全分离的关注点，前者主要由领域的专家负责和设计，后者主要由软件开发人员负责。
1.简介
根据[1]的一项对全球开发者的调查报告显示，敏捷软件开发(ASD)已经以35%的比例成为了主流，在传统软件工程(TSE)和瀑布式软件开发(WSD)中占据主导地位，前者的比例为21%，后者为13%。这并不意味着TSE(甚至WSD)中的一切都是错误的，而ASD中的一切都是正确的。事实上，在从TSE到ASD这样一个戏剧性的转换中存在着将婴儿连同洗澡水一起倒掉的风险。将TSE (甚至WSD)中的那些已被证明是有效的理念和实践转移到ASD中是很重要的，不能仅仅因为它们是传统的就对它们（的作用）大打折扣(就好像新的理念和实践不应该仅仅就因为它们是新的而被接受一样)。
本研究项目的整体目标是开发一种结合TSE和ASD（甚至WSD）优点的软件开发新方法。本文代表了本研究的第一步。它讨论了最初开发这种新方法的背景，解释了这种新方法，包括一些理论和实践的优缺点，并讨论了进一步研究的领域(如该方法的数据支持功能)和支持新方法的开发(如开发工具、类库和框架)。
软件模型，像所有的模型一样，是由它们的范围(它们表示的宽度)、视角（软件的特定视图）以及它们的抽象级别（模型中包含的细节或复杂性的数量）来定义的。模型也有许多不同的表示形式(例如物理模型、文本模型、图形模型、数学模型和计算模型)，每一种都有其不同的特征、优点和缺点。
软件开发是关于建模的。软件模型包括文本模型(例如用户故事、用例和需求文档)、图形模型(例如类图、序列图)和其他模型(例如数学模型)。人们经常过于关注源代码而忽视了重要的软件模型。应用程序的源代码(并且是可执行的)是另一种模型，它仅仅恰好是可执行的(即可以直接运行或解释运行)，又是软件开发主要目标(即构建软件应用程序)。
软件模型可以表示软件中实体之间的静态关系(大部分)，有点类似于照片。静态模型的例子有UML类图和部署图[2]。软件模型还可以表示软件中实体内部和实体之间的动态，有点类似于电影。动态模型的例子有UML序列图和交互图。
软件开发就是解决问题。因此，所有的软件开发，不管使用哪种方法，都要经历相同的生命周期（需求、分析、设计和实现），不依赖于方法采取的形式，也不依赖于构建(或不构建)的模型。WSD的目标是只进行一次软件生命周期的迭代，而TSE和ASD的最佳做法是高度迭代和增量式开发。人们编写的所有源代码都有一些指导开发并提供环境的设计、分析和需求说明，即使这些都是在开发人员的头脑中完成的。
本文的下一节将讨论传统软件工程和敏捷软件开发中的一些问题，以及基于两者优点的一种解决方案，即敏捷软件工程。之后的一节将介绍双重应用模型作为一种与敏捷软件工程兼容的软件开发方法。本文最后对该方法进行了进一步的讨论，包括相关工作、常见问题的解答、可能的工具或框架以及未来的研究方向。
2.敏捷软件工程
在这里，传统软件工程(TSE)被定义为在敏捷软件开发出现之前进行的最佳实践。根据Rational Unified Process [3]的例证，它是有计划的，高度迭代的和增量开发的，并且使用了许多正在开发的软件系统的模型。敏捷软件开发(ASD)在这里由Agile Manifesto [4]定义，它往往是高度迭代的和增量开发的，但是它是自适应的，而不是有计划的，并且它通常比TSE包含更少的正式流程和更少的持久模型[5]。
2.1.分析与设计
分析是理解领域和软件问题本身的过程。在这里，“问题”一词是指将要承担的任务，例如在满足特定约束的特定领域中，开发一个软件系统来执行特定的信息处理和存储。分析指独立于任何可能的最终解决方案，对问题进行建模，特别是独立于任何非功能性需求和关于解决方案的任何决策。分析或逻辑模型是问题的模型（不仅仅是问题域的一般模型）。
设计是使用满足非功能性需求的特定实现技术来确定和说明问题解决方案的过程。本质上，如果没有非功能性需求或实现约束，就不需要设计。在软件开发中，分析模型实际上是一个满足功能性需求（而不是非功能性需求）或实现约束的解决方案。设计模型或物理模型是使用所选的实现技术对分析模型进行修改以满足非功能性需求的，解决方案的模型[6]。
软件开发最初是由领域问题(例如业务或技术领域)驱动的。然而，从定义上讲，解决领域问题是领域专家的任务。企业如何解决其业务问题，信息处理问题，寻找某些技术业务问题的解决方案等，这些并不是软件开发人员的任务（尽管它看上去是，至少在企业中，这种情况经常发生）。
对于任何的领域问题，都有一个由领域专家从一组可能的领域设计中选择的，用以满足领域内的功能性和非功能性需求的领域解决方案。软件开发人员的任务是将此领域解决方案作为具有自身非功能需求的软件开发问题，并从许多可能的软件设计中找到最合适的软件解决方案。领域解决方案本质上是功能需求和分析或逻辑模型，是软件系统应该做什么的完整说明。
表1.领域问题解决方案和软件问题解决方案
使用自动化的工具来同时分别创建逻辑模型的不同表征(如使用CASE工具)和物理模型的不同表征是可能的。使用工具来实现从逻辑模型到物理模型（或相反）的自动化转换通常是不可能的（至少不是完全自动化转换）。这是因为，这里是进行创造性设计、做出权衡、确定满足非功能性需求的解决方案的地方，而且还没有任何方法可以完全自动化地实现这些决策(或在解决方案库中搜索决策)。
总之，软件分析就是在领域专家的帮助下，理解逻辑模型中提出或开发的功能性需求。例如，对于软件来说，这可以通过用户故事、用例或需求文档以及其他各种分析模型来完成。然后，软件设计就是把逻辑模型变成物理模型，并使用所选的实现技术确保结果满足非功能性需求。
对于软件开发而言，非功能性需求可以是运行速度、可靠性、易用性、可扩展性和稳定性等特征。由于这些不同的非功能性需求，我们在软件开发中有不同的角色和专业知识，如算法设计人员、UI设计人员、持久性设计人员和软件架构的设计人员(随着系统的开发而提前或增加)。软件分析是领域解决方案的理解和建模(如果这些还没有提供的话)，而软件设计是寻找满足非功能性需求的领域解决方案的软件实现。
分析/逻辑模型的好处是：1）他们只关注软件问题/领域解决方案。2）它们独立于与所有和软件解决方案相关的决策（例如架构或技术决策）。3）它们独立于所有的非功能性需求(例如，它们不必关心自己是否满足非功能性需求)。不可避免的，问题一定有一个逻辑模型，即使它只是部分的或者只是在软件开发人员的脑中临时存在。
2.2.传统软件开发和敏捷软件开发中的问题
在作者看来，TSE的主要优势之一是其软件开发的多模型方法。拥有能够在软件开发生命周期的不同阶段，提供不同观察角度的模型，开发人员就可以关注软件开发任务的特定方面（例如：需求、分析、设计、实现）。正如其他学科的工程师也使用多种模型(例如建筑和道路)一样，我们有充分的理由认为这是软件开发工程方法中的一个关键方面。
与本文相关的传统软件工程中最大的实践问题不是瀑布方法(正如许多敏捷软件开发者非正式地争论的那样)，因为传统软件工程的最佳实践是高度增量和迭代开发。最大的问题是开发的各种模型时，(例如需求、分析、设计和代码)彼此间迅速就变得不同步，特别是当开发者在没有更新其他模型的情况下更改代码时。
需求(结合功能性和非功能性需求)和分析(仅功能性需求)模型通常也是静态和动态文本模型、图形模型，数学模型的集合。静态文本和图形模型可能很快变得非常复杂和难以理解，而动态文本和图形模型在捕获领域解决方案的全部动态特性方面存在困难。由于它们的形式或者它们是部分的、不完整的，这些模型也很难验证。
敏捷软件开发(ASD)的主要优势之一是软件的增量开发，没有详细的总体计划，甚至没有详细的需求说明书。软件开发工作通常是一次完成一个(垂直的)部分，来为用户和利益相关者创造增量价值。实现此ASD建议的最快方法是最低限度地使用其他建模，而且通常只是短时间地使用，来直接访问源代码模型。一般来说，ASD采用的模型甚至比“即时”模型还要少。大多数ASD模型(除了源代码)被认为只是临时的工件，并且通常只用于开发人员之间的短暂通信。
当然，ASD是一个非常广泛表现形式，所以很难说它有一个特定的问题(因为通常会有一种形式的ASD没有这个问题)。也就是说，与本研究最相关的问题，以及在ASD中常见的问题，是使用源代码模型作为所有与软件开发相关的主要内容和文档。源代码不仅包括功能源代码，还包括单元测试、测试工具以及代码中的其他支持代码和注释。物理模型代码(即最终解决方案)中包含所有文档和替代模型(包括逻辑模型)并不是最佳选择，这似乎是合理的。
ASD代码确实捕获了解决方案的大部分(如果不是全部)结构特性。例如，代码中隐含的是最终应用程序的架构、每个API的结构设计以及每个模块的最优算法和数据结构。然而，就其本质而言，这些是解决方案细节和实现细节。毕竟，它们是在所选实现技术中满足功能性和非功能性需求的源代码。问题是，逻辑模型通常没有被记录，因为逻辑模型和物理模型之间没有简单的映射。因此逻辑模型在人们只关注物理源代码时会丢失。
逻辑模型的一些片段可以以代码注释或独立文档(例如，用户故事、图，序列图)的形式保存下来。然而，这种独立的文档也会遇到和传统文档相同的问题，即如果解决方案发生变化，那么它就会很快过时和不同步。最重要的是,如果其他开发人员,例如维护源代码的开发者,想要真正理解问题域和域的解决方案，他们将不得不尝试在代码中通过所有满足非功能性需求的修改和所选的实现技术来理解它。源代码的目标是满足非功能性需求，而不是清晰地表达逻辑模型。
2.3.敏捷软件工程
敏捷软件工程(ASE)的目标是将TSE和ASD的优点结合起来，并克服各自存在的问题。它采用的是TSE和ASD的高度迭代和增量开发的方法，而且最常见的是ASD的自适应方法，而不是TSE的计划方法。不同于ASD有限的并且主要是物理建模的方法，ASE采用了TSE的多模型观点。它解决模型中不同步问题的方法主要是消除掉除源代码模型(或者源代码模型中可以表示的内容)之外的软件中所有的永久模型。ASE解决模型不同步问题的方法是鼓励维护多个模型，并在逻辑或物理空间中分别提供工具或自动生成模型，以便保持同步。
本文重点研究了上述问题，即在TSE中，需求、分析和设计模型变得不同步，ASD中缺乏分析或逻辑模型。一个开发方法如何拥有多个不会(或者至少不应该)变得不同步模型（不仅仅是物理模型）? 本文也没有对ASE进行完整的描述，这项工作仍在进行中，但是这里给出了一些与这些问题相一致的ASE的一般原则:
适当模型原则：该原则指出，处理问题的逻辑方面的最合适位置是在问题的逻辑模型中，而处理软件解决方案的物理方面的最合适位置是在物理模型中。
这似乎是显而易见的，但在ASD中通常不是这样做的。如前所述，ASD主要工作于源代码模型，即系统的物理模型。所有的逻辑模型要么隐含在物理模型中，要么是在生成物理模型后就丢弃的临时模型。
不可逆向工程原则：这个原则是前一个原则的推论，它指出逆向工程或者从物理模型返回到逻辑模型是不合适的。一般来说，即使可能，这样做也违反了先前的原则。
当然，后者并不意味着如果可能和必要时，你仍然不能进行反向工程，例如，如果你接收的代码没有任何逻辑模型。其目的是不鼓励开发人员从传统的源代码(即物理模型)开始，然后在需要时尝试回退到逻辑模型，因为这通常是很难完全完成，如果可能的话。
3.双重应用模型
ASE的目标似乎很难实现——将TSE和ASD结合起来——至少满足上述原则。在本节中，我们提出了一种软件开发方法，双重应用程序模型(DAM)，它至少在一定程度上踏出了该方向上的一步。
在详细解释双重应用程序模型之前，应该说明，它只涉及软件开发方法的特定方面(尤其是开发了哪些模型)。对于软件开发的所有其他方面，该方法都采用当前软件开发中的最佳实践。例如，使用Scrum[7]方法进行高度迭代或使用Kanban[8]方法进行工作管理，使用单元测试和验收测试驱动开发。尽管本文探讨了两种模型的发展,但是这绝对不是说,这些将采用瀑布流形式开发,可能每步都是在多次迭代中增量地构建，就像传统的ASD方法中开发源代码模型一样,或者,这些必然是唯一的模型开发。
3.1.双重应用模型概述
DAM建议软件开发人员开发两个应用程序，而不是他们将要部署的一个。第一个应用程序称为逻辑应用程序(LA)，它实现领域解决方案/软件问题的可运行的逻辑模型。第二个应用程序被称为物理应用程序(PA)，它实现了所需软件系统的物理模型，该模型实际上就是所需的软件系统。
图2：逻辑应用和物理应用
这种DAM方法听起来可能很疯狂。为什么开发人员要做两倍的工作来获得相同的结果？这些假设(需要证明)是：1）将有一些额外的工作，但不会是两倍的工作(将解释)。2）这种方法还有其他优点，比如更高的质量和整体生产力，这些优点超过了额外的工
全文共15190字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[598]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
