Jak ważne są diagramy UML dla udanego projektu? [Zamknięte]

Jestem w trakcie projektu i poproszono mnie o napisanie diagramów UML (przypadki użycia, diagram klas itp.). Projekt nie jest zbyt skomplikowany.

Zastanawiałem się, czy to strata mojego czasu? Czy powinienem robić inne fajne rzeczy, takie jak pisanie kodu? A kiedy budowanie czegoś bez przejścia przez całą fazę koncepcyjną nie jest w porządku? Czy chodzi o złożoność? A jeśli tak, jak to zmierzyć?

Jakiś czas temu byłem wielkim fanem UML. Mam nawet certyfikat OMG. Wykorzystałem go szeroko w dużych projektach korporacyjnych, w które byłem zaangażowany.

Dzisiaj prawie całkowicie zatrzymałem UML. Czasami używam diagramu sekwencji, który uważam za bardzo przydatny, do opisywania interakcji między systemami, ale żadnych innych diagramów.

Teraz wolę pracować z historiami użytkowników, popartymi zarówno (tylko) niezbędną dokumentacją napisaną przez właściciela produktu (lub analityków) ORAZ jego (ich) poświęcenie zespołowi programistów, aby podać więcej szczegółów w razie potrzeby.

UML to narzędzie, którego możesz użyć, ale z pewnością nie jest to kluczowy czynnik sukcesu twoich projektów. Po wielu latach uważam, że kluczowym czynnikiem jest zespół programistów, bez względu na to, jakich narzędzi używa.

Planowanie ma kluczowe znaczenie, ale, jak ostrzega słynny strateg Carl von Clausewitz

Żaden plan kampanii nie przetrwa pierwszego kontaktu z wrogiem

Więc nie jest to wielka strata czasu na planowanie, jak początkowo atakować problemy. Ale prawdopodobnie strata czasu na udokumentowanie kodu dla przyszłych programistów. Aby użyć metafory wojskowej, potrzebujesz planu bitwy, ale nie dałbyś tego planu historykom do wykorzystania jako raport po akcji.

Mówiąc konkretniej, możesz wykorzystać te diagramy do komunikowania swoich zamiarów w zespole i zastanowienia się nad planem ataku przed i podczas projektu. Ale szanse są takie, że wymyślisz to, co wymyślisz, gdy będziesz kodować i dowiedzieć się więcej o tym problemie. Prawie zawsze twój początkowy plan / projekt musi zostać zmieniony, ponieważ nie możesz wiedzieć wszystkiego z góry.

Myślę, że diagramy UML mogą być użyteczne tylko wtedy, gdy wyrażają coś na wyższym poziomie abstrakcji niż twój kod .

Pisanie UML tylko dla samego pisania UML staje się niepotrzebną biurokracją i sprawia, że ​​projekt i kod są mniej przystosowalne do zmian bez żadnej korzyści.

Na przykład diagram klas UML pokazujący wszystkie klasy w pakiecie, ze wszystkimi ich atrybutami i metodami - czymś, co można łatwo wygenerować automatycznie - nie zawiera żadnej wartości: jest na tym samym poziomie abstrakcji niż kod . Ponadto kod z pewnością będzie lepszym źródłem tych informacji, ponieważ zawsze będzie aktualny i prawdopodobnie zostanie udokumentowany i zorganizowany w sposób łatwiejszy do zrozumienia, które metody / atrybuty / rzeczy są ważniejsze.

Z drugiej strony, jeśli masz pojęcia o wyższym poziomie abstrakcji niż to, co można wyrazić w kodzie, udokumentowanie ich na diagramie może być dobrym pomysłem.

Na przykład schemat przedstawiający moduły abstrakcyjne wyższego poziomu w złożonym systemie, z ich zależnościami i być może krótkim opisem ich obowiązków oraz tego, do jakiego pakietu / przestrzeni nazw odwzorowują w kodzie źródłowym, może być naprawdę przydatny dla nowego członka zespołu które należy wprowadzić do projektu lub można go również wykorzystać do ustalenia, gdzie należy wprowadzić nową klasę / funkcjonalność.

