A General Architecture for Client-Agnostic Hybrid Model Editors as a Service
2025-04-30
0
0
1.11MB
6 页
10玖币
侵权投诉
A General Architecture for Client-Agnostic Hybrid Model
Editors as a Service
Liam Walsh
liam.walsh@queensu.ca
Queen’s University
Canada
Juergen Dingel
dingel@queensu.ca
Queen’s University
Canada
Karim Jahed
jahed@cs.queensu.ca
Queen’s University
Canada
ABSTRACT
In this paper, we propose a general architecture for designing lan-
guage servers for hybrid modeling languages, that is, modeling
languages that contain both textual and graphical representations.
The architecture consists of a textual language server, a graphi-
cal language server, and a client that communicates with the two
servers. The servers are implemented using the Language Server
Protocol (LSP) and the Graphical Language Server Protocol (GLSP)
and are based on a shared abstract syntax of the hybrid language.
This means that only static resources need to be common between
the graphical and textual language servers. The servers’ separa-
tion allows each to be developed and maintained independently,
while also enabling forward-compatibility with their respective
dependencies.
We describe a prototype implementation of our architecture in
the form of a hybrid editor for the UML-RT language. The evalua-
tion of the architecture via this prototype gives us useful insight
into further generalization of the architecture and the way it is used.
We then sketch a suitable extension of the architecture to enable
support for multiple diagram types and, thus, multiple graphical
views.
CCS CONCEPTS
•Software and its engineering →Software design engineer-
ing;Domain specic languages.
KEYWORDS
Hybrid, LSP, UML-RT, Graphical Modeling, Language Server
ACM Reference Format:
Liam Walsh, Juergen Dingel, and Karim Jahed. 2022. A General Architecture
for Client-Agnostic Hybrid Model Editors as a Service. In ACM/IEEE 25th
International Conference on Model Driven Engineering Languages and Systems
(MODELS ’22 Companion), October 23–28, 2022, Montreal, QC, Canada. ACM,
New York, NY, USA, 6 pages. https://doi.org/10.1145/3550356.3563131
1 INTRODUCTION
With the increasing amount of complexity in software systems, it
is important to be able to express them clearly and consistently.
This is a must to ensure eective communication among possibly
diverse sets of stakeholders such as designers, developers, and
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
MODELS ’22 Companion, October 23–28, 2022, Montreal, QC, Canada
©2022 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-9467-3/22/10.
https://doi.org/10.1145/3550356.3563131
users. Abstracting away implementation-level details is one way to
provide clarity to a user. Consistency can be achieved by a denition
of rules and patterns. This type of approach to expressing systems
allows them to be easily understood by way of familiarity with
their domain, rather than programmatic knowledge.
The high-level motivation of our work is to enable better ways to
express models of software as used in Model-Driven Development
(MDD). The ultimate goal is to facilitate the development of hybrid
editors for modeling languages.
We propose a methodology of creating two separate services
to equip Integrated Development Environments (IDEs) with the
capabilities of hybrid editing. This involves the implementation of
two concrete syntaxes, one textual and the other graphical, each
providing suitable representations (or views) of the same underly-
ing model and its abstract syntax. While this methodology seems
straightforward conceptually, it is challenging to implement in a
way that supports cohesion, maintainability and evolvability.
2 BACKGROUND
2.1 Hybrid Modeling Languages
Hybrid modeling languages are characterized by their use of more
than one concrete syntax paradigm. In this paper, we will use the
term to refer specically to a modeling language which has both a
textual concrete syntax, and a graphical concrete syntax.
2.2 Language Servers
The classical method of implementing support for a language in an
IDE usually results in high coupling to the IDE, even though most
modern IDEs are functionally similar. Language servers take advan-
tage of these similarities by treating IDEs as clients to be serviced
and whose behaviour is dictated by the language’s semantics.
2.2.1 Language Server Protocol. The Language Server Protocol
allows a client IDE to trade information and instructions with a lan-
guage server. The language server can run as a background process
and be queried by the IDE in order to give the user advanced edit-
ing features such as “auto complete”, “go to denition/declaration”,
“nd all references”, among others [
17
]. LSP allows for the client
IDE to be completely language-agnostic.
2.2.2 Graphical Language Server Protocol (GLSP). The Graphical
Language Server Protocol [
3
,
5
], is an open source framework origi-
nally built to facilitate displaying SVG graphs and providing editing
tools for graphical languages. This is all done in such a way that one
implementation would be able to service multiple IDEs compliant
with GLSP, hence the similarity in names between it and LSP.
GLSP functions by visiting a model, similar to how any other
modeling tool would parse it, and systematically creating graph
arXiv:2210.12246v1 [cs.SE] 21 Oct 2022
MODELS ’22 Companion, October 23–28, 2022, Montreal, QC, Canada Liam Walsh, Juergen Dingel, and Karim Jahed
objects that reect each dierent object in the original model speci-
ed by the developer. GLSP also allows the language developer to
choose where to persist any elements of the concrete syntax that
do not impact the execution semantics of the model (i.e. graph X/Y
positioning, colors, shapes, etc.).
2.3 UML for Real-Time
The Unied Modeling Language for Real-Time (UML-RT) is a mod-
eling language that is specied as a UML Prole. The language
was created with the properties necessary to be able to describe
Real-Time systems [
11
,
16
]. UML-RT’s established graphical speci-
cations made it a good candidate for our prototype hybrid editor.
The two main components of a system’s architecture are its struc-
tural and behavioral aspects. UML-RT is able to create graphical
models of systems that are capable of specifying both these struc-
tural and behavioral aspects. Some tools for specifying UML-RT
models, such as the open-source eclipse-based Papyrus-RT [
7
], are
able to automatically generate functional code from a given model.
RTPoet is a toolset that we have created for the purposes of
working with UML-RT models of dierent forms [
12
]. The original
use case was to bridge the gap between dierent UML-RT imple-
mentations (specically Papyrus-RT [
7
] and RTIST/RSARTE [
8
,
9
])
by model transformation. We have already specied a textual im-
plementation of UML-RT under the RTPoet umbrella. Once the
UML-RT hybrid language server prototype is suciently mature,
we intend to integrate it into the RTPoet suite.
3 PROPOSED ARCHITECTURE
In this section, we identify some key requirements that the architec-
ture must satisfy. Then, the structure of the architecture is described
together with sequence diagrams showing the interaction between
components to realize aspects of these requirements.
The use of any language in an IDE must include the support of the
standard CRUD (create, read, update, delete) operations. However,
these are not a necessary point of focus for our proof-of-concept
implementation, as these operations are mostly realized by the
language denitions contained in the servers themselves. We are
more interested in the design of a high-level architecture.
Current best practices in GUI development include the use of
the Model-View-Controller (MVC) design pattern. GLSP’s design
is informed by this pattern, as graphs naturally suggest the use of
GUIs. We have chosen to model the textual language server in a
similar way. While MVC is not normally applied to text editors, its
properties allow us to maintain synchronization between views.
In the context of language servers, most of the responsibilities of
the “controller" and “view" are carried out by the client, language-
specic tasks are delegated to the server.
3.1 Four Core Interface Requirements
Figure 1 shows our proposed general approach to creating the
architecture for hybrid language services. There are four main
interfaces that must be implemented in order to fulll the CRUD
use cases in each of the textual and graphical views while keeping
them synchronized. These four interfaces are denoted by the edges
in the gure, and each represent a transformation to, or from, the
views and model. Essentially, the model is the abstract syntax,
Figure 1: High-Level Relationship Between Graphical and
Textual Views
while the graphical and textual views are two dierent types of
concrete syntaxes used to specify and represent it. The four dierent
interfaces will be discussed in more detail below.
3.1.1 Generation. We will use “generation" or “regeneration" to
refer to the transformation of the textual view into the model. This
is the intended usage of Xtext [
4
], and will not be any dierent
than the rst step of implementing a textual DSL (Domain-Specic
Language) using the tool. The realization of this interface requires
the specication of a grammar for the language. The textual lan-
guage server uses the grammar to instruct the language client how
to perform this transformation.
3.1.2 Serialization. The model that the textual view generates re-
tains enough information about the original specication that it is
still possible to perform a transformation from the model itself back
to the textual view. This process is the inverse to the previously
explained one, and the client is advised on how to do so by the
textual language server.
3.1.3 Rendering. The “rendering" of the graphical view should
be realized by specifying a mapping between model objects and
graph element objects (predominantly dierent types of nodes and
edges). More granular parts of the language may be left out of this
mapping, if they can not be appropriately graphed and can be more
eectively handled by the textual view (e.g., action code in state
machines).
3.1.4 Updating. Graphical views typically only display a subset of
the elements of the model they represent. Lower-level properties
may be simplied or excluded altogether, meaning we cannot reli-
ably retrieve these by transforming a graphical view into a model.
We can, however, manipulate the model directly by keeping track
of the graph elements’ source mappings. GLSP allows for this to be
done natively. We will refer to this as “updating" the model, as we
are applying an update directly to the model objects by proxy of
the graphical elements. Models can be kept complete and correct
by restricting the operations available in the graphical view (often
by using “palettes of operations"). Each time an update is applied,
the graphical view must then be rendered anew using the updated
model.
3.2 Architecture Diagram
Figure 2 depicts our proposed general architecture for hybrid lan-
guage servers. The diagram shows the communication between two
摘要：
展开>>
收起<<
AGeneralArchitectureforClient-AgnosticHybridModelEditorsasaServiceLiamWalshliam.walsh@queensu.caQueen’sUniversityCanadaJuergenDingeldingel@queensu.caQueen’sUniversityCanadaKarimJahedjahed@cs.queensu.caQueen’sUniversityCanadaABSTRACTInthispaper,weproposeageneralarchitecturefordesigninglan-guageserver...
声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！
分类：图书资源
价格：10玖币
属性：6 页
大小：1.11MB
格式：PDF
时间：2025-04-30
渝公网安备50010702506394
