Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs

Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs Alessandra Mancas

Mounir Ammam

Hyacinth Ali∗

Université de Montréal DIRO Montreal, Canada alessandra.thais.mancas@umontreal.ca

Université de Montréal DIRO Montreal, Canada mounir.ammam@umontreal.ca

University of Alberta Electrical and Computer Engineering Alberta, Canada hcali@ualberta.ca

Kevin Delcourt

Houari Sahraoui

Université de Montréal DIRO Montreal, Canada kevin.delcourt@umontreal.ca

Université de Montréal DIRO Montreal, Canada sahraouh@iro.umontreal.ca

arXiv:2608.12228v1 [cs.SE] 12 Aug 2026

Abstract Large language models (LLMs) have recently shown strong capabilities for code understanding, making them promising for reverse engineering domain models from source code. However, state-ofthe-art proprietary LLMs cannot be used in many industrial contexts due to privacy and confidentiality constraints, while compact open-source LLMs that can run locally are limited by their context window and cannot process large code bases directly. In this paper, we propose an automated approach to extract domain models from source code using lightweight, locally deployable LLMs. Our method combines structural and semantic heuristics with iterative LLM-based reasoning to overcome context limitations. By progressively analyzing ranked subsets of code elements, the approach identifies domain concepts and refines domain boundaries without requiring full-system context. Our approach achieves high F1-scores on a dataset of ten projects, each comprising a curated domain model and its corresponding implementation, while remaining fully executable on locally deployable LLMs. This makes it particularly suitable for reverse engineering tasks in privacy-sensitive industrial environments.

CCS Concepts • Software and its engineering → Software reverse engineering; Model-driven software engineering; Unified Modeling Language (UML).

Keywords Domain Modeling, Large Language Models (LLMs), Reverse Engineering, Domain Models, Class Diagram, Model Generation ACM Reference Format: Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui. 2026. Towards Automated Domain Model Extraction from Source ∗ Also with Université de MontréalDIRO,.

This work is licensed under a Creative Commons Attribution 4.0 International License. MODELS 2026, Málaga, Spain © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2809-9/2026/10 https://doi.org/10.1145/3822455.3830329

Code using Heuristics and Open-Source LLMs. In ACM/IEEE 29th International Conference on Model Driven Engineering Languages and Systems (MODELS 2026), October 04–09, 2026, Málaga, Spain. ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/3822455.3830329

1

Introduction

Domain models play a central role in Model-Driven Engineering (MDE), where they are used to represent domain concepts, guide system design [16], and support automated analysis and code generation [9]. As understanding, maintaining and evolving complex or legacy software remains a significant challenge in the industry [43], reverse engineering domain models from existing software systems can offer valuable assistance to practitioners [8]. Recent advances in generative artificial intelligence have significantly expanded the range of tasks that can be automated in software engineering [2]. Large language models (LLMs) have demonstrated strong capabilities for code understanding, making them promising candidates for reverse engineering tasks [46], including the extraction of domain models from source code [12]. While early applications of LLMs to software engineering [25] and modeling tasks [26] showed encouraging but limited performance, more recent studies suggest that state-of-the-art proprietary models are approaching human-level performance on such tasks [40]. This is in part due to the fact that these LLMs can process large contexts and perform complex reasoning over code. However, relying on such models raises ethical concerns in academic, industrial, and governmental contexts. A systematic mapping study by Huang et al. [24] identifies transparency and privacy as two of the five major concerns associated with their widespread adoption. Many companies are reluctant or unable to disclose their source code to third-party providers due to security, privacy, and intellectual property constraints. Deploying proprietary LLMs for reverse engineering tasks is often not a viable option in practice. An alternative is to rely on open-source LLMs that can be executed locally. While this addresses privacy and confidentiality concerns, it introduces a different limitation. Compact open-source models typically have restricted context windows, which prevent them from processing large code bases in a single prompt [3]. Consequently, these models cannot directly perform domain model extraction at the scale of real-world systems.

MODELS 2026, October 04–09, 2026, Málaga, Spain

This creates a fundamental gap: powerful LLMs capable of handling large code bases are not deployable in many industrial contexts, while locally executable models lack the capacity to analyze complete systems. There is a need for approaches that enable effective domain model reverse engineering using lightweight, locally deployable LLMs despite their limited context. In this paper, we propose an automated approach to extract domain models from source code using compact open-source language models. Our approach combines structural and semantic heuristics with iterative LLM-based reasoning to overcome context limitations. Starting from a rough UML class diagram extracted from the code, we compute the semantic similarity between code elements and available project documentation to rank classes according to their likelihood of representing domain concepts. We then iteratively process the ranked list of classes, classifying each class as either domain-specific or implementation detail. As the process progresses, the language model accumulates contextual knowledge about the domain, enabling it to progressively refine domain boundaries despite operating under limited context. The identification of attributes and relationships is performed using a similar combination of heuristics and LLM-based reasoning. Beyond extracting domain models, our approach establishes explicit links between model elements and the corresponding implementation artifacts, enabling applications such as model–code traceability and AI-assisted development, both often cited as opportunities in Model-Driven Engineering (MDE) [6]. A key advantage of our approach is that it can be executed entirely on compact open-source models, making it suitable for industrial contexts where code confidentiality is critical. We evaluate our approach on ten projects for which both manually defined domain models and corresponding source code implementations are available. The results show that our method achieves high precision and recall, while remaining fully deployable in a local setting. The main contributions of this paper are:

Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui

models foster shared understanding between stakeholders and engineers, bridging the gap between business knowledge and system implementation [16]. During requirements elicitation and design, modelers translate textual specifications into UML class diagrams [45], a process that is time-consuming and requires expertise [14]; these models then serve as central artifacts supporting downstream activities such as model transformation, system analysis [15], and facilitate traceability between requirements and implementation. Domain modeling has been applied to a wide range of industrial applications, such as cyber-physical systems [11], or digital twins [35].

2.2

Model Driven Reverse Engineering

Reverse engineering refers to the process of analyzing software systems to identify their components and recover higher-level representations from source code [29]. In the context of MDE, ModelDriven Reverse Engineering specifically focuses on deriving highlevel models by leveraging MDE techniques such as metamodeling and model transformations [48]. This area addresses long-standing challenges in software engineering practice, including legacy system modernization, maintenance, and evolution, by aiming to produce comprehensible representations such as domain diagrams from source [8, 12]. These challenges are further amplified by the increasing prevalence of LLM-generated code. As development teams generate more code with LLMs, it becomes more difficult to maintain a shared understanding of system behavior [49]. Consequently, there is a growing need for methods that can abstract and recover the underlying domain concepts of a system, helping to manage this emerging form of cognitive debt [49].

2.3

Context Windows in Large Language Models

2 Background 2.1 Domain Modeling

LLMs have demonstrated remarkable capabilities across a wide range of natural language processing tasks [7]. They are effective at generalizing across different modalities [50]. This makes them key building blocks for intelligent systems addressing various Software Engineering challenges [2]. However, these models also face notable limitations. In particular, the high computational cost associated with training and deploying large LLMs limits their accessibility for many organizations, while the use of proprietary, closed-source models raises increasing ethical concerns [24]. Smaller LLMs, which can be deployed on cheaper hardware, provide a practical alternative, but are often constrained by limited context windows. As highlighted by Naveed et al. [39], handling long contexts remains a major challenge in current LLM research, and a variety of approaches are being explored to address this limitation.

In Model-Driven Engineering and Requirements Engineering, the domain model is a central artifact representing the key concepts of a problem space [52]. Domain modeling aims to capture the main concepts, attributes, and relationships that characterize a domain, while excluding implementation details such as operations or interfaces. It abstracts real-world entities into structured representations, which can be expressed as graphical models (e.g., UML class diagrams) or textual models (e.g., PlantUML or UMPLE class diagrams [31]). As a core artifact in early software design, domain

