Jak często używasz Formalnego UMLa?

Użyłem ad-hoc MUML (wymyślonego języka modelowania) do dość częstego projektowania i wyjaśniania systemu. Wygląda podobnie do UML i wydaje się być całkiem dobrze zrozumiany.

Jednak miałem profesora lub dwóch, którzy starali się stosować ścisłe, formalne UML, jak najbliżej specyfikacji. Zawsze podejrzewałem, że ścisłe UML nie było tak powszechne, jak twierdzili. A co powiesz na to - jak często rysujesz kompletne diagramy zawierające wszystkie właściwe zakończenia linii, wielokrotność, symbole typu członka itp.?

Nigdy.

Heck, to już rok, odkąd ostatni stworzył żadnego UML. Schematy liniowe na tablicach i skrawkach papieru się nie liczą.

W rzeczywistości właśnie usunęliśmy jedno pytanie UML z przewodnika, którego używamy podczas wywiadów, ponieważ nikt z nas tak naprawdę nie przejmował się odpowiedziami.

Używam tylko wystarczającej liczby języków UML (zarówno pod względem typów diagramów, jak i treści informacji na diagramie), aby uzyskać punkt, który pozwala mi lub innej osobie wdrożyć system lub podsystem. I jedynym powodem, dla którego używam UML jest to, że jest to powszechnie znany zestaw symboli, z których każdy oznacza coś bardzo konkretnego, więc nie ma dwuznaczności - każdy inżynier oprogramowania powinien być w stanie spojrzeć na diagram i zrozumieć, co próbuję powiedzieć o system.

Jak na ironię, UML ma być elastyczny.

W realnym świecie, to nie ma być pedantyczny ćwiczenie robi to jeden właściwy sposób. Chodzi o skuteczne komunikowanie i dokumentowanie systemu / procesu / pomysłu.

Aby odpowiedzieć na twoje pytanie, jestem z innymi. Nigdy nie korzystałem w pełni z formalnego UML.

Używam UML bardzo regularnie przez około cztery lata w przypadku produktu, który wygenerował wszystkie (większość) szkieletów kodu z produktu Rational Rose.

W ciągu ostatnich pięciu lat pojawiło się więcej „pudełek i strzał” wymyślonych głównie na miejscu i zwykle wystarczających, aby przekazać ogólny pomysł. Formalnie popraw UML tylko kilka razy w tym czasie.

Jednak miałem profesora lub dwóch, którzy starali się stosować ścisłe, formalne UML, jak najbliżej specyfikacji.

Zapytaj swojego profesora, kiedy ostatni raz zastosował to podejście w prawdziwym systemie. Poważnie.

Staram się być tak formalny, jak to możliwe, jeśli chodzi o UML, ale tylko wtedy, gdy ma to sens. Zeloci po obu stronach spektrum (od kowbojów po uczciwych formalistów) tego nie rozumieją.

Istnieją konteksty, w których mniej sztywne podejście (takie jak to, którego osobiście używasz) jest najlepszym rozwiązaniem. Dobrym przykładem są małe systemy lub zmiany, w których wymagania są małe i nie w pełni zdefiniowane; grupa odpowiedzialna jest wydajna i skuteczna; ważniejsze jest, aby go wydobyć niż zrobić to idealnie. Odbywa się to iteracyjnie, a niektóre braki są dopuszczalne.

A może jesteś na etapie, w którym robisz gościnę i szkicujesz, a nie pełną fazę formalnego modelowania. To są przykłady, które przychodzą na myśl.

W innych przypadkach potrzebujesz sztywnego formalnego podejścia do języka UML. Na przykład możesz być związany umową; masz bardzo dużą liczbę programistów w wielu zespołach (prawdopodobnie rozproszonych); zakres projektu może być za lata; jest to bardzo duży system (w tym komponenty oprogramowania i sprzętu); koszt awarii jest wysoki itp.

Innym razem musisz użyć czegoś innego zamiast / oprócz UML (rzeczywiste matematyczne modele formalne, takie jak sieci petri, CSP lub logika czasowa). Przykładem tego są systemy czasu rzeczywistego, systemy, w których awarie są katastrofalne (urządzenia medyczne) lub gdzie jesteś związany umową (np. jak w Europie podczas opracowywania systemów transportu)

