Jakich diagramów UML używasz? [zamknięte]

Używam żadnego.

Prawie ich nie widziałem od czasów studiów i moich projektów dyplomowych.

Mam wrażenie, że głównie studenci/profesorowie są zainteresowani tymi metodologiami, świat praktyki żyje szczęśliwie bez UML.

Chociaż nie mówię, że UML nie może przynieść żadnych korzyści.

Schematy sekwencji są dla mnie podstawowym typem, bardzo mało wykorzystania czegokolwiek innego naprawdę.

Narzędzie Online

Być może lepiej byłoby zapytać, jakie praktyczne korzyści czerpię z używania UML ?

• UML nie dostarczył narzędzi, które rozumieją diagramy i wypluwają kod szablonowy.
• Użytkownicy Nietechniczni nie rozumieją UML.
• czy diagramy sekwencji naprawdę uchwycić cały przepływ programu?
Diagramy klasowe-większość ludzi kończy z sphaghetti - ponieważ próbują włożyć za dużo.
• diagramy przypadków użycia-są często zbyt proste, są bezwartościowe.
• RUP - im mniej mówi się o tym, tym lepiej..

Każdy mechanizm diagramowania wraz z jasną narracją może być użyty do przekazania dowolnego pomysłu. Wystarczy zrobić to czytelne, jasne i logiczne i powinno pomóc być oczywiste.

Używam diagramów przejścia stanów do modelowania złożoności-dobrze-różnych stanów danej aplikacji.

• diagramy przypadków użycia : aby uchwycić wymagania behawioralne
• diagramy sekwencji : aby uchwycić interakcje obiektów

Bardzo małe lub żadne użycie w ogóle czegokolwiek innego

Diagramy przypadków użycia nie zawierają żadnych szczegółów, ale nie widziałem lepszego sposobu na szybkie przedstawienie przeglądu wszystkich przypadków użycia w systemie.

Diagramy klas są przydatne do pokazania klas, które są częścią każdego pakietu. Jednak Rzadko widuję je używane do tego celu przez innych programistów. Są one zwykle używane do rzucania kilka klas na obraz z małym rymem i powodu, dlaczego poszczególne klasy są w każdym obrazie. Tak więc diagramy nie są bardzo przydatne.

Schematy sekwencji są niezbędne. Narzędzia absolutnie nie obsługują użytecznego wykorzystania diagramów sekwencji, więc musisz być nieco pomysłowy w ramach ograniczeń narzędzi. Ale używam diagramów sekwencji, aby udowodnić, że moje przypadki użycia pasują do mojej architektury, a mój projekt pasuje do moich operacji na pakietach itp... Myślę, że nie ma bardziej użytecznego diagramu. Jednak większość ludzi ich nie używa, prawdopodobnie dlatego, że zmusza cię to do myślenia o swoim projekcie.

Pojęcie diagram komponentów jest przydatny. Wersja UML jest dość brzydka, więc zwykle kończę rysowanie własnego diagramu za pomocą Powerpoint lub Visio.

Nie przepadam za diagramami stanu czy aktywności. Miałem kilka złych doświadczeń z projektami maszyn państwowych innych ludzi na początku mojej kariery, a tym samym uniknąć ich jak zarazy.

Jeśli chodzi o prezentację klientowi/menedżerowi to korzystam z informacji z tych diagramów, ale umieszczam je w formacie łatwiejszym do zrozumienia i na znacznie wyższy poziom.

Jednakże, aby przedstawić innym programistom, schematy te powinny być wystarczające do przekazania wymaganych informacji poprzez projektowanie. Ale zwykle wymagają one napisania tekstu narracyjnego, aby był wartościowy.

Model domeny jest niezbędny w większości projektów. Daje to personelowi technicznemu spójne, jasne i jednoznaczne zrozumienie słownictwa domenowego. Diagram klasy UML jest najlepszą notacją do tego (tak, nawet lepszą niż słowniczek języka angielskiego).

Model przypadków użycia (to jest model, a nie diagram) jest znacznie łatwiejszy do manipulowania niż tuzin dokumentów Word (oczywiście w zależności od wyboru narzędzia UML) i dlatego polecam podążanie ścieżką UML w dokumentowaniu użycia sprawy. Twoje narzędzie UML prawie na pewno pozwoli Ci przypisać dodatkowe informacje do Twoich przypadków użycia, takich jak skrypty testowe, metryki itp. Posiadanie tego w modelu pozwoli Ci tworzyć niestandardowe raporty na temat tych dodatkowych informacji.

Poza tym, powiedziałbym, że jeśli potrzebujesz diagramu stanu, użyj diagramu stanu UML; jeśli potrzebujesz diagramu przepływu, użyj diagramu aktywności UML; jeśli potrzebujesz wykresu wywołania, użyj diagramu sekwencji UML. W każdym przypadku notacja UML będzie szerzej rozumiana niż jakikolwiek ad hoc zapis, który sam wymyślisz.

