Czy UML jest praktyczny? [Zamknięte]

Na studiach miałem wiele kursów projektowania i zorientowanych na UML i zdaję sobie sprawę, że UML może być wykorzystany do wspierania projektów oprogramowania, zwłaszcza mapowania przypadków użycia , ale czy jest to naprawdę praktyczne? Zrobiłem kilka warunków pracy w trybie współpracy i wygląda na to, że UML nie jest intensywnie używany w branży. Czy w trakcie projektu warto tworzyć diagramy UML? Uważam również, że diagramy klas są generalnie nieprzydatne, ponieważ po prostu szybciej jest spojrzeć na plik nagłówkowy klasy. W szczególności, które diagramy są najbardziej przydatne?

Edycja: Moje doświadczenie jest ograniczone do małych projektów deweloperskich poniżej 10 lat.

Edycja: Wiele dobrych odpowiedzi i choć nie są to najbardziej szczegółowe, uważam, że ta wybrana jest najbardziej wyważona.

W wystarczająco złożonym systemie są miejsca, w których niektóre UMLsą uważane za przydatne.

Przydatne diagramy dla systemu różnią się w zależności od zastosowania.
Ale najczęściej używane to:

• Diagramy klas
• Diagramy stanów
• Diagramy aktywności
• Diagramy sekwencji

Jest wiele przedsiębiorstw, które przysięgają na nich, i wielu z nich wprost odrzuca je jako całkowitą stratę czasu i wysiłku.

Najlepiej nie przesadzać i nie myśleć, co jest najlepsze dla projektu, w którym się znajdujesz, i wybierać rzeczy, które mają zastosowanie i mają sens.

Używanie UML jest jak patrzenie na swoje stopy podczas chodzenia. To świadome i wyraźne tworzenie czegoś, co zwykle można zrobić nieświadomie. Początkujący muszą dokładnie przemyśleć to, co robią, ale profesjonalny programista już wie, co robią. W większości przypadków samo pisanie kodu jest szybsze i bardziej efektywne niż pisanie o kodzie, ponieważ intuicja programistyczna jest dostosowana do zadania.

Nie chodzi jednak tylko o to, co robisz. A co z nowym pracownikiem, który pojawi się za sześć miesięcy i musi szybko wprowadzić kod? A co za pięć lat, kiedy wszyscy pracujący nad projektem znikną?

Niezwykle pomocne jest posiadanie podstawowej, aktualnej dokumentacji dostępnej dla każdego, kto później dołączy do projektu. Nie opowiadam się za pełnoprawnymi diagramami UML z nazwami metod i parametrami (o wiele za trudne w utrzymaniu), ale uważam, że podstawowy diagram komponentów w systemie wraz z ich relacjami i podstawowym zachowaniem jest nieoceniony. O ile projekt systemu nie zmieni się drastycznie, informacje te nie powinny się zbytnio zmieniać, nawet gdy implementacja jest modyfikowana.

Odkryłem, że kluczem do dokumentacji jest umiar. Nikt nie przeczyta 50 stron pełnowymiarowych diagramów UML z dokumentacją projektową bez zasypiania kilku stron. Z drugiej strony, większość ludzi chciałaby otrzymać 5-10 stron prostych diagramów klas z podstawowymi opisami tego, jak system jest złożony.

Innym przypadkiem, w którym okazało się, że UML jest przydatny, jest sytuacja, gdy starszy programista jest odpowiedzialny za zaprojektowanie komponentu, ale następnie przekazuje projekt młodszemu programistowi do wdrożenia.

Używanie UML jest jak patrzenie na swoje stopy podczas chodzenia. To świadome i wyraźne tworzenie czegoś, co zwykle można zrobić nieświadomie. Początkujący muszą dokładnie przemyśleć to, co robią, ale profesjonalny programista już wie, co robią. W większości przypadków samo pisanie kodu jest szybsze i bardziej efektywne niż pisanie o kodzie, ponieważ intuicja programistyczna jest dostosowana do zadania.

Wyjątkiem jest to, że znajdujesz się w lesie w nocy bez latarki i zaczęło padać - wtedy musisz patrzeć pod nogi, aby nie spaść. Są chwile, kiedy zadanie, którego się podjąłeś, jest bardziej skomplikowane niż twoja intuicja może obsłużyć i musisz zwolnić i wyraźnie określić strukturę swojego programu. W takim razie UML jest jednym z wielu narzędzi, z których możesz korzystać. Inne obejmują pseudokod, diagramy architektury wysokiego poziomu i dziwne metafory.