Approaches for handling large contexts with LLMs. A first category of approaches focuses on modifying LLM architectures to natively support longer contexts. For example, techniques such as RoPE scaling [41] extend the usable context length by adapting positional embeddings, enabling models trained on shorter sequences to generalize to longer inputs.Other works redesign the attention mechanism to reduce the computational cost of standard self-attention [22]. Recent versions of Qwen leverage these techniques to enable relatively small models to handle contexts of

• An automated approach for domain model reverse engineering from source code using lightweight, locally deployable language models. • A method that combines structural and semantic heuristics with iterative LLM reasoning to overcome context window limitations. • A process that establishes explicit links between domain models and implementation code. • An empirical evaluation on ten projects conducted on modest hardware.

Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs

up to 1M tokens, as seen with Qwen2.5-14B [1]. However, these approaches remain an active area of research and are difficult to deploy on consumer-grade hardware [39] . A second category of approaches circumvents context window limitations without modifying the underlying model architecture. Retrieval-Augmented Generation (RAG) methods improve prompts with information retrieved from large external corpora [19]. Similarly, memory-augmented LLMs rely on external memory structures to store and retrieve relevant information [59]. These techniques enable models to handle complex tasks despite limited context windows. Finally, Kyoung et al. [30] shows that decomposing complex queries into smaller sub-questions improves long-context question answering performance without requiring additional training. This effectively allows models to process complex inputs through multiple focused reasoning steps. Our work aligns with this latter category. We adopt a multi-step, iterative prompting strategy. However, unlike generic approaches, our method leverages domain-specific knowledge from ModelDriven Engineering to design a structured pipeline tailored to the task, which can lead to more accurate, meaningful and efficient abstractions.

2.4

MODELS 2026, October 04–09, 2026, Málaga, Spain

Figure 1: Expert-developed CoolSupplies domain model

Embeddings and Semantic Similarity

Embeddings are a fundamental representation technique in machine learning, which is extensively used in a wide variety of modern Natural Language Processing (NLP) [51] and generation [58] tasks. They map discrete data, such as words, sentences, or code elements, into a continuous high-dimensional vector representation, where semantic relationships are encoded geometrically. Existing approaches, such as Word2Vec [33], demonstrate that semantic regularities can be captured through vector representations learned from large corpora, which allows meaningful comparisons between textual units [36]. This idea has since been extended to contextualized representations using transformer-based models, which encode richer syntactic and semantic information. Recently, models, such as Sentence-BERT (SBERT) [18], generate semantically meaningful embeddings for documents, which support efficient comparison using similarity measures such as cosine similarity. These embedding-based approaches have become the standard for semantic textual similarity tasks, where the goal is to quantify the degree of semantic equivalence between two pieces of text [20]. Given two vectors, a and b, their similarity can be expressed using cosine similarity as:

similarity(a, b) =

a·b ∥a∥ ∥b∥

(1)

Cosine similarity is widely adopted as it captures the angular relationship between vectors and is empirically effective for comparing semantic representations across a variety of embedding models [60]. In our work, this enables the estimation of semantic similarity between extracted diagram elements (i.e., classes) and the domain description, thereby supporting the extraction of domain diagrams at an appropriate level of abstraction.

Figure 2: Reverse engineered CoolSupplies model through our pipeline (excerpt)

3

Approach

Our approach aims to extract domain models from source code using lightweight language models under limited contexts. To achieve this, we adopt a multi-stage and iterative pipeline that refines a domain model from an implementation-level representation. Illustrative example: Given the CoolSupplies project, which is a school-oriented system that enables administrators to manage grades, students, and supply bundles, while allowing parents to register, select students, and place orders of required school supplies for a given academic year. Its expert-curated domain model is shown in Figure 1, which we use as ground truth for evaluating our approach. Two independent implementations of this domain model exist. We consider one implementation, comprising 90 classes and 7,899 lines of code, and aim to reverse engineer its source code into the corresponding domain model. Figure 2 illustrates a corresponding reverse-engineered model (excerpt) produced by our pipeline, and we discuss and analyze the differences between the extracted model and the ground truth model in Section 4. Overview: As illustrated in Figure 3, the process starts by extracting an implementation UML class diagram from the source code ○, A which serves as an initial approximation of the domain model. We then rank the extracted classes according to their likelihood of representing domain concepts using semantic similarity with project

MODELS 2026, October 04–09, 2026, Málaga, Spain

Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui

A Extract implementation class diagram

Repository

Low-level class diagram

Source code (Java) extract class names

B Documentation (README)

Rank semantic similarity with problem description

raw class names

(SBERT cosine similarity - all-mpnet-base-v2)

ranked list of classes

for each class

C LLM (LLama3.1-70B)

Classify classes (domain v. implementation detail)

P1

domain classes

Classify attributes (relevant v. irrelevant) domain classes with filtered attributes

Remove "implementation" classes

irrelevant attributes

Remove irrelevant attributes

inferred association

Add associations to domain model

for each class pair

E P3

implementation detail classes

for each class

D P2

Class Registry (JSON)

Infer associations between class pairs

Prompts P1: class name + previously identified domain classes P2 : class name + attributes & types P3 : (class 1, class 2) + respective attributes & types

Final domain model

Figure 3: Overview of the Domain Model Extraction Pipeline documentation ○. B Rather than analyzing the entire system at once, we iteratively process this ranked list, allowing the language model to incrementally build contextual knowledge of the domain despite operating with limited context. The pipeline proceeds through successive refinement steps, including the classification of classes into domain or implementation elements ○, C the filtering of irrelevant attributes ○, D and the inference of relationships between domain concepts ○. E Each step combines structural heuristics with LLMbased reasoning, and leverages previously inferred information to guide subsequent decisions. The proposed approach targets object-oriented systems and assumes that an implementation-level class diagram can be extracted from the source code. It requires a short, domain-level description of the system (e.g., a README or requirements description), rather than a rigid documentation format. Class and attribute identifiers should retain sufficient semantic information to reflect the application domain. These assumptions underpin the semantic ranking and iterative classification stages. The following subsections describe these components as well as the remainder of the pipeline.

3.1

Documentation and Diagram Extraction

In this work, we focus on object-oriented systems, using Java projects as a representative setting. Additionally, our approach leverages domain documentation from the source code repository. This documentation need not be exhaustive or fully up to date, as its primary purpose is to introduce core domain concepts and establish a shared vocabulary.

In step ○, A we use a model-driven static analysis tool to automatically derive from the source code an implementation-level representation capturing the structural elements of the system, including classes, attributes, and relationships. This representation serves as the initial view of the system and may include both domain concepts (e.g., an Order class) and implementation artifacts (e.g., a CoolSuppliesController class). To facilitate subsequent processing, it is transformed into a simplified textual class registry that records classes, attributes, relationships, and other relevant structural information while omitting non-essential details such as package hierarchies. Method signatures are retained as context to support semantic abstraction but are omitted from the final domain model, which captures only structural domain concepts. The registry can be serialized into any machine-readable representation, such as JSON. Consequently, once such a structural representation is available, the remainder of the pipeline operates exclusively on this intermediate representation together with the available project documentation. Adapting the approach to another object-oriented language therefore primarily requires producing an equivalent structural representation as input to the pipeline

3.2

Semantic similarity ranking

A key challenge in our setting is that, at the beginning of the process, the language model has no explicit knowledge of the domain boundaries. As a result, directly classifying classes as domain-related or

Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs

