Czy kod jest często generowany z UML? [Zamknięte]

39

Kiedy byłem na uniwersytecie, dowiedziałem się o zaletach UML i jego przyszłości w rozwoju kodu.

Jednak z mojego doświadczenia w branży odkryłem, że chociaż używamy diagramów - od diagramów ER, diagramów klas, diagramów stanów, do diagramów przepływu pracy - wszystko to jest do celów komunikacyjnych.

Oznacza to, że nigdy nie generowałem kodu automatycznie na podstawie diagramów iz punktu widzenia komunikacji staram się, aby moje diagramy były tak proste i łatwe do zrozumienia, jak to możliwe.

Ale kiedy patrzę na Visio i Enterprise Architect, wydaje się, że mają wiele różnych typów wykresów, kształtów, właściwości obiektów, z których większość nie używam.

Czy ludzie używają UML do bardziej skomplikowanych czynności, takich jak generowanie kodu lub bazy danych?

RoboShop
źródło
6
@SK - Wszyscy wiemy, że TWÓJ kod jest wspaniały i napisany w tak krystalicznie czysty sposób, że nawet 5-latek może zrozumieć cały projekt, czytając tylko kilka z twoich metod. Jednak dla reszty z nas, którzy nie mają nadprzyrodzonej zdolności do pisania krystalicznie czystego kodu, diagramy mają ogromną zaletę w opisywaniu zwięzłego działania systemu, a diagramy UML są standardowym sposobem rysowania tych diagramów. Nie twierdzę, że to najlepszy sposób, tylko standardowy sposób, który działa w większości.
Dunk
2
@Dunk, prawdopodobnie przegapiłeś ten moment, kiedy reszta z nas wymyśliła mowę zamiast malowania jaskiniowego. Diagramy są prawie zawsze niczym innym, jak sposobem na ukrycie tego, co mają reprezentować. Zwykły tekst jest zawsze lepszy. Im większy system, tym bardziej złożone jest jego zachowanie, tym większa jest luka między stylem komunikacji z epoki jaskiniowców a nowoczesnym angielskim. Nigdy nie widziałem diagramu, który mógłbym zrozumieć bez ręcznego przetłumaczenia go na tekst.
SK-logic,
9
@ SK-logic - Myślałem, że obraz namalował tysiąc słów?
Michael Arnell,
5
@ SK-logic: A więc niektóre rzeczy lepiej komunikować się za pomocą tekstu. I wierzcie lub nie, inni są lepiej komunikowani za pomocą diagramów, a to obejmuje projektowanie systemu, a nie tylko projektowanie OO. I może być nawet różny dla różnych ludzi i nie, twoja preferencja dla informacji tekstowych nie jest boskim znakiem wyższości.
Michael Borgwardt
3
@ Sk - choć twoja opinia ma pewne ważne punkty, sam schemat prawie nigdy nie wystarcza i trzeba dodać trochę tekstu. Będę nadal korzystać z tego, co według ciebie są bezużyteczne, podczas gdy z powodzeniem buduję dość duże systemy z prawie niemożliwymi terminami w dużych zespołach, ponieważ nie widziałem jeszcze lepszego sposobu komunikowania się z innymi programistami. Wiem, że masz dużo czasu, aby usiąść i indywidualnie poprowadzić każdego programistę, ale jestem zbyt zajęty pracą.
Dunk

Odpowiedzi:

64

Tak, narzędzia UML CASE były jednym z najgorętszych elementów lat 90., a potem nie zostały dostarczone.

Podstawowym tego powodem jest to, że diagramy UML (lub większość innych rodzajów) pomagają zrozumieć problem i / lub program go rozwiązujący tylko w zakresie, w jakim schemat wyodrębnia szczegóły implementacji rzeczywistego kodu. Tak więc (dla każdego nietrywialnego fragmentu kodu), łatwy do zrozumienia schemat jest z natury bezużyteczny do generowania kodu , ponieważ brakuje mu niezbędnych szczegółów. I odwrotnie, diagram, który można bezpośrednio wykorzystać do generowania kodu, nie pomaga lepiej zrozumieć programu niż sam kod. Jeśli kiedykolwiek widziałeś schemat klasy UML poddany inżynierii wstecznej z kodu produkcyjnego, prawdopodobnie wiesz, co mam na myśli.

