Czy UML jest w ogóle wykorzystywany poza studiami?

Naszła mnie taka refleksja, jestem kilka lat po studiach, pracowałem w kilku firmach - w tym w bardzo dużych, absolutnie w żadnej nie był wykorzystywany UML (no może czasem jakiś prosty diagram trzeba było wstawić do dokumentacji, której było wiadomo, że i tak nikt nie czyta). Co więcej, już w trakcie studiów nie widziałem przydatności tego języka - w firmach, w których pracowałem zwykle dostaje się opisane słownie wymaganie czego użytkownik oczekuje + klikalna makieta i to wydaje mi się dużo lepsze niż jakieś np. use case w formie diagramów, bo tu mam klikalne makiety więc widzę jak coś ma wyglądać i działać.

Ktoś z Was w ogóle wykorzystuje w pracy UMLa?

Pracuję na razie dość krótko i niedawno skończyłem studia, ale wykorzystywaliśmy już UML-a w normalnych projektach. Co prawda nie robi się tego codziennie, a głównie podczas planowania projektu, jego gruntownego refaktoringu lub planowania jakiegoś bardziej złożonego komponentu. Nie była to sztuka dla sztuki, a diagramy UML w przypadku, o którym piszę, rzeczywiście się przydały. Niemniej jednak, jeśli miałbym podać częstotliwość użycia UML-a, to byłoby to raz na pół roku lub raz na rok w zależności od tego, jaki jest projekt. Podejrzewam, że w przypadku maintenancu jakiegoś legacy kodu UML-a nie wykorzystuje się wcale lub ewentualnie ogląda się go w dokumentacji. Jeżeli mamy narzuconą architekturę aplikacji przez jakiś powszechnie znany framework i nie musimy tworzyć nietypowych, dedykowanych rozwiązań, to tworzenie UML-a też nie ma większego sensu. Wszystko zależy od sytuacji i konkretnych potrzeb.

@pytk są miejsca gdzie się używa ;) Głównie tam gdzie buduje sie systemy mission-ciritical, gdzie nie ma miejsca na bugi bo nie da się "poprawić w nowej wersji".
ESA na przykład ma trochę swoich zabawek do takich celów (Leirios, HOOD, Savoire). No ale Space Industry to jest w ogóle Document-Driven-Develpment i Waterfall ;)

pytk napisał(a):

Co więcej, już w trakcie studiów nie widziałem przydatności tego języka - w firmach, w których pracowałem zwykle dostaje się opisane słownie wymaganie czego użytkownik oczekuje + klikalna makieta i to wydaje mi się dużo lepsze niż jakieś np. use case w formie diagramów, bo tu mam klikalne makiety więc widzę jak coś ma wyglądać i działać.

A kto i na jakiej podstawie robi te klikalne makiety?

Nie posuwałbym się do stwierdzenia, że skoro gdzieś UML jest nieużywany, to jest niepotrzebny. Zwłaszcza, jeśli dokumentacji i tak nikt nie czyta", bo to dużo świadczy o tych firmach.

Ktoś z Was w ogóle wykorzystuje w pracy UMLa?

W poprzedniej pracy bez UMLa nie było nawet mowy o implementacji czegokolwiek. To nawet dość normalne, że klient chce mieć dokumentację, a programiści dokładnie wiedzieć, co mają robić.

U mnie normalnie używa się UML w dokumentacji projektu.

(no może czasem jakiś prosty diagram trzeba było wstawić do dokumentacji, której było wiadomo, że i tak nikt nie czyta)

Pogratulować, to po kiego piszecie tą dokumentację w ogóle? :D

Ja praktycznie do każdej umowie o dzieło załączam dokument zwany "wizją systemu", a przynajmniej diagram przypadków użycia. W mojej opinii, taki diagram najprościej i na jednym obrazku pokazuje, jak ten system ma właściwie wyglądać. Jest konkretna lista funkcjonalności i każda dodatkowa będzie płatna dodatkowo. Dlatego lepiej, by klient czytał dokumentację, przed podpisaniem umowy.

Natomiast w codziennej pracy absolutnie nie wykorzystujemy RUPa, ale UML przydaje się właśnie na etapie projektowania. Po co mam przez 10 stron opisywać, jak ma wygląda komunikacja, skoro mogę narysować diagram komunikacji? To samo gdy dostałam za zadanie opisać przebieg programu - mogłam opowiadać godzinami i nikt by nie skumał, a mogłam narysować jeden diagram sekwencji na pół strony A4.

James Iry napisał(a)

1842 - Ada Lovelace writes the first program. She is hampered in her efforts by the minor inconvenience that she doesn't have any actual computers to run her code. Enterprise architects will later relearn her techniques in order to program in UML.

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html

A wracając do tematu: U nas nie używa się. UML mało przydaje się w dyskusjach "co" ma być w systemie i jak ma działać od strony użytkownika, natomiast jak już wiadomo, czego chce użytkownik, to ktoś po prostu siada i pisze prototyp. Dyskutowanie na temat, która klasa ma co rozszerzać lub w jakiej kolejności coś tam w systemie ma wywoływać coś tam innego jest raczej stratą czasu, bo każdy programista jest w stanie samemu projektować z sensem. Znacznie lepiej jest mieć szybko coś konkretnego, działającego, co później można modyfikować, niż 200 stron dokumentacji stworzonej przez jakiegoś astronautę, który na oczy nie widział kodu (np. analityka albo architekta) i czego i tak się nie da zaimplementować. Jak mamy prototyp, to robimy demo + prezentację i każdy może zgłaszać uwagi.

@Krolik, a jak opisujecie jakie dane ma przechowywać moduł magazynowy, a jakie fakturujący? Albo sekwencje podróży użytkownika przez ekrany aplikacji w celu wykonania jakiejś czynności?

somekind napisał(a):

pytk napisał(a):

Co więcej, już w trakcie studiów nie widziałem przydatności tego języka - w firmach, w których pracowałem zwykle dostaje się opisane słownie wymaganie czego użytkownik oczekuje + klikalna makieta i to wydaje mi się dużo lepsze niż jakieś np. use case w formie diagramów, bo tu mam klikalne makiety więc widzę jak coś ma wyglądać i działać.

A kto i na jakiej podstawie robi te klikalne makiety?

Spotkałem się z tym, że specjaliści ds. UX robili klikalne makiety na podstawie dokumentacji projektu, rozmów i warsztatów z klientem.
Takie makiety, a właściwie klikalne mocki miały być docelowo punktem wyjściowym do tworzenia GUI aplikacji. Niemniej jednak, w praktyce wychodziło to średnio, choć miało na to wpływ kilka czynników.

Wiem, że w mojej obecnej pracy wcześniej były tworzone diagramy UML do dokumentacji dla programisty która liczyła kilkaset stron, ale wtedy oprogramowanie w mojej obecnej firmie było tworzone metodą wodospadową więc jeden etap trwał minimum miesiąc. Natomiast gdy została u nas wprowadzona metodyka SCRUM (wtedy już dołączyłem do obecnej firmy) to już tworzenie takich diagramów straciło sens, bo 1 sprint trwa u nas tydzień więc nawet nie byłoby czasu na zrobienie takich diagramów.

W mojej obecnej pracy widziałem UML w dokumentacji, aczkolwiek bezpośrednio z niego nie korzystałem. Poszczególne zadania są zrozumiale rozpisywane i przekazywane do programistów, jak coś jest niejasne to zwykle praktykuje się zapytanie do opiekuna projektu lub ew testera :)