implementation-related in an arbitrary order may lead to early misclassifications, which can negatively impact subsequent decisions due to the iterative nature of the approach. To mitigate this issue, we introduce an ordering strategy that increases the likelihood of correct early classifications. Our intuition is that classes representing domain concepts are more likely to be reflected in high-level project documentation, whereas implementationspecific classes are less frequently described. Based on this heuristic, we estimate the semantic relevance of each class with respect to the documentation. Concretely, in step ○, B we represent both class names and documentation fragments using vector embeddings and compute their semantic similarity using cosine similarity. In our running example, a class such as SchoolAdmin receives higher cosine similarity scores (0.5991), whereas an implementation detail class like XmlSerializer, which is unrelated to the domain, receives a much lower score (0.0840). Hence, each class is ranked according to its similarity with the documentation, and this ranked list is then used to guide the iterative classification process. This approach fosters the intuition that classes most likely to represent domain concepts are considered first, allowing the language model to establish an initial and more reliable understanding of the domain, which is progressively refined as additional classes are analyzed. Since this ranking relies only on the semantic correspondence between implementation-level identifiers and high-level domain terminology, the concise project description introduced in Step ○ A is generally sufficient to guide the process. However, this ranking alone is not a sufficient heuristic, as some implementation detail classes may also contain domain-related terms, for instance, CoolSuppliesFxmlView scores 0.4888 despite being primarily tied to the UI implementation. To this effect, we augment the workflow using an LLM to classify the ranked model elements as either domain-specific or implementation detail elements, as detailed in the following section.

3.3

Classifying classes

The goal of step ○ C is to classify each class as either domainspecific (DS) or implementation detail (ID), aiming to transform the implementation-level representation into a domain-oriented abstraction. Rather than performing this classification independently, we adopt an iterative process in which classes are analyzed sequentially following the order established in the previous step. This allows the model to progressively build contextual knowledge about the domain and improve its performance over time. 3.3.1 Iterative classification process. The project documentation (included in the classification prompt) provides an initial understanding of the application domain but does not establish how domain concepts are represented in the implementation. Classes are therefore processed sequentially, with previously classified concepts included in subsequent prompts to progressively build this mapping. This enriched context enables the model to approximate global reasoning while operating under limited context. Furthermore, because classes are processed according to their semantic similarity

MODELS 2026, October 04–09, 2026, Málaga, Spain

with the project documentation, likely domain concepts are typically identified first, allowing the domain-specific (DS) context to grow rapidly and improving the reliability of later classifications. 3.3.2 LLM-based classification strategy. At each iteration, the classification decision is performed by a language model that evaluates whether a given class represents a domain concept or an implementation artifact. The decision is based on multiple sources of information: (i) the class name, (ii) the project documentation, and (iii) the set of previously classified classes. The model is guided by general software engineering heuristics, which are used as soft indicators. In particular, domain classes typically correspond to real-world entities or core concepts of the application domain, while implementation classes often relate to architectural patterns, data access layers, or technical mechanisms. Naming conventions can provide useful signals (e.g., Controller, Repository, DTO), but they are inherently ambiguous as similar terms may refer to either domain concepts or implementation artifacts depending on the application (e.g., air traffic controller vs. MVC Controller). The classification is formulated as a strict binary decision. To support this process, we design structured prompts that provide the model with the relevant context and guide its reasoning through instructions and examples. The prompt includes the project documentation, previously classified classes, and representative examples of domain and implementation elements [34]. 3.3.3 Filtering implementation elements. Once all classes have been classified, we have domain-specific and implementation-detail classes. The domain model is then constructed by retaining only DS classes and removing ID classes from the initial diagram. Since relationships in the original diagram may involve ID classes, removing them can lead to the loss of connections between domain concepts. This motivates an additional step to preserve meaningful structural relationships. 3.3.4 Preserving structural relationships. To mitigate the loss of relationships induced by the removal of implementation classes, we introduce a mechanism to recover indirect associations between domain classes. The initial class diagram is interpreted as a graph, where nodes represent classes and edges represent relationships. We identify paths of the form 𝐷 1 → 𝐼 1 → · · · → 𝐼𝑛 → 𝐷 2 , where 𝐷𝑖 are domain classes and 𝐼 𝑗 are implementation classes. For each such path, we introduce a direct association between 𝐷 1 and 𝐷 2 , effectively bypassing the implementation layer. Existing direct associations between domain classes are preserved. While this transitive association mechanism helps maintain connectivity and improves recall, it may introduce spurious relationships when implementation classes connect unrelated domain concepts. In practice, we observed that retaining these inferred associations yields better overall results than relying solely on direct relationships.

3.4

Classifying attributes

In step ○, D we refine the classes identified in step ○ C by retaining only the attributes that contribute to the representation of domain concepts, and filtering out those related to implementation concerns. For example, an OrderItem class in the implementation codebase

MODELS 2026, October 04–09, 2026, Málaga, Spain

may include a cachedHashCode attribute, which reflects a low-level implementation concern (e.g., performance optimization) rather than a domain concept, and should therefore be removed at this stage. For each class, we consider its attributes and their types as extracted from the initial class diagram. The task is formulated as a binary classification problem, where each attribute is either relevant or irrelevant to the domain entity represented by the class. Attribute classification is performed iteratively. For a given class, attributes are processed sequentially, and previously classified attributes are used as contextual information to guide subsequent decisions. This allows the model to progressively identify patterns within the attributes of a class and improve classification consistency. In addition, the classification of attributes is contextualized by considering the surrounding structure of the model. In particular, neighboring classes, identified through associations, are provided as context, as some attributes may correspond to relationships rather than intrinsic properties of the class. 3.4.1 LLM-based classification strategy. At each iteration, a language model evaluates whether a given attribute contributes to the domain representation of the class. The decision is based on (i) the class name, (ii) the attribute name and type, (iii) the project documentation, (iv) previously classified attributes, and (v) neighboring classes, all of which are included in the prompt used [34]. The model is guided by general modeling heuristics. Relevant attributes typically describe intrinsic properties of domain entities (e.g., identifiers, descriptive fields, or domain-specific characteristics), while irrelevant attributes often correspond to technical concerns such as temporary variables, flags, storage mechanisms, or implementation-specific data structures. Once all attributes have been classified, irrelevant attributes are removed from each class. The resulting representation retains only domain-specific classes and their relevant attributes, forming a domain model that abstracts away implementation-level details.

3.5

Inferring associations between class pairs

After filtering classes and attributes, the resulting model may still lack meaningful relationships between domain concepts. While some associations are preserved from the original class diagram or recovered through transitive connections, others may be missing due to the abstraction process. Removing implementation elements can break indirect links between domain classes, and some relationships may not be explicitly represented in the code structure. To address this, we introduce a final step ○ E to infer potential associations between domain-specific (DS) classes, with the goal of improving the completeness and coherence of the resulting domain model. We consider all pairs of DS classes that are not already connected through either direct associations or previously inferred transitive associations. These pairs represent potential candidates for new relationships. This step reduces the search space to unresolved class pairs, allowing the model to focus on identifying missing connections rather than reconsidering established ones. 3.5.1 LLM-based association inference. For each candidate pair, the language model is used to determine whether a meaningful association should exist between the two classes. The decision is based on (i) the class names, (ii) their attributes, methods and types,

Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui

(iii) the project documentation, and (iv) existing relationships in the model, which are included in the prompts [34]. The model is guided by general modeling heuristics. In particular, associations may be inferred when (i) one class appears as the type of another program element (e.g., an attribute, method parameter, or return value), suggesting an implicit structural relationship, or (ii) the corresponding domain concepts are semantically related according to the documentation. These signals are interpreted jointly to determine whether a direct association should be introduced. The classification is formulated as a binary decision (association vs. no association). The final set of associations is obtained by combining (i) the original associations extracted from the class diagram, (ii) the transitive associations introduced earlier, and (iii) the newly inferred associations. The current pipeline recovers associations between domain classes without directionality or multiplicities.