Ogólny przepływ pracy i DFD mogą być bardzo przydatne w przypadku złożonych procesów. Z mojego doświadczenia wynika, że ​​wszelkie inne tworzenie diagramów (ZWŁASZCZA UML) bez wyjątku było bolesną stratą czasu i wysiłku.

Muszę się nie zgodzić, UML jest używany wszędzie - wszędzie tam, gdzie projekt IT jest projektowany, UML zwykle tam będzie.

Teraz, czy jest dobrze używany, to inna sprawa.

Jak powiedział Stu, uważam, że zarówno przypadki użycia (wraz z opisami przypadków użycia), jak i diagramy aktywności są najbardziej pomocne z punktu widzenia programisty.

Diagram klas może być bardzo przydatny podczas próby pokazania relacji, a także atrybutów obiektów, takich jak trwałość. Jeśli chodzi o dodawanie pojedynczego atrybutu lub właściwości, zwykle są one przesadą, zwłaszcza że często szybko tracą aktualność po napisaniu kodu.

Jednym z największych problemów związanych z UML jest ilość pracy wymaganej do utrzymania jego aktualności po wygenerowaniu kodu, ponieważ istnieje niewiele narzędzi, które mogą przeprojektować UML z kodu, a nadal niewiele robi to dobrze.

Kwalifikuję swoją odpowiedź, wspominając, że nie mam doświadczenia w dużych korporacyjnych środowiskach programistycznych (podobnych do IBM).

Sposób, w jaki postrzegam UML i Rational Unified Process, polega na tym, że bardziej ROZMOWA o tym, co zamierzasz zrobić, niż faktycznie ROBIĆ to, co zamierzasz zrobić.

(Innymi słowy, jest to w dużej mierze strata czasu)

Wyrzuć tylko moim zdaniem. UML to świetne narzędzie do komunikowania pomysłów, jedynym problemem jest to, kiedy go przechowujesz i utrzymujesz, ponieważ zasadniczo tworzysz dwie kopie tych samych informacji i właśnie tam zwykle się to wydarza. Po początkowej rundzie implementacji większość UML powinna zostać wygenerowana z kodu źródłowego, w przeciwnym razie bardzo szybko straci on aktualność lub będzie wymagał dużo czasu (z ręcznymi błędami), aby był na bieżąco.

Przez ostatnie dwa semestry w szkole współprowadziłem projekt rozwojowy dla seniorów. Projekt miał być używany w środowisku produkcyjnym z lokalnymi organizacjami non-profit jako klientami płacącymi. Musieliśmy mieć pewność, że kod robi to, czego się spodziewaliśmy i że uczniowie wychwytują wszystkie dane niezbędne do zaspokojenia potrzeb klientów.

Czas zajęć był ograniczony, podobnie jak mój czas poza salą. W związku z tym musieliśmy przeprowadzać przeglądy kodu na każdym spotkaniu klasowym, ale przy zapisanych 25 uczniach czas na indywidualną recenzję był bardzo krótki. Narzędziem, które uznaliśmy za najbardziej wartościowe w tych sesjach przeglądowych, były ERD, diagramy klas i diagramy sekwencji. Diagramy ERD i diagramy klas były wykonywane tylko w Visual Studio, więc czas potrzebny na ich stworzenie był dla studentów trywialny.

Diagramy bardzo szybko przekazały wiele informacji. Mając szybki przegląd projektów uczniów, mogliśmy szybko wyodrębnić obszary problemowe w ich kodzie i przeprowadzić bardziej szczegółową recenzję na miejscu.

Bez korzystania z diagramów musielibyśmy poświęcić czas na przejrzenie plików kodu uczniów w poszukiwaniu problemów.

Podchodzę do tego tematu trochę późno i spróbuję tylko wyjaśnić kilka drobnych punktów. Pytanie, czy język UML jest przydatny, o ile jest zbyt szeroki. Większość ludzi zdawała się odpowiadać na to pytanie z perspektywy typowego / popularnego UML jako narzędzia do rysowania / komunikacji. Uwaga: Martin Fowler i inni autorzy książek UML uważają, że UML najlepiej nadaje się tylko do komunikacji. Jednak istnieje wiele innych zastosowań języka UML. Przede wszystkim UML jest językiem modelowania, który ma notację i diagramy odwzorowane na koncepcje logiczne. Oto kilka zastosowań UML:

• Komunikacja
• Standaryzowana dokumentacja projektu / rozwiązania
• Definicja DSL (język specyficzny dla domeny)
• Definicja modelu (profile UML)
• Wykorzystanie wzorca / zasobu
• Generowanie kodu
• Model do transformacji modelu

