基于Umple的服务机器人控制系统设计外文翻译资料

摘要 特征作为一组行为，可以提供良好的重用性机制。然而，它们在重要方面受到了限制，并不存在于广泛使用的编程和建模语言中，因此不容易被主流开发人员使用。在本文中，我们将UML关联和其他建模概念添加到特征中，并通过模型驱动开发将其应用于Java和C 。我们还使用所需的接口扩展特征，因此语义级别的依赖关系成为它们使用的一部分，而不是它们的使用方式。在Umple中，这是一种基于UML的文本建模语言，它允许将编程结构添加到模型中。我们将工作应用于两个案例研究。结果表明，我们可以将模型的特征提升到建模水平，同时提高灵活性和可重用性。

关键词 可重用性 特征 建模 Umple UML

1 介绍

重用一直是软件工程的重要目标。在本文中，我们展示了增强的基于特征的重用机制。我们展示如何扩展特质以结合更深入的语义和建模抽象，如UML关联。 此外，我们演示了如何为流行的编程语言实现这一点。

软件重用研究带来了更高层次的语言、组件、生成方法、新架构和领域工程。这些抽象和继承的重要性起着特别重要的作用。继承以各种形式显示如单继承、多重继承和混合。然而，这些变体在概念上和实际上都存在问题。例如，对于多重继承来说，有一个名为“钻石问题”或“分叉连接继承”的麻烦的情况。对于混合物，还存在线性组成，胶水分散和脆性继承的问题。线性组合表示我们可能会发现混合物的总顺序不存在的情况。胶水代码的处理表明，为了解决冲突，有时开发人员需要修改mixins，引入新的mixins或者使用相同的mixin两次。

为了克服这些问题，特征的概念是由沙特里亚尔引入的。另一方面作为课堂的基础，原始形式是一组纯粹的方法；它是一个简单而强大的代码重用单元。特征可以用于以组合方式构造面向对象的程序。它们已经在诸如Squeak和PHP的编程语言中本地实现。

在进行之前，我们想澄清一点，在本文中，我们不是在C 中提到的称为特征类的语义上不同的概念。这些是携带其他对象使用的信息来确定实现细节的小对象。例如，它们可以用于指示在C 程序中的“无效”。本文中使用“特质”一词是针对更广泛的面向对象文献的用法。

几项研究项目扩展了原有的特征概念。这些项目中的大多数都涉及到应用不同语言的特征或者显示新的特征应用。同时，模式驱动的技术正在进入开发社区，尽管缓慢。建模抽象例如状态机和关联提供了重用的新机会，并且可以与继承相结合以获得更大的可重用性。然而，先前描述的继承问题也适用于当抽象是可继承单元时；这表明特征和模型应该能够协同合并。

目前的情况是，大多数开发人员无法自己设计并获得软件灵活性，因为它们在主流编程语言（如C 和Java）或UML等建模语言中并不容易。因此，软件系统的重复数量比其他方式重复。为了解决所指出的问题，提供具有先进特性的特征，我们以三种方式扩展了经典特征：

（a）我们允许他们包括建模元素，特别是UML关联，状态机和约束。在这篇论文中，我们将讨论建模抽象限于关联。

（b）我们允许开发人员指定特征必须实现的客户端所需的接口，扩展所需方法的预先存在的概念。必需的接口强制特征的客户端来实现这些接口，以便使用特定的特征。设计人员可以构建层次化的必需接口，以提高一致性和更多的可重用性，或者使用已有的接口来构建所需的特征。

（c）我们使特征可以用于Java和C 等语言。

总而言之，这些增强功能在建模者和程序员的主流发展中都被引用。可以使用增强的特征来帮助构建可重用的模型和代码库，并且可以减少重复和重复的缺陷。

我们通过将它们应用于Umple来演示这些功能，这是一种文本建模语言，允许将编程概念嵌入到模型中。 在我们的研究中，我们并没有尝试将特质引入UML（这是一种图形语言），部分原因在于我们可以在文本建模符号中达到更高的表达能力。Umple遵循UML语义，但具有许多功能，例如混合和使用其文本形式的方面。特征是另一个这样的面向文本的功能。

我们研究的新颖性可以总结为（i）我们将特征的概念引入到建模层面，并将其与建模概念相结合，以便在模型驱动的开发环境中使用它们；（ii）我们在该建模环境中创建了一个用于特征的文本语法；（iii）我们有一个工作模型编译器，并且已经演示了使用从模型生成的代码创建的真实系统中的特征。