4 Evaluation 4.1 Research Questions The goal of this evaluation is to assess the effectiveness of our approach for extracting domain models from source code using lightweight, locally deployable language models, as well as to analyze the impact of its key design choices. To this end, we address the following research questions: RQ1: What is the overall performance of the proposed approach in extracting domain models from source code? This question evaluates how accurately the approach identifies domain classes, relevant attributes, and associations when compared to a reference domain model. RQ2: Does preprocessing class names through tokenization improve the performance of the approach? This question investigates whether splitting compound identifiers into meaningful tokens (before step ○ A in Figure 3) improves semantic interpretation by the language model. For example, ClientController becomes “client controller” before embedding and classification, potentially improving classification accuracy. RQ3: What is the impact of semantic similarity-based ranking on the performance of the approach? This question evaluates the contribution of the ranking strategy (step ○ B in Figure 3) by comparing the proposed approach with variants that process classes without prioritization. RQ4: How sensitive is the proposed approach to different implementations of the same domain model? This question evaluates the robustness of the approach by comparing its performance across multiple implementations of the same domain.

4.2

Experimental Setup

We present here the dataset, metrics and implementation details for the evaluation of our pipeline. These elements are included in our replication package [34]. 4.2.1 Dataset. We evaluate our approach on ten publicly available Java software engineering projects developed as part of an undergraduate Model-Driven Engineering course [34]. In this course, students implement an instructor-provided domain model, resulting in software systems for which the intended conceptual model is

Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs

known a priori. These projects correspond to seven distinct domain models spanning different application domains, meaning three have two independent implementations. The presence of multiple implementations for the same domain model allows us to assess the robustness of the approach across different code bases representing the same conceptual domain. Table 1 summarizes the main characteristics of the reference domain models used in our evaluation, including the number of classes, attributes, and relationships. All projects are implemented in Java and follow standard objectoriented design practices, making them suitable for our pipeline, which operates on implementation-level class diagrams extracted from source code. In addition to the source code, the pipeline relies on a short textual description of the system and its application domain. Although the descriptions used in our experiments were curated by domain experts, they are representative of the high-level information typically available in project documentation, such as README files or software requirements specifications. This dataset allows us to evaluate the ability of our approach to recover domain concepts, attributes, and relationships from realworld code bases. However, it also presents some limitations. First, the number of projects is relatively small, which may limit the generalizability of the results. Second, conceptual domain models are subjective and may vary in abstraction. The reference models therefore represent one plausible conceptualization rather than a unique ground truth.= Finally, the projects are of moderate size, and larger industrial systems may introduce additional challenges not fully captured in this evaluation. 4.2.2 Evaluation Metrics. We evaluate the extracted domain models using standard information retrieval metrics: precision, recall, and F1-score. These metrics are automatically computed separately for classes, attributes, and associations. To account for variability in LLM outputs, each experiment is executed three times, and we report the average precision, recall, and F1-score across runs. For classes, true positives correspond to correctly identified domain classes, false positives to implementation classes incorrectly classified as domain, and false negatives to missing domain classes. For attributes, evaluation is restricted to correctly identified domain classes (true positives). An attribute is considered correct if it belongs to a true-positive class and matches an attribute in the reference model. Precision and recall are computed based on the set of attributes retained after filtering. For associations, evaluation is more complex due to the transformations applied to the initial class diagram. We consider an association to be correct if it connects two domain classes that are also connected in the reference model. Similar to attributes, associations are evaluated with respect to the set of correctly identified domain classes. This avoids penalizing the approach for discrepancies introduced by errors in earlier classification steps. In particular, only associations between true-positive classes are considered when computing precision and recall. Finally, we report macro-averaged precision, recall, and F1-scores across all projects. 4.2.3

Implementation Details.

Proposed approach. Our approach uses the open-source LLaMA3.170B language model, executed locally, across multiple stages of the

MODELS 2026, October 04–09, 2026, Málaga, Spain

pipeline, including class classification, attribute filtering, and association inference. The intermediate representation of each repository is extracted using Visual Paradigm’s Instant Reverse functionality. Experimental protocol. Each experiment is repeated three times to account for variability in LLM outputs, and we report average results. For ablation studies (RQ2 and RQ3), we compare the default configuration of our approach with variants that modify specific components (e.g., tokenization, ranking strategy). Hardware configuration. All experiments are conducted on a machine equipped with 4 NVIDIA GeForce RTX 3090, with 24 GB of GPU memory. The use of locally deployable models is a key aspect of our approach, and this setup reflects realistic hardware constraints in average industrial environments.

5 Evaluation Results 5.1 RQ1: Overall Performance Recovery performance. Table 2 reports the aggregated performance of our approach across all ten projects, while Table 3 provides detailed results for each individual case. The full results along with the scripts used are included in our replication package [34]. Overall, the approach achieves strong performance across all elements of the domain model. For classes, we obtain a precision of 0.84, a recall of 0.97, and an F1-score of 0.90, indicating that most domain concepts are correctly identified, with limited confusion with implementation elements. For attributes, performance is even higher, with an F1-score of 0.94, reflecting the effectiveness of the attribute filtering step once domain classes are correctly identified. For associations, evaluated only between correctly identified domain classes, the approach achieves a precision of 0.78, a recall of 0.93, and an F1-score of 0.85. While recall remains high, precision is lower compared to classes and attributes, indicating that the approach tends to infer additional relationships that are not always present in the reference model. Since associations are inferred only between classes retained in the extracted domain model, evaluating associations involving false-positive or false-negative classes would conflate errors originating from different stages of the pipeline. Restricting the evaluation to true-positive classes therefore isolates the quality of the association recovery process itself. Runtime. The end-to-end execution time is approximately 30 minutes on our hardware configuration and remained relatively stable across the evaluated projects, which range from 24 to 122 implementation classes. Since domain model reverse engineering is primarily an offline program task, i.e., batch processing, rather than a runtime activity, this execution time is aligned with the intended use cases [56]. The detailed results in Table 3 show that recall is consistently high across all projects, often close to or equal to 1.00 for classes and attributes. This suggests that the approach is effective at capturing domain elements and rarely misses relevant concepts. In contrast, precision varies more across cases, particularly for associations, where inferred relationships may introduce noise. Finally, performance differences across projects appear to be more influenced by the nature of the application domain than by model size or complexity. While the reference domain models are

MODELS 2026, October 04–09, 2026, Málaga, Spain

Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui

Table 1: Overview of evaluated systems (cases) in our dataset Case

Domain name

Description

Case 1 Case 2 Case 3 Case 4 Case 5 Case 6 Case 7 Case 8 Case 9 Case 10

Flexibook (imp 1) Flexibook (imp 2) Climbsafe (imp 1) Climbsafe (imp 2) BikeTourPlus AssetPlus CoolSupplies (imp 1) CoolSupplies (imp 2) CheECSEManager BTMS

Service booking Service booking Book climbing activities Book climbing activities Book and manage bike tours Hotel asset management Manage school supplies Manage school supplies Manage cheese aging Transportation management

Table 2: Average precision, recall, and F1-score across all cases. Classes Attributes Associations (TP classes only)

Precision 0.84 0.89 0.78

Recall 0.97 0.99 0.93

F1 0.90 0.94 0.85

of comparable size and structure (Table 1), the corresponding implementations vary more significantly in terms of number of classes and lines of code (Table 1). Despite this variability, no clear correlation is observed between implementation size and performance. Instead, domains with clearly defined entities and relationships tend to yield higher precision. For instance, systems such as CoolSupplies and CheECSEManager, which involve concrete entities (e.g., supplies, orders, or cheese batches) and explicit relationships between them, achieve higher precision, particularly for associations. In contrast, domains involving more implicit or abstract relationships, such as Climbsafe or AssetPlus, lead to increased ambiguity. In these cases, concepts such as bookings, assets, or operational processes can be represented in multiple ways, making it more difficult for the model to distinguish between domain and implementation elements and to infer precise relationships. Answer to RQ1: The proposed approach achieves high recall and strong overall performance in extracting domain models from source code, with particularly strong results for classes and attributes. While association inference introduces some noise, the approach remains effective across diverse projects.

5.2

RQ2: Impact of Tokenization

