Czy powinieneś tworzyć diagramy klas przed wdrożeniem czy po nim?

Widzę to, jeśli utworzysz taki, zanim uzyskasz przewagę:

• Planowanie z wyprzedzeniem
• Omówienie projektu

ale przegrywasz:

• Czas (wykonywanie pracy, którą prawdopodobnie będziesz powtarzać podczas pisania kodu)

Z drugiej strony, mogłem je wszystkie utworzyć po napisaniu mojego kodu, aby zachować go jako odniesienie dla przyszłych programistów.

Który służy do celów diagramów klas, a który jest bardziej korzystny?

Jeśli utworzysz je wcześniej, będą one częścią fazy projektowania.

Jeśli utworzysz je później, możesz po prostu użyć ich do dokumentacji. Ale dokumentowanie jest lepsze i szybsze, jeśli robisz to podczas projektowania i kodowania.

Nawiasem mówiąc, nie tracisz czasu na projektowanie! Część kodująca będzie szybsza. I lepiej.

W końcu uważasz, że projektowanie drapacza chmur lub mostu to strata czasu, a nie budowanie go?

Kompromisem jest rozpoczęcie tworzenia jakiegoś fałszywego kodu podczas fazy projektowania (tylko prototypy klas / funkcji) i wykorzystanie tego szkieletu kodu do budowania diagramów klas.

Kiedy już je utworzyłem przed kodowaniem, widzimy je jako dokumenty „tymczasowe”. Oznacza to, że tworzymy diagramy i zapisujemy nasze myśli na papierze. Zaczynamy kodować od tych diagramów klas. Następnie je wyrzucamy. Nie warto tracić czasu na ich utrzymanie po rozpoczęciu kodowania. A jeśli chcesz mieć aktualne modele klas, użyj narzędzia, aby je utworzyć z kodu.

W obu przypadkach pozostaną w ramach dokumentacji. Nikt ich nie zaktualizuje po wprowadzeniu zmian w implementacji. Diagramy nie będą zawierać dat, więc nie będziesz nawet wiedział, do której wersji kodu się odnoszą. Gdy do projektu zostanie dodana nowa osoba, przekażesz jej diagramy z informacją: „Oto kilka diagramów, które zostały utworzone w pewnym momencie projektowania lub wdrażania. Nie wiemy, jak aktualne są”.

Jest to część projektu i dlatego powinna zostać utworzona przed wdrożeniem. Nie oznacza to, że nie można ich dopracować podczas / po implementacji, aby odzwierciedlić aktualny stan implementacji.

Zapewnienie projektu po wdrożeniu to, co nazwałbym „kodowaniem kowboja”, i na pewno możesz się rozwijać na dzikim dzikim zachodzie, ale pamiętaj, że kowboje zwykle w pewnym momencie padają martwi.

To zależy od głębokości projektu. Niektórzy nalegają na pisanie diagramów klas nawet dla najbardziej trywialnych klas, ponieważ „to dobra praktyka”. Myślę, że narysowanie czegoś jest stratą czasu, gdy już wiesz dokładnie, jak to będzie realizowane. Podczas tworzenia nowego projektu, czegoś nieznanego, zdecydowanie warto najpierw narysować kilka diagramów.

Nigdy nie używam narzędzi UML, ponieważ projekt zwykle zmienia się tak bardzo podczas implementacji, że muszę przerysować schemat. Przypuszczam, że dobre dwukierunkowe narzędzie poradziłoby sobie z tymi zmianami, ale nigdy nie korzystałem z dobrego (korzystałem tylko z darmowych). Zamiast tego rysuję na papierze lub na tablicy, aby pomóc mi uporządkować projekt. Po jego wdrożeniu i upewnieniu się, że brzmi to dobrze, zrobię bardziej formalny schemat.

Nie zapominajmy też o innych typach diagramów. Zawsze uważałem, że diagramy sekwencji są jednymi z najbardziej przydatnych i używam ich często, gdy istnieje duża komunikacja między komponentami.

Przed wdrożeniem. Jak jeden z moich byłych współpracowników powiedział kiedyś: „Lubię robić jak najwięcej programowania, zanim zacznę kodować”, i myślę, że to dobre podejście do tego.