Wszystko zależy od okoliczności i tego, czego oczekujemy od każdego podejścia. Profesor, który usiłuje trzymać się formalności, jest po prostu ślepym fanatykiem. Świat inżynierii nie jest czarno-białą, właściwą / złą dychotomią. To świat inteligentnych kompromisów.

Jeśli jesteś wystarczająco inteligentny, aby zastosować przypadkowy, nieformalny model w sposób skuteczny i odpowiedni do wykonania pracy, niech tak będzie. Z tego samego powodu będziesz musiał rozpoznać, kiedy NIE należy stosować podejścia nieformalnego i / lub kiedy NIE należy stosować formalnego.

Powiedziawszy to, musisz grać na głos z profesorami. Daj im kość, aby dali ci ocenę, a jeśli to oznacza w końcu ukłonić się ich gorliwej mantrze, to w porządku. Wiesz, co dla Ciebie działa, i mam nadzieję, że będziesz wiedział, kiedy i czego używać w prawdziwym świecie.

W ramach moich badań doktoranckich badałem, jak doświadczeni projektanci używają UML we współpracy przy projektowaniu (chociaż w sztucznych warunkach).

Moje ustalenia były takie, że metafory i zapisy UML są zapożyczone, ale przestrzeganie ścisłości narzędzi jest niewielkie.

Później niektóre modele mogą być iteracyjnie przekształcane w bardziej rygorystyczny UML, często gdy wymagane jest wymagające narzędzie CASE do generowania kodu.

Oczywiście obowiązują zwykłe zastrzeżenia dotyczące badań akademickich :)

Link do streszczenia i samego papieru (jeśli nie masz dostępu do ACM) .

Poza tym gorąco polecam „Agile Modeling” Amblera.

Używamy formalnego UML do generowania kodu hibernacji ORM. Większość innych rzeczy to nieformalne lub biała tablica. Jest to dla nas ważne tylko przy generowaniu kodu, ponieważ złamałby go brak formalności.

Zależy to od branży, w której się znajdujesz. Jeśli pracujesz dla klientów, którzy wymagają częstych przeglądów technicznych (np. PDR, CDR itp.), Wtedy wolą jakiś rodzaj standaryzacji niż systemy notacyjne ad-hoc. W szczególności praca rządowa. Zapobiega to nieporozumieniom i wstępnemu 15-minutowemu wyjaśnieniu wymyślonego przez ciebie zapisu.

Również fakt, że używasz UML, nie oznacza, że ​​musisz kropkować każde i i przecinać każde t zgodnie ze standardem. Dzieje się tak tylko wtedy, gdy chcesz wykonać jakieś automatyczne generowanie / wykonywanie kodu. Nie znam nikogo, kto zrobiłby to dla więcej niż 1 projektu.

Z drugiej strony, jeśli pracujesz dla swojej firmy tylko z zespołem własnych programistów, to kogo obchodzi, jakiej notacji używasz. Jeśli jednak wybierzesz odpowiednie narzędzie, może to być oszczędność czasu rzeczywistego.

Biorąc to wszystko pod uwagę, trudno będzie sobie radzić w niektórych branżach bez możliwości projektowania za pomocą UML. W innych branżach nigdy tego nie zobaczysz.

Sądzę również, że znajdziesz korelację między tymi branżami, które wymagają poprawnego zaprojektowania, ponieważ koszty korekty są odpowiednio wysokie, ponieważ są dużymi użytkownikami UML; w porównaniu z branżami, w których koszty poprawek projektu są niewiele większe niż zmiany dokumentacji / kodu, ponieważ są to miejsca, w których prawdopodobnie nigdy nie używa się UML.

W odniesieniu do pierwotnego pytania. Większość szkół zazwyczaj przygotowuje szkolenia swoich studentów dla firm, które najczęściej rekrutują ich studentów. Jeśli profesor uważa, że ​​UML jest ważny, nie zdziwiłbym się, że wiele firm rekrutujących się z twojej szkoły używa UML. Dlatego powinieneś nauczyć się z niego korzystać.