本文的其余部分安排如下：第2节扩大了我们研究的动力；第3节描述了我们用来实现我们的方法的Umple技术；第4节描述了除了扩展之外的经典特征的基本特征；我们通过第5讲的两个案例研究来重点评估所提出的特征；与我们的研究有关的工作见第6节。；第7节描述了我们的一些研究挑战；我们讨论了第8节中建模级别的特征引起的可重用性。最后，我们提出结论和未来的工作。

2 动机

模型，例如国家机器和关联，是可重复使用的元素，并且可以通过它们可用的类别来继承。本方法可以避免与程序中编程语言的其他构造方法相同的难题。特征的概念在编程语言中已经显示出来，他们可以克服这些困难。我们想探索其在建模语言方面的实用性，看看它们是否可以提供同样的优势-更好地模块化和改进重用的方法，以及解决围绕避免多重继承的一些问题的方法。此外，如果要在建模中使用特征，则其语法和语义需要与其他建模元素良好关联。我们想探索将模型级结构（如关联）结合到特征中的效果。

另一方面，在大多数流行语言（如Java和C ）中，并不支持特征，因此我们希望调查在这些语言中实现基于模型的特征的能力。换句话说，我们想探讨特征是否可以是平台无关模型的一部分，并且可以在平台特定的模型中使用，同时也不用担心在这些语言中没有对特征的本机支持。

3 Umple

为了探索模型级特征的概念，并展示了特征和扩展的可行性，我们在Umple中实现了它们。Umple是一个开源的建模工具和编程语言系列，使我们能够拥有所谓的面向对象编程。它将诸如关联，状态机和从UML派生的约束等抽象引入面向对象的编程语言。它还允许开发人员在建模阶段使用方面方向，设计模式，跟踪和现在的特征，而不用担心他们在不同目标语言中的真正实现。Umple中的所有概念都是文本定义的，文本语言遵循C语言的语言规范。尽管开始了文本，Umple还提供了一种定义视觉的方式。Umple的基于云的界面可以在[57]找到，涵盖文本和图形表示。有关Umple的文献出版了许多，因此我们提供以下有限的概述，以便读者能够理解本文中的符号。

列表1-10显示了Umple的示例。主要顶级实体是类，接口和特征。每个这样的实体都使用一个关键字（class，interface或trait）声明，后跟实体的名称，然后将一系列元素的大括号相匹配。顶级结构中的元素可以包括属性（被声明为变量，但是应用其他语义），方法（以其他C族语言声明），关联，约束，isA（泛化）指令，刻板印象和状态机。 具有关联的类的示例是：

class Club {0..1 -- * Person member;}

1. .1和*是UML中的多项式。“member”一词是给予关联的可选角色名称。-表示双向关联；在一个方向上导航的协会只能显示为“-gt;”或“lt;-”。约束是由方括号包围的布尔条件。isA指令指定泛化（单继承）或接口实现。单词“isA”后面是超类和/或接口。Umple采用这个惯例，允许设计从一种形式的继承变成另一种形式。正如我们将看到的，我们采用相同的表征法来表现特质。

4 方法的细节

在本节中，我们首先解释（在第4.1节中）来自编程语言基础的特征的已有特征。之后，我们在关联和需要的接口方面解释我们对特征的贡献（在4.2、4.3节中）。我们最初提供非常简单的抽象示例，说明特征的现有特征，以及我们自己的增强功能。然后，为了充分解释在区域系统的背景下使用我们的增强算法，4.4节中我们描述了基于特征的图形系统的设计。最后4.5节提出了各种自动代码生成机制，并描述了实现。

前面提到的是，我们不推荐为UML添加特质。 我们将它们介绍为与UML强烈对齐的Umple语言的文本建模概念，但不是UML本身。 也就是说，我们创建了一个图形表示，以帮助可视化特征。这不是提出的UML扩展，甚至是对论文的正式贡献; 它只是为了帮助解释特征的使用，并帮助读者了解它们。 在我们的方法中，生成图表，而不是使用绘图工具绘制图形。我们没有对编辑图表或使用它们在模型中创建特征是否可用或有用的声明。

4.1基本特征能力

最初引入的特征包括提供的方法和所需方法的集合。特征的客户端声明它们使用trait，在这种情况下，trait提供的方法的内容在逻辑上成为客户端的一部分。所提供的方法可以访问这些必需的方法中的功能。可以包含其他特征或类的客户端必须具有每个必需方法的自己的实现。访问任何客户端的属性，通过访问方法（即设置和获取方法，形成所需方法的子集）。

如果trait的客户端是一个类，也称为最终客户端，则该类必须通过自身或从其超类继承来满足所需的方法。最终客户可以使用任何数量的特征，并且必须满足所有使用特征的所有必需的方法。

