面向服务的UML和UML-RT建模语言在复杂反应式系统开发中的应用

34理论计算机科学电子笔记65 No.7（2002）网址：http://www.elsevier.nl/locate/entcs/volume65.html17页使用UML和UML-RT基础、挑战和限制因戈尔夫湾克吕格加州大学圣地亚哥分校加州电信和信息技术研究所La Jolla，CA，92093-0114，美国摘要系统地开发复杂的反应式系统的关键是彻底理解系统提供的服务。在我们看来，服务的定义是建立某种结果所需的组件之间的相互作用服务将注意力从单个组件的细节转移到系统的全局视图我们给出了服务概念的正式定义，并讨论了UML和UML-RT提供的建模语言在多大程度上支持面向服务的开发方法。1介绍越来越多的软件系统是通过组合在各种类型的计算平台上运行的单个甚至个性化的软件服务而形成的，所述计算平台的范围从大型服务器到汽车中的电子控制单元（ECU）到智能卡系统。当今基于客户机/服务器的Internet应用程序、机顶盒、蜂窝电话、便携式数字助理，甚至手持计算机游戏的流行，只是高度分布式、交互式、面向服务的软件系统所具有的潜力的第一个指标。但是服务到底是什么，它与方法有什么区别呢 在某种编程语言中调用一个对象，我们需要什么来系统地开发服务是一些著名的建模语言，UML是否已经为服务的规范化做好了准备1.1服务的概念文献提供了术语“服务”的许多非正式定义其中，[7]。例如，在[8]中，我们在“（软件）服务”条目下发现了以下内容2002年由ElsevierScienceB出版。 诉操作访问根据C CB Y-NC-N D许可证进行。克吕格35到通常可通过应用程序编程接口访问的客户端软件或系统 类似的定义出现在中间件技术的上下文中，例如Jini[25]，SOAP[23]，.NET[18]或JXTA[12];它们确实将服务视为系统实现中的中心元素。然而，他们的服务概念通常只包括客户端可以调用的（语法）操作列表。执行某些调用的顺序–然而，我们认为，准确描述服务的一个关键因素是建立服务所涉及的实体之间的交互。为了支持这一观点，我们给出了一个汽车领域的例子在当今的一些单独的功能（如越来越多地，由乘客连同他们的蜂窝电话、膝上型计算机或个人数字助理（PDA）一起带入汽车的服务与车辆上的系统交互;作为示例，考虑基于蜂窝电话的导航系统与前面提到的豪华汽车的车载显示器交互这个例子表明，在开发上述服务时，我们必须对所考虑的系统内的交互有深刻的理解。这远远超出了在提到的中间件方法中提倡的函数名和数据库的主要语法驱动规范。这个例子还显示了另一个重要的趋势：越来越多的安全相关和便利功能融合在一起-这就需要一个精确的、数学上建立的服务概念，以支持组件交互的系统分析和设计。1.2系统化服务开发设计和管理多个单独服务之间的相互作用非常复杂。虽然XML、SOAP和.NET等技术确实为某些服务提供了一个实现平台，但需要一种更基本的概念性方法来捕获服务的需求并开发服务规范证明正确性和预测资源需求是除了最琐碎的“独立”系统之外的所有系统都存在的困难问题的例子;服务之间的通常情况下，在需求捕获与软件系统的后续设计和实现阶段之间存在显著差距系统向其环境提供的不同服务通常分布在克吕格36系统传统上，客户端/服务器系统是围绕中央服务器（平台）构建的，客户端和服务器之间有着明确的区别;随着时间的推移，这种关注点的分离逐渐消失，产生了每个组件都扮演客户端和服务器角色的系统。一个关键的问题是如何跟踪在开发过程早期捕获和建模的需求，直到它们在实现中的对应物这种可追溯性的缺乏反过来又使得难以确保重要的质量属性，例如信息传输的吞吐量、延迟或安全性–这些质量属性中的许多不能在本地建立;相反，它们来自几个系统组件的相互作用这使得研究和设计这些属性的基础上，参与建立一个服务的组件的协作;因此，我们可以在全球范围内，而不是只在本地的基础上的原因。然后，将全局交互协议和属性映射到各个组件的行为成为系统设计的一个步骤，从更抽象的服务描述到实现服务的组件的更具体的规范然而，大多数著名的软件开发方法和建模都将重点放在单个软件组件的构建上，而不是组件协作上面 向 对象开发领域的一个例子是统一建模语言（UML）[19]。它的语法手段，指定基于状态的行为的各个组件（状态图）是远远优于相应的nota-tions交互模式（活动，序列和协作图）的发展。例如，相应的工具环境几乎不支持从交互规范到实现这些交互的组件规范的转换。因此，基于UML的开发过程（参见，例如，[13，11]）强调状态图的开发-协调方面通常只被看作是非正式的初始需求捕获的一部分，或者作为文档的一种手段。对于强调用例的方法论来说，这一点尤其正确例如，[10]）;用例以非正式的方式描述用户和开发中的系统之间的交互它们主要用于早期开发阶段，以捕获整个系统的核心功能从用例到系统实现的无缝转换既不是预期的，也不是自动可行的。因此，这些开发方法及其相应的工具需要根据本文中所假设的服务概念和迭代开发方法来重新考虑。克吕格37∈1.3贡献和大纲在以下几节中，我们将解决两个挑战。在第2节中，我们将在正式系统模型的基础上介绍一个精确的服务概念。这种服务概念主要关注系统组件之间的相互作用，但可以很容易地扩展到满足复杂的分层系统规范，甚至表示详细的服务质量约束。基于这种服务概念，我们在第3节中研究了工业上接受的建模语言（即UML及其“实时”伙伴UML-RT）在多大程度上在第4节中，我们提出了我们的结论，并讨论了未来工作的机会。2迈向精准服务理念正如我们在第1节中所概述的，服务的概念仍然缺乏精确的基础。在本节中，我们将为建立这样一个基础迈出第一步，特别是将服务理解为交互模式2.1系统模型我们通过首先介绍我们工作所基于的结构和行为模型（系统模型我们特别注意提供一个系统模型，使面向交互和状态的行为规范并行。这是这两个互补架构方面无缝集成的先决条件;这种集成是必要的，例如，捕获服务质量（QoS）规范。在此过程中，我们介绍了描述模型所需的符号和概念2.1.1系统结构在结构上，系统由组件、对象或进程1的集合P和命名通道的集合C组成每个通道通道C直接从它的源到它的目标组件;我们假设通道名称是唯一的。通道连接相互通信的组件通过这些渠道进行信息交换的通信过程。对于每一个p∈P，我们关联一个唯一的状态集，即的部件状态空间Sp. 我们将系统的状态空间定义为Sd=efp∈PSp. 为简单地说，我们用消息标识符的集合M来表示消息表1总结了这些结构要素。1在本文档的其余部分中，我们可以互换地使用术语组件、对象和克吕格38∈−∈ECLMCLL控制CRRRM实体含义P系统组件C有向通道分量p∈P的Sp态S系统状态（Sd=efp∈PSp）M组消息标识符表1系统模型的结构要素图1示出了系统结构图（SSD），描述了集合P和C在图形符号;它定义P={LM，Control，RM}和C={cl，lc，cr，rc，ec}。图1.一、定义集合P和C的简单SSD我们在这里考虑的系统是固定的，因为集合P和集合C都不随时间变化。在2.3节中，我们将讨论这个模型如何适应结构动态变化的系统。2.1.2系统行为现在我们转向系统模型的动态方面我们假设系统组件通过在通道上交换消息来在彼此之间以及与环境进行通信。我们进一步假设一个离散的全局时钟驱动系统。我们用自然数的集合来模拟这个钟。 直觉，在时间t每个组件决定其输出基于它在时间t1之前已经接收的消息以及基于它的当前状态。然后将输出写入相应的输出通道并改变状态。至少一个时间单位的延迟模拟了输入和它触发的输出之间的处理时间[1，3]）。形式上，对于每个通道c C，我们将从收集沿c发送的所有消息中获得的历史按其发生的顺序相关联。这里我们的基本假设是通信是异步发生的：消息的发送方不必等待目的地组件接收消息这使我们能够通过流来模拟信道历史。流和流上的关系是一种非常强大的指定机制克吕格39∈∈∈P×∈实体含义Cchannelvaluationn（Cd=ef C→M）所有通道历史的C轴S∞状态历史（C_∞×S）_∞组合通道与状态历史系统的P（（C_∞×S）_∞）语义域表2系统模型的行为要素对于分布式、交互式系统（cf.[4，24]）。它特别适用于面向属性的组件规范，以及细化概念的定义和规范之间相应细化关系的验证（参见[14]）。在这里，我们只使用和介绍了这个丰富语义模型的一小部分;为了对这个主题进行全面的介绍，我们建议读者参考[24，4]。流是一个有限或无限的消息序列通过X和X∞我们分别表示集合X上的有限序列和无限序列的集合Xωd=efX∈X∞表示集合X上的流的集合。 注意我们可能用i ∈识别X_∞和X_∞（[0，i]→X），X，分别。这允许我们，对于x Xω和n，使用函数应用程序来编写x.n，流x的第n个元素。WefineCd=ef C→M作为一个通道估值，分配一个序列，消息到每个信道;我们获得所有信道的有限估值的定时流元组C_∞它模拟了在每个时间点，组件可以在单个通道上发送多个消息有了消息序列上的定时流，我们就有了一个组件间通信随时间变化的模型。类似地，我们可以定义一系列系统状态随时间的变化作为集合S∞的一个元素。有了这些语义，我们现在可以定义一个系统的语义，该系统具有通道集C、状态空间S和消息集M作为f的元素。（（CS）∞）。一个系统的语义的一个元素nt（n1，n2）由系统的C通道的评估C∞）和系统的描述状态随时间的变化（Δ2S∞）。在一个系统的语义中存在多个元素就表示非确定性。表2列出了用于建模系统行为的语义实体2.2服务理念基于上面介绍的系统模型，我们现在正式定义我们的服务概念。这个定义有两个目的。首先，它为我们提供了一个准确的处理方法，克吕格40∈∈∈∈∈∞ ∈×语义学上其次，它是确定UML和UML-RT在多大程度上适合描述服务根据我们的观察，理解服务的关键是理解交付服务所涉及的组件之间的相互作用，我们将服务概念定义为特定时间段内整体系统行为的投影更确切地说，我们定义了一个集合，Q（C×S）∞×∞作为一个服务（规范），与第2.1节中介绍的系统模型相关给定一个服务Q，每个元素（t，t）Q描述了系统在时间t之前的行为的一个非确定性替代这个服务概念以抽象的方式捕捉到在某个时间点之前所考虑的系统中发生的事情;它涉及系统行为的两个主要方面：组件交互和状态更改。组件只是间接地被称为通道的源和目的地，以及这个模型中程序状态的位置例如，考虑以下服务规范，其中cC是任意通道2：Qt={（ε，∞）：ε∈（Cε×S）∞ε#{t∈：周期性kε=ε1.c.t}=∞}这个规范描述了一个服务，其中消息tick经常在通道c上发生;例如，这可以在通道c上建模时间服务。在第2.4节中，我们将展示如何用直观的图形符号来指定这些服务。2.3讨论我们上面定义的服务概念是相当抽象和一般的。例如，在服务规范Qt中，我们不约束除c之外的任何通道上的行为。在某种意义上，对于上面定义的服务，我们只指定系统至少必须满足的内容由于其“松散性”，这一服务理念很• 服务组合：正如我们在第1节中所概述的，面向服务的系统开发中的一个关键元素是从现有服务中组合出更精细的服务。在我们在这里介绍的语义框架中，我们可以很容易地表达顺序和并行的组合，有限和无限的重复，以及服务的中断或抢占。该模型还适应重叠服务的加入，即，服务2ForanysetAby#A我们表示A的元素的数目。为了一个新的世界（C）S）∞we定义为1C_∞tob_e_n的投影不会使其构成一个;类似于e_n的定义2S∞是S ∞在 其 第 二 个 分量 上 的 投影克吕格41⊆共享执行序列的一部分在[14]中定义的交互模式的组合操作符可以直接转移到我们在这里介绍的服务概念。• 服务细化：细化的概念，如行为和结构细化，对于将服务无缝、可扩展地集成到整体开发过程中至关重要。例如，如果Q1Q2成立，我们定义Q1为Q2的（行为）细化行为细化减少了服务规范中的不确定我们建议读者参考[14]以了解有关此和其他细化概念的详细信息，包括用于调整消息粒度和分层系统分解的工具。• 服务质量规范：QoS约束可以用公式表示为对构成服务的交互或状态行为模式的预测。例如，Q是一个服务规范，e，d∈是自然数，c∈C是一个信道。则对于所有的（n，t）∈Q，谓词：⟨ ∀t1,t2

下载后可阅读完整内容，剩余1页未读，立即下载