Kiedy czytałem o UML, wypróbowałem to na wszystkich problemach, które miałem rozwiązać na moim kursie C ++. Na szczęście jednym z pierwszych przykładów, które próbowałem, było opisanie połączonej listy.
Nie działało
To powiedziawszy, w połączeniu z dobrym procesem modelowania przydatny jest UML. Tylko dlatego, że jest to lepszy lub gorszy standard.
Bardzo chciałbym zobaczyć język opisu meta programowania szablonów. Myślę, że to bardzo pomogłoby zrozumieć, co się dzieje w kraju <<<>>>

UML jest bolesny, jeśli spróbujesz również programowania opartego na modelu. Mam na myśli, że UML jest bardzo użyteczną tylko notacją graficzną, a wszystko inne jest bezużyteczne. Nie wydaje się na modelowanie, ale używam UML każdego dnia, aby stworzyć strukturę moich projektów. To, co robię, to szybko narysować podstawowy schemat przypadków użycia na poziomach wymagań, a następnie natychmiast przejść do diagramów klas. Dodam śledzenie wymagań między diagramami przypadków użycia i klas. Mój diagram klas tworzy również kod, ponieważ jest zsynchronizowany na żywo. W kodzie nie ma znacznika, wszystkie modele są zapisywane w modelu UML, który jest odwzorowany na projekt Java.

Szkielet mojej aplikacji tworzę za pomocą kilku diagramów klas, a następnie przełączam się na kod. Po zakończeniu kodu scalam go z modelem. Jest to rodzaj iteracji między kodem a modelem, w którym kod uruchamia model. Zatem diagramy klas dają mi wyższy poziom abstrakcji i kodu, podczas gdy mój kod zapewnia mi implementację logiki biznesowej (np. Metody).

Modelowanie UML wymaga mniej niż 10 minut dziennie, co jest wykonywane, gdy potrzebuję czasu, aby przemyśleć, co muszę rozwinąć i jak.

UML jest świetny, fantastyczny i bardzo przydatny, ale rozwój oparty na modelach jest bezużyteczny !!

Jeśli dokumentuję system, który wdrożyliśmy, staram się go ustanowić przy użyciu pełnego formalnego języka UML. Ale przez resztę czasu używam tylko tyle, ile jest konieczne, aby zrealizować ten pomysł. Uważam też, że używam więcej DFD niż UML, ponieważ wydają się one bardziej odpowiednie dla systemów, które ostatnio projektujemy.

Właśnie porzuciłem naukę na moim najwyżej położonym uniwersytecie (przynajmniej tymczasowo) z powodu ich sztywnego nalegania na nadmiernie czasochłonne działania związane z modelowaniem wizualnym, obowiązkami na forum, nadmiernie zbędnymi umiejętnościami miękkimi, które każdy, kto dorastał wokół komputerów lub kiedykolwiek rozglądał się z namysłem w kierunku interfejsu użytkownika dostatecznie dobrze, że myśl o głębokim zadłużeniu sprawiłaby, że ktoś chciałby załamać wszystko w całkowitej frustracji.

Musiałem wybierać między nauczeniem się, co widziałem jako wymagające na poziomie podstawowym i młodszym, a tym, co wpływa na CES dla akredytacji uniwersytetu ABET, co powoduje, że decydenci są głupi, gdy pojawiają się rażące problemy z ograniczeniami czasowymi i nierealistycznymi oczekiwaniami, które ujawniłaby ocena PERT. Uniwersytet nie ćwiczy tego, czego uczy.

Moim zdaniem Unified Process ma wiele zalet, ale cała praktyka wybijania artefaktów wizualnych, choć język modelowania jest nieco niedorzeczny. Udoskonalony iteracyjnie dokument zawierający szeregowaną listę, taki jak np. Word, Workflowy, Evernote, OpenOffice lub nazwa edytora tekstu, jest w stanie doskonale udokumentować to, czego wymaga Unified Process. Coś w tym prostym języku może z łatwością pracować wielu użytkowników, kontrolować wersję, a jeśli wybierzesz odpowiednie narzędzie, zespół może nawet nad nim pracować w tym samym czasie. Jest to o wiele łatwiejsze do wykonania niż wtedy, gdy UML wydawał się koniecznym sposobem zjednoczenia hord.