Innym przykładem przydatnego diagramu może być schemat sekwencji pokazujący kroki wysokiego poziomu, które należy podjąć w protokole komunikacyjnym. Być może każdy z nich ma małe dziwactwa i złożoność, ale prawdopodobnie wystarczy je opisać w samym kodzie. Diagram wyższego poziomu może pomóc programiście w łatwym zrozumieniu „dużego obrazu” rzeczy bez konieczności martwienia się o złożoność każdej interakcji.

W każdym razie to tylko niektóre przykłady; istnieje wiele przypadków, w których prosty schemat może być bardzo pomocny. Pamiętaj tylko, że powinieneś to robić tylko wtedy, gdy nie możesz wyrazić czegoś w samym kodzie. Jeśli używasz diagramów UML do wyjaśnienia samego kodu źródłowego, zamiast tego spraw, aby kod soruce był bardziej samo-dokumentujący.

Wreszcie, niektóre ogólne zasady dotyczące kodu mogą również dotyczyć diagramów: unikaj powtarzania się, upraszczaj, nie obawiaj się zmian (tylko dlatego, że coś jest udokumentowane na diagramie UML, nie oznacza, że ​​nie może zmienić) i zawsze pomyśl o tym, kto będzie czytał / utrzymywał te diagramy w przyszłości (prawdopodobnie twoje przyszłe ja), pisząc je :)

UML ma wartość, jeśli członkowie zespołu wspólnie to rozumieją i uważają to za użyteczny sposób podsumowywania i komunikowania decyzji projektowych. Nie musisz wiedzieć wszystkiego, tylko ten podzbiór, który zespół uważa za użyteczny.

Nie musisz też rysować idealnych, dopracowanych diagramów. Z grubsza naszkicowany schemat sekwencji na tablicy lub diagram klas, w którym klasy są karteczkami samoprzylepnymi przyklejonymi do tej tablicy, może być wystarczający, w zależności od kontekstu.

Kiedyś pracowałem nad koncertem, w którym musiałem zarządzać zespołem programistów kontraktowych za granicą.

Niektóre z rzeczy, które produkowali, były dość przerażające (powszechny objaw zdalnych koderów kontraktowych - tak naprawdę nie dbają o twój kod, po prostu chcą zrobić to szybko).

Aby zarządzać projektem, stworzyłem diagramy UML i podałem je kodowi. Odniosło duży sukces - napisanie programu w języku UML nie zajęło mi dużo czasu, znacznie szybciej niż w Javie, i było to coś, za czym kontrahenci mogli podążać i porównywać go.

Jedno zastrzeżenie - czasami chcieli stać się kreatywni i odbiegać od moich modeli, jednak w tych przypadkach były w rzeczywistości poprawne, a ponad wszystko UML poprawił jakość produktu końcowego

Jeśli ktoś poprosił cię o przygotowanie diagramów UML i że ktoś płaci ci pensję, to nie jest to strata twojego czasu. Może to być strata czasu innej osoby.

Jeśli ktoś planuje zrozumieć Twój projekt, czytając diagramy UML, to prawdopodobnie nie jest to strata czasu.

Uważam, że przydatne jest na początkowym etapie projektowania, aby uzyskać pomysły na papierze lub na tablicy. Korzystałem głównie z diagramów klas UML, bez ścisłego przestrzegania standardów. Przydaje się ponowne sprawdzenie oryginalnego projektu UML, gdy jesteś w trakcie realizacji, a także pod koniec projektu. Pomogło mi to spojrzeć na bazę kodu na wyższym poziomie abstrakcji, jaki kiedykolwiek można było po prostu czytając kod, a nawet pomogło wykryć potencjalne błędy.

Jest to dobry punkt wykonana tutaj przez ragu.pattabi rozróżnienie między dwoma rodzajami UML ...

Myślę, że zwinny smak UML (np. Szybki szkic białej tablicy) jest bardziej skuteczny niż wodospad UML (np. Skomplikowany schemat ze wszystkimi krwawymi szczegółami dla dokumentacji, generowania kodu itp., Aby uszczęśliwić menedżerów znających dokument).

