MAS4SysML: Wieloagentowy framework do generowania modeli SysML v2 z języka naturalnego

Summary

Protokół ten prezentuje MAS4SysML, podejście wieloagentowe, które automatycznie generuje kod SysML v2 poprzez skoordynowany podział zadań, wymagając niewielu iteracji naprawczych i znacząco skracając czas ręcznego modelowania, jednocześnie poprawiając efektywność modelowania systemowego.

Abstract

Automatyczne generowanie dokładnych modeli SysML na podstawie wymagań języka naturalnego może znacząco przyspieszyć wdrażanie inżynierii systemów opartych na modelach (MBSE) w rozwoju złożonych systemów. Jednak korzystanie z dużych modeli językowych (LLM) do generowania kodu modelu często nie spełnia ścisłych ograniczeń składniowych formalnych języków modelowania, a konsekwentne zapewnienie semantycznego dopasowania między generowanymi modelami a wymaganiami pozostaje wyzwaniem. Aby sprostać tym wyzwaniom, artykuł przedstawia MAS4SysML, wieloagentowy framework współpracy do generowania kodu SysML v2, który poprawia poprawność składniową i spójność semantyczną przy ograniczonym budżecie napraw. Framework rozkłada zadanie modelujące na hierarchiczne podzadania, formalizuje je jako strukturalne karty zadań i generuje kod modelu w sposób oddolny. Podczas generowania używa się oficjalnego środowiska walidacyjnego do diagnostyki składni; Po ukończeniu framework weryfikuje spójność semantyczną między kodem a kartami zadań. Jeśli walidacja składni lub semantyczna zawodzi, ramy iteracyjnie naprawiają i rewalidują kod w ramach ustalonego budżetu napraw, kierując się informacjami zwrotnymi diagnostycznymi, aż do spełnienia kryteriów walidacji lub wyczerpania budżetu. Aby ocenić proponowaną metodę, tworzymy zbiór danych SysML v2 obejmujący pięć podstawowych typów zadań — wymagania, przypadki użycia, strukturę, parametrykę i maszyny stanów — oraz przeprowadzamy eksperymenty porównawcze. Wyniki pokazują, że MAS4SysML zmniejsza średni wskaźnik błędów składniowych do 2,63, zwiększa podobieństwo semantyczne do 0,91 i przewyższa istniejące metody generowania kodu ogólnie.

Introduction

MBSE stało się kluczową metodologią analizy wymagań, projektowania architektury systemów oraz planowania weryfikacji w rozwoju złożonego sprzętu w dziedzinach takich jak lotnictwoⁱ kosmonautyka. Korzystając z jednolitych języków modelowania, takich jak SysML, jako szkieletu modelowania, informacje — w tym wymagania, struktura, zachowanie i ograniczenia — mogą być organizowane w spójny model framework, poprawiając strukturę procesów i efektywność współpracy interdyscyplinarnej². Jednak wraz ze wzrostem skali systemu, liczba modeli, które trzeba opracować, rośnie odpowiednio, co prowadzi do stałego wzrostu obciążenia ręcznego modelowania SysML. Ponadto modelarze muszą pracować w ścisłych warunkach składniowych i metodologicznych, co wymaga znacznej wiedzy i silnych umiejętności abstrakcyjnych. Te czynniki stały się głównym wąskim gardłem w inżynierskim wdrażaniu MBSE³.

W ostatnich latach LLM wykazały się silnymi umiejętnościami w rozumieniu języka naturalnego, strukturyzowanej reprezentacji informacji oraz generowaniu kodu, co umożliwia automatyzację modelowania MBSE od języka naturalnego do kodu modelu⁴. Wcześniejsze badania dotyczyły bezpośredniego generowania kodu modelu SysML przy użyciu LLM-ów⁵. Niemniej jednak pozostają poważne wyzwania. Składniowo, system typów, mechanizmy zakresu oraz semantyka referencyjna SysML są regulowane przez ścisłe formalne ograniczenia i często są bardziej złożone niż w językach programowania ogólnego przeznaczenia⁶. Semantycznie LLM mogą nie w pełni uchwycić logiki behawioralnej, relacji strukturalnych i ograniczeń międzywarstwowych, co skutkuje brakującymi relacjami, niespójnościami logicznymi lub niekompletnymi modelami⁷. Te ograniczenia utrudniają niezawodność, sterowalność i interpretowalność podejść generowania bezpośredniego.

