DIAGRAM KLAS

ZASTOSOWANIE

 Opisuje typy obiektów w systemie i różne rodzaje statycznych relacji między nimi; atrybuty i
operacje klas oraz ograniczenia tego, w jaki sposób mogą być powiązane
 Obiekt – występuje w środowisku (np. przedmioty (urządzenia techniczne, budynki, twory
przyrody), osoby, jednostki organizacyjne, zdarzenia, twory przyrody lub dokumenty), ale może być
elementami oprogramowania (ekrany, interfejsy, bazy danych, zarządcy aplikacji czy komunikacji)
 Obiekt opisany jest trzema elementami (indywidualna tożsamość, stan o zmieniających się
wartościach i zachowanie)

Samochod_Jana samochod_Krzysztofa

 Klasa stanowi opis wybranego podzbioru obiektów, w którym każdy z obiektów posiada takie same
atrybuty, operacje, metody, związki i znaczenie. Z określenia tego wynika założenie dotyczące
inwariantności (niezmienności) cech i zachowań obiektów, którym przypisano wspólny klasyfikator
w postaci nazwy klasy.
Ponieważ klasa stanowi wzorzec dla tworzonych obiektów, nie jest celowe, aby każdy z nich
przechowywał kopię tego samego opisu operacji; wszystkie utworzone obiekty powinny zatem
odwoływać się do wspólnej definicji operacji zawartych w klasie. Możemy więc założyć, że klasa nie
stanowi jedynie prostego opisu zbioru obiektów, ale zawiera jeden egzemplarz definicji operacji,
które działają na wielu egzemplarzach atrybutów, unikatowych dla każdego obiektu.

Samochód

 Klasa składa się z nazwy, listy atrybutów i operacji.

 Atrybut to nazwana właściwość klasyfikatora, określająca zestaw wartości, które mogą przyjmować
jego instancje.
Atrybuty klas charakteryzują pojedyncze obiekty lub grupy obiektów, tworząc dla każdego z nich
niezależną ich instancję. Jeżeli atrybut klasy może istnieć niezależnie od obiektu, to często lepszym
rozwiązaniem jest zbudowanie z niego nowej klasy, np. atrybut Adres dla klasy Klient.
 Operacja to funkcja dostarczana przez obiekt, która manifestuje się przez odpowiednie jego
zachowanie. Operacja ma sygnaturę, która określa jej dopuszczalne parametry i sposób wywołania.
Operacje klasy działają na pojedynczych obiektach lub ich zbiorach. W odróżnieniu od atrybutów,
zwykle tworzona jest jedna instancja operacji klasy (przechowywana w klasie), wspólna dla
wszystkich obiektów tej klasy. W niektórych sytuacjach operację lepiej jest przedstawić jako klasę
(np. operacja wypożyczSamochód jako działanie może być operacją klasy lub może być klasą
wypożyczSamochód z własnymi atrybutami: dataWypożyczenia, dataZwrotu, etc.).
Składniki klasy mogą posiadać różne modyfikatory dostępu:
 + to składnik publiczny (public)
 # to składnik chroniony (protected)
 – to składnik prywatny (private)
 ~ to składnik dostępny w obrębie projektu (package)
 metody abstrakcyjne w klasie abstrakcyjnej są pochylone lub podkreślone.


Związki pomiędzy klasami w UML

W relacjach pomiędzy klasami mogą występować cechy krotności:

 1 dokładnie jeden obiekt

 0..3 od zera do trzech obiektów
 * dowolna ilość obiektów
 3..* od trzech do dowolnej ilości obiektów

Krotności umieszczamy po obu stronach zależności. Jeżeli krotność nie jest podana należy
przyjąć, że ma wartość 1.

Zależność

Zależność jest najsłabszą relacją jaka może występować pomiędzy dwoma klasami. Oznacza, że
jedna klasa chwilowo wykorzystuje drugą, lub wie o jej istnieniu. Jak sama nazwa wskazuje –
występuje zależność. Zmiana w jednej z klas może spowodować ale (nie musi) konieczność
zmian w drugiej klasie.

Powyższą zależność należy czytać w sposób: klasa portfel jest zależna od klasy Pieniadze.

