„UML jest najgorszą rzeczą, jaka kiedykolwiek przydarzyła się MDD”. Dlaczego?

17

William Cook w tweecie napisał:

UML to najgorsza rzecz, jaka kiedykolwiek przydarzyła się MDD. Na szczęście wiele osób zdaje sobie z tego sprawę…

Chciałbym poznać uzasadnienie tego twierdzenia (najwyraźniej nie odnoszę się do jego osobistej opinii).

Zauważyłem, że wiele osób tak bardzo nie lubi UML. Warto również wspomnieć, że jest on w środowisku akademickim, gdzie UML jest świętym graalem skutecznego projektowania i modelowania.

Florents Tselai
źródło
15
Powiedziałbym, że MDD jest najgorszą rzeczą, jaka kiedykolwiek przydarzyła się MDD.
Michael Borgwardt,

Odpowiedzi:

39

Jestem naukowcem, który opublikował oryginalny tweet. Tweety nie mają być artykułami naukowymi. Są to reklamy i myślę, że mogą być również kontrowersyjne. Oto moje kolejne tweety:

1) UML został stworzony do modelowania projektów OO. To wpływa na modelowanie kodu systemu, a nie na zachowanie systemu. UML jest na złym poziomie.

2) szalona jest idea, że ​​7 (lub 13) formatów diagramów w UML może obejmować wszystko. Co z graficznymi interfejsami użytkownika, szkieletami sieci, autoryzacją itp.?

3) UML poparł pomysł, że modele muszą być graficzne. Śmieszny! Modele tekstowe i graficzne są przydatne i często wymienne

4) UML jest jednocześnie zbyt duży i złożony, a jednocześnie bardzo ograniczony. Stereotyp i profile nie są skuteczne dla użytecznych rozszerzeń.

Zauważ, że niekoniecznie mówię, że UML jest zły. Mówię po prostu, że nie pomaga to celowi „rozwoju opartego na modelu”, co mnie interesuje. Nie rozumiem komentarza na temat „świętego Graala”.

William Cook
źródło
10
+1 za znalezienie i odpowiedź na pytanie na prog.SE dotyczące twojego własnego tweeta!
Warren P,
Dlatego rozwój oparty na Modelach zawsze wydawał mi się mieć model wizualny. A jeśli nie UML, to co? (uwaga: nigdy nie lubiłem MDD i nie znoszę UML. Ale jestem gotów dać szansę MDD-sans-UML. Co powinienem spróbować?
Warren P
1
@Warren P: czego nie lubisz w MDD i UML?
dan_l
1
Usunąłem swoją odpowiedź, ponieważ wyraźnie myliłem się co do tego, co miałeś na myśli. Ale podtrzymuję stwierdzenie, że UML, jak każdy język, jest narzędziem komunikacji, a nie narzędziem do projektowania. Odpowiedziałeś, że „wiele języków programowania ma w nazwie słowo„ język ”, ale to nie znaczy, że służą one wyłącznie do komunikacji, a nie wykonywania” - myślę, że nie rozumiesz, że wykonanie JEST komunikacją z komputerem. Nie używałbyś również COBOL-a jako narzędzia do projektowania.
pdr
Myślę, że komentarz do „świętego graala” odnosi się do częstotliwości nauczania.
8

UML jest odpowiednikiem wzięcia śrubokręta i młotka, zlepienia ich razem i nazwania „uniwersalnym narzędziem do mocowania”. Teoretycznie można go użyć do przedstawienia bardzo wielu szczegółów, w praktyce jest to zestaw słabo zintegrowanych narzędzi, które podają się za jedno narzędzie, co znacznie utrudnia wykonanie każdego zadania, niż posiadanie odpowiedniego narzędzia na początek.

Ryathal
źródło
Zabawne jest to, że istnieje harborfreight.com/impact-screwdriver-set-with-case-37530.html
Buddhi741
3

Wydaje mi się, że należy również wysunąć argument, że MDD jest najgorszą rzeczą, jaka przytrafiła się UML (po co mielibyśmy mieć UML2, który mamy?), Ale ignorując to na razie ...

MDD = Model sterowany <Projektowanie | Rozwój>. Chodzi o to, aby być w stanie opracować rozwiązania na poziomie abstrakcji odpowiednim do dziedziny problemowej - to jest próba wyrażenia rozwiązania problemów w najbardziej naturalnej składni do wyrażenia tych rozwiązań. Sama dziedzina problemowa charakteryzuje się modelem operacyjnym (to znaczy modelem, który można wykonać za pomocą komputera). Tak więc MDD może być bardzo atrakcyjnym podejściem, aczkolwiek z dwoma głównymi wymaganiami:

  1. Trzeba umieć skompilować ten język do formy odpowiedniej do wykonania komputerowego (model musi działać ); i
  2. Należy stworzyć język modelowania dla domeny problemowej.

Rozumiem, że wysiłek UML2 miał na celu zajęcie się punktem 1, prawdopodobnie pod przekonaniem, że doświadczenia przemysłowe z UML wykazały, że punkt 2 był spełniony w przypadku niektórych dużych podzbiorów domen problemowych. Niestety, i myślę, że właśnie do tego zmierzał William Cook, UML nie spełnia punktu 2 z powodu bliskiego zakresu rozważanych problemów. Nie mówię z własnego doświadczenia, ale myślę, że przemysłowe doświadczenie używania MDD z UML ma dwa wspólne wyniki:

  • Albo kod źródłowy wygenerowany z UML musi zostać zmodyfikowany, aby rozwiązać te małe luki między projektem UML a wymaganiami programu (zmuszając programistów do pracy z generowanym kodem, który ma różne standardy konserwacji i zmniejszając możliwość zastosowania artefaktów UML do implementacji ); LUB
  • UML jest zaśmiecony wieloma szczegółami, co zmniejsza jego użyteczność jako języka do komunikowania się na temat projektu.

    W obu przypadkach obietnica MDD jest niespełniona. UML może być uważany za najgorszą rzecz, jaka przydarzyła się MDD, ponieważ zwrócił uwagę twórców narzędzi MDD na wykluczenie modeli, które mogłyby faktycznie działać (choć w przypadku mniejszego zestawu problemów z oprogramowaniem).

  • Aidan Cully
    źródło
    -2

    UML jest świetny, o ile jest tylko językiem modelowania. Jeśli spróbujesz połączyć MDD z UML, aby uzyskać widok graficzny, jest to bezużyteczne. MDD byłoby świetne bez UML, a także UML bez MDD.

    Powiedzmy, że UML i MDD rozwiedli się dzisiaj, aby mieć lepsze życie już nie razem :-)

    UML_Guru
    źródło
    Na żadnym poziomie nie jest „świetny”. Użytkownik katastroficznego języka programowania ADA (Booch) stworzył dziecinne diagramy i połączył kilka poważniejszych podejść do tworzenia diagramów UML. UML natychmiast stał się generatorem przychodów dużego producenta oprogramowania. To było przerażające, ale uratowane przez zwykłe upuszczenie nowych typów diagramów (ten wcześniejszy UML), takich jak sekwencja, przepływ danych itp. Nie ma w tym nic rozszerzalnego. Bez schematów baz danych, bez diagramów warstw, jest pełen luk i jednocześnie bezużytecznych diagramów.
    Rick O'Shea,