Aby sprostać tym wyzwaniom, niniejszy artykuł przedstawia MAS4SysML, framework generowania kodu SysML v2 obejmujący cztery role agentów. Zamiast bezpośrednio celować w jednorazowe generowanie kompletnego modelu systemu cross-view, badanie skupia się na generowaniu i iteracyjnej naprawie wielu reprezentatywnych zadań modelowania SysML v2. Napędzany dekompozycją zadań i ustrukturyzowanymi kartami zadań, integrując generowanie kodu, diagnostykę składni na poziomie narzędzi oraz weryfikację spójności semantycznej, MAS4SysML ustanawia zamknięty pętli procesu generowania, walidacji i naprawy. Ten projekt poprawia poprawność składniową, spójność semantyczną oraz strukturalną kompletność generowanego kodu przy ograniczonym budżecie napraw.

Główne osiągnięcia są podsumowane następująco: (1) framework MAS4SysML. Proponujemy MAS4SysML, wieloagentowy framework oparty na LLM, który umożliwia generowanie od końca do końca od wymagań w języku naturalnym do wykonywalnego kodu modelu SysML v2, oferując praktyczną ścieżkę obniżenia kosztów modelowania i poprawy efektywności modelowania. (2) Parsowanie zadań i walidacja dualna. Wprowadzamy mechanizm parsowania struktura zadań i drzewo oraz schemat dualnej walidacji (składnia i semantyka). W parsowaniu zadań cele modelowania są hierarchicznie rozkładane i formalizowane na ustrukturyzowane karty zadań. Do walidacji diagnostyka składniowa wykorzystuje oficjalne środowisko walidacyjne⁸ do sprawdzania wygenerowanego kodu i zwracania diagnostyki nastawionej na naprawę, podczas gdy walidacja semantyczna wykorzystuje kluczowe pola na kartach zadań jako odniesienia do oceny ogólnej spójności między wygenerowanym modelem a celami modelowania. (3) Ocena eksperymentalna. Prowadzimy eksperymenty porównawcze, wykorzystując wskaźnik błędów składni i wynik spójności semantycznej jako główne wskaźniki. Wyniki pokazują, że MAS4SysML zmniejsza średni wskaźnik błędów składniowych do 2,63 i zwiększa podobieństwo semantyczne do 0,91, przewyższając metody bazowe pod względem dokładności generowania i automatyzacji.

Protocol

Proces generowania kodu w ramach MAS4SysML jest podsumowany w Pliku Uzupełniającym 1. Należy zauważyć, że badanie nie ma na celu jednorazowego wygenerowania kompletnego modelu systemu z języka naturalnego z ścisłą spójnością widoków krzyżowych, obejmującą wymagania, strukturę, parametrykę i zachowanie. Zamiast tego protokół koncentruje się na generowaniu kilku reprezentatywnych typów kodu widokowego SysML v2.

Faza I: Analiza zadań
Workflow zaczyna się od parsowania zadań. System dostarcza zamysł modelowania w języku naturalnym dla Agenta Generowania Struktury Zadań, który generuje zestaw kart zadań. Aby zapewnić, że kolejne generacje będą wykonywalne i powtarzalne, każda karta zadania musi zawierać co najmniej (i) identyfikator zadania, (ii) zależności zależności oraz (iii) kluczowe informacje modelujące do walidacji, takie jak cel modelowania, ograniczenia/warunki brzegowe, sloty parametrów, wartości instancji oraz oczekiwane wyjścia. Ten etap generuje task_card_set, który stanowi jednolitą podstawę do kolejnego generowania kodu modelowego.

