=Paper=
{{Paper
|id=Vol-3013/20210142
|storemode=property
|title=Towards On-The-Fly Creation of Modeling Language Jargons
|pdfUrl=https://ceur-ws.org/Vol-3013/20210142.pdf
|volume=Vol-3013
|authors=Ilia Bider,Erik Perjons,Dominik Bork
|dblpUrl=https://dblp.org/rec/conf/icteri/BiderPB21
}}
==Towards On-The-Fly Creation of Modeling Language Jargons==
https://ceur-ws.org/Vol-3013/20210142.pdf
Towards On-The-Fly Creation of Modeling Language
Jargons
Ilia Bider1,2 , Erik Perjons1 and Dominik Bork3
1
Department of Computer and Systems Sciences (DSV), Stockholm University, 164 55 Kista, Sweden
2
Institute of Computer Science, University of Tartu, Estland
3
TU Wien, Business Informatics Group, Favoritenstrasse 11, 1040 Vienna, Austria
Abstract
When designing modeling languages, researchers and practitioners often take contradicting positions.
While the former argue for formal soundness and precise specification, practitioners aim for more flexi-
bility in using a modeling language, i.e., by adapting it to a specific project context. The same distinction
applies to the differentiation between modeling tools and drawing tools. While the former enable model
processing functionality and support modelers in creating only valid models, in practice, too often the
latter tools (e.g., Visio or even PowerPoint) are used due to their ease of use and non-constraining nature.
When aiming to introduce flexibility into modeling languages, one often needs to have metamodeling
knowledge. Besides, changing the metamodel requires re-deployment of tools and hampers compatibil-
ity with previously created models. In this paper, we introduce the notion of modeling language jargons
as a means to countervail these two contradicting positions. With such jargons, on-the-fly adaptation
of modeling languages can be achieved by business users without requiring changes to the metamodel.
To illustrate the conceptualization and use of modeling language jargons we report on the Fractal En-
terprise Model (FEM) language and the experience of using the FEM tool in practice.
Keywords
Modeling language, Flexibility, Fractal Enterprise Model
1. Introduction
This paper has its origin in an ongoing project of designing and using a tool for Fractal Enterprise
Models (FEMs) - the FEM toolkit. A FEM [1] connects an enterprise’s business processes with
assets used in these processes or being managed by them. As a result, the model depicts the
enterprise’s operational activities important for a particular goal, e.g., problem analysis, redesign,
etc. The FEM toolkit is being developed on the metamodeling platform ADOxx [2]. Though
the tool is specialized for FEM and the development is specific to ADOxx, the requirements we
derived from using FEM and first tool prototypes in projects, such as [3, 4] are more general
and can be encountered in other modeling tools being developed for other modeling languages
on other metamodeling platforms – or even without such a platform.
The main source of the challenges that we encountered is connected to the fact that FEM is a
general enterprise modeling technique that can be used for various purposes. Dependent on
ICTERI’21: 17th International Conference on ICT in Education, Research, and Industrial Applications
" ilia@dsv.su.se (I. Bider); perjons@dsv.su.se (E. Perjons); dominik.bork@tuwien.ac.at (D. Bork)
0000-0002-3490-6092 (I. Bider); 0000-0001-9044-5836 (E. Perjons); 0000-0001-8259-2297 (D. Bork)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
the purpose, additional means for expressing particularities of a specific project might emerge.
Adding additional means to a generic language and tool as soon as they are encountered increases
the complexity of the modeling language and impedes its use. This has already happened to
many standardized languages, like BPMN [5, 6], which started with a small set of concepts
aimed at business people, but ended up with hundreds of concepts, many of them too difficult
to understand for non-technical people (see critique in [7, 8, 9]). There exists thus a need to
provide instruments to add additional means to express domain- or project-specific concepts
without overloading modeling languages and tools.
One obvious approach to adapt a modeling language is allowing direct manipulations of
the metamodel and thus, explicitly introduce new concepts related to a particular purpose or
project. This approach is particularly suitable if there is a need to have formal semantics of the
language and its extension, i.e. in order to process the model by built-in algorithms, which is
why most standardized modeling languages allow that (see the stereotyping mechanism for
UML [10] and ArchiMate [11]). However, such changes require metamodeling expertise and
most often also technical skills which modelers usually do not possess. Even if the required
skills would be available, conformance of existing models with the new metamodel cannot be
considered as granted. Eventually, there is a risk that extensions made for one project will
follow to the next one etc. which leads to overarching metamodels and tools that hamper human
comprehensibility and usability of the tool.
In the paper at hand we propose an approach that allows flexible adaptations of modeling
languages to specific contexts without requiring changes to the metamodel. Such adaptations
can be performed by business people and are primarily based on changing the visual appearance
of the shapes representing the language concepts, e.g., as background colors. The interpretation
of the adapted visual appearance are left to the modelers engaged in the project. In essence,
this approach facilitates project and domain-specific modeling language jargons. This approach
obviously has a disadvantage based on the informal convention accepted for the project at
hand. However, this disadvantage is not severe if the models are meant to be interpreted
by people of that project; not by formal algorithms. The contribution this paper aims to
make is well positioned in the ongoing endeavors of the enterprise modeling community to
elevate enterprise modeling for the masses [12, p. 229] where, amongst others, "local practices in
capturing knowledge" and softening "completeness, coherence and rigor requirements to models
and modelling languages in some contexts" are described as necessary steps toward reaching
this goal.
The rest of the paper is organized as follows. Section 2 provides relevant background on
metamodeling and FEM, and introduces the running example. In Section 3, we introduce the
three ways of defining and using modeling language jargons: Subclassing, Ghosting, and Nesting.
The proof-of-concept implementation for the FEM modeling tool is then presented in Section 4.
In Section 5, we briefly refer to related works before we conclude this paper with a summary of
the results achieved so far and an outlook to future research in Section 6.
2. Background
2.1. Metamodeling platforms
Metamodeling platforms are used for the development of modeling tools by raising the abstrac-
tion level to a more elaborate level that aims to be adequate also for non-programmers. This is
achieved by providing pre-configured functionality attached to a generic meta-metamodel. The
method engineer then only needs to adapt this meta-metamodel to her domain. Moreover, engi-
neers can benefit from existing tool developments and reuse/extend existing implementations.
ADOxx [2] is one such metamodeling platform that has been widely used in academia and
industry. The platform comes with a rich set of domain-independent functionality like model
management and user interaction. Method engineers need to: 1) configure the specific meta-
model by referring its concepts to the ADOxx meta-metamodel; 2) define a visualization for the
concepts; 3) combine the concepts into logical chunks, i.e., ADOxx modeltypes; and 4) realize
additional model processing functionality like model transformation or simulation.
Classattribute Attribute Facet
1..1 1..1
0..*
1..n Modeltype
Is subclass-of
0..* 0..* 0..*
0..1 0..* 1..1
0..* Is From-Class 1..1
Modeling Class Relation Class
1..1
0..* Is To-Class 1..1
has
Predefined User-defined Predefined User-defined.
class class Relation Class Relation Class
1..1 1..1 1..1 1..1
1..* 1..* 1..* 1..*
ADOxx 1..* 1..1 User-defined
Metamodel
Metamodel
1..1 1..1 Class hierarchy
1..*
Figure 1: Excerpt of the ADOxx meta-metamodel [13]
An ADOxx-based modeling tool is composed of modeltypes which themselves comprise
predefined and user-defined modeling classes and relation classes (see Fig. 1). Following a graph-
based structure, modeling classes refer to nodes and relation classes to edges between nodes.
Modelers instantiate a modeltype and use the provided classes to create models. Attributes
define the semantics of all ADOxx classes. Amongst, basic attribute types like string and integer,
ADOxx provides interref attributes that allow semantic relationships between modeling class
instances of the same or of different models. The ADOxx meta-metamodel contains generic
concepts and attributes that are inherited to the specific modeling language (e.g. the metamodel
of FEM). These concepts and attributes, for example, the attribute "interref", can be applied by
the modeler without the need to change the metamodel. This is the approach we are applying
when conceptualizing modeling jargons, which will be detailed in forthcoming sections.
2.2. Fractal Enterprise Modeling
In this section, we present the main principles of building Fractal Enterprise Models (FEM) -
more background on FEM can be found in [1, 14]. The basic components of a FEM model are:
business processes, assets, and relationships between them. Fig. 2 shows a fragment of a FEM
model that will be used for explaining the FEM concepts and that introduces the business case
used throughout this paper.
Graphically, a process is represented by an oval, an asset is represented by a rectangle (box),
while a relationship between a process and an asset is represented by an arrow. We differentiate
two types of relationships in FEM. One type represents a relationship of an asset used by a
process; in this case, the arrow points from the asset to the process and has a solid line. The
other type, referred to as affects relationship, represents a relationship of a process changing the
asset; in this case, the arrow points from the process to the asset and has a dashed line. These
two relationship types allow tying up processes and assets in a directed graph. In FEM models,
labels are used to further specify the semantics of the instances, e.g., the names of processes
and assets placed inside the oval and rectangle, respectively. The labels of FEM relationships
indicate the specific relationship type being used. For example, the label acquire identifies that
the process Sales can/should increase the pool size of the asset Stock of manufacturing orders in
Fig. 2.
In FEM, the same asset can be used in multiple processes playing the same or different roles.
Likewise, the same asset may play multiple roles in the same process. Similarly, a process could
affect multiple assets, each in the same or in different ways (see the two relationships between
the Sales process and the corresponding assets in Fig. 2). Moreover, a single process may affect
a single asset in multiple ways. Multiple relationships between assets and processes can be
represented by having two or more labels on the corresponding arrows.
Labels defining the relationships between processes and assets are standardized in FEM.
The method defines eight abstract relation types that further specify the semantics of the
used by: Beneficiary, Workforce, EXT, Partner, Stock, Tech & Info Infrastructure, Organizational
Infrastructure, Means of Payment, and Attraction. Furthermore, three abstract relation types
that describe how an asset is managed by a process exist: Acquire, Maintain, and Retire.
Two new concepts were introduced to FEM in order to represent the business context of the
organization and connect it to specific processes [14]: External pool and External actor. External
pools, visualized by a cloud shape, represent a set of things or agents of a certain type (see the
pool of companies that need the manufacturing products in Fig. 2). External actors, visualized
by a rectangle with rounded corners, represent an agent (e.g., a company or person) acting
outside the boundary of the organization. If a set of external actors shall be represented like the
competitor external agents in Fig. 2, the border of the shape has a double line. External pools
and external actors may be related to each other and to other elements of the FEM diagram.
This concludes the brief introduction to FEM. Readers interested to learn more about FEM
and why it is called fractal are again referred to [1, 14].
Figure 2: Fragment of a FEM for the manufacturing business model
2.3. Running example
To illustrate and discuss our proposal we will be using a running example taken from [15].
The example belongs to the field of Business Model Innovation (BMI), more specifically to
the field of so-called industry level innovation according to the classification from [16]. This
kind of innovation means developing products and/or services that are radically different from
the current ones, and/or entering completely different markets. In the center of the case is a
manufacturing company that uses an expensive equipment (robots) in their manufacturing
process. To make the best use of this equipment, they have developed diagnostic predictive
software. The software is used for deciding when the equipment needs servicing, rather than
relying on the standard recommendations from the maintenance plan. This allows to avoid
unexpected breaks, while increasing intervals between the stops for planned maintenance.
Developing and supporting the software requires having specialists, and other types of
investments. The company decided to explore a way to convert costs to profitable investment
by starting a new business of licensing the software to other manufacturers that use the same
equipment, including their current competitors.
A FEM model of the case company is represented in Fig. 2. The model is not complete, the
purpose is to show how the company currently operates in general, and to show more details
related to the diagnostic predictive software.
3. Modeling Language Jargons
In a modeling project, there often is a need to on-the-fly graphically differentiate elements that
are represented using the same language concept. For example, in a FEM model, one might
need to differentiate physical assets, e.g., computers, from the virtual assets, e.g., electronic
documents or IT systems. Another recurring need we experienced in many FEM modeling
projects is that modelers want to reuse already modeled elements inside the same, or even in a
different FEM model. Eventually, a need for nesting was ubiquitous, i.e., modelers wanted to
specify enterprises on different levels of granularity.
As one approach to tackle the three modeling needs stressed previously, the paper at hand
introduces the notion of modeling language jargons. The Oxford dictionary defines ’jargon’
as: "words or expressions that are used by a particular profession or group of people, and are
difficult for others to understand" [17]. The Cambridge dictionary defines jargon as: "the special
slang of a particular group of people" and "special words or phrases used within a group, trade or
profession" [18].
A modeling language jargon thus provides additional means for those knowledgeable in the
specific terms and their meanings while at the same time hampering the comprehension by
a wider, unknowledgeable audience. Such a jargon is specific to a modeling project and the
involved stakeholders and is expected to change when starting a new modeling project in a new
context. In the following, we introduce three approaches for enabling project-specific modeling
language jargons that all do not require any metamodel changes. We will refer to and further
extend the FEM example depicted in Fig. 2 to exemplify the use of modeling language jargons
in FEM.
3.1. Subclassing
The aim of the Subclassing approach is to enable modelers to on-the-fly introduce more specific
semantics to the concepts provided by the FEM metamodel (e.g., Process and Asset). In a business
model innovation project, like the one in our running example, the modelers could be interested
to distinguish automated processes from manual processes, or to distinguish processes and
assets that need to be introduced to realize a new business model.
The only requirement for creating subclasses of the existing language concepts in such cases
is to have a unique visual representation of each subclass. A simple enough way for such
visualization would be assigning a specific background color to each subclass. In this respect, all
subclasses still use the same shape, e.g., an ellipsis for FEM processes, but allow the identification
of an individual subclass based on its unique background color. This differentiation is related to
the type and inherent semantics dichotomy introduced in [19] where the metamodel concept
defines the type semantics (e.g., what is the semantics of a process in FEM) and the labels of
the process instances further specify the instance semantics (e.g., what is a primary process in
Fig. 3).
Fig. 3 shows a set of potential subclasses for the new business model in our running business
model innovation example. Labels inside the shape define the semantics of each subclass for the
project. Most colors are already used in Fig. 2 to identify which elements of the FEM model are
intended to be introduced when designing a new business, the red color will appear in Fig. 4
and explained subsequently.
Figure 3: Subclasses defined for the case
3.2. Ghosting
Inspiration for the ghost concept was derived from a tool called InsightMaker [20], where it
was introduced to solve the problem of a model becoming cluttered if too many connections
are made to the same element. In InsightMaker, a ghost is a copy of an already existing element
in the same model. Ghosts can be distinguished from their original by the use of a lighter
background color.
Our extended notion of ghosts in modeling language jargons comprises the following three
aspects:
• Usage across models, i.e., ghosts can relate to original elements in the same or in a different
FEM model of the same modeling project. In Fig. 4, we have a number of ghosts that
relate to elements that were introduced in Fig. 2 (like Software development process and
Service technicians asset).
• Navigation, i.e., allowing to find all usages of a given FEM element starting from a ghost,
or the original.
• Visual distance, i.e., ghosts need to be distinguishable from the original shape, but this is
not constrained by relying on the background color.
Figure 4: Fragment of a FEM that shows the new business models with many ghost elements relating
to the elements proposed in the existing business model (see Fig. 2)
While subclassing adds a vocabulary to a jargon, the extended ghosting approach allows
modelers to add specific modeling styles to the jargon. Ghosting, for example, can be used to
create model views and visual repositories without introducing these concepts in the language.
Fig. 3 and Fig. 4 demonstrate a usage of extended ghosting in the business model innovation
project. First, one builds a model of the current business and marks elements that can potentially
be used in a new business. Then one moves the identified elements as ghosts to another model,
adds new nodes and configures a new business model. Note that in Fig. 4, we use an additional
subclass from Fig. 3 - the two elements with red background color - to mark the transitional
(temporal) processes in the model.
The extended ghosting approach thus not only supports reuse of existing model elements,
enabling the modeler to on-the-fly create a repository of elements, it also enables rearrangement
of model elements in a more comprehensible way by reducing long-distance and crossing
relationships by simply adding an additional ghost element at the position the original element
would be required.
3.3. Nesting
Quite often, a modeler needs to use different levels of granularity when creating an enterprise
model. For a high-level overview, the granularity will be coarse, while a view on the detailed
aspects of a particular part of the business requires a finer level granularity. There needs to
be a way to relate models on different granularity levels. For example, a business process
that is depicted as one entity in one model may need to be related to an interconnected set
of subprocesses in a more detailed model. Some languages, like IDEF0 and BPMN, introduce
the concept of decomposition with strict semantics. Other languages, including FEM, may not
introduce the concept explicitly, but the practice often needs some means for decomposition.
The semantics of the decomposition may vary from project to project. In one case, the
decomposition may mean variants of the same thing, which is considered as specialization in
some modeling languages, like UML. In other cases, the decomposition may mean depicting
smaller elements and their interconnections that together makes the decomposed elements.
There can be other alternatives of the decomposition concept as well. Instead of introducing
the concept explicitly with all its variants, we suggest to use visual means that allow to present
decomposition on-the-fly without introducing strict semantics. The semantics in this case,
should be understood from the decomposition itself, or be agreed upon inside the project group.
We suggest using nesting in combination with the extended ghosts approach to represent a
decomposition. This is illustrated in Fig. 5, which shows the decomposition of the Sales process
from Fig. 2. The decomposed process is presented as special type of ghosts – group ghost, and it
comprises two new processes, Sales to existing customers and Sales to new customers. To show
the connection between the new processes and other elements of the model from Fig. 2, ghosts
of the connected elements are presented in the new model. The decomposition in this example
is of specialization type, a further type is referred to as subprocess type, where the decomposed
elements are also connected inside the group. The ghosts navigation facilitates easy movement
from the decomposed element to the model that depicts the decomposition and back. Nesting
thus enables modelers to create new styles in a modeling language jargon on-the-fly.
4. Modeling Langauge Jargons for FEM
As a Proof of Concept (PoC) we will report in the following on the conceptualization of modeling
language jargons in a concrete case: the Fractal Enterprise Modeling (FEM) [1, 14]. We will
present and discuss the realization of the FEM modeling tool which runs as a project within
the Open Models Laboratory (OMiLAB) [21]. Albeit the specific case, the conceptualization
itself will be described in a way that shall enable not only comprehension but also facilitate
the implementation of modeling language jargons in other modeling tools. Please note, that
the conceptualization requires technical knowledge and only needs to be done once, while the
Figure 5: FEM fragment showing the nested Sales process (specialization type).
definition of arbitrary modeling language jargons can be done on-the-fly by business users
without any further changes to the implementation or metamodel.
4.1. Conceptualization of Subclassing
For the conceptualization of Subclassing in the FEM tool we introduced an additional modeltype:
FEM Subclassing which complements to conventional FEM modeltype one would use to create
FEM models as the one in Fig. 2. The new modeltype basically acts as a repository of all
subclasses of all FEM modeling classes. Modelers can instantiate FEM processes or assets and
thereby define a new subclass of that type which can be used on-the-fly in all other FEM models
that form part of the current modeling project. When creating a new subclass, the modeler can
specify its properties (like the name) and its appearance.
When aiming to use a subclass, FEM modelers are assisted by a smart menu that lists all
existing subclasses of the current project defined in the FEM Subclassing model. As soon as
the modeler selected a subclass a reference is stored in the properties of the subclass and the
appearance of the subclass is automatically propagated to the newly linked subclass, thereby
replacing the default appearance. When removing the subclassing reference, the element is
automatically returning to its default appearance. Likewise, synchronization has been realized
to make sure that changes in the appearance of the subclass in the FEM Subclassing model are
propagated to all referenced subclasses in all other FEM models of a modeling project.
Fig. 6 shows the use of the Subclassing approach. After opening the properties of a new
Process element, modelers can select ’Subclass’ in the Color Picker property (see number 2 in
Fig. 6). An automatically generated dialog then lists all applicable subclasses for the Process.
After the modeler selected one subclass, the representation of the subclass (in this case a red
background color defined in Fig. 3) is automatically propagated to the new Process. In the
shown example, the process on the right is now further specified as being a transitional process.
Figure 6: Conceptualization of the Subclass approach in the FEM tool
For the project participants, the subclassing model in Fig. 4 presents a convention on which
they agree. It can also be viewed as an agenda, or vocabulary of the project’s jargon. The
scope of the jargon is a group of models that share the jargon, i.e. the same subclassing model.
Consequently, any FEM modeling project will have one Sublcassing model and multiple FEM
models.
4.2. Conceptualization of Ghosting
The conceptualization of ghosting in the FEM modeling tool is primarily realized by an Interref
attribute that is available for all FEM metamodel concepts. With this Interref, the modeler
is enabled to link a selected FEM instances to an already existing instance of the same type
in the same model or in a different model of the same modeling project. Similarly to the
Subclass procedure introduced previously, the conceptualization of ghosting is build on two
major functions: a smart menu that supports the modeler in selected an appropriate original,
and automated adaptation of the graphical representation of the ghost instance. Consequently,
the appearance of the ghost instance is automatically adopting the appearance defined in the
linked original element. Noteworthy, for ghosts, the synchronization between original and
ghost also concerns other attribute values like the name. If the modeler changes the name of
the original, the new name is propagated and all ghost instances are updated automatically
thereby keeping all FEM models in a consistent state [22].
In order to support comprehensibility of large FEM modeling projects that might require
many FEM models, the FEM tool also comes with some processing functionality that enable
the modeler to efficiently list all ghost instances of a selected original in the current model as
well as in all other models of the FEM modeling project. When executing this functionality
an algorithm queries all FEM models to find the usage of the selected element as ghost and
provides a list that has a navigable link to the specific model and element. The modeler thus
only needs to click on an entry on the list of ghosts to navigate to its usage. Fig. 7 shows the
navigable list generated as a result of executing the ’find usage in all FEM models’ functionality
on the process Software maintenance. The list shows three usages of this element in three FEM
models.
Figure 7: Conceptualization of the Ghosting approach in the FEM tool
4.3. Conceptualization of Nesting
The Nesting approach is conceptualized also on the FEM metamodel level and allows its on-the-
fly use by modelers in any FEM modeling project. All FEM concepts provide an attribute that
qualifies them for being a group or not. By changing the attribute value, the appearance of the
selected element automatically changes, e.g., from a solid border line and a strong background
color to a dashed border line and light background color. This change is exemplified when
comparing the Sales process in Fig. 2 with the Sales nesting visualized in Fig. 5.
As introduced in Section 3.3, grouping can also be applied to ghosts. Again, the example of
Fig. 5 can be referred to where Sales is not only a ghost (visually encoded by the dashed border
and the light color) but also a ghost of the original Sales process in Fig. 2 (visually encoded by
the arrow on the top right corner that would navigate the modeler to its original when being
clicked).
Table 1
Contrasting modeling language jargon from profiling/stereotyping
Criteria Modeling Language Jargon Profiling / Stereotyping
Adaptation role Modeler Method engineer
Adaptation point Model Metamodel
Adaptation scope Notation Syntax
Adaptation time on-the-fly ex-ante
Adaptation effect Expressivity and processing ⇑ Expressivity ⇑
5. Related works
The intention to introduce flexibility in modeling methods is not new in itself (cf. [5, 23, 24, 12,
25, 9, 26]). In the following, we will briefly elaborate on the most relevant related works in order
to position modeling language jargons within the state of the art. Afterwards, we conclude the
paper with a summary of its contribution and future research directions.
FlexiSketch is a very interesting approach comprehensively introduced in [25]. With FlexiSketch
modelers are able to sketch models and automatically transform their model sketches into a
metamodel and a corresponding modeling tool. In contrast to our approach, FlexiSketch primar-
ily focuses on sketching new elements and designing the metamodel on-the-fly. This approach
comes with promising possibilities while the problems of e.g., ever increasing metamodel size
with every new modeling project and interoperability remain.
The AOAME approach proposed in [27] aims to enable business people with domain knowl-
edge to adapt the modeling language to specific project contexts. AOAME binds a modeling
language to an ontology that provides clear, unambiguous, and machine-interpretable seman-
tics. This ontology can then be adapted on-the-fly thereby enabling the modeler to introduce
context-specific semantics. Apart from the fact, that AOAME puts the ontology at the heart
and users should have basic knowledge in ontology engineering, users can remove unnecessary
concepts which is in conflict to our goal of retaining conformance to the core modeling language.
In contrast to the previously mentioned, existing, stereotyping and UML profiling [10, 11]
approaches, modeling language jargons aim to be usable by business users that don’t have any
technical skills. Jargons are defined on-the-fly during the modeling process in the modeling tool
instead of ex-ante implementation on the metamodel backbone as for stereotypes and profiles.
Moreover, we propose means to navigate inside and between the models in order to find jargon
usages in whole corpora of created models. Table 1 further contrasts our proposed modeling
language jargon from profiling and stereotyping.
6. Conclusion
In the paper at hand we propose the notion of modeling language jargons, a means to on-the-
fly adapt modeling languages to specific contexts. Key to our approach is that the language
adaptations don’t involve any changes to the metamodel, as such they can be performed
by regular modelers, and the fact, that the created models are still valid according to the
underlying modeling language. The three approaches forming part of modeling language
jargons, Subclassing, Ghosting, and Nesting are introduced on a generic level.
The three approaches listed above are fully implemented in version 0.7 of the FEM toolkit,
which is publicly available for download and test1 . The toolkit has already been used in two
practical projects. The first project was completed at Tartu Water Utility company; it was aimed
at designing a new digitalization strategy at a company with an outdated IT systems park, as
well as creating more detail requirements for completing the first step of the strategy. The FEM
toolkit was successfully used in many tasks of this complex project, including understanding of
how the company operated, developing "as-is" and "to-be" models, tying them together via the
ghosting feature, and marking changes via the subclassing feature.
The second project’s practical goal was to suggest improvements for a so-called sourcing
process in an international concern. The sourcing project aimed at signing long-term purchasing
contracts for all branches of the concern. The project employed all three features introduced
in this paper. Analysis of the produced FEM diagrams resulted in a number of suggestions for
process improvements.
Besides testing in practical projects, the FEM toolkit was employed in teaching enterprise
modeling at University of Tartu. We experienced, that the students had no problems in under-
standing the features discussed in this paper, as they successfully used them when completing
project and exam assignments.
The results of testing our suggestions implemented in FEM toolkit are quite encouraging,
although a comprehensive empirical evaluation, e.g., with respect to ease of use, usability, and
comprehensibility of the resulting models is on a route we plan to follow in our future research.
It will be interesting to see, how the gains in flexibility might influence comprehensibility. One
could imagine that by adding additional semantics, the models are more expressive while on
the other hand adding several different appearances for the same concept might result in an
increase of cognitive load [28, 29].
Another important part of future research is to investigate transferability of the modeling
language jargon to other modeling tools. We thus hope this paper motivates the modeling
community to gain interest in our concept and the combined generic and case-based introduction
of the concept eases the implementation of it for other modeling tools. Eventually, we see the
possibility that metamodel platform vendors would be interested in ideas that enable a balance
between flexibility and context-adaptability on the one hand, and conformity to a formally
defined metamodel on the other. Implementing the modeling language jargon concept in a way
such that modeling tool developers only need to define the metamodel concepts they want it to
be enabled for seems feasible.
In the practical terms, we are working on the next version of FEM toolkit (0.8) with an
additional classification option, which will be orthogonal to the existing subclassing, and which
will have visualization via coloring the shapes’ borders. This kind of classification might be
useful in multi-organizational contexts of the type discussed in [3]. Another feature that is
considered for the new version is allowing the usage of several subclassing forms along with a
switching mechanism to have several, mutually exclusive perspectives on the same FEM diagram.
1
FEM tool: https://www.fractalmodel.org/fem-toolkit/, last visited: 09.07.2021
Acknowledgement: The authors are very grateful to Steven Leego, Erik Falenius and August
Carlsson who independently tested the FEM toolkit in practical projects. The work of the second
author was partly supported by the Estonian Research Council (Grant PRG1226).
References
[1] I. Bider, E. Perjons, M. Elias, P. Johannesson, A fractal enterprise model and its application
for business development, Software & Systems Modeling 16 (2017) 663–689.
[2] ADOxx.org, Official homepage of the ADOxx meta-modeling platform, 2021. http://adoxx.
org, last visited: 10.03.2021.
[3] M. Henkel, G. Koutsopoulos, I. Bider, E. Perjons, Using the fractal enterprise model for
inter-organizational business processes, in: Proceedings of the ER Forum and Poster &
Demos Session co-located with 38th International Conference on Conceptual Modeling
(ER 2019), volume 2469 of CEUR Workshop Proceedings, 2019, pp. 56–69.
[4] V. Klyukina, I. Bider, E. Perjons, Does fractal enterprise model fit operational decision
making?, in: J. Filipe, M. Smialek, A. Brodsky, S. Hammoudi (Eds.), Proceedings of the
23st International Conference on Enterprise Information Systems, ICEIS 2021, Volume 2,
SciTePress, 2021, pp. 525–533.
[5] C. Atkinson, R. Gerbig, M. Fritzsche, Modeling language extension in the enterprise
systems domain, in: 2013 17th IEEE International Enterprise Distributed Object Computing
Conference, IEEE, 2013, pp. 49–58.
[6] R. Braun, Towards the state of the art of extending enterprise modeling languages, in: 2015
3rd International Conference on Model-Driven Engineering and Software Development
(MODELSWARD), IEEE, 2015, pp. 1–9.
[7] J. Recker, Opportunities and constraints: the current struggle with bpmn, Business Process
Management Journal (2010).
[8] M. zur Muehlen, J. Recker, How much language is enough? theoretical and practical use
of the business process modeling notation, in: J. A. B. Jr., J. Krogstie, O. Pastor, B. Pernici,
C. Rolland, A. Sølvberg (Eds.), Seminal Contributions to Information Systems Engineering,
25 Years of CAiSE, Springer, 2013, pp. 429–443.
[9] E. Van Wyk, M. P. E. Heimdahl, Flexibility in modeling languages and tools: A call to arms,
International journal on software tools for technology transfer 11 (2009) 203–215.
[10] L. Fuentes-Fernández, A. Vallecillo-Moreno, An introduction to uml profiles, UML and
Model Engineering 2 (2004) 72.
[11] M. M. Lankhorst, A. Aldea, J. Niehof, Combining archimate with other standards and
approaches, in: Enterprise Architecture at Work, Springer, 2017, pp. 123–140.
[12] K. Sandkuhl, H.-G. Fill, S. Hoppenbrouwers, J. Krogstie, A. Leue, F. Matthes, A. L. Opdahl,
G. Schwabe, Ö. Uludag, R. Winter, Enterprise modelling for the masses–from elitist
discipline to common practice, in: IFIP Working Conference on The Practice of Enterprise
Modeling, Springer, 2016, pp. 225–240.
[13] D. Bork, Metamodel-based Analysis of Domain-specific Conceptual Modeling Methods,
in: R. A. Buchmann, D. Karagiannis, M. Kirikova (Eds.), IFIP Working Conference on The
Practice of Enterprise Modeling, Springer, 2018, pp. 172–187.
[14] I. Bider, Structural coupling, strategy and fractal enterprise modeling, in: International
Conference on Research Challenges in Information Science, Springer, 2020, pp. 95–111.
[15] I. Bider, A. Lodhi, Moving from manufacturing to software business: A business model
transformation pattern, in: International Conference on Enterprise Information Systems,
Springer, 2019, pp. 514–530.
[16] E. Giesen, S. J. Berman, R. Bell, A. Blitz, Three ways to successfully innovate your business
model, Strategy & Leadership 35 (2007) 27–33.
[17] Oxford Learner’s Dictionary, Defition of the term ’jargon’, 2021. https://www.
oxfordlearnersdictionaries.com/definition/english/jargon, last visited: 17.03.2021.
[18] Cambridge Dictionary, Defition of the term ’jargon’, 2021. https://dictionary.cambridge.
org/dictionary/french-english/jargon, last visited: 17.03.2021.
[19] P. Höfferer, Achieving business process model interoperability using metamodels and
ontologies, in: H. Österle, J. Schelp, R. Winter (Eds.), Proceedings of the Fifteenth European
Conference on Information Systems, ECIS 2007, St. Gallen, Switzerland, 2007, University
of St. Gallen, 2007, pp. 1620–1631.
[20] https://insightmaker.com/, Official homepage of Insightmaker, 2021. https://insightmaker.
com/, last visited: 22.03.2021.
[21] D. Bork, R. A. Buchmann, D. Karagiannis, M. Lee, E.-T. Miron, An Open Platform for
Modeling Method Conceptualization: The OMiLAB Digital Ecosystem, Communications
of the Association for Information Systems 44 (2019) pp. 673–697.
[22] D. Bork, R. Buchmann, D. Karagiannis, Preserving multi-view consistency in diagram-
matic knowledge representation, in: International Conference on Knowledge Science,
Engineering and Management, Springer, 2015, pp. 177–182.
[23] M. Bjeković, H. A. Proper, J.-S. Sottet, Embracing pragmatics, in: International Conference
on Conceptual Modeling, Springer, 2014, pp. 431–444.
[24] D. Bork, S. Alter, Satisfying four requirements for more flexible modeling methods: Theory
and test case, Enterprise Modelling and Information Systems Architectures (EMISAJ) 15
(2020) 3–1.
[25] D. Wüest, N. Seyff, M. Glinz, Flexisketch: a lightweight sketching and metamodeling
approach for end-users, Software & Systems Modeling 18 (2019) 1513–1541.
[26] Z. Zarwin, M. Bjekovic, M. Favre, J.-S. Sottet, H. A. Proper, Natural modelling, Journal of
Object Technology 13 (2014) 4:1–36.
[27] E. Laurenzi, K. Hinkelmann, A. Van der Merwe, An agile and ontology-aided modeling
environment, in: IFIP Working Conference on The Practice of Enterprise Modeling,
Springer, 2018, pp. 221–237.
[28] D. L. Moody, Cognitive load effects on end user understanding of conceptual models:
An experimental analysis, in: A. Benczúr, J. Demetrovics, G. Gottlob (Eds.), Advances in
Databases and Information Systems, Springer Berlin Heidelberg, 2004, pp. 129–143.
[29] S. Yusuf, H. Kagdi, J. I. Maletic, Assessing the comprehension of uml class diagrams via eye
tracking, in: 15th IEEE International Conference on Program Comprehension (ICPC’07),
IEEE, 2007, pp. 113–122.