第七届MEDI会议：模型与数据工程

需积分: 10 189 浏览量更新于2024-07-19 收藏 24.7MB PDF 举报

"Model and Data Engineering" 是一本关于第七届国际会议MEDI 2017的会议论文集，由Yassine Ouhammou、Mirjana Ivanovic、Alberto Abelló和Ladjel Bellatreche编辑。这本书包含了在西班牙巴塞罗那举办的MEDI 2017会议上精选的论文，涵盖了模型与数据工程相关的多个领域。本书的主要内容分为以下几个关键知识点： 1. **特定领域的语言**：会议中的论文讨论了如何使用特定领域语言来解决复杂问题，这可能涉及到定制化的建模语言或数据表示方法，以适应特定行业或应用的需求。 2. **系统和软件评估**：这部分论文聚焦于评估和优化系统及软件性能的方法，可能包括性能分析、可靠性测试和质量保证策略。 3. **建模和形式化方法**：建模是理解复杂系统的关键，而形式化方法则提供了严谨的数学基础。这些论文可能探讨了新的建模技术，如UML、BPMN等，以及如何利用形式化方法进行验证和分析。 4. **数据工程**：数据工程涵盖了数据的获取、处理、存储和管理。这些论文可能涉及数据清洗、转换、集成、大数据处理技术，以及数据库设计和优化。 5. **数据探索和开发**：这部分内容关注如何有效地探索大量数据以发现有价值的信息，可能包括数据挖掘、可视化和预测性分析。 6. **建模异质性和行为**：在现代系统中，异质性和动态行为是常见的挑战。这些论文可能探讨如何在模型中捕捉和处理这种复杂性，比如在物联网(IoT)或分布式系统中的应用。 7. **基于模型的应用程序**：模型驱动的开发方法论是软件工程的一个重要方向，这部分论文可能展示了如何将模型应用于实际系统开发，以提高效率和可维护性。 8. **基于本体的应用程序**：本体在语义网和知识表示中起着核心作用。这些论文可能探讨了本体在信息整合、问答系统或智能决策支持系统中的应用。 "Model and Data Engineering" 作为一本学术出版物，汇集了全球研究者在模型和数据工程领域的最新研究成果，对于相关领域的学者、学生和从业者来说，是了解该领域最新进展和技术创新的重要资源。书中的论文通过严格的同行评审，确保了内容的质量和学术价值，有助于推动模型与数据工程的研究与实践。

4K.H¨olldobler et al.

the problem domains and the solution domains that raises unintended complex-

ities [18]. As a result, Domain-Speciﬁc Languages (DSLs) and Domain-Speciﬁc

Modeling Languages (DSMLs) [48] were created to match domain speciﬁc needs.

Due to the ongoing digitization of virtually every domain in our life, work, and

society, the need for more speciﬁc languages raises. It is apparent, that we need

to be able to accommodate new and changing domains with appropriate domain-

speciﬁc languages – ideally on-the-ﬂy. This raises three questions:

1. How to design new DSLs that ﬁt speciﬁc purposes?

2. How to engineer a DSL from predeﬁned components?

3. How to derive DSLs from other DSLs?

In this paper, we give an overview of the current state of the art on the

design of DSLs, discuss the mechanisms enabling their composition, and describe

how to derive new DSLs from predeﬁned ones, such that we prevent restarting

design of the language from scratch each time, but instead successfully engineer

language from reusable components. These mechanisms to derive and compose

languages are the core of what we today calls software language engineering

(SLE) [32]: the discipline of engineering software languages, which are not only

applied to computer science, but to any form of domain that deals with data,

their representation in form of data structures, smart systems that need control,

as well as with smart services that assist us in our daily life.

The rest of this paper is organized as follows: First, Sect. 2 presents current

language deﬁnition techniques and sketches language creation by example. After-

wards, Sect. 3 introduces language composition techniques and illustrates their

application, before Sect. 4 highlights language derivation techniques. Section 5

presents the case study of modeling a data explorer application leveraging soft-

ware language engineering techniques. Ultimately, Sect. 6 concludes this paper.

2 Language Engineering

Model-driven engineering [18] lifts abstract models to primary development arti-

facts to facilitate software analysis, communication, documentation, and trans-

formation. Automated analysis and transformation of models require that these

adhere to contracts that analyses and transformations can rely upon (and be

developed against). Such automation is feasible, where models conform to mod-

eling languages. For many popular modeling languages, such as UML [22],

AADL [16], or Matlab/Simulink [1], research and industry have produced use-

ful analyses and transformations. These rely on making the constituents and

concerns of languages machine processable. To this eﬀect, the discipline of SLE

investigates disciplined and systematic approaches to the design, implementa-

tion, testing, deployment, use, evolution, and recovery of modeling languages.

Similar to research in natural languages, SLE commonly deﬁnes languages

