UML w pracy. Poziom zaawansowania

Cześć.
Interesuje mnie informacja czy używacie w pracy notacji UML?
Jeśli tak to jak diagramy owe najczęściej wyglądają? Tzn jakie obiekty na nich się znajdują? Czy są to tylko klasy, agregacje, asocjacje, generalizacje i zależności?

czy może używacie też bardziej złożonych obiektów jak np:
pakiety, ograniczenia, przypadki użycia, aktorów, aspekty itd?

Interesuje mnie to dlatego, że gdy tworze projekt i chcę stworzyć sobie przed pisanie diagram UML to najczęściej jest to prowizorka mająca kilka podstawowych elementów wymienionych wcześniej w pierwszej części posta.

Inną sprawą jest jeszcze to, że chciałbym popatrzeć na UML różnych projektów. Istnieje jakaś strona udostępniająca coś takiego?
Są strony zbierające projekty OpenSource i można śmiało zajrzeć do kodu, ale czy można też gdzieś spojrzeć na sensowny szkic projektu jak np diagram UML?

Pozdrawiam.

Na www.topcoder.com mają własne narzędzie do UML. Na stronie często są konkursy na rozbudowę czegoś co już istnieje. Są wówczas udostępniane diagramy UML. Wszystko jest "z życia wzięte" więc możesz się zainteresować.

Ok dzięki.

A jak to wygląda w pracy?
Czy w projektach, które robicie rozbijacie wszystkie części na tak małe elementy jak np tutaj:
http://tempus.metal.agh.edu.pl/~regulski/dydaktyka/psk/cw/Stacja_narciarska-UML.pdf

Wygląda to na pracę studencką, bo pamiętam jak sam musiałem w zespole takie coś robić, ale sądzę, że to za dużo rozbijania i często niepotrzebnej pracy (po prostu do przesady rozbijanie projektu, czasami na elementy oczywiste wręcz). Jak to wygląda w pracy programisty na co dzień?

nigdy w ciągu całej mej profesjonalnej kariery nawet na chwilę nie przebąknął nikt "a może by tak w uml-u". Dlaczemu? Czasu nie ma. Ewentualnie bazowe rozplanowanie się robi, ale to tak daleki od uml że nawet nic wspólnego z tym nie ma.

Doskonale !
Po ciszy w tym topicu spodziewałem się właśnie, że UML w pracy nie jest przesadnie używany.
Właśnie takiej konkretnej odpowiedzi oczekiwałem. Albo w pracy tego wymagają i w jakim stopniu, albo nie.

Dziękuję za pomoc. Jeśli ktoś chciałby coś dodać lub napisać od siebie to bardzo proszę. Będę wdzięczny.

U nas też nie jest używany.

Jeśli jeszcze mogę zapytać to w takim razie jak wyglądają prace projektowania aplikacji?
No bo przy większym projekcie, gdzie jest klas parędziesiąt oraz baza danych posiada również mnóstwo tabel, jakieś analizy i projektowanie chyba ma miejsce?
Czy wygląda to tak, że:

• Cześć Piotr, masz wykonać takie coś by to łączyło się z tym, a tutaj klient chciałby mieć dodatkowo możliwość dodania nowych danych do tych wcześniejszych. Do tego dodaj w tej klasie kilka funkcjonalności zwiększających wydajność. Na koniec zaimplementuj możliwość dogrywania filmów wrzuconych na serwer.
  Taki Pan Piotr musi sam sobie wszystko wymyślić w głowie, gdzie, co i w jakiej klasie powinno się znaleźć oraz w jaki sposób obiekty mają ze sobą się porozumieć?

Czy może wygląda to tak:

• Cześć Piotr. W projekcie trzeba zaimplementować taka klasę. Tutaj masz prowizorkę zrobioną (na jakimkolwiek diagramie). Widzisz tutaj masz zmienną, tutaj obiekt, a tutaj to dziedziczy od tego. Na koniec postaraj się zrobić hermetyzację tak by wyglądała jak tu (kolejny diagram jakikolwiek).

Która wersja jest bliższa prawdy? Mógłby ktoś napisać jakąś podobną zmyśloną historyjkę jak to wygląda?
Bo wiem z natury, że tworzenie bez jakichkolwiek diagramów dużego projektu kończy się fiaskiem. Zazwyczaj czegoś się nie przewidzi, a z drugiej strony nie ma sensu i czasu tracić na zbędne humanistyczne wymysły i rozpisywanie rzeczy oczywistych.