Jedynym potencjalnym wyjątkiem od tego, o czym wiem, są diagramy relacji encja, które same w sobie nie obejmują kodu, a jedynie (jak sama nazwa wskazuje) fragmenty danych i ich relacje. Ale nigdy nie słyszałem o udanej próbie użycia dowolnego rodzaju diagramów UML do generowania prawdziwego kodu [Aktualizacja] - tj. Więcej niż szkielety klas i trywialny kod, taki jak getters / setters -, z wyjątkiem narzędzi / obszarów specjalnego przeznaczenia, takich jak ORM, zgodnie ze świadectwem autorstwa Doktora Browna poniżej [/ Update] i myślę, że to nie przypadek.

Ja osobiście nie nienawidzę UML - myślę, że diagramy UML mogą być świetnym narzędziem komunikacji - aby pokazać swoje intencje i pomysły podczas dyskusji projektowych lub wizualizować architekturę Twojej aplikacji. Ale najlepiej trzymać ich przy tym i nie próbować używać ich do rzeczy, w których nie są dobrzy.

Péter Török
źródło
5
Dokładnie. Ale wtedy pojawia się pytanie, dlaczego UML ze wszystkimi swoimi bezcelowymi ścisłymi regułami, a tym samym rozdętymi narzędziami do tworzenia UML, w pierwszej kolejności? Proste wielokąty i elipsy, połączone liniami i strzałkami, wykonują równie dobrą robotę, jeśli nie lepszą, w przekazywaniu intencji, jak UML.
Dexter,
1
+1 dla szumu lat 90. Projekt sprzętu poruszał się w tym samym czasie w przeciwnym kierunku, z dala od schematycznego przechwytywania i w kierunku HDL.
jk.
2
Od 1996 do 2002 roku pracowałem dla firmy, w której z powodzeniem stosowaliśmy diagramy UML jako „lepsze” modele ER. Mieliśmy własne generatory kodu do generowania kodu C ++ dla naszej struktury ORM, SQL / DDL i dokumentacji z jednego modelu.
Doc Brown
2
Świetnym zastosowaniem diagramu UML jest również rusztowanie. Generuj klasy, używając getters / setters, może twojego drzewa katalogów itp.
Clement Herreman
5
@Dexter: chodzi o to, że „Proste wielokąty i elipsy połączone liniami i strzałkami” pozostawiają wiele do interpretacji. Możliwe, że UML zbyt mocno stara się mieć specjalny symbol dla wszystkiego, ale z pewnością znormalizowana notacja ma wartość, która pozwala wizualnie rozróżniać klasy i systemy sprzętowe oraz relację dziedziczenia i kanał komunikacji.
Michael Borgwardt
36

Więc kiedy byłem na uni (jakiś czas temu), powiedziano mi, że UML jest przyszłością, UML zastąpi programowanie i po prostu wygenerujemy kod z diagramów itp.

Mylili się. Stanie się tak w momencie, gdy ludzie porzucą mowę i wrócą do malowania jaskiń.

Rzeczywiste problemy i programy, które je rozwiązują, mają zasadniczą złożoność, której nie można zmniejszyć. Aby stworzyć działający program, tę złożoność należy uchwycić i wyrazić w języku wykonywalnym. Pytanie brzmi, czy jakiś schematyczny język programowania może być bardziej skuteczny niż tekstowy język programowania. Eksperymentujemy z programowaniem schematycznym od około trzydziestu lat, a jak dotąd dowody przemawiają za programowaniem tekstowym. Nie znam żadnej ważnej aplikacji, która została wygenerowana przez generowanie kodu z diagramów.

Kevin Cline
źródło
2
+1, dziękuję za poruszenie problemu złożoności prawdziwych problemów słownych. Świetny punkt
NoChance,
co z G, graficznym językiem programowania używanym w LabVIEW?
Angelo.Hannes
1
@ Angelo.Hannes: Rozwiązywanie rzeczywistych problemów w niezmiennych podejściach laboratoryjnych
whatsisname
@whatsisname ten diagram jest bardzo zagracony. Ale widziałem bardzo dobrze ustrukturyzowane i bardzo „czytelne” diagramy w LabVIEW rozwiązujące rzeczywiste problemy.
Angelo.Hannes
@ Angelo.Hannes: Użyłem systemów podobnych do LabVIEW. Doskonale nadają się do budowania małych aplikacji w ograniczonej domenie.
kevin cline
9

NIE

Legenda została oparta na nieudanym założeniu, że pisanie:

class ClassName extends SomeThing
{

}

