2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)

2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C) | 978-1-6654-2484-4/21/$31.00 ©2021 IEEE | DOI: 10.1109/MODELS-C53483.2021.00090

DoMoBOT: An AI-Empowered Bot for Automated

and Interactive Domain Modelling
Rijul Saini Gunter Mussbacher Jin L.C. Guo Jörg Kienzle
Dept. of ECE Dept. of ECE School of Computer Science School of Computer Science
McGill University McGill University McGill University McGill University
Montréal, QC, Canada Montréal, QC, Canada Montréal, QC, Canada Montréal, QC, Canada
[email protected] [email protected] [email protected] [email protected]

Abstract—Domain modelling transforms informal require- for automated domain modelling is advantageous to quickly
ments written in natural language in the form of problem prototype a domain model for the given problem description.
descriptions into concise and analyzable domain models. As
However, extracted domain models using current approaches
the manual construction of these domain models is often time-
consuming, error-prone, and labor-intensive, several approaches represent only one solution for a given modelling scenario.
already exist to automate domain modelling. However, the current This inhibits modellers to gain insights into other possible
approaches suffer from lower accuracy of extracted domain solutions which may further leave problem descriptions impre-
models and the lack of support for system-modeller interactions. cise. For instance, the extracted model uses the Enumeration
To better assist modellers, we introduce DoMoBOT, a web-based
solution to model categories. The presentation of the other
Domain Modelling BOT. Our proposed bot combines artificial
intelligence techniques such as natural language processing and solution (Generalization) can indicate to a modeller that more
machine learning to extract domain models with higher accuracy. information about the categories needs to be added in the
More importantly, our bot incorporates a set of features to problem description if categories are to be modelled only
bring synergy between automated model extraction and bot- by the Generalization solution, i.e. when categories exhibit
modeller interactions. During these interactions, the bot presents
different characteristics (attributes or associations). Further-
multiple possible solutions to a modeller for modelling scenarios
present in a given problem description. The bot further enables more, manually updating the Enumeration solution to the
modellers to switch to a particular solution and updates the Generalization in the extracted domain model defeats the
other parts of the domain model proactively. In this tool demo whole purpose of automated domain modelling. Therefore, we
paper, we demonstrate how the implementation and architecture argue that synergy is required between automated support and
of DoMoBOT support the paradigm of automated and interactive
system-modeller interactions to better assist modellers.
domain modelling for assisting modellers.
Index Terms—Domain Models, Natural Language (NL), Ma- In our previous work, we combine natural language process-
chine Learning (ML), Bot, Model Extraction, Recommendation, ing (NLP) and machine learning (ML) techniques to extract
Bot-Modeller Interactions, Traceablity Knowledge Graph domain models of high accuracy [1], [2], [3]. In addition,
we propose a Traceability Information Model to trace domain
I. I NTRODUCTION modelling decisions taken by our extractor system [4]. In this
During requirement analysis or early stages of design, tool demo paper, we present our web-based domain modelling
domain modelling transforms informal requirements (domain bot, DoMoBOT, with the main focus to demonstrate how the
problem descriptions) expressed in natural language (NL) into architecture and implementation of DoMoBOT facilitate bot-
concise and analyzable domain models. These models capture modeller interactions. The rest of the paper is organized as
the key concepts of a domain in the form of classes, attributes, follows: Section II presents an overview of our proposed bot
relationships, and cardinalities (class diagrams). Constructing and its architecture. Sections III explains our tool’s capabilities
these domain models manually is time-consuming, error- in the context of possible bot-modeller interactions. Section IV
prone, and labor-intensive, particularly for large problem de- describes existing tools that are similar to ours and explains
scriptions. Therefore, several approaches already exist to au- how our tool is different from them. Finally, Section V
tomate the construction of these domain models for the given highlights ongoing and future work.
problem descriptions. However, the extracted models from
these approaches suffer from low accuracy. Furthermore, these II. OVERVIEW OF D O M O BOT
approaches lack the support of system-modeller interactions. The architecture of our proposed bot is composed of various
Motivating Scenario: Domain modelling scenarios can be components, as shown in Figure 1. The bot has a Frontend
often modelled in multiple ways. For example, the scenario that provides the User Interface. The Frontend is developed
“Products have two categories - commodity and premium”, can using the React JS and GOJS frameworks (see Figure 1).
be modelled using the Generalization solution (the categories The Backend of our bot is developed using the Python
are modelled as sub-classes) or the Enumeration solution (the programming language and composed of Model Extraction,
categories are modelled as enumeration items). The support Recommendation, and Query-Answering Components in addi-