as the set of sentences they can produce [3]. Operationalizing languages, how-

ever, requires more precise characterizations. To this eﬀect, languages usually

Advances in Modeling Language Engineering 5

are deﬁned in terms of their syntax (possible sentences) and semantics (mean-

ing) [26], which can be concretized to requiring a concrete syntax (words), an

abstract syntax (structure), static semantics (well-formedness), and dynamic

semantics (behavior) for language deﬁnition [3]. The technical realizations of

modeling languages often follow the latter distinction. As “software languages

are software too” [15], their technical realizations are as diverse as other rep-

resentatives of other software categories. This complicates comprehensibility,

maintenance, evolution, testing, deployment, and reuse.

To shed light onto this diversity, this section presents diﬀerent mechanisms

to deﬁne modeling languages and highlights selected language development envi-

ronments employing these mechanisms. Afterwards, we illustrate development

of a language to represent a variant of UML class diagrams that will serve as

running example for the subsequent sections.

2.1 Engineering Modeling Languages

Research has produced various means to develop solutions for representing the

diﬀerent concerns of modeling languages. Lately, two diﬀerent language imple-

mentation techniques have been distinguished:

1. Internal modeling languages are realized as ﬂuent APIs [17] in host program-

ming languages whose method names resemble keywords of the language.

Omitting syntactic sugar (such as dots and parentheses) as supported by

modern programming languages (cf. Groovy, Scala) enables to create chains

of method calls that resemble models. This method is suitable to language

prototyping and yields the beneﬁt of enabling to reuse the host language’s

tooling (such as parsers, editors, compilers, etc.). The expressiveness of the

modeling language depends on the host programming language.

2. External modeling languages feature a stand-alone syntax that requires tool-

ing to process its models into machine-processable representations. While this

creates additional eﬀort over internal languages, external languages can lever-

age a greater language deﬁnition ﬂexibility. However, language-related tooling

must be provided by the language engineer.

The majority of modeling language research focuses on external languages,

which yield greater ﬂexibility in language design. Consequently, research has

produced more solutions to the deﬁnition of external languages, which is why

we focus on their realization techniques in the following.

Engineering language syntaxes historically is related to the development and

processing of (context-free) grammars [33], which are sets of derivation rules that

at least enable describing the languages’ abstract syntaxes. Many approaches

to grammar-driven language engineering also support specifying a language’s

concrete syntax in the same grammar as well [21]; hence, enabling eﬃcient lan-

guage development and maintenance. Metamodels are another popular means to

develop the abstract syntax of languages [48]. Here, classes and their relations

structure the syntax of a language. While these do not support the integration

6K.H¨olldobler et al.

of concrete syntax (and, hence, always require providing editors), they enable

reifying references between model elements that are name-based in grammars,

as ﬁrst level references.

Concrete syntaxes are either textual [34,49], graphical [10], or projec-

tional [48]. Textual and graphical languages both require parsing, whereas pro-

jectional syntaxes (e.g., forms enabling editing the abstract syntax directly [47])

usually are bound to speciﬁc editors. In contrast, textual syntaxes enable to

reuse established software engineering tooling, such as editors or version control

systems.

Whether the well-formedness of models is subject of their syntax or their

static semantics is subject to debate. Nonetheless, various techniques have been

established to enforce the well-formedness of models with respect to properties

that cannot be captured by grammars or metamodels (e.g., preventing to class

members of the same name). Popular approaches to well-formedness checking

are programming language rules and Object Constraint Language (OCL) [40]

constraints. Both require a model’s internal representation and raise errors if

these are not well-formed according to the individual rule. As OCL is a mod-

eling language itself, this requires interpreting it or translating the constraints

to programming language artifacts actually executing the models under devel-

opment.

Executing models is a popular way to realize their dynamic semantics. This

can have the form of interpretation [30] or transformation [6]. With the for-

mer, a software (the interpreter) processes the models and executes according

to their description. This interpreter can be part of the models or a separate

software. Transformations process models and translates these into other for-

malisms with established semantics, such as a programming language. Model-

to-text (M2T) transformations [36] read models of a speciﬁc language and trans-

late these to plain text (such as programming language code), whereas model-

to-model (M2M) transformations [36] translate models from an input modeling

language to an output modeling language. The former lends itself for ad-hoc

transformation development using template engines or string concatenation (as

the output language is not required), but lacks the structure and veriﬁability of

M2M transformations.

Language workbenches [13] are software development environments support-

ing language engineering. Based on an, usually ﬁxed, integration of language deﬁ-

nition constituents, they facilitate creating languages and corresponding tooling.

For instance, GEMOC Studio [5] employs ECore [44] metamodels for abstract

syntax, OCL for static semantics, and Kermeta [30] for weaving interpreta-

tion capabilities into its languages. Concrete syntax can, e.g., have the form

of Xtext [14] grammars or Sirius [46] editors. The meta programming system