... jest trudny i wymaga automatyzacji .

Nadal możesz znaleźć okazjonalnego wierzącego lub tłumy wierzących.
Ale tak właśnie jest z religiami i kultami.

ZJR
źródło
4
Naprawdę czułem potrzebę odpowiedzi z dużym NIE gdzieś.
ZJR,
6

Byłem tam, nie uważam tego za zbyt przydatne.

Zasadniczo diagramy na tyle specyficzne, aby wygenerować z nich jakiś kod, głównie diagram klas, nie dodają zbyt wiele do zrozumienia programu i nie można wygenerować kodu z diagramów przeglądowych, takich jak przypadek użycia lub aktywność na poziomie przeglądu, które są kluczowe dla dokumentacji. Jednym z diagramów, który jest przydatny do zrozumienia i może generować kod, jest wykres stanu, który jest przydatny, gdy naprawdę potrzebujesz maszyny stanu. Ale ogólnie powinieneś starać się ich unikać, ponieważ są one z natury podatne na błędy.

W jednym projekcie byliśmy zobowiązani do zaprojektowania kodu w modelu UML (Rhapsody) i wygenerowania go stamtąd. To działało i prawdopodobnie było nieco nieco łatwiejsze niż pisanie nagłówków (było to C ++) i prototypów ręcznie. Zdolność do utrzymania tych dwóch spójnych automatycznie była nieco przydatna.

Ciała metody nadal musiały być wypełniane ręcznie, ponieważ diagramy tak naprawdę nie mogą tego reprezentować, z wyjątkiem szkieletów maszyn stanowych.

Z drugiej strony jest to dość skomplikowane, więc musisz nauczyć się wielu dodatkowych rzeczy, a co ważniejsze, połączenie było trudne. Scalanie jest dobrze zbadane dla plików tekstowych i działa z nimi, ale nikt nie wymyślił jeszcze łatwego sposobu scalania zmian w diagramach. Rhapsody faktycznie zachowuje część informacji w wygenerowanym kodzie i analizuje ją z powrotem, więc nie była całkowicie bezużyteczna, ale nadal była poważną komplikacją.

Jan Hudec
źródło
@mouviciel: Nie sądzę, aby istniało narzędzie, które nie miałoby takich problemów. Rhapsody faktycznie próbuje złagodzić najgorsze problemy, wykorzystując wygenerowany kod, którym jest tekst, jako autorytatywny dla członków.
Jan Hudec
3

Chociaż z pewnością możliwe jest generowanie kodu (a nawet całych systemów) bezpośrednio z modeli UML, nigdy nie spotkałem się z tym, że jest on używany w ten sposób.

Z mojego doświadczenia wynika, że ​​większość firm wydaje się używać go jako narzędzia komunikacyjnego do wymagań lub „MS Paint do rysowania diagramów”.

Jednym ważnym rozróżnieniem, które chciałbym wprowadzić, jest to, że większość narzędzi do modelowania UML pozwala zbudować jeden model systemu. Na przykład Visio dość dobrze rozumie, jak działa UML, i można dodać wiele rzeczy, które nie są bezpośrednio związane z diagramem. Rzeczywiste diagramy to po prostu różne perspektywy części modelu, co pozwala wyróżnić różne aspekty systemu.

Daniel B.
źródło
1

wszystko to (schematy modelowania) służy celom komunikacyjnym

Modelowanie ma 4 ważne zastosowania w procesie tworzenia oprogramowania:

  1. Zintegrowane narzędzie do projektowania

  2. Narzędzie komunikacji

  3. Pomoc w generowaniu oprogramowania

  4. Sposób na zmniejszenie złożoności problemu rzeczywistych słów (dowiedziałem się tego z powyższej odpowiedzi @kevin cline)

  5. Proces modelowania zmusza niektórych projektantów do myślenia o szczegółach nieuwzględnionych podczas kodowania (i vice versa). Modelowanie w czasie projektowania pozwala rozważyć większy obraz niż kodowanie metody lub klasy w języku.

Moim zdaniem modelowanie jest niezbędne do budowania baz danych (diagramy ER), zrozumienia przepływów procesów (diagramy aktywności) i zrozumienia interakcji użytkownik-system (diagramy przypadków użycia).

Czy ludzie używają UML do bardziej skomplikowanych czynności, takich jak generowanie kodu lub bazy danych?