Faza II: Iteracyjne generowanie kodu
W generowaniu iteracyjnym system inicjalizuje kontekst kodu prev_code do stanu pustego i generuje kod dla każdej karty zadania kolejno zgodnie z kolejnością wyznaczoną przez pola zależności. Dla każdej karty zadania Agent Generowania Kodu przyjmuje bieżącą kartę zadania oraz kod kontekstowy jako wejście, aby wygenerować candidate_code, a następnie natychmiast wywołuje moduł walidacji składni do sprawdzenia. Moduł waliduje kod za pomocą oficjalnego środowiska walidacyjnego SysML v2 i zwraca wyniki diagnostyczne. Jeśli walidacja się powiedzie, candidate_code jest używany do aktualizacji prev_code i wspiera kolejne generacje. Jeśli walidacja się nie powiedzie, uruchamiany jest Agent Naprawy Kodu i wykonuje minimalne, ukierunkowane edycje na podstawie zwróconej diagnostyki, po czym naprawiony kod jest ponownie przesyłany do ponownej walidacji. Ta pętla rewalidacji napraw jest ograniczona maksymalnym budżetem naprawczym _{K max}. Jeśli weryfikacja zakończy się w ramach budżetu, wersja przechodząca aktualizuje się prev_code; w przeciwnym razie, po próbach K_max, system rejestruje awarię i kontynuuje generowanie kart zadań, używając ostatniej naprawionej wersji prev_code, aby uniknąć blokowania przepływu pracy przy zachowaniu ciągłości kontekstowej.

Faza III: Walidacja semantyczna
Po wygenerowaniu kodu dla wszystkich kart zadań, workflow przechodzi do weryfikacji semantycznej. Agent walidacji semantycznej ocenia spójność między końcowym kodem a zamiarem modelowania, używając kluczowych pól w task_card_set jako odniesień i generuje wyniki walidacji semantycznej. Jeśli walidacja się powiedzie, prev_code jest akceptowany jako ostateczny model modelu SysML v2. W przeciwnym razie system generuje Raport Odchyleń Semantycznych, który identyfikuje niespełnione pola karty zadań oraz wymagany zakres rewizji. Agent naprawy kodu następnie odpowiednio poprawia kod i generuje zrewidowany kod modelu jako końcowy wynik.

Architektura i metodologia modelu
Architektura modelu
Ramowy system MAS4SysML, zilustrowany na Rysunku 1, składa się z czterech agentów współpracy: agenta generującego strukturę zadań, agenta generującego kod, agenta naprawy kodu oraz agenta walidacji semantycznej. Odpowiadające szablony promptów przedstawiono na Rysunku 2.

Agent generujący strukturę zadania wykonuje analizę semantyczną intencji modelowania wejściowego oraz generuje wykonywalne, strukturalne karty zadań. Najpierw stosuje mechanizm hierarchicznej dekompozycji zadań (patrz mechanizm hierarchicznej dekompozycji zadań), aby rozłożyć ogólny cel modelowania na węzły zadań o dobrze określonych granicach semantycznych, a następnie konstruuje dla każdego węzła ustrukturyzowaną kartę zadania. Następnie karty zadań są uporządkowane zgodnie z polami zależności modelowania, aby zapewnić, że sekwencja wykonania jest zgodna z ostateczną strukturą kodu, tworząc tym samym fundament dla generowania kodu oddolnego napędzanego globalnym celem modelowania.

Agent generujący kod stopniowo generuje kod modelu zgodny z SysML v2 zgodnie z zależnościami modelowania. Bazując na artefaktach kodu generowanych przez zadania nadrzędne, agent wykonuje odpowiadające operacje generowania kodu na podstawie wymagań określonych w każdej karcie zadania, umożliwiając tym samym stopniowy proces konstrukcyjny — od lokalnych komponentów do całego modelu.

Agent naprawy kodu koryguje błędy w wygenerowanym kodzie na podstawie wyników modułu walidacji składni (patrz moduł walidacji składni) oraz wyników walidacji semantycznej. Do naprawy składni wykorzystuje typ błędu, pozycję oraz informacje kontekstowe zwracane przez walidator składni do syntezy celowych strategii naprawczych i generowania poprawionego kodu. Dla naprawy semantycznej dostosowuje relacje strukturalne i logiczne zgodnie z wynikami walidacji semantycznej, zapewniając spójność semantyczną i kompletność strukturalną w modelu końcowym.

Agent walidacji semantycznej ocenia spójność semantyczną między w pełni wygenerowanym kodem a kartami zadań, korzystając z dedykowanego mechanizmu walidacji semantycznej (patrz mechanizm walidacji semantycznej). Dzięki ocenie ilościowej zapewnia, że wygenerowany kod wiernie odzwierciedla pierwotne zamierzenie modelowania, osiągając tym samym precyzyjne dopasowanie między kodem modelu a określonymi wymaganiami modelowania.

