Статья опубликована в рамках: CIV Международной научно-практической конференции «Вопросы технических и физико-математических наук в свете современных исследований» (Россия, г. Новосибирск, 26 октября 2026 г.)
Наука: Информационные технологии
Секция: Системы автоматизации проектирования
Скачать книгу(-и): Скачать книгу
дипломов
ВОЗМОЖНОСТИ И ОГРАНИЧЕНИЯ ПРИМЕНЕНИЯ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА ПРИ ПРОВЕРКЕ UML-МОДЕЛЕЙ
CAPABILITIES AND LIMITATIONS OF USING ARTIFICIAL INTELLIGENCE IN VERIFYING UML MODELS
Аннотация
В статье рассматриваются возможности использования больших языковых моделей для проверки UML-диаграмм и ограничения такого подхода. Цель работы – определить, какие ошибки можно обнаружить с помощью формальных правил, а в каких случаях требуется анализ содержания модели. Для этого рассмотрены пять научных публикаций, посвящённых применению языковых моделей в UML-моделировании. Также приведён пример диаграммы вариантов использования, на котором разобраны три ситуации: неправильное использование связи, возможное дублирование вариантов использования и отсутствие функции, необходимость которой нельзя установить без дополнительных требований. На основе проведённого анализа предложены требования к представлению замечаний и рекомендации по совместному применению формальных проверок и языковых моделей.
Abstract
The article examines the possibilities of using large language models to verify UML diagrams and the limitations of this approach. The aim of the work is to determine which errors can be detected using formal rules, and in which cases an analysis of the model’s content is required. To this end, five scientific publications devoted to the use of language models in UML modeling are reviewed. An example of a use case diagram is also provided, which examines three situations: incorrect use of a relationship, possible duplication of use cases, and the absence of a function whose necessity cannot be established without additional requirements. Based on the analysis conducted, requirements for submitting comments and recommendations for the joint use of formal checks and language models have been proposed.
Ключевые слова: UML, варианты использования, большие языковые модели, проверка моделей.
Keywords: use cases, large language models, model checking.
Введение и подход к анализу
При проверке UML-моделей могут возникать разные виды ошибок. Некоторые из них можно определить по правилам нотации, например неправильное использование связей между элементами. Другие ошибки связаны с содержанием диаграммы. Чтобы определить, дублируют ли два варианта использования друг друга или все ли необходимые функции представлены в модели, нужно учитывать сценарии и требования к системе. Даже если диаграмма построена без нарушений правил UML [1], это не означает, что она полностью соответствует требованиям к разрабатываемой системе. Аналогичная проблема возникает при использовании больших языковых моделей (LLM): они могут предложить объяснение возможной ошибки, но его правильность необходимо проверять.
Для достижения поставленной цели рассмотрены пять научных публикаций 2023–2026 годов. Работы сравнивались по решаемым задачам, результатам и ограничениям, особое внимание уделялось применимости рассмотренных подходов к проверке диаграмм вариантов использования. Исследование ограничено анализом публикаций и авторского примера; разработка программного средства и эксперименты с LLM не проводились.
Сопоставление опубликованных подходов
Cámara и соавторы исследовали возможности ChatGPT при выполнении задач UML и OCL [2]. Авторы отмечают, что полученные результаты не всегда соответствуют правилам используемых языков и требуют дополнительной проверки. Однако работа не оценивает способность LLM самостоятельно обнаруживать ошибки в готовых диаграммах и относится к ранней версии ChatGPT.
Wang и соавторы изучали применение LLM при построении UML-диаграмм начинающими аналитиками [3]. В исследовании участвовали 45 студентов, создававших диаграммы вариантов использования, классов и последовательностей. Авторы оценивали корректность моделей по отдельным критериям, включая определение акторов, вариантов использования и связей. Результаты показали, что LLM могут помогать при моделировании, но не исключают ошибок. При этом оценивалась совместная работа человека и LLM, а не самостоятельная проверка готовых диаграмм.
De Bari и соавторы сравнивали результаты выполнения 20 заданий по построению UML-диаграмм классов с использованием LLM и человеком [4]. Исследование показывает, что при создании моделей могут возникать как нарушения правил нотации, так и ошибки в содержании. Однако работа посвящена диаграммам классов, поэтому её результаты нельзя напрямую переносить на диаграммы вариантов использования.
Wang и соавторы исследовали автоматизированное оценивание UML-диаграмм с помощью GPT [5]. Авторы проанализировали 40 студенческих отчётов по 11 критериям и сравнили результаты с экспертными оценками. Однако близость итоговых баллов не означает, что система правильно обнаруживает каждое нарушение: отдельные ошибки могут быть пропущены даже при совпадении общей оценки. Поэтому для проверки UML-моделей необходимо оценивать правильность конкретных замечаний.
Ardimento и соавторы представили UML Miner — инструмент для анализа действий пользователя при построении UML-диаграмм и формирования рекомендаций с помощью LLM [6]. В исследовании участвовали 94 студента, работавших с диаграммами классов и вариантов использования. Проверка заданных ограничений сочетается с использованием RAG для подготовки пояснений. Понятность обратной связи студенты оценили в среднем на 4,46 балла из 5. Однако эта оценка характеризует восприятие рекомендаций, а не точность обнаружения ошибок в готовой диаграмме.
Сравнение работ показывает, что LLM применяются для создания UML-диаграмм, поддержки пользователей, оценивания моделей и формирования обратной связи. Однако рассмотренные исследования не дают единой оценки точности обнаружения ошибок. Поэтому при разработке средства проверки важно разделять нарушения формальных правил UML и содержательные проблемы, для оценки которых могут потребоваться требования и описания сценариев. Формальные ограничения позволяют выявлять известные нарушения, а LLM может использоваться для анализа содержания и объяснения возможных ошибок с учётом доступной информации.
Таблица 1.
Задачи исследований и границы выводов
| Работа | Задача | Граница вывода |
|---|---|---|
| Cámara [2] | Применение ChatGPT к UML/OCL | Не оценивается поиск ошибок в готовых моделях |
| Wang [3] | Построение трёх типов UML-диаграмм с помощью LLM | Не оценивалась самостоятельная проверка готовых моделей |
| De Bari [4] | Построение диаграмм классов | Результаты не проверялись на Use Case |
| Wang [5] | Автоматизированное оценивание UML | Общая оценка не отражает точность выявления отдельных ошибок |
| Ardimento [6] | Анализ процесса моделирования и обратная связь | Оценка рекомендаций не равна точности обнаружения ошибок |
Аналитический разбор и требования к замечаниям
Рассмотрим авторский пример диаграммы вариантов использования интернет-магазина (рисунок 1). В нём выделены три ситуации: нарушение правил использования отношения include (B1), возможное дублирование вариантов использования (B2) и отсутствие функции возврата товара (B3). Для оценки двух последних ситуаций необходимы дополнительные сведения о сценариях и требованиях. Пример носит аналитический характер и не является результатом работы LLM.
В ситуации B1 актор «Покупатель» связан с вариантом использования «Оформить заказ» отношением include. Согласно спецификации UML, такое отношение должно соединять два варианта использования [1]. Следовательно, в данном случае допущена ошибка, которую можно обнаружить с помощью формальной проверки типов элементов. Однако для выбора правильного исправления необходимо понимать, какую связь хотел показать автор диаграммы. Если покупатель участвует в оформлении заказа, следует использовать ассоциацию. Если предполагалось включение другого варианта использования, нужно изменить структуру связи.
В ситуации B2 рассматриваются варианты использования «Войти в систему» и «Авторизоваться». Их названия близки по смыслу, поэтому возникает предположение, что они могут описывать одно и то же действие. Однако по одним названиям нельзя определить, действительно ли сценарии дублируются. Например, вход в систему может включать проверку учётных данных, а авторизация – проверку прав пользователя на выполнение определённых действий. Чтобы сделать вывод, необходимо сравнить цели, предусловия и основные шаги обоих сценариев. Пока эта информация отсутствует, объединять варианты использования нельзя. Языковая модель может обратить внимание пользователя на сходство названий, но не должна представлять его как подтверждённую ошибку.
В ситуации B3 на диаграмме отсутствует вариант использования, связанный с возвратом товара. Для интернет-магазина такая функция может быть необходима, однако её отсутствие не всегда является ошибкой. Например, возврат может рассматриваться в другой части системы или не входить в задачи, описываемые данной диаграммой. Поэтому сначала нужно обратиться к требованиям и определить, должна ли эта функция присутствовать в модели. Если требования неизвестны, сделать однозначный вывод о неполноте диаграммы нельзя. В таком случае система проверки должна сообщить о необходимости уточнения требований, а не автоматически добавлять отсутствующий вариант использования.
Рассмотренные ситуации показывают, что нарушения правил UML можно выявлять с помощью формальных ограничений, а для поиска возможных смысловых ошибок использовать LLM. При этом её выводы необходимо сопоставлять с требованиями и сценариями, а решение об исправлении модели должен принимать пользователь. Каждое замечание должно содержать указание на элемент модели, основание проблемы и её статус. При недостатке информации система должна сообщать об этом, а рекомендации по исправлению следует отделять от описания ошибки. Результаты проверки необходимо связывать с конкретной версией диаграммы и обновлять после изменений. Если LLM недоступна, формальные проверки должны оставаться доступными.
Заключение
Анализ пяти публикаций показал, что LLM могут помогать при создании UML-диаграмм и формировании рекомендаций. Однако рассмотренные исследования не позволяют оценить точность самостоятельного обнаружения отдельных ошибок в готовых моделях, поскольку посвящены другим задачам.
На примере диаграммы вариантов использования показано, что одни нарушения можно установить по правилам UML, а другие требуют анализа сценариев и требований. Поэтому при проверке важно различать подтверждённые ошибки, возможные проблемы и случаи недостаточности информации. Совместное применение формальных правил и LLM может использоваться при разработке интеллектуального средства визуального моделирования, но его эффективность необходимо оценить экспериментально.
Список литературы
- Object Management Group. OMG Unified Modeling Language. Version 2.5.1 [Электронный ресурс]. – 2017. – URL: https://www.omg.org/spec/UML/2.5.1/PDF (дата обращения: 23.10.2026).
- Cámara J., Troya J., Burgueño L., Vallecillo A. On the assessment of generative AI in modeling tasks: an experience report with ChatGPT and UML // Software and Systems Modeling. – 2023. – Т. 22. – P. 781–793. – DOI: 10.1007/s10270-023-01105-5.
- Wang B., Wang C., Liang P., Li B., Zeng C. How LLMs Aid in UML Modeling: An Exploratory Study with Novice Analysts // 2024 IEEE International Conference on Software Services Engineering (SSE). – 2024. – P. 249–257. – DOI: 10.1109/SSE62657.2024.00046.
- De Bari D., Garaccione G., Coppola R., Ardito L., Torchiano M. Evaluating Large Language Models in Exercises of UML Class Diagram Modeling // ESEM ’24. – 2024. – P. 393–399. – DOI: 10.1145/3674805.3690741.
- Wang C., Wang B., Liang P., Liang J. Assessing UML diagrams by GPT: Implications for education // Journal of Systems and Software. – 2026. – Т. 234. – Art. 112709. – DOI: 10.1016/j.jss.2025.112709.
- Ardimento P., Bernardi M.L., Cimitile M., Scalera M. A conversational tool for AI-driven feedback for UML modeling // Software and Systems Modeling. – 2026. – DOI: 10.1007/s10270-026-01373-x.
дипломов