Raczej żadna z tych dwóch wersji... jest coś pomiędzy.
Ja dostaję diagramy, które hm, czasem są "podobne" do uml, na których przedstawione mam raczej moduły niż klasy. Jest to jedynie poglądowe, a opieram się o opis, który jest zazwyczaj bardzo dokładny, a mówi, co ma dany moduł robić.

Diagram klas to mi się zdarzyło rysować raczej wtedy, gdy dla samej siebie chciałam się najpierw zastanowić jak to rozplanować. Wtedy to co powstanie ewentualnie dołączam do projektu (albo nie).

Wszystko jest raczej płynne, bo w trakcie realizacji prawie zawsze okazuje się, że coś trzeba zrobić inaczej niż było zakładane.

A ponoć w korpo się używa UML, siedzą ci wszyscy architekci i analitycy, i rysują szlaczki dla zwykłych programistów.

W mojej pracy najczęściej UML miał dużą rolę roboczą w komunikacji między analitykami a programistami. Chodzi tu o aplikacje "biznesowe" z dość dużym naciskiem na dokumentowanie wymagań i analitykami pracującymi na poziomie dość ścisłych konkretów, a nie stenotypistami strumienia świadomości klienta. ;) Typowe produkty UML-owe to diagram klas z modelem dziedziny, diagramy stanów dla klas z modelu dziedziny, diagramy przypadków użycia (ale te to w sumie obrazki dla przedszkolaków), jakieś modele procesów.
Natomiast dla programistów w tego rodzaju projektach na wstępnym etapie pracy bardziej liczy się świadomość użycia w rozwiązaniu konkretnych wzorców i specyfikacja interfejsów. Ze względu na wzorce projektowe, bardzo podobny zbiór diagramów w kółko by się powtarzał, więc w sumie nie ma sensu ich tworzyć. Oczywiście przy czymś trudniejszym ludzie coś tam sobie rysują na kartce, ale nie ma znaczenia, czy jest to nawet UML. Mogą być wymagania na robienie dokumentacji projektowej "po fakcie" i wtedy oczywiście wchodzą tam różne diagramy, ale często jest to użycie UML-a o charakterze kosmetycznym (w odróżnieniu od roboczego), bo prawie nikt na serio tej dokumentacji potem nie czyta.

Dziękuję bardzo wszystkim za odpowiedzi.
Osobiście zawsze uważałem UML za coś co powinno pomagać programiście, ale im dalej w las z tym UML i budowaniem schematów tym mniej to wszystko było dla mnie zrozumiałe, a sam kod był jakby sztuczny bo był machinalnie pisany bez żadnego myślenia nad kodem. Toteż osobiście mam taki stosunek, że:
UML stosować, ale tylko na tyle by ułatwiał on napisanie bardziej złożonych problemów. Nie przejmować się bardziej złożonymi aspektami tego języka (UML) tylko skupić się na tym by diagram ułatwiał napisanie sensownej aplikacji.

Dziękuję jeszcze raz za opisane przez Was sytuacje z życia. Sporo rozjaśniają one i dzięki nim można się dowiedzieć czego oczekiwać.

A ponoć w korpo się używa UML, siedzą ci wszyscy architekci i analitycy i rysują szlaczki dla zwykłych programistów.

I tak i nie. Duże firmy składają się z działów, zespołów, pracują nad wieloma projektami naraz. W różnych zespołach mogą obowiązywać zupełnie różne metodopatologie tworzenia aplikacji.
Właściwie to nie wiesz gdzie trafisz — nawet jeśli ci coś powiedzą na rozmowie, to po paru miesiącach mogą cię przenieść do innego projektu albo przyjdą nowe wytyczne z góry.

Diagram klas/ encji jest wg mnie trochę bez sensu, bo przecież można go wygenerować z kodu/ schematu bazy.

Dużą część UMLa mogą zastąpić "samodokumentujące się" testy, opisane w języku biznesowym. Patrz: http://dannorth.net/introducing-bdd/ i http://jbehave.org/

Na diagramach umieściłbym bardziej wysokopoziomowe rzeczy. W sumie jeśli ktoś siedzi wiele lat w jednym projekcie to czuję że raczej nie ma większego znaczenia w/ na czym ten diagram jest opisany. Ważne żeby spełniał swoją rolę :) UML to jednak standard i jeśli ktoś pozna UMLa to łatwiej mu się będzie wdrożyć w kolejny projekt jeśli diagramy będą w UMLu, a nie zrobione z palca.

W przeciwieństwie do testów jednostkowych (jak np JBehave powyżej) UMLa nie da się odpalić. Są narzędzia np do sprawdzania pokrycia kodu testami, ale wątpię, żeby było narzędzie sprawdzające pokrycie kodu UMLem (w szczególności diagram klas można z kodu wygenerować, więc nie ma sensu go sprawdzać). Dlatego myślę, że programiści będą olewać rozbudowywanie UMLi. No chyba, że będą wydzielone osoby, które będą zajmować się UMLem, a nie kodowaniem.