Mechanizm hierarchicznej dekompozycji zadań
Jako formalny język modelowania dla złożonych systemów, SysML v2 cechuje się ściśle powiązaną składnią, głęboko zagnieżdżonymi strukturami hierarchicznymi oraz ograniczeniami semantycznymi na poziomie międzypoziomowym. Na przykład blok struktury systemu może zawierać wiele podczęści, atrybutów i portów, jednocześnie wyrażając wymagania dotyczące wydajności lub zachowania poprzez ograniczenia między warstwami. Te struktury i ograniczenia tworzą odgórne zależności strukturalne oraz relacje semantyczne sprzężenia zwrotnego oddolnego do góry. W przypadku płaskiego, jednorazowego generowania, dokładne mapowanie takich hierarchicznych zależności staje się wyzwaniem, często prowadząc do brakujących relacji, niespójności semantycznych lub utraty informacji o ograniczeniach.

Aby sprostać temu wyzwaniu, opracowujemy metodę parsowania intencji modelowania opartą na drzewie zadań, która hierarchicznie rozkłada wymagania modelowania w języku naturalnym. Jak pokazano na Rysunku 3, złożone cele modelowania są rozkładane na ustrukturyzowane i śledzalne węzły zadań, co pozwala systemowi interpretować semantykę modelowania w sposób odgórny i identyfikować zależności zależności. Konkretnie, gdy agent generujący strukturę zadania otrzymuje dane wejściowe od użytkownika, najpierw wykorzystuje możliwości semantycznego parsowania LLM, aby zidentyfikować kluczowe cele modelowania, kluczowe jednostki i ich zależności. Następnie rekurencyjnie rozkłada cel najwyższego poziomu na semantycznie niezależne podzadania i dalej je doprecyzuje do zadań atomowych, które można bezpośrednio odwzorować na operacje modelowania SysML v2, ostatecznie tworząc kompletne drzewo struktury zadań. Po skonstruowaniu drzewa zadań agent generuje ustrukturyzowaną kartę zadań dla każdego węzła zadania na podstawie zdefiniowanego szablonu. Format karty zadania jest zdefiniowany następująco:

TC = {id,O,N,K,P,V,C,D} (1)

Gdzie id to unikalny identyfikator węzła zadania, O jako cel zadania, N jako opis zadania w języku naturalnym, K oznacza podstawowe elementy semantyczne SysML v2, które mogą być zaangażowane w zadanie, głównie w tym wymagania def/requirement, część def/part, port def/port, item def, attribute def/attribute oraz stan/transition. Relacje między tymi elementami wyrażane są głównie poprzez połączenia (połączenia strukturalne), elementy wejścia/wyjścia na portach (przepływy informacji/materiałów) oraz warunki wyzwalające/strażnicze przejść między automatami stanów (np. polecenia, stan zdrowia i ograniczenia progowe), C jako reguły semantyczne lub warunki brzegowe, P jako parametryzowalne sloty w zadaniu, takie jak nazwy atrybutów, typy danych czy typy złożone, V jako wartości instancjonowane dla każdego slotu oraz D jako zależności modelowania między zadaniami, gdzie depend_on określa wymagane wyjścia z innych zadań przed wygenerowaniem aktualnego kodu zadania, dostarcza oznacza wyjścia generowane po zakończeniu zadania, a konsumuje zewnętrzne wejścia wymagane przez zadanie.

Moduł walidacji składni
Moduł walidacji składni jest budowany na podstawie pilotażowej implementacji SysML v2. Wywołując interfejsy parsera i walidatora, moduł analizuje i weryfikuje poprawność składniową wygenerowanego kodu modelu SysML v2. Kryteria walidacji modułu pochodzą głównie ze specyfikacji języka SysML v2, a także z reguł gramatycznych, reguł zakresu i rozwiązywania oraz powiązanych mechanizmów kontroli ograniczeń zaimplementowanych w narzędziu pilotażowym. W szczególności walidacja sprawdza, czy deklaracje elementów są dobrze sformułowane, czy struktury bloków są kompletne, czy adnotacje typów są poprawne, czy nazwy i odwołania można skutecznie rozwiązywać oraz czy konstrukty modelowania, takie jak porty, połączenia, stany i przejścia, spełniają wymagania języka.