To evaluate the impact of class name tokenization, we compare the default configuration of the approach (no tokenization) with its tokenized variant under the same conditions (Table 4). The results show that tokenization does not improve performance across any of the evaluated metrics. Compared to the default configuration, tokenization leads to a decrease in precision (from 0.84 to 0.50), recall (from 0.97 to 0.90), and consequently F1-score (from 0.90 to 0.64). This indicates that tokenization not only fails to provide benefits, but can significantly degrade performance. A likely explanation is that splitting compound identifiers removes useful semantic and structural information embedded in

Domain Model #classes #constructs 13 45 13 45 13 35 13 35 11 33 11 28 10 20 10 20 13 38 7 12

Implementation Doc #words #classes LOC 146 33 7787 146 36 9348 160 68 5763 160 56 18615 119 58 15408 122 95 12639 107 95 8048 107 90 7899 135 122 11611 38 24 3509

Table 3: Performance of the proposed approach across all cases (averaged over 3 runs) C. 1 2 3 4 5 6 7 8 9 10

P 0.85 0.82 0.78 0.80 0.88 0.76 0.90 0.89 0.87 0.86

Classes R F1 1 0.92 1 0.90 0.92 0.84 0.92 0.86 1 0.94 0.91 0.83 1 0.95 1 0.94 1 0.93 1 0.92

Attributes P R F1 0.90 1 0.95 0.88 1 0.94 0.85 0.96 0.90 0.87 0.96 0.91 0.92 1 0.96 0.82 0.95 0.88 0.93 1 0.96 0.92 1 0.96 0.91 1 0.95 0.90 1 0.95

Associations P R F1 0.72 0.94 0.81 0.70 0.91 0.79 0.43 0.89 0.58 0.45 0.90 0.60 0.75 0.92 0.83 0.47 0.88 0.61 0.86 0.93 0.89 0.84 0.92 0.88 0.79 0.94 0.86 0.78 0.93 0.85

Table 4: Evaluation of the impact of removing semantic similarity ranking and the contribution of class name tokenization. The default configuration (✗, ✓) corresponds to the results reported in Table 2. Tokenization ✗ ✗ ✓ ✓

Ranking ✗ ✓ ✗ ✓

Precision 0.55 0.84 0.55 0.50

Recall 0.95 0.97 0.95 0.90

F1 0.69 0.90 0.70 0.64

class names. Modern language models are able to interpret such identifiers effectively without preprocessing, and tokenization may disrupt these representations. Answer to RQ2: Tokenization does not improve performance and can significantly degrade it. The default approach without tokenization is therefore preferable.

5.3

RQ3: Impact of Semantic Similarity Ranking

To evaluate the impact of semantic similarity-based ranking heuristic, we compare the default configuration of the approach (with ranking) to a variant that processes classes without prioritization (Table 4). The results show that ranking has a significant impact on performance. When ranking is disabled, the F1-score drops from 0.90 to

Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs

0.69, with a corresponding decrease in precision (from 0.84 to 0.55), while recall remains relatively high. This indicates that, without ranking, the approach tends to misclassify more implementation elements as domain concepts, leading to lower precision. We also observe this trend when considering the tokenized configuration. These results highlight the importance of processing classes in an order that prioritizes likely domain concepts. By guiding the iterative classification process, ranking enables the model to establish a more reliable initial context, which improves subsequent decisions and reduces error propagation. Answer to RQ3: Semantic similarity-based ranking is a key component of the approach, significantly improving precision and overall performance by stabilizing the iterative classification.

5.4

RQ4: Sensitivity to Implementation Variations

To assess the robustness of the proposed approach, we compare its performance across projects that share the same domain model but differ in their implementations. In our dataset, three domain models (Flexibook, Climbsafe, and CoolSupplies) are each associated with two independent implementations, allowing us to evaluate the sensitivity of the approach to variations in code structure. Performance remains consistent across different implementations of the same domain. For each of these domains, the corresponding implementations yield similar precision, recall, and F1scores across classes, attributes, and associations. This indicates that variations in code organization, naming, or implementation details have limited impact on the extracted domain models. These findings suggest that the approach captures domain-level semantics rather than relying on specific implementation patterns. In particular, the use of documentation and iterative reasoning enables the model to focus on domain concepts independently of how they are encoded in the code. Answer to RQ4: The proposed approach is robust to implementation variations, producing consistent results across different code bases that implement the same domain model.

6 Related work 6.1 AI-assisted Modeling Several works in recent years have explored the use of AI and machine learning techniques to support modeling tasks. Early approaches relied on heuristics and classical NLP techniques. For instance, [53] demonstrated the potential of such methods for domain model extraction, albeit with limited performance and generalization capabilities. With the advent of LLMs, increasing attention has been devoted to this problem [4]. Recent work has explored their use for extracting various types of models from textual requirements, including sequence diagrams [17], activity diagrams [27], use case diagrams [26], and class diagrams [4, 40]. While these approaches show strong potential, they still face challenges in achieving human-level abstractions. In this work, we focus on the extraction of domain models in the form of class diagrams, leaving the extension to other types of diagrams for future work. Indeed, prior user studies have demonstrated the potential of LLMs for assisting domain modeling tasks, both for class diagram generation [42] and completion [5].

6.2

MODELS 2026, October 04–09, 2026, Málaga, Spain

LLMs for Generating Domain Models from Textual Requirements.

Chen et al. [14] investigated the applicability of GPT-3.5 and GPT-4 for domain modeling using use cases derived from software engineering courses. Their results showed improvements over previous approaches, but also highlighted important limitations. In a followup work, Yang et al. [55] demonstrated that a multi-step, iterative approach yields better results than a holistic one (i.e., prompting an LLM to generate a complete domain diagram in a single step). This observation is further supported by Shi et al. [46], who compared different strategies for LLM-based domain modeling on similar datasets. Their results confirm that multi-step generation pipelines outperform single-step approaches. In terms of prompt engineering, they found that few-shot prompting provides the best performance. Similarly, Reinhartz-Berger et al. [44] investigated the use of LLMs (up to GPT-4) for domain modeling from textual descriptions, comparing multiple strategies. Their findings indicate that decomposing requirements into smaller units can improve requirement coverage, albeit at the risk of increased redundancy. Finally, Nguyen et al. [40] recently investigated the use of state-of-the-art LLMs (up to GPT-5) for domain diagram generation from textual requirements, as well as their use as evaluators of such diagrams. Their results showed strong performance on both tasks, although complex domains remained challenging. Overall, these works highlight the complexity of generating domain models from natural language requirements and show that decomposing the task into smaller subtasks, combined with appropriate prompting strategies, is key to achieving high-quality results. However, while prior work focuses on deriving models from textual specifications, we address a complementary and less explored problem: extracting domain models directly from source code.

6.3

AI and LLMs for Reverse Engineering

Early approaches for Model-Driven Reverse Engineering relied on heuristics and rule-based transformations to derive model elements from source code. For instance, ontology-driven and model transformation techniques have been used to filter and restructure class diagrams [10, 21], while other works employed machine learning classifiers to condense diagrams into more relevant representations [54]. More recently, Capuano et al. [13] proposed a RoBERTa-based approach [32] to generate domain models from source code. Although these approaches demonstrate the feasibility of learning abstractions from code, the resulting models often remain close to implementation-level structures, highlighting the difficulty of capturing higher-level domain concepts. With the emergence of LLMs, new opportunities have arisen for reverse engineering at higher levels of abstraction [57]. For example, Siala and Lano [47] showed that LLMs can accurately extract low-level class diagrams from source code at a level comparable to rule-based tools. LLMs have also shown promise on more complex tasks, including identifying design patterns in source code [28], extracting natural language requirements [37], and generating structural (component diagrams) and behavioral (state machine) models from code [23].

MODELS 2026, October 04–09, 2026, Málaga, Spain

