Diagram obiektów

Czym jest diagram obiektów#

Diagram obiektów (object diagram) pokazuje wybrane obiekty, ich wartości i połączenia w określonym stanie modelu. Jest statycznym obrazem konkretnych instancji, a nie opisem wszystkich możliwych obiektów. Pozwala odpowiedzieć na pytanie: „Jak mogłaby wyglądać struktura systemu w tym konkretnym przykładzie?”.

Diagram klas opisuje klasy i reguły dotyczące zbioru ich instancji; diagram obiektów pokazuje egzemplarze tych klas. Jeśli diagram klas mówi, że zamówienie może mieć wiele pozycji, diagram obiektów może pokazać jedno zamówienie z dwiema konkretnymi pozycjami. Może dzięki temu pomóc wyjaśnić trudny model, sprawdzić scenariusz albo pokazać, jak zastosować krotności do rzeczywistego przykładu.

UML 2.5.1 ujmuje diagram obiektów jako diagram strukturalny oparty na specyfikacjach instancji i łączach. W praktyce diagram najczęściej prezentuje wybrane obiekty klas i połączenia odpowiadające asocjacjom. Nie przedstawia przebiegu czasu ani komunikatów; do tego służą diagramy zachowania, takie jak diagram sekwencji.

Jak wygląda obiekt#

Obiekt jest zwykle rysowany jako prostokąt z podkreśloną etykietą. Typowy zapis to:

nazwaObiektu: NazwaKlasy

Można pominąć nazwę obiektu i pokazać sam typ, np. : Klient, gdy ważna jest instancja, ale nie jej nazwa. Można też pominąć typ, jeśli kontekst go określa, choć jawny typ zwykle ułatwia odczyt. Podkreślenie etykiety odróżnia obiekt od klasy w konwencji graficznej UML.

W prostym widoku prostokąt zawiera jedynie nazwę. Wartości cech można pokazać w dodatkowym przedziale, np. status = opłacone. Techniczny model UML opisuje wartości instancji jako sloty przypisane do cech klasyfikatora. Diagram może pokazywać tylko część wartości; brak atrybutu na rysunku nie dowodzi, że obiekt nie ma tej cechy.

Wartości muszą być zgodne z modelem. Jeśli klasa deklaruje ilość: Liczba, instancja nie powinna prezentować tam dowolnego obiektu tekstowego, chyba że typ modelu na to pozwala. Ograniczenia takie jak krotność, unikalność czy dozwolone wartości również mają zastosowanie. Diagram nie musi jednak powtarzać pełnej definicji klasy.

Łącza między obiektami#

Łącze (link) przedstawia konkretne powiązanie między instancjami. Zwykle jest rysowane linią ciągłą. W prostym diagramie może nie mieć nazwy; można też dodać etykietę lub nazwy ról, gdy pomagają odróżnić kilka możliwych znaczeń.

Łącze powinno odpowiadać relacji dopuszczonej w modelu klas. Jeśli klasa Zamówienie nie może być powiązana z Klientem według modelu, narysowanie takiego łącza sygnalizuje niezgodność modelu, nie alternatywną składnię. Podobnie liczba łączy do instancji musi być zgodna z krotnościami i innymi ograniczeniami, o ile diagram przedstawia stan mający spełniać te warunki.

Nazwa klasy na etykiecie obiektu i jego konkretne atrybuty nie powinny być mylone z nazwą relacji. Obiekt zamowienie104: Zamówienie to instancja, a zawiera może być rolą albo nazwą asocjacji łączącej ją z instancją pozycji.

Przykład: stan zamówienia#

Poniższa migawka pokazuje przykładowy fragment danych w sklepie. jan: Klient jest powiązany z zamówieniem z104: Zamówienie, które ma jedną widoczną pozycję. Pozycja odnosi się do produktu kawa: Produkt.

To nie jest drugi diagram klas. Pokazuje cztery konkretne obiekty z wybranymi wartościami i trzema łączami. Nie pokazuje wszystkich zamówień Jana, pełnego katalogu ani tego, co stanie się po kolejnej operacji. Wartość status = opłacone należy do tej przykładowej migawki, a nie do definicji każdej instancji Zamówienie.

Migawka jest zgodna z uproszczonym modelem z artykułu o diagramie klas: jedno zamówienie należy do klienta, zawiera pozycję, a pozycja dotyczy produktu. Artykułowy przykład nie przedstawia wszystkich ograniczeń produkcyjnego sklepu. Gdyby model wymagał co najmniej jednej pozycji w każdym zamówieniu, diagram powinien pokazać tyle instancji pozycji, by przykład spełniał tę regułę. Jedna pozycja spełnia warunek 1..*.

Diagram obiektów a diagram klas#

