PO Obiektowe modelowanie dziedziny

<<< Powrót do przedmiotu Programowanie obiektowe

Wprowadzenie

Programowanie obiektowe (ang. object-oriented programming) jest obecnie najpopularniejszą techniką tworzenia programów komputerowych. Program komputerowy wyraża się jako zbiór obiektów będących bytami łączącymi stan (czyli dane) i zachowanie (czyli metody, które są procedurami operującymi na danych obiektu). W celu realizacji zadania obiekty wywołują nawzajem swoje metody, zlecając w ten sposób innym obiektom odpowiedzialność za pewne czynności. W porównaniu z tradycyjnym programowaniem proceduralnym, w którym dane i procedury nie są ze sobą powiązane, programowanie obiektowe ułatwia tworzenie dużych systemów, współpracę wielu programistów i ponowne wykorzystywanie istniejącego kodu.

Historia programowania obiektowego

Pierwszy język obiektowy – Simula 67 – powstał już w latach sześćdziesiątych ubiegłego stulecia. Jego twórcami byli Ole-Johan Dahl i Kristen Nygaard z Norsk Regnesentral w Oslo. Podczas swoich prac nad symulacją statków musieli dla każdego rodzaju statku uwzględniać wiele atrybutów. Ponieważ liczba modelowanych rodzajów statków była duża, uwzględnienie wszystkich możliwych zależności między atrybutami stało się problematyczne. Pojawił się pomysł, aby pogrupować różne rodzaje statków w klasy obiektów. Każda klasa obiektów sama miała być odpowiedzialna za definiowanie swoich danych i zachowania. Simula była pierwszym językiem programowania, w którym wprowadzono pojęcie klasy i jej egzemplarza. Warto tu zwrócić uwagę, że zgodnie z nazwą języka takie odwzorowanie obiektów spotykanych w świecie rzeczywistym na obiekty programowe można nazwać symulacją.

<flash>file=Statki.swf|width=550|height=220</flash>

Niedługo potem w laboratorium badawczym Xerox's Palo Alto stworzono Smalltalk. Jego głównym pomysłodawcą był Alan Kay. Smalltalk zawierał wiele rewolucyjnych pomysłów - m.in. dziedziczenie - i zyskał sobie sporą popularność. W pewnej skali był również z powodzeniem stosowany w praktyce. Standardem przemysłowym programowanie obiektowe stało się jednak dopiero w latach dziewięćdziesiątych za sprawą języka C++, który jest obiektowym rozszerzeniem C. Obecnie jednym z najpopularniejszych języków obiektowych i równocześnie języków programowania w ogóle jest Java.

Znajomość języka obiektowego takiego jak Java jest niezbędna, aby zostać programistą obiektowym, jednak zgodnie z powiedzeniem "posiadanie młotka nie czyni architektem" zanim przyjrzymy się konstrukcjom spotykanym w obiektowych językach programowania, wyjaśnijmy kilka pojęć i nauczmy się tego, co najważniejsze, czyli co to znaczy myśleć obiektowo.

Czemu programowanie obiektowe stało się takie popularne?

Największym atutem programowania obiektowego jest zbliżenie programów komputerowych do naszego sposobu postrzegania rzeczywistości. Często nazywa się to zmniejszeniem luki reprezentacji (ang. representational gap). Wymyślając nowy lub analizując istniejący program obiektowy nasz mózg ma ułatwione zadanie. Dlatego ludzie są w stanie łatwiej zapanować nad kodem i tym samym tworzyć większe programy. Łatwiej jest również zrozumieć kod i pomysły innych programistów i tym samym współpracować w zespole oraz ponownie wykorzystywać istniejące rozwiązania. Co więcej ten sam, naturalny dla ludzi sposób myślenia i te same pojęcia można użyć przy analizie problemu, który ma być rozwiązany i projektowaniu jego programowego rozwiązania. Już Arystoteles analizując rzeczywistość wprowadził pojęcia formy i materii. Formie w programowaniu obiektowym odpowiada klasa (ang. class), materii jej egzemplarz (ang. instance) wymiennie nazywany obiektem (ang. object). Klasyfikacja, czyli łączenie występujących w rzeczywistości obiektów w grupy – klasy, jest najbardziej naturalnym sposobem rozumienia rzeczywistości.

Analiza i projektowanie obiektowe