Biorąc pod uwagę listę zastosowań powyżej, opublikowanie przez Pascala nie jest wystarczające, ponieważ mówi tylko o tworzeniu diagramu. Projekt może odnieść korzyści z UML, jeśli którykolwiek z powyższych czynników jest krytycznymi czynnikami sukcesu lub są obszarami problemowymi wymagającymi znormalizowanego rozwiązania.

Dyskusja powinna rozwinąć się od tego, jak UML może być nadmiernie zabijany lub stosowany w małych projektach, aby omówić, kiedy UML ma sens lub faktycznie ulepszy produkt / rozwiązanie, ponieważ wtedy należy używać UML. Istnieją sytuacje, w których UML dla jednego programisty również może wyczuć, na przykład aplikacja wzorców lub generowanie kodu.

UML pracował dla mnie od lat. Kiedy zaczynałem, przeczytałem UML Distilled Fowlera, w którym mówi „zrób wystarczająco modelowania / architektury / itp.”. Po prostu użyj tego, czego potrzebujesz !

Z punktu widzenia inżyniera zapewniania jakości diagramy UML wskazują na potencjalne błędy w logice i sposobie myślenia. Ułatwia mi pracę :)

Myślę, że UML jest przydatny, myślę, że specyfikacja 2.0 sprawiła, że ​​to, co kiedyś było jasną specyfikacją, było nieco rozdęte i uciążliwe. Zgadzam się z edycją diagramów czasowych itp., Ponieważ wypełniły one pustkę ...

Nauka efektywnego korzystania z UML wymaga trochę praktyki. Najważniejszą kwestią jest jasna komunikacja, modelowanie w razie potrzeby i modelowanie jako zespół. Tablice są najlepszym narzędziem, jakie znalazłem. Nie widziałem żadnego „oprogramowania do tablicy cyfrowej”, które potrafiłoby uchwycić użyteczność rzeczywistej tablicy.

Mimo to podoba mi się następujące narzędzia UML:

1. Fiolet - gdyby było prostsze, byłaby to kartka papieru

2. Altova UModel - Dobre narzędzie do modelowania Java i C #

3. MagicDraw - Moje ulubione komercyjne narzędzie do modelowania

4. Poseidon - przyzwoite narzędzie z dobrym hukiem za grosze

5. StarUML - Najlepsze narzędzie do modelowania open source

Diagramy UML są przydatne do przechwytywania i komunikowania wymagań oraz upewnienia się, że system spełnia te wymagania. Mogą być używane iteracyjnie i na różnych etapach planowania, projektowania, rozwoju i testowania.

Z tematu: Korzystanie z modeli w procesie programowania pod adresem http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Model może pomóc w wizualizacji świata, w którym działa Twój system, wyjaśnieniu potrzeb użytkowników, zdefiniowaniu architektury systemu, analizie kodu i upewnieniu się, że Twój kod spełnia wymagania.

Możesz również przeczytać moją odpowiedź na następujący post:

Jak nauczyć się „dobrego projektowania / architektury oprogramowania”? pod adresem /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Chociaż ta dyskusja była od dawna nieaktywna, mam kilka - moim zdaniem ważnych - punktów do dodania.

Kod błędny to jedno. Błędy projektowe mogą stać się bardzo rozdęte i brzydkie. Jednak UML sprawdza się samoczynnie. Rozumiem przez to, że umożliwiając badanie modeli w wielu matematycznie zamkniętych i wzajemnie sprawdzających się wymiarach, zapewnia solidną konstrukcję.

UML ma jeszcze jeden ważny aspekt: ​​„mówi” bezpośrednio o naszych najsilniejszych zdolnościach, czyli wizualizacji. Gdyby na przykład ITIL V3 (w sercu dość prosty) został zakomunikowany w postaci diagramów UML, mógłby zostać opublikowany na kilkudziesięciu rozkładówkach A3. Zamiast tego ukazało się w kilku tomach o prawdziwie biblijnych proporcjach, dając początek całej branży, zapierające dech w piersiach koszty i powszechny szok katatoniczny.

Widzę diagramy sekwencji i diagramy aktywności używane dość często. Dużo pracuję z systemami „czasu rzeczywistego” i systemami wbudowanymi, które współdziałają z innymi systemami, a diagramy sekwencji są bardzo pomocne w wizualizacji wszystkich interakcji.

Lubię tworzyć diagramy przypadków użycia, ale nie spotkałem zbyt wielu ludzi, którzy uważają, że są wartościowi.