Poprawnie zaprojektowany system powinien zawierać jak najmniej zależności. Wszelkie

zależności utrudniają rozbudowę istniejącego projektu. Aby pozbyć się zależności, można w
argumencie funkcji przyjmować poszczególne pola klasy Pieniadze zamiast całego obiektu.

Asocjacja

Asocjacja jest związkiem pomiędzy dwoma klasami. Jest silniejszym wiązaniem niż zależność.
Paradoksalnie w odróżnieniu od zależności, w asocjacji dwie klasy nie wpływają na siebie.
Oznacza to, że usunięcie jednego obiektu nie wpływa w żadnym stopniu na drugi.

Asocjacje mogą być jednokierunkowe, dwukierunkowe a nawet nieokreślone (bez grotów na

końcu linii). W diagramach klas UML asocjacji używa się rzadko. Wynika to z faktu jej wysokiego
poziomu abstrakcyjności. Częściej wykorzystywane są w diagramach UML innych typów.

Istnieje pewna dowolność w czytaniu asocjacji. Aby pomóc w ich odczytywaniu często są one
dodatkowo opisane.
Znacznie częściej stosowane są szczególne formy asocjacji czyli agregacje częściowe i
całkowite. Sama asocjacja jest relacją nieco luźniejszą, przez co w diagramach UML klas
spotykana jest rzadko.

Agregacja częściowa

Agregacja częściowa jest mocniejszą odmianą zwykłej asocjacji. Jeżeli spotkasz się z nazwą
samej agregacji, oznacza to że chodzi o agregację częściową. Jest to związek dwóch klas w
formie relacji całość-część. Ważnym jest fakt, że usunięcie klasy całość nie wpływa na istnienie
klasy część.

W Agregacji częściowej element częściowy może należeć do elementu głównego, jednak nie
jest od niego zależny. Usunięcie elementu głównego nie wpływa na usunięcie elementu
częściowego. Element częściowy może także należeć do wielu elementów głównych. Sprawa
wydaje się skomplikowana, ale rozważmy przykład:

Ten prosty diagram agregacji częściowej należy czytać w następujący sposób: klasa katalog ma
klasę dokument.

Agregacja całkowita (kompozycja)

Ostatnią odmianą asocjacji jest agregacja całkowita nazywana często kompozycją. Działa
podobnie na zasadzie agregacji częściowej z tą różnicą, że kontroluje cykl życia części. Oznacza
to, że po usunięciu klasy głównej, zostanie usunięta klasa częściowa.

Powyższy obrazek można czytać w następujący sposób: klasa System ma na własność klasę
Plik. Pamiętaj, że nie chodzi tutaj o zawieranie albo zagnieżdżenie tylko o związek relacji
całkowitej, czyli odpowiedzialność klasy głównej za istnienie klasy częściowej.

Przykład programu będzie podobny jak w agregacji częściowej. Jedyną różnicą jest fakt, że
klasa System będzie odpowiedzialna za utworzenie instancji klasy Plik na stercie oraz za
przechowywanie referencji do niej. Jaki z tego wniosek? Wzorując się przykładem C#, po
usunięciu klasy System klasa Plik także zostałaby usunięta ze sterty przez garbage collector, po
wykryciu braku referencji.

Dziedziczenie

Nie ma sensu rozpisywać się na ten temat. Dziedziczenie jest głównym filarem paradygmatu
programowania obiektowego. Dziedziczenie umożliwia wyodrębnienie cech wspólnych dla
kilku klas i zamknięciu ich w klasie bardziej ogólnej – o wyższym poziomie abstrakcji.

Klasy dziedziczące po klasie bazowej przejmują jej cechy. Pozwala to znacznie skrócić kod i
zorganizować kod od strony logicznej.

Klasa Osoba posiada pewne cechy wspólne dla wszystkich klas, które ją rozszerzają.

Klasy zagnieżdżone w UML

Na diagramie klas UML możemy umieścić także klasę zagnieżdżoną. Jej symbolem jest puste
kółko z czarnym krzyżykiem.

Diagram należy czytać w następujący sposób: klasa Silnik jest zagnieżdżona w klasie Samochód.