Dlaczego niewłaściwe jest używanie diagramów UML do planowania organizacji kodu?

Tak, diagramy mogą być czasami nieodpowiednie. Kiedy są nieodpowiednie? Kiedy tworzysz je bez kodu, aby je zweryfikować, a następnie zamierzasz ich przestrzegać. Nie ma nic złego w rysowaniu diagramu, aby zbadać pomysł.

_{Zwinne tworzenie oprogramowania: zasady, wzorce i praktyki - Robert C. Martin}

Co on dokładnie przez to rozumie? Czy UML nie został zaprojektowany, aby pomóc zaplanować strukturę kodu przed „zanurzeniem się”? Jaki jest sens korzystania z niego, jeśli nie postępujesz zgodnie ze schematami, które wymyśliłeś?

Kontekst: W tym rozdziale wujek Bob tworzy diagram UML dla zdobywcy punktów w grze w kręgle. Następnie rozwija program w sposób testowy, bez sprawdzania schematu UML. Powstały program nie przypomina diagramu UML, a wujek Bob dochodzi do powyższego wniosku.

design object-oriented tdd uml q126y
źródło

Punktem wuja Boba jest to, że architektura wyłaniająca się z programowania opartego na testach może się radykalnie różnić od schematu UML.

Robert Harvey,

Przeczytaj także, czy projekt nie żyje? Autor: Martin Fowler za zrównoważoną dyskusję na ten temat i zwinny ruch

Eliezer Steinbock,

Wzmocnienie tego pytania w odpowiedzi na zły osąd @RobertHarvey i in. Podczas głosowania w celu zamknięcia tego ważnego i przydatnego pytania.

David Arno,

@DavidArno Jeśli masz mocne opinie na temat tego, co powinno, a czego nie powinno być zamknięte, gorąco zachęcam do wzięcia udziału w dyskusjach na naszej stronie meta. Wszyscy, którzy obecnie tam publikują (w tym ja), prawdopodobnie należą do „@RobertHarvey i in.”, Z wyjątkiem kilku pracowników SE, i obawialiśmy się, że nie można reprezentować innego punktu widzenia, ale jak dotąd nikt go nie pokazał .

Ixrec,

@Ixrec, nigdy wcześniej nie angażowałem się w dyskusje na temat meta, inaczej niż raz, aby sprawdzić, czy mogę odnieść się do własnych bibliotek open source w odpowiedziach (odpowiedź na to była taka, że mogłem). Może powinienem jednak skorzystać z twojej porady i zaangażować się bardziej. Dzieki za sugestie.

David Arno,

Odpowiedzi:

Aby właściwie to wyjaśnić, potrzebujemy krótkiej lekcji historii. We wczesnych latach inżynierii oprogramowania często stosowaną analogią było budowanie domu. Architekt i inżynier budowlany omawiają plany z klientem i opracowują projekt. Następnie budowniczowie wykonują ten projekt, aby zbudować rzeczywisty dom. Pisanie kodu było postrzegane jako odpowiednik budowy rzeczywistego domu. Tak więc istniała potrzeba wcześniejszego zaprojektowania, zanim ta kompilacja będzie mogła mieć miejsce. Stworzono różne narzędzia do projektowania graficznego, w tym UML.

Pierwotnie pomysł z UML polegał na tym, że należałoby w pełni zaprojektować system z UML, a następnie przekazać go programistom, aby przełożyły ten projekt na kod. W rzeczywistości to po prostu nie działa i doprowadziło do tego, że lata programistów były postrzegane jako „realizatorzy”, a nie „projektanci”, projekty były spóźnione, projekty musiały się ciągle zmieniać po tym, jak miały być ukończone itp.

Powód jest prosty. Kodowanie to projektowanie . W przypadku analogii domu kod jest rysunkiem architekta. Kompilator jest konstruktorem, który bierze te projekty i tworzy z nich program. Ta realizacja doprowadziła następnie do powstania zwinnych technik, narodzin TDD itp.: Narzędzi pomagających poprawić jakość tego projektu kodu.

Tak jak architekt może przygotować wstępne szkice, aby pomóc jej i jej zespołowi wizualizować ogólny projekt, tak programista może użyć UML lub innych narzędzi, aby pomóc w wizualizacji potrzebnego projektu. Tak jak te szkice nie są ślepo przestrzegane, tak nie należy ślepo przestrzegać UML. Projekt kodu powinien ewoluować w oparciu o zwinne iteracje i używanie TDD. Podsumowując, tak jak architekt może zbudować model domu, aby pomóc jej i jej zespołowi w wizualizacji rysunków, tak też UML może pomóc w wizualizacji struktury kodu.

Jak mówi wujek Bob, nie możesz sprawdzić poprawności UML, możesz jedynie zweryfikować kod. Dlatego kod jest główną dokumentacją projektową, a UML, jeśli jest używany, jest jedynie dokumentacją wtórną.

David Arno
źródło

Część dachu mojego domu podniosłem wcześniej w tym roku i było to dość pouczające. Architekt naprawdę nie zrobił nic więcej, niż rysował, jak powinien wyglądać produkt końcowy. Wręczył ciężkie obliczenia i projekt konstrukcyjny inżynierowi budowlanemu. Budowniczowie musieli następnie dopasować teoretyczne projekty do rzeczywistości domu (po wyłączeniu płyty gipsowej belki znajdowały się w nieco innych miejscach), więc projektowanie odbywało się na każdym kroku.

Jaydee,

To przydatna odpowiedź, jednak upraszcza niektóre aspekty. Jednym z głównych powodów, dla których UML nie działa dobrze, ponieważ „notacja projektowa wysokiego poziomu” jest IMHO, ich wynalazcy byli zbyt uparci, aby dodać schemat przepływu danych. Jest to jedyny rodzaj zapisu, jaki znam, który pasuje do najlepszych projektów, pozwalając wyrazić abstrakcje dla komponentów i interfejsów między nimi o różnej skali, a także może mieć dobrze zdefiniowane odwzorowanie na kod. Zamiast tego UML zawiera wiele bzdur, których nikt tak naprawdę nie potrzebuje.

Doc Brown

Wydaje mi się, że nie każdy idiom programistyczny (lub projekt, czy kod) pasuje do UML (co przyznaję, że nie wiem dobrze - po prostu czytam kilka książek na ten temat - nigdy go nie używałem i prawdopodobnie go nie lubię).

Zwykły kod C (np. Kod źródłowy jądra Linuksa) może nie być dokładnie modelowany przez UML.

Kod Ocaml (z jego modułami i funktorami), a nawet kod C ++ 11 (z lambdami i szablonami) może nie pasować do UML.

Programowanie wieloetapowe à la MetaOcaml prawdopodobnie nie pasuje do UML.

Kod Prolog lub kod Common Lisp prawdopodobnie nie pasuje do UML.

Zobacz również tę odpowiedź i tę kwestię kopalni.

Przeczytaj Scott's Programming Language Pragmatics oraz Van Concept 's Concepts, Techniques and Models of Computer Programming , a następnie zadaj sobie pytanie, czy każdy model programowania pasuje do UML.

Zobacz także: Martin Fowler Is Design Dead? blog.

Basile Starynkevitch
źródło