Z programowaniem obiektowym nieodzownie wiążą się analiza i projektowanie obiektowe (ang. Object-Oriented Analysis and Design, OOA/D). Analiza to badanie problemu i wymagań, ale nie rozwiązania. Analiza to obszerny termin. Analiza obiektowa (ang. object-oriented analisys) zajmuje się badaniem i klasyfikacją obiektów pojęciowych. Obiekty pojęciowe nie mają nic wspólnego z programowaniem. Reprezentują pojęcia i koncepcje ze świata rzeczywistego, a dokładniej z dziedziny, która jest analizowana. W wypadku systemu informacyjnego dla Zakładu Transportu Miejskiego obiektami pojęciowymi są na przykład: Autobus, Linia i Kierowca.

Projektowanie to wymyślanie koncepcyjnego rozwiązania (programistycznego i sprzętowego), które realizuje wymagania. Takim koncepcyjnym rozwiązaniem może być opis schematu bazy danych lub klas programowych. Podczas projektowania zazwyczaj pomija się niskopoziomowe lub oczywiste (dla zamierzonych odbiorców projektu) szczegóły i koncentruje się na wysokopoziomowych pomysłach oraz ideach. Projektowanie obiektów programowych określane jest jako projektowanie obiektowe (ang. object-oriented design).

Najważniejszą czynnością projektowania obiektowego jest wyznaczenie odpowiedzialności obiektom programowym oraz określenie jak mają współpracować, by wykonać zadanie. Tak naprawdę są to jedyne czynności, jakie na pewno trzeba będzie wykonać. Główna trudność polega na tym, że istniej wiele poziomów swobody, a każde rozwiązanie ma swoje wady i zalety. Na programowaniu obiektowym nauczysz się, na co zwracać uwagę i jak świadomie wybierać. Poznasz również wzorce projektowe, czyli typowe rozwiązania typowych problemów, których wady i zalety dobrze poznano.

Analiza i projektowanie dają się krótko streścić jako "zrób co należy (analiza) oraz zrób to jak należy (projektowanie)".

Proces wytwórczy

Trzeba od razu podkreślić, że w większości przedsięwzięć programistycznych nie da się najpierw wykonać całej analizy, potem przygotować kompletny projekt, a na końcu jedynie przekształcić go w kod. Takie podejście nazywane "kaskadowym" opiera się na błędnych przekonaniach, że wytwarzanie oprogramowania jest podobne do innych zajęć, np. budowania domów. Tak nie jest! Większość przedsięwzięć programistycznych to opracowywanie nowego produktu, gdzie nawet klient nie wie dokładnie czego chce. Najlepiej wytwarzać oprogramowanie przyrostowo, dzieląc całą pracę na krótkie, trwające od dwóch do sześciu tygodni iteracje. W każdej iteracji wykonuje się zarówno analizę, projektowanie jak i pisze kod. Oczywiście w początkowych iteracjach więcej czasu poświęcane jest na analizę, a w końcowych na projektowanie i kodowanie. Wynikiem każdej iteracji powinien być sprawny system realizujący część funkcjonalności. Zmiany będą się pojawiały i trzeba się z nimi pogodzić, ale można ograniczyć ich zasięg oraz koszt wybierając do realizacji w początkowych iteracjach wymagania, które mają największą wartość dla klienta, których realizacja wywiera największy wpływ na architekturę systemu i które niosą za sobą największe ryzyko. W ten sposób zmniejsza się prawdopodobieństwo zmian powodujących zmarnowanie części już wykonanej pracy.

Więcej o procesach wytwórczych i tworzeniu iteracyjnym dowiesz się na Inżynierii oprogramowania. Mimo, że w tej chwili ta rada może wydawać ci się na wyrost i prawdopodobnie nie możesz się już doczekać poznawania obiektowych języków programowania, zapamiętaj: pisząc program zaliczeniowy z programowania obiektowego oraz programując zawodowo podziel pracę na dające się zakończyć w kilka tygodni iteracje i nie odraczaj trudnych i ryzykownych zagadnień na sam koniec!

Obiektowe modelowanie dziedziny