Po wygenerowaniu fragmentu kodu dla bieżącego zadania, wynik jest przekazywany do modułu walidacji składni, gdzie skrypt walidacyjny analizuje kod i zwraca wyniki w formie ustrukturyzowanych informacji diagnostycznych. Wyniki walidacji przedstawiamy następująco:

E₁ = (Typ_I, Pos_I, MSG_I) (2)

Gdzie e_i oznacza listę wykrytych problemów dla bieżącego zadania modelowania, każdy wpis zawiera typ błędu typ_i, lokalizację błędu pos_i oraz komunikat diagnostyczny w wiadomości_i .

Na przykład, jeśli wygenerowany kod zawiera błąd składniowy, taki jak "atrybut nie jest typowany przez definicję atrybutu", moduł walidacyjny zwraca następujący komunikat diagnostyczny:

'type' : 'error'
'message' : 'BŁĄD: Atrybut musi być wpisany według definicji atrybutu.' (3)
'pozycja' : 'linia 7 kolumna: 3'

Gdy wynik walidacji e_i ≠ 0, zebrane informacje o błędzie e_i są przekazywane agentowi naprawiającemu kod w celu dalszej korekty. Dlatego proces naprawy kodu nie jest procedurą niekontrolowanej modyfikacji, lecz ukierunkowaną rewizją kierowaną na podstawie jawnych informacji diagnostycznych zwracanych przez parser i walidator.

Mechanizm walidacji semantycznej
Mechanizm walidacji semantycznej wykorzystuje pola karty zadania klucza, które mają wyraźne i możliwe do śledzenia powiązania z kodem modelu jako kotwicy semantyczne. Ocenia spójność semantyczną na poziomie modelu, dostarczając tym samym wyraźnych, praktycznych kryteriów dla późniejszej naprawy modelu. Konkretnie, dla każdej karty zadania TC_i jako kluczowe odniesienia semantyczne używane są następujące pola: (i) cel modelowania O_i, (ii) ograniczenia semantyczne i warunki brzegowe C_i, (iii) instancjonowane wartości slotów parametrów V_i oraz (iv) oczekiwane wyjścia po zakończeniu zadania D_i['zapewnić']. Te dziedziny nakładają komplementarne ograniczenia semantyczne na generowany model z wielu perspektyw: realizacja intencji modelowania, spełnienie ograniczeń, spójność instancji parametrów oraz kompletność wyników modelu—umożliwiając zasadniczą decyzję, czy kod modelu spełnia wymagania modelowania bez konieczności stosowania dodatkowych założeń.

Na podstawie tych kluczowych pól definiujemy wielopolową funkcję decyzyjną o spójności semantycznej:

(4)

gdzie I(·) oznacza funkcję wskaźnikową równą 1, jeśli wszystkie poddecyzje w nawiasach są obowiązujące, a 0 w przeciwnym razie. Ta decyzja binarna wyraźnie rozróżnia stany spełniające wymagania modelowania od wymagających dalszej naprawy, zapewniając deterministyczny warunek wyzwalający dla kolejnego procesu naprawy semantycznej. Ogólna decyzja jest wspólnie ustalana przez następujące cztery funkcje poddecyzji:

(1) Modelowanie spójności celowej:

Φ₀ (TC_{i,c f}) = I(skład (c_{f,0 i})) (5)

gdzie Consist(c_{f,0 i}) wskazuje, czy kod modelu c_f jest semantycznie zgodny z celem modelowania 0_i określonym na karcie zadania.

(2) Spełnianie ograniczeń semantycznych:

Φ_c (TC_{i,c f}) = I(Spełniając(c_{f,C i})) (6)

gdzie Spełnia(c_{f,C i}) wskazuje, czy kod modelu c_f spełnia ograniczenia semantyczne i warunki brzegowe C_i określone w karcie zadania.

(3) Spójność parametrów:

Φ_c (TC_{i,c f}) = I(Instant(c_{f,V i})) (7)