LLM-assisted Domain Diagram Extraction from Code. Campanello et al. [12] explored the use of LLMs for reverse-engineering domain class diagrams. They compared different single-prompt strategies for generation from source code using proprietary LLMs up to GPT-4, reporting promising results (F1 between 62% and 75%) when comparing LLM-extracted domain diagrams with expert-curated ones. Their findings highlight persistent challenges in accurately identifying relevant domain entities and relationships. A similar approach by Boronat and Mustafa [8] employed smaller proprietary LLMs (GPT-4o-Mini and Gemini-1.5-Flash) to extract domain models from source code. To mitigate context window limitations, they adopted a retrieval-augmented generation (RAG) approach, incorporating an abstract syntax tree (AST) of the source code into the prompt. While their method shows promising results, it is primarily designed to extract diagrams at a lower level of abstraction, closely reflecting implementation details. Our work focuses on identifying which elements should be retained or abstracted away in order to capture only the concepts relevant to the application domain.

7

Discussion

This work represents an initial step towards automated reverse engineering of domain models from source code using lightweight LLMs. While the results are encouraging, several limitations also highlight opportunities for future improvements.

7.1

Threats to validity

Failure Modes and Input Representation. Errors primarily arise from ambiguity in code and limited domain signals in the documentation. When class names are unclear or overloaded, or when documentation is sparse, the model may misclassify implementation elements as domain concepts or infer spurious associations. For instance, in Figure 2, the class TOStudent is incorrectly identified as a domain class, although it corresponds to an implementation-level artifact. These limitations stem in part from the information provided to the model, which currently relies mainly on class names, documentation, and structural context. Our study does not explicitly evaluate the impact of naming quality, although we do expect performance to decrease when identifiers contain little semantic information. Consequently, naming conventions constitute only one of several signals considered by the model. Project documentation, structural information, and the contextual knowledge accumulated throughout the iterative process provide complementary sources of evidence that may compensate for moderate naming inconsistencies, although meaningful identifiers are generally expected to improve classification accuracy. In future work, richer representations could be considered, such as comments, or the class implementation. Providing more detailed code-level context could help disambiguate borderline cases and improve both classification and association inference. The robustness of the approach can also be evaluated under different naming conventions and varying levels of identifier quality, as well as with different documentation sources, such as requirements specifications, or under limited or missing documentation. Dataset and Generalizability. The evaluation is conducted on Java projects following object-oriented design principles, which aligns with our use of class diagrams. Extending the approach to

Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui

other programming paradigms, such as functional or dynamically typed languages, remains an open challenge. Moreover, the dataset consists of moderately sized academic projects with relatively wellstructured code and documentation. While this provides a controlled evaluation setting, it does not fully reflect the complexity of industrial systems, where code bases are larger and documentation is often incomplete. Future work should therefore include larger and more diverse datasets, including industrial case studies. Evaluation and Matching Strategy. Our evaluation relies on exact matching between generated elements and reference models. This strict criterion may penalize semantically equivalent but syntactically different elements. While this assumption is reasonable in our dataset, where domain concepts are reflected in class names, it may not hold in more heterogeneous systems. Future work could investigate more flexible evaluation strategies, including semantic similarity between model elements or graph-based matching techniques. Additionally, extending the approach to identify implicit domain concepts, i.e., concepts not directly mapped to a single class, remains an open challenge. LLM Variability and Stability. Finally, the approach relies on stochastic language model outputs. Although we mitigate this variability by averaging results over multiple runs, some fluctuations may still affect individual predictions. Investigating more stable prompting strategies, calibration techniques, or smaller specialized models could further improve robustness and reproducibility.

7.2

Discussion

Comparison with existing approaches. Alternative approaches exist to improve the context-handling capabilities of LLMs. However, these methods still require high-end hardware to operate effectively. For example, Qwen2.5-14B, which supports contexts of up to 1M tokens [1], can be run on our setup (four NVIDIA GeForce RTX 3090 GPUs, each with 24 GB of memory). Nevertheless, we found during our experiments that the available GPU memory is exceeded when the input exceeds 271K tokens, which remains insufficient for handling large industrial codebases. This suggests that largecontext open-source LLMs still require hardware resources that are impractical in most real-world settings in order to fully leverage their capabilities. In addition, as we discussed in Section 6, existing solutions focus on recovering implementation models or operating at different abstraction levels compared to our approach that recovers domain models from source code. Automation and human oversight. Our pipeline operates fully automatically, with limited human intervention at the final validation and refinement of the recovered domain model. However, the iterative design can be improved to support human involvement during execution. By estimating the confidence of each classification, the pipeline can identify uncertain decisions and trigger human intervention only when a confidence threshold is not met. Since later decisions build upon earlier ones, validating these lowconfidence classifications before subsequent iterations can improve downstream classifications while allowing users to balance automation and manual oversight.

Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs

7.3

Future work

Domain Modeling Subjectivity. Evaluating domain models is inherently challenging due to the absence of a single ground truth. Multiple valid models may represent the same domain at different levels of abstraction [38]. As a result, some discrepancies between generated and reference models may reflect alternative modeling choices rather than true errors. For example, the status attribute of the Order class (Figure 2) is flagged as incorrect, although it can reasonably be considered part of the domain. This observation suggests that domain model extraction should not be viewed as a fully deterministic task. Instead, future work can explore interactive or configurable approaches, where users guide the level of abstraction or validate intermediate results, enabling the generation of models that better align with specific modeling goals. Association Multiplicities. While our approach successfully retrieves associations between classes, it does not currently address the problem of identifying their multiplicities. Inferring multiplicities is particularly challenging, as this information is often implicit in the codebase and may depend on dispersed implementation details, naming conventions, or domain-specific semantics rather than explicit structural cues. As a result, reliably determining whether an association is one-to-one, one-to-many, or many-to-many requires deeper semantic understanding and contextual reasoning. Future work will investigate extending our approach to this problem by combining heuristics with LLM-based techniques. Scalability and Context Limitations. A central motivation of this work is to enable domain model extraction under limited context constraints. While the proposed iterative approach mitigates this limitation, it introduces a trade-off between locality and global reasoning. Decisions are made based on partial views of the system, which may lead to inconsistencies or suboptimal classifications. Future work can explore hybrid strategies that combine iterative reasoning with selective context expansion, for example, by dynamically retrieving relevant code fragments or using memory mechanisms to maintain a more global view of the system. Our iterative ranking and classification strategy is introduced to compensate for the limited context available to such models and constitutes the main contribution of the paper.

8

Conclusion

In this paper, we present an automated approach for reverse engineering domain models from source code using lightweight, locally deployable large language models. By combining structural and semantic heuristics with iterative LLM-based reasoning, the approach addresses a key limitation of compact models, their restricted context window, by enabling progressive identification of domain concepts and relationships without requiring full-system context. This makes it suitable for privacy-sensitive industrial environments. Our evaluation shows that the approach achieves competitive performance despite operating under constrained computational resources. These results demonstrate that carefully designed hybrid methods can compensate for the limitations of smaller models and provide a practical alternative to large proprietary systems. This work highlights the continued relevance of Model-Driven Engineering in the era of AI-assisted software engineering. While

MODELS 2026, October 04–09, 2026, Málaga, Spain

advances in LLMs may shift attention away from explicit modeling, AI can support the reconstruction, evolution, and use of domain models, reinforcing their role in the software development lifecycle. Finally, the proposed approach opens several opportunities. It can support educational settings by lowering the barrier to modeling, facilitating downstream tasks such as test generation through richer domain representations, and improving human–AI collaboration by making domain knowledge more explicit and structured. More broadly, automating parts of the modeling process has the potential to reduce effort and improve consistency, contributing to more efficient modeling practices.