Ale ogólnym przesłaniem jest, aby używać wszelkich narzędzi, które masz pod ręką, aby ułatwić swoją pracę.

Zagłosuję za diagramami przypadków użycia, ponieważ są to jedyne diagramy UML, które użytkownicy/klienci mogą zrozumieć i znaleźć odpowiednie dla ich potrzeb.

Wszystkie mogą być wykorzystane do projektowania i dokumentacji projektu. Jest to bardzo otwarte na interpretację.

To będzie zależało od projektu i dla kogo tworzysz dokumentację. W niektórych przypadkach UML jest prawie bezużyteczny, ale może pomóc w zbudowaniu prostszego diagramu innego niż UML, który użytkownicy końcowi mogą zrozumieć.

W innych przypadkach, gdy tylko dokumentujesz dla innych programistów diagramy UML mogą być przydatne. W tym przypadku diagramy przejścia stanu mogą być przydatne dla programistów systemów, podczas gdy diagramy przypadków użycia mogą być lepsze dla analityków dokumentujących wymagania.

Ogólnie używanie UML w tym celu nie jest pomocne dla innych programistów, użytkowników ani twoich klientów. To tylko jedno narzędzie do komunikacji. Jeśli jesteś zbyt religijny w używaniu UML, nie zaspokajasz potrzeb żadnej z tych grup.

Nie lubię diagramów przypadków użycia. Schemat nie pokazuje zbyt wiele, uważam, że lista punktowana z opisami jest znacznie bardziej przydatna, jeśli nie pełne opisy przypadków użycia ze scenariuszami, warunkami awarii itp.

Diagramy klas są przydatne, chociaż nigdy nie wkładałem w nie wszystkich szczegółów. Uzyskiwanie połączeń między obiektami domeny i tym, jak wszystko pasuje do siebie, wydaje się bardziej przydatne niż przechodzenie i wypełnianie zachowań i pola.

Diagramy sekwencji są świetne, jeśli próbujesz zrozumieć przepływ czegoś, co staje się zbyt skomplikowane i masz problemy z wizualizacją, co się dzieje.

Diagramy klas, diagramy sekwencji i diagramy stanu są również Świetne do prób zrozumienia, co robi istniejący kod.

Nie martwię się formalnościami w moich diagramach; są to szkice na tablicy.

Mój głos osobisty: Diagramy Przypadków Użycia Diagramy Sekwencji Diagramy Klas

Z okazjonalnym, uzupełniającym diagramem aktywności.

Ale myślę, że przebieg jest różny. Zazwyczaj pracuję na systemach z wieloma przypadkami użycia, z których niektóre są obsługiwane przez integrację komercyjnych rozwiązań i pisanie trochę kodu. Więc dla mnie przypadki użycia są często najbardziej odpowiednią częścią UML, z okazjonalnym diagramem komponentów.

Sekwencja i klasa są diagramami defacto dla Projektowanie oprogramowania, ale widziałem, że są bardzo źle używane. Łatwo jest wpaść w schemat projektowania diagramów wycinarek do ciastek, a nie wiercić w diagram, który pokazuje naprawdę krytyczne aspekty projektu systemu.

Uwielbiam UML za jego zdolność do zapewnienia jasnej, znormalizowanej składni do spójnego wyjaśniania problemów projektowych. Ale nienawidzę, że czasami jego za rozwój "standard", a nie tylko jedno narzędzie do pracy. Używaj ich, jeśli pomóż oświecić krytyczną grupę ludzi i pominąć je całkowicie, jeśli służą teraz użytecznemu celowi do podjęcia decyzji technicznej.

Nigdy, przenigdy nie używam żadnej formy UML do przekazywania pomysłów technicznych. Uważam, że jest to wyjątkowo bezużyteczne medium do tego celu. Przebyliśmy długą drogę od czasu używania malowideł jaskiniowych do przekazywania pomysłów między jednostkami. Od kilku tysiącleci ludzie używają rzeczywistego języka, z całą jego złożonością, niuansami i elokwencją, aby jasno i jednoznacznie przekazać wszystkie rodzaje pojęć. Jako gatunek, dokonaliśmy tego ważnego przejścia od dwuznacznej graficznej reprezentowanie idei w jednoznacznym języku z bardzo dobrego powodu: jasności.

Jedynymi ludźmi, których widziałem przy użyciu UML z wielkim zapałem, są osoby nietechniczne (zazwyczaj analitycy biznesowi i kierownicy projektów), którym błędnie sprawia wrażenie, że angażują się w pewne precyzyjne rozwiązywanie problemów, podczas gdy w rzeczywistości są tylko bardzo niejednoznacznymi rysunkami, które często oznaczają znacznie różne i sprzeczne rzeczy dla różnych odbiorców, na których są są zadane. Widziałem, jak użytkownicy końcowi, Programiści, analitycy biznesowi i kierownicy projektów siedzą wokół tego samego zestawu diagramów, kiwając głową w pozornym zrozumieniu i harmonii, a dopiero później zdają sobie sprawę, że każdy z nich odebrał zupełnie inne zrozumienie, na czym polega rzeczywisty problem i co trzeba zbudować, aby go rozwiązać.

