Większość, jeśli nie wszyscy informatycy, których znam, uważają, że przed kodowaniem korzystne jest modelowanie oprogramowania za pomocą UML lub innych typów diagramów. (Moje pytanie nie dotyczy konkretnie UML, może to być dowolny graficzny lub tekstowy opis projektu oprogramowania).
Nie jestem tego taki pewien. Głównym powodem jest: Kod nie kłamie. Jest sprawdzany przez kompilator lub tłumacza. Mam nadzieję, że ma zautomatyzowane testy i musi przejść analizę kodu statycznego. Jeśli moduł nie komunikuje się poprawnie z innym modułem, zwykle jest to oczywiste w kodzie, ponieważ pojawia się komunikat o błędzie.
Nie można tego wszystkiego zrobić za pomocą diagramów i innych dokumentów. Tak, istnieją narzędzia sprawdzające UML, ale wszystko, co do tej pory widziałem, jest bardzo ograniczone. Dlatego dokumenty te są zwykle niekompletne, niespójne lub fałszywe.
Nawet jeśli same diagramy są spójne, nie możesz być pewien, że kod faktycznie je implementuje. Tak, istnieją generatory kodu, ale nigdy nie generują całego kodu.
Czasami mam wrażenie, że obsesja na punkcie modelowania wynika z założenia, że kod nieuchronnie musi być jakimś niezrozumiałym bałaganem, z którym architekci, projektanci lub inni dobrze opłacani ludzie, którzy dostają duży obraz, nie powinni mieć do czynienia. W przeciwnym razie byłoby o wiele za drogo. Dlatego wszystkie decyzje projektowe należy odejść od kodu. Kod należy pozostawić specjalistom (małpy kodowe), które potrafią go napisać (i być może przeczytać), ale nie muszą zajmować się niczym innym. Prawdopodobnie miało to sens, gdy asembler był jedyną opcją, ale współczesne języki pozwalają na kodowanie na bardzo wysokim poziomie abstrakcji. Dlatego tak naprawdę nie widzę już potrzeby modelowania.
Jakich argumentów przemawiających za modelowaniem systemów oprogramowania brakuje?
Nawiasem mówiąc, uważam, że diagramy to świetny sposób na dokumentowanie i komunikowanie niektórych aspektów projektowania oprogramowania, ale to nie znaczy, że powinniśmy na nich opierać projektowanie oprogramowania.
Wyjaśnienie:
Pytanie zostało zawieszone jako niejasne. Dlatego dodam kilka wyjaśnień:
Pytam, czy warto używać dokumentów (niekodujących), które modelują oprogramowanie jako podstawowe źródło prawdy o projektowaniu oprogramowania. Nie mam na myśli przypadku, w którym znaczna część kodu jest generowana automatycznie z tych dokumentów. Gdyby tak było, uważałbym same dokumenty za kod źródłowy, a nie za model.
Wymieniłem wady tej procedury, które sprawiają, że zastanawiam się, dlaczego tak wiele osób (z mojego doświadczenia) uważa ją za preferowany sposób projektowania oprogramowania.
źródło
Odpowiedzi:
Zaletą modelowania systemów oprogramowania w porównaniu do całego kodu jest to, że mogę dopasować model do tablicy.
Wierzę w magię komunikowania się na jednym arkuszu papieru. Gdybym próbował umieścić kod na tablicy, ucząc nasz system nowych koderów, po prostu nie ma kodu o wymaganym poziomie abstrakcji, który mieści się na tablicy.
Znam obsesję na punkcie modelowania, o której mówisz. Ludzie robią rzeczy, bo tak właśnie robili wcześniej, nie zastanawiając się, dlaczego to robią. Przyszedłem nazywać to formalizmem. Wolę pracować nieformalnie, ponieważ trudniej jest ukryć głupotę za tradycją.
To nie znaczy, że od czasu do czasu nie wyciągam szkicu UML. Ale nigdy nie będę facetem, który zażąda od ciebie dokumentu UML, zanim będziesz mógł kodować. Mogę potrzebować poświęcić 5 minut i znaleźć NIEKTÓRY sposób na wyjaśnienie tego, co robisz, ponieważ nie mogę znieść istnienia kodu, który rozumie tylko jedna osoba.
Fowler zidentyfikował różne sposoby używania UML, które nazwał trybami UML . Niebezpieczną rzeczą jest to, że można je ukryć przed wykonaniem pożytecznej pracy. Jeśli robisz to, aby kodować za pomocą myszy, dobrze widziałem wielu prób. Nie widziałem, żeby ktoś sprawił, że to naprawdę działa. Jeśli robisz to w celu komunikacji, lepiej upewnij się, że inni cię rozumieją. Jeśli robisz to w celu zaprojektowania, cholernie lepiej znajdź i rozwiąż problemy podczas pracy. Jeśli wszystko idzie gładko, a większość czasu spędzasz na ładnym strzale, odrzuć go i wróć do pracy.
Co najważniejsze, nie twórz diagramów, które mają być ważne dłużej niż jeden dzień. Jeśli w jakiś sposób możesz, nie udało ci się. Ponieważ oprogramowanie ma być miękkie. Nie spędzaj tygodni na tworzeniu diagramów we właściwy sposób. Po prostu powiedz mi, co się dzieje. Jeśli musisz, użyj serwetki.
To powiedziawszy, wolę koderów, którzy znają swój UML i wzorce projektowe. Łatwiej się z nimi komunikuje. O ile wiedzą, że tworzenie diagramów nie jest pracą na pełny etat.
źródło
Nie. To nigdy nie ma sensu. Twój kod jest podstawowym dokumentem projektowym, tj. „Głównym źródłem prawdy o projektowaniu oprogramowania”. Tylko kod opisuje dokładnie to, co robi aplikacja, ponieważ kompilator pobiera ten projekt i tworzy z niego aplikację.
Używaj diagramów jako dodatkowych dokumentów projektowych, ale jeśli nie są one generowane automatycznie z kodu, strzeż się, że opowiadają inną historię niż prawdziwy projekt. Jeśli UML pływa łodzią, użyj tego. Jeśli nie, użyj czegoś innego.
Niektórzy ludzie uważają, że warto naszkicować swoje myślenie w formie diagramu przed rozpoczęciem pisania kodu. Pamiętaj jednak, co powiedział wujek Bob w tej sprawie:
Jeśli używasz UML do eksploracji projektu, wyrzuć je, gdy zaczniesz kodować. Napisz test, a następnie napisz kod, aby go przejść. Powtarzać. W ten sposób uzyskasz zatwierdzony projekt. UML nigdy nie może zaoferować tego samego poziomu weryfikacji twojego projektu.
źródło
actionPerformed()metoda znajduje się w warstwie prezentacji i że powinna ona po prostu przekazać kontrolę nad warstwą domeny, jest kluczowym aspektem separacji. (Trywialny przykład, ale można go zastosować do wszelkiego rodzaju strategii projektowych, które nie są łatwe do pokazania tylko w kodzie).Nie zgadzam się z tym, że wszyscy znajomi w to wierzą, ale nie sądzę, że jest to powszechne. W 1970 roku Winston Royce wiedział, że rozwój oprogramowania ma pewien poziom iteracji między działaniami projektowymi a kodowymi. W 1992 r. Jack Reeves napisał o kodowaniu jako prawdziwej działalności projektowej ( omawianej również na Wiki Wiki ).
Nie oznacza to, że ludzie próbowali tworzyć narzędzia programistyczne oparte na modelu. Istnieją narzędzia, które próbują generować kod z modeli UML (i nie tylko diagramy klas, ale łącząc ze sobą różne typy diagramów i generując z nich kod). Ale to nie są, przynajmniej z tego, co widziałem, powszechnie używane narzędzia.
Nie oznacza to również, że powinieneś przejść od wymagań do pisania kodu. Istnieją pewne decyzje projektowe, które mają kluczowe znaczenie dla wczesnego podjęcia decyzji, a pewien poziom modelowania może być przydatny, aby upewnić się, że wszyscy rozumieją opcje, ich wpływ i mogą się komunikować. Niektórzy ludzie (w tym ja) nazywają to „architekturą oprogramowania” .
To tak naprawdę stanowi sedno niektórych aspektów modelowania zwinnego, zwłaszcza specyfikacji wykonywalnych i pojedynczego źródła informacji . Niekoniecznie zgadzam się z TDD, ale pomysł, aby kod i powiązane testy (od jednostki przez testy akceptacyjne, najlepiej przechwycone jako testy automatyczne) były jednym źródłem prawdy, jest dobrym pomysłem.
Myślę, że ogólną zasadą jest przejście z kodu model-> w niewłaściwy sposób. Zamiast tego kod powinien generować modele. Oznacza to, że narzędzia powinny być w stanie badać kod i generować graficzne i tabelaryczne reprezentacje, które mogą być dalej ulepszane, gdy inżynierowie piszą wokół nich tekst. Ta generacja modeli z kodu powinna być bezproblemową częścią procesu kompilacji i wydania.
Istnieją narzędzia, które w różnym stopniu obsługują to w różnych językach. Biorąc pod uwagę naturę języków i paradygmatów, dla niektórych jest to łatwiejsze niż dla innych.
Nie sądzę, aby ci ludzie koniecznie rozumieli inżynierię oprogramowania i projektowanie oprogramowania. Myślę, że ci ludzie patrzą na to, co robią inne dyscypliny inżynieryjne i przypisują to do rzeczy, które według nich powinni robić inżynierowie oprogramowania. Ale ignorują jedną zasadniczą różnicę. Inne dziedziny inżynierii tworzą najpierw modele i symulacje, ponieważ zbudowanie rzeczywistego produktu jest niezwykle kosztowne i czasochłonne. W inżynierii oprogramowania możemy wziąć części naszego projektu i wyprodukować coś, co można przetestować w środowisku rzeczywistym w bardzo krótkim czasie i przy bardzo niskich kosztach. Ekonomia jest bardzo różna.
Gdy masz wyjątkowo skomplikowany system oprogramowania, posiadanie modeli oznacza posiadanie czegoś, co jest łatwiejsze do zrozumienia. To inny poziom abstrakcji, coś, co pomaga ludziom zrozumieć różne aspekty twojego systemu. Jest to jeden z powodów, dla których istnieje tak wiele różnych języków modelowania i różnych typów modeli dozwolonych przez każdy język lub notację modelowania - aby umożliwić różnym interesariuszom szybkie i łatwe zrozumienie systemu oprogramowania.
źródło
Wiele dokumentów niekodowanych jest przydatnych jako plany . Oznacza to, że „prawda” projektu powinna podążać w tym kierunku. Jest to sposób na modelowanie elementów, które musi spełnić projekt. Można nazwać je dokumentami wymagań, ale może to być zbyt mocne we wszystkich przykładach, które mógłbym podać. Użyłem PlantUML przez PlantText.com do ich produkcji.
Diagramy przypadków użycia mogą przedstawiać zamierzone funkcje i interakcje z użytkownikami lub systemami zewnętrznymi.
Diagramy aktywności mogą pokazywać procesy biznesowe, które oprogramowanie musi obsługiwać.
Diagramy stanów mogą pokazywać zamierzoną dynamikę na stronie internetowej:
Wzory projektowe Gang of Four są przedstawiane jako modele statyczne i dynamiczne. Na przykład Memento:
Jeśli interesują Cię prawdziwe informacje o korzystaniu z UML poza twoim doświadczeniem, są pewne badania, które zostały wykonane (starałem się znaleźć linki do artykułów niepłacących):
źródło
My, programiści, uwielbiamy używać zdjęć do wyjaśnienia naszego świata, dlatego oto jedno z produkcji samochodu:
W naszych światach często zdarza się, że ci, którzy wymyślają i tworzą dokument projektowy, są tacy sami, jak ten, który tworzy kod. Nie dotyczy to innych dziedzin. Nie oznacza to jednak, że naprawdę możesz osiągnąć ten sam poziom jakości, wykonując je wszystkie razem.
Tworząc najpierw ten dokument bez kodowania (z wyłączeniem czegoś takiego jak dowód słuszności koncepcji ...):
Uwaga: te afirmacje zakładają, że kod jest naprawdę odzwierciedleniem projektu i oba są na bieżąco ...
źródło