Uważam, że narysowanie diagramu zwykle ostrzega mnie o brakujących informacjach. Stanie się tak również, jeśli po prostu piszę w edytorze kodu bez rysowania schematu, ale instancje będą bardziej oddalone od siebie (ponieważ spędzę czas na pisaniu algorytmów, obliczeń i testów itp.), Więc mogę pozwolić na więcej czasu na przejść przed otrzymaniem moich brakujących informacji.

Ponadto, jeśli projekt, który niejasno masz w głowie, okaże się bzdurą, zauważysz to szybciej, jeśli najpierw go nakreślisz. Dlatego przynajmniej rysuję coś szybko i nieformalnie. To, czy przekształci się w schemat elektroniczny, którego inni mogą użyć w celach informacyjnych, będzie zależeć od projektu.

Tworzenie diagramów klas powinno odbywać się w trakcie i po nim, ponieważ model powinien być interaktywny z modyfikacjami kodu i wymagań. Najpierw musisz stworzyć diagram klas, aby rozpocząć projekt. Pomoże to wizualizować na wyższym poziomie abstrakcji twoje obiekty. Będziesz mógł stworzyć stabilną i inteligentną architekturę oprogramowania. Następnie musisz napisać kod, a czasem zauważysz, że architektura, która wydaje się być dobra w UML, nie jest tak naprawdę możliwa w kodzie. Następnie zmieniasz kod i architekturę. Na koniec aktualizujesz swój model, modyfikując kod i generując dokumentację.

W ostatnim projekcie decydenci zmienili moje wymagania ponad 50 razy w ciągu ostatniego roku. Jest to bardzo bolesne, a UML pomaga mi śledzić zmiany i dlaczego. UML powinien umożliwiać scalanie modelu i kodu w dowolnym momencie w sposób iteracyjny (np. Od kodu do modelu, od modelu do kodu, od obu po kod po refaktoryzacji itp.) Używam Omondo EclipseUML dla Helios i jestem bardzo zadowolony z to narzędzie. Moją ulubioną funkcją jest scalanie modeli, która pozwala mi na aktualizację modelu w dowolnym momencie bez utraty informacji o modelu. Lubię też modelowanie jednostek bezpośrednio na diagramie klas i tworzenie bazy danych przy użyciu stereotypu i hibernacji. Naprawdę potężny i kompletny od obiektu do bazy danych !!

Przedtem : pomoże ci uporządkować myśli i przekazać twoje zamiary. Nie wchodź tutaj w szczegóły.

Po : jest automatycznie generowany z kodu jako część procesu kompilacji, oczywiście (mam nadzieję, że nie jesteś zbyt przywiązany do uml)

Oba są przydatne, ale przedtem rzeczy można wyrzucić, gdy tylko zostaną zaimplementowane ... w tym momencie i tak są już przestarzałe.

W Topcased tworzę diagramy klas podczas fazy projektowania. Następnie klikam przycisk „Generuj kod”, aby utworzyć płótno mojej implementacji. Następnie wypełniam symbole zastępcze kodem.

Głosuję na odpowiedź (C) Nie przejmuj się.

Są w dużej mierze niepotrzebne. Osobiście nigdy nie zadaję sobie trudu, aby na nie spojrzeć, kiedy są zapewnione.

Są niepotrzebne przed opracowaniem, ponieważ projekt i tak się zmieni. A jeśli nie uważasz, że plan zajęć się zmieni, oznacza to, że już jesteś kajdankami i uniemożliwiasz swojemu przyszłemu ja właściwe rozwiązywanie problemu. Jeśli uważasz, że musisz trzymać się wcześniej istniejących schematów klas, albo pracujesz dla NASA, albo strzelasz sobie w stopę.

Następnie są niepotrzebną dokumentacją. Jeśli nie możesz dowiedzieć się, co robią klasy lub jak są one ze sobą powiązane, przeprowadzając małą kontrolę kodu, masz dziurę w swoich umiejętnościach jako programista.

Oczywiście ta odpowiedź brzmi naprawdę arogancko i zdyscyplinowana; No cóż.

W przypadku Eiffela i powiązanych narzędzi jest to tylko różnica poglądów, z których wszystkie wskazują te same pliki źródłowe.