W rzeczy samej. ERD (nie diagram UML) i diagramy klas mogą być używane (w zależności od możliwości twojego narzędzia) do generowania:

1 - Język definicji danych (DDL)

2 - Procedury przechowywane dla CRUD i diagramów klas w preferowanym języku (mniej przydatne, ponieważ narzędzia ORM robią więcej na ten temat)

Do najcenniejszych funkcji narzędzi do modelowania należą:

1 - Zdolność do zachowania integralności modelu. Jeśli dokonasz zmiany, propaguje się ona w modelu

2 - Zdolność do odpowiedzi na pytania, w których przypadkach używane (gdzie „konto” jest używane w moim modelu?)

3 - Możliwość umożliwienia jednoczesnym użytkownikom pracy nad modelem

4 - Szukaj w reprezentacjach graficznych

5 - Kontrola drukowania

6 - Nakładanie warstw (organizuj elementy diagramu w warstwy), abyś mógł skupić się na warstwie na raz

7 - Generowanie kodu bazy danych dla kilku systemów baz danych

8 - Walidacja modelu (sprawdza spójność, brakujące klucze, cykle itp.)

Narzędzia do modelowania, zwłaszcza te dobre, robią znacznie więcej niż Paint.

Bez szans
źródło
3
Chcę wskazać 2 rzeczy: 1. Lubisz uporządkowane listy.
talnicolas,
@talnicolas, masz rację! Robię :)
NoChance,
0

Używamy Software Architect do tworzenia projektów na wysokim poziomie i dokumentowania niektórych bardziej tajemnych interakcji komponentów w naszych materiałach. Czasami generujemy szkielet aplikacji na podstawie diagramów, ale gdy to zrobimy, zachowujemy oba oddzielnie, nie próbujemy przekształcać kodu z powrotem w diagram po jego zakończeniu. Kiedyś korzystałem z narzędzia o nazwie Rational XDE, które działało całkiem dobrze w przypadku małych programów, ale gubiło się, gdy zacząłeś dodawać programy obsługi zdarzeń Swing lub próbowałeś pracować z Struts.

Myślę, że dużą część powodu, dla którego ludzie nie piszą w UML, jest to, że potrzeba dużo więcej pracy, aby całkowicie określić wszystko w UML, a następnie wygenerować kod z diagramu. Wiem, że US DoD współpracuje z OMG w celu opracowania niektórych narzędzi, które będą generować „sprawdzony” kod z diagramów, które zostały zweryfikowane poprawnie, ale mam wrażenie, że skończysz o rząd wielkości więcej metadanych niż rzeczywisty kod. Co jest prawdopodobnie dobre (w końcu to dokumentacja), ale generowanie metadanych nie jest szybsze niż pisanie kodu, więc spędzasz proporcjonalnie więcej czasu.

TMN
źródło
0

Sam UML jest systemem notacji, dlatego jest przyczyną komunikacji i dokumentacji. Generowanie kodu na podstawie modelu UML jest rzadkością, ale tak, robią to ludzie. Użytkownicy Rhapsody robią to częściej niż Rose. Trudność polega na zsynchronizowaniu modelu i kodu, w przypadku większości prawdziwych projektów koszt jest po prostu zbyt wysoki.

pinxue
źródło
-1