References [1] Imtiaz Ahmed, Sadman Islam, Partha Protim Datta, Imran Kabir, Naseef Ur Rahman Chowdhury, and Ahshanul Haque. 2025. Qwen 2.5: A comprehensive review of the leading resource-efficient llm with potentioal to surpass all competitors. Authorea Preprints (2025). [2] Domenico Amalfitano, Andreas Metzger, Marco Autili, Tommaso Fulcini, Tobias Hey, Jan Keim, Patrizio Pelliccione, Vincenzo Scotti, Anne Koziolek, Raffaela Mirandola, et al. 2026. A Research Roadmap for Augmenting Software Engineering Processes and Software Products with Generative AI. ACM Transactions on Software Engineering and Methodology (2026). [3] Shengnan An, Zexiong Ma, Zeqi Lin, Nanning Zheng, Jian-Guang Lou, and Weizhu Chen. 2024. Make your llm fully utilize the context. Advances in Neural Information Processing Systems 37 (2024), 62160–62188. [4] Léna Bamouh, Thibault Béziers La Fosse, and Massimo Tisi. 2025. Towards Diagram-Based Data Model Generation with LLMs. In International Conference on Conceptual Modeling. Springer, 157–175. [5] Meriem Ben Chaaben, Lola Burgueño, Istvan David, and Houari Sahraoui. 2025. On the Utility of Domain Modeling Assistance with Large Language Models. ACM Trans. Softw. Eng. Methodol. (June 2025). https://doi.org/10.1145/3744920 [6] Luca Berardinelli, Vittoriano Muttillo, Romina Eramo, Hugo Bruneliere, Abbas Rahimi, Antonio Cicchetti, Joan Giner-Miguelez, Abel Gomez, Pasqualina Potena, and Mehrdad Saadatmand. 2025. Model driven engineering, artificial intelligence, and devops for software and systems engineering: A systematic mapping study of synergies and challenges. ACM Transactions on Software Engineering and Methodology (2025). [7] Rishi Bommasani, Drew A Hudson, Ehsan Adeli, Russ Altman, Simran Arora, Sydney von Arx, Michael S Bernstein, Jeannette Bohg, Antoine Bosselut, Emma Brunskill, et al. 2021. On the opportunities and risks of foundation models. arXiv preprint arXiv:2108.07258 (2021). [8] Artur Boronat and Jawad Mustafa. 2025. MDRE-LLM: A tool for analyzing and applying llms in software reverse engineering. In 2025 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 850–854. [9] Manfred Broy. 2013. Domain modeling and domain engineering: Key tasks in requirements engineering. In Perspectives on the Future of Software Engineering: Essays in Honor of Dieter Rombach. Springer, 15–30. [10] Hugo Bruneliere, Jordi Cabot, Grégoire Dupé, and Frédéric Madiot. 2014. Modisco: A model driven reverse engineering framework. Information and Software Technology 56, 8 (2014), 1012–1032. [11] Alessio Bucaioni, Antonio Cicchetti, Gordana Dodig Crnkovic, Romina Spalazzese, Emma Söderberg, and Dániel Varró. 2025. Engineering Future Critical CPSs with Trustworthy GenAI Across the Lifecycle. (2025). [12] Victor Campanello, Shariq Shahbaz, Vladislav Indykov, and DGF Strüber. 2025. On the use of GPT-4 in the reverse engineering of class diagrams. Journal of Object Technology (2025). [13] Thibaut Capuano, Houari Sahraouiand Benoit Frenay, and Benoit Vanderose. 2022. Learning from Code Repositories to Recommend Model Classes. Journal of Object Technology 21, 3 (2022). [14] Kua Chen, Yujing Yang, Boqi Chen, José Antonio Hernández López, Gunter Mussbacher, and Dániel Varró. 2023. Automated domain modeling with large language models: A comparative study. In 2023 ACM/IEEE 26th International Conference on Model Driven Engineering Languages and Systems (MODELS). IEEE, 162–172. [15] Duy Dao, Alessio Bucaioni, and Antonio Cicchetti. 2025. Learning to Transform: Evaluating LLMs on Model Transformation by Example. In 2025 ACM/IEEE 28th International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). IEEE, 576–585. [16] Eric Evans. 2004. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional. [17] Alessio Ferrari, Sallam Abualhaijal, and Chetan Arora. 2024. Model generation with LLMs: From requirements to UML sequence diagrams. In 2024 IEEE 32nd

MODELS 2026, October 04–09, 2026, Málaga, Spain

International Requirements Engineering Conference Workshops (REW). IEEE, 291– 300. [18] Naofumi Fujishiro, Yasuhiro Otaki, and Shoji Kawachi. 2023. Accuracy of the sentence-BERT semantic search system for a Japanese database of closed medical malpractice claims. Applied Sciences 13, 6 (2023), 4051. [19] Mauro Giuffrè, Simone Kresevic, Nicola Pugliese, Kisung You, and Dennis L Shung. 2024. Optimizing large language models in digestive disease: strategies and challenges to improve clinical outcomes. Liver International 44, 9 (2024), 2114–2124. [20] Larissa Guder, João Paulo Aires, Hígor Uélinton da Silva, Felipe Meneguzzi, and Dalvan Griebler. 2026. Sentence representations for semantic textual similarity: A systematic review. Computer Speech & Language (2026), 101970. [21] Giancarlo Guizzardi, Guylerme Figueiredo, Maria M Hedblom, and Geert Poels. 2019. Ontology-based model abstraction. In 2019 13th International Conference on Research Challenges in Information Science (RCIS). IEEE, 1–13. [22] Mandy Guo, Joshua Ainslie, David C Uthus, Santiago Ontanon, Jianmo Ni, YunHsuan Sung, and Yinfei Yang. 2022. LongT5: Efficient text-to-text transformer for long sequences. In Findings of the Association for Computational Linguistics: NAACL 2022. 724–736. [23] Ahmad Hatahet, Christoph Knieke, and Andreas Rausch. 2025. Generating Software Architecture Description from Source Code using Reverse Engineering and Large Language Model. In 2025 ACM/IEEE 28th International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). IEEE, 566–575. [24] Yutan Huang, Chetan Arora, Wen Cheng Huong, Tanjila Kanij, Anuradha Madugalla, and John Grundy. 2026. Ethical concerns of generative AI and mitigation strategies: A systematic mapping study. Applied Soft Computing (2026), 114789. [25] Oseremen Joy Idialu, Noble Saji Mathews, Rungroj Maipradit, Joanne M Atlee, and Mei Nagappan. 2024. Whodunit: Classifying Code as Human Authored or GPT-4 generated-A case study on CodeChef problems. In Proceedings of the 21st International Conference on Mining Software Repositories. 394–406. [26] Pragyan KC, Rocky Slavin, Sepideh Ghanavati, Travis Breaux, and Mitra Bokaei Hosseini. 2024. An Analysis of Automated Use Case Component Extraction from Scenarios using ChatGPT. arXiv preprint arXiv:2408.03395 (2024). [27] Parham Khamsepour, Mark Cole, Ish Ashraf, DaYuan Tan, Sandeep Puri, Mehrdad Sabetzadeh, and Shiva Nejati. 2025. The Impact of Critique on LLM-Based Model Generation from Natural Language: The Case of Activity Diagrams. arXiv preprint arXiv:2509.03463 (2025). [28] Sirojiddin Komolov, Manuel Mazzara, and Imran Sarwar Bajwa. 2026. Design Pattern Prediction From Source Code Using LLM–Based Feature Engineering and SVM Classification. IET Software 2026, 1 (2026), 7163249. [29] Rainer Koschke. 2006. Architecture reconstruction: Tutorial on reverse engineering to the architectural level. International Summer School on Software Engineering (2006), 140–173. [30] Minyoung Kyoung, Joon-Ho Lim, and Youngsoo Kim. 2025. Reasoning Beyond Length Limits: Improving Accuracy in Long-Context Question Answering with Small-Scale Language Models. IEEE Access (2025). [31] Timothy C Lethbridge, Andrew Forward, Omar Badreddin, Dusan Brestovansky, Miguel Garzon, Hamoud Aljamaan, Sultan Eid, Ahmed Husseini Orabi, Mahmoud Husseini Orabi, Vahdat Abdelzad, et al. 2021. Umple: Model-driven development for open source and education. Science of Computer Programming 208 (2021), 102665. [32] Yinhan Liu, Myle Ott, Naman Goyal, Jingfei Du, Mandar Joshi, Danqi Chen, Omer Levy, Mike Lewis, Luke Zettlemoyer, and Veselin Stoyanov. 2019. Roberta: A robustly optimized bert pretraining approach. arXiv preprint arXiv:1907.11692 (2019). [33] Long Ma and Yanqing Zhang. 2015. Using Word2Vec to process big text data. In 2015 IEEE international conference on big data (Big Data). IEEE, 2895–2897. [34] Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui. 2026. Towards Automated Domain Model Extraction from Source Code using Heuristics and Open-Source LLMs (Replication Package). https://doi.org/10. 5281/zenodo.19324631 [35] Judith Michael, Loek Cleophas, Steffen Zschaler, Tony Clark, Benoit Combemale, Thomas Godfrey, Djamel Eddine Khelladi, Vinay Kulkarni, Daniel Lehner, Bernhard Rumpe, et al. 2026. About Opportunities and Challenges in Model-Driven Engineering for Digital Twins–. Modellierung 2026 (2026), 155–156. [36] Tomas Mikolov, Kai Chen, Greg Corrado, and Jeffrey Dean. 2013. Efficient estimation of word representations in vector space. arXiv preprint arXiv:1301.3781 (2013). [37] Cameron Miskell, Richard Diaz, Parth Ganeriwala, Khaled Slhoub, and Fitzroy Nembhard. 2023. Automated framework to extract software requirements from source code. In Proceedings of the 2023 7th International Conference on Natural Language Processing and Information Retrieval. 130–134. [38] Parastoo Mohagheghi and Vegard Dehlen. 2008. Where is the proof?-a review of experiences from applying mde in industry. In European Conference on Model Driven Architecture-Foundations and Applications. Springer, 432–443.

