Dlaczego UML nie jest używany w większości bezpłatnych programów (np. W systemie Linux)?

Próbuję zrozumieć, dlaczego UML nie jest używany w większości projektów wolnego oprogramowania . Na przykład, mój system Debian / Linux ma prawdopodobnie ponad dziesięć tysięcy pakietów wolnego oprogramowania i nie mogę wymienić nawet jednego, który został opracowany przy użyciu jawnej struktury i metodologii UML. Na przykład, Qt , GCC , jądro Linux , bash , GNU make , Ocaml , Gnome , Unison , lighttpd , libonion , doker są bezpłatne oprogramowanie, które projekty (AFAIK) nie wspominają UML w ogóle.

^{(Domyślam się, że UML bardzo dobrze nadaje się do formalnego podwykonawstwa zadań programistycznych, i nie tak rozwija się wolne oprogramowanie)}

Zauważ, że chociaż czytałem jakiś materiał na temat UML, nie twierdzę, że dobrze go rozumiem.

Właściwie nie mogę łatwo nazwać wolnego oprogramowania, w którym użyto UML (z wyjątkiem być może niektórych narzędzi UML zaimplementowanych jako wolne oprogramowanie). Być może openstack jest wyjątkiem (coś tam wspomina o UML).

^{(nawet stare projekty wolnego oprogramowania mogły przyjąć UML po ich uruchomieniu, ale nie zrobiły tego)}

Niektórzy koledzy pracujący nad Papyrusem wspominali, że większość projektów wolnego oprogramowania nie miała na początku żadnego wyraźnie (i wystarczająco głębokiego) sformalizowanego modelu. Ponadto, UML wygląda na znacznie bardziej związany z Javą, niż twierdzi (nie jestem całkowicie pewien, czy miałoby to sens dla Ocaml, Common Lisp, Haskell lub Javascript, a może nawet nie dla C ++ 11 ....). Być może zwinne tworzenie oprogramowania nie jest zbyt przyjazne dla języka UML.

Zobacz także tę odpowiedź na jakoś powiązane pytanie. Blog M.Fowler Is Design Dead? jest wnikliwy.

^{PS. Nie sądzę, że jest to głównie kwestia opinii; powinien istnieć jakiś obiektywny powód i podstawowa cecha wolnego oprogramowania, która tłumaczy dlaczego. Zgaduję, że UML jest użyteczny tylko w przypadku sformalizowanego podwykonawstwa i jest użyteczny tylko wtedy, gdy jakaś część opracowanego oprogramowania jest ukryta, jak w projektach zastrzeżonych. Jeśli to prawda, UML byłby niezgodny z tworzeniem wolnego oprogramowania.}

^{NB: Sam nie jestem fanem UML. Nie definiuję UML jedynie jako dokumentacji papierowej, ale także jako format [meta] danych dla narzędzi programowych}

Istnieją różne sposoby korzystania z UML. Martin Fowler wywołuje te tryby UML i identyfikuje cztery: UML jako Notatki , UML jako Szkic , UML jako Projekt i UML jako Język Programowania .

UML jako język programowania nigdy tak naprawdę nie wystartował. W tej dziedzinie pracowano pod różnymi nazwami, np. Architektura oparta na modelu lub Inżynieria oprogramowania oparta na modelu. W tym podejściu tworzysz bardzo szczegółowe modele swojego oprogramowania i generujesz kod na podstawie tych modeli. Mogą być przypadki użycia, w których takie podejście jest przydatne, ale nie w przypadku ogólnego oprogramowania, a zwłaszcza poza dużymi firmami, które mogą sobie pozwolić na narzędzia napędzające to podejście. Jest to również czasochłonny proces - mogę wpisać kod dla klasy szybciej niż mogę stworzyć wszystkie modele graficzne niezbędne do jego wdrożenia.

UML jako plan często wskazuje na projekt „dużego projektu z góry” . Oczywiście nie musi tak być. Model można również w pełni opisać dla konkretnego przyrostu. Ale chodzi o to, że poświęca się czas na tworzenie projektu w postaci modeli UML, które są następnie przekazywane komuś do konwersji na kod. Wszystkie szczegóły są określone, a konwersja na kod jest bardziej mechaniczna.