W moim najnowszym projekcie korzystam z UML-Lab (https://www.uml-lab.com). To miłe narzędzie, które pozwala również na inżynierię wsteczną. Narzędzie generuje kod Java, a nawet adnotacje JPA, które są dość dokładne.

Wyzwaniem jest praca w zespole. Model jest statyczny i znajduje się w jednym zasobie, co utrudnia synchronizację z wieloma zmianami programistów. Dostępna jest wersja próbna dostępna przez 1 miesiąc, co jest dobrym czasem na zapoznanie się i porównanie z innymi, jeśli prowadzisz dochodzenie.

Po raz pierwszy widziałem produkt, który wykonuje modelowanie obiektów i modelowanie danych w jednym ujęciu, a także generowanie kodu.

W innych projektach zawsze widziałem przestarzałe modele, które są niedokładne lub zbyt szczegółowe.

W swoich poprzednich projektach czasami generowałem diagramy za pomocą inżynierii odwrotnej. Przez większość czasu odkryłem, że diagramy są zagracone i wolałem rysować je ręcznie, filtrując cały hałas.

koya
źródło
-4

Myślę, że możemy używać UML do generowania kodu. Nie logika biznesowa, ponieważ logika biznesowa nie jest standardem i różni się w zależności od aplikacji. Diagramy klas wraz ze schematami ER mogą być używane do generowania interfejsów, klas, encji hibernacyjnych, podstawowych metod dao itp. Inne kody wzorcowe, takie jak implementacja elewacji, konwertery typów danych (np. Encja do przesyłania obiektów) mogą być również generowane za pomocą digramów obiektów .

Ponadto, jak wspomniano w poprzednich komentarzach, przy użyciu modeli można wygenerować schemat bazy danych, skrypty DDL itp.

Za pomocą OAW i narzędzia do modelowania, takiego jak Enterprise Architect, możemy pisać silniejsze generatory kodu, które mogą nawet pomóc w generowaniu plików konfiguracyjnych, kodu fabrycznego przy użyciu stereotypów i oznaczonych wartości.

Siddhesh Patil
źródło
-5

Nadal nie rozumiem, dlaczego inteligencja biznesowa z narzędziami takimi jak Business Object jest w stanie analizować i wykorzystywać wszystkie informacje firmowe, podczas gdy na poziomie technologicznym nadal pracujemy tylko na poziomie kodu lub na poziomie abstrakcyjnym z UML !!

Problemem nie jest UML, ale transformacja modelu między UML i MOF oraz generowanie kodu z diagramu klas lub xmi przy użyciu szablonów. Mówi się, że UML daje abstrakcyjny obraz prawdziwego świata, dlatego widzisz tylko to, co jest naprawdę ważne. Powiedziawszy to, jak wygenerować dokładny kod, jeśli diagram UML jest tylko widokiem prawdziwego świata? Jest to niemożliwe i dlatego nie powiodło się tworzenie z wykorzystaniem modelu, które generowałoby kod z modelu.

Rozwiązaniem jest przekształcenie w celu zmapowania świata rzeczywistego, a zatem całego kodu projektu do jednego modelu UML. Mając jeden model i pełną logikę projektu, możesz za każdym razem generować widoki z modelu, a nie z kodu. Omondo ma odważną inicjatywę w technologii Java / Jee. Koncepcja polega na synchronizacji na żywo MOF i UML bezpośrednio z kodem i ORM. Diagram UML jest teraz tylko widokiem wysokiego poziomu modelu, który mapuje cały projekt. Możesz stworzyć setki widoków, dodać sto notatek itp ..., aby lepiej zrozumieć projekt. Kod zostanie wygenerowany tylko wtedy, gdy element zostanie zmieniony lub utworzony. Cudowna technologia, w której Java ID jest mapowany na identyfikator UML bez tradycyjnego mostu transformacji między MOF i UML.

Fantastyczne jest także to, że mogę modelować moją domenę na poziomie UML i otrzymywać adnotacje ORM bezpośrednio w kodzie, a zatem za pomocą Hibernacji mogę tworzyć, usuwać, tworzyć moją bazę danych, wdrażać itp. W ciągłej ciągłej integracji, w której UML jest częścią całej architektury, a nie samej architektury projektu.

Nigdy nie byłem rozczarowany UML jako przeglądarką wysokiego poziomu, jeśli synchronizacja na żywo z kodem była absolutnie zdewastowana przez tradycyjne używanie MDA z generowaniem kodu szablonów programistycznych. Generowanie kodu z modelu przypomina stronę HTML pochodzącą z dokumentu tekstowego. Jak to zmienić po wygenerowaniu? Aktualizacja jest po prostu niemożliwa i spędzasz więcej czasu na czyszczeniu kodu niż na pisaniu od zera!

UML_GURU
źródło
1
To nie jest odpowiedź, tylko narzekać. Zgadzam się trochę co do tego, dlaczego koderzy wciąż piszą każdy kod wiersza, podczas gdy ŁATWE jest tworzenie małych konstruktorów kodu metodą przeciągnij i upuść. Masz całkowitą rację, że Bussiness lepiej wdrożył technologię niż użytkownicy, którzy jej używają. Możesz utworzyć całą wstępnie skonfigurowaną maszynę za pomocą aplikacji w kilka sekund, ale nie możesz stworzyć oprogramowania za pomocą kilku (tysięcy) kliknięć lub naciśnięć klawiszy. Dodatkowy. Mam pewność, że Día i Pythonnect mogą wykonać dobrą robotę, wykonując kod bezpośrednio z twojego UML, ale jeszcze nie przetestowałem.
erm3nda