Oba diagramy uzupełniają się. Diagram obiektów może być osadzony lub zestawiony z diagramem klas, ale nie zastępuje modelu klas jako definicji typów. Pojedynczy poprawny przykład nie dowodzi, że wszystkie przypadki są poprawne; pokazuje tylko jeden dozwolony albo wymagający wyjaśnienia stan.

Kiedy używać diagramu obiektów#

Wyjaśnianie złożonej struktury#

Diagram klas może być trudny, gdy wiele relacji, ról lub krotności nakłada się na siebie. Konkretne nazwy instancji i ich wartości pozwalają pokazać jeden przypadek krok po kroku. Odbiorca widzi wtedy, które obiekty są powiązane i co oznaczają końce relacji.

Sprawdzanie przykładów i krotności#

Diagram obiektów może pomóc sprawdzić, czy ograniczenia klasyfikatorów dopuszczają oczekiwany przypadek. Przykład obiektu połączonego z kilkoma instancjami może ujawnić zbyt wąską krotność. Przypadek brzegowy, taki jak brak powiązanych elementów, może z kolei sprawdzić dolną granicę 0 albo 1.

Nie zastępuje to formalnej walidacji wszystkich instancji. Diagram przedstawia tylko wybrany zestaw. Jeżeli poprawność modelu ma być dowiedziona dla pełnej przestrzeni stanów, potrzebne są odpowiednie ograniczenia i metody weryfikacji.

Ilustrowanie przykładowych danych#

Diagram może pokazywać przykładowe dane testowe, scenariusz domenowy lub wycinek stanu pamięci. Należy używać danych fikcyjnych albo bezpiecznie zanonimizowanych. Konkretna migawka nie powinna przypadkowo ujawniać danych osobowych ani być mylona z rzeczywistym stanem produkcyjnym.

Dokumentowanie stanu w określonym momencie#

Warto opisać, czego dotyczy migawka: przypadku testowego, stanu po określonej operacji, danych przykładowych czy hipotetycznej konfiguracji. „Stan systemu” bez wskazania zakresu jest nieprecyzyjny, bo diagram nie pokazuje wszystkiego i nie niesie automatycznie informacji o czasie.

Jak przygotować diagram obiektów#

1. Wybierz konkretny scenariusz albo stan, który chcesz objaśnić.
2. Wypisz niezbędne instancje i podaj ich klasyfikatory.
3. Dodaj tylko wartości cech potrzebne do zrozumienia przykładu.
4. Połącz obiekty zgodnie z asocjacjami i ograniczeniami modelu.
5. Sprawdź zgodność liczby połączeń z krotnościami oraz warunkami.
6. Oznacz ważne założenia i zakres migawki w tekście.
7. Porównaj diagram z odpowiednim diagramem klas, jeśli stan ma ilustrować jego reguły.

Nie trzeba pokazywać pełnego zestawu cech każdej instancji. Wartości nieistotne dla pytania zwiększają obszar i utrudniają odczyt. Jednocześnie nie pomijaj wartości, które decydują o sensie przykładu, np. statusu, identyfikatora lub wybranej opcji.

Częste błędy#

• Zapisywanie obiektu jak klasy. Etykieta instancji powinna odróżniać nazwę obiektu od typu, zwykle przez zapis obiekt: Klasa i podkreślenie.
• Pokazywanie klas zamiast instancji. Prostokąt Klient opisuje typ; jan: Klient opisuje konkretny obiekt.
• Traktowanie wartości jako cech każdej instancji. Wartość na diagramie dotyczy przedstawionego obiektu w tym przykładzie.
• Rysowanie niedozwolonego łącza. Sprawdź, czy relacja istnieje w odpowiednim modelu klas.
• Naruszanie krotności. Policz konkretne powiązania i porównaj je z ograniczeniami.
• Zakładanie, że jeden przykład potwierdza cały model. Diagram obiektów ilustruje przypadek, nie dowodzi poprawności wszystkich stanów.
• Brak kontekstu czasu lub scenariusza. Opisz, co migawka ma przedstawiać i które elementy pomija.
• Nadmierna liczba instancji i szczegółów. Ogranicz diagram do scenariusza potrzebnego odbiorcy.
• Ujawnianie rzeczywistych danych. Stosuj dane fikcyjne lub zanonimizowane.

Co diagram obiektów pokazuje, a czego nie#

Diagram obiektów przedstawia przykładowe instancje, wybrane wartości ich cech i istniejące między nimi łącza. Jest przydatny do objaśniania struktur, konkretyzowania abstrakcyjnego diagramu klas i sprawdzania przykładowych konfiguracji.

Nie definiuje wszystkich klas ani wszystkich dopuszczalnych stanów systemu. Nie pokazuje kolejności działań, czasu, algorytmu ani komunikatów. Z tego powodu używaj go jako uzupełnienia diagramu klas lub diagramu zachowania, a nie jako jedynego opisu całej struktury i działania systemu.