Kiedy UML był postrzegany jako umiejętność „must have” (10 lat temu lub więcej), prawdopodobnie byłem przeciwko niemu ze względu na opinie wielu fanów w tym czasie. Ale teraz, gdy popadł w niełaskę, widzę, że jest taki, jaki jest - użyteczne narzędzie, które ma zalety, ale nie jest srebrną kulą rozwoju oprogramowania.

Używam UML (lub czegoś podobnego do UML :)), kiedy rozmawiam ze znajomymi o czymś, co zamierzamy zrobić. Omawiać pomysły. Nie przygotowywać projektu UML, który automatycznie wygeneruje kod dla mnie. Nie wyobrażam sobie tworzenia moich klas w języku UML, a następnie generowania kodu i nie zmieniania go później. To się nigdy nie zdarza. Będziesz musiał wprowadzić zmiany z kodu do UML. A kiedy używam UML, rysuję na tablicy lub papierze. Nigdy w narzędziach takich jak Enterprise Architect.

Jedynym powodem do udokumentowania całego mojego kodu w UML byłaby umowa, w której klient tego wymaga. Na przykład, gdy chce mieć opcję zmiany sklepu z oprogramowaniem po zakończeniu części oprogramowania.

Dokumentacja pracy projektu jest podstawowym rezultatem profesjonalnego projektu. Jak duzo wystarczy? Oczywiście zależy to od wielu czynników. Jednak moim zdaniem przypadki użycia, diagramy klas, diagramy przebiegu procesu itp. Wcale nie są stratą czasu. Mają wartość na różnych etapach projektu. Jedynym problemem związanym z dokumentacją są zwykle zasoby.

Niektórzy programiści uważają, że dokumentacja to strata czasu. Ale to nie jest prawda. Jeśli spojrzysz na dokumentację jako prezentację swojego projektu i reguł systemowych w elegancki i przejrzysty sposób, możesz docenić ją bardziej. Ponadto należy postawić się w sytuacji ludzi, którzy muszą utrzymywać system. Wyrzucenie 500 plików kodu i poproszenie o naprawienie problemów z nimi jest trochę złe, ale nierzadkie.

Sugeruję, abyś poświęcił czas na swój projekt i tworzył diagramy w cyklach. Pierwszy obejmowałby aspekty twojego projektu na wysokim poziomie, a kolejne poziomy mogłyby skupiać się bardziej na szczegółach.

W szczególności przypadków użycia nie można łatwo wywnioskować z kodu (w przeciwieństwie do wielu innych aspektów systemu). Upewnij się, że to robisz.

UML to narzędzie, nic więcej, a to, czy jest użyteczne, czy nawet kluczowe, zależy wyłącznie od przebiegu prac projektowych i projektowania. Istnieje wiele dróg do Rzymu, a niektóre z nich wymagają UML, a inne nie.

Jeśli przepływ pracy zależy od UML do dokumentowania lub planowania architektury, upuszczenie go byłoby niemądre. Jeśli UML jest najlepszym możliwym sposobem komunikowania struktury projektu innym członkom zespołu (w szerszym znaczeniu tego słowa), to za wszelką cenę skorzystaj z niego. Ale jeśli projekt działa dobrze bez UML, tworzenie diagramów UML tylko ze względu na to jest nonsensem.

Mam o tym pewne przemyślenia. Języka można używać i nadużywać, wymuszać i rozpraszać, wyzwalać i usypiać. UML jest po prostu innym językiem przystosowanym do określonego zestawu problemów i tak jak każdy inny język, zajmie trochę czasu i wysiłku, aby nauczyć się płynnie mówić i rozumieć go poprawnie.

Decyzja o tym, co się komunikować, jest niezwykle ważniejsza niż język, w którym się komunikuje. UML nie magicznie sprawi, że twoje złe projekty będą zrozumiałe. Tak jak w każdym innym języku, łatwo jest zagubić się w szczegółach lub pozostawić zbyt wiele wyobraźni.

