Szczęśliwie zaliczyłem przedmiot UML, ale uważam, że to wyjątkowe paskudztwo. :-P Nie wyobrażam sobie jak można tworzyć w tym diagramy, które mają się potem przydać przy tworzeniu programów w językach obiektowych. Dlaczego ? Bo wszędzie i wszyscy mówią co innego. Podam przykłady:
Na pierwszym laboratorium z UML z tworzenia diagramów use case u siebie na studiach miałem zastępstwo z panią doktor (wykładowcą przedmiotu) - mówiła ona co i jak należny tworzyć, że np. jak modelujemy diagram use case dla szpitala to aktor pacjent dziedziczy od lekarza i że w dokumentacji tam pisze się, że pewne przypadki użycia nie podlegają dziedziczeniu, więc na tej podstawie wszyscy wymodelowali swoje diagramy use case, na następne zajęcia przyszedł właściwy ćwiczeni owiec - również doktor i oczywiście stwierdził, że to jest źle - że pacjent nie może dziedziczyć od lekarza. Ponad to mówił, że np. przypadek użycia 'dodaj pracownika' połączony asocjacją z pracodawcą musi być także obowiązkowo połączony z pracownikiem, bo pracownik w tym też uczestniczy, a ja na jednej stronie znalazłem przypadek 'dodaj pracownika' połączony tylko z pracodawcą. Na kolejnych zajęciach z diagramu klas w UML dowiedziałem się, że obowiązkowo muszą być klasy typu 'rejestr', np. rejestr pracowników - w książkach tego nie znalazłem. Poza tym na jednych stronach o diagramach klas zauważyłem klasy typu Menager, na innych nic podobnego nie dostrzegłem. Na kolejnych zajęciach mieliśmy znowu zajęcia z innym doktorem od UML'a - zajęcia z diagramów maszyny stanowej i przy ocenianiu dowiedzieliśmy się, że stan, np. 'przetwarzanie', 'realizowanie' nie może być czasownikiem tylko rzeczownikiem, tymczasem w książce "UML 2.0" stan jest przymiotnikiem. Dodatkowo przy tworzeniu diagramu sekwencji, do którego tworzenia jest wykorzystywany diagram klas z operacjami w klasach - okazało się, że jak np. w diagramie klas mamy w klasie pracodawca operacje 'dodaj pracownika' i klasa ta jest połączona asocjacja z pracownikiem to jak na diagramie sekwencji połączymy linię życia pracodawcy z pracownikiem to już nie mamy do wyboru metod z klasy pracodawca a tylko pracownik, więc np. funkcja 'dodaj pracownika' musi się znajdować w klasie pracownik. W ogóle ten cały UML jest bez sensu - każdy mówi co innego, w jednej książce przedstawiają daną sytuację, a w drugiej zupełnie inaczej, tak samo na stronach internetowych. Wole pisac normalnie programy w c++ czy javie bez żadnego UML'a, bo w tym UML'u nie mozna sie połapać - wszedzie jest co innego :/
Bez obrazy, ale Twoj post wyglada jak siano - slyszales o akapitach badz blokach?
Nie wczytujac sie nadmiernie w to co napisales (lekko oczy bola o tej porze), ale majac nadzieje, ze uchwycilem sedno, zadam jedno krotkie pytanie:
Jak wyobrazasz sobie prace zespolu powiedzmy 10 programistow, kierownika, 2 analitykow i koordynatora projektu (ktory ustala wymagania z klientem) bez ujednoliconego jezyka i systemu porozumiewania sie pomiedzy roznie wyksztalconymi ludzmi, ktory umozliwialby precyzyjnie przekazanie abstrakcyjnego modelu skomplikowanego systemu?
Tak, jest powszechnie wykorzystywany, bo a) jest dobry, b) dziala, c) nawet jak go nie lubisz, to lepiej dla Twojego zdrowia i przyszlosci projektu go uzywac.
@wiewiorek, powiem ci szczerze, że masz pecha. UML zazwyczaj jest prowadzony do du@@, a ty trafiłeś chyba wyjątkowo źle.
Tak jak pisał johny, UML jest uniwersalnym narzędziem do porozumiewania się pomiędzy programistami, analitykami, architektami i managerami. Pozwala na opisanie problemu i rozwiązania za pomocą niezwiązanych z konkretnym językiem programowania czy technologią obrazków. Weź pod uwagę, że kod można zdrowo zamieszać, a UML jest zazwyczaj w miarę zrozumiały i przejrzysty. UML został stworzony jako rozwiązanie problemów związanych z komunikacją pomiędzy ludźmi - uczestnikami projektu. Po latach objawiają się też inne zalety na przykład brak konieczności tłumaczenia ton dokumentacji na inne języki. Wierz mi lub nie, ale angielski w praktyce projektowej jest zupełnie inny niż w szkole. Masz chociażby ludzi z różnych krajów, którzy mówią po angielsku, a ty ich nie rozumiesz (szczególnie boli słuchanie Azjatów).
UML jest uniwersalnym językiem tak samo jak piktogramy na kibelkach.
wiewiorek napisał(a)
Wole pisac normalnie programy w c++ czy javie bez żadnego UML'a, bo w tym UML'u nie mozna sie połapać - wszedzie jest co innego :/
A projektować je też będziesz w C++ ? czy w ogóle nie projektujesz tylko piszesz wszystko na żywca.
A tak ogólnie to zgadza się. Wielu ludzi którzy uczą UML'a są po prostu kiepskimi projektantami i z tego takie kwiatki. To nie wina UML że twoi doktorzy nie kleją o co chodzi w dziedziczeniu. poza tym w use case najważniejszy jest słowny opis a nie sam diagram. Albo co ma UML do klasy Manager? Potrzebujesz jakiegoś menagera to go dajesz... zarówno w C++ jak i UML. Metoda dodaj_pracownika w klasie pracownik? samozatrudnienie czy co? Pomyślmy logicznie: Dodajesz pracownika do czego ? Np. do firme, do departamentu, itp. czyli
Firma f = ...;
f.dodaj(new Pracownik("Zbychu Nierob"));
Tu się kłaniają umiejętności z projektowania obiektowego. UML jest tu tylko narzędziem.
Osobiście jak mam zaprojektować coś od zera (całą aplikację lub jakiś większy moduł) to bez rozrysowania tego wszystkiego w UML'u ani rusz. A generalnie UML wykorzystuje cały czas jako szkice projektowe żeby przedstawić innym z zespołu jak chce jakiś problem rozwiązać. I generalnie jak masz to tego zdrowe podejście i nie stosujesz jakiś semantycznych dziwadeł z głębi specyfikacji UML to wszyscy się rozumieją.
Może jakbym miał zajęcia z jakimiś praktykami magistrami co w pracy go używają to faktycznie wydałby mi się potrzebny, po zajęciach z doktorami teoretykami mam tylko mętlik :-P ;-P
wiewiorek napisał(a)
Może jakbym miał zajęcia z jakimiś praktykami magistrami co w pracy go używają to faktycznie wydałby mi się potrzebny, po zajęciach z doktorami teoretykami mam tylko mętlik :-P ;-P
A bo to pierwszy raz? Albo ostatni?
To chyba logiczne, że jak ktoś się na czymś zna, to w tym pracuje, a jak ktoś się nie nadaje do pracy, to zostaje wykładowcą.
Taki truizm - UMLa czy inżynierii oprogramowania nie da się nauczyć z książek, tu trzeba praktyki.
I jeszcze coś - jak rozumiem studiujesz - myślisz, że napiszesz pracę dyplomową z dziedziny programowania bez użycia UMLa? Jak?
Ja z UML'a na uczelni byłem "świetny", ale jak przyszło co do czego i pokazałem ludzikom w pracy co skleciłem (bazując na tym czego nauczyłem się na zajęciach) to myślałem że padną ze śmiechu :) Więc podpisuję się pod przedmówcami: praktyka, praktyka i jeszcze raz praktyka :)
[browar]
Wygląda na to, że w tym wątku głównie dowiesz się, że UML na uczelniach jest wykładany w zasadzie kiepsko.
Do tego może Ci się wydawać niepotrzebny, bo nie pracowałeś jeszcze w zespole nad dużym projektem (z tym też kiepsko na uczelniach).
Ale jak np. trafisz do małej firmy (która go nie stosuje) to już po kilku miesiącach będziesz czuł, że potrzebujesz czegoś co pozwoli Ci wyspecyfikować wymagania klienta, bo inaczej to będzie wyglądało tak:
- klient Wam powie, że chce stronę z treścią, menu i zielonym tłem
- będziecie programować przez miesiąc - dwa
- przez drugie tyle będziecie wprowadzać poprawki bo klient "inaczej to sobie wyobrażał"
Jednak jest jeszcze druga strona medalu: nie ma co robić diagramów UML dla idei (np wszystkich możliwych perspektyw dla każdego projektu). UML - jak każde inne narzędzie - używasz tak długo, jak bardziej pomaga niż przeszkadza.
Jednak prawdę mówią przedmówcy: jeśli nie znasz narzędzia, to nie będziesz umiał go użyć (nawet nie będziesz wiedział jak mógłby Ci pomóc). Więc go poznaj (np czytając jakąś dobrą książkę, a ćwiczenia z niej możesz zawsze skonsultować tutaj)
Powiedzmy tak: miałem podobne zdanie. Ale się przekonuję, że przynajmniej niektóre elementy UML-a są fajne i przydatne, gdy robi się coś większego. Sensu istnienia diagramów niektórych nie widzę, ale możliwe, że się przekonam ;-)
I jeżeli UML to paskudztwo, to dowiedz się jakim okropieństwem jest WebML. Tutaj to już zupełnie stwierdziliśmy na laboratoriach, że chyba szybciej sami stworzymy aplikację niż nam się uda to zaprojektować (a samo WebRatio do tego wspaniałego języka jest równie okropne).
Byl juz taki temat, ale odpowiem jeszcze raz: jak piszesz samemu, to UML jest na ogol zbedny, jak piszesz cos z druga osoba, to UML pozwala pewne rzeczy wyklarowac, ale jak piszesz z duza grupa ludzi, to bez projektu ani rusz, ale UML jest wlasnie narzedziem projektowym.
Problem z uczelniami jest taki, ze wykladowcy bardziej koncentruja sie na tym co opisuja (a podejsc przeciez moze byc wiele), niz to, ze ucza sposobu jak opisywac.
W pewnych systemach lekarz moze dziedziczyc z pacjenta, w pewnych absolutnie nie - takie dywagowanie Cie niczego nie nauczy, ale jak ktos Ci powie, ze dziedziczy (bo tak analityk wymyslil i zaprojektowal system), to masz to rozumiec i umiec zaimplementowac, a jak jestes analitykiem, to masz rozumiec, jakie konsekwencje ma decyzja o dziedziczeniu (lub nie).
WebML - koszmarne paskudztwo... Ktos, podpisuje sie pod twoimi slowami obiema rekami.
Mi w pracy na razie przydały się przypadki użycia i diagramy sekwencji (nawet dziś jeden robiłem). Reszta diagramów jeszcze mi się nie przydała.
Nawet klas? Mi się wydaje, że to chyba najczęściej używany...
No właśnie. U mnie na uczelni UML też był wyłożony beznadziejnie. W ogóle cała inżynieria oprogramowania był wyłożona beznadziejnie. Być może do złego wykładu dokłada się pewna przewrotna zasada, którą miałem okazję "odkryć" na podstawie uczestniczenia w wielu wykładach (i zarazem samemu nieco wykładając): "Nie ucz teorii przed praktyką, ale jeśli Cię zmuszą, to zacznij od dużej liczby przykładów".
Po prostu mam wrażenie, że taki przedmiot jak inżynieria oprogramowania powinien zostać wyłożony już po tym, jak studenci ubabrali się w jakimś dużym projekcie i stracili nerwy na słabej komunikacji, zmieniających się wymaganiach, krótkich terminach, marudzącym kliencie, spaghetti w kodzie itp. A na większości uczelni jest za wcześnie i studenci myślą sobie "Zieeeeww.... Ale nuda...", a później wracają do klepania kolejnego projektu na 100 linijek na zaliczenie, po którego ukończeniu stwierdzają "I po diabła nam ten UML?".
Krolik napisał(a)
"Zieeeeww.... Ale nuda...", a później wracają do klepania kolejnego projektu na 100 linijek na zaliczenie, po którego ukończeniu stwierdzają "I po diabła nam ten UML?".
Normalnie jakbyś u mnie był xD
Chociaż nie naże... narze... nie marudzę, u mnie wykładali to kolesie, którzy na codzień pracują w tym fachu, w swojej firmie i stosują uml w swoich projektach, więc prowadznenie nie było takie tragiczne, chociaż najlepsze też nie było, zdecydowanie za mało przykładów. Samego umla doceniam, chociaz w praktyce okazji stosować nie miałem, nawet gdy realizowałem projekt na zaliczenie z kumplem, jakoś obeszło się bez niego, każdy wiedział, co ma zrobić i się robiło. Ale mam świadomość, że to dobry kumpel i łatwo się z nim było porozumieć. Gdyby w projekcie była chociaż jeszcze jedna osoba - bez umla sobie tego nie wyobrażam.
Zdecydowanie brak na uczelniach wyższysz projektów grupowych, mocno grupowych, zarządzanych też jakoś bardziej odgórnie, czy tam wspomaganych. Niby jest jeden projekt grupowy z programowania, ale w dwie osoby to nie tak znowu grupowo. Jest projekt grupowy z baz danych, zobaczymy jak to będzie, no ale w większości bedzie to aplikacja wyklikana w c#, więc raczej też bez szaleństw. Brak jednego, całosemestrowego, większego projektu, w którym prowadzący na bieżąco obserwowałby postęp i te sprawy, komentował, wspomagał, oceniał.
Ale patrząc na moją grupę, gdzie na 19 osób (mała grupa :P ) programowaniem interesuje się jakoś poważniej osób może 4, może 5 w porywach, to nie ma szaleństwa, ciężko byłoby wielkogrupowy projekt zrobić.
U mnie projekt grupowy z baz danych był w 3 osoby, a z "projektu grupowego" był 5 osobowy. Ale oba zrobiliśmy z jednym kumplem we dwóch, wychodząc ze słusznego założenia, że jakbyśmy tamtych leszczy dopuścili, to do tej pory byśmy tego nie skończyli, a nawet jeśli, to oceny byłyby marne. Nienawidzę projektów grupowych, bo nie ma z kim ich robić :/
A UML? Jasne - w sprawozdaniu i dokumentacji z projektu, bo w trakcie tworzenia się w zasadzie nie przydał, a ponadto UMLem chyba tylko ja byłem w tych grupach zainteresowany.