概要
模型驱动软件开发的出现为快速原型设计带来了新的机遇和挑战。一方面，建模过程本质上是抽象的，从细节中消除原型设计，并且让他或她专注于探索系统各个方面的设计选择。另一方面，最流行的建模语言和工具完全省略了用户界面的建模和生成。因此，用户界面原型作为与用户和客户交互的媒介的好处将会丢失。本文提出了一种称为Umple的面向模型的技术，可用于编程和支持模型驱动工程。Umple允许最终用户快速创建类和状态机模型，并逐步嵌入实现工件。在建模过程的任何时候，用户都可以快速生成一个功能完整的原型，从而在用户界面上显示建模意义，并允许利益相关者了解整个系统的行为方式。版权所有copy;2011 John Wiley＆Sons，Ltd。
1．介绍
在本文中，我们描述了一种名为Umple的技术如何帮助将模型驱动开发和快速原型开发方法结合到软件开发中。Umple可以快速开发数据和行为模型，以及生成用户界面。 这些模型可以作为标准UML图，在UML的文本表示中出现，允许编程语言代码的合并，或作为两者的组合。原型可以在几分钟内完成，可以被丢弃，也可以逐渐增强，以构建最终的系统。
软件行业的原型制作起着不可或缺的作用。霍夫曼和莱纳指出，“大多数软件项目都使用了某种原型”。在早期开发活动中，可以使用一次性的原型（也称为软件尖峰）来帮助定义系统范围，评估可行性和估计工作量。在后期阶段，通常使用进化原型（有时称为模型原型，或敏捷环境中的示踪子弹），原型演化为工作生产系统。
每种原型方法都有优缺点。制定特定类型原型或根本不开发原型的决定是基于若干因素；然而，保持原型的成本低是至关重要的。将一次性的原型转变为进化原型并随后改进为最终可交付产品并不罕见。
Lim et al很好地概述了原型的原因。他们说：原型是一种活动，其目的是创造一种表现形式，以最简单的形式过滤设计师感兴趣的品质，而不会扭曲整体的理解。他们还提出了他们的经济原则原型，这是一种以最简单和最有效的方式，使设计理念的可能性和局限性变得可见和可衡量的原型。设计理念可以是用户界面设计，数据种类由系统操纵或底层系统将捕获的应用程序域的表示。本文提出的研究目的是展示我们如何将所有上述的基本方面原型化在一起，重点是应用程序域数据（UML类图）和行为（状态机），同时滤除许多其他细节，如持久性机制，算法等。
Umple提供了一组UML建模抽象的文本符号，如类，关联，状态和转换。 这些可以自己用于快速和抽象地对软件系统的数据和行为进行原型化。或者，Umple可以直接嵌入到多种编程语言中，以减少所需的代码量并加快编程过程。Umple还提供了一种允许以图形形式编辑UML类图的工具，文本形式出现在图表的编辑中。模型的后续编辑可以通过视觉方式执行，进一步促进实现。使用Umple编译器可以生成可执行系统，并附有原型用户界面。
1.1 模型驱动的开发和挑战，同时遵循原型制作方法
模型驱动的软件开发（MDSD）虽然尚未被普遍接受为最佳实践。使用UML等语言的模型本身已被软件开发人员使用多年。MDSD的理念是，这些模型应该用于直接生成可执行系统。
在概念上，从模型生成原型应该始终是固有的，因此将原型设计作为模型驱动方法的核心部分。然而，目前设想的MDSD对原型设计构成了几个挑战：
- 尽管UI模型在验证客户端和用户的原型方面是非常有价值的，但最受欢迎的模型类型并不是用于建模用户界面。特别是UML模型通常涉及内部系统数据（类模型），组件（组件，包和部署模型）和行为（状态，活动，序列和通信模型）；
- 结合代码生成从模型中选择需要的代码不可信。在模型中无法表示的这些代码包括用户交互所需的计算算法和详细信息。通常的做法涉及编辑生成的代码以添加这样的代码。然而，必须使用复杂的机制来允许对模型进行更改，而不会导致生成的代码覆盖对以前生成的代码的编辑。经常使用一种叫做“往返”的做法。这需要捕获生成的代码的更改，以便在重新生成代码时自动重新应用。另一种方法包括用信息注释模型以指导用户界面生成。这两种方法都涉及相当大的复杂性，因此不利于快速原型制作；
- 原型对通常不了解软件建模符号的业务领域利益相关者尤其有用。因此，需要产生有形的事实，无论是屏幕模型还是可执行程序。模型本身就不能满足这个需要；
- 软件建模者通常不能完全了解其建模决策的后果。我们以前的研究表明，建模者经常创建不反映系统意图行为的模型。有时，模型的存在实际上可能导致过度自信，并且引导开发人员认为他们不需要真正创建一个原型；
- UML模型中原型生成的现有方法存在局限性。现有的原型方法依赖于一种特定的建模符号（例如状态图），并且仅为该符号生成代码。然而，在典型的软件项目中，有几个建模符号来描述相同的系统（例如，类图，活动图和状态图）。因此，期望从模型的许多相关方面生成原型。此外，特别是支持原型生成的建模工件的注释是不可取的，因为模型不断更新。除非注释被紧密地集成到建模符号中，否则这种注释的维护很快就会变得耗时。
本文中描述的Umple方法试图解决上述问题。它允许从模型（问题1）即时生成UI。它通过允许在模型中直接嵌入任意代码来解决往返（问题2）的问题。它本质上是可执行的（问题3）。一个糟糕的模型将不会创建一个有效的可执行系统，而且这种解决方案可以快速解决问题。最后，它结合了多个UML建模概念（问题5），允许系统的任何或所有方面在需要时同时进行原型设计。
1.2 原型的理想属性
我们认为原型的以下属性至关重要：
- 准确反映系统部件和数据；
- 准确反映当前系统设计方向，对未来设计和实施决策的贡献；
- 由于与原型相关的成本（努力和时间）是原型的完整性（保真度）背后的主要因素，因此快速而便宜地生成原型；
- 最大限度地利用和组合的潜力；
- 支持不同层次的抽象；
- 支持增量开发。
本文报告的工作支持所有这些属性。 我们将在结论中重新审视这个标准清单，以展示Umple如何满足他们。
原型中的完整性水平是其成功的主要因素。例如，Jones et al. state：“原型功能完整的事实对于其在引发需求方面的成功至关重要”。 然而，开发原型的成本和原型的完整性水平是成比例的。因此，重要的是定义原型功能的哪些方面最重要，以便利益相关者能够专注于它们。
Throwaway原型是成本敏感的，但利益相关者通常不愿意投入大量的努力。它们是探索设计替代或新技术的重要方面，但是除非能够非常便宜地生成它们，否则应该谨慎使用。本文报道的工作确实允许这样快速生成。
另一方面，进化原型演变成最终的工作产品。利益相关者更愿意为这种原型投入大量的精力和时间，因为在项目中保持了努力。这类原型变得越来越有吸引力，原因如下：
- 敏捷和其他迭代开发方法倡导开发可执行的可执行文件，它们是以前版本的小型增强版。这些类型的方法与进化的面向原型的方法相融合；
- 支持进化原型的技术开始出现。因为模型，特别是在以迭代模型为中心的开发方法中，不断更新和增强，因此能够从不完整模型生成原型很重要。从不完整的模型生成工件将不可避免地需要一些开发干预来填补空白以产生可用作原型的有形工件。如果基础工具和开发过程不能适应迭代开发，则可能会浪费这种努力。
本文提出的概念可以用于一次性和进化原型。
本文的组织如下：在第2节中，我们提供了Umple技术的概述，并描述了如何用它来支持原型的生成。在第3节中，我们讨论了从UML模型生成原型的其他研究。该文件在第4节中得出结论。本文是RSP 2010会议中出现的论文的扩展版本。
2.模拟技术
为了支持以模式为中心的系统快速发展的环境，必须在高层次的抽象支持系统方面的发展和必要的某些较低级别的细节。正如Pomberger等指出，完整的原型很少只能用发电机和可重复使用的软件来生产。高度复杂的零件仍然需要手写。这是Umple的方法。Umple将高级系统抽象和较低级别的“常规”代码组合在相同的开发工件中，从而可以设计系统，并逐步添加开发的组件。此外，Umple结合了类和状态机模型的建模，并支持来自两个建模符号的原型生成。
对于UmpleOnline，特别感兴趣的是在线网络应用程序UmpleOnline。该工具允许创建和编译任何Umple程序，并将其存储在云中。UmpleOnline还提供了一系列Umple示例。通过遵循从UmpleOnline到Umple主页的链接，读者可以找到用户手册的链接，一个描述Umple整体哲学和远景的文档，一个使用Umple来建模或编程的开发人员的指南，Google Code的开源存储库，关于Umple的三篇论文，以及几篇论文。Umple自2008年以来一直在开发中，并被用于几个小型工业项目。
基于Umple的系统可以使用Eclipse插件或独立编译器开发，这两个编译器都可以通过以下方式获得来自UmpleOnline网站的链接。
图1说明了使用UmpleOnline。
图1. UmpleOnline Web应用程序显示一个UML模型在以文字和图形方式进行编辑
2.1 Umple建模和原型设计方法
如上所述，Umple支持视觉或文字建模。在独特的图形环境中创建模型可能是一项艰巨的任务，特别是当模型较大时，会导致许多具有交叉线的形状，或许多单独的图必须以某种方式相互关联。以鼠标为中心的方法需要重复微调布局。文本图1. UmpleOnline Web应用程序，显示一个UML模型，以文字和图形方式进行编辑。相比之下，编辑器支持许多功能，如语法驱动的编辑，搜索和自动缩进，可以使创建和编辑文本的过程更省时。此外，文本方法可以促进重用概念，如mixins。
另一方面，图形模型可以更好地进行通信和协作。特别是关系可以更清楚。Umple的目标是支持这两种方法的好处。它提供用于创建模型的文本环境，而不会影响与模式相关联的优点。使用者可以使用简单的抽象语法符号或使用任何UML图表工具来验证模型。Umple消除了模型和实现代码之间以及文本和图形建模之间的界限。更改立即反映在两个视图中。相同的工件可以包含多个建模符号（状态机和类图）。另外，建模和实现工件会合并在同一个文件中。下一节通过简单的例子说明这些概念。
2.2 Umple中的类图
以下是显示三个类，两个关联和一个属性的Umple模型。
class Student {}
class CourseSection {}
class Registration
{
String grade; // an attribute: get and set methods are generated
*-- 1 Student; // an association: A registration has 1 Student
*-- 1 CourseSection; // another association
}
相应的UML类图如图2所示。该图可以由读者简单地将上述文本粘贴到UmpleOnline工具中。
图2.与Umple代码对应的类
开发人员可以以与运行任何编译器相同的方式编译上述代码。例如，在UmpleOnline中，我们称之为“基本语言”或“动作语言”的“Generate Code”button代码能够在Java，Ruby，或PHP中生成。此外，可以生成许多其他类型的工件，包括UI原型代码。这将在短时间内讨论。
在建模阶段或之后，使用Java，PHP或Ruby编写的方法可以直接嵌入到Umple代码中，从而可以从纯模型平滑过渡到更完整的系统。使用Umple以外的语言编写的任何代码由Umple编译器不变地发送，并传递给基础语言的编译器。
Umple生成代码来实现关联多项式的所有组合，包括单向和双向关联，以及反身关联。维护参照完整性，并在运行时遵守多重约束。这样就可以让人玩“原型”来操纵受限制的数据样本，因为数据将被限制在最终的系统中。
Umple支持唯一的属性，其值在每个实例中必须不同，以及不可变属性，其中值在构造后不能更改。创建新对象时，不可变字段最初是可编辑的，但之后字段变为只读字段。还可以定义一组关键属性，这不仅表明这些属性是不可变的，而且还定义了两个对象的“等同”是什么意思。Umple的关键语法如下：
key { attribute1, attribute2, .., ..}
以下是Umple的另一个例子，这一次显示了使用命名空间并指出一些元素形成唯一的键，并且还说明了Umple程序中如何存在普通的Java方法。请注意该方法调用getName（）；这是在编译Umple抽象时生成的API之一。相应的UML图如图3所示。
图3.具有“可选”的第二个类图，即0 ... 1的多重性
namespace education;
class School
{
String name;
String address;
String description;
0..1 --*Person student;
key {name}
}
namespace human;
class Person {
String name;
Integer idNumber;
key {idNumber}
String firstLetterOfName() { //
return left(getName(),1);
}
}
2.3 Umple用户
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[141330]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
课题毕业论文、外文翻译、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
