O pożytkach i nieużytkach UML-a

2008-01-26 17:45

Stare chińskie przysłowie mówi, że klient zazwyczaj nie wie dokładnie, czego tak naprawdę chce. (Inne przysłowie mówi też, że jeśli nie znamy pochodzenia danej sentencji, to najlepiej powiedzieć, że jest to stare chińskie przysłowie). Dlatego też często nie potrafi swoich potrzeb przełożyć na opis wymagań co do oprogramowania. Jest to jeden z problemów, przy rozwiązywaniu których ma pomagać Unified Modelling Language, czyli UML. W założeniu jest to notacja, umożliwiająca rozpisanie całego procesu tworzenia aplikacji na szereg różnego rodzaju diagramów, na których znaczenie poszczególnych symboli jest ściśle określone – na pewno ściślej niż języka naturalnego. Założenie jest szczytne i bardzo ambitne, a z praktyką jest jak zwykle nieco gorzej :)

Symbol notacji UMLNiewykluczone, że jedną z idei przyświecających twórcom UML-a było przynajmniej częściowe zasypanie tej przepaści między dwoma etapami tworzenia: kiedy wiemy, co mamy zrobić, ale jeszcze nie mamy wielkiego pojęcia o tym, jak to zrobić. Przeskoczenie dystansu pomiędzy tymi punktami jest bowiem często kwestią odpowiedniego pomysłu, który najlepiej realizuje całą koncepcję systemu. Jak zaś wiadomo, pomysły biorą się głównie z niezbadanych obszarów pewnego organu znajdującego się między uszami i ich jakość zależy głównie od tego, do kogo ów organ należy. UML stara się więc usystematyzować programistyczną kreatywność, aby zaprojektowanie dobrze działającego systemu nie było tylko wypadkową wymysłów kłębiących się pod czaszką analityka.
Trzeba przyznać, że wychodzi mu to dość średnio. Różne rodzaje diagramów, jakie mamy do dyspozycji, nie bardzo pomagają w płynnym przechodzeniu od wymagań funkcjonalnych do projektu, który te wymagania ma spełniać. Mam raczej wrażenie, że ich celem jest głównie spoglądanie na aplikację z coraz to nowych punktów widzenia. Patrzymy więc na projekt z perspektywy użytkownika zewnętrznego (diagram przypadków użycia), zmieniających się stanów obiektów (diagramy stanów), przepływu danych i obiektów między “miejscami” w programie (diagramy interakcji), i tak dalej. W sumie widzimy coraz więcej pojęć, związków, relacji i zależności, przez co projekt – zamiast upraszczać się, co z pewnością kieruje nas bliżej implementacji – komplikuje się jeszcze bardziej.

Większość z tych konstrukcji nie jest zresztą widoczna w wynikowym kodzie. Nic więc dziwnego, że spośród całego UML-a zdecydowanie najpopularniejsze i najczęściej stosowane są diagramy klas i diagramy sekwencji (przepływu zdarzeń). Odpowiadają one bowiem niemal bezpośrednio strukturze klas i ich składowych oraz przepływowi sterowania w metodach i funkcjach. W ich przypadku przyznaję, że schemat graficzny jest bardziej przejrzysty niż tekst w języku naturalnym czy kod. Co więcej, używana przy okazji notacja jest też najszerzej znana. Autorzy wielu książek dotyczących języków programowania bardzo często bowiem “przemycają” w nich zwłaszcza diagramy klas, z nieśmiertelną strzałką w górę jako symbolem dziedziczenia.
Jeśli zaś chodzi o resztę diagramów, to ich użyteczność wydaje mi się wątpliwa. Mówiąc wprost, uważam je póki co za zwyczajne zawracanie głowy :)

Tags:
Author: Xion, posted under Computer Science & IT, Thoughts »


5 comments for post “O pożytkach i nieużytkach UML-a”.
  1. SirMike:
    January 26th, 2008 o 20:35

    Myslalem, ze to tylko ja uwazam UML za gowno :D
    Ale widzac po tym watku na forum, nie jestem sam.

  2. moriturius:
    January 27th, 2008 o 8:12

    Ja tylko wstępnie zapoznałem się z UML po czym postanowiłem go olać ^^ IMO trochę strata czasu – tyle samo mozna sobie rozpisać na kartce na 100 różnych sposobów, a więc bez wcześniejszej nauki UML (oczywiście mówię o zespole n programistów gdzie n=1, bo jesli n>=2 to wtedy moze pojawic sie problem ze zrozumieniem tych zapiskow przez reszte zespolu ;) ).

  3. Bedger:
    January 27th, 2008 o 16:43

    Imo UML jest przydatny, szczególnie jeśli przychodzi nam pracować w zespole. Osobiście używam tylko diagramów przypadków użycia, klas i czasami sekwencji, reszty jak dotąd nie używałem i raczej się nie zapowiada abym był zmuszony ich używać. Nauka UML’a to góra godzina (nie mówię tu oczywiście o wszystkich diagramach) a czas przeznaczony na naukę powinien zwrócić się już po pierwszym projekcie. Moriturius – można owszem olać UML’a i pisać po swojemu, ale wystarczy kilka projektów aby w UML’u pisać tak samo szybko i przyjemnie jak przy wykorzystywaniu własnych oznaczeń. A nigdy nie wiadomo co przyniesie przyszłość, gdzie się zatrudnimy i jakie będą wymagania pracodawcy ;)

  4. Liosan:
    January 27th, 2008 o 23:27

    A ja używam UMLa na tyle, na ile mam ochotę :) dziedziczenie, agregacja i kompozycja to bardzo przydatne relacje pomiędzy klasami. Diagramy sekwencji są fuj – jeśli mam coś takiego opisać, to robię diagram przepływu (najlepiej w formie animowanej, jeśli mam taką opcję). Oprócz tego diagramy stanów, ale trudno to nazwać UMLem…

    W ogóle (a propos animowanych diagramów przepływu) czy wiadomo wam coś o jakichś… bardziej dynamicznych metodach modelowania? Nikt nie mówi, że trzeba cały proces widzieć na raz na ekranie (zresztą i tak się pewnie nie zmieści), a wersja mrygająca może być dużo bardziej informatywna. Jakieś przemyślenia?

    Liosan

  5. Bober:
    September 3rd, 2008 o 21:08

    Dla mnie UML, w kontakcie z klientem, wydaje się byćniezłym narzędziem. Użycie tej notacji nie ogranicza się do programowania. Osobiście maluję przypadki użycia przy omawianiu funkcjonalności powstającej elektroniki.
    Diagramy klas – miodzio przy programowaniu.
    UML przydaje się również do projektowania systemów bardziej rozproszonych, jak np. systemy nadzoru składające się z dziesiątków elementów połączonych wspólną magistralą, którą muszą się grzecznie dzielić. Wtedy też przypadki użycia wprost idealnie pokrywają się ze zdarzeniami “dobrymi”, “złymi” i “UWAGA” :)
    Co do animacji – może “Synoptyki”?

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.