Duze projekty - UML TAK
male projekty - UML NIEKONIECZNIE

gwarantuje Wam, ze jak pojdziecie szukac pracy i dostaniecie jakies zadanie do zakodzenia jako sprawdzenie Was, to UML tez bedzie do zrobienia.

hutrysuej napisał(a)

gwarantuje Wam, ze jak pojdziecie szukac pracy i dostaniecie jakies zadanie do zakodzenia jako sprawdzenie Was, to UML tez bedzie do zrobienia.

Chcesz się o to założyć?

up

widocznie nie pracowales przy duzym projekcie, a model obiektow narysowales na kolanie.
:)

Diagram klas/ encji jest wg mnie trochę bez sensu, bo przecież można go wygenerować z kodu/ schematu bazy.
Albo kod z diagramu, ale to jest upierdliwe gdy chcesz robić większe zmiany w kodzie. Niestety, czasami kolejność działania jest taka: rysujesz diagram, a z diagramu generuje ci klasy z pustymi metodami do ręcznego wypełnienia.

Duze projekty - UML TAK
Pytanie tylko: jak duże. Mnie się wydaje, że żaden projekt nie jest wystarczająco duży, by się w to bawić: a jeśli jest, to znaczy że jest za duży, i należałoby podzielić go na 10 mniejszych.

Miałem do czynienia z takim projektem "full wypas UML" i wg. mnie to strata czasu: ścisłe rysowanie diagramów do wszystkiego powoduje podwójną pracę — cały program istnieje w dwóch formalnie równoważnych wersjach: na diagramach UML i w języku programowania, co w ekstremalnym przypadku staje się odpowiednikiem komentowania każdej linii kodu: i++; // zwiększ i

No ale czasami jest po prostu wymóg.

inzynieria oprogramowania, poczytajcie :)

hutrysuej napisał(a)

widocznie nie pracowales przy duzym projekcie, a model obiektow narysowales na kolanie.

Byłem już na kilku rozmowach kwalifikacyjnych w życiu, jeszcze na żadnej nie dostałem zadania z UML, więc na Twoim miejscu niczego bym nie gwarantował.
Po prostu uczelniana inżynieria oprogramowania rozmija się z rzeczywistością.

Azarien napisał(a)

Miałem do czynienia z takim projektem "full wypas UML" i wg. mnie to strata czasu: ścisłe rysowanie diagramów do wszystkiego powoduje podwójną pracę — cały program istnieje w dwóch formalnie równoważnych wersjach: na diagramach UML i w języku programowania, co w ekstremalnym przypadku staje się odpowiednikiem komentowania każdej linii kodu: i++; // zwiększ i.

Moim zdaniem, dla programisty, sens mają fragmentaryczne diagramy tabel i klas (diagram całości, w którym jest np. wszystkie 200 tabel z bazy jest po prostu nie do ogarnięcia) oraz diagramy czynności, w przypadku jakichś bardziej złożonych operacji.
Ale dla jakiegoś kierownika sens przyszłościowy może mieć istnienie całej dokumentacji, żeby mogli się z nią zapoznawać nowi członkowie projektu.

W ostatecznym rozrachunku jak zwykle chodzi o pieniądze.
Czas spędzony nad projektem to koszt. Dany projekt przyniesie też oczywiście określony zysk przychód, jednakże trzeba uważać, by koszt nie przerósł zysku przychodu... Dlatego też na dany projekt jest przydzielone tyle a tyle godzin.
Jasne, dobrze jest sobie zrobić choćby poglądowy diagramik systemu - takich widzę dużo i często, bo szybciej jest sobie rozrysować, niż opisywać słowami. Ale w pewnym momencie zarys i idea programu są już opisane zrozumiale, stopień szczegółów pozostałych do opracowania jest już taki, że sprawniej będzie przygotować prototyp i zapytać, czy to o to chodziło.
Tak jest po prostu szybciej, a to się przekłada na pieniądze.

IMHO UML jest dobry jako dokumentacja do istniejącego już projektu (chociążby do prostszego wyjaśnienia jak jest zbudowany i jak działa nowym osobom). Rozpoczynanie projektu od diagramu klas raczej bardzo nie pomaga.
Na kilku rozmowach też byłem, tylko na jednej pytali mnie o strzałki w jakimś tam diagramie UMLowym (nikt nie kazał mi samemu rysować).