UML jako Szkic i UML jako Notatki mają podobny charakter, ale różnią się w zależności od tego, kiedy są używane. Użycie UML jako Szkicu oznacza, że ​​będziesz szkicował projekty za pomocą notacji UML, ale diagramy prawdopodobnie nie będą kompletne, ale skupią się na określonych aspektach projektu, które musisz komunikować się z innymi. UML as Notes jest podobny, ale modele są tworzone po kodzie, aby pomóc w zrozumieniu podstawy kodu.

Rozważając to, uważam, że wszystko powyżej jest prawdziwe dla każdego rodzaju notacji modelowania. Można go zastosować do diagramów relacji między bytami, diagramów IDEF , notacji modelowania procesów biznesowych i tak dalej. Bez względu na notację modelowania, możesz wybrać, kiedy ją zastosujesz (wcześniej jako specyfikację, później jako alternatywną reprezentację) i ile szczegółów (pełne szczegóły w kluczowych aspektach).

Drugą stroną tego jest kultura open source.

Często projekty typu open source zaczynają od rozwiązania problemu, z którym boryka się osoba (lub dziś firma). Jeśli jest uruchamiany przez osobę, liczba programistów wynosi 1. W tym przypadku narzut komunikacji jest bardzo niski i nie ma potrzeby komunikowania się na temat wymagań i projektu. W firmie prawdopodobnie będzie mały zespół. W takim przypadku prawdopodobnie będziesz musiał komunikować możliwości projektowania i omawiać kompromisy. Jednak po podjęciu decyzji projektowych należy zachować modele wraz ze zmianą bazy kodu lub je wyrzucić. W Agile Modeling kategoriach, „dokument ciągły” i utrzymanie „jednego źródła informacji” .

Krótko mówiąc, istnieje idea, że ​​kod jest projektem, a modele to tylko alternatywne widoki projektu. Jack Reeves napisał trzy eseje na kodzie jak projektowanie , a tam są dyskusje na wiki C2, jak również, omawiając pomysły, które jest kod źródłowy jest projektowanie , konstrukcja jest kod źródłowy i kod źródłowy i modelowanie . Jeśli zgadzasz się z tym przekonaniem (co ja robię), kod źródłowy jest rzeczywistością, a wszelkie diagramy powinny istnieć, aby zrozumieć kod i, co ważniejsze, uzasadnienie, dlaczego kod jest tym, czym jest.

Udany projekt open source, jak te, o których wspominasz, ma współpracowników na całym świecie. Ci współautorzy są zwykle technicznie kompetentni w zakresie technologii, które zasilają oprogramowanie i prawdopodobnie są również użytkownikami oprogramowania. Współautorzy to ludzie, którzy potrafią czytać kod źródłowy równie łatwo jak modele i mogą używać narzędzi (IDE i narzędzi inżynierii odwrotnej) do zrozumienia kodu (w tym generowania modeli, jeśli czują taką potrzebę). Mogą również samodzielnie tworzyć szkice przepływu.

Z czterech trybów, które opisuje Fowler, nie sądzę, że znajdziesz projekt open source lub bardzo wiele projektów w dowolnym miejscu, które używają języków modelowania jako języków programowania lub planów. To pozostawia notatki i szkicuje możliwe zastosowania UML. Notatki zostałyby utworzone przez autora dla autora, więc prawdopodobnie nie można ich nigdzie załadować. Szkice tracą na wartości, ponieważ kod staje się bardziej kompletny i prawdopodobnie nie zostałby zachowany, ponieważ wymagałoby to tylko wysiłku ze strony autorów.

Wiele projektów typu open source nie ma udostępnionych modeli, ponieważ nie stanowi to wartości dodanej. Nie oznacza to jednak, że modele nie zostały utworzone przez kogoś na początku projektu lub że osoby nie stworzyły własnych modeli systemu. Po prostu więcej czasu zajmuje utrzymanie jednego źródła informacji projektowych: kodu źródłowego.

Jeśli chcesz znaleźć osoby wymieniające się informacjami o projekcie, polecam przejrzenie wszelkiego rodzaju forów lub list mailingowych używanych przez autorów. Często fora i listy mailingowe służą jako dokumentacja projektowa projektów. Możesz nie znaleźć formalnego UML, ale możesz tam znaleźć graficzną reprezentację informacji projektowych i modeli. Możesz również wpaść do czatów lub innych kanałów komunikacji dla projektu - jeśli zobaczysz ludzi rozmawiających o decyzjach projektowych, mogą komunikować się z modelami graficznymi. Ale najprawdopodobniej nie staną się częścią repozytorium, ponieważ nie są cenne, gdy osiągną swój cel w komunikacji.

