Praktyczny przewodnik po UML z wykorzystaniem Visual Paradigm i VPasCode

UML – Unified Modeling Language (Zstandaryzowany język modelowania) – to standaryzowany sposób opisywania struktury i zachowania systemu. Pomaga zespołom w dyskusji na temat wymagań, projektowaniu oprogramowania i dokumentowaniu decyzji. UML jest językiem modelowania, a nie językiem programowania: diagramy komunikują model, ale nie gwarantują automatycznie, że implementacja mu odpowiada.

Ten przewodnik wykorzystuje system sklepu internetowego jako ciągły przykład. Omawia główne typy diagramów UML oraz przepływ pracy z wykorzystaniem Visual Paradigm do modelowania wizualnego oraz VPasCode do diagramów tekstowych.

1. Zacznij od pytania, na które powinien odpowiadać Twój diagram

Zanim zaczniesz rysować, zdecyduj, co czytelnik musi zrozumieć:

• Co mogą robić użytkownicy? Użyj diagramu przypadków użycia.

• Co dzieje się w trakcie scenariusza? Użyj diagramu sekwencji lub aktywności.

• Jakie koncepcje i relacje tworzą domenę? Użyj diagramu klas.

• Jak oprogramowanie jest podzielone na części nadające się do wdrożenia lub wymiany? Użyj diagramów komponentów i wdrożenia.

• Jak jeden obiekt zmienia się w czasie? Użyj diagramu maszyny stanów.

Diagram, który próbuje odpowiedzieć na wszystkie pytania jednocześnie, zazwyczaj staje się trudny do odczytania. Preferuj kilka skupionych diagramów zamiast jednego przeładowanego przeglądu.

2. Rodziny diagramów UML

UML 2.x obejmuje 14 standardowych typów diagramów, które zazwyczaj grupuje się na diagramy strukturalne i behawioralne. Diagramy interakcji są podzbiorem diagramów behawioralnych.

Rzadko potrzebujesz wszystkich 14 diagramów do projektu. Dla wielu projektów aplikacji silnym zestawem wyjściowym są diagram przypadków użycia, klas, sekwencji, aktywności, komponentów i wdrożenia.

3. Najbardziej przydatne diagramy z przykładem e-commerce

Diagram przypadków użycia: cele i granica systemu

Diagram przypadków użycia opisuje cele użytkowników, a nie układy ekranów ani kod wewnętrzny. Dla sklepu internetowego aktorzy mogą obejmowaćKlient, Dostawca płatności, orazUsługa magazynowa. Przypadki użycia mogą obejmowaćPrzeglądaj produkty, Złóż zamówienie, Opłać zamówienie, orazŚledź przesyłkę.

Użyj<<include>>gdy przypadek użycia zawsze wywołuje inne wymagane zachowanie. Użyj<<extend>>w przypadku zachowania opcjonalnego lub warunkowego, które rozszerza podstawowy przypadek użycia. Zachowaj wyraźną granicę systemu, aby czytelnicy mogli odróżnić system od zewnętrznych aktorów.

Diagram aktywności: przepływ pracy i decyzje

Diagramy aktywności są przydatne w procesach z gałęziami lub pracą równoległą. Przepływ procesu zakupowego może wyglądać następująco:

1. Zweryfikuj koszyk i adres.

2. Oblicz koszty dostawy i podatek.

3. Utwórz zamówienie w stanie oczekującym.

4. Zażądaj autoryzacji płatności.

5. Jeśli płatność się powiedzie, potwierdź zamówienie i powiadom o realizacji.

6. Jeśli płatność się nie powiedzie, wyświetl komunikat o błędzie i pozostaw zamówienie niepotwierdzone.

Używaj węzłów decyzyjnych i scalających do rozgałęziania, węzłów rozgałęziania i scalania do pracy równoległej oraz basenów (swimlanes), gdy odpowiedzialność zmienia się między klientem, sklepem i zewnętrznym dostawcą.

Diagram sekwencji: jeden scenariusz w czasie

Diagramy sekwencji pokazują uczestników oraz wiadomości, które wymieniają. Są szczególnie przydatne do wyjaśniania granic usług, kolejności wywołań oraz przypadków błędów. Dodaj ścieżki alternatywne dla wyników takich jak odrzucenie płatności lub brak towaru w magazynie.

@startuml
aktor Klient
uczestnik "Sklep internetowy" jako UI
uczestnik "Usługa zamówień" jako Zamówienia
uczestnik "Usługa magazynu" jako Magazyn
uczestnik "Dostawca płatności" jako Płatność

Klient -> UI: złóż zamówienie
UI -> Zamówienia: placeOrder(koszyk, adres)
Zamówienia -> Magazyn: rezerwuj(towary)

alt towary dostępne
    Magazyn --> Zamówienia: rezerwacja potwierdzona
    Zamówienia -> Płatność: autoryzuj(kwota)
    alt płatność zatwierdzona
        Płatność --> Zamówienia: zatwierdzono
        Zamówienia --> UI: zamówienie potwierdzone
        UI -> Klient: pokaż potwierdzenie
    else płatność odrzucona
        Płatność --> Zamówienia: odrzucono
        Zamówienia -> Magazyn: zwolnij rezerwację
        Zamówienia --> UI: płatność nieudana
        UI -> Klient: pokaż błąd płatności
    end
