:sparkles: PWA :sparkles:
Logo

Piotr Kowalski

Organizator WarsawJS , Trener, YouTuber

Po co mi UML?

Wielu z Was - programistów Front-end - na pewno słyszało o UML-u. Część, która miała już tą przyjemność korzystania z możliwości zamodelowania dowolnego scenariusza pewnie ma już wyrobione zdanie na temat tego języka. W tym artykule przedstawię Ci, czym dla mnie jest UML.

Jest to pierwszy post z serii o UML. Mam w planach napisanie kilku artykułów na temat konkretnych diagramów UML, które wykorzystuję w codziennej pracy zawodowej.

Logo UML
Oficjalne logo UML

Co to jest UML?

Drogi czytelniku, jeśli jeszcze nie wiesz co to jest UML, to pozwól, że w telegraficznym skrócie Ci wytłumaczę.

Czy czasami, kiedy masz problem ze zrozumiem czegoś, jakiegoś problemu, czy nie korzystasz wtedy z długopisu i kartki? Jeśli tak to na pewno starasz się narysować na kartce papieru pewne elementy, takie jak np. użytkownik, serwer, przycisk albo okno przeglądarki.

Każdy kto rysuje na kartce papieru tworzy coś na swój sposób. Co jeśli wystąpi konflikt? W mojej głowie użytkownika będzie reprezentował kwadrat, a u Ciebie to będzie okrąg? Co wtedy No właśnie. UML to umowny zapis jak powinno się rysować elementy ze świata inżynierii oprogramowania.

Diagram Klas mojego autorstwa. Temat - Zamek. 2010 rok.

Po co?

  1. Przedstawienie innemu programiście implementacji za pomocą obrazka.

    Ile razy słyszałeś “a weź mi to narysuj”? Jeśli masz komuś coś wytłumaczyć, to bardzo często lepiej jest to po prostu narysować.

    Przedstawienie czegoś na obrazku lepiej obrazuje omawiane zagadnienie. Ilu programistów tyle różnych rysunków. Dlaczego więc nie rysować zgodnie z jakimiś zasadami?

    Diagram Klas mojego autorstwa. Temat - Szkoła. 2012 rok.
  2. Świetne na spotkania z biznesem, aby pokazać jak wygląda implementacja.

    Za poprawną implementację odpowiedzialni są programiści. Tylko oni znają się na programowaniu. Biznes nie rozumie o co chodzi w tych krzaczkach, które wyświetlają się całymi dniami na komputerach developerów.

    Przykład diagramu czynności.

    To, że biznes nie potrafi programować, to nie znaczy, że nie potrafi myśleć. Dlatego też, jeśli chciałbyś - developerze - pokazać np. jak wygląda flow, które zaimplementowałeś to pokaż biznesowi diagram czynności, na którym będzie rozrysowane krok po kroku jak wygląda np. rejestracja użytkownika w projekcie opartym na React-cie :smiley:

    Stoisz na spotkaniu i nikt Cię nie rozumie gdy tłumaczysz implementację?
    NARYSUJ JĄ!
  3. Planowanie implementacji.

    Ważna zasada

    Najważniejszą rzeczą poprzedzającą implementację jest analiza!

    Ile razy drogi programisto gryzłeś się w język, że napisałeś kod bez wcześniejszego namysłu i teraz niestety musisz go się pozbyć, bo ktoś zwrócił Ci uwagę, że brniesz w złą stronę. Najbardziej boli, kiedy to Ty sam zauważasz, że po kilku godzinach zabrnąłeś zupełnie nie tam gdzie powinieneś. No właśnie :exclamation:

    Analiza (z angielskiego “design”) to projektowanie rozwiązania.

    W tym przypadku problemem jest brak etapu projektowania. Wszystkie szkoły wytwórców oprogramowania mówią, że pierwszą fazą (w modelu kaskadowym) jest specyfikacja, czyli określenie wymagań projektu, ale tuż za nim jest faza projektowania systemu na którą powinno poświęcić się do 30-40% całości trwania projektu (źródło 1, źródło 2).

    Poprzez “projekt” mam też na myśli dowolne “zadanie”.

Planowanie, Analiza, Projekt, Implementacja, Testowanie, Pielęgnacja
Prezentacja jak NAJCZĘŚCIEJ przebiega realizacja projektu. Źródło.

Nuda?

Wiele osób może uważać, że tworzenie diagramów to nuda. Dlatego też, nie chce się im ich rysować. Nie rozumiem dlaczego w głowach developerów pojawia się takie myślenie. Jestem w stanie zrozumieć, że Ci młodzi “zapaleńcy”, którzy by tylko klepali w klawiaturę - nie ważne co, ważne że klepią - mogą nie zakochać się w diagramach, bo tutaj nie ma kodowania.

Jednak kiedy młody developer staje się coraz bardziej odpowiedzialny za system, to zastawia się jak tutaj sobie pomóc i nie pisząc kodu, móc określić jego potencjalne działanie.

Architekci, czyli tacy developerzy, którzy na pewnym etapie swojej kariery postanowili zająć się na dobre projektowaniem, wiedzą, że bez odpowiednich modeli (czytaj diagramów) ich praca nie byłaby efektywna. Zaprezentowanie swojego pomysłu dla zespołu projektowego wiąże się z tym, że jeśli zostanie on źle zrozumiany to ponosi za to konsekwencje.

Diagramy to dokumentacja

Pliki z diagramami to typowa, zaraz po słownej, dokumentacja. Wszyscy wiemy, że nieaktualizowana dokumentacja nadaje się tylko do śmietnika. Trzeba aktualizować dokumentację słowną, ale też i rysunkową.

Moja prośba