当特征的客户是另一个特征，也称为组合特征时，有两种方式可以满足组合性状所需的方法。提供组合特征的组合特征提供方法将使组合特征的最终客户满足他们。当组合特征不满足组合特征的所需方法时，可以采用方法来满足所需要的方法。通过匹配方法名称，返回类型和参数来确定在客户端中满足的方法。诸如公共和私人的能见度是不相关的。

清单1和图1说明了这些情况。在Umple中，traits由关键字“trait”定义。特性属性和提供的方法的定义与属性和方法在类中的定义（具有可见性，名称，返回类型，参数和体）类似。然而，提供的方法不能是抽象的。如果方法被定义为抽象，那么它们被认为是必需的方法。

支持自动绘制在Umple中包含特征的图表。图表与UML中的类图类似，但有两个截面形式方法。右侧部分显示所需的方法，左侧部分显示提供的方法。 Umple还提供了一种将系统可视化为一种正常类别的机制，因为它们在平铺之后。开发人员可以轻松地在这两种视图之间切换，以更好地了解系统设计。

在清单1中，有两个类Class1（1-3行）和Class2（行4-8），两个特征Trait2（行9-14）和Trait1（lines15-19）。ClassClass2是classClass1的一个子类（第5行），并使用组合特征Trait2（第6行）。traitTrait2使用组合特征Trait1（第10行），并具有一个所需的methodmethod3（）（line11）和两个提供的方法method1（）和method2（）（第12-13行）。traitTrait1在本例中是一个组成特征，它有两种方法method1（）和method2（）（第16-17行）；一种提供方法method4（）（第18行）。通过提供的特征Trait2的方法，满足特征Trait1的所需方法。另外，通过Class1类中的方法，满足特征Trait2所需的方法method3（）。

当一个组合使用一个组合的特征时，有一种情况，即组合特征的某些所需方法可以由类和组合特征两者来满足。在这种情况下，来自类别优先级的满足（或实现），并为这些所需的方法验证了有效性。在清单1中，例如，特征Trait1的所需方法method2（）通过提供的特征Trait2的方法和Class2类的方法来满足。在这种情况下，提供的特征Trait2的方法将被忽略。 因此，单一继承的结果和Class2类的特征是四个具体方法method1（），method2（），method3（）和method4（），其中特征Trait2的具体方法method2（）不起任何作用。

使用特质并不总是一个直接的机制，有时也有冲突。提供的方法是在客户端出现冲突的主要原因，派生于不同的层次结构。具有相同签名的方法来自两种不同特征的客户端，它被认为是冲突，必须解决。然而，如果该方法来自两个不同的特征，但具有共同的来源（即，不同的特征使用共同的第三特征），则不被认为是冲突。自动在我们的实现中检测到冲突。

清单2显示了两种情况的象征性例子，其中一种情况导致冲突，另一种则导致冲突。Class1类使用两个特征（第2行），因此，将得到两个方法-方法1（）和方法2（）（lines5-6）），来自两个不同的特征Trait1和Trait2。对于method1（）没有冲突，因为Trait1和Trait2从一个普通的源（TraitTrait3）获得相同的方法。

但是，由于此方法已被traitTrait2（第13行）覆盖，所以method2（）不是这样。换句话说，来源现在是不一样的。因此，在Class1类中，存在冲突。重要的是要注意，此示例没有图形表示，因为Umple检测到冲突并且不允许生成不一致的图。

解决这种冲突有两种机制。第一个是别名（或重命名），第二个是删除。别名允许重命名一个冲突的方法，所以客户端可以访问这两种方法。删除可以让开发人员移除其中一个冲突的方法，因此不再需要更多的访问，因此避免了冲突。选择这两种方法之一取决于应用程序的结构和开发人员的需求。为了通过重命名来解决清单2中的冲突，以下是Umple语法，它必须替换Class1类的第2行中的语法：

isA Trait1, Trait2 lt; -method2() gt;;

减号表示“删除”，这样就不会产生方法2（第13行），它来自特征Trait2，只有具有相同名称的方法来自traitTrait1.同样的冲突也可以解决通过使用重命名，其中一个新的名称method3（）将被提供给一个冲突的方法。此外，还可以改变重命名方法的可见性，以限制对其的访问。必须在Class1类而不是第2行使用的语法如下。 此语法还使重命名的方法是私有的，以免让其他类有权访问它。

isA Trait1, Trait2 lt; method2() as private method2() gt;;

特征也可以更一般，这

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[141325]，资料为PDF文档或Word文档，PDF文档可免费转换为Word