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?

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.

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.

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.

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ą.

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.

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.

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.

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.

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.

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.

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!