UML i jego uzytecznosc

[SirMike]

Pozwole sobie rozpetac maly flejmik na temat, ktory ostatnio troche mnie nurtuje.
Osobiscie uwazam UML za badziewie, ktore jest zbyt przekombinowane i prawde mowiac przydaje sie z niego maly procent diagramow - wg mnie jest to diagram klas i ew. diagram sekwencji. Jako, ze jestem zwolennikiem metod wytwarzania oprogramowania takich jak Agile czy XP, nie bardzo widze sens nauki zawilosci UML. Doswiadczenie przy duzych projektach aplikacji webowych i desktopowych podpowiada, ze diagramy UML sa niezbyt uzyteczne i mozna je zastapic kazdym innym, dowolnym diagramem lub przekazem slownym.

Niestety brak mi doswiadczenia przy duzym projekcie w gamedev wiec nie bardzo moge wypowiedziec sie w tej kwestii.

Jakie jest Wasze zdanie na ten temat?

[shyha]

W gamedev nie wiem, ale zgodzę się, że tylko te dwa wspomniane przez ciebie typy diagramów mają większy sens. Nie widziałem, żeby ktoś pozaakademicko innych używał. Co do sensu całego UMLa to ma jak najbardziej sens, ale odżegnywałbym się od przypisywania UMLowi jakiejś magicznej mocy samoopisywania i przejrzystości projektów. W większości przypadków nadaje się do
a) zarysowania wstępnego projektu
b) udokumentowania ZAKOŃCZONEGO projektu (z projektami w trakcie prac często i gęsto robi się bagno i i tak koniec końców nikt nic nie wie)

W gamedev widziałbym to podobnie. Szablon zależności elementów gry, zależności klas itp.

[revo]

Kiedyś doszliśmy do momentu w którym szef powiedział, że albo zamykamy projekt, albo robimy refactoring z pomocą kogoś z zewnątrz teamu zanim zaczniemy kontynuować - oczywiście wybraliśmy drugą opcję. Wspólnie wygenerowaliśmy diagram klas w Enterprise Architect z kodu, wydrukowaliśmy go i dość przyjemnie się na to spoglądało (chyba 4 kartki A4). Od razu zauważyliśmy, że część funkcjonalności jest nie tam gdzie trzeba i dużo da się poprawić. Następnie zmiany zrobione flamastrem na diagramie pozwoliły dość szybko uporządkować kod do bardziej życiowej postaci.

Na codzień UMLa nie używam.

[SirMike]

Kiedyś doszliśmy do momentu w którym szef powiedział, że albo zamykamy projekt, albo robimy refactoring z pomocą kogoś z zewnątrz teamu zanim zaczniemy kontynuować - oczywiście wybraliśmy drugą opcję. Wspólnie wygenerowaliśmy diagram klas w Enterprise Architect z kodu, wydrukowaliśmy go i dość przyjemnie się na to spoglądało (chyba 4 kartki A4). Od razu zauważyliśmy, że część funkcjonalności jest nie tam gdzie trzeba i dużo da się poprawić. Następnie zmiany zrobione flamastrem na diagramie pozwoliły dość szybko uporządkować kod do bardziej życiowej postaci.

Tylko to raczej malo ma wspolnego z UML - diagram klas nie koniecznie musi byc czystym UML-em (patrz Class Diagram z Visual Studio).
A co do problemu, ktory opisales - sam w pracy borykam sie z cholernie skomplikowanym projektem, ktory ma ogromna ilosc klas wg wielu paskudnie zaprojektowanych - wydrukowanie calosci (choc to pewnie bedzie duzo wiecej niz 4xA4 ) jest bardzo dobrym pomyslem.

[Riddlemaster]