Zgodnie ze swoją nazwą model dziedziny ma odzwierciedlać pojęcia z modelowanej części świata rzeczywistego oraz ich zależności. Jest to najważniejszy artefakt analizy obiektowej. W modelu dziedziny nie zajmujemy się klasami programowymi (ang. software class). Może on posłużyć jako źródło inspiracji przy ich projektowaniu, ale nie w drugą stronę. Tworzenie modelu dziedziny nie jest obowiązkowe ale bardzo przydatne, jeżeli dziedzina problemu, który rozwiązujemy, nie jest dobrze zrozumiała. Jeżeli jest, tworzenie modelu dziedziny należy potraktować jako dekompozycję dziedziny na godne uwagi pojęcia i obiekty. Inspirowanie się nim podczas projektowania systemu pomoże w zmniejszeniu luki reprezentacji.

W modelu dziedziny pokazuję się:

• klasy pojęciowe,
• powiązania między klasami pojęciowymi i
• atrybuty klas pojęciowych.

Przykład

Przykład częściowego modelu dziedziny dla aplikacji wspomagającej rezerwację miejsc i sprzedaż biletów kinowych znajduje się na poniższym diagramie.

Klasy pojęciowe przedstawiane są w prostokątach. Są to Film, Seans i Sala. Każda klasa pojęciowa reprezentuje wszystkie możliwe obiekty jednego typu/rodzaju. Nazwy klas pojęciowych przyjęło się umieszczać w pierwszej przegródce prostokąta i pisać wielką literą. Jeżeli nazwa klasy składa się z kilku członów, łączy się je i każdy kolejny człon również rozpoczyna wielką literą, np. RozkładJazdy.

W drugiej przegródce prostokąta reprezentującego klasę pojęciową umieszcza się jej atrybuty. Atrybuty to napisy, liczby, daty bądź wartości logiczne opisujące poszczególne egzemplarze klasy pojęciowej. Każdy egzemplarz/obiekt klasy Film posiada na przykład tytuł i czasTrwania.

Uzupełniając klasy o atrybuty trzeba zachować ostrożność. Coś, co na pierwszy rzut oka wydaje się atrybutem, może być inną klasą pojęciową. W naszym przykładzie, mimo że podczas seansów wyświetlane są filmy, klasa Seans nie ma takiego atrybutu. Jest za to powiązana z klasą Film. Na diagramie jest to pokazane przy pomocy ciągłej linii łączącej obie klasy. Powiązanie oznacza, że między egzemplarzami klas pojęciowych może zachodzić związek, który warto pamiętać przez jakiś czas. Powiązania również mają nazwy. Będziemy je zapisywać tak samo jak nazwy klas pojęciowych, chociaż niektórzy nazwy członów rozdzielają myślnikami. Jako nazw powiązań należy używać zwrotów czasownikowych tak, aby informacje na diagramie tworzyły zdania. W naszym przypadku z diagramu można odczytać:

• film jest wyświetlany w trakcie seansu oraz
• seans odbywa się w sali.

Domyślnie przyjmuje się kierunek czytania z góry na dół lub od lewej do prawej. Jeżeli niewygodne jest rozmieszczenie klas na diagramie tak, żeby zachować domyślny kierunek, można przy etykiecie umieścić jakiś symbol graficzny wskazujący właściwy kierunek czytania, np. wypełniony na czarno trójkącik.

Podczas obiektowego modelowania dziedziny największą wagę przykłada się do odnajdywania klas pojęciowych i od tego zaczyna się pracę. Następnie rozważa się związki, które mogą wystąpić między egzemplarzami klas pojęciowych i przedstawia je jako powiązania. Odnajdywanie atrybutów jest czymś najmniej istotnym i zostawia się je na koniec.

Odnajdywanie klas pojęciowych

Przy znajdywaniu klas pojęciowych (ang. conceptual class) należy postępować jak kartograf:

• należy używać istniejących nazw, np. gdy analizujesz system do zbierania wyników w nauce, który ma być używany w liceum, jego użytkownikami będą uczniowie, a gdy jest przeznaczony dla uczelni wyższej to studenci,
• nie zajmować się niczym, co nie dotyczy modelowanej części rzeczywistości; jeżeli pracujesz iteracyjnie powstrzymaj się od rozpoznawania klas pojęciowych, które są nieistotne w obecnej iteracji oraz
• nie dodawać rzeczy, których nie ma.

Często spotykane kategorie klas pojęciowych