Często zastanawiałem się, czy Rational Rose jest dobrym przykładem rodzajów aplikacji, które można uzyskać dzięki projektowaniu opartemu na modelu UML. Jest nadęty, powolny, brzydki ...

Uważam, że UML nie jest zbyt przydatny w bardzo małych projektach, ale naprawdę nadaje się do większych.

Zasadniczo nie ma znaczenia, czego używasz, wystarczy pamiętać o dwóch rzeczach:

• Chcesz jakiegoś planowania architektury
• Chcesz mieć pewność, że wszyscy w zespole faktycznie używają tej samej technologii do planowania projektów

Tak więc UML to po prostu: standard planowania projektów. Jeśli zatrudniasz nowych ludzi, istnieje większe prawdopodobieństwo, że znasz jakiś istniejący standard - czy to UML, Flowchard, Nassi-Schneiderman, czy cokolwiek - niż dotychczasowe wewnętrzne rzeczy.

Używanie UML dla jednego programisty i / lub prostego projektu oprogramowania wydaje mi się przesadą, ale pracując w większym zespole, zdecydowanie chciałbym mieć jakiś standard oprogramowania do planowania.

UML jest przydatny, rzeczywiście! Główne zastosowania, które go wykorzystałem, to:

• Burza mózgów na temat tego, jak powinno działać oprogramowanie. Ułatwia przekazywanie tego, o czym myślisz.
• Dokumentowanie architektury systemu, jego wzorców i głównych relacji między jego klasami. Pomaga, gdy ktoś wchodzi do twojego zespołu, kiedy odchodzisz i chcesz mieć pewność, że twój następca to zrozumie, i kiedy w końcu zapomnisz, do czego, do diabła, była przeznaczona ta mała klasa.
• Dokumentowanie dowolnego wzoru architektonicznego, którego używasz we wszystkich swoich systemach, z tych samych powodów, które przedstawiono powyżej

Nie zgadzam się z Michaelem tylko wtedy, gdy mówi, że używanie UML dla jednego programisty i / lub prostego projektu oprogramowania wydaje mu się przesadą . Używałem go w moich małych, osobistych projektach i udokumentowanie ich za pomocą UML zaoszczędziło mi dużo czasu, kiedy wróciłem do nich siedem miesięcy później i całkowicie zapomniałem, jak zbudowałem i złożyłem wszystkie te zajęcia.

Uważam, że może istnieć sposób na wykorzystanie ryb, latawców i przypadków użycia na poziomie morza w stylu Cockburn, jak opisano przez Fowlera w jego książce „UML Distilled”. Moim pomysłem było wykorzystanie przypadków użycia Cockburn jako pomocy dla czytelności kodu.

Zrobiłem więc eksperyment i jest tutaj post o tym z tagiem „UML” lub „FOWLER”. To był prosty pomysł na c #. Znajdź sposób na osadzenie przypadków użycia Cockburn w przestrzeniach nazw konstrukcji programistycznych (takich jak przestrzenie nazw klas i klas wewnętrznych lub wykorzystując przestrzenie nazw do wyliczeń). Uważam, że może to być wykonalna i prosta technika, ale nadal mam pytania i potrzebuję innych, aby to sprawdzić. Może to być dobre dla prostych programów, które wymagają pewnego rodzaju języka specyficznego dla domeny, który może istnieć w środku kodu C # bez żadnych rozszerzeń językowych.

Jeśli jesteś zainteresowany, sprawdź post. Idź tutaj .

Jednym z problemów, które mam z UML, jest zrozumiałość specyfikacji. Kiedy próbuję naprawdę zrozumieć semantykę konkretnego diagramu, szybko gubię się w labiryncie meta-modeli i meta-meta-modeli. Jedną z zalet UML jest to, że jest mniej niejednoznaczny niż język naturalny. Jeśli jednak dwóch lub więcej inżynierów inaczej zinterpretuje diagram, nie osiągnie celu.

Próbowałem także zadawać konkretne pytania dotyczące dokumentu superstruktury na kilku forach UML oraz członkom samego OMG, z niewielkim lub żadnym rezultatem. Nie sądzę, by społeczność UML była jeszcze wystarczająco dojrzała, aby się utrzymać.

Jako student stwierdzam, że UML ma bardzo małe zastosowanie. Uważam za ironię, że PROGAMERZY nie opracowali jeszcze programu, który będzie automatycznie generował rzeczy, o których powiedziałeś, że są konieczne. Byłoby niezwykle proste zaprojektowanie funkcji w programie Visual Studio, która mogłaby pobierać fragmenty danych, wyszukiwać definicje i odpowiedzi dotyczące produktów na tyle, aby każdy mógł na nią spojrzeć, niezależnie od tego, czy jest duży czy mały, i zrozumieć program. Zapewniłoby to również jego aktualność, ponieważ wygenerowałoby informacje bezpośrednio z kodu.

