Fujaba图形重写技术：支持eHome系统工具的开发

理论计算机科学电子笔记127（2005）89-99www.elsevier.com/locate/entcs基于Fujaba的eHome系统工具开发Ulrich Norbisrath，Priit Salumaa，Erhard Schultchen，BodoKraft1亚琛工业大学计算机科学系55，52074 Aachen，Germany摘要阻止eHome系统在实践中广泛应用的主要原因之一是需要将所有电器、必要的控制器和基础设施组件组合起来以从衍生的增值服务中受益的电子设备。属性、依赖项、位置和安装条件必须针对此组合及其部署进行适当指定。由于服务和eHome配置的巨大差异，需要为eHome系统提供工具支持。 在本文中，我们解决了这些工具的软件开发问题。 在我们的方法中，图重写语言技术的软件开发。根据我们的经验，我们认为这种方法可以提高eHome系统工具开发的生产率。在Fujaba的帮助下，我们创建了一个能够指定功能、设备、环境和增值服务的模型。此外，我们使用Fujaba创建活动作为模型修改的图重写规则。为了应用该模型并对特定eHome和特定电器进行实际规范，我们从模型及其活动中生成了eHomeSpecificator工具。该工具可以作为支持eHome系统的更广泛工具的基础。关键词：家庭自动化，eHome，富士，图形重写1介绍eHome系统是计算机科学领域的一个不断增长的部分。其市场潜力正在增加。然而，在eHome系统可以常规地部署到群众之前，必须解决一些问题。增值服务必须满足家庭中高度多样化的条件1电子邮件：{uno|普里特|艾哈德|kraft}@ i3.informatik.rwth-aachen.de1571-0661 © 2005 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2004.12.03890联合Norbisrath等人理论计算机科学电子笔记127（2005）89例如动态方面或任意设备的交互，仅举几例。eHome一词指透过结合其先进电子设备而为其居民提供增值服务的家庭。实现增值服务的系统被称为eHome系统。eHome相关场景由特定eHome中的不同增值服务的实例支持。为了实现一个eHome场景，我们需要以下三个部分：第一-功能需求的组成;第二-结构需求;第三-行为需求，其中包含所述功能的逻辑协作机制，以描述人与eHome环境的交互。为了支持eHome场景，增值服务必须考虑这三个部分。我们在此背景下开发工具的动机是为了使生产者和消费者都能够指定设备、通用增值服务和eHome环境。此外，该等工具必须能够及支援满足eHome环境规范中的功能或硬件要求，以部署所需的增值服务。从软件工程师的角度来看，动机因此，本文的重点是表明，基于图重写语言的软件开发是一个成功的方式来开发必要的工具，以支持eHome系统。本文概述了eHome系统的领域，并以工具eHomeSpecificator为例，深入了解基于图形重写语言的软件开发。我们的研究涉及安全、消费和信息娱乐领域。作为本文的一个具体例子，我们考虑一个住在部分设备的eHome公寓中的客户（见图1）。在公寓里，有六个房间：走廊，办公室，客厅，浴室（包括厕所），厨房和卧室。每个房间都至少有一个可控光源，并通过一扇门连接到走廊。走廊本身有一个入口门。一扇门从厨房通向起居室。除了走廊外，每个房间都有窗户。卧室和客厅的窗户都装有破窗传感器。在入口处和走廊上安装了开/关传感器，走廊上有一个摄像头。厨房配备了火灾传感器。住在这间公寓的客户希望有一个自动照明系统和监视他/她的财产，以增加安全性。这些请求可以通过两项增值服务来满足：轻型移动和安全。2有关这些域名和可能的增值服务的更多信息，请参见[9]。联合Norbisrath等人理论计算机科学电子笔记127（2005）8991图1.一、支持安全方案的eHome规范更改示例虽然只言片语足以表达客户的意愿，但从订购到最终安装设备和部署增值服务的过程自动化是具有挑战性的。在图1的第二部分中，所有用圆圈标记的设备都必须添加到公寓的安装中，以完成客户订单的硬件设置为了便于获取必要的数据来描述已安装的设备和所示示例的修改，需要一个规范工具这个工具就是eHomeSpecificator。它有助于指定eHome环境的位置结构是什么 此外，它还有助于根据选定的服务要求添加缺少的设备。一方面，该工具提供了在特定的eHome中指定先决条件的可能性，另一方面有助于执行所需增值服务所需的更改（见图1）。因为我们需要指定各种实体以及它们之间的关系Fujaba [12]是一个开放的UML建模环境，最初设计用于支持往返工程。它方便用户以可视化的方式设计类、其他几个UML图和故事图。类图用于定义类，它们的属性和相互关系。类可以以Java源代码的形式导出，其中包含处理这些类的对象的适当方法。生成的代码[4]符合Java Bean架构。故事图是通过图重写规则来定义的[5]。这些图包含由对象、与其他对象的关系和一般断言组成的故事模式 这些模式与主机图相匹配。如果找到这样的匹配，故事模式可以创建或删除对象以及关系。而且，控制流程可以根据这种匹配的成功而改变。与类图一样，故事图也是92联合Norbisrath等人理论计算机科学电子笔记127（2005）89Fujaba的代码生成。在某种程度上，Fujaba可以被视为一种使用图形转换的可视化编程语言[13]。由于其灵活的插件机制，在过去的几年里，Fujaba从一个UML建模工具发展成为一个开放的框架，用于多种类型的基于图的应用程序。这尤其适用于软件工程领域，因为许多通过插件扩展Fujaba的项目都集中在软件开发或分析上。在下一节中，我们将描述eHomeSpecificator中使用的模型以及为该特定模型生成eHomeSpecificator的关键步骤第3节介绍了相关的工作，第4节显示了该项目的可能扩展最后，我们在第5节中进行了总结。2从Fujaba到eHomeSpecificator在我们的项目中，我们使用Fujaba来指定UML类图方面的数据模型。添加活动是为了实现模型的逻辑组件。我们选择不将我们的项目集成到Fujaba框架本身，而是创建一个仅基于Fujaba生成的Java代码的独立应用程 序 。 我 们 将 把 这 个 包 含 Fujaba 数 据 模 型 代 码 的 应 用 程 序 称 为eHomeSpecificator。与插件开发项目相比，此解决方案会触发一些关于基本用户交互的重复性任务。然而，这种独立的方法允许更大的可扩展性，因为它不会对用户交互造成任何限制。此外，创建数据模型和系统逻辑的开发人员与工具的用户严格分离我们专注于简化从Fujaba到eHome-Specificator的代码转换。特别是，我们专注于以通用但有用的方式在eHomeSpecificator用户界面中启用由故事图表定义的活动。例如，从故事diagram创建的生成和编译的Java代码不包含用于其参数或活动本身的有用名称。我们添加一个XML描述文件，为每个Activity定义附加属性，例如标签和工具提示。一般而言，eHomeSpecificator的开发有以下步骤，本节稍后将详细介绍• eHome模型的设计：为模型的静态结构创建类图，为模型的动态创建故事图• eHome模型联合Norbisrath等人理论计算机科学电子笔记127（2005）8993图二、eHome模型• 工具开发：创建访问和可视化模型的环境。在本文中，我们仅介绍了eHomes模型的一部分，以通过一个更小且更难以理解的示例来说明eHomeSpecificator的开发。所呈现部分涵盖装置定义的规范，其稍后用于给定eHome的规范。在这个受限制的例子中，我们说明了模型如何与Fujaba和eHomeSpeci ficator.eHomeSpecificator的开发始于Fujaba的eHome模型的设计模型的静态结构在UML类图中指定（参见图2），其动态方面由Fujaba故事图指定的活动捕获（参见图3）。如前所述，图2仅提供了定义设备的必要信息。设备可以是任何类型的设备，如火灾探测器，灯或控制器形式的软件组件。设备定义结合了热量或烟雾探测等功能，这些功能由功能类定义，并通过设备接口提供基于这些接口，设备可以稍后在eHome规范或增值服务部署中连接。eHomeSpecificator工具中火灾探测器设备定义的图示如图4所示。eHome模型的设计活动是更改模型并获取有关信息的唯一方法图3显示了向设备定义添加功能的活动该Activity为给定的设备定义创建一个新的DeviceFunction，在图中称为此对象创建的DeviceFunction属于给定的FunctionClass。 活动使用通用活动调用机制94联合Norbisrath等人理论计算机科学电子笔记127（2005）89图三. 用于向设备定义添加功能的活动。前面提到的。作为集成的结果，该活动显示为编辑器窗口左侧的一个按钮。此特定活动在eHomeSpecificator中显示为按钮New DevFunc（参见图4）。在eHome模型设计阶段之后，模型被具体化为Java代码使用Fujaba的代码生成器。在下一个开发阶段，我们将开发eHomeSpeci ficator工具。将该工具想象为所描述的eHome模型的容器和运行时环境。模型上的活动使用前面提到的通用机制与工具的图形用户界面绑定。模型结构的不同逻辑部分在相应的编辑器中可视化（见图4）。逻辑部分使用JGraph [3]技术呈现在用户界面中。建立了相应的翻译器。因此，每个编辑器视图都有一个翻译器。翻译器的任务是遍历eHome模型使用Fujaba给我们带来了几个优势。我们可以建模工具的内部数据结构，在标准化的可视化规范语言UML中的eHome模型的静态结构。虽然获得的类图表示eHome模型的静态方面，但我们也可以使用Fujaba故事图可视化地指定模型的动态方面。来自模型的基因级代码是可执行的，并且可以使用通用活动调用机制轻松地集成到工具中。如果我们在模型中需要一个新的活动，那么最终的集成任务包括代码生成，联合Norbisrath等人理论计算机科学电子笔记127（2005）8995图四、设备定义编辑器中的火灾探测器编辑XML文件，编译生成的代码。然而，执行这些更改的时间成本减少了3。但是，如果静态结构发生了变化，我们仍然需要为翻译器手动编程。我们将在今后的工作中处理这方面的问题。3相关工作一个工作的eHome的一个重要先决条件是一个基于组件的框架，它使不同的传感器和演员的控制-电器- 并且同时允许容易的基于组件的互连和部署。已经提出并建立了几种技术来实现这一目标。其中最著名的是OSGi[16]。它的目标是集成不同的家庭自动化标准（例如，Jini、USB、EHS、EIB），并为基于组件的服务提供执行环境。OSGi框架的作用类似于基于组件的服务的服务器和容器，这些服务被表示为bundle。对OSGi及其概念的更深入了解可以在[2]中找到。家庭自动化瞄准大众市场。因此，我们不能指望用户提供技术背景。主要是，用户将期望从家庭自动化设备的琐碎的即插即用功能，因为他们知道他们从他们的传统吊坠。这导致了对自配置和免维护系统的需求。家庭自动化不能要求技术人员3我们需要大约五分钟96联合Norbisrath等人理论计算机科学电子笔记127（2005）89到用户家中，将任何类型的设备集成到家庭网络中。因此，需要自动配置和软件部署。当前的方法处理手动配置管理和软件部署[19，18]。这种需求的解决方案必须简化分布式eHome系统的实现、配置和部署，这不会给用户带来任何进一步的负担。eHomeSpecificator只是支持配置和部署过程的工具链的一部分。它支持eHome的规格化和增值服务的配置。DeploymentProducer [14]将使用此规范，并使用知识库创建最终配置作为OSGi Instancer的输入，后者负责OSGi框架上的实际部署。对于我们的模型，我们可以依赖于概念建筑设计方法的结果[11，10]，它代表了从软件工程到土木工程的联系。当设计一座建筑时，一个有经验的建筑师会将他积累的知识隐含地应用到新的草图上。 建筑元素，如墙、窗或门，具有其概念意义，即形成组织区域或房间，以保证例如光线和通风，或以确保无障碍。因此，这些概念元素形成了设计结构的功能视图，但没有明确定义。在这个早期的设计阶段，称为概念设计，大多数建筑师不使用CAD系统来详细说明他们的草图。他们宁愿用铅笔和纸工作。他/她头脑中的概念信息丢失了。这些概念信息将为我们的自动化方法提供非常有价值的输入。而eHomeSpecificator则相反，因为该工具允许对概念设计阶段丢失的细节进行后验规范。因此，我们的模型在一定程度上受到这种方法的激励有许多不同的工具用于可视化建模和代码生成。Fujaba就是其中之一。我们可以使用的另一个系统是我们部门开发的PROGRES（编程图形重写）语言[17]。PROGRES系统不一定局限于UML模型，尽管UML建模是可能的。PROGRES用于指定和测试图模型和重写规则，并最终生成可以以高效方式执行的源代码。它由UPGRADE框架（基于GRAph-based DESIGMENT的通用平台）[1]支持，可用于快速开发在生成的代码上运行的原型。UPGRADE提供了一个用户界面，可以适应应用程序的需求。UPGRADE还可以管理持久的图形存储，而无需开发人员的任何支持。我们部门的各种项目都得益于PROGRES和UPGRADE的组合，以实现一个规范-联合Norbisrath等人理论计算机科学电子笔记127（2005）8997基于原型，例如AHEAD [8]。Fujaba缺乏这种快速原型，因此我们必须为此目的实施eHomeSpeci ficator。然而，Fujaba在开发人员和教育中被广泛接受。它由一个活跃的社区支持，可以免费使用。4今后工作如第3节所述，我们使用知识库支持自动构建部署配置文档。我们的目标是通过知识库方法将所提出的基于UML模型的方法与一组新的翻译器集成在一起，像[6]中那样桥接UML模型和本体进一步的活动旨在为我们的eHomeSpecificator提供更广泛的支持，将其转换为开源，并将所有提到的工具合并到一个名为eHomeConfig的项目中[15]。与我们的合作伙伴inHaus [7]进行的有希望的测试显示了我们的方法在现实环境中的适用性。eHomeSpecificator是为了在eHome上下文中建模的指定目的而构建的。然而，它的灵活性允许eHomeSpecificator适应其他领域的工作。除了交换由Fujaba创建的数据模型之外，开发人员还必须为模型的故事 图 编 写 一 个 新 的 XML 描 述 文 件 。它 还 需 要 实 现 一 个 所 谓 的“Translator”Java类来帮助显示模型图。目前，由于缺乏信息，显示包括节点和边缘标记的图形不是也不能自动完成。例如，在没有进一步信息的情况下，不能为节点分配合适的标签。可以指定图形对象本身的类名，这对用户没有太大帮助。或者，可以强制开发人员提供一个getLabel方法来传递适当的标签文本。然而，这将需要在数据模型中实现严格用于向用户显示信息的代码，而这不是模型的逻辑部分的目的。标签也不能由用户自定义。5总结我们应用基于图重写语言的软件开发实践，开发一个支持工具的eHome系统。我们认为这种方法比传统的开发方法更有成效。我们开发了eHomeSpecificator以查看和编辑eHome规格。利用图重写的概念，在开发环境的98联合Norbisrath等人理论计算机科学电子笔记127（2005）89模型被集成到工具中，主要侧重于通用机制。这样做的结果是，对模型的更改只需要对工具进行很小的更改。eHomeSpecificator可作为开发面向不同细分市场的工具系列的平台。eHomeSpecificator可在概念建筑设计开发的基础上与ArchiCAD集成。基于图的解决方案是建模依赖关系的好选择，如图4所示，但是像图1这样的底层计划，结合基于图的方法，对于非计算机科学家来说会更加直观。前面提到的一体化将开放增加这种可能性。引用[1] BorisBohlen，DirkJager，AnsgarS chlei c her，andBernhard Westfe c htel. UPGRADE：为视觉语言构建在Nagib Callaos，Luis Hernanid-Encinas和Fahri Yetim的编辑，第六届世界系统学，控制论和信息学（SCI 02），卷I（信息系统开发I），第17-22页，奥兰多，佛罗里达州，美国，2002年7月。IIIS。[2] Kirk Chen和Li Gong。用Java嵌入式服务器技术开发开放式服务网关。Sun Microsystems，2001年。[3] JGraph社区Jgraph swing组件。http://jgraph.com/jgraph.html（2004年6月1日）。[4] T. Fischer ， J. Niere ， and L. 托 伦 斯 基 Konzeption und realisierung einer integriertenentwicklungsumgebungfur？ ruml，java undstory-driven-mo deling. 硕士[5] T. 这是她，J。涅尔湖 Torunski和A. 祖恩多夫。 故事图：一种基于统一建模语言的新的图形重写 In G. Engels和G.罗森伯格，编辑， Proc. 第六届图变换理论与应用国际研讨会（TAGT），Paderborn，Germany，LNCS 1764，第296Springer Verlag，1998年11月[6] K. Falkovych，M. Sabou和H. Stuckenschelles。语义网的UML：基于转换的方法。Omelayenko和M. Klein，编者，语义网，第92IOS Press，2003.[7] 在杜伊斯堡。杜伊斯堡智能创新中心。http：//www. inhaus-duisburg.de（22.6.2004）。[8] DirkJüager，AnsgarSchleic her，andBernhardWestfecht el. AHEAD：一个基于图形的系统，用于建模和管理开发过程。在ManfredNagl、AndySchu？rr和 ManfredMu？ nch编辑的《关于应用具有工业相关性的GraphTransformation的出版物研讨会》（AGTIVE'99）中，LNCS第1779卷，第325-339页，Kerkrade，荷兰，2000年9月斯普林格。[9] 迈克尔·基希霍夫和塞巴斯蒂安·林茨。基于Web的eHome服务的开发。在Proceedings ofUbiquitous Mobile Information and Collaboration Systems Workshop 2004 （ UMICS2004），卷3272的Lecture Notes in Computer Science中。Springer，2004.出现。[10] Bodo Kraft，Oliver Meyer，and Manfred Nagl. 概念设计的图形技术支持学位土木工程. In M.Schellenbach-Held和H. Denk，编辑，欧洲工程智能计算小组国际研讨会（EG-ICE 2002），第1-49页。Fortschritt Berichte，2002年。联合Norbisrath等人理论计算机科学电子笔记127（2005）8999[11] 博多·卡夫和曼弗雷德·纳格尔。概念设计的语义工具支持。 在重症 洪水，编辑，第四届国际会议的程序。土木工程信息技术研讨会，第1-12页，2003年。[12] T. Klein，U. Ni ck el，J. Niere和A. 祖恩多夫。从一个人到另一个人再回来。 技术报告tr-ri-00-216，帕德伯恩大学，帕德伯恩，德国，1999年9月。[13] H.J. 科勒大学 Ni ck el，J. Niere和A. 祖恩多夫。 使用uml作为可视化编程语言。技术报告tr-ri-99-205，帕德博恩大学，帕德博恩，德国，1999年8月[14] Michael Kirchhof，Ulrich Norbisrath，and Christof Skrzypczyk. 面向eHome系统的自动部署：描述语言和工具支持。在Robert Meersman和Zahir Tari编辑的《迈向有意义的互联网系统2004：CoopIS、DOA和ODBASE：OTM联合国际会议》中，CoopIS、DOA和ODBASE 2004，塞浦路斯，Agia Napa，2004年10月25日至29日。Proceedings，Part I，Volume 3290 of LectureNotes in Computer Science. Springer，2004.DOI：10.1007/b102173，ISBN 3-540-23663-5.[15] UlrichNorbisrath和PriitSalumaa。eHomeConfigurator。http://sourceforge.net/projects/ehomeconfig，2004年。[16] 开放服务网关计划。OSGi服务平台。http://www.osgi.org（2003年11月13日），2001年10月。 第二版。[17] 安迪·斯库尔。 O PE RationalesS pezizie enmitp rog rammiertenG raphersetzungssysteme n. 博士论文，亚琛工业大学，1991年。[18] 然后去找霍克。 集成C配置管理和软件是一种开发工具。复杂动态系统架构工作会议论文集（CDSA 2001），2001年。[19] Bernhard Westfechtel 和 Reidar Conradi 。 软 件 配 置 管 理 的 版 本 模 型 。 ACM ComputingSurveys，30（2），June 1998.