Żeby szybko zorientować się, co jest a co nie jest klasą pojęciową posłużymy się listą często spotykanych kategorii. Początkowo ta lista będzie pełnić rolę pomocy naukowej. Z czasem, gdy nabierzesz już doświadczenia, większość klas pojęciowych rozpoznasz od razu. Listy warto wtedy używać, aby upewnić się, czy żadne klasy nie zostały pominięte.

Często spotykane kategorie klas pojęciowych

Kategoria	Przykłady	Klasy z dziedziny gry w Monopol
transakcje	SprzedażBiletu, RezerwacjaMiejsc
pozycje transakcji Do tej kategorii jest dostępny komentarz Często zdarza się, że transakcje nie grupują po prostu produktów lub usług, ale jeszcze zawierają jakieś dodatkowe informacje ich dotyczące. Pozycja rezerwacji może na przykład zawierać informacje, czy dane miejsce jest rezerwowane jako pełnopłatne, czy też przysługuje jakaś ulga.	PozycjaRezerwacji
produkty bądź usługi związane z transakcjami i kontraktami lub ich pozycjami	Bilet
gdzie transakcje są odnotowywane	Kasa, WykazDostępnychMiejsc
role ludzi i organizacji związanych z transakcją	Kasjer	Gracz
miejsce zajścia transakcji/obsługi transakcji	Kasa, SalaKinowa
zdarzenia (często trzeba pamiętać czas ich zajścia)	Seans	GraWMonopol
obiekty fizyczne	Bilet, Kino, Kasa, Miejsce	Plansza, Pionek, Kostka
opisy Do tej kategorii jest dostępny komentarz W niektórych przypadkach może się okazać, że ważne informacje są trzymane tylko z egzemplarzami pewnej klasy i przepadną, jeżeli te egzemplarze zostaną usunięte. Wyobraźmy sobie, że wszystkie seanse odbywające się w poniedziałek o godzinie 20 będą na przykład miały tę samą cenę. Co jednak będzie, jeżeli kino będzie musiało wstrzymać pracę na jakiś czas, czyli nie będzie obiektów odpowiadających seansom w poniedziałek, a wszyscy z obsługi zapomną, ile kosztowały bilety na ten dzień? W tym przypadku warto rozważyć utworzenie dodatkowej klasy z opisem i przenieść do niej informacje o cenie. Inne przykłady uzasadniające użycie klas z opisem to strajk na kolei powodujący odwołanie wszystkich kursów, przez co przepadają informacje o rozkładzie jazdy, oraz wyprzedanie wszystkich produktów danego typu ze sklepu, co spowoduje niemożliwość odtworzenia ich ceny. Uwaga: klasy z opisem często zawierają również przedział czasowy, w którym dany opis obowiązuje.	OpisSeansu
katalogi	KatalogSeansów, KatalogFilmów
kontenery rzeczy fizycznych lub informacji	Kino, SalaKinowa	Plansza
rzeczy w kontenerach	SalaKinowa, Miejsce	Pole
inne współpracujące systemy	SystemAutoryzującyPłatnościElektroniczne
potwierdzenia, rejestry, kontrakty, zagadnienia prawne	Pokwitowanie, PotwierdzenieRezerwacji
instrumenty finansowe	Czek, Gotówka
harmonogramy, instrukcje, dokumenty regularnie używane podczas wykonywania prac	DziennaListaPromocji

Analiza fraz rzeczownikowych

Innym wygodnym pomysłem na odnajdywanie klas pojęciowych jest analiza fraz rzeczownikowych w tekstowym opisie dziedziny lub wymagań (jeżeli takimi dysponujemy). W przypadku gry w Monopol na pewno warto rozpoznać frazy rzeczownikowe w instrukcji z zasadami gry. Okaże się na przykład, że nie uwzględniliśmy kompletów pól, banku, ani kart szansy/ryzyka. Załóżmy jednak, że w tej iteracji uwzględnimy jedynie klasę KompletPól, a bankiem i kartami nie będziemy się na razie zajmować.

Klasy pojęciowe dla gry w Monopol

Rozpoznane przez nas klasy pojęciowe są pokazane na poniższym diagramie.

Modelowanie artefaktów programowych

Pamiętaj, że wykonujesz analizę dziedziny, to nie jest projektowanie. Nie uwzględniaj artefaktów programowych, np. okienek, baz danych, itp. Wyobraź sobie, że programu nigdy nie napiszesz lub że zrobi to za ciebie ktoś inny. Oczywiście wyjątkiem są artefakty programowe należące do dziedziny, którą modelujesz, na przykład możesz uwzględnić zewnętrzne systemy, z którymi twój system będzie współpracował, a jeżeli twoim celem jest stworzenie modelu dziedziny dla sieci komputerowej, to możesz uwzględnić pakiety, połączenia, itp.

