Dziś dzwoni do mnie pani z rekrutacji Oczywiście podać nic nie może (dlatego nie wiem co to za firma) ale pogadaliśmy, a ona się mnie pyta, jak tam u mnie ze znajomością uml
Ja się pytam, serio ktoś tego wymaga
Pani mówi, że jak najbardziej
Zdziwiłem się bo ostatni raz ktoś mnie o uml pytał z ładnych parę lat temu (studia) potem już nigdy
Na rozmowach (a było ich trochę) ani razu
A tu wymaganie, że trzeba być w tym dobry
Głównie diagram sekwencji, stanu i czasami jak są jakieś pojebane logiki biznesowe które mają dziesiątki wyjątkow, dziwny error handling to diagram aktywności.
W tych przypadkach chyba nie ma nic lepszego :p
I raczej ich brak to patologia.
Przy czym ja wątpię, żeby ktoś gdzieś wymagał, aby kolor strzałki i gęstość kresek się zgadzała. Chodzi o umiejętność przekazania koncepcji.
Warto wiedzieć, że jest coś takiego jak UML i warto umieć sobie znaleźć informacje na ten temat, jak zobaczymy gdzieś dziwną strzałkę.
Ale...
ref napisał(a):
ona się mnie pyta, jak tam u mnie ze znajomością uml
(...)
A tu wymaganie, że trzeba być w tym dobry
Bez przesady, jak są gdzieś UMLe, to ile czasu ci zajmie wygooglanie, co która strzałka znaczy, nawet jak zapomnisz?
Chociaż w branży IT ze wszystkiego potrafią zrobić "technologię" i wszystko potrafią zrobić jako wymaganie rekrutacyjne i ze wszystkiego potrafią pytać na rekrutacjach, więc nie zdziwiłbym się, gdyby cię odrzucili za słabą znajomość UMLa. W końcu to jedna z "technologii" wykorzystywanych w projekcie, a ty się zdziwiłeś, zamiast powiedzieć, że znasz.
My dokumentacji nie piszemy a co dopiero jakieś diagramy. Panie, trzeba bugi łatać i pisać testy jednostkowe do starego kodu, ale tylko takie które przechodzą.
Bez przesady, jak są gdzieś UMLe, to ile czasu ci zajmie wygooglanie, co która strzałka znaczy, nawet jak zapomnisz?
Tu nie chodzi o to
Tu chodziło mi o sam fakt wymagania znajomości uml w stopniu zaawansowanym.
Każda firma może sobie wymagać czego tam chce, jej prawo
Mnie to zwyczajnie zaskoczyło, bo to była pierwsza firma, która tego wymaga
Mówię do pani rekruterki, że tak na poważnie to z tego ostatni raz na studiach korzystałem
Pani na to - dobrze to się dopytam
Niektóre diagramy bardzo często, niektóre wcale. Diagramy sekwencji, stanu są bardzo przydatne, a takiego diagramu klas nie narysowałem od lat.
Pracowałem w projektach w których był używany uml i dobre praktyki z tym związane i ta praca przyznam była przyjemnością, można było z kimś podyskutować na wyższym poziomie abstrakcji i szybko ogarnąć kontekst.
Także taka informacja od rekruterki byłaby dla mnie raczej zachętą, bo aktualnie promowane podejście żeby robić byle jak byle szybko bo jesteśmy agile do mnie nie przemawia :P
piotrpo napisał(a):
Diagramy sekwencji, stanu są bardzo przydatne, a takiego diagramu klas nie narysowałem od lat.
Największy problem z UMLem jest to że na studiach rzeźbiło się te diagramy klas które w moment stają się nieaktualne i są niesamowitym 
Z drugiej strony na studiach nie robi się za bardzo diagramu sekwencji który jest najbardziej przydatny z tego. Pamiętam jak miałem czasem wprowadzenie do projektu w pracy to wyglądało to tak że najstarszy programista rysował na tablicy coś co w miarę przypomina diagram sekwencji albo "diagram komunikacji" między mikroserwisami, czasem ktoś robił temu zdjęcie, ale nikt tego nie przepisywał do dokumentacji.
Parę razy widziałem też "diagram algorytmu", ale nawet nie wiem czy to podpada pod UML czy graficzny pseudokod
BTW pamięta ktoś jeszcze ze studiów rozpiskę wszystkich diagramów? tego było ze 20. Większości nigdy na oczy nie widziałem :D
@KamilAdam: Diagram klas nie jest kupą. Jeżeli chcesz zrozumieć na czym polega jakiś wzorzec projektowy, albo jak poskładane jest collections w Javie, to właśnie diagramy klas są przydatnym narzędziem. Natomiast są one kompletnie nie przydatne w codziennym programowaniu, bo ani wzorców, ani złożonych bibliotek nie tworzy się często. No i dochodzą mikrousługi, które z założenia powinny być na tyle proste, że dokumentacja na poziomie kodu jest zbędna.
I ogólnie, diagram klas tworzony przez architekta, który później jest wypełniany implementacją przez programistę, to raczej mokry sen OOD/OOP.
Pisałem wiele razy na tym forum, że UML to 14 różnych typów diagramów więc jest w czym wybierać. Niektóre są przydatne bardziej inne mniej jak diagram przypadków użycia, klas, obiektów.
Argumentem za UML-em którego często brakuje w dyskusjach to standaryzacja/unifikacja diagramów. Dzięki temu, że typ strzałki, bloku, rombu i każdego innego kształtu jest jasno określony, od razu wiadomo co on znaczy i nie trzeba zastanawiać się co autor miał na myśli rysując przerywaną strzałkę w lewo czy prawo.
Jeśli chodzi o dokumentowanie architektury aplikacji to korzystam z C4, ale do modelowania używam kształtów z UML bo UML jest u nas standardem. Na załączonym obrazku jest zmapowany diagram komponentów z modelu C4 na UML
Przez prawie pełnoletnią karierę zawodową w różnych rolach, m.in. architekta rozwiązań, czy analityka biz / sys UMLa zdarzyło mi się używać:
UML ma pewnie swoje zalety, jak wszyscy "mówią" tym językiem, ale jak musisz np. z biznesem rozmawiać i proces rysować, to uczenie ich od nowa, co jest co, zamiast skupić się na przekazie jest działaniem anty-skutecznym i frustrującym, jeśli chodzi o poprawę komunikacji.
Co do diagramów technicznych, to jeszcze high-level architektura (fizyczna, logiczna), ale to też można na "strzałkach i kwadratach". Rozpisywanie diagramu klas, to dla mnie jest totalna abstrakcja i nigdy na projektach, które realizowałem, a uzbierało się tego trochę, nie robiliśmy tego typu dokumentacji.
pare razy w korpo, gdize bylo wymaganie zeby zrobic diagramy, dokumentacje ktorych nikt nie czyta. Sporawdycznie/minimalnie przez ostatnie prawie 8 lat
Szczerze mówiąc, to dopiero czytając ten wątek, dowiedziałem się, że UML to coś więcej, niż diagramy klas - bo pomimo studiowania na trzech różnych uczelniach, nigdy nie słyszałem o żadnym z innych rodzajów.
Wracając do pytania zadanego przez OP - w jednej robocie do API mieliśmy załączone diagramy sekwencji, w innej mieliśmy diagramy przepływu danych przez CI. Ale żaden z tych nie był oparty o UMLowskie konwencje.
kazdy debil umie czytac UML, nie musi byc po IT. Sformalizowany sposob przekazywania koncepcji i tyle
ja sama z własnej chęci wrzucałam UML spisując wymagania przyjemnie było popatrzeć jak szefostwo udawało że rozumie diagram
Chdzk napisał(a):
kazdy debil umie czytac UML, nie musi byc po IT. Sformalizowany sposob przekazywania koncepcji i tyle
Miang napisał(a):
ja sama z własnej chęci wrzucałam UML spisując wymagania przyjemnie było popatrzeć jak szefostwo udawało że rozumie diagram
Czyli jednak nie każdy.
@Chdzk: czytać tak ale rozumieć nie. To tak jak z matmą. Logikę każdy coś tam kuma co to zbior też a nie każdy przeczyta coś takiego:
A jak jeszcze wproadzisz kwatynfikatory zamiast opisu słownego to wgl jest maczek.
Zdarzyło mi się pracować z wykorzystaniem UML, BPMN. Nawet sam proponowałem dokumentowanie w ten sposób jakichś ustaleń biznesowych. Po pół roku, nigdy już nie pamiętam co do czego, ale ogólnie dla różnych procesów warto używać diagramów, przede wszystkim dla spójności wizji biznes, analityk, programista.
bo jezeli do diagramu potrzebnea jest legenda tzn ze poszło coś nie tak IMO
WUT? Do UMLa są całe książki https://helion.pl/kategorie/programowanie/uml . wiec nie do końca rozuiem to stwierdzenie.
Używam w następujący sposób:
Do modelowania procesów - BPMN.
Do prototypownia podczas spotkań - power point.
Podstawowe problemy z diagramami:
Problem z UML jest taki że nie każdy te diagramy rozumie. Osobiście wole robić diagramy w C4 model bo łatwiej jest taki diagram ogarnąć osobom mniej technicznym. Generalnie z narzędzi polecam plantUML i podejście 'architecture diagram as a code'.
Oczywiście - ale głównie diagramy sekwencji, klas i stanów(bo maszyna stanów to w sumie był podstawowy wzorzec tak w telco jak i w automotive).
Zgodnie z moim doświadczeniem powszechnie nie używa się stricte UML. Problemem jest to, że mało kto umie poprawnie komunikować się tym językiem.
Hipotetycznie wyobraźmy sobie nietrywialny diagram UML, który miałby być czytany przez wiele kompetentnych osób (zespół, organizację). Czy został w pełni poprawnie zapisany? Czy wszyscy czytelnicy będą w stanie w pełni poprawnie zinterpretować diagram?
Raczej w branży powszechnie używamy uproszczonych i uogólnionych tworów UML-podobnych (mylnie nazywanych UML), pochodnych od UML, które są prostsze w poprawnym użyciu.
gienek64bit napisał(a):
Problem z UML jest taki że nie każdy te diagramy rozumie.
you had one job... XD The unified modeling language (UML) is a general-purpose modeling language that is intended to provide a standard way to visualize the design of a system.[1] https://en.wikipedia.org/wiki/Unified_Modeling_Language
Osobiście wole robić diagramy w C4
https://xkcd.com/927/
UML miał stać się czymś uniwersalnym, a stał się kolejnym formalnym sposobem zapisu konkurującym z innymi formalnymi sposobami albo masą nieformalnych na zasadzie "będziemy rozumieć, o co chodzi".
Być może chodzi o to, że diagramy UMLm mimo że zawierają ciekawe pomysły, to same w sobie nie są zbyt ekspresywne, że opisać działanie współczesnego software'u, szczególnie takiego bardziej dynamicznego, w którym co chwila się coś dzieje (np. apki React). Tak jakby nie przetrwały próby czasu, mimo że pewne rzeczy mogą być w nich przydatne.