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

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.

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

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.

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:

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 :-)