(MPS) features projectional language engineering on top of a metamodel and

combines this with well-formedness checking and execution through M2M trans-

formations. The Neverlang language workbench [45] supports grammar-based

language deﬁnition and focuses on combining these with language processing

tools. It executes models via interpretation.

Advances in Modeling Language Engineering 7

The next section illustrates engineering of a textual modeling language for

class diagrams (CDs) with the MontiCore language workbench.

2.2 Language Engineering with MontiCore

MontiCore [34] is a language workbench for eﬃcient development of compo-

sitional modeling languages. The concrete and abstract syntax of languages

are deﬁned as extended context-free grammars and it supports a Java-based

well-formedness checking framework as well as model execution through M2M

and M2T transformations. From the grammars, MontiCore generates parsers

and abstract syntax classes. The parser enables processing textual, conforming

models, into instances of the languages’ abstract syntax classes. Java context

conditions process these instances to check their well-formedness before M2M

transformations [27] or template-based code generators [41]. MontiCore sup-

ports language inheritance, language embedding, and language aggregation [25]

to reuse and combine languages with little eﬀort.

Consider the excerpt of the MontiCore grammar depicted in Fig. 1,which

describes the class diagram for analysis (CD4A) modeling language: After the

keyword grammar and its name, the grammar extends existing types to reuse

previously deﬁned grammars (l. 1). Afterwards, a body of productions follows

that characterize a variant of class diagrams. Each production is deﬁned by a

left-hand-side (e.g., CDDefinition in l. 2) and a right-hand-side, which contains

terminals (e.g., "classdiagram" in l. 2) and non-terminals (e.g., CDInterface in

l. 3). Diﬀerent operators (e.g., * in l. 3, ? in l. 13, and + in l. 15) deﬁne the quan-

tity or presence of a part on the right-hand-side. MontiCore also supports addi-

tional grammar constructs to extend the generated AST (e.g., astimplements

in l. 13).

Fig. 1. An excerpt of a MontiCore grammar for the CD4A language.

With this grammar, the CD4A model shown as an excerpt in Fig. 2 can be cre-

ated. It describes a simpliﬁed banking system consisting of a package declaration

(l. 1); an abstract Account class to describe diﬀerent types of accounts (ll. 3–7);

an interface to model employees (l. 17) and its implementation (ll. 18–20); and

multiple associations (e.g., l. 55). From this grammar, MontiCore produces a

parser and an abstract syntax class for each production. The latter captures the

production’s right hand side by providing members capable of storing its content.

8K.H¨olldobler et al.

Fig. 2. An example of a CD4A model describing a lightweight banking system.

In addition, an infrastructure to check context conditions, which are predicates

deﬁned with respect to the abstract syntax to determine the language’s consis-

tency. For example, to restrict the modiﬁers of classes to abstract only (l. 13

in Fig. 1).

3 Composing Modeling Languages

Model-driven development is successful when initiated bottom-up [50], i.e.,

developers employ modeling languages considered suitable for their challenges

instead of using predeﬁned, monolithic general-purpose modeling techniques.

For their eﬃcient development, evolution, validation, and maintenance, such

languages should be retained as independent as possible. Ultimately, however,

combining such languages mandates their eﬃcient composition [3]. Considering,

for instance, software of the smart and modular factories imagined with Indus-

try 4.0, these demand integrating business processes, domain models, behavior

models and failure models of the automation systems, assembly plan models,

manipulator kinematics, etc. Integrating these modeling languages into a com-

bined software requires operations for their composition.

Software engineering itself is another prime example of a domain leverag-

ing language composition to facilitate development, evolution, and maintenance.

To this eﬀect, research and industry have produced languages for 1. modeling

structure and behavior of the software under development, such as UML [22];

2. describing database interaction, such as SQL [7] or HQL [29]; 3. describing

software build processes, such as Maven’s Project Object Models [37]; 4. describ-

ing conﬁguration of product lines [4], such as feature diagrams [6]; 5. describing

model changes in a structured fashion, such as delta modeling languages [24]6.

extending models with additional, external information (tagging languages [20]);

7. coordinating the use of diﬀerent modeling languages, such as the BCOol lan-

guage [35]; 8. transforming of models of other languages, such as ATL [31]orthe

FreeMarker [39] template language; and 9. describing the syntax and semantics

of modeling languages, such as ECore [44], Kermeta [30], or MontiCore [34].

剩余396页未读，继续阅读

ALo54

粉丝: 5
资源: 111

第七届MEDI会议：模型与数据工程

Engineering Design via Surrogate Modelling: A Practical Guide-1.pdf

Engineeing Design via Surrogate Modelling-A practical guide

Data Engineering

Model-driven engineering

Model based Systems Engineering

Combining Prior Knowledge and Data for Robust Controller Design

model-view qt

Power designer sql server

tell me about how to reprocess data in machine learning

最新资源