978-1-6654-2484-4/21/$31.00 ©2021 IEEE 595

DOI 10.1109/MODELS-C53483.2021.00090
Authorized licensed use limited to: Sri Sai Ram Engineering College. Downloaded on November 19,2024 at 08:28:50 UTC from IEEE Xplore. Restrictions apply.
 3UHWUDLQHG
$8VHU,QWHUIDFH %0RGHO([WUDFWLRQ&RPSRQHQW 0/0RGHOV (.QRZOHGJH%DVH
'HVFULSWLYH 3UHGLFWLYH
3UREOHP 0RGHO 0RGHO *OR9H
'HVFULSWLRQ 'HVFULSWLYH 3UHGLFWLYH 3UHVFULSWLYH (PEHGGLQJV
%R[ 'RPDLQ 0RGHOOLQJ 0RGHOOLQJ 0RGHOOLQJ 0/
3UREOHP 7UDLQLQJ
'HVFULSWLYH 3UHGLFWLYH 3UHVFULSWLYH 'DWD
'HVFULSWLRQ
7UDFH0RGHO 7UDFH0RGHO 7UDFH0RGHO
1DWXUDO 7UDFH
/DQJXDJH 0RGHOV
3UHVFULSWLYH ,QGXFHG
0RGHO &KDQJHV 3UHWUDLQHG
*OR9H
'RPDLQ0RGHO 'RPDLQ &5HFRPPHQGDWLRQ&RPSRQHQW (PEHGGLQJV

%R[ 0RGHO
$FWLRQV 6WUDWHJ\ &RQILJXUDWLRQV
&DWHJRUL]DWLRQ 3UHSDUDWLRQ 3UHSDUDWLRQ
5$6$
0RGHOOHU $FWLRQ 6WUDWHJLHV 3RVVLEOH 1/8
$FWLRQV &DWHJRU\ &RQILJXUDWLRQV

7ULJJHUHG 5HTXHVW
&KDW ,QWHQW 5HVSRQVH
:LGJHW 5$6$1/8  &
%RW 
6XJJHVWLRQV '4XHU\$QVZHULQJ&RPSRQHQW 
3UHGLFWHG , '
7UDFH4XHU\ /
,QWHQW ,QWHQWV $FWLRQV
&ODVVLILFDWLRQ ([HFXWLRQ
0HVVDJHV 7UDFHDELOLW\
1DWXUDO *HQHUDWHG *HQHUDWHG 7UDFH .QRZOHGJH*UDSK
/DQJXDJH 0HVVDJH 4XHU\ 5HVXOWV

5HIHUHQFHV
ϭ͘ZĞĂĐƚ;ŽŵƉŽŶĞŶƚͿͲ ŚƚƚƉƐ͗ͬͬƌĞĂĐƚũƐ͘ŽƌŐͬ ϲ͘ ũĂŶŐŽ;ŽŵƉŽŶĞŶƚƐ͕͕͕͕ĂŶĚͿͲ ŚƚƚƉƐ͗ͬͬǁǁǁ͘ĚũĂŶŐŽƉƌŽũĞĐƚ͘ĐŽŵͬ
Ϯ͘^ƉĂLJ ;ŽŵƉŽŶĞŶƚƐĂŶĚͿ Ͳ ŚƚƚƉƐ͗ͬͬƐƉĂĐLJ͘ŝŽͬ ϳ͘ WLJƚŚŽŶ;ŽŵƉŽŶĞŶƚƐ͕͕͕ĂŶĚͿͲ ŚƚƚƉƐ͗ͬͬǁǁǁ͘ƉLJƚŚŽŶ͘ŽƌŐͬ
ϯ͘ 'K:^;ŽŵƉŽŶĞŶƚͿͲ ŚƚƚƉƐ͗ͬͬŐŽũƐ͘ŶĞƚͬůĂƚĞƐƚͬŝŶĚĞdž͘Śƚŵů ϴ͘ ^ĐŝŬŝƚͲůĞĂƌŶ;ŽŵƉŽŶĞŶƚͿͲ ŚƚƚƉƐ͗ͬͬƐĐŝŬŝƚͲůĞĂƌŶ͘ŽƌŐͬƐƚĂďůĞͬ
ϰ͘ 'ůŽsĞ ʹ ;ŽŵƉŽŶĞŶƚͿͲ ŚƚƚƉƐ͗ͬͬŶůƉ͘ƐƚĂŶĨŽƌĚ͘ĞĚƵͬƉƌŽũĞĐƚƐͬŐůŽǀĞ ϵ͘ ,ĞƌŽŬƵůŽƵĚ;ŽŵƉŽŶĞŶƚƐ͕͕͕͕ĂŶĚͿͲ ŚƚƚƉƐ͗ͬͬǁǁǁ͘ŚĞƌŽŬƵ͘ĐŽŵͬ
ϱ͘ EĞŽϰũ;ŽŵƉŽŶĞŶƚͿͲ ŚƚƚƉƐ͗ͬͬŶĞŽϰũ͘ĐŽŵͬ

Fig. 1. Architecture of DoMoBOT.

tion to the Knowledge Base. The Django framework integrates merged to generate a domain model and their meta-data is
our Frontend and Backend. We further plan to deploy our bot transformed into a Traceability Knowledge Graph.
on the Heroku cloud as a web-based service. Excluding all Descriptive Modelling: We call this step descriptive be-
external libraries, the bot is approx. ≈ 4500 lines of source cause it abstracts a given Problem Description written in NL
code. In this section, we explain the architecture of our bot and captures only the relevant domain concepts in the form
using a small problem description of an Employees Manage- of classes, attributes, relationships, and cardinalities. In the
ment System (P DEM S ): Employees are assigned to multiple Descriptive Modelling step, we use spaCy library (see Fig-
projects. Each project has a project ID and title. Employees ure 1) to extract linguistic features, e.g., part-of-speech (POS)
can be temporary employees or permanent employees. tags and lemmatized form of each word entity in the Problem
Description. These linguistic features are then processed with
A. User Interface our rule-based NLP to extract candidate domain concepts
Our proposed bot provides an intuitive user interface to the and their relationships [1]. In addition, for relationships and
modeller for performing various functions. First, a modeller cardinalities, we compute semantic similarity scores between
can write a problem description in NL in the Problem Descrip- identified entities and a pre-defined list of sample word tokens
tion Box. This problem description is then processed in the for each relationship (e.g., association and attributes) and
Model Extraction Component. Second, an extracted domain cardinality (e.g., zero-to-one and zero-to-many). For example,
model is visualized in the Domain Model Box. The bot also for the first sentence of P DEM S , the “assigned” entity gets
allows modellers to update the extracted model in this box. a maximum score in the association relationship list. The
All the changes are collected and processed in the Recom- extracted concepts and their relationships are represented by
mendation Component. Finally, bot-modeller communications the Descriptive Model, while their meta-data such as POS tags
take place inside the Chat Widget. These communications are represent the Descriptive Trace Model.
further processed in the Query Answering Component. Predictive Modelling: We call this step predictive as its
objective is to improve the Descriptive Model based on the pre-
B. Model Extraction Component dictions of Pre-trained ML Models from the Knowledge Base.
The bot extracts domain models from the given problem The information in the problem description is often not suffi-
descriptions by combining NLP and ML techniques. Different cient to model some necessary domain concepts. For example,
models and their meta-data are generated across the various the concepts “id” and “title” from the second sentence of
stages of the model extraction process. These models are then P DEM S are often modelled as attributes with types “Integer”

596

Authorized licensed use limited to: Sri Sai Ram Engineering College. Downloaded on November 19,2024 at 08:28:50 UTC from IEEE Xplore. Restrictions apply.
and “String”, respectively. However, the information about example, a modeller’s action to change the type of attribute
their types is usually not present in a problem description. To “id” from “Integer” to “String” falls into the Attributes -
address these scenarios, we use GloVe word embeddings [5] to Update Type category. Similarly, we create other categories for
capture the context information of participating concepts. For potential actions which could be performed by a modeller [6].
the classification of concepts, relationships, and cardinalities, The output from this step is the Action Category.
we use the techniques proposed in our previous work [1], Strategy Preparation: Based on each Action Category, one
[2], [3]. The prediction results represent the Predictive Model, or more Strategies are identified to create the Bot Suggestions
while their meta-data such as probability scores represent the followed by the Induced Changes to update the Prescriptive
Predictive Trace Model. Model and Domain Model. For example, a modeller’s action of
Prescriptive Modelling: We call this step prescriptive as removing a class from the extracted model (Class - Remove ac-
it merges the Descriptive and Predictive Models and makes tion category), prepares a strategy for the bot response. In this
decisions for the domain model to be generated. In this step, strategy, the bot starts a search for alternative configurations
we use our proposed algorithms [3] to resolve the conflicts for the associated decision point, which are closest to the new
while merging the Descriptive and Predictive Models. For state of extracted model, i.e., after removing a class. If the bot
example, for the third sentence of P DEM S , the Descrip- discovers any alternative configurations then a new strategy is
tive Model generates generalization configuration with super prepared for presenting the configuration to the modeller. We
class (“Employee”) and sub-classes (“TemporaryEmployee” further explain bot-modeller interactions in Section III.
and “PermanentEmployee”). In contrast, the Predictive Model
predicts Enumeration configuration for the same decision D. Query Answering Component
point. To resolve these conflicts, the proposed algorithms [3] Bot-modeller communication is managed by the Query
consider the probability and semantic similarity scores of Answering Component. For example, a modeller can initiate
these results from the Descriptive and Predictive Models. In communication with the bot if the modeller is interested
addition, we consider domain modelling policies which refer to to gain insights into the modelling decisions for extracted
general rules which we use while practicing domain modelling model elements. Similarly, a bot can initiate communication by
to resolve conflicts. For example, to resolve the current conflict presenting suggestions or taking confirmation from a modeller
(enumeration vs generalization), a policy is used which gives before updating the domain model with a new configuration.
preference to the generalization configuration if the associated Intent Classification: A modeller’s message to the bot
concepts (“TemporaryEmployee” and “PermanentEmployee”) which is written in NL is first interpreted in the Intent Clas-
exhibit different characteristics, e.g., different associations or sification step. In this step, we use the RASA NLU (Natural
attributes. The selected configurations for all the decision Language Unit) pipeline which includes pre-trained models to
points represent the Prescriptive Model. In contrast, the meta- classify the messages into one or multiple pre-defined intents.
data such as the source of selected configurations (Descriptive For example, an intent Find Rationale is predicted for the
or Predictive) represent the Prescriptive Trace Model. modeller’s message “Why is the EmployeeType enumeration
class created?”. Similarly, some intents are forcefully triggered
C. Recommendation Component (Triggered Intents) by the bot, e.g., when presenting alternative
The Prescriptive Model is transformed into a suitable form configurations to a modeller (Offer Suggestions intent).
in the Recommendation Component so that it can be visualized Actions Execution: For each Predicted Intent, the cor-
as a domain model. A modeller can update this extracted responding actions are executed, which further results in a
domain model where each modeller’s change is processed in Generated Message and/or Generated Query. A Generated
this component to generate proactive responses by the bot [6]. Message is presented to the modeller in NL, while a Generated
Configurations Preparation: During the model extrac- Query is transformed into a Trace Query to retrieve the trace
tion process, decision points are identified for domain sce- results (meta-data) from the Traceability Knowledge Graph.
narios present in a given problem description. For each For example, a trace query for an extracted model element
decision point, Possible Configurations are generated. Fur- returns the indices of sentences and words of the problem
thermore, while preparing these configurations, slices are description which are responsible for modelling this element.
created for each configuration. For example, the enumera-
tion decision point is used to model the scenario which is E. Knowledge Base
present in the third sentence of P DEM S . To prepare the The Knowledge Base provides Pre-trained ML Models and
corresponding configuration, four slices are created – (Em- GloVe Embeddings to the Model Extraction Component for
ployee, attribute, type), (type, type, EmployeeType), (Employ- extracting the domain model from a given problem description.
eeType, enumeration item, TemporaryEmployee), and (Em- In addition, the Knowledge Base provides RASA NLU to the
ployeeType, enumeration item, PermanentEmployee). Query Answering Component for interpreting the messages
Actions Categorization: A modeller can update the ex- and predicting their associated intents. We manually prepare
tracted domain model or problem description. Each action the training data for Pre-trained ML Models and for the classi-
change made by a modeller is collected and categorized into fiers used in the RASA NLU pipeline. Furthermore, the Trace
discrete categories in the Action Categorization step. For Models constructed during the model extraction process are

597

Authorized licensed use limited to: Sri Sai Ram Engineering College. Downloaded on November 19,2024 at 08:28:50 UTC from IEEE Xplore. Restrictions apply.
 decision point where the TemporaryEmployee concept is not
a part of the group, i.e., not an enumeration item. The bot
further validates if these equivalent configurations are rejected
by the modeller in the past. The bot also allows modellers to
skip this validation by deselecting the flag “Consider Modeller
Rejections” in the tool.

(a) Initial State (b) New State

Fig. 2. Two States of the Extracted Domain Model.

transformed into the corresponding trace graphs. These graphs

are then weaved together to create a Traceability Knowledge
Graph. This graph conforms to the Traceability Information
Model which maintains different artifacts generated across the
model extraction process and trace relationships among these
artifacts to enable traceability of modelling decisions [4].
Fig. 3. Bot’s Suggestions.
III. B OT-M ODELLER I NTERACTIONS
Bot’s Recommendations: During analysis, if the bot dis-
In this section, we demonstrate our bot’s support for bot-
covers alternative configurations, then the bot prepares a new
modeller interactions. We use the running scenario of P DEM S
strategy to present these configurations to the modeller. For the
to describe some possible bot-modeller interactions.
Domain Model Generation: A modeller provides the prob- example scenario, the bot finds two alternative configurations:
lem description P DEM S and the corresponding domain model Player-Role and Sub-classes. The bot then triggers Offer
is generated automatically as shown in Figure 2a. The ex- Suggestions intent to present alternative configurations as two
tracted domain model is composed of “Employee”, “Project”, options inside the chat widget, as shown in Figure 3.
Modeller Confirmation: A modeller can confirm “Yes”
and “EmployeeType” classes. The “Employee” class has the
by selecting either the Player-Role option or the Sub-classes
“type” attribute (with type “EmployeeType”). The “Employ-
option, as shown in Figure 3. On the other side, a modeller can
eeType” enumeration class has enumeration items – “Tem-
also decline the suggestions by selecting the None option. A
poraryEmployee” and “PermanentEmployee”. The “Project”
modeller’s “Yes” confirmation triggers the Accept Suggestion
class has “id” and “title” attributes with “Integer“ and “String”
intent, while a modeller’s “No” confirmation triggers the
types, respectively. Finally, there is an association relationship
Decline Suggestion intent.
between Employee and Project classes with zero-to-many
cardinality on both sides of the relationship.
Modeller Actions: After observing the extracted model, a
modeller may want to switch to a different configuration for
the decision points which exist in the domain model. For the
running scenario, the modeller prefers the configuration with
the Player-Role pattern over the Enumeration configuration
to support modelling of features of temporary and permanent
employees. Therefore, the modeller makes changes to the
extracted domain model in multiple ways with the intention
of bringing the state of the extracted domain model closer
to the Player-Role configuration for the associated decision Fig. 4. Updated Domain Model.
point. For example, a modeller brings the TemporaryEmployee
enumeration item outside of the EmployeeType enumeration Bot’s Response: Based on the modeller’s response to the
class, as shown in Figure 2b. This action leads to the change bot’s suggestions, different intents are triggered. These intents
of the state of the extracted domain model, i.e., the “Tempo- induce changes to the Prescriptive Model where the selection
raryEmployee” concept is no longer an item of a class. of configurations for the associated decision points changes.
Bot’s Analysis: The bot analyzes the new state of the In addition, configurations for other decision points may be
extracted domain model as shown in Figure 2b. During this changed so that all the configurations are compatible together
analysis, the bot determines that a modeller has performed a when presented to a modeller again in the form of an updated
Concept - Ungroup action, i.e., removing the TemporaryEm- extracted domain model. A new version of the domain model
ployee from the class (group). Next, the bot prepares a strategy (adapted) is presented to the modeller with the highlighted
to address the Concept - Ungroup action. In this strategy, the changes, as shown in Figure 4. The modeller can also undo
bot searches for equivalent configurations for the associated or redo the changes by selecting the respective buttons.

598

Authorized licensed use limited to: Sri Sai Ram Engineering College. Downloaded on November 19,2024 at 08:28:50 UTC from IEEE Xplore. Restrictions apply.
 IV. R ELATED W ORK respectively [6]. Finally, we conduct an exploratory user study
with 11 modellers [6]. The preliminary results are promising.
In the literature, some recommendation systems already
In the future, first, we plan to augment the training data
exist which aim to assist modellers by offering suggestions
based on bot-modeller interactions. This augmented data can
based on certain factors such as the similarity between the
improve the accuracy of predicted intents while interpreting
current content (models) and the existing models in a knowl-
the messages or actions in the future. Second, we plan to
edge base [7], [8], [9], [10], [11], [12]. In addition, a research
improve the model extraction process to increase the accuracy
plan is proposed by Savary-Leblanc et al. [13] which aims
of extracted domain models. Third, we plan to cover a wider
to create modelling assistants using Artificial Intelligence
range of domain modelling scenarios as well as potential
(AI) techniques for providing suggestions. In contrast, our
solutions for these scenarios. Fourth, we aim to perform a more
proposed bot aims to extract complete domain models with
rigorous evaluation of our bot. Finally, we plan to conduct a
high accuracy from problem descriptions written in NL and to
large-scale user study to assess the benefits and limitations of
facilitate bot-modeller interactions. The existing recommen-
our bot in facilitating bot-modeller interactions.
dation systems in the literature aim to provide suggestions
based on the syntactic or semantic match with the contextual R EFERENCES
knowledge or general knowledge of the domain. On the other [1] R. Saini, G. Mussbacher, J. L. Guo, and J. Kienzle, “Towards queryable
side, the objective of our bot is to provide insights into the and traceable domain models,” in 2020 IEEE 28th International Re-
quirements Engineering Conference (RE), 2020, pp. 334–339.
modelling decisions of extracted model elements based on the [2] ——, “A neural network based approach to domain modelling rela-
Traceability Knowledge Graph, which goes beyond providing tionships and patterns recognition,” in 2020 IEEE Tenth International
suggestions. Also, Pérez-Soler et al. [14][15] develop a mod- Model-Driven Requirements Engineering (MoDRE), 2020, pp. 78–82.
[3] R. Saini, G. Mussbacher, J. L. C. Guo, and J. Kienzle, “DoMoBOT: A
elling bot using NLP techniques to interpret the users’ inputs bot for automated and interactive domain modelling,” in Proceedings
in their NL for building a metamodel incrementally. However, of the 23rd ACM/IEEE International Conference on Model Driven
their bot neither generates a complete domain model for a Engineering Languages and Systems: Companion Proceedings, ser.
MODELS ’20. New York, NY, USA: Association for Computing
given problem description nor provides insights into the mod- Machinery, 2020. [Online]. Available: https://doi.org/10.1145/3417990.
elling decisions taken by the extractor system. Furthermore, 3421385
Mussbacher et al. present a conceptual framework to build [4] R. Saini, G. Mussbacher, J. L. Guo, and J. Kienzle, “Automated
traceability for domain modelling decisions empowered by artificial in-
intelligent modelling assistants more systematically [16]. In telligence,” in 2021 IEEE 29th International Requirements Engineering
contrary, our work focuses on building a modelling assistant Conference (RE) (to be published).
for one formalism – domain modelling, and provides a proof- [5] J. Pennington, R. Socher, and C. D. Manning, “Glove: Global vectors
for word representation,” in Empirical Methods in Natural Language
of-concept in the form of a web-based modelling bot. Processing (EMNLP), 2014, pp. 1532–1543. [Online]. Available:
http://www.aclweb.org/anthology/D14-1162
V. D ISCUSSION AND F UTURE W ORK [6] R. Saini, G. Mussbacher, J. L. Guo, and J. Kienzle, “Automated, inter-
active, and traceable domain modelling,” Software & Systems Modeling
Synergy between automated model extraction and bot- (to be published), 2021.
[7] L. Burgueño, R. Clarisó, S. Gérard, S. Li, and J. Cabot, “An NLP-based
modeller interactions is required to better assist modellers. architecture for the autocompletion of partial domain models,” in In-
Support for bot-modeller interactions enables modellers to ternational Conference on Advanced Information Systems Engineering.
quickly switch to their preferred configurations in the extracted Springer, 2021, pp. 91–106.
[8] H. Agt-Rickauer, R.-D. Kutsche, and H. Sack, “Domore-a recommender
domain model and to update the problem descriptions when system for domain modeling.” in MODELSWARD, 2018, pp. 71–82.
required. In this paper, we present DoMoBOT, a web-based [9] A. Elkamel, M. Gzara, and H. Ben-Abdallah, “An UML class recom-
modelling bot to automate model extraction and facilitate bot- mender system for software design,” in 2016 IEEE/ACS 13th Interna-
tional Conference of Computer Systems and Applications (AICCSA).
modeller interactions. In our previous work, we validate the IEEE, 2016, pp. 1–8.
accuracy of extracted domain models [1], [2], [3], [4] for [10] T. G. Cerqueira, F. Ramalho, and L. B. Marinho, “A content-based
an unseen set of problem descriptions. The average precision approach for recommending uml sequence diagrams.” in SEKE, 2016,
pp. 644–649.
and recall scores of extracted domain models using our pro- [11] D. Lucrédio, R. P. d. M. Fortes, and J. Whittle, “Moogle: a metamodel-
posed approach are 90% and 77%, respectively. During bot- based model search engine,” Software & Systems Modeling, vol. 11,
modeller interactions, our bot discovers alternative configura- no. 2, pp. 183–208, 2012.
[12] Á. M. Segura, A. Pescador, J. de Lara, and M. Wimmer, “An extensible
tions, presents these configurations to a modeller in the form meta-modelling assistant,” in EDOC 2016. IEEE, 2016, pp. 1–10.
of suggestions, and updates the domain models. Therefore, [13] M. Savary-Leblanc, “Improving MBSE tools UX with AI-empowered
we also perform the evaluation of our bot for these categories software assistants,” in MODELS 2019 Companion. IEEE, 2019, pp.
648–652.
where we compare the bot responses with the ground truth [14] S. Pérez-Soler, E. Guerra, J. de Lara, and F. Jurado, “The rise of the
domain models (manually constructed domain models) for (modelling) bots: Towards assisted modelling via social networks,” in
the test problem descriptions. During this comparison, we ASE 2017. IEEE Press, 2017, pp. 723–728.
[15] S. Pérez-Soler, E. Guerra, and J. de Lara, “Collaborative modeling
obtain the total relevant concepts, total retrieved concepts, and group decision making using chatbots in social networks,” IEEE
and the total retrieved relevant concepts for each category Software, vol. 35, no. 6, pp. 48–54, November 2018.
to calculate F1 scores. Our bot achieves the median F1 [16] G. Mussbacher, B. Combemale, J. Kienzle, S. Abrahão, H. Ali, N. Ben-
como, M. Búr, L. Burgueño, G. Engels, P. Jeanjean et al., “Opportunities
scores of 81%, 90%, and 88% in the Found Configurations, in intelligent modeling assistance,” Software and Systems Modeling,
Offered Suggestions, and Updated Domain Models categories, vol. 19, no. 5, pp. 1045–1053, 2020.

599

Authorized licensed use limited to: Sri Sai Ram Engineering College. Downloaded on November 19,2024 at 08:28:50 UTC from IEEE Xplore. Restrictions apply.