gdzie Instant(c_{f,V i}) wskazuje, czy wartości parametrów V_i na karcie zadania są konsekwentnie odzwierciedlone w kodzie modelu.

(4) Spójność wyników:

 (8)

gdzie Artifacts(c_j) wskazuje, czy wyniki oczekiwane przez kartę zadania są obecne w końcowym kodzie modelu, służąc jako miara kompletności wygenerowanego wyniku.

Te oceny spójności są realizowane przez Agenta Walidacji Semantycznej, wykorzystując możliwości zrozumienia semantycznego LLM; Wewnętrzny proces rozumowania agenta nie zmienia formalnej definicji ani zastosowania funkcji spójności.

Dzięki temu wielopolowemu sprawdzaniu spójności semantycznej wygenerowany model może być weryfikowany pole po polu, aby zapewnić, że każdy cel modelowania, warunek ograniczenia, konfiguracja parametrów i oczekiwany wynik są odpowiednio spełnione. Proces ten nie tylko stanowi wyraźny impuls do późniejszej naprawy semantycznej, ale także dostarcza śledzicielnych dowodów semantycznych w całym procesie generowania, poprawiając tym samym niezawodność i spójność generowanego modelu.

Dane eksperymentalne i ocena
Dane eksperymentalne
Kod modelu SysML v2 nie jest zwykłym kodem programowym; Generowane przez niego artefakty wykazują charakterystyczne cechy modelowania formalnego. Różne poglądy zazwyczaj obejmują odrębne kategorie podstawowych elementów modelowania, takie jak wymagania, części, porty, atrybuty, stany i przejścia, które znacznie różnią się stylem deklaracji, formami organizacyjnymi i strukturami kompozycyjnymi. Ponadto kod modelu musi spełniać wiele ograniczeń, w tym odwoływanie się do typów, hierarchiczne zagnieżdżanie, ograniczenia połączeń oraz ponowne użycie semantyczne między elementami.

Aby kompleksowo ocenić wydajność proponowanej metody przy różnych złożonościach modelowania, konstruuje się zbiór kodu obejmujący pięć reprezentatywnych typów widoków modelu—wymagania, przypadki użycia, strukturę, parametrykę i automaty stanów. Te widoki modeli odpowiadają odpowiednio specyfikacji wymagań, interakcji funkcjonalnej, składu strukturalnego, parametrycznej reprezentacji ograniczeń oraz opisu logiki behawioralnej w modelowaniu systemów. Oddzielna ocena frameworka dla różnych typów widoków modelu umożliwia bardziej szczegółową analizę jego zastosowania w różnych cechach struktury kodu oraz warunkach ograniczeń modelowania.

Każdy typ widoku modelu zawiera 15 ręcznie tworzonych instancji modeli, co daje zbiór danych N = 75 modeli SysML v2. Zbiór danych obejmuje wiele dziedzin inżynieryjnych, w tym lotnicze, motoryzacyjne, medyczne oraz systemy inteligentnego domu, a wszystkie modele pomyślnie przeszły oficjalne środowisko walidacyjne SysML v2, zapewniając ścisłą zgodność składniową.

Następnie wygenerowaliśmy odpowiadający opisowi intencji modelowania w języku naturalnym dla każdego modelu. Aby zwiększyć efektywność budowy, użyliśmy szablonu promptu pokazanego w Pliku Uzupełniającym 2 oraz zastosowaliśmy GPT-4o do przygotowania początkowych opisów. GPT-4o został wybrany ze względu na silne zrozumienie semantyczne i zdolności ekstrakcji informacji, umożliwiające precyzyjne uchwycenie kluczowych elementów modelu bez halucynacji oraz generowanie opisów intencji modelowania przypominającego człowieka⁹. Aby zapewnić dokładność i wyeliminować niejednoznaczności, wszystkie generowane opisy były ręcznie przeglądane i dopracowywane przez badaczy z doświadczeniem inżynierii systemów. Reprezentatywne przykłady dla różnych typów modeli przedstawiono w Tabeli 1.

Metryki oceny
Stosujemy następujące trzy kluczowe metryki do oceny jakości wygenerowanego kodu modelu SysML v2:

Średni wskaźnik błędów składniowych (SER)
Ta metryka określa proporcję błędów składniowych wykrytych podczas weryfikacji generowanego modelu według oficjalnych reguł składni SysML v2. Oblicza się ją jako:

   (9)

gdzie E_i oznacza liczbę błędów składniowych zidentyfikowanych w i-tym generowanym modelu. Ta metryka odzwierciedla, w jakim stopniu wygenerowany kod modelu jest zgodny z formalną specyfikacją składni SysML v2.

Wynik spójności semantycznej (SCS)
Ta metryka ocenia, jak dokładnie i kompleksowo wygenerowany kod modelu oddaje intencję semantyczną wyrażoną w specyfikacjach modelowania w języku naturalnym. Konkretnie wyodrębniamy jednostki semantyczne z intencji modelowania — takie jak entity systemowe, uczestniczące komponenty, funkcje podstawowe lub scenariusze behawioralne oraz kluczowe warunki lub ograniczenia — i porównujemy je z jednostkami semantycznymi obecnymi w generowanym kodzie modelu. Spójność semantyczna oblicza się jako:

    (10)

gdzie U oznacza zbiór jednostek semantycznych wyodrębnionych z zamiaru modelowania, a zbiór jednostek semantycznych zidentyfikowanych w wygenerowanym kodzie. wskazuje liczbę jednostek poprawnie zarejestrowanych przez generowany kod modelu. Wyższa wartość SCS oznacza silniejsze pokrycie semantyczne i dopasowanie.

Ocena jakości człowieka
Tradycyjne zautomatyzowane metryki, takie jak BLEU i CodeBLEU, głównie oceniają podobieństwo powierzchowne lub wykonalność kodu, ale nie rejestrują, czy model rzeczywiście rozumie lub poprawnie wyraża zamierzoną semantykę modelowania. Te metryki ograniczają się do oceny spójności semantycznej, kompletności kluczowych elementów oraz zgodności z zamysłem modelowania¹⁰. Natomiast ocena ludzka może dokładniej zidentyfikować problemy takie jak brakujące elementy semantyczne, niespójności logiczne, redundancja strukturalna czy niepoparte halucynacje, zapewniając tym samym bardziej wiarygodną ocenę¹¹. Motywowani tymi ograniczeniami projektujemy ramy oceny ludzkiej dla wygenerowanych modeli SysML v2, składające się z trzech kryteriów: (1) Poprawność: wygenerowany model musi dokładnie odzwierciedlać intencję modelowania, utrzymywać strukturalną i logiczną spójność z celami zadania oraz nie zawierać niejednoznaczności semantycznej, brakujących elementów ani błędnych rozszerzeni. (2) Czytelność: kod modelu powinien być jasny i łatwy do zrozumienia, z spójnym nazewnictwem, spójną strukturą oraz dobrze zorganizowaną hierarchią wspierającą inspekcję i późniejszą konserwację. (3) Integralność: model powinien wykazywać pełną logikę strukturalną, spójne odniesienia między elementami oraz brak nieokreślonych typów lub zerwanych łańcuchów zależności, co zapewnia jego użyteczność do dalszej analizy i integracji. Zaprosiliśmy badaczy z doświadczeniem w modelowaniu SysML do oceny każdego wygenerowanego modelu w trzypunktowej skali, gdzie 1 oznacza najniższą jakość, a 3 najwyższą. Podczas oceny oceniający mogli porównać wygenerowany kod modelu z modelem opartym na rzeczywistości, aby zapewnić dokładniejszą i kompleksową ocenę.

Linia bazowa
Wybraliśmy kilka punktów odniesienia do porównania z proponowaną metodą, w tym:
CodeCoT¹²: Łączy rozumowanie łańcucha myśli z mechanizmem samokontroli, umożliwiając modelu jawne rozumowanie podczas generowania i samokorektę błędów składniowych, poprawiając tym samym jakość kodu i spójność semantyczną.

Samoplanowanie¹³: Wprowadza dwuetapowy proces generowania kodu, w którym model najpierw planuje kroki rozwiązania, a następnie generuje kod zgodnie z planem, skutecznie zwiększając spójność logiczną i interpretowalność dla złożonych zadań.