else towary niedostępne
    Magazyn --> Zamówienia: rezerwacja nieudana
    Zamówienia --> UI: towar niedostępny
    UI -> Klient: pokaż błąd dostępności
end
@enduml

Ten przykład używa składni PlantUML. Jest to szkic behawioralny, a nie specyfikacja każdego limitu czasowego, ponawiania lub reguły bezpieczeństwa. Dodaj te szczegóły, gdy będą istotne dla projektu.

Diagram klas: struktura domenowa

Diagramy klas opisują typy i ich relacje. Mały model zamówienia może zawierać:

• Klient

• Zamówienie

• pozycja zamówienia

• Produkt

• Płatność

Wyświetl atrybuty i operacje, gdy pomagają wyjaśnić odpowiedzialności. Używaj mnożności, aby uczynić reguły ilości wprost widocznymi: na przykład jedno Zamówienie zawiera jedną lub więcej pozycja zamówienia obiektów, podczas gdy każda pozycja zamówienia odnosi się do jednego Produkt.

Typowe rodzaje relacji:

• Asocjacja:ogólny związek strukturalny.

• Dziedziczenie/uogólnienie:jedna klasa jest specjalnym rodzajem innej.

• Agregacja:relacja całość–część, w której części mogą istnieć niezależnie; stosować oszczędnie.

• Kompozycja:silna relacja całość–część, w której cykl życia części jest powiązany z cyklem życia całości.

• Zależność:jeden element używa lub zależy od innego.

Dla modelu handlowego Linia zamówieniaczęsto modeluje się jako należącą do jednego Zamówienia, podczas gdy Produktistnieje niezależnie od jakiegokolwiek konkretnego zamówienia. Wybierz relację, która odzwierciedla rzeczywisty cykl życia i reguły dziedziny.

Diagram automatu stanów: reguły cyklu życia

Użyj automatu stanów, gdy istotne są dozwolone przejścia obiektu. Zamówienie może przechodzić przez:

Oczekujące → Oczekujące na płatność → Potwierdzone → Zrealizowane

Może również przejść do Anulowane lub Płatność nieudana. Oznacz przejścia zdarzeniami wyzwalającymi lub warunkami, takimi jak płatnośćZatwierdzona lub [dostępność towaru]. Ten diagram może ujawnić nieprawidłowe przejścia – na przykład, czy zrealizowane zamówienie może zostać anulowane.

Diagramy komponentów i wdrożenia: oprogramowanie i środowisko wykonawcze

Diagram komponentówpokazuje odpowiedzialności i zależności oprogramowania, takie jak sklep internetowy, usługa zamówień, usługa magazynu i adapter płatności. Jest przydatny do omawiania modułowości i granic integracji.

Diagram wdrożeniapokazuje, gdzie działa oprogramowanie: na przykład przeglądarka, środowisko wykonawcze aplikacji, baza danych i zewnętrzny dostawca płatności. Używaj go do omawiania topologii środowiska wykonawczego, a nie szczegółowej konfiguracji sieci.

4. Modeluj dobrze: praktyczne konwencje

• Nadaj każdemu diagramowi jasny tytuł i jeden cel.

• Używaj języka domenowego konsekwentnie; unikaj wymyślania różnych nazw dla tego samego pojęcia.

• Zachowaj diagramy na tyle małe, aby można je było czytać w ich zamierzonym rozmiarze.

• Dołączaj tylko szczegóły, które odpowiadają na pytanie stawiane przez diagram.

• Oznacz ważne powiązania i przepływy wiadomości.

• Dodawaj mnożności do powiązań, gdy zasady dotyczące ilości mają znaczenie.

• Używaj notatek dla założeń, ograniczeń i nierozstrzygniętych decyzji.

• Zachowaj spójność nazw i odpowiedzialności na wszystkich diagramach.

• Rozróżniaj to, co jest potwierdzone, od tego, co jest proponowane lub wciąż nieznane.

• Aktualizuj diagramy, gdy zachodzą ważne zmiany w decyzjach projektowych lub zachowaniu.

Traktuj UML jako narzędzie komunikacji. Diagram może być poprawny składniowo, a mimo to wprowadzać w błąd, jeśli jego etykiety, założenia lub zakres są niejasne.

5. Korzystanie z Visual Paradigm

Visual Paradigm jest dostosowany do modelowania graficznego: tworzenia i rozmieszczania elementów UML na płótnie, organizowania powiązanych diagramów oraz udoskonalania modelu poprzez edycję wizualną. Materiały produktowe opisują modelowanie UML jako jedną z jego możliwości modelowania wizualnego.

Praktyczny przepływ pracy:

1. Utwórz projektdla systemu lub obszaru o określonych granicach, który modelujesz.