Odnajdywanie powiązań

Powiązanie (ang. association) między klasami wskazuje, że między ich egzemplarzami może występować jakaś zależność. W modelu dziedziny pokazujemy powiązania, które są niezbędne do wypełnienia wymagań informacyjnych i pomagają zrozumieć dziedzinę. Pokazanie zbyt wielu powiązań sprawi, że diagramy będą mało czytelne. Zazwyczaj warto pokazywać powiązania między klasami, jeżeli przez jakiś czas "trzeba pamiętać" o zależności między ich egzemplarzami. Dlatego, mimo że powiązania rysujemy między klasami, myślimy o ich egzemplarzach. Czy trzeba na przykład pamiętać na jakim Polu jest Pionek albo do jakiego Gracza należy? Oczywiście. Jednak informacji, że wartość wskazywana przez Kostkę określa, na które Pole się ruszyć, nie trzeba przechowywać w modelu. Jest to metainformacja. Tak samo nie ma potrzeby zapamiętywać, że Gracz przesuwa Pionek.

Często spotykane kategorie powiązań

Przy znajdywaniu powiązań również posłużymy się listą często spotykanych kategorii.

Lista często spotykanych kategorii powiązań

Kategoria	Przykłady	Klasy z dziedziny gry w Monopol
A jest transakcją związaną z inną transakcją B	Płatność–RezerwacjaMiejsc
A jest pozycją transakcji B	PozycjaRezerwacji–RezerwacjaMiejsc
A jest produktem lub usługą z transakcji lub pozycji transakcji B	Bilet–SprzedażBiletu
A jest rolą związaną z transakcją B	Klient–Płatność
A jest fizyczną lub logiczną częścią B	Miejsce–SalaKinowa, SalaKinowa–Kino	Pole–Plansza, Pole–KompletPól, GraWMonopol–Plansza, GraWMonopol–Kostka, GraWMonopol–Pionek
A fizycznie lub logicznie przechowywane w/na B	Kasa–Kino	Pionek–Pole, Pole–Plansza
A jest opisem B	OpisSeansu–Seans
A jest rejestrowane, zgłaszane, utrwalane, pamiętane w/na B	SprzedażBiletu–Kasa	Pionek–Pole, GraWMonopol–Plansza
A jest uczestnikiem/pracownikiem/członkiem B	Kasjer–Kino	Gracz–GraWMonopol
A jest organizacyjną podjednostką B	Kino–SiećKin
A używa, zarządza lub posiada B	Kasjer–Kasa	Gracz–Pionek
A jest obok B	PozycjaRezerwacji–PozycjaRezerwacji

Nazywanie powiązań

Nazywanie powiązań nie zawsze jest proste. Wymyślając nazwę sami wiemy co mamy na myśli, ale nie każda nazwa, która pasuje, pozwoli innym zorientować się, o co nam chodziło. Dla wielu powiązań będzie na przykład pasować nazwa Dotyczy, ale nie przenosi ona wielu informacji. Pamiętaj o tym nazywając powiązania!

Liczebność

Odnajdując powiązania, powinniśmy zastanowić się nad ich liczebnością (ang. multiplicity). Liczebność określa, jak wiele egzemplarzy klasy A może być powiązane z jednym egzemplarzem klasy B. Na diagramach liczebność przedstawia się w postaci wyrażenia umieszczanego obok klasy A tuż przy linii obrazującej powiązanie. Przykładowe wyrażenia liczebności to:

• 1 (dokładnie jeden)
• 11 (dokładnie jedenaście)
• 3, 5, 7 (trzy lub pięć lub siedem)
• 2..8 (od dwóch do ośmiu)
• 0..1 (zero lub jeden)
• 1..* (co najmniej jeden)
• * (dowolna ilość również zero)

Określając liczebność pamiętaj, żeby wyrażać ograniczenia związane z dziedziną. Jeżeli na podstawie twojego modelu powstanie w przyszłości system obiektowy, te ograniczenia będą bardzo przydatne i na ich podstawie zostaną określone więzy spójności.