Jeśli chodzi o projektowanie oprogramowania to wg mnie przydatne są diagramy klas, sekwencji i stanów (choćby do zaprojektowania fsm'u). Choć swego czasu, jeszcze w Afterfallu wykorzystaliśmy tylko 2 wspomniane przez Ciebie. Natomiast w szerszych zastosowaniach informatycznych wykorzystuje się dużo więcej diagramów - należy pamiętać, że UML 2.x jest dość silnie ukierunkowany na organizacje i pozwala choćby na modelowanie ich struktury czy procesów. I biznes z tych możliwości robi użytek (przynajmniej tak twierdzi część znanych mi osób z tym związanych).
SirMike - a w czym niby przeszkadza tu Agile (swoją drogą miło że nie jestem jedyny )? Można sobie w UMLu choćby iteracje dobrze zaplanować i architekturę na początku.

[SirMike]

Natomiast w szerszych zastosowaniach informatycznych wykorzystuje się dużo więcej diagramów - należy pamiętać, że UML 2.x jest dość silnie ukierunkowany na organizacje i pozwala choćby na modelowanie ich struktury czy procesów. I biznes z tych możliwości robi użytek (przynajmniej tak twierdzi część znanych mi osób z tym związanych).

Problem w tym, ze przy projektowaniu duzych aplikacji nie zdarzylo mi sie uzyc niczego stricte UML-owego.

SirMike - a w czym niby przeszkadza tu Agile (swoją drogą miło że nie jestem jedyny )? Można sobie w UMLu choćby iteracje dobrze zaplanować i architekturę na początku.

Glownie to, ze nie ma tu az tyle projektowania i soft produkuje sie mniejszymi kroczkami

[nameczanin]

Niestety mnie nie przekonuje UML w kwestii gamedevu, szczególnie który stricte dotyczy KODU programu, tudzież toola albo gry. No może poza projektowaniem jakiegoś protokołu sieciowo-(lub nie sieciowo)zdarzeniowego, w którym występują tzw. aktorzy.

Tak czy owak, zawsze dobry jest ołówek i dużo papieru (nie, nie używam gumki, bo zawsze jest nie tam gdzie trzeba, czyli w sklepie albo pod łóżkiem, o czym nie wiem). UML może się przydać do projektowania jakichś abstrakcji, ale nie potrafię go używać do generowania kodu na przykład (mowa o klasach) :/

[BadRay]

hm, dużo UML'a nie używałem, jednakże czasami mi się przydaje,
nie jest to strict UML, ale "moim" UML-em zaprojektowałem sobie kilka aplikacji, taki ogólny schemat ich działania np:

Pętli:

Kod:

wylicz dyski->kolejny dysk->szukaj pliku costam.txt:
->jeżeli znajdziesz->zapisz->zakończ program;
->jeżeli nie->(jeśli to nie był ostatni dysk)powrót do instrukcji |kolejny dysk|;

Programu:

Kod:

Początek->Pobierz informacje o systemie->Dodaj informacje do autostartu->itd;

Oczywiście to wszystko było na kartce w postaci strzałek, kółek i prostokącików i mi bardzo ułatwiało pracę.

W gamedev'ie użyłem tego dwa razy:
-do opisania ogólnej architektóry silnika(to akurat jeszcze robie )
-do opisania mechaniki w prostej grze rpg(a dokładniej pętli głównej i kolejności przetwarzania danych, oraz zaprojektowaniu kilku prostych klas)

Ogólnie UML uważam za pożyteczną rzecz w gamedev'ie(chociaż tutaj nie mam zadużo z nim doświadczenia) jak i w programowaniu aplikacji użytkowych.

[Asmodeusz]

Pozwolę sobie odgrzać kotleta - pominięto jedną, dość istotną zaletę UMLa.
Co z automatycznym generowaniem kodu (plików kodu, plików nagłówkowych, szkieletu klas i metod, pliku projektu) za pomocą UMLowych narzędzi? Nikt z tego nie korzysta? Nie ułatwiacie sobie życia i programowania poprzez zaprojektowanie, kliknięcie "Generate" a potem szukanie i zapełnianie wszystkich fragmentów oznaczonych jako "TODO" lub "FIXME"? Sądzę, że właśnie to jest największa zaleta UMLa - wliczając generowanie kodu oraz komentarzy. UML sam produkuje około (na oko) 10-15% kodu wynikowego - co stanowi większość 'mało ambitnego' kodu związanego z rozdmuchaną składnią języka.

[Xion]

A ja lubię wpisywanie tego 'mało ambitnego' kodu i dopóki terminy nie będą mnie goniły tak, by z tego przyjemnego rytuału rezygnować, nie zamierzam go sobie odmawiać ;P

[vashpan]

Hehe, dokladnie

Kiedy piszemy 'class NewFullWypasGame' wtedy, bez implementacji, to jedyny moment w trakcie tworzenia, kiedy wszystko wydaje sie piekne i wspaniale zaprojektowane.. I ty chcesz nam to zabrac

A tak powaznie... czy ja wiem czy to da nam taka wielka oszczednosc czasu ? Narysowanie tych diagramow tez troche trwa, i wcale nie wiem czy w ogole sie oplaca dla niewielkich projektow.

[SirMike]

Pozwolę sobie odgrzać kotleta - pominięto jedną, dość istotną zaletę UMLa.
Co z automatycznym generowaniem kodu (plików kodu, plików nagłówkowych, szkieletu klas i metod, pliku projektu) za pomocą UMLowych narzędzi? Nikt z tego nie korzysta? Nie ułatwiacie sobie życia i programowania poprzez zaprojektowanie, kliknięcie "Generate" a potem szukanie i zapełnianie wszystkich fragmentów oznaczonych jako "TODO" lub "FIXME"? Sądzę, że właśnie to jest największa zaleta UMLa - wliczając generowanie kodu oraz komentarzy. UML sam produkuje około (na oko) 10-15% kodu wynikowego - co stanowi większość 'mało ambitnego' kodu związanego z rozdmuchaną składnią języka.

Niestety kod wygenerowany przez narzedzia z reguly odbiega od standardow kodowania przyjetych w danej firmie wiec na niewiele sie to zdaje. Jedyne co sie nadaje do tego to fajny tool z Visual Studio (niestety tylko do C#), ktory jednak nie pozwala na tworzenie stricte UML-owych diagramow.

[shyha]

Nie spotkałem się, żeby ktokolwiek tego jakoś używał. Jacyś studenci do zabawy - tak. Asystenci do gnębienia studentów - tak. W pracy zawodowej - nigdy (póki co przynajmniej).

[bies]

Nie spotkałem się, żeby ktokolwiek tego jakoś używał. Jacyś studenci do zabawy - tak. Asystenci do gnębienia studentów - tak. W pracy zawodowej - nigdy (póki co przynajmniej).

U mnie takoż. Zarówno analizy jak i projekty to zazwyczaj kobylaste pliki Worda. Raz kiedyś, w innej firmie próbowaliśmy -- nie wiem czy uzywają tego po moim odejściu ale wrażenia raczej negatywne. Ot kolejna zabawka dla szamanów z Rationala (teraz IBM).

[Kos]

Niestety kod wygenerowany przez narzedzia z reguly odbiega od standardow kodowania przyjetych w danej firmie wiec na niewiele sie to zdaje. Jedyne co sie nadaje do tego to fajny tool z Visual Studio (niestety tylko do C#), ktory jednak nie pozwala na tworzenie stricte UML-owych diagramow.

Widziałem go, całkiem mi się podobał. Według mnie projektowanie wizualne (niekoniecznie czysty UML) może mieć przyszłość - sam myślałem by pokombinować z FreeMindem (aplikacja w javie do robienia drzewek / mindmap, zapisuje w XML), opracować jakiś wygodny sposób tworzenia w nim class diagramów i napisać program który na podstawie freemindowskich plików generowałby szkielet kodu (headery klas i pliki z pustą implementacją). Jeśli byłoby to w miarę wygodne, możnaby pokusić się o opracowanie sensownej integracji z jakimś IDE, np. c::b.