Mam do Ciebie drogi developerze serdeczną prośbę.
Dbaj o dokumentację. Uratuje Ci ona kiedyś skórę. Mówię Ci ze swojego doświadczenia.

Teza: diagramy są trudne!

W świecie front-endu jest wiele frameworków, narzędzi, systemów. Utarło się, że osoby bez znajomości dowolnego z nich stwierdzają, że jest on “trudny”. Nie mam pojęcia dlaczego pojawia się takie myślenie.

Złota myśl

Wychodzę z założenia, że nie ma rzeczy trudnych, są rzeczy których po prostu jeszcze się nie poznało.

Drogi czytelniku, jeśli nie znasz jeszcze UML to poczytaj o dowolnym diagramie i rysuj go. Naucz się wszystkiego co z nim związane i rysuj tyle tych diagramów ile wlezie. Taką praktyką dojdziesz do momentu, że już nawet nie poczujesz, że musisz narysować diagram. Stanie się to po prostu łatwe i przyjemne. Dlaczego? Bo już poznałeś na wylot zasady jakie w nim panują.

Ze swojej strony proponują naukę dowolnego z poniższych:

  • diagram przypadków użycia
  • diagram związków encji
  • diagram sekwencji
  • diagram czynności

Teza obalona :tada:

Kto go używa?

  1. Programiści back-end

    Ci programiści wykorzystują diagramy do modelowania swoich usług wystawionych w świat.

  2. DevOps-i, czyli administratorzy systemów

    Ci, natomiast mogą prezentować swoją architekturę serwerową, wszelkie sieci szkieletowe i inne.

  3. Programiści front-end

    Ci mają bardzo łatwo, bo liczba procesów które mogą zostać narysowane w diagramach jest przeogromna, zaczynąjąc od komunikacji sieciowej z back-endem, skończywszy na definicji zachowania kontrolek po interakcji użytkownika.

  4. Inni

    Istnieje wiele stanowisk, które również wykorzystują takie diagramy i nie sposób jest ich tutaj wszystkich wymienić.

Kto powinien znać UML?

Każdy developer sieciowy.

Kto jest takim developerem? Każdy kto wytwarza oprogramowanie, do którego dostęp możliwy jest za pomocą sieci, czy to wewnętrznej (intranet) czy to zewnętrznej (internet).

Jak mi “jako programiście” pomagają diagramy?

Z mojego doświadczenie najlepszym diagramem dla programistów front-end jest diagram sekwencji, który obrazuje jak wygląda ich kod w stosunku do innych systemów, np. back-endu lub też inter-obiektowy w aplikacji.

Inter-obiektowy, to taki który określa połączenia między obiektami, klasami w architekturze aplikacji. Np. jak wygląda komunikacja między DataService a modelem UserModel.

Diagram Sekwencji mojego autorstwa. Temat - Przychodnia. 2013 rok.

Jak mi “jako kierownikowi” pomagają diagramy?

  1. Nie muszę patrzeć na implementację aby zweryfikować poprawną architekturę.

    Code Review to świetna sprawa - uwielbiam to robić. Jednak jest pewien case, kiedy robienie CR to droga przez męką. Zastanów się kiedy tak jest?

    W moim przypadku, ciężko mi się przegląda Pull Request, który zawiera ogromną liczbą zmian. Kiedy w PR liczba dodanych linijek przekracza ponad 1000 (1 tysiąc) linijek kodu, to jest kiepsko.

    Gdybym miał diagram opisujący jak wygląda implementacja, to nie musiałbym mocno zwracać uwagę na zmienione linijki, ponieważ niektóre błędy mógłbym z niego wyczytać.

  2. Oszczędność czasu.

    Jako kierownik wieloosobowego zespołu nie mam za dużo czasu, aby weryfikować każdą implementację. Każda godzina jest ważna, dlatego staram się najefektywniej je wykorzystywać. A ślęczenie nad czyimś kodem aby zapoznać się co zrobił developer nie jest mega efektywnym zajęciem.

  3. Prezentacja implementacji mojego zespołu przed biznesem.

    Często jest tak, że biznes wyraża chęć poznania w jaki sposób została zrealizowana dana funkcjonalność. Ma do tego pełne prawo. Posiadając odpowiednie typy diagramów jest w stanie bardzo szybko udzielić odpowiedzi nie produkując się za każdym razem gdy takie pytanie będzie miało miejsce.

Przykład (z życia wzięty)

Jestem przekonany, że gdy tworzysz stronę, czy to budując API RESTowe, czy UI myśli o użytkowniku, który będzie korzystał z tego co zrobisz.

W UML istnieje taki diagram, na którym możesz rysować to co użytkownik może zrobić z Twoim “systemem”1. Taki diagram nazywa się Diagram Przypadków Użycia. Z angielskiego zwany Use Case Diagram.

Diagram Przypadków Użycia mojego autorstwa. Temat - Restauracja. 2011 rok.

Niech przykładem będzie sytuacja z użytkownikiem portalu wideo. Na takim diagramie możemy zapisać, jakie możliwości posiada użytkownik.

Głowa batmana, Wyświtl listę filmów, Dokonaj płatności za film, Odtwórz film
Przykład diagramu przypadków użycia użytkownika w portalu wideo.

  1. Anegdotka. Od kilku dni moja partnerka życiowa zwraca się do mnie “System”, przez wzgląd na to, że ciągle pracuję :smiley: Pisanie artykułów na bloga co drugi dzień oraz nagrywanie i montowania filmów na kanał WarsawJS oraz swój, to dużo pracy. 

Tagi: uml

2 dni wcześniej napisałem: Jak zbudować widget prezentujący testimoniale? 2 dni później napisałem: WarsawJS Meetup #33: Mój punkt widzenia

Możesz osadzić kod wykorzystując: <pre><code class="{language}"></code></pre>