Diagramy UML

Jestem studentem, nie uczestniczylem w projektach gdzie to by bylo wykorzystane.

Wiec pytanie: do czego sluza te diagramy, czy rzeczywiscie sa pomocne ? Czy to standard w wiekszych firmach ze cos takiego sie wykorzystuje ?

Bo dla mnie na razie to bezsens, ale pewnie sie myle :D

Tak jest to pewien standard.

Co do tego co to jest to wikipedia juz nie dziala, czy google ?

Też nigdy nie korzystałem, ale chodzi pewnie o to że łatwiej zobaczyć niepożądanie powiązania i zaprojektować aplikację.

t0m_k-tmp napisał(a)

Co do tego co to jest to wikipedia juz nie dziala, czy google ?

a Tobie nie działa mozg ?

Wiem jak zrobic diagram, ale pytanie jest PO CO sie to robi ? Cyz rzeczywiscie ma to zastosowanie ?
Nie pracuje w IBMie, MS, czy tam w wiekszych korporacjach/firmach.
Moze ktos wie, po cholere te diagramy tak naprawde w praktyce...

@autor: a brałeś udział / pisałeś kiedyś coś na prawdę dużego w kilka osób? (na tyle dużego ze nie jesteś w stanie ogarnąć całego tego systemu). Diagramy służą do projektowania systemów informatycznych. Nie wyobrażam sobie np. żeby bez sensownego projektu dało się w napisać cokolwiek w grupie kilkunastu/kilkudziesięciu programistów.
Ogólnie nawet nie wielkość systemu jest tutaj kluczowa ale ilość zaangażowanych osób. Można w ten sposób zamodelować system a potem przydzielić zadania członkom zespołu i nie marnować potem kupy czasu na to żeby programiści się dogadali jak ma wyglądać system w miejscach gdzie ich części się łączą. Piszą po prostu tak jak jest na diagramie.
Poza tym są diagramy bardziej "informatyczne", ale też takie UseCase które można pokazać klientowi i zorientować się czy o coś takiego mu chodzi.

W Hello World faktycznie mało przydatne. W jednowarstwowych też nie, a niektórzy "profesjonaliści" potrafią tworzyć je całkiem sporych rozmiarów...

I nie trzeba tu MS czy IBM, znacznie mniejsze firmy też tego używają. Niestety w wielu jednak ludzie wolą sobie utrudniać życie, zamiast poznać dobry standard wspomagania pracy. Efekt braku używania UML - strata czasu i pieniędzy.

@Shalom - myślę, że kryteria rozmiaru czy projektu, czy liczby osób nie są właściwe. Czasem samemu dla siebie dobrze coś narysować. Niby można mieć wszystko w głowie, ale po co, skoro łatwiej na kartce? Trudniej wtedy zapomnieć.

UML jest po to, żeby wiedzieć:

1. co się robi;
2. do czego to ma służyć;
3. jakie funkcjonalności udostępniać;
4. jakie dane przechowywać;
5. z jakich elementów się składać;
6. jak mają one być ze sobą powiązane;
7. jakie operacje maja między nimi zachodzić;
8. w jakiej kolejności te operacje mają się odbywać;
9. i jeszcze trochę...

Po co to wiedzieć? Żeby to zrobić. :) W sensownym czasie i w miarę przypominającego to, czym miało być.
Notacja graficzna jest czytelniejsza i łatwiej przemawiająca do wyobraźni niż suchy tekst. A zwłaszcza jego brak. ;)
Łatwiejsza nie tylko dla programisty, ale także dla klienta. Każdy jest w stanie zrozumieć, że ludzik z patyków symbolizuje użytkownika, a elipsa funkcję systemu. A narysowanie tego dobrze, to połowa sukcesu.

Obecnie razem z jednym kolegą z pracy robimy projekt. Specyfikacja jaką dostaliśmy to plik psd z layoutem oraz pdf z połączonymi layoutami poszczególnych podstron systemu... WTF?
Naszymi zleceniodawcami jest trzech handlowców z naszej firmy. Gdy idziemy do nich na spotkanie w sprawie projektu, to generalnie kłócą się o to, czy menu powinno być z lewej czy z prawej albo czy przycisk powinien być niebieski czy zielony. No nawet śmieszne - w końcu mi płacą od godziny. ;)

Już z miesiąc nad tym przesiedziałem, generalnie jestem gdzieś na początku pracy (tzn. tak mi się wydaje, bo zielonego pojęcia o rozmiarze projektu nie mam, a Adobe Reader nie potrafi go pokazać :d).
Gdyby specyfikacja była sensowna, to pewno bym był w połowie i wiedział, co będę robił jutro.

To miłe móc sobie spojrzeć na jakiś diagram i ocenić, ile projektu już się wykonało. Dobrze wiedzieć, gdzie się jest, człowiek jest wtedy jakiś taki spokojniejszy i ma więcej chęci do pracy.
Kuźwa, żeby jeszcze w mojej pracy to rozumieli. :/

Diagramy maja rozne poziomy zrozumienia i rozne grupy docelowe. Nasz klient wymaga projektu zleconej zmiany, ktory ma zawierac miedzy innymi diagramy UML. Nam jest to na reke, bo system jest skomplikowany biznesowo, pisany do tej pory przez wiele osob i czesci kodu juz nikt nie pamieta albo nie kojarzy. Korzysci to:

• diagramy use case: programisci widza mniej wiecej jak to ma dzialac i do czego to ma sluzyc, testerzy na ich podstawie moga sobie napisac przypadki testowe, zeby wiedziec co i jak testowac, analityk po stronie klienta sprawdza czy to jest to o co chodzilo w zleceniu
• diagramy techniczne: sluza glownie do tego, zeby po roku bylo wiadomo co to jest i po co bylo napisane, miedzy innymi:
  • diagramy klas: podzbior klas, latwo wtedy skojarzyc dana funkcjonalnosc z dana grupa klas i wiedziec, w ktorym miejscu szukac np. bledu w zwiazku ze zgloszeniem
  • diagramy interakcji, aktywnosci i obiektow: zwykle zapisana mniej wiecej logika rozwiazania, fajne, jesli do problemu siada osoba, ktora funkcjonalnosci nie zna, a ma cos poprawic
  • diagramy przeplywu danych: przydatne, jesli przez 20 klas i metod przelatuje jakas informacja, szczegolnie jesli jej postac sie zmienia i trzeba ja przesledzic

Do tego takie oczywiste oczywistosci jak np. diagramy ERD z opisem do czego sluzy kazda kolumna :) To wszystko sklada sie na jasny opis co nalezy zaimplementowac, jak ma sie zmienic funkcjonalnosc systemu, a w dalszej kolejnosci - jak to dziala i wskazowki co zmienic, zeby bylo lepiej/poprawic blad/zaimplementowac dalsza zmiane.

by teoretyczni masochiście nie opisywali swoich projektów językiem matematyki ;p

Aby nie zaśmiecać forum krótkim pytaniem, zapytam tutaj: czy w diagramie przypadków użycia mogą się krzyżować połączenia pomiędzy poszczególnymi użyciami?

O co dokładnie chodzi, przykład:

Gdyby poprowadzić prostą od użytkownika do "Rejestrowanie administratora" (tak wiem, że to jest bez sensu, to tylko teoretycznie), to prosta ta przecięłaby ze 3 inne. Można tak zrobić?

No tak, bo nie dałoby sie przesunąć "rejestrowania administratora" do góry żeby się nie przecinało...
Ogólnie: nie jest to żaden błąd, ale jest nieestetyczne i zaciemnia obraz i należy unikać takich sytuacji.