Użyjmy Linuksa jako przykładu,

• To nie jest projekt zorientowany obiektowo, niektóre części, takie jak VFS, mogą być modelowane w UML, ale inne nie mogą być lub nie bardzo skuteczne, tj. Po prostu proste tłumaczenie z structdiagramu klasowego bez relacji.
• UML jest dobry do dokumentacji, aby sprawić, by ktoś nowy w projekcie przyśpieszył. To nie jest coś, co naprawdę zaspokoi Linux, ludzie powinni się tego nauczyć.
• Nie jestem pewien, jakiego narzędzia UML użyć, ludzie muszą się zgodzić na coś, jeśli ma być utrzymane. Była do tego darmowa aplikacja Java, ale nie sądzę, aby wielu chciało z niej korzystać.
• W latach 90-tych GUI wciąż stanowiło wyzwanie dla Linuksa. Wystarczy przejrzeć archiwum listy mailingowej, założę się, że nie znajdziecie żadnej grafiki poza logo dla Linuksa w formacie xpm, która będzie wyświetlana w czasie uruchamiania. Preferowany format to zwykły tekst.
• Nie sądzę, żeby nikt tak naprawdę dbał o design. Ludziom zależy na funkcjach, a jeśli zostaną zaakceptowane, kod zostanie sprawdzony. Przypadki użycia są nadal najlepiej opisywane słowami, podobnie jak pisane są standardy takie jak POSIX i SUS.
• Wiele obiektów w dziedzinie systemów operacyjnych jest dobrze rozumianych i znormalizowanych w społeczności. Np. Ludzie wiedzieliby, jak struct in_addrwygląda pamięć, żadne diagramy nie mogłyby jej wyjaśnić.
• UML niewiele pomaga w algorytmach modelowania, takich jak alokator pamięci, harmonogram, programy obsługi przerwań itp. Źródło jest prawdopodobnie łatwiejsze do zrozumienia.

To są rzeczy, o których mogę myśleć w ustawieniach projektu Linux. Chyba chodzi bardziej o praktyczność. Co ciekawe, nie pamiętam, by Tanenbaum używał UML w swoim podręczniku systemu operacyjnego, opisując Minix.

Prawdopodobnie warto wspomnieć, nie używam też UML w pracy. Prawdopodobnie 20% osób, z którymi współpracuję, zna pewien podzbiór UML.

UML jest reprezentacją, więc jest formą języka i dla argumentu załóżmy, że jego celem jest przekazanie modelu mentalnego między osobami.

To, czego szukam w języku, to jego skuteczność w wychwytywaniu zmian w modelu mentalnym. Załóżmy, że po napisaniu opisu własnego modelu należy wprowadzić niewielką zmianę. Jak dużą zmianę należy wprowadzić w reprezentacji? W języku tekstowym sposób pomiaru polega na uruchomieniu diffmiędzy kodem przed i po oraz zliczeniu różnic. W języku graficznym powinien istnieć podobny sposób pomiaru różnicy.

IMHO nazywam język „specyficzny dla domeny” (DSL) w takim stopniu, w jakim minimalizuje powyższą miarę, co ma oczywiste korzyści w zmniejszeniu kosztów utrzymania i błędów. Jak zrobić DSL? Istnieje kilka sposobów. Jednym z najprostszych jest po prostu zdefiniowanie struktur danych i metod w istniejącym języku programowania. To dodaje rzeczowniki i czasowniki do podstawowego języka, ułatwiając powiedzenie, czego się chce. (Uwaga: nie szukam DSL bez krzywej uczenia się. Być może czytelnik DSL musi zainwestować jednorazowy koszt nauki.)

Ważna kwestia: we wszystkich przypadkach DSL musi zawierać warunki, które sprawiają, że wyrażanie własnego modelu i zmiany w modelu są wygodne. Ponieważ nie ma wyraźnego ograniczenia zakresu możliwych domen, żaden pojedynczy DSL nie może obsłużyć wszystkich.

Mam wrażenie, że UML właśnie tego próbował.