UML ma złą nazwę z powodu wielu okropnych IDE, umożliwiając prototypowanie w obie strony, manipulowanie grafem wymagające dużej liczby kliknięć i trudność zmiany czegokolwiek. UML 2.0 może być wystarczająco skomplikowany, aby zadowolić niektórych naukowców, ale jego meta-model nie wydaje się przyciągać wielu praktycznych zastosowań.

Mimo to od czasu do czasu używam UML. Aby ocenić projekt wysokiego poziomu (dobry projekt ma złożoność na obrzeżach i prostotę w środku). Aby przekazać pomysł koledze i otrzymać informację zwrotną. Znajdować ukryte relacje, normalizować itp. Ale zawsze jest to odzwierciedlenie czegoś, co już jest w mojej głowie. Generalnie rysuję UML za pomocą pióra i papieru, najlepiej z dala od dowolnego komputera. W razie potrzeby, gdy projekt krystalizuje, wykonuję wizualną reprezentację w programie do rysowania.

UML jest absolutnie fantastyczny, aby uzyskać graficzny widok swojej architektury za pomocą diagramu klas. Interakcja za pomocą diagramu sekwencji jest dla mnie magią. Problemem nie jest więc UML, ale MDD.

Mam na myśli, że jeśli UML jest przeglądarką kodu, to jest on naprawdę pomocny do celów dokumentacji, ale z pewnością nie do generowania kodu. Projekt powinien koncentrować się na kodzie, a na pewno nie na modelu. UML powinien być stosowany na etapie implementacji przy użyciu synchronizacji kodu na żywo i modelu. Mam na myśli nie tylko poziom wymagań, który wymaga zbyt dużych inwestycji dla niewielkiego zwrotu wydajności i jakości.

Uważam je za bardzo przereklamowane. Uważam je za jedyne obrazy, które nie malują tysiąca słów.

UML ma wartość tylko wtedy, gdy osoby projektujące system nie mogą same napisać kodu. tj. UML jest „językiem”, który przekazuje koncepcje architektoniczne komuś innemu. Teraz, jeśli jesteś osobą, która projektuje kod i wdraża go, to dlaczego miałbyś chcieć pokazać, co zamierzasz zrobić ?! Zamiast tego wejdź i idź prosto do kodowania. Nadal będziesz musiał udokumentować to, co zrobiłeś później, ale ogólna wydajność jest szybsza.

Ale jeśli byłeś architektem systemu, który chciałby powiedzieć zewnętrznemu zespołowi programistów, czego chcesz, to musisz im w jakiś sposób powiedzieć, i tu właśnie pojawia się UML. Myślę jednak, że istnieje wiele alternatywnych sposobów działania to zadanie w dzisiejszych czasach i, szczerze mówiąc, złożoność diagramów UML oznacza, że ​​wszyscy muszą zrozumieć, jak je czytać, co jest w pewnym sensie samowystarczalne, jeśli tego nie zrobią.

Nigdy nie byłem fanem UML, ale doceniłem dobry schemat sekwencji opisujący interakcje między systemami lub zadaniami.

Jednak diagram klas jest przestarzały przed jego narodzinami. Wstępny projekt nie wymaga UML, a dokładna dokumentacja jest lepiej automatycznie pobierana (na żywo) z bazy kodu. Javadoc i Doxygen całkowicie zdezaktualizowali potrzebę ręcznych diagramów klas.

Dokumentacja polega na tym, że istnieją dwa poziomy:

• decyzje na wysokim szczeblu (architektoniczne) powinny być dokumentacją ręcznie
• fakty niskiego poziomu (relacje między podmiotami) powinny zostać wyodrębnione automatycznie

Zwykle iteruję między kodem a diagramami UML. Uważam, że diagramy pokazują duży obraz i solidną ścieżkę naprzód i można je zmienić dość szybko po wykryciu problemów. Ponadto, gdy mam schematy, kodowanie staje się trywialne.

