Jakie są zalety modelowania systemów oprogramowania w porównaniu z robieniem wszystkiego w kodzie?

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.

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.

Pytam, czy sensowne jest używanie (niekodowanych) dokumentów, które modelują oprogramowanie jako główne źródło prawdy o projektowaniu oprogramowania

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:

„ Tak, 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 w celu zbadania pomysłu ”.

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.

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.

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

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.

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.

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.

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.

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.

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.

Jakie są zalety modelowania systemów oprogramowania w porównaniu z robieniem wszystkiego w kodzie?

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.

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.

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:
  
  

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.

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

• Petre, Marian (2013). UML w praktyce . W: 35. Międzynarodowa Konferencja Inżynierii Oprogramowania (ICSE 2013), 18–26 maja 2013 r., San Francisco, Kalifornia, USA, s. 722–731.
• N. Mangano, TD LaToza, M. Petre i A. van der Hoek (2015). Jak projektanci oprogramowania wchodzą w interakcje ze szkicami na tablicy . W: Transakcje IEEE dotyczące inżynierii oprogramowania, vol. 41, nr 2, ss. 135–156.
• Andrew Forward i Timothy C. Lethbridge. 2008. Problemy i możliwości rozwoju oprogramowania skoncentrowanego na modelu a kodu opartego na kodzie: ankieta wśród specjalistów od oprogramowania . W materiałach z międzynarodowych warsztatów z 2008 roku na temat modeli w inżynierii oprogramowania (MiSE '08). ACM, Nowy Jork, NY, USA, 27–32.

My, programiści, uwielbiamy używać zdjęć do wyjaśnienia naszego świata, dlatego oto jedno z produkcji samochodu:

• Samochód jest wynikiem łańcucha produkcyjnego, tak samo dla kodu (oczywiście dodaj proces wdrażania).
• Dokument projektowy samochodu jest taki sam jak dokument projektowy oprogramowania.

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

• Z pewnością pomyślisz przed zrobieniem, kodowanie, gdy wiesz, co musisz zrobić, jest ŁATWE.
• Jesteś w stanie zmusić bardziej doświadczone osoby do skupienia się na najtrudniejszej części twojego oprogramowania: projektowanie, algorytm / matematyka są dowolne, z wyjątkiem bardzo specyficznego celu (wbudowany, w czasie rzeczywistym, montaż).
• Możesz przekazać mniej doświadczonym ludziom dużą część procesu kodowania, podczas gdy bardziej doświadczeni ludzie skupiają się tylko na tych najbardziej krytycznych częściach, które potrzebują poziomu ich umiejętności. Mniej doświadczeni ludzie wiele się o tym dowiedzą.
• Możesz dyskutować z osobami niebędącymi informatykami poprzez obraz dokumentu projektowego, a jeśli miałbyś tylko kod, musiałbyś wyodrębnić obraz tego, co zrobiłeś, z całym ryzykiem zapomnienia o czymś (gdzieś zapomniany słuchacz ...). Zobacz odpowiedź CandiedOrange, aby uzyskać więcej informacji na temat komunikacji.
• Gdy musisz dokonać ewolucji oprogramowania, możesz lepiej przewidzieć, jaki będzie wpływ.
• Projektowanie ułatwi wycięcie części oprogramowania i jednoczesne rozwijanie części oprogramowania.
• Napisz te cholernie rebeliatywne testy jednostkowe będą o wiele łatwiejsze, gdy nie będziesz musiał mieć kłopotów z koniecznością pokrycia wszystkich przypadków podczas ich kodowania, w podejściu TDD kodującym test, zanim kod będzie łatwy.
• ...

Uwaga: te afirmacje zakładają, że kod jest naprawdę odzwierciedleniem projektu i oba są na bieżąco ...