Będę trzymać się tego, co dobrze działało dla mnie i użytkowników końcowych, których zbudowałem ponad czterdzieści systemów w ciągu ostatnich dwudziestu lat:

1) pisanie jednoznacznych dokumentów definicji problemu w prostym języku angielskim (uzupełnione prostymi tabelami i diagramami dotyczącymi problemu dyskretnego, które należy rozwiązać w stosownych przypadkach).

2) Po zdefiniowaniu problemu, napisanie oddzielnej specyfikacji technicznej (również w języku angielskim), która opisuje proponowane rozwiązanie tego dobrze zdefiniowanego problemu w kategoriach, które rzeczywisti użytkownicy końcowi mogą zrozumieć.

3) wreszcie, kodowanie rozwiązania, które spełnia zarówno definicję problemu, jak i proponowana Specyfikacja techniczna wykonana w krokach 1 i 2 powyżej, dostosowując rozwiązanie do rzeczywistości, w stosownych przypadkach (etapy 2 i 3 często nakładają się, z jednym zasilaniem do drugiego).

Żal mi ludzi, którzy szczerze wierzą, że mogą pominąć krok 1 (Definicja problemu)* powyżej, i jakoś magicznie przeskoczyć prosto do kroku 2, próbując opisać rozwiązanie źle rozumianego i słabo skalowanego problemu, zwiększając ich trudność za pomocą niezdarnego medium, takiego jak UML, który jest z natury niejednoznaczne i podlegające rozpowszechnionej błędnej interpretacji między różnymi stronami procesu. W ten sposób szaleństwo kłamie.

[15]} co gorsza, kiedy wskazujesz nietechnicznym ewangelistom UML, że nie zdefiniowali problemu przed próbą opisania proponowanego rozwiązania, zwykle wskazują na masę "przypadków użycia" i diagramów z małymi figurkami, które lubią nazywać "aktorami" , i zupełnie nie doceniają tych aspektów tego, co stworzyli są w najlepszym razie jedynie niepełnymi opisami jednego możliwego rozwiązania i w żaden sposób nie reprezentują abstrakcyjnej definicji problemu. Na przykład, przypadek użycia "Bob naciska pedał przyspieszenia, a samochód idzie szybciej" jest częściowy opis potencjalnego rozwiązania (samochód), który jest sam w sobie tylko jedno możliwe rozwiązanie (i, być może, nie najbardziej trafne) do rzeczywistego podstawowego problemu, że "Bob musi dostać się z A do B". Jeśli wiesz również, że Bob 1) nie może prowadzić, 2) w każdym razie żyje na Łódź - które fakty tylko pełna definicja rzeczywistego problemu powie ci - że przypadek użycia pedału zaczyna wyglądać dość nieistotnie, prawda?

Często używam pewnego rodzaju diagramu wdrażania podczas modelowania systemu (choć, co prawda, mam tendencję do używania nie-UML rzeczy w moich diagramach, jak również)

Używam diagramów klas dość często, aby udokumentować projekt wysokiego poziomu i relacje między najważniejszymi klasami. Często używam diagramów przejścia stanu, ale nie robionych w stylu UML. Rzadko korzystam z diagramów sekwencji, trudno mi je odczytać (i napisać).

Pracuję w zwinnym środowisku, więc większość UML, który piszę, to krótkotrwałe rysunki na tablicy.

Używam diagramów klas do zilustrowania, jak Klasy odnoszą się do siebie nawzajem. Używam diagramy aktywności zamiast tradycyjnych schematów blokowych, aby wyjaśnić ogólny przepływ programu. diagramy maszyn stanowych mogą być przydatne do wyjaśnienia zmian stanu w cyklu życia obiektu. Bardzo okazjonalnie, użyję diagramu sekwencji do pracy z jakąś splątaną logiką programu, chociaż często zmieniam kod, aby to zrozumieć.

Zadaj sobie pytanie, co rozumieją moi użytkownicy, czy naprawdę jestem w stanie i zobowiązałem się do utrzymywania moich diagramów aktualnych i dokładnych, czy też będą gnić i dodawać zamieszania...

Zadaj sobie pytanie czy. NET lub Java dostarczają gdzieś UML jako część pakietu dokumentacji ?

Używam tylko diagramu przypadków użycia i diagramu wdrażania, ponieważ uważam je za przydatne w wyjaśnieniu odpowiednio funkcjonalności i konfiguracji wdrażania.

Schematy sekwencji, które pomogą mi śledzić rzeczy, gdy próbuję zgrubić Kod innych ludzi.