Wprowadzenie
“The Unified Modeling Language User Guide” autorstwa Grady’ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że “możesz wykonać 80% modelowania za pomocą 20% UML” gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią”.
Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu analizy i modelowania jako dyscypliny, oraz dość powszechne niezrozumienie istoty ten notacji. Na to nakłada się ogromna różnica między tym co nazywamy analizą i projektowaniem obiektowym (OOAD) a obiektowo-zorientowanymi językami programowania (OOP).
Notacja UML jest przez wielu ludzi błędnie traktowana jako kolejny zestaw symboli do tworzenia ilustracji. Większość znanych mi deweloperów uważa, że te diagramy im w niczym nie pomagają i generalnie mają racje, gdyż jakość i treść znacznej części dokumentacji powstającej z użyciem UML, jest niska, i dokumentacja taka faktycznie jest nieprzydatna dla dostawcy oprogramowania.
Dlaczego tak jest? Moim zdaniem jest to niezrozumienie tego czym jest oprogramowanie, szczególnie gdy mówimy o oprogramowaniu wspierającym tak zwany biznes, czyli szeroko pojmowane zarządzanie informacją. Na to nakłada się niezrozumienie różnicy między ontologią systemu a samym systemem, oraz tego czym tak na prawdę jest jego mechanizmem działania.
Notacja UML, podobnie jak i inne, to metoda komunikowania wiedzy, jednak komunikacja ta jest skuteczna pod warunkiem poprawnego stosowania notacji. Wspólne stosowanie notacji to standaryzacja komunikacji:
Standaryzacja jest dobrą praktyką we wszystkim, co robimy w życiu. Oznacza to zatem, że korzystanie ze standardowych diagramów UML pomoże usprawnić tworzenie oprogramowania ze względu na łatwe zrozumienie między programistami. Ponadto, zrozumienie abstrakcyjnego charakteru logiki programu jest niezbędne przy rysowaniu diagramów UML. Co więcej, konieczne jest szkolenie programistów, którzy nie są zaznajomieni z korzystaniem z narzędzi projektowych wspomaganych przez UML. Można z łatwością stwierdzić, że dobre diagramy UML pomagają w dobrym rozwoju oprogramowania i można to osiągnąć, jeśli modelowanie dowolnego systemu przy użyciu projektu UML odbywa się w zrozumiały i przejrzysty sposób, tak aby każdy programista mógł łatwo zrozumieć diagramy UML.
Rola i wpływ UML na projekty są znane od dawna:
Pisałem bardzo dużo o modelowaniu i zarządzaniu informacją, tu opiszę podstawowe pojęcia dotyczące modelowania i kluczowe diagramy UML od strony ich klasyfikacji i zastosowania.
Taksonomia diagramów UML
Pojęcie “diagram w UML” oznacza określony typ schematu blokowego. Taksonomię tych diagramów (klasyfikacja rodzajowa) pokazano poniżej:
Klasyfikacja rodzajowa to powyższy podział: diagramy dzielimy na te, które opisują struktury i te które opisujące zachowania. W UML jest jednak także wyróżniona klasyfikacja ze względu na zastosowanie w modelowaniu, która ma trzy główne obszary semantyczne.
Diagramy
Diagram w notacji UML to obszar zawierający (grupujący) elementy (ikony) notacji oraz ich związki. Jest obramowany i zawiera fiszkę z nagłówkiem, ta zawiera symbol typu diagramu i jego tytuł. Pojęcie diagram w UML jest ściśle powiązane z pojęciem model (repozytorium). Notacja wprowadza różne typy diagramów UML. Model UML składa się z elementów takich jak pakiety, klasy i asocjacje. Odpowiadające im diagramy UML to graficzne reprezentacje części modelu UML, diagram – jako element grupujący – jest typem pakietu.
Diagramy w UML zostały pogrupowane na trzy obszary semantyczne:
- struktury: mamy tu takie pojęcia jak wartości, klasy i pakiety
- zachowania: mamy takie pojęcia jak maszyny stanowe, aktywności, interakcje, zadania (akcje),
- diagramy pomocnicze: mamy tu takie pojęcia jak przypadki użycia, wdrożenie (rozlokowanie), przepływ informacji.
Modele systemów służą do wyrażenia tego jak system ma sie zachowywać (mechanizm) w odpowiedzi na określone bodźce. Podstawowe obszary modelowania systemów to: wymagania, struktura (architektura) systemu, oraz zachowania systemu (to jak on i jego elementy, reaguje na bodźce). Wyodrębnione diagramy pomocnicze w UML można uznać za metody wyrażania wymagań.
Szczególnym i bardzo ważnym diagramem jest – pomocniczy – diagram przypadków użycia, który grupuje wymagania funkcjonalne przyporządkowując je do modeli zachowania systemu, oraz organizuje pozostałe modele: każdy przypadek użycia to scenariusze opisujące interakcje i zachowania elementów architektury systemu. Całość można zobrazować jak poniżej:
Diagramy wdrożenia (rozlokowania) i przepływu informacji można potraktować jako model wymagań pozafunkcjonalnych.
Należy tu podkreślić, że słowo wymagania oznacza oczekiwania wobec systemu, cele interesariuszy to ich potrzeby mapowane na model systemu.
Np. potrzebą interesariusza może być możliwość sprawdzenia adresu kontrahenta, jej zaspokojeniem może być dostęp do historii faktur, gdyż na fakturach są adresy kontrahentów. Wymaganiem wobec systemu jest istnienie tego adresy na fakturach (tego akurat wymaga także prawo, więc jest to także wymaganie prawne). Wymaganie to dokumentujemy tworząc strukturalny model faktury (diagram struktur złożonych).
Elementy modeli
Podstawowym pojęciem w UML jest element (element modelu) oraz jego specyficzne typy: związek, związek skierowany oraz komentarz. Elementy mogą zawierać siebie nawzajem, co do zasady komentarz jest zawarty w elemencie komentowanym (jest jego częścią, rozdz.7, Figure 7.1 Root). [w nawiasach podano numery odpowiednich rozdziałów w specyfikacji UML, 2.5.1. z 5 maja 2017 roku), co obrazuje poniższy diagram:
Specjalnym typem klasy jest wartość (Value, rozdz. 8). Jest to klasa, której obiekty nie mają tożsamości (odpowiednik value object we wzorcu DDD).
Klasa to podstawowy element modelowania w UML. Służy do modelowania struktur pojęciowych (namespace) lub struktur opisujacych architektury systemów na różnych poziomach abstrakcji. Klasa to nazwany element modelu, klasyfikator to definicja obiektów danej klasy (tak zwana definicja realna) czyli cechy obiektów tej klasy: atrybuty i operacje (rozdz. 9).
Klasyfikator może być prosty (rozdz. 10). Proste klasyfikatory standardowo są używane do definiowania strukturalnych typów danych. Klasyfikator złożony zawiera drzewiasta strukturę zagnieżdżenia. Jeżeli klasa reprezentuje złożony wewnętrznie element architektury systemu, można na diagramach użyć jej uproszczonej formy jakim jest komponent (rozdz. 11).
Pakiet to element grupujący. Jego cechą jest to, że nie ma on instancji. Pakiet służy do organizowania elementów modelu. Specjalnym typem pakietu jest Model. Jest to pakiet grupujący wszystkie elementy modelu określonego systemu, jego perspektywy lub poziomu abstrakcji (rozdz.12).
Zachowania to opis tego jak zachowują się i współpracują ze sobą elementy struktury systemu, jego komponenty. Zachowanie określonego elementu systemu to jego reakcja na bodźce: operacje. Operacja to sposób jej wywołanie (nazwa bodźca), mechanizm tworzący odpowiedź to metoda operacji (procedura, algorytm) (rozdz. 13).
Zachowania elementu mogą zależeć od jego aktualnego stanu i mogą także powodować zmiany tego stanu. Nośnikiem wartości stanu są określone atrybuty (rozdz. 14). Operacje i ich łańcuchy można modelować na wyższym poziomie abstrakcji jako aktywności (rozdz. 15). Na poziomie metod są to procedury i algorytmy złożone z elementarnych kroków (rozdz. 16). Diagramy aktywności mogą posłużyć także do modelowania przepływu danych (obiektów niosących treść).
Scenariusze opisujące współdziałanie elementów systemu (wzajemne wywołania operacji przez obiekty, protokół komunikacyjny) modelowane są jako interakcje. Interakcje najczęściej modelujemy z użyciem diagramu sekwencji, rzadziej z użyciem diagramu komunikacji (rozdz. 17).
Kluczową różnicą miedzy aktywnością a interakcją, jest to, że aktywności reprezentują odpowiedzialność klas i komponentów, a interakcje reprezentują wywołania operacji i ich parametry.
W celu pokazania systemu z perspektywy interesariuszy i bezpośredniego otoczenia tego systemu, stosujemy pomocniczy diagram, jakim jest diagram przypadków użycia. Celem tworzenia tego diagramu jest zobrazowanie zakresu (granicy) systemu, jego interesariuszy (aktor), oraz tego do czego system służy (przypadek użycia). Diagram ten służy do udokumentowania tego CO system robi, a nie JAK to robi (rozdz. 18). To jak system to robi opisujemy z pomocą innych modeli (sekwencji, aktywności).
Techniczne środowisko systemu opisujemy jako jego obecne, lub planowane, rozlokowanie: sprzęt, systemu operacyjne, środowiska wykonawcze, frameworki, komponenty aplikacyjne (rozdział 19). Aby pokazać przepływy danych na tym poziomie można dodatkowo użyć modeli przepływu informacji (rozdzał 20).
Modele
Podręcznikowa struktura modeli opisujących system to struktura, której korzeniem są oferowane interesariuszom usługi systemu: przypadki użycia. Diagram przypadków użycia to model systemu wyrażony jako “czarna skrzynka” .
Architekturę HLD (High Level Design) całego systemu modelujemy diagramem komponentów. Wewnętrzną architekturę komponentów (model struktury LLD) realizujących usługi aplikacji (przypadki użycia) modelujemy z użyciem diagramów klas (tu wyrażają one architekturę a nie pojęcia).
Współdziałanie komponentów systemu modelujemy diagramami interakcji. Metody i scenariusze ich wywoływania modelujemy (jeżeli jest taka potrzeba) z użyciem diagramów aktywności. Automatyczne zmiany wartości wybranych atrybutów modelujemy z użyciem maszyn stanowych. W uproszczeniu strukturę tych modeli można zobrazować tak:
Powyższy schemat pomija bardzo ważny element jakim jest przestrzeń pojęciowa. To co nazywamy modelem dziedziny, to model pojęciowy: diagram klas, na którym klasy reprezentują pojęcia z języka naturalnego a asocjacje związki między nimi. Nie są to elementy architektury systemu. Mylenie tych rzeczy: nazwy i elementy systemu, to powszechnie popełniany błąd. Prawdopodobnie jest to skutkiem naleciałości z modeli ERD opisujacych relacyjne modele danych. Jednak należy pamiętać, że model danych nie jest modelem systemu, i budowanie diagramów klas w celu modelowania danych jest poważnym błędem .
Spójny proces analizy i projektowania opisali Doug Rosenberg i Matt Stephens . Wskazali które diagramy UML, kiedy i do czego należ użyć:
Tu jawnie wskazano, że konieczny jest model pojęciowy (Domain Model), który dopiero zostanie wykorzystany do budowy architektury kodu obiektowego (Class Model).
Związki między elementami diagramów dzielimy na dwa rodzaje: związki pojęciowe i związki architektoniczne (rozdz.9). Asocjacje i generalizacje to związki pojęciowe (modele pojęciowe, ‘domain model’). Związkami strukturalnymi na modelach architektury systemu, są: zależność, jej szczególny typ: związek użycia, oraz realizacja.
Z uwagi na to, że diagramy komponentów i struktur złożonych pozwalają na bardziej intuicyjne umieszczanie elementów niektórych modeli wewnątrz siebie, stosowanie związków kompozycji i asocjacji na modelach architektury (struktur) powoli traci zastosowanie. Poniższy przykład (rozdz.11.) pokazuje dwa sposoby pokazanie tej samej treści na modelach struktury systemów:
Struktura (i) po lewej powstała z użyciem klas i związków asocjacyjnych, w tym kompozycji (diagram klas). Po prawej (ii) mamy to samo, ale wyrażone z użyciem diagramu struktur złożonych.
Podsumowanie
Celem tego artykułu jest pokazanie UML z perspektywy typów diagramów. Jednak specyfikacja UML to opis języka, a nie podręcznik analizy i modelowania OOAD. Dlatego ważne jest nie tylko poznanie notacji UML, ale także studiowanie paradygmatów, wzorców architektonicznych i dobrych praktyk modelowania systemów.
Nie przytaczałem w tym tekście przykładów diagramów, jest wiele publikacji na ten temat (w tym moja ). Nie opisałem tu wszystkich czternastu typów diagramów, gdyż skupiłem się na tych, które są wykorzystywane w codziennej praktyce projektowania. Powyższe to niecałe 10% całej notacji UML, wykorzystywane w 99% projektów z użyciem tej notacji (moim zdaniem). Ich stosowanie opisałem w artykule na temat ICONIX.
Gorąco odradzam książki i materiały, napisane przed 2015 roku (rok publikacji UML v.2.5), moim zdaniem w większości (poza niektórymi pracami ogólnymi) przynoszą one wiele szkód i powodują ogrom nieporozumień.
Na koniec: po co nam te modele i dokumenty:
Udokumentowanie problemu, dostępnych rozwiązań i planu dostarczenia wartości pozwala wszystkim osiągnąć sukces. Przynajmniej w ten sposób staje się jasne, jaki problem ty i twój zespół próbujecie rozwiązać i jakie rozwiązania są dostępne – i które z nich wybrałeś – sprawia, że jest jasne dla każdego, kto to czyta (zespół, interesariusze, zarząd, klient), w jaki sposób zamierzasz dostarczyć wartość. Jeśli nie możesz tego zapisać i uzyskać zgody interesariuszy, i tak musisz wykonać tę pracę: po prostu zanurkujesz w kodowanie mając nadzieję, że wszystko się ułoży. Jednak nadzieja nie jest dobrą strategią.
Z perspektywy projektów realizowanych w zgodzie z MBSE, projektowanie oprogramowania (aplikacji) zorientowane na przypadki użycia, realizowane jako mikro-usługi (mikroserwisy), a te jako mające komponentową architekture elementy systemu, można przedstawić jak poniżej:
Poster: struktura opisu technicznego kodu aplikacji:
Polecam także ciekawy referat o modelowaniu i diagramach:
?The Unified Modeling Language User Guide by Grady Booch, James Rumbaugh, and Ivar Jacobson (Addison-Wesley, 1998) tells us that ?you can do 80% of your modeling with 20% of the UML? somewhere after page 400. They would have saved the industry many millions (billions?) of dollars and horrific cases of analysis paralysis [?] if they had said that in the Introduction, but they didn?t. To compound the felony, they never tell us which 20% of UML is the useful part.?
Doug Rosenberg and Matt Stephens
Zgadzam się. Ale na szczęście, ktoś od razu napisał książkę o ICONIX. Szkoda, że mało popularna.
Rosenberg, D., & Scott, K. (1999). Use case driven object modeling with UML. Springer.
Rosenberg, D., & Stephens, M. (2007). Introduction to ICONIX Process. Use Case Driven Object Modeling with UML: Theory and Practice, 1?20.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile development with ICONIX process: People, process, and pragmatism. Apress.
Rosenberger, P., Gerhard, D., & Dumss, S. (2019). Modelling the Behaviour of Context-aware Systems: State-of-the-Art Analysis and Introduction of a Customized UML Profile. MODELSWARD, 519?526.
Polecam także to:
Ivar Jacobson, Ian Spence, & Kurt Bittner. (2014, July 21). Use-Case 2.0 ebook. Ivar Jacobson International. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
Kurt Bittner. (2011). Use-Case 2.0: Scaling up, scaling out, scaling in for agile projects. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
c.d.
Dodam, że i specyfikacja UML i ww. podręcznik jej użycia to nie są podręczniki analizy i projektowania a opis języka.
Booch, G., Jacobson, I., & Rumbaugh, J. (1996). The unified modeling language. Unix Review, 14(13), 5.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language user guide. Addison-Wesley.
Booch, G., Rumbaugh, J., & Jacobson, I. (2002). UML przewodnik użytkownika (drugie wydanie). WNT.
Dlatego bardzo dobrze, że wiele lat temu Doug Rosenberg i Matt Stephens uzupełnili tę lukę. Pozostaje się zastanowić, dlaczego tak mało ludzi z ich dorobku korzysta (ja robię to niemalże od początku pojawienia sie tego: Rosenberg, D., & Scott, K. (1999). Use case driven object modeling with UML. Springer.)
“They would have saved the industry many millions (billions?) of dollars”
Robię to dla moich klientów od samego początku moje samodzielnej działalności eksperckiej, czyli od ok. 2004 roku, studentów uczę tego od 2005 roku.
Uzupełniłem artykuł o diagramy używane w procesie ICONIX i literaturę źródłową z tym związaną.
Zgadzam się z myślą, że UML to tylko język, a jego specyfikacja to nie podręcznik analizy.
Rodzi się jednak pytanie, czy UML jest wygodną notacją do modelowania zagadnień JEDNOCZEŚNIE z zakresu analizy biznesowej i systemowej, a jeśli tak, to do jak uprawianej analizy, bo szkół jej rozumienia i praktykowania jest kilka.
Kiedyś byłem programistą i wtedy też byłem entuzjastą UML, ale krótko. Szybko zrozumiałem, że choć wymyślony przez programistów i dla programistów, nie jest zbyt przydatny.
Potem zostałem analitykiem i architektem. Próbowałem komunikować się nim (tzn. modelami w UML) z biznesem i programistami. Niestety. Zarówno przez biznes jak i przez programistów był odrzucany. Dla biznesu modele były zbyt skomplikowane, dla programistów zbyt uproszczone. No i zostałem z tym UMLem jak Himilsbach z angielskim.
A może z moimi modelami było coś nie tak? Mnie się podobały, bo przecież moje modele były “mojsze” od innych.
I na tym polega problem. W wielu przypadkach model a la “obrazek” niesie tylko część informacji. Reszta znajduje się w głowie jego autora i bez zestawu “obrazek+autor” nie da się go pojąć. Czytelnik zawsze musi się zastanawiać “co poeta chciał w wierszu powiedzieć?”. Przy próbie jego doprecyzowania jednak gwałtownie rośnie stopień komplikacji modelu: coraz więcej diagramów, coraz więcej na nich “pudełek”. I tak źle, i tak niedobrze.
Zatem powróćmy do fundamentalnego pytania: czy w UML da się opowiadać “historie” zrozumiałe zarówno dla biznesu, jak i programistów? To, że są one zawsze zrozumiałe dla autora-analityka to oczywiste. Tylko czy aby o to chodzi w analizie?
“Rodzi się jednak pytanie, czy UML jest wygodną notacją do modelowania zagadnień JEDNOCZEŚNIE z zakresu analizy biznesowej i systemowej, a jeśli tak, to do jak uprawianej analizy, bo szkół jej rozumienia i praktykowania jest kilka.”
1. jest tylko jedna szkoła: oryginalna specyfikacja. UML to notacja do modelowania systemów, oprogramowanie jest jednym z typów systemów, coraz częściej jest częścią czegoś większego (samochodu, samolotu, pralki). To co nazywamy analizą biznesową wymaga innych narzędzi (BPMN, reguły biznesowe, szablony opisujące dokumenty biznesowe i ich treść)
“Kiedyś byłem programistą i wtedy też byłem entuzjastą UML, ale krótko. Szybko zrozumiałem, że choć wymyślony przez programistów i dla programistów, nie jest zbyt przydatny.”
2. jeżeli jakiś model UML nie jest przydatny, to znaczy, że jest niepotrzebnie albo źle wykonany.
“Potem zostałem analitykiem i architektem. Próbowałem komunikować się nim (tzn. modelami w UML) z biznesem i programistami. Niestety. Zarówno przez biznes jak i przez programistów był odrzucany. Dla biznesu modele były zbyt skomplikowane, dla programistów zbyt uproszczone. No i zostałem z tym UMLem jak Himilsbach z angielskim.”
3. to znaczy tylko tyle, że te modele były złe
“A może z moimi modelami było coś nie tak? Mnie się podobały, bo przecież moje modele były ?mojsze? od innych.”
4. były złe z powodów jak wyżej
“I na tym polega problem. W wielu przypadkach model a la ?obrazek? niesie tylko część informacji. Reszta znajduje się w głowie jego autora i bez zestawu ?obrazek+autor? nie da się go pojąć. Czytelnik zawsze musi się zastanawiać ?co poeta chciał w wierszu powiedzieć??. Przy próbie jego doprecyzowania jednak gwałtownie rośnie stopień komplikacji modelu: coraz więcej diagramów, coraz więcej na nich ?pudełek?. I tak źle, i tak niedobrze.”
5. znowu jest to przykład złych modeli
“Zatem powróćmy do fundamentalnego pytania: czy w UML da się opowiadać ?historie? zrozumiałe zarówno dla biznesu, jak i programistów? To, że są one zawsze zrozumiałe dla autora-analityka to oczywiste. Tylko czy aby o to chodzi w analizie?”
6. Da się, świat robi to od 20 lat. Dobry model to model zrozumiały dla adresata, inne są złe. Pozostaje poprawnie określić adresata (podobnie jak Himilsbach, po angielsku mówimy do Brytyjczyków a nie do Polaków), ale adresat tez musi wykazać pewne minimum kompetencji: np. robotnik na budowie musi umieć czytać rysunki techniczne, podobnie jak tokarz czy stolarz, rzecz w tym by projktant też robił je poprawnie.
Podsumuję:
Największym problemem z UML jest to, że problemem nie jest UML a brak umiejętności abstrakcyjnego modelowania z użyciem tej notacji: dokumentowania wyników analizy lub projektu. UML to to samo co rysunki techniczne w każdej innej inżynierii. Jak ktoś nie potrafi narywać schematu koparki, roweru, samolotu czy szafy, systemu w UML też nie udokumentuje. Używanie UML na etapie analizy biznesowej jest nieporozumieniem, ta notacja nie do tego powstała (choć jej elementy są potrzebne na tym etapie do modelowania struktur informacyjnych dokumentów).
Na tym blogu jest wiele przykładów praktycznego użycia UML. W 100% są to zanonimizowane przykłady realnych projektów, które były zrozumiałe w 100% przez bines i programistów. Wszystkie miały jedną wspólną cechę: nie były zbyt skomplikowanie a dzięki tym schematom blokowym dokumentacja miały raczej sto stron a nie tysiąc. Drugą cechą było to, że tam gdzie było to drugie podejście po poprzednim nieudanym, dzięki tej dokumentacji i etapom analiz, realizowałem te projekty nawet 10 krotnie taniej niż poprzednicy, głównym powodem było to, że wszelkie problemy z niejasnością logiki biznesowej i logiki działania systemu były rozstrzygane w ciągu pojedynczych godzin na schematach UML, a nie ciężką wielodniową pracą koderów na prototypach kodu i jego testowaniu.
Tu kilka przykładów:
https://online.visual-paradigm.com/community/bookshelf/default-10o6bovwlu
c.d.
Przytoczony na początku cytat autorstwa Doug Rosenberg, Matt Stephens, to odpowiedź na wszelkie pytania jakie padły z Pana ust: rzecz w tym używać właściwych diagramów, we właściwym czasie i we właściwy sposób. Śledzę ich publikacje, także te naukowe na ten temat (szczególnie Douga Rosenberg’a), i jedno jest pewne: UML jest OK, do tego stopnia, że jako profil SysML jest używany do projektowania złożonych urządzeń w przemyśle. I ostatnie lata pokazały, że od kilku lat zainteresowanie UML/SysML rośnie a nie maleje.
Cały powyższy wywód jest generalnie ok, pod jednym wszakże warunkiem, że uznamy za uprawnione porównanie modelu w UML do rysunku technicznego (na papierze lub w CADzie), gdy każdy “robotnik na budowie […], tokarz czy stolarz […]” itd.
Problem w tym, że rysunek techniczny zawsze jest rysunkiem rzeczy realnej, materialnej, i nie pozostawia swobody interpretacyjnej. Jeśli rysunek jest zły, powstaje zły przedmiot (albo wcale nie powstaje).
Model systemu (w UML lub w jakiejkolwiek innej notacji) natomiast jest modelem do pewnego stopnia abstrakcyjnym i często na bazie złych modeli powstają dobre systemy (lub odwrotnie) gdyż od wrodzonych lub nabytych zdolności autora jak i odbiorcy/wykonawcy zależy końcowy rezultat.
Poza tym ostatnie lata też pokazały, że rośnie zainteresowanie innymi notacjami, a nawet innymi podejściami przy analizowaniu wymagań i projektowaniu systemów. Oczywiście stary dobry UML zawsze będzie w obiegu, niczym łacina. W pewnych kręgach nie wypada jej nie znać.
“Cały powyższy wywód jest generalnie ok, pod jednym wszakże warunkiem, że uznamy za uprawnione porównanie modelu w UML do rysunku technicznego (na papierze lub w CADzie),”
Tak jest traktowany od 20 lat w Siemens czy Boeingu. Dzisiejsze trendy: https://youtu.be/aHr5wVRXvMc
“Poza tym ostatnie lata też pokazały, że rośnie zainteresowanie innymi notacjami, a nawet innymi podejściami przy analizowaniu wymagań i projektowaniu systemów. ”
Jakimi? Bo np. autor dość znanej już C4 zaleca bazowanie na UML.
Więcej u UML w przemyśle:
https://it-consulting.pl/2020/05/25/sysml-co-warto-przeczytac-i-miec-na-polce/
Dodałem ciekawy referat jako uzupełnienie.