Alessandra Mancas, Mounir Ammam, Hyacinth Ali, Kevin Delcourt, and Houari Sahraoui

[39] Humza Naveed, Asad Ullah Khan, Shi Qiu, Muhammad Saqib, Saeed Anwar, Muhammad Usman, Naveed Akhtar, Nick Barnes, and Ajmal Mian. 2025. A comprehensive overview of large language models. ACM Transactions on Intelligent Systems and Technology 16, 5 (2025), 1–72. [40] Jackson Nguyen, Rui En Koe, Fanyu Wang, Chetan Arora, and Alessio Ferrari. 2026. Class Model Generation from Requirements using Large Language Models. (2026). [41] Arka Pal, Deep Karkhanis, Manley Roberts, Samuel Dooley, Arvind Sundararajan, and Siddartha Naidu. 2023. Giraffe: Adventures in expanding context lengths in llms. arXiv preprint arXiv:2308.10882 (2023). [42] Francisco Javier Pérez-Blanco, Juan Manuel Vara, Cristian Gómez-Macías, David Granada, and Carlos Villarrubia. 2025. Empowering Service Designers with Integrated Modelling Tools: A Model-Driven Approach. Systems 13, 12 (2025), 1107. [43] Asha Rajbhoj, Akanksha Somase, Tanay Sant, Ajim Pathan, Purvesh Doud, and Vinay Kulkarni. 2025. Leveraging LLM for software modernization: COBOL Functionality Extraction Case study. In 2025 40th IEEE/ACM International Conference on Automated Software Engineering Workshops (ASEW). IEEE, 14–21. [44] Iris Reinhartz-Berger, Syed Juned Ali, and Dominik Bork. 2025. Leveraging LLMs for domain modeling: the impact of granularity and strategy on quality. In International conference on advanced information systems engineering. Springer, 3–19. [45] James Rumbaugh. 2005. The unified modeling language reference manual. Pearson Education India. [46] Haoran Shi, Shijun Liu, and Li Pan. 2025. How LLMs Aid in Domain Modeling: Opportunities and Challenges. In 2025 IEEE International Conference on Software Services Engineering (SSE). IEEE, 202–210. [47] Hanan Abdulwahab Siala and Kevin Lano. 2025. Leveraging Llms for Abstracting Uml and Ocl Representations From Java and Python Programs. Available at SSRN 5348203 (2025). [48] Hanan Abdulwahab Siala, Kevin Lano, and Hessa Alfraihi. 2024. Model-driven approaches for reverse engineering—a systematic literature review. IEEE Access 12 (2024), 62558–62580. [49] Margaret-Anne Storey. 2026. From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI. arXiv preprint arXiv:2603.22106 (2026). [50] Zhen Tan, Dawei Li, Song Wang, Alimohammad Beigi, Bohan Jiang, Amrita Bhattacharjee, Mansooreh Karami, Jundong Li, Lu Cheng, and Huan Liu. 2024. Large language models for data annotation and synthesis: A survey. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing. 930– 957. [51] Duyu Tang, Bing Qin, and Ting Liu. 2015. Document modeling with gated recurrent neural network for sentiment classification. In Proceedings of the 2015 conference on empirical methods in natural language processing. 1422–1432. [52] Andrzej Wąsowski and Thorsten Berger. 2023. Domain Analysis and Abstract Syntax. In Domain-Specific Languages: Effective Modeling, Automation, and Reuse. Springer, 47–85. [53] Song Yang and Houari Sahraoui. 2022. Towards automatically extracting UML class diagrams from natural language specifications. In Proceedings of the 25th International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings. 396–403. [54] Xinli Yang, David Lo, Xin Xia, and Jianling Sun. 2016. Condensing class diagrams with minimal manual labeling cost. In 2016 IEEE 40th Annual Computer Software and Applications Conference (COMPSAC), Vol. 1. IEEE, 22–31. [55] Yujing Yang, Boqi Chen, Kua Chen, Gunter Mussbacher, and Dániel Varró. 2024. Multi-step iterative automated domain modeling with large language models. In Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems. 587–595. [56] JunWeon Yoon, TaeYoung Hong, ChanYeol Park, Seo-Young Noh, and HeonChang Yu. 2020. Log analysis-based resource and execution time improvement in HPC: a case study. Applied Sciences 10, 7 (2020), 2634. [57] Wenli Zhang, Weixing Zhang, Daniel Strüber, and Regina Hebig. 2025. An empirical study of manual abstraction between class diagrams and code of opensource systems. Software and Systems Modeling 24, 6 (2025), 1797–1823. [58] Yizhe Zhang, Zhe Gan, Kai Fan, Zhi Chen, Ricardo Henao, Dinghan Shen, and Lawrence Carin. 2017. Adversarial feature matching for text generation. In International conference on machine learning. PMLR, 4006–4015. [59] Zeyu Zhang, Quanyu Dai, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Jieming Zhu, Zhenhua Dong, and Ji-Rong Wen. 2025. A survey on the memory mechanism of large language model-based agents. ACM Transactions on Information Systems 43, 6 (2025), 1–47. [60] Vitalii Zhelezniak, Aleksandar Savkov, April Shen, and Nils Hammerla. 2019. Correlation coefficients and semantic textual similarity. In Proceedings of the 2019 conference of the north American chapter of the association for computational linguistics: Human language technologies, volume 1 (long and short papers). 951– 962.

Related documents

• SLRMentor: An LLM-Based Tool Supporting Learning of SLR in Software Engineering#267737
• Towards Knowledge Alignment in Code LLMs: Contrastive Unlearning for Evolving APIs#324973
• Automated program synthesis from natural language for domain specific computing … — Virginia Tech Intellectual Properties, Inc. (US10843080B2)#607296
• Program Analysis Guided LLM Agent for Proof-of-Concept Generation#2686
• Code Transformation Rule Synthesis using LLMs: Potential and Limits#926496