实时设计模式对操作重要数据量的系统的管理至关重要

沙特国王大学学报用于表示实时设计模式Hela Marouanea，b， Claude Duvalleta，Achraf Maknib，Rafik Bouazizb，Bruno Sadega法国勒阿弗尔大学LITIS实验室b突尼斯斯法克斯大学MIRACL实验室阿提奇莱因福奥文章历史记录：2016年11月15日收到2017年6月20日修订2017年6月25日接受2017年6月29日在线发布保留字：UML profile设计模式对象约束语言实时数据库A B S T R A C T操作重要数据量的系统需要用实时（RT）数据库进行管理。这些系统受到与数据和事务有关的若干时间约束。因此，它们的设计仍然是一项复杂的任务。为了弥补这种复杂性，有必要集成设计方法来支持数据和事务的时间约束。在这些设计方法中，基于模式的设计方法在许多领域得到了广泛的应用。然而，尽管这些模式有其优点，但也存在一些缺点。实际上，它们不能有效地管理模式可变性，不要在实例化模式元素时指定它们。为了克服这些局限性，我们提出，在本文中，一个新的UML轮廓（i）表达模式的可变性和（ii）确定其实例中的模式元素此外，为了更好地捕捉领域的知识，建议的轮廓扩展UML与实时数据库相关的概念，并集成OCL（对象约束语言），以加强变化点的一致性。最后，我们给出了一个RT模式的例子，说明这些UML扩展，我们实现了建议的配置文件，我们验证模式图使用我们提出的约束。©2017作者。制作和主办：Elsevier B.V.代表沙特国王大学这是一CC BY-NC-ND许可下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。1. 介绍近来，许多实时（RT）系统（例如，驾驶员辅助系统和控制交通系统）需要存储大量数据，并处理它们，以便有效地运作。因此，应使用RT数据库。该数据库必须不仅具有传统数据库的相同特征（例如，结构化数据访问的有效管理），但也需要数据和事务时间约束的有效管理（Ramamritham，1993）。传统数据库的设计方法不能直接应用于RT数据库应用程序的建模，因为没有处理时间约束表示的机制。此外，RT数据库应用程序变得更加复杂，导致了广泛的概念性描述，并从实用的角度来看，*通讯作者：突尼斯斯法克斯大学MIRACL实验室电子邮件地址：marouane. gmail.com（H.Marouane），claude.univ-lehavre.fr（C.Duvallet ） ， Achraf. fsegs.rnu.tn （ A.Makni ） ， Raf.fsegs.rnu.tn （ R. Bouaziz ） ，bruno.sadeg@ univ-lehavre.fr（B. Sadeg）。沙特国王大学负责同行审查风景因此，这些应用程序的设计是一个艰难的过程，需要开发新的设计方法来支持RT应用程序的数据结构和动态行为，基于RT数据库。为了成功地设计这样的应用，我们认为，一种强大的设计方法（例如，设计专利（Gamma等人，（1995年）可以提高开发过程的质量。设计模式是可重用的抽象设计元素，可以降低系统建模的难度这些模式提供了在软件设计中成功捕获和提升最佳实践的机制.然而，尽管设计模式有很多好处，设计人员可能会花费大量的时间来理解和实例化它们。因此，许多研究人员提出了几种符号，以促进规范的专利和文件的实例。这些符号有助于理解复杂的概念。在文献中存在不同的符号来记录模式。例如，我们可以提到自然语言，它不精确，太模糊，以及视觉语言（例如，统一建模语言（UML））。UML语言是一种标准的面向对象的通用软件建模语言。它是通过提供其概念的精 确 语 义 来 可 视 化 、 指 定 和 累 积 系 统 的 工 件 的 常 用 语 言（Rumbaugh等人， 1999年）。它提供了一组图形符号来捕获所开发系统的不同方面http://dx.doi.org/10.1016/j.jksuci.2017.06.0051319-1578/©2017作者。制作和主办：Elsevier B.V.代表沙特国王大学这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。制作和主办：Elsevier可在ScienceDirect上获得目录列表沙特国王大学学报杂志首页：www.sciencedirect.comH. Marouane等人/Journal of King Saud University479●在这些好处中，这些符号（如图表和图标）带来的是（i）加强设计师之间的沟通（促进开发过程中所有参与者之间的沟通），（ii）使概念和模型的理解更容易事实上，学习画插图的方法比学习写课文容易，因为画插图比写课文更有意义，更具体最后，这些符号可以帮助人们比书面文本更快地掌握大量信息。尽管有其优点，图形符号也有一些缺点。事实上，它们缺乏清晰度和表达力。此外，它们有时是不精确和模糊的，因为它们没有为不同的UML概念提供定义良好的语义。例如，UML参数化协作太有限（它们没有精确地解释如何指定模式及其用法（Sunyé et al.，2000年））。此外，在实例化级别中，图形化标记不能准确地标识模式元素及其在模式中的角色。此外，符号的表达能力不足以对特定领域进行建模。事实上，在一个特定的领域设计中，UML应该考虑到领域的特殊性。例如，如果我们考虑RT数据库应用程序，我们发现这些应用程序是复杂的，它们有几个细节应该由UML符号来考虑它们必须指定RT数据库特性，比如时间约束的数据和事务。为了克服图形符号的缺点，UML定义了一个新的包，名为Profile，以扩展其语法和语义。这个概要文件提供了三种具有特定名称的扩展机制，以便用定量信息注释UML图：stereotype-name：一个原型，它允许定义UML词汇表的扩展可以将标记值和约束关联到原型。一个标记值：这是一个与建模元素相关联的属性，以便用某种细节来扩展其属性。约束：这是添加到模型元素的语义限制。通常，约束是用OCL编写的（OMG，2003）。概要文件的定义非常重要，因为它允许向UML概念添加语义和约束（例如，类、属性和生命线）。此外，它通过给出与特定领域相关的特定符号来为特定领域提供新的词汇表。因此，在本文中，我们定义了一个新的概要文件，它代表了UML 2.1.2的一个特殊化变体这个概要文件提供了UML扩展来支持RT数据库需求。此外，它的目的是扩展UML的概念，按照设计模式表示。制定这一概况有三个动机：1. 它代表了RT数据库应用程序的概念。RT数据库有两个主要特征：（i）数据时间一致性和（ii）事务RT约束的概念（Ramamritham和Pu，1995）。它的一些数据不仅必须是逻辑上一致的，而且还必须是时间上一致的，即，一个数据必须在其有效性间隔期间使用，并且两个相关的数据必须在它们的相对有效性间隔（某个时间窗口）内使用。RT数据被分类为：（i）从传感器收集的传感器数据，以及（ii）使用传感器数据计算的导出数据（Amirijoo等人，2006年）。RT数据通过更新事务进行更新，更新事务可以定期执行（以更新传感器数据）或偶尔执行（以更新导出数据）。因此，我们可以推断RT数据库有其自身的特殊性.因此，他们的设计需要有适当的概念，以考虑因素，如传感器数据，派生数据，数据管理的质量，TEM，事务和并发控制机制的局部语义，以便满足RT应用的定时约束（Idoudi等人，2008年）。出于这个原因，在我们的工作中，我们定义UML扩展来考虑所有这些概念。2. 它表示规范级别的模式。在这个层面上，我们的配置文件是有益的，因为：（i）它提供了灵活的模式，允许区分基本元素和可变元素，（ii）它有助于理解模式实例化。它在实例化级别表示模式。在这个层次上，我们的概要文件有两个优点：（i）它确保了模式元素的可追溯性，因为它清楚地标识了属于每个模式的元素，以及（ii）它通过标识每个模式元素所扮演的角色来避免组成模式时的歧义。此外，建议的概要文件包括OCL约束，以确保设计模式图的一致性和正确性，即，该图尊重设计者指定的所有约束。在本文中，我们专注于图内一致性（对于给定的UML图，我们检查其元素之间的一致性）。为此，我们提出了OCL约束以处理每个模式图中变量元素的相关性。此外，我们评估建议的配置文件的基础上，一些标准，我们将其与其他现有的配置文件。此外，我们认为，我们通过Marouane等人（2012）定义的RT设计模式来说明我们的配置文件。我们还实现了建议的配置文件使用MagicDraw UML工具，我们将其纳入到设计模式图及其实例。之后，我们验证这些图的元素是否符合OCL约束。本文的其余部分组织如下。第2节概述了最近提出的UML概要文件。第3节描述了我们的UML概要文件。本节还定义了一组用OCL编写的格式良好的规则，以验证模式的一致性和正确性。第4节描述了案例研究方法，展示了我们如何组织和开展研究。第5节使用Marouane等人（2012）中定义的RT感知模式说明了曲线。它还给出了两个例子实例化模式的系统模型。第6节描述了建议概要的实现和模式的UML图上的OCL规则的验证。在第7节中，我们给出了一些结论性意见，并概述了未来的工作。2. 相关工作2.1. 用于模式表示的在文献中已经提出了几个UML概要来表示设计模式。它们可以分为三类。第一个揭示了规范级别的设计模式（例如， Arnaud et al.（2008））。 第二类提出了在实例化级别显示模式的扩展（例如，Dong et al. （2007）和Loo et al.（2012））。 在第三类中，提出扩展以在两个先前提到的级别（例如， Reinhartz-Berger和Sturm（2009年）以及Rekhis等人提出的配置文件。（2010））。这些UML概要文件是根据模式规范（表1）和模式实例化（表2）的一组标准进行评估的使用的标准是Rekhis等人（2010）定义的标准（可变性，一致性，表达性，组合和可追溯性），以及模式解决方案的完整性。●●480H. Marouane等人/Journal of King Saud University表1在规范级别表示模式的标准图是有限的。实际上，用例图太抽象了，不允许设计者识别，例如，可选图案规格的标准意义属性或方法。因此，所提出的UML概要文件部分地满足了可变性模型中的可变性是UML的表示不同系统的元素可能不同。事实上，可变性被分为可选和替代特征。因此，有必要根据上下文显示模式实例中可以省略的一致性使用扩展引入可变性可以产生一些不一致（例如，如果基本参与者与可选用例相关联，则所得到的模型是不连贯的）。然后，需要指定一些规则这些规则通常用OCL表示。因此，正确的模式实例化取决于是否遵守可变性一致性所固有的定义规则表达性为了更灵活和更容易理解模式，有必要定义基于UML的表达可视化符号。为了提高设计语言的表达能力，区分用于模式规范的符号和用于模式实例化的符号也很重要。完备性一个模式解决方案是完备的，如果解决方案包含功能、结构和行为视图。需要注意的是，模式的完整性是理解模式使用上下文的关键因素。此外，完整性标准保证所有需要的信息都存在。因此，我们建议将模式解决方案表示为一个由功能视图（UML用例图）、结构视图（UML类图）和行为视图（UML序列图）组成的小型系统。因此，有必要为每个图定义UML扩展。表2实例化级别的模式表示标准。模式的标准可追溯性这一标准包括容易地识别模式的模型实例化中的模式元素。关键模式元素的显式表示可以帮助模式的可追溯性，因为它允许从复杂模型追溯模式（Bouassida等人， 2006年）。一个图案可以与其他图案组合或集成在一起。模式来解决软件设计中的设计问题。因此，如果不同的模式组合在一个模型中，UML扩展必须清楚地区分属于每个设计模式的元素当组合模式之间存在重叠元素时，这一点2.1.1. 用于模式规范的UML概要文件Arnaud在Arnaud et al.（2008）UML extensions中定义，用于在功能、静态和动态视图中明确表示模式变化点。事实上，作者提出了扩展来表达用例图和序列图中的变化点和变体。此外，他引入了用例图的扩展来表示基本和可选用例。作者还用UML扩展扩展了类图，以表明此图与用例相关联。用例图表示实例化过程的输入图，设计者在此过程中根据建议的扩展选择功能变体。因此，我们认为，这些扩展非常有用，但它们在用例中的应用可变性标准。此外，它不包括可追溯性和组成标准。事实上，建议的扩展不允许在使用模式实例化建模的设计图中可视化模式元素。此外，作者还提出用引用功能变体的基本分离包来表示模式静态视图。因此，轮廓不是完全表达的。2.1.2. 用于模式实例化的UML概要文件Dong et al.（2007）介绍的概要集中在pat实例化级别。作者建议扩展UML类图，以允许设计人员在使用模式实例化创建的设计模型中可视化模式元素。这个概要文件包括原型PatternClass、PatternAttribute和PatternOperation，它们分别标识属于模式的每个实例的类、属性和操作。每个原型都有一个相关的标记值，用来显示模式名称和每个元素（类、属性和操作）的角色名称。因此，所提出的概要文件满足静态视图中的可追溯性和组合准则。然而，它既不涉及非语言观点，也不涉及功能观点。另外，这个侧写以满足图案规范所需的标准与Dong等人提出的轮廓不同，Loo等人引入了UML序列图的扩展，以可视化设计模式的模式角色和不同类型的交互组（Loo等人，2012年）。事实上，作者定义了以下刻板印象：（一）模式角色用于确定 消 息 的 模 式 角 色 和 从 模 式 实 例 化 的 生 命 线 ， （ ii ）PatternInteractionFragment，指定模式角色存在于特定模式中，（iii）PatternDisengage，指示从设计模式中移除模式角色，以及（iv）PatternEngage用于指定添加新的模式角色一个特定的设计模式。然而，定义的配置文件没有提出扩展的模式规范，这降低了扩展的表达能力。此外，该配置文件使用交互操作符（例如，使用操作符alt）。但是，它并不明确表示可变元素（即，消息和生命线）。此外，此配置文件没有提出扩展来识别静态视图中的变化点2.1.3. 用于规范和实例化模式的Reinhartz-Berger等人定义了一种基于DOmain建模方法（ADOM-UML）的应用程序，该方法提供了新的扩展来表示模型元素可以在特定上下文中出现多少次（Reinhartz-Berger和Sturm，2009）。事实上，作者提出了四个扩展，命名为可选的单一，可选多个、强制单个和强制多个。 每个扩展都有最小和最大标记值，分别定义最小和最大的多重性边界。这些扩展允许表达领域特定设计模式中的可变性.他们扩展了UML用例图（功能视图）、UML类图（静态视图）和UML序列图（行为视图），以区分模式中的基本元素和可选元素。此外，定义的概要文件提出了扩展，以显式地可视化特定设计模型中的模式元素。事实上，对于设计模式中定义的每个模型角色，都会创建一个扮演这个角色的设计模型元素拥有这个构造型。因此，该概要文件提高了设计模型的可读性，但它H. Marouane等人/Journal of King Saud University481在实例化时不保留模式名称的踪迹。这个概要文件需要为每个已定义的模型角色创建新的原型，这使得原型的数量无限，从而无法控制。此外，这种刻板印象是模糊和混乱的，特别是当模型角色有相同的名字。事实上，ADOM-UML方法无法满足组合标准，因为它在实例化时没有跟踪模式名称。每个模式图通常包含不同的参与者，例如类、属性和方法。这些参与者扮演着由他们的名字具体化的某些角色。当设计模式被实例化时，其参与者的角色名称可以被调整以反映应用程序域。因此，由角色名称表示的模式相关信息丢失，这使得难以确定在哪些模式中建模元素（例如，类、属性和方法）参与应用程序设计。在这种情况下，设计人员无法在应用程序设计中跟踪此信息。为 了填 补 这些 空 白，Rekhis 等 人提 出 了一 个 名为 UML-RTDP（UML-RT设计模式）的概要文件（Rekhis等人，2010），它使用了MARTE profile（OMG，2011）中引入的一些扩展来指定RT域方面。此外，UML-RTDP概要文件提出了一些扩展，这些扩展集中在RT设计模式规范和模式实例化上.事实上，该简档允许区分在模式的规范中使用的扩展和在模式实例化中使用的扩展，这允许确保表达性标准。在规范级别，这个概要文件引入了扩展来明确区分固定部分和可变部分，这表示模式的可变性事实上，该配置文件定义了以下扩展：（i）强制性的，用于表示基本元素（即，类、关联和生命线），（ii）可选，用于指定可选要素（即，类、关联、属性和方法），（iii）可扩展，用于指示类是否可通过添加新的属性和/或操作来扩展，以及（iv）变量，用于示出方法实现根据模式实例而变化然而，UML-RTDP概要文件在表示可变性标准方面有局限性首先，它提出了在静态视图（UML类图）和行为视图（UML序列图）中表达可变性的扩展，但它没有定义在功能视图中表达可变性的扩展其次，它没有为某些模式参与者提供扩展（例如，属性和消息）。事实上，它没有提供扩展（i）来显式地表示基本属性和操作，以及（ii）在序列图中区分可选消息和基本消息。这使得模式实例化成为一项困难的任务，因为设计者无法区分基本元素和可变元素。此外，UML-RTDP概要文件集成了一些OCL约束，确保了模式静态视图的一致性。然而，作者没有验证这些约束;他们没有使用OCL验证模式图的一致性此外，UML-RTDP概要文件没有包含检查其他视图（如行为视图）一致性的约束这可能会产生一些不一致，从而导致不正确的模式实例。出于这个原因，有必要定义约束，使验证的UML图组成的模式。在实例化级别，定义的概要文件提出了扩展，以显式地表达有关参与模式实例的设计模型元素所扮演的角色的信息。实际上，作者建议使用以下原型来扩展类和序列图：PatternClass、PatternInteraction和PatternLifeline。第一个用于指定类是从设计模式实例化的。另外两个构造型分别用于定义模式交互的角色和特定序列图中的生命线实例化了设计模式。每个原型都有两个相关的标记值，分别命名为PatternName（表示模式的名称）和PropantRole（表示元素在模式中扮演的角色）。因此，这些扩展满足可追溯性和组成标准。然而，该概要文件是有限的，因为它定义了仅允许指定在模式中起作用的类、生命线和交互的扩展，但是它没有指定用于表示对象的属性和行为特征（属性、操作和消息）的基本元素。这意味着难以（i）追踪这些图案元素，以及（ii）区分图案元素和添加的元素。Park等人开发了一种PICUP（Pattern Instance Changes withUML Profiles）设计方法，其中包含DPUP（Design pattern in UMLprofiles）（Park等人，2013年）。这种设计方法通过减少设计模式缺陷的数量，在软件系统的完善性和纠正性设计维护过程中，有助于保持基于UML模式的设计质量。作者使用从UML Meta模型（M2）扩展的UML概要文件来指定设计模式。该概要文件用于验证设计模式实例与设计模式的一致性。一致性检查可以通过UML类图和OCL约束来实现。作者区分了刻板印象和立体类型的实例。实际上，每一个原型都是在模式元素名称的上方或前面用原型关键字声明的。这些陈规定型观念不允许区分基本要素和可变要素。因此，UML概要文件没有表达模式中的可变性但是，构造型实例是用stereo类型关键字字符串表示的，字符串的上方或在模型元素名称的前面。定义了模式实例化的关联、属性和方法分别与以下原型：PatternAssociation、PatternProperty和PatternOperation。原型名称中的在实例化级别使用的构造型允许容易地确定模式元素。因此，UML概要文件可以充分表达可追溯性和可扩展性。位置标准。总之，上述研究的概要文件都不满足模式规范和实例化的所有标准。我们注意到同时满足模式规范和实例化标准的UML概要文件有一些局限性。例如，UML-RTDP概要文件在表达模式的可变性方面有局限性。此外，上面研究的概要文件没有处理RT设计模式，因为它们没有提供扩展来表示RT特征。UML-RTDP概要文件是唯一一个提供扩展来满足RT域需求的概要文件但是，这些扩展不是很有表现力，因为它们没有清楚地表达RT数据库需求（例如，两种RT属性：传感器属性和导出属性）。为了克服这些弱点，我们在本文中定义了一个UML概要文件(i)这是用于设计模式表示，以及（ii）考虑到已经提出的标准以及RT数据库应用程序的具体情况。此配置文件让我们获得可理解的，完整的，表达和一致的模式。2.2. RT UML概要文件一些研究定义UML扩展RT应用程序已被提出。例如，我们可以提到TURTLE （ Timed UMLand RT-LOTOS Environment ） profile（Apvrille et al.， 2004）和RT-UML profile（Douglass，2004）。RT-UML的基本概念通过UML概要文件集成到UML标准中，482H. Marouane等人/Journal of King Saud University●●●●可重复性、性能和时间（表示为SPT曲线）（OMG等人，2005年）。从UML 1.4扩展而来的SPT概要文件并没有指定完整的方法论。它在表达能力和灵活性方面有一些局限性。基于这个原因，这个概要文件被MARTE概要文件所取代，MARTE概要文件是一个UML OMG标准，用于RT嵌入式系统的建模和分析（OMG，2011）。这个概要扩展了UML2.0，以支持时间、硬件和软件资源以及非功能属性（NFP）等方面。然而，RT数据和RT事务的概念是RT数据库的基本特征，没有考虑在MARTE。因此，Idoudi et al. 引入了UML-RTDB（UML-Real-TimeDataBase）概要文件，以便仅在结构模型（类图）中考虑RT数据库需求（Idoudi等人，2008年）。该配置文件指定了RT类和两种RT属性：传感器和派生属性，以满足当前RT应用程序的要求。此外，此概要文件通过立体类型显式地表示RT操作的类型定期、零星和非周期. 然而，UML-RTDB并没有提到如何指定某些属性RT数据库，特别是非功能属性，尽管它们在提高软件开发质量的重要性。UML/MARTE概要文件被引入以在结构模型中表达RT数据库特征（Louati等人，2012年）。在Louati等人（2012）中，一些概念受到UML-RTDB和MARTE概要文件的启发。UML/MARTE概要文件支持所有RT数据库特性，即时间约束数据、时间约束事务、并发性、可扩展性、非功能属性等。但是，它不提供行为视图的扩展。而且，它没有提到如何指定某些约束的值（例如，零星事务的触发时间）。从前面的UML RT配置文件的描述，我们得出结论，应该引入一个新的配置文件来表示RT数据库的功能和非功能属性的结构和行为模型。然而，唯一的UML扩展，定义为代表RT数据库的特点，仍然不足以指定设计模式。事实上，它们必须是通用设计，旨在被实例化，以便对任何需要RT数据库环境的系统进行建模。出于这个原因，除了表示RT数据库特性的UML符号之外，我们还需要区分模式域中系统之间的共性和差异的符号。我们还需要扩展，以便在实例化模式的设计模型中显式表示模式元素角色。3. DP-RTDB配置文件在本节中，我们提出了DP-RTDB（设计模式实时数据库），一个模式的UML概要文件。它代表了UML 2.1.2的扩展。我们的配置文件不仅考虑了RT数据库方面，还考虑了与患者相关的可变性和方面。事实上，DP-RTDB配置文件提供了扩展，(i)表达模式中的可变性，（ii）指定每个模式元素在其实例中所扮演的角色，以及（iii）表示RT数据库需求以及非功能属性。为了定义我们的配置文件，我们从现有的配置文件中导入了一些扩展。我们还提出了新的扩展。每个立体类型及其标记值都使用注释在UML图上表示。3.1. 用于RT数据库特性本小节总结了支持RT数据库特性建模的UML扩展。一些刻板印象是受UML-RTDB简档的启发（Idoudi等人，（2008）用于UML类图。我们还在UML序列图上应用了这些构造型。此外，原型nfp是从MARTE配置文件导入的（OMG，2011）。此外，我们定义了一个新的原型，明确表示数据库系统存储RT数据和管理RT操作。我们在下面描述使用每个原型的目的感觉刻板印象我们使用这个构造型来扩展Class和Lifeline元类。它表示测量是传感器数据（从传感器发出的数据）。这种刻板印象的含义与传感器Idoudi中定义的刻板印象等人（2008），它只扩展了Property元类。衍生的刻板印象我们使用这个构造型来扩展Class和Lifeline元类。它指示测量是导出数据，即，使用传感器数据计算数据。这个原型与Idoudi et al.（2008）中定义的派生原型具有相同的含义，后者只扩展了Property元类。我们使用这两个原型来扩展类和生命线元类，因为传感器数据和派生数据表示由属性表征的对象：值，单位，时间戳和有效期。我们没有考虑与Idoudi等人介绍的传感器和派生定型相关的标记值。（2008），因为这些属性被表示为与存储在数据库中的每个RT数据相rtDatabase构造型。根据定义，RT数据库是具有若干组件的数据库系统，诸如事务、并发控制和存储管理（Stankovic等人，1999年）。因此，RT数据库的设计要考虑这些组件。 因此，我们定义了rtDatabase构造型，它扩展了元类Class和元类Lifeline。此构造型指定存储RT数据（传感器和派生数据）和管理RT操作（例如，并发控制和更新数据）。定期和零星的刻板印象。我们用它们来扩展 和Message元类。periodic原型表明事务是周期性执行的。零星的构造型表明事务是零星执行的（方法在请求中执行）。这些刻板印象具有相同的意义，定期和零星的刻板印象（Idoudi等人，2008年），它只扩展了操作元类。截止日期和周期属性受到UML-RTDB概要文件的启发（Idoudi等人， 2008年）。与定期和零星原型相关联的deadline属性与周期构造型相关的period属性决定了事务的周期性。此外，我们定义了以下属性：triggeredTime属性：当传感器数据项被更新时，零星事务必须从传 感 器 数 据 项 中 派 生 一 个 新 的 数 据 项 ; 这 就 是 我 们 引 入triggeredTime属性的原因。我们将其与sporadic原型相关联，以定义事务执行的时间。policy属性：事务必须读取或写入数据项。读取器事务可以读取RT数据项并且读取或写入非RT数据项。但是，writer事务只需写入RT数据项。因此，我们定义了policy属性来指定每个事务的类型。我们将这种属性与周期性和零星的刻板印象联系起来。优先级属性：事务根据其优先级进行调度，优先级是根据事务的截止日期分配给事务的●●●H. Marouane等人/Journal of King Saud University483●（最早期限优先调度策略）。因此，在较低优先级事务之前执行高优先级事务。只有当高优先级事务准备好执行时才是这样。如果没有更高优先级的事务准备好执行，则执行更低优先级的事务（如果它准备好的话）。因此，数据冲突解决应该基于事务优先级。因此，优先级分配策略对于控制事务间的并发性具有重要意义。事实上，我们定义了优先级属性，它接受一个整数参数。我们将这一属性与周期性和偶发性刻板印象联系起来。nfp原型：它是从MARTE（OMG，2011）的NFP建模子配置文件导入的。该构造型扩展了Property元类，以显示属性用于满足非功能性需求，如持续时间和频率。3.2. 模式规范设计模式是通用设计，旨在实例化以建模不同的系统。因此，有必要定义UML扩展来表达模式中的可变性，以帮助设计人员区分不同系统之间的共性和差异。出于这个原因，我们扩展了功能，结构和行为视图与UML扩展表示明确的可选和基本元素。实际上，类图、序列图和用例图是用以下原型扩展的：（a）强制性的，用于指定当模型应用于特定应用时必须实例化的基本元素（即类、属性、方法、关系、用例、参与者、生命线、消息和组合片段），以及（b）可选的，用于表达可选的特征（即，类、属性、操作、关系、用例、参与者、生命线、消息和组合片段）。这些定型观念与Rekhis等人（2010年）定义的可选和强制定型观念具有相同的含义。Rekhis等人（2010）中引入的原型仅扩展了UML类图，特别是类和关系。此外，我们还使用变体和variationPoint刻板印象对于用例图，后者用于指定一个抽象的用例，可以用不同的方式表达，而前者用于指定用例表示变化点的具体实现。对于类图，我们使用UML继承和构造型（构造型用于为UML类提供更多的语义）对变化点进行建模：每个变化点由一个抽象类和一组子类表示。抽象类是原型化的variationPoint，每个子类都用原型变量定义。 这两个刻板印象与Ziadi中定义的刻板印象具有相同的意义等人（2003年）的报告。此外，我们建议的替代刻板印象来扩展序列图。这种刻板印象被用来表达不同的信息。实际上，它表明设计者必须根据当模式被实例化时，3.3. 模式实例化设计模式被专门化，并由特定的应用程序实例化。因此，我们需要新的扩展来区分模式参与者和特定的添加元素。出于这个原因，我们扩展了我们的配置文件，以支持设计模式的结构、行为和功能视图的实例化。对于结构化设计模式的实例化，我们的原型旨在可视化应用程序模型中的基本模式元素（类、属性和操作）。为了定义类、属性和操作的符号，我们的工作基于Dong等人（2007）提出的UML概要文件。因此，我们导入了以下构造型：（a）PatternClass，与一个类相关联，以表明此元素是一个实例化的模式类，并且不是由设计者添加的，以及（ii）PatternAttribute和PatternOperation，它们分别显示了属性和操作在设计模式中的作用。在特定应用程序的设计中，除了实例化在模式中起作用的元素外，设计人员还可以添加一些与应用程序相关的特定元素。因此，区分图案元素和特定元素是重要的。因此，我们定义了新的ApplicationClass、ApplicationAttribute和Applica-tionOperation构造型，它们分别表示类、属性和操作是由设计器添加的，构成具体的应用要素。为了识别在模式中扮演角色的模型元素，序列图表，我们从Rekhis et al.（2010）中定义的配置文件中导入了原型PatternLifeline。这个构造型用于区分实例化的模式生命线和特定的生命线。Rekhis等人（2010）提出的UML概要文件并没有处理消息和组合片段，这些片段代表序列中的基本元素图.因此，在本发明中，我们定义了PatternMessage和PatternFragment构造型。前一个构造型用于指示消息参与序列模式实例。后者与一个组合片段相关联，以显示此元素是从模式序列图实例化的。此外，我们还提出了ApplicationLifeline和ApplicationMessage构造型，分别表示设计者根据建模的应用程序将生命线和消息作为特定元素添加。由于用例图是模式解决方案的一部分，因此我们提出了新的扩展来显式地表示功能视图中的模式元素角色。我们引入了新的原型，称为Patternal-Case和PatternActor。 第一个原型用于指定用例是从模式中实例化的，而第二个原型用于指示参与者是从模式的用例图中实例化的我们支持-还提出了ApplicationActor和ApplicationActor Case构造型，以分别指定参与者和用例是用于实例化模式的建模应用程序的特定元素。所提出的构造型允许容易地区分模式元素和特定元素，这使得使用工具来验证模式实例变得更容易。对于每一个原型，我们采用了Dong等人（2007）提出的标记值模式，不仅指定了模式类图中元素的确切角色，而且还指定了模式序列图和用例图中元素的角色。这个标记值的格式如下：{pat- ternName，role}，其中patternName是模式的名称，role是元素在模式中所扮演的角色的名称。PatternAttribute和模式操作当在不同类角色内定义的两个不同操作或属性角色具有相同名称时，符号可能会混淆。在模式实例的验证过程中，这种模糊性可能会使工具感到困惑。为了克服这一限制，我们保留了有关属性或操作的类名的信息。 因此，我们添加了className 为PatternAttribute和PatternOperation构造型。 所以，这些刻板印象484H. Marouane等人/Journal of King Saud University跟在标记值{patternName，className.role}之后，以指示属性或操作与模式中名称为className的类相关联。当两个不同的操作或不同类角色的属性角色具有相同的名称时，信息类名称允许消除歧义。我们建议通过上述的原型来扩展类、序列和用例元模型，如图1（结构视图）、图2（行为视图）和图3所示。图3（功能视图）。这些图描述了UML元类之间的关系，以便于理解下一节中解释的OCL规则。事实上，图1展示了UML类图元模型。后者提供了通过关联和继承关系链接的基本元素（类、分类器、属性、操作和关联）。结构元素由属性（使用Property元类定义）描述。概念ofProperty有两个基数为1的对象属性。在实例层，确定类Prop的实例是表示属性（由类包含）还是非属性（由关联包含）。此外，Meta模型支持定义操作（操作元类），表示类的函数和方法。图2显示了UML序列图元模型。生命-line元类表示特定对象。生命线通过消息（Message元类）相互通信每个消息触发两个事件：发送事件和接收事件。交互元类指的是行为 单 元 ， 它 关 注 于 图 中 一 组 对 象 之 间 的 信 息 交 换 。InteractionFragment是交互的一部分Interaction和InteractionFragment之间的聚合指定了复合交互，在这个意义上，交互可以包含其他子交互。图3显示了UML用例图元模型。这个Meta模型涵盖了用例图的基本元素：Actor、Use-Case、Extend和Include. Actor元类表示直接与系统交互的外部实体所采用的角色。ACCECase元类引用了一组表示系统行为的操作。用例之间可以有关系。基本上，一个用例可以包括（或可以被包括在）其他用例，并且可以扩展（或可以被扩展）其他用例。这些元模型包含的概念缺乏精确的语义。因此，我们通过上面描述的构造型扩展了UML概念。这些原型增强了各种UML概念的概念语义。换句话说，我们将原型添加到UML元素中，以帮助设计人员区分（i）基本元素和可选元素，（ii）模式元素和特定元素，以及（iii）RT概念和非RT概念。3.4. OCL约束使用构造型引入可变性使模式的理解更容易，但是，它可能会产生一些不一致。例如，如果一个强制类继承自一个可选类，则生成的模型是不一致的。因此，我们提出定义以OCL表示的约束，以减少可变元素的影响，从而保证模式图的一致性和正确性。事实上，这些约束可以用来确保设计模式的（i）静态视图的元素，（ii）功能视图的元素和（iii）行为视图的元素之间的一致性。这些约束的表达基于辅助操作（isStereotyped（S）），该操作指示元素是否由字符串S定型。Ziadi等人（2003）使用OCL将其形式化如下：Fig. 1. 类元模型扩展的原型。H. Marouane等人/Journal of