2. Zacznij od wymagań i zakresu.Zidentyfikuj użytkowników, zewnętrzne systemy i kluczowe cele.

3. Utwórz diagram przypadków użyciaaby określić granice i główne interakcje.

4. Dodaj diagramy zachowaniadla scenariuszy, które niosą największe ryzyko lub niejednoznaczność.

5. Stwórz model klasoparty na koncepcjach domenowych i ich regułach.

6. Dodaj widoki komponentów i wdrożeniajeśli architektura lub rozmieszczenie w czasie wykonania wymaga dyskusji.

7. Przejrzyj z interesariuszami.Sprawdź nazwy, zakres, alternatywne przepływy i kardynalności.

8. Eksportuj lub udostępnij diagramyw formatach odpowiednich do przeglądów i dokumentacji.

9. Utrzymuj model w aktualnym stanie.Przypisz właściciela i aktualizuj diagramy, gdy zmieniają się decyzje.

Dokładne nazwy menu i dostępne funkcje mogą się różnić w zależności od edycji i wersji Visual Paradigm, dlatego do kroków specyficznych dla danej edycji należy korzystać z aktualnej dokumentacji interfejsu produktu.

6. Korzystanie z VPasCode

VPasCode to przeglądarkowy edytor diagramów typu „diagram jako kod” od Visual Paradigm. Informacje o produkcie opisują obsługę tekstowych formatów diagramów, w tym PlantUML i Mermaid, z podglądem na żywo; opisuje również eksport do formatów takich jak SVG i PNG.

Prosty przepływ pracy:

1. Otwórz VPasCode i wybierz język diagramów, np. PlantUML.

2. Napisz lub wklej skrypt diagramu.

3. Sprawdzaj podgląd renderowany podczas edycji.

4. Dopracuj nazwy, relacje, układ i ścieżki błędów.

5. Eksportuj obraz do dokumentu lub przeglądu.

6. Zachowaj skrypt źródłowy wraz z projektem, jeśli chcesz mieć tekstowy zapis, który można przeglądać i wersjonować.

VPasCode jest dobrym rozwiązaniem dla szybkich szkiców, diagramów dokumentacyjnych i zespołów preferujących edycję tekstową. Graficzny model Visual Paradigm jest przydatny, gdy chcesz wizualnie manipulować elementami modelu i organizować diagramy jako część większego projektu modelowania. Te dwa podejścia mogą się uzupełniać, ale nie zakładaj, że każdy diagram lub model przenosi się między nimi z idealną wiernością w obie strony; waliduj każdą konwersję w swoim przepływie pracy.

7. Przydatny przepływ pracy od początku do końca

Dla funkcji koszyka lekka sekwencja modelowania mogłaby wyglądać następująco:

1. Przypadek użycia:określ, kto może złożyć zamówienie i które systemy zewnętrzne biorą w tym udział.

2. Aktywność:zmapuj przepływ koszyka i jego decyzje.

3. Sekwencja:opisz interakcje dla ścieżek: sukces, niepowodzenie płatności oraz brak towaru.

4. Klasa:zdefiniuj pojęcia: zamówienie, pozycja zamówienia, produkt i płatność oraz ich reguły.

5. Maszynowy stan:określ poprawny cykl życia zamówienia.

6. Komponent:pokaż, które usługi ponoszą te odpowiedzialności.

7. Wdrożenie:dokumentuj rozmieszczenie w czasie wykonania, jeśli decyzje infrastrukturalne są istotne.

Użyj Visual Paradigm, gdy zespół czerpie korzyści z modelowania opartego na płótnie i zarządzanego modelu wizualnego. Użyj VPasCode, gdy zespół chce szybko pisać i renderować tekst diagramów. Powszechnym podejściem jest szkicowanie scenariusza w VPasCode, jego przegląd i dopracowanie z zespołem, a następnie utrzymanie diagramów w formacie najlepiej pasującym do dokumentacji projektu i procesu zmian.

8. Typowe pułapki

• Próba zdiagramowania całego systemu na raz:podziel według obszaru zainteresowania lub scenariusza.

• Mylenie aktywności z sekwencjami:aktywności podkreślają przepływ pracy; sekwencje podkreślają komunikaty w czasie.

• Przeciążanie diagramów klas:skup się na istotnych koncepcjach domenowych, a nie na każdym szczególe implementacji.

• Używanie include i extend jako ozdobnik:wyrażają one specyficzne relacje między przypadkami użycia.

• Pomijanie ścieżek alternatywnych:niepowodzenia i anulowania często ujawniają istotne wymagania.

• Traktowanie obrazka jako specyfikacji:jawnie dokumentuj istotne reguły biznesowe, założenia i ograniczenia.

• Pozwalanie diagramom przestarzeć się:przestarzały diagram może być gorszy niż brak diagramu, ponieważ czytający mogą mu ufać.

Silny zestaw UML nie jest największym zestawem. To najmniejszy zestaw diagramów, który pozwala zamierzonym odbiorcom zrozumieć system, omówić decyzje i wykryć luki, zanim staną się kosztowne.

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文