Samodzielna edycja¹⁴: Przyjmuje iteracyjny paradygmat generowania i edycji, który wykonuje wygenerowany kod i automatycznie koryguje błędy na podstawie informacji zwrotnej w czasie działania, stale dopracowując wyniki.
CodeChain¹⁵: Wykorzystuje generowanie modułowe i iteracyjne rewizje, rozkładając złożone zadania na niezależne moduły funkcjonalne oraz poprawiając wytrzymałość i ogólną jakość konstrukcji poprzez wielokrotne rundy optymalizacji.

Samodebugowanie¹⁶: Nadaje modelowi autonomiczne możliwości debugowania i wyjaśniania. Dzięki zamkniętemu procesowi generowania, wykonania i debugowania znacznie poprawia poprawność złożonych zadań programistycznych bez udziału człowieka.

MapCoder¹⁷: Tworzy wieloetapowy framework współpracy składający się z czterech agentów — wyszukiwania, planowania, kodowania i debugowania — ściśle symulujących ludzki proces programowania i umożliwiających generowanie zamkniętej pętli od zrozumienia zadań do weryfikacji wyników.

Samodzielna współpraca¹⁸: Organizuje system jako wirtualny zespół programistyczny z rolami takimi jak analityk, programista i tester, poprawiając ogólną wydajność przy tworzeniu złożonego kodu poprzez współpracę opartą na rolach i iteracyjne informacje zwrotne.

Układ eksperymentalny
Aby zapewnić sprawiedliwość i porównywalność między eksperymentami, najpierw oceniliśmy kilka popularnych LLM, stosując bezpośrednie generowanie kodu, aby ustalić wyniki wyjściowe. Na podstawie tych początkowych wyników wybrano najlepiej działający LLM jako model zunifikowany szkieletowy dla wszystkich kolejnych eksperymentów. Następnie porównaliśmy proponowany framework MAS4SysML z wieloma reprezentatywnymi metodami generowania kodu. Wszystkie interakcje LLM były przeprowadzane przy użyciu stałego ustawienia temperatury (T = 0,2), aby zminimalizować losowość podczas generowania. Dla każdego zadania modelowania maksymalna liczba iteracji naprawczych w MAS4SysML była ustalana na K_max = 3. Wszystkie metody bazowe były wykonywane w tej samej konfiguracji eksperymentalnej co MAS4SysML, aby zapewnić spójność wyników i sprawiedliwość eksperymentalną. Skrypt Python metody MAS4SysML jest udostępniony jako Plik Uzupełniający 3.

Results

Ocena modelu bazowego
Najpierw wybraliśmy kilka popularnych LLM i przeprowadziliśmy wstępne testy wydajności z wykorzystaniem bezpośredniego generowania model-to-code, w tym CodeX(175B)¹⁹, CodeGen-Mono(16.1B)²⁰, PaLM Coder(62B)²¹, Alphacode(1.1B)²², Incoder(6.7B)²³ oraz code-davinci-002(175B)²⁴. Jak pokazano w Tabeli 2, code-davinci-002(175B...

Discussion

Proponujemy MAS4SysML, wieloagentowy framework współpracy do półautomatycznego generowania kodu modelu SysML v2. Ramy składają się z czterech funkcjonalnie komplementarnych agentów. Podczas generowania (i) hierarchicznie rozkłada wymagania modelowania w języku naturalnym, korzystając ze struktury opartej na drzewie zadań, i formalizuje je na strukturalne karty zadań, a (ii) generuje kod modelu SysML v2 oddolnie, kierując się ograniczeniami i relacjami zależnościami określonymi w tych kartach. Przez całą generację moduł w...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain (projekt open-source)	v1.0.8; https://github.com/langchain-ai/langchain	Ramy interakcji LLM i orkiestracji agentów
LangGraph	LangChain (projekt open-source)	v1.0.3; https://github.com/langchain-ai/langgraph	Framework wykonawczy wieloagentowego przepływu pracy
Python	Python Software Foundation	3.10.x; https://www.python.org/downloads/release/python-3100/	Główny język programowania implementacji MAS4SysML
Pilotażowa implementacja SysML v2	Grupa Zarządzania Obiektami (OMG)	(podaj wersję wydania/tagu); https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	Wykorzystywane do walidacji składni i parsowania modeli