UML jest używany, gdy tylko przedstawisz klasę z jej polami i metodami, chociaż jest to tylko rodzaj diagramu UML.

Problem z UML polega na tym, że książka założycieli jest zbyt ogólnikowa.

UML to tylko język, a nie metoda.

Jeśli chodzi o mnie, naprawdę denerwuje mnie brak schematu UML dla projektów Opensource. Weź coś takiego jak Wordpress, po prostu masz schemat bazy danych, nic więcej. Musisz wędrować po api kodeksu, aby uzyskać pełny obraz.

UML ma swoje miejsce. Wraz ze wzrostem wielkości projektu staje się to coraz ważniejsze. Jeśli masz długo działający projekt, najlepiej udokumentować wszystko w UML.

UML wydaje się być dobry dla dużych projektów z dużymi zespołami ludzi. Jednak pracowałem w małych zespołach, w których komunikacja jest lepsza.

Korzystanie z diagramów w stylu UML jest jednak dobre, zwłaszcza na etapie planowania. Zwykle myślę w kodzie, więc pisanie dużych specyfikacji jest trudne. Wolę zapisywać dane wejściowe i wyjściowe i zostawiać programistom zaprojektowanie bitu w środku.

Uważam, że UML jest użyteczny tylko dlatego, że skłania ludzi do myślenia o relacjach między ich klasami. To dobry punkt wyjścia, aby zacząć myśleć o takich związkach, ale zdecydowanie nie jest to rozwiązanie dla wszystkich.

Uważam, że użycie UML jest subiektywne w stosunku do sytuacji, w której pracuje zespół programistów.

Z mojego doświadczenia:

Umiejętność tworzenia i przekazywania znaczących diagramów kodu jest niezbędną umiejętnością dla każdego inżyniera oprogramowania, który opracowuje nowy kod lub próbuje zrozumieć istniejący kod.

Znajomość specyfiki UML - kiedy używać linii przerywanej lub punktu końcowego koła - nie jest tak konieczna, ale nadal dobrze jest ją mieć.

UML jest przydatny na dwa sposoby:

• Strona techniczna: wiele osób (menedżer i niektórzy analitycy funkcjonalni) uważa, że ​​UML to funkcja luksusowa, ponieważ kod jest dokumentacją: zaczynasz kodować, po debugowaniu i naprawianiu . Synchronizacja diagramów UML z kodem i analizami wymusza dobre zrozumienie żądań klienta;

• Strona zarządzania: diagramy UMl są odzwierciedleniem wymagań klienta, który jest niedokładny: jeśli kodujesz bez UML, być może po wielu godzinach pracy możesz znaleźć błąd w wymaganiach. Diagramy UML pozwalają znaleźć możliwe kontrowersyjne punkty i rozwiązać przed kodowaniem => pomóc w planowaniu.

Generalnie wszystkie projekty bez diagramów UML mają powierzchowną analizę lub mają niewielki rozmiar.

Jeśli jesteś w grupie linkedin INŻYNIEROWIE SYSTEMÓW , zobacz moją starą dyskusję .

Ostatecznie UML istnieje tylko dzięki RUP. Czy do korzystania z Java / .Net potrzebujemy UML lub innych powiązanych elementów? Praktyczna odpowiedź brzmi: mają własną dokumentację (javadoc itp.), Która jest wystarczająca i pozwala nam wykonać naszą pracę!

UML no thanx.

UML jest zdecydowanie pomocny, tak jak niezbędny jest junit. Wszystko zależy od tego, jak sprzedasz pomysł. Twój program będzie działał bez UML, tak jak działałby bez testów jednostkowych. Powiedziawszy to, powinieneś utworzyć do UML, ponieważ jest on połączony z twoim kodem, tj. Kiedy aktualizujesz diagramy UML, aktualizuje on twój kod, lub gdy aktualizujesz kod, automatycznie generuje UML. Nie rób tego tylko dla samego robienia tego.

UML z pewnością ma swoje miejsce w branży. Wyobraź sobie, że tworzysz oprogramowanie dla samolotu Boing lub innego złożonego systemu. UML i RUP byłyby tutaj bardzo pomocne.

UML to tylko jedna z metod komunikacji między ludźmi. Tablica jest lepsza.