I odwrotnie, kiedy rysuję kod na zdjęciach, uwidacznia to problemy zależności i sprawia, że ​​możliwości ulepszenia projektu są rażąco oczywiste, co prawdopodobnie nie zostałoby zauważone, gdybyśmy mieli po prostu kod do pracy. W szczególności, jeśli narysowanie jest uciążliwe, będzie to również utrudnienie w kodowaniu i utrzymanie koszmaru.

Przekonałem się, że iteracja jest wymagana, ponieważ samo rysowanie obrazów zawsze pomija ważne aspekty, a samo kodowanie powoduje problematyczne projekty.

Jednak, jak powiedział inny plakat, wszystko sprowadza się do ludzi. Jeśli potrafią „używać” diagramów UML, UML jest nieoceniony. Jeśli tak nie jest, diagramy nie mają żadnej wartości.

Tak więc odpowiedź na twoje pytanie brzmi „zależy”. W takim przypadku zależy to od ludzi, złożoności projektu i tego, jak ważne jest prawidłowe działanie systemu.

Z mojego doświadczenia wynika, że ​​UML jest ważny w komunikacji między programistami na temat wzorców kodu i ogólnie dla architektury aplikacji.

Uwielbiam diagramy, ale gdybym został poproszony o zrobienie jednego (szczególnie UML!), Zadałbym dwa pytania:

1. Dla kogo to jest?
2. Czy potrzebują tego teraz?

Diagramy od razu stają się nieaktualne. Więc jeśli nie używasz go teraz do komunikacji z kimś teraz, po prostu gnije. A jeśli osoba, z którą się komunikujesz, lepiej poradziłaby sobie z opisem tekstowym, rozmową telefoniczną lub nieformalnym digramem na tablicy - sugeruj to zamiast tego.

Jednym z głównych problemów związanych ze schematami UML, jakie widziałem do tej pory, jest to, że zwykle służą one tylko jako „ładne zdjęcia” na czyjejś ścianie lub jako złożoną stronę w oprawie i rzadko służą jako podstawa dla kodu produkcyjnego.

W tego typu scenariuszu diagramy UML (lub inny rodzaj używanego języka modelowania) rzadko są przydatne na dłuższą metę, ponieważ z czasem tracą na znaczeniu i wraz z rozwojem projektu. Te wstępne rysunki są w większości bezużyteczne i niepoprawne za kilka lat, a ich posiadanie jest w większości szkodliwe.

To powiedziawszy, korzystanie z narzędzi do modelowania (niekoniecznie UML) nie jest całkowicie bezużyteczną praktyką, jeśli modele zapewniają rzeczywiste i odpowiednie dane wejściowe do rzeczywistego działającego kodu. Jeśli opis modelu jest użytecznym artefaktem kodu, należy go traktować jako kod:

Albo wykorzystując go jako bezpośrednie źródło metadanych do podejmowania dynamicznych decyzji w oparciu o modelowane koncepcje, albo używając generowania kodu do generowania statycznych artefaktów kodu, które są wykorzystywane w rzeczywistym kodzie roboczym.

Nie wiem, czy pytanie dotyczy zalet UML, czy zasługi projektowania architektury programów.

O UML. Zwykle potrzebujesz tylko: przypadków użycia, diagramów klas i diagramów sekwencji. Prosty i łatwy, chociaż można to zrobić na pewno dzięki własnym typom diagramów. Pod tym względem UML jest standardem, który wszyscy zrozumieją.

O projektowaniu programów.

1. Każdy program ma swój projekt, nawet jeśli go nie planujesz. Kiedy kod zostanie napisany, po prostu poddaj go inżynierii wstecznej. Jeśli tego nie planowałeś, założę się, że będzie to zły projekt.

2. Projektowanie pozwoli Ci zaoszczędzić czas, wykorzystując znane wzorce powtarzających się problemów.

3. Jeśli pracujesz w zespole, projekt jest niezbędny do omówienia rozwiązań, przekazania pomysłów i bardzo praktyczny, ale konieczny do rozpowszechnienia pracy.