特定领域设计模式的构造和重用方法及其在RT领域中的应用

Journalof King Saud University沙特国王大学沙特国王大学学报www.ksu.edu.sawww.sciencedirect.com一种构造和重用领域特定设计模式的新方法：在RT领域的Saoussen Rekhisa，*，Nadia Bouassidaa，Rafik Bouaziza，Claude Duvalletb，Bruno SadegbaMIRACL，PoleTechnologiquedeSfax，BP 242，Sfax3021，TunisiabLITIS，UFR des Sciences et Techniques，BP 540，76 058 Le Havre Cedex，France接收日期：2015年9月18日;修订日期：2016年4月19日;接受日期：2016年2016年4月27日在线发布特定领域的设计模式捕获领域知识，并提供特定领域中非平凡设计问题的解决方案。它们的应用大大提高了软件设计的质量。为了从这些优势中受益，并加强这些优势的应用模式，在本文中，我们提供了新的过程和工具，用于开发和实例化特定领域的设计模式，特别是那些用于实时领域的设计模式。首先，我们提出了一个模式开发过程，指导模式开发人员在建设模式。所提出的过程定义了统一规则，这些规则在模式域中的各种应用中应用一组比较标准这个过程通过控制器模式的设计来说明此外，我们还提出了一个基于模型转换的模式实例化指导过程最后，建议的RT模式和他们的开发过程进行评估，通过计算质量指标和比较的应用程序设计与我们的RT模式和其他专家开发的没有使用我们的模式。©2016作者。制作和主办由爱思唯尔B.V.代表沙特国王大学。这是CC BY-NC-ND许可下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。1. 介绍*通讯作者。电 子 邮 件 地 址 ： saoussen. fsegs.rnu.tn （ S.Rekhis ） ， nadia.bouassida@isimsf.rnu.tn（N.布阿西达），拉夫。布阿齐兹@fsegs.rnu.tn（R。Bouaziz），claude.univ-lehavre.fr（C.Duvallet），Bruno. sadeg@univ-lehavre.fr（B. Sadeg）。沙特国王大学负责同行审查制作和主办：Elsevier设计模式（Gamma等人，1994）代表了给定环境中常见设计问题的解决方案。它们大大提高了软件质量，降低了开发成本。如今，它们的使用非常广泛，因为它们捕获并促进了软件设计中的最佳实践。然而，GoF的设计模式（Gamma等人，1994年）不专注于一个特定的领域，因此，他们需要一个巨大的适应努力，因为它是很难确定在哪个上下文中或在系统的哪一部分，这些模式可以使用（端口，1998年）。这些原因激发了一些关于特定领域模式的工作，这些模式封装了特定领域http://dx.doi.org/10.1016/j.jksuci.2016.04.0041319-1578© 2016作者制作和主办由爱思唯尔B.V.代表沙特国王大学。 这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。关键词设计模式工程;模型转换;实时应用建模326S. Rekhis等人(e.g.、人机交互、安全和实时系统）。特定于领域的设计模式提供了一个具有清晰边界的灵活架构，根据定义良好和高度封装的部分，这些部分与所考虑领域的自然约束保持一致（Port，1998）。通过模式进行重用将带来许多好处的领域之一是实时（RT）领域，因为它是一个复杂且不断发展的领域。RT模式帮助设计人员开发表达时间约束数据和时间约束方法的应用程序。它们提供了各种解决方案来解决基本的RT调度，通信和同步问题（Boukhelfa和Belala，2015）。特定于RT域的设计模式类似于任何特定于域的模式;它们需要一种表示语言来显示域的特定性。它们还需要一个设计过程来帮助它们的构建，最终需要一个实例化过程来指导它们的重用（Boukhelfa和Belala，2015）。如今，特定领域设计模式的表示及其重用受到许多研究人员的特别关注（例如，Kim等人，2004; Kim，2007）。他们提出了建模语言，以考虑模式的可变性。事实上，当表示特定领域的模式时，设计语言，例如，UML不仅要支持模式的可扩展性，还要支持领域本身的特性（Port，1998）。然而，在实时（RT）领域的例子因此，已经提出了对UML语言的不同扩展，以考虑RT应用程序的特性（Douglass，2004;Lanusse等人，1999; OMG，2008）。然而，所提出的建模语言不适合模式。也就是说，RT模式必须是通用设计，旨在被RT领域中的任何应用程序专用化和重用。出于这个原因，除了表示RT方面的UML扩展之外，我们还需要新的符号来区分模式域中应用程序之间另一方面，特定领域模式开发和规范的困难减缓了其扩展。这主要是因为它们必须包含可扩展性和可变性，以便为域中的各种应用程序实例化。因此，需要一个设计过程来指导特定领域的模式开发，并定义规则，以找到所考虑领域中的一组应用程序及其可能的变化之间的相似性。这种需求在RT领域中是至关重要的，因为它是一个不断发展的领域，其中应用程序的种类非常多，重用非常重要。在RT域中，我们区分了应用程序使用大量RT数据的情况，这些数据必须存储在数据库中。我们称这种情况为“密集数据的实时域”。我们的贡献旨在通过定义统一规则来指导RT领域的RT设计模式的开发，这些规则具有密集的数据，便于它们的 规范。最后，请注意，即使在帮助模式开发人员表达和构建设计模式时，也不能确定这些模式是否会被应用程序设计人员正确地实例化因此，验证模式实例化的最终帮助一些研究人员（例如，Kim和Carrington，2006; Kajsa，2013;Hammouda等人，2009; Koskinen等人，（2010）感兴趣在模式实例的验证中，它们的方法并不适用于RT域。他们没有考虑UML扩展，区分被动资源和RT主动资源，并指定RT特性，如并发性和截止日期。因此，仍然需要一个有效的指导过程来重用RT模式。在我们的方法中，我们有兴趣提供帮助，不仅为模式设计师支持RT设计模式的表示和开发，而且为应用程序设计师实例化RT设计模式。这种援助是通过以下方式提供的：(1) 用于RT设计模式规范和重用的UML概要文件。这个概要文件建立了需要类似设施的不同系统之间的关系，并为建立RT系统的真正模式语言(2) 一种模式开发过程，使用统一规则来确定模式的基本元素和变化点。这个过程方便了模式开发人员它解决了结构和行为方面的问题，描述了模式的不同角色如何交互。(3) 用于构建和验证重用模式的应用程序的指导过程当在应用程序设计中部署模式时，必须保留一些约束模式实例化过程指导应用程序设计人员重用模式，并防止他们违反模式约束。本文的第一个贡献在于展示了我们的模式开发过程，最初在Rekhis等人（2010）中提出，可以改进，微调和自动化，以定义RT设计模式的结构。此外，在本文中，该过程通过RT设计模式的行为规范进行了扩展。本文的第二个贡献在于提出了一个新的模式实例化过程，指导应用程序设计师在RT模式重用，并防止他们违反模式约束。我们使用现有的建模框架EMF实现实例化过程，并将实现作为插件合并到Eclipse建模环境中。所开发的插件可以自动解释pat-terns的属性，因为它们是使用UML-RTDP profile以精确的方式描述的（Rekhis等人，2013年，我们定义了预处理。本文的第三个贡献在于定义了新的度量，并使用Chidamber和Kemerer（1994）提出的CK度量来实验性地评估我们设计过程的效率。对于我们提出的开发过程中获得的RT模式的评估，我们提出了一些项目的实验设计师，同时将他们分为两组，一组模型RT应用程序使用我们的模式的方法，和其他将不使用它们。然后，我们计算所生产项目的一些质量指标（例如，类的数量、属性的平均数量等）。评估回答了两个问题：RT模式是否具有良好的设计质量？RT模式是否真的概括了与RT域相关的概念本文其余部分的结构如下。第2节讨论了相关工作。第3节介绍了模式构建和重用特定领域的设计模式327hhiihhiihhiihhiihhiihhiihhiihhiihhiihhiihhiihhiihhiihhii hhii发展过程第4节提出了一个指导领域特定设计模式的重用和验证的过程，并描述了我们开发的支持CASE工具。第5节介绍了建议的RT模式的评价。第6节总结了本文，并讨论了未来的工作。2. 相关工作在本节中，我们首先介绍先前提出的轮廓（Rekhis等人，2013），它扩展了UML 2.2，使用新的立体类型表示RT域的设计模式。其次，我们简要介绍了通过统一现有应用程序或通过领域分析对专利开发感兴趣的作品。最后，我们提出的作品，提供支持和指导设计模式实例化。2.1. 基于UML-RTDP的在我们以前的工作中（Rekhis等人，2013），我们提出了一个UML概要文件，命名为UML-RTDP，包括描述RT功能的MARTE立体类型。由于下面描述的构造型，这个概要文件促进了模式的理解和实例化：– 可选原型允许表示可选元素（即，类、关联、属性、方法、接口、关联类）。– 强制构造型允许表示必须至少实例化一次的基本元素– 可变构造型表明方法实现根据模式实例化而变化。– 可扩展构造型表明模式类可以通过添加新的属性和/或方法来扩展– patternClass构造型用于区分实例化的模式类和设计者在应用程序模型中添加的原始类，并检查是否存在与模式属性的冲突。除了上面的构造型之外，RT设计模式的规范需要使用UML扩展来对RT方面进行建模。因此，我们从MARTE中导入了profilestereotype，它处理与行为、通信和并发相关的定量和定性特征。从HLAM（高级应用程序建模）子配置文件中，我们导入以下原型：– rtFeature（实时特性）构造型用于建模时间特性，如截止日期。– ppUnit（protected passive Unit，受保护的被动单元）原型用于对需要指定并发策略的共享数据进行建模。受保护的被动单元通过它们的concPolicy属性为它们提供的所 有 服 务 全 局 地 指 定 它 们 的 并 发 策 略 ， 或 者 通 过RtService原型的concPolicy属性在本地指定它们的并发策略。– rtUnit（real-time Unit，实时单元）构造型将实时单元建模为自治执行资源，能够同时处理不同的消息。实时单元可以管理并发性和附加到传入消息的实时约束。– rtService（实时服务）原型用于指定由实时单元和受保护的被动单元提供的服务并发策略（读取器、写入器或并行）。此外，我们还从NFP（非功能属性）导入 子配置文件两个原型：Nfp和NfpType。Nfp构造型描述了满足非功能需求的属性。NfpType构造型指定了一个包含属性值及其单位的复合类型。有一组预先声明的NFP_Types，可用于指定NFP值，例如NFP_Duration和NFP_Frequency。在图1中，我们通过RT传感器模式的设计来说明我们的UML-RTDP配置文件的使用，其中突出显示了强制性和可选元素。如图1所示，有三个基本类：传感器类、测量类和测量元素类。传感器分为无源或有源。有源传感器采用其电流值的传输主动性（推动机制）。而被动传感器仅在需要时传输其值（拉动机制）。根据设计师继续。Measure类对RT数据进行建模，RT数据分为基础数据和派生数据。基础数据从传感器发出，而衍生数据从基础数据计算。派生数据具有与基本数据相同的特征（时间戳、有效期、. . ）.基础RT数据和派生RT数据之间的关系由Measure类上定义的可选和相关关联表示。这个类是构造型的ppUnit，因为它表示一个被动资源，需要由主动资源（如控制器）设置和控制。它提供了一个名为updateValue的RT服务。此操作携带并发类型（writer）和expertation类型（remoteImmediate），指示立即使用调用的活动对象（Control）执行。此外，活动控制器资源创建动态可调度资源以处理需要在截止日期之前实现的2.2. 开发过程在文献中，许多研究人员感兴趣的是模式提取，而不是像我们这样的情况下模式的建设。他们的方法基于图表（例如，Tsantalis等人，2006;Liamwiset et al.，2013年），其他作品使用XML（例如，Satvinij和Vatanawood，2011年;Bouassida等人，2013 ），以及其他基于本体（例如，Alnusair和Zhao，2010年;Robles等人，2012年）。然而，它们与我们的上下文不同，因为它们与逆向工程上下文有关 。 (e.g. 、 Tsantalis 等 人 ， 2006; Liamwiset et al. ， 2013年）。此外，所有这些方法都是基于预期的设计模式的结构。也就是说，设计模式的UML类图是用于从分析的应用程序模型中提取模式的自动工具的输入。我们的贡献在于确定特定于特定领域的设计模式另一方面，我们注意到，可重用元素的现有开发过程（例如，框架，模式）可以分为自下而上或自上而下。下而上328S. Rekhis等人图1RT传感器模式。过程从一组代表域的应用程序开始，并识别它们的公共和可变元素。检查示例应用程序的目的是创建一个可理解且易于重用的通用可重用组件。当一个领域已经被很好地理解时，自底向上的设计过程工作得很好，例如，在一些初始的进化周期之后（Ben-Abdallah等人，2004年）。然而，不能保证满足所有的域需求.此外，这个过程被认为是高度迭代的，因此在大型或复杂的应用程序设计的情况下，它变得效率低下。自顶向下的过程从域分析开始，然后构造可重用元素。因此，设计是从功能需求开始向解决方案替代方案驱动的。自顶向下的开发过程代表了当领域尚未被充分探索时的最佳解决方案（Ben-Abdallah等人，2004年）。然而，这种类型的过程是耗时的，它缺乏领域需求分析的指导方针。 作为一个例子，Raminhoset al.（2006）和Caillas et al.（2004）描述了开发人员必须遵循的步骤，以便通过域需求分析构建模式。然而，所提出的过程不提供有效的帮助模式的发展。 此外，它们不指导开发人员找到模式的基本元素和可变元素。最后，我们认为有必要定义一个融合自下而上和自上而下的过程的过程。为了创建设计模式，模式开发过程必须指导设计人员捕获领域需求，并确定属于特定领域的应用程序模型的公共属性2.3. 模式实例化和验证工作概述有几项工作对为模式实例化和验证提供帮助感兴趣Kim和Carrington，2006年; Kajsa，2013年）。 它们定义了模式实例化的必要步骤，然后检查结果应用程序的有效性。通过使用正式规范或通过模型转换完成可重用组件的验证最近，Kajsa（2013）提出了一个设计模式实例化的过程。该过程包括定义（i）UML概要文件和（ii）基于语义的模型转换这个概要提出了新的原型来描述设计模式的参与者和他们在特定应用程序模型中的关系模型转换支持并自动将设计模式部署到特定的应用程序模型中。这种方法需要为每个设计模式定义适当的原型。因此，开发人员必须知道与每个应用的设计模式相关的不同原型，并且还必须理解每个原型元属性的语义标记值）。Kim 和 Carrington （ 2006 ） 提 出 了 一 种 基 于 Object-Z（Graeme，2000）的形式化方法，该方法允许定义和重用设计模式。他们形式化了角色Meta模型，该模型构成了用于定义设计模式和一致性约束的建模语言。Object-Z中定义的角色Meta模型自动转换为Ecore模型，然后使用Eclipse建模框架（EMF）实现（Steinberg et al.，2008年）。这些作者还使用Object-Z来形式化绑定Meta，构建和重用特定领域的设计模式329hi2将模式实体映射到应用程序模型实体的模型，并定义必须保留的约束，以使模式部署有效。3. RT设计模式我们的流程通常指导特定于领域的模式的开发，并且特别适用于具有密集数据的RT领域的RT设计模式。它采用自上而下的方法，一方面允许识别域需求，另一方面采用自下而上的方法，使用统一规则从给定的应用程序集生成模式。生成的模式用UML-RTDP profile表示设计模式开发过程被分解为五个主要阶段，如图2所示。通过RT控制器模式的建模说明了这一点。该图示见附录A。3.1. 域功能的识别第一步的目标是划定域边界，它包括识别最重要的域子问题。每个子问题都有一个主要的功能目标，称为域功能。通过收集专家和利益相关者提供的信息，识别与该领域相关的最重要功能。在这一步中识别的功能帮助开发人员确定每个创建的模式的上下文在数据密集的RT域中，所有应用程序都有一个共同的行为：它们通过传感器报告的值来监视和控制环境。通过检查这些应用，我们区分了三个主要的域功能：（i）通过传感器从环境中获取RT数据，（ii）RT数据分析和在时间约束内产生结果，以及（iii）通过致动器向环境发送命令。对于每个功能，我们定义了一个可重用的设计模式，捕获RT领域知识和设计经验。在本文中，我们只关注通过定义RT控制器模式对数据控制功能进行建模。3.2. 查明需求这一步包括细化域功能。每个识别的功能被迭代地分解为函数，直到达到函数成为初等的水平。这一步确定了所有与每个功能相关的领域概念和约束。该步骤中的功能域需求表示为一对F、Ef，其中F是域功能，Ef是基本功能。a. RT数据采集功能被分解为四个基本功能：Ef1{传感器（例如，雷达摄像头. 观察环境中的物理元素，例如，飞机、车辆、病人等}。Ef2{传感器获取测量值（例如，速度，温度，压力，脉搏，. ）}.Ef 3{主动传感器周期性地将所获取的测量传输到计算单元，以便存储在RT数据库中（推送机制）}。Ef4{周期性地请求无源传感器将所获取的测量值发送到计算 单元， 以便存储在RT 数据库 中（拉 取机制）}。注意，Ef3和Ef4是RT数据传输的两个可能的替代方案。此外，一组域概念，如传感器，主动传感器，被动传感器，测量和观察元素，在细化步骤中被识别。主动传感器和被动传感器是领域概念，它们代表了传感器这一一般概念这些概念将在下一个步骤中使用，即分解。b. RT数据控制功能被分解为五个基本功能：Ef1{一个控制器监视每个被观察元素的状态}。Ef2{控制器计算导出值（即，导出数据）从捕获值（即，基本数据）}。Ef3{一个控制器检查一个动作是否错过了最后期限}。Ef4{一个控制器监控被观察元素的捕获值，以检查测量值是否Ef5{控制器在检测到异常情况时启动纠正措施}。Ef6{控制员通知监视操作员任何检测到的异常情况}。注意，Ef2、Ef3、Ef4、Ef5和Ef6是描述RT数据控制功能性的可能场景的可选功能。数据控制功能的细化允许识别域概念，例如控制器、观察元素等。3.3. 应用程序的分解这一步是根据已经确定的领域概念分解不同的应用程序。它旨在根据以下两个分解规则（DRI）确定应用程序类与不同功能相关的领域概念之间的关系。第一条规则将与域概念相关的类添加到不同的应用程序片段中。第二个规则将其他类（即，与领域概念无关DR1。对于每个类C2 {CAi}，如果类名称与域概念CD2{CDj}相同或同义，则类C被转移到片段Fi j，其中{CAi}是属于应用程序i的类的集合。{CDj}是相对于函数性j的域概念的集合。Fij是应用i相对于功能j的片段。如果应用程序类C不是任何领域概念的同义词，则模式设计者必须验证C是否扮演领域概念CD {CDj}的角色（例如，COMPASS系统的RoadSegment类扮演ObservedElement330S. Rekhis等人22图2模式开发过程。域概念）。在这种情况下，类C被添加到片段Fij。DR2。 对于每对类（C，C 0）{C A i}，如果CF ij，C 0R F ij（即，C0与任何领域概念无关），是C和C0之间的关联，则类C0被转移到片段Fij。分解阶段生成域字典的初始版本，其中包含与RT域概念同义或等价它包含也就是被设计者识别为扮演域概念角色3.4. 应用程序设计统一规则允许统一不同的应用程序片段，然后生成RT设计模式。统一在于找到所有应用程序的公共类并导出模式的基本然后，特定于应用程序的类，构建和重用特定领域的设计模式331元素被提取为可变元素。统一规则基于语义比较标准。后者依赖于语言关系来定义类、属性和操作名称之间的语义等价和变化。语言/语义关系的确定是通过词汇数据库WordNet或我们创建的领域词典来处理的（参见。图3）。设计师被要求验证模型元素的名称（即，类、属性、操作等）根据WordNet词典，对于这些词没有语言关系，它们可以是RT域中的同义词、反义词或下位词类图的统一规则已经在以前的工作中以初始形式定义（Rekhis等人，2010年）。在本节中，我们改进了它们，并提出了与序列图统一相关的新在统一应用程序片段之前，需要对类名、属性名和操作名进行预处理。例如，如果属性的名称 由几个用短划线分隔的单词组成，或包含首字母大写的单词，我们建议将每个单词分开处理。这允许检查组成属性名称的单词与其他属性名称的单词之间是否存在语言关系。例如，分别属于Vehicle和Segment类的属性名VehicleStatus和SegmentStatus的分解允许识别两个相同的单词（Status）。因此，这两个属性被视为两个因为单词Vehicle和Segment与包含这些属性的类名相关，所以它们是3.4.1. 类图片段类名、属性名和操作名的比较标准使用一组语言关系。类名比较条件由以下三个关系组成：N_equiv（CA 1），. . ，CAnj）意味着类的名称或者相同或者同义。● 注意，应用Ai的片段j中的类C由CAij表示，其中片段j是相对于功能j的应用模型的一部分。N_var（CA 1 j，. ，CAnj）意味着类的名称是概念的变体，例如，移动传感器被动传感器主动传感器N_dist（CA 1），. . ，CAnj）意味着上述关系都不成立。属性比较条件使用以下三种关系来比较属性名称和类型：Att_equiv（CA 1 j，. ，CAnj）意味着类具有相同类型的相同或同义属性名。图3域字典创建。●●●●332S. Rekhis等人hhiihhii● Att_int（CA 1 j，. ，CA nj）意味着类CA 1j，... 、CAnj具有共同的属性。Att_dist（CA 1 j，. ，CAnj）意味着上述关系都不成立。操作比较准则使用三个关系（Op_equiv（CA 1），. ，CAnj ） 、 Op_int （ CA1j ， . ， CA_nj ） 和 Op_dist（CA_1j，.. . ，CAnj））来比较操作名称和签名（参数类型和返回类型）。这些关系以与属性比较关系类似的方式定义。为了便于理解统一规则，我们在下面定义了一些新概念：如果模型元素（类、属性、方法或消息）出现在超过50%的应用程序中，则它与RT域相关。为此，我们定义域覆盖率（Rdc），计算如下：RdcE模型元素E在应用程序申请数量请注意，如果模型元素E的域覆盖率小于1，则该元素与RT域无关，并且它过于特定于应用。因此，如果将其添加到图案中，则可能不必要地使图案分解复杂化。任意阈值（50%）可以由模式开发人员根据需要进行更改。请注意，这个阈值将在未来的工作中确定，这要归功于可以帮助找到理想阈值的一个模型元素（类或对象）扮演一个领域概念的角色，如果在分解阶段，它已经被设计者识别为扮演一个领域概念的角色（观察元素，传感器等）。并且它已经被存储在域字典中。模式类图的设计由统一规则（URI）指导：UR1.如果一组类{CA 1 j，. ，CAnj}存在于具有等同属性的所有应用中，即，Att_equiv（CA 1 j，.. . ，CAnj）和方法，即，Op_equiv（CA 1 j，.. . ，CA nj），则类被添加到模式中作为基本类原型化hhmandatoryii。UR2。如果一组类{CA 1 j，. ，CAn}共享等同的属性和/或方法，即，Att_int（CA 1 j，.. . ，CA n j）和/或Op_int（CA 1 j，. ，CAnj），则存在三种情况：情况1：如果N_equiv（CA 1，. ，CAnj），则将基本类添加到具有公共属性和方法的模式中。不同的属性和/或方法作为可选元素被添加，如果它们对域是特定的。情况2：如果N_var（CA 1，. . ，CAnj），那么一个具有公共属性和方法的类作为基本类被添加到模式中，有两种可能的情况：1. 如果存在来自类（CA 1，j，. . ，CA nj），其起到与域概念相同的作用（例如，有源传感器、无源传感器），并构成一种变化一般域概念（例如，传感器），则添 加 从基本类继承并包含相关属性和/或方法的一组子类。 4共享共同的属性和方法，它们的名称表示概念的变体。CameraSensor和BoundaryStickSensor扮演领域概念被 动 传 感 器 的 角 色 ， 而 ActimetrySensor 和InductionLoopSensor扮演领域概念主动传感器的角色。由于主动传感器和被动传感器代表领域概念传感器的变体，因此添加了从名为传感器的超类继承的两个子类。2. 如果不存在来自类（CA 1-j，. ，CA n j），则存在于类 （ CA1j ， . 例 如 ， 图 5 中 所 示 的 类WaterController、PatientController和PatientController共享共同的方法，并且它们的名称表 示 一 个 概 念 即 Controller 的 变 体 。 然 后 将 类Controller添加到模式中，并将notify（）方法作为可选元素。情况3：如果N_dist（CA 1），. . ，CAn j）和类（CA1j，-.. . ，CA nj）扮演相同领域概念的角色，则将具有公共属性和方法的基本类添加到模式中，并且它将采用领域概念的名称。在这种情况下，还应用在该规则的情况2中解释的两种可能的替代方案。例如，类RoadSegment、Vehicle和Patient扮演与ObservedElement相同的角色。这些类共享公共属性和方法。因此，一个名为ObservedElement的类被添加到模式中。注意：对于规则UR 2的所有情况，如果存在与所考虑的域不相关的不同属性和/或方法，则将基本类添加到具有公共属性和/或方法的模式中，并将其定型 可扩展的，以表明当模式被重用时，类可以被扩展。UR3。如果有一组类对所有应用程序都不通用，它们共享等效的属性和/或方法，并且它们与RT域相关，则将一个可选类添加到具有公共属性和方法的模式中。UR4。如果一个方法存在于所有的应用程序中，但具有相同的名称，但具有不同的签名，那么它将具有一个对应的方法在模式中有一个未定义的签名，它是一个原型变量。UR5。如果所有应用程序中都存在同名但类型不同的属性，则有两种情况：情况1：如果这些类型兼容（实数、整数等），则它将在模式中具有最通用类型的对应属性。情况2：如果这些类型不兼容，则它将在模式中具有对应的属性，●●●构建和重用特定领域的设计模式333图4表示具有继承关系的概念变体的类示例。相同的名称和枚举类型，其中包括不同类型的冲突属性。UR6。如果两个或多个类在模式中被转移，那么它们的所有关系（聚合、继承、关联）都将在模式中被维护3.4.2. 序列图统一规则用于识别不同序列图之间的公共元素以及相对于相同域功能的可变元素。序列图的统一基于对象和消息名称的语言比较标准。对象的一致性标准与类的一致性标准相似。它们基于以下三种关系：● N_equiv（0A 1，. ，OA nj）意味着相对于对象（OA1j，. . ，OAnj）是相同的或同义的。● 注意，应用程序Ai的序列图j中的对象O由OAij表示，其中序列图j与功能j相关。图5表示概念变体的类示例334S. Rekhis等人●hhiihhiihhii● N_var（0A 1 j，. ，OA n j）意味着相对于对象（OA 1j，. .，0Anj）是概念的变体。N_dist（0 A1 j，. . ，OAnj）意味着上述关系都不成立。邮件比较条件使用以下两种关系：N_equiv（MA 1 j，. ，MAnj）意味着消息具有相同或同义的名称。N_dist（MA 1 j，. . ，MAnj）意味着消息具有不同的名称。RT设计模式序列图的设计遵循以下统一规则：UR7。如果存在一组对象{OA 1，j，. . ... ，OA nj），则对象被添加到模式序列图作为基本元素，并且它必须是定型的。UR8。如果存在一组对象{OA 1，j，. . .，OAn}实例化扮演域概念的相同角色的不同类，然后添加对象作为定型强制性的基本元素，其类型对应于域概念。UR9。如果存在一组对象{OA 1，j，. ，OAnj}，其类型是一般概念N_Var（OA1， j，.... ，OAnj），则存在两种情况：情况1：如果这些对象是模式类图中的类C的实例，则添加一个对象作为基本元素（原型化强制性），其类型对应于类C。案例二：如果这些对象是从一个通用类继承的几个子类的实例，并且每个子类在模式类图中都有自己的操作，那么对应于这些专用类的对象就作为原型化的可选项添加到模式序列图中。UR10。如果有一组对象不是所有应用程序都通用的，它们有等价的类型，并且它们与RT域相关，那么将对象作为可选元素原型hhoptionalii添加到模式中。UR11。如果存在消息集合{MA 1，j，. .. .，MAnj），其中发送方对象和接收方对象已经在模式序列图中传输，则存在两种情况：情况1：如果这些消息对所有应用程序都是通用的，则将基本消息添加到模式序列图中。案例二：如果这些消息不是所有应用程序所共有的，但它们与RT域相关，则将可选的代表性消息添加到模式中。此消息属于具有opt操作符的可选组合片段。UR12。如果存在消息集合{MA 1，j，. .. ，OA nj）到其它 对 象 （ OA01j ， .. ， OA0nj ）等的N_Var（OA1， . . ，OAnj ）或N_Var （OA01j ， . . . ，OA0nj），则两种情况是可能的：情况1：如果根据规则UR9传送发送对象（相应地接收对象）（情况1），则如果一个消息对于所有应用程序是公共的，则将其作为基本消息添加到模式。否则，如果此消息不是所有应用程序通用的，但它与RT域相关，则将其添加到模式序列图中的可选组合片段中。案例二：如果发送对象（相应地接收对象）根据规则UR9被传送（情况2），则相关的消息被添加到具有备选操作符alt的组合片段中的模式。3.5. 模式验证模式开发过程的最后一步是检查生成的模式是否满足了所有的需求和约束，以验证它们。该确认分两步进行。首先，将获得的RT模式实例化，并与原始应用程序片段进行比较。其次，通过检查所获得的模式是否满足不同领域功能的所有需求和约束来在RT域中，模式验证阶段非常重要，因为它定义了用OCL表示的附加约束和依赖关系。它还允许添加原型来建模RT特性以及支持服务质量（QoS）约束的属性。在本文中，我们定义了以下五个验证规则（VRi），以指导RT模式开发人员在添加RT原型时：VR1。每个提供非功能需求信息的属性（例如，吞吐量、延迟或调度策略）必须被定型。VR2。每个RT方法的执行必须在截止日期之前完成，因此必须在hrtagurer ii中构造原型。VR3。每个包含共享RT数据的被动类都必须构造型 为hhppUnitii。VR4每个活动类都有自己的执行资源，并同时处理各种消息，必须将其定型为hhrtUnitii。VR5 每个属于类原型化hhppUnitii或hhrtUnitii并且具有要满足的定时约束的方法都需要原型化hhrtServiceii。4. RT设计模式在本节中，我们将介绍RT设计模式的实例化过程及其基于模型转换的相关工具。这个过程将我们的开发过程生成的RT设计模式作为输入，并生成一个实例化RT模式的应用程序的类图，如图6所示。实例化过程包括两个步骤：映射步骤和转换步骤。第一步定义映射模型，将设计模式元素链接到应用程序元素，然后根据模式模型验证应用程序模型变形金刚-●●构建和重用特定领域的设计模式335hhiihhiihhiihhii执行步骤自动生成部署实例化模式的应用程序模型。因此，本提案的主要目标是使用模型转换工程技术，通过实例化RT设计模式，同时尊重约束，创建特定的应用程序模型 隐式 由强制性和可扩展的原型定义。由RT立体类型（如rtFeature和rtUnit）定义的RT约束自动传输到实例化RT模式的RT应用程序模型。这些约束的验证只能在运行时进行。例如，只有在运行RT系统时，我们才能验证不会错过4.1. 映射步骤4.1.1. 映射步骤描述所需设计模式的实例化始于交互式映射步骤，该步骤允许应用程序设计人员实例化模式的强制类及其属性和操作。然后，应用程序设计人员必须选择适当的可选元素。此外，设计者可以重命名映射的模式元素，也可以添加新的应用程序特定的元素，如属性，操作，类等。这一步的结果是一个映射模型，它将模式的元素与应用程序相匹配。图6模式实例化过程。336S. Rekhis等人hhiihhiihhiihhii hhii hhii阳离子模型元素当关联的模式元素被映射时，关系元素被自动传输。在 图 6 所 示 的 映 射 模 型 示 例 中 ， RT 控 制 器 模 式 的ObservedElement 类 在 应 用 程 序 模 型 中 映 射 了 两 次（RoadSegment和Vehicle类）。此示例还显示了两个新属性（StartPointLocation和EndPointLocation）的添加。4.1.2. 映射步骤映射模型使用Acceleo和EMF（Steinberg等人，2008年）。我们使用Acceleo生成器，以转换每个RT设计模式表示的UML 到 一 个 Ecore 模 型 。 这 种 转 换 是 通 过 Acceleo 模 板"www.example.com“的定义来执行UMLtoEcore.mt。生成的Ecore模型将是EMF框架的输入模型，它允许自动生成编辑器来实例化所需的设计模式。生成的编辑器显示了与所选模式模型对应的所有类的列表。然后，它会显示与每个选定模式类相关的属性和操作。因此，要创建所需模式的实例，应用程序设计者从列表中选择适当的元素并填充它们的属性（如名称和类型）在属性窗口中。请注意，我们没有选择使用EMF提供的从UML模型自动生成Ecore模型的方法，原因有二：– EMF提供的生成的Ecore模型不允许添加应用程序特定的元素（即，新属性、新操作、新类），它们不实例化模式元素。因此，它可以防止应用程序设计人员向一个可扩展的类中添加新的属性或方法。– UML的关联概念在Ecore元模型中被不同地对待（Kim和Carrington，2006）。在UML中，关联是一个独立的概念，而在Ecore中，它是用引用和对立面来表示的。因此，使用EMF从模式类图创建Ecore模型不允许生成一个编辑器，该编辑器列出了模式模型中定义的所有类，特别是那些与UML关联而不是与UML组合关系相关联的类。4.1.3. 验证映射模型使用EMF验证框架检查模式实例化的有效性该框架一方面验证了所有强制模式元素（例如类、属性和操作）是否都映射到应用程序模型元素。此外，它还验证了每个映射的模式类（不是原型化的可扩展的）没有应用程序设计者添加的新属性或新操作另一方面，它验证映射模型中的每个元素是否都有名称，每个属性是否都有类型。结果，检查映射模型的验证，并且如果违反了任何约束，则利用在Problems选项卡中