Klasy pojęciowe i powiązania dla gry w Monopol

Rozpoznane przez nas klasy pojęciowe oraz powiązania wraz z nazwami i liczebnościami są pokazane na poniższym diagramie.

Dodawanie atrybutów

Wartości atrybutów (ang. attirbute) opisują egzemplarze klas pojęciowych. Nie wszystkie klasy pojęciowe muszą mieć atrybuty. Dodawanie atrybutów jest w zasadzie prostsze niż odnajdywanie klas pojęciowych czy powiązań i zazwyczaj zostawia się je na koniec. Są jednak dwie pułapki.

Po pierwsze, trzeba pilnować, żeby wartości atrybutów rzeczywiście opisywały egzemplarze klas pojęciowych. Może się zdarzyć, że coś, co wydaje nam się atrybutem klasy A, powinno tak naprawdę być atrybutem klasy B, a między A i B powinno być powiązanie. Przykładowo numer jest atrybutem Miejsca, a nie Biletu.

Po drugie niech atrybuty będą jedynie wartościami typów podstawowych – "czystymi danymi" – jak napisy, liczby, wartości logiczne czy daty. W przeciwnym przypadku prawdopodobnie znowu lepiej dodać klasę pojęciową i ustanowić z nią powiązanie. Przykładowo kierownik nie jest atrybutem Kina. To oddzielna klasa pojęciowa sama posiadająca wiele atrybutów jak imię, nazwisko czy dataUrodzenia.

Uwaga: w pewnych sytuacjach coś, co wydaje się być wartością typu podstawowego wcale nią nie jest! Niektóre wartości liczbowe mają na przykład jednostki, które mogą być istotne, a część identyfikatorów, mimo że na pierwszy rzut oka wydaje się liczbą lub napisem, ma pewną strukturę pozwalającą odczytać dodatkowe informacje.

Częściowy model dziedziny dla gry w Monopol

Po uzupełnieniu o atrybuty nasz model dziedziny dla gry w Monopol wygląda następująco:

Nie jest to jeszcze wersja ostateczna. Nie uwzględniliśmy na przykład kart szansy/ryzyka, a być może w trakcie późniejszych prac (projektowania, kodowania lub dalszych iteracji) zdecydujemy się wprowadzić jakieś zmiany. Nie należy się tym jednak przejmować. Wystarczy, że przez godzinę lub dwie myśleliśmy o dziedzinie zadania. O to właśnie chodzi, żeby unikać "pędu do kodowania" i zastanowić się nad dziedziną. Pamiętaj również żeby pracować iteracyjnie i nie zabierać się za wszystko na raz, tylko zacząć od tego, co najbardziej ryzykowne.

Obiekty i ich stan

Po rozpoczęciu tworzenia modelu dziedziny dla gry w Monopol można przyjrzeć się jakiejś rozgrywanej grze i wypisać wszystkie obiekty wraz z wartościami ich atrybutów. Wartości atrybutów pojedynczego obiektu określają jego stan. A stany wszystkich obiektów składają się w sumie na stan gry. Dotychczas na diagramach pokazywaliśmy jedynie klasy. Używając tej samej notacji można pokazywać poszczególne obiekty wraz z ich stanem.

Na powyższym diagramie widać trzy obiekty klasy Gracz oraz wartości ich atrybutów. Pierwsza przegródka zawiera etykietę składającą się z identyfikatora obiektu i występującą po dwukropku nazwę klasy. Cała etykieta musi być obowiązkowo podkreślona. Identyfikator można opuścić, ale jego podanie ułatwia odwoływanie się do danego obiektu. W drugiej przegródce wymienione są kolejne atrybuty oraz po znaku "=" ich wartości. Ten przykład pokazuje również, jak na diagramach umieszczać komentarze tekstowe. Służą do tego notatki (ang. note) przedstawiane jako prostokąt z zagiętym prawym górnym rogiem. Notatki dołącza się do opisywanych przez nie elementów przy pomocy przerywanej linii.

Wiązania

Godne uwagi związki pomiędzy obiektami pokazujemy w ten sam sposób co powiązania między klasami. Przyjęło się je nazywać wiązaniami (ang. link). Tak samo jak obiekty są egzemplarzami klas, wiązania można uznać za egzemplarze powiązań. Poniższy diagram pokazuje wiązanie między obiektami klas Gracz i Pionek.