Obiecane posty z cyklu, diagramy UML, po co? Na co ? i dlaczego ? - Diagram Klas

Ale może zanim o samym diagramie, to dwa słówka wprowadzenia (no może więcej niż dwa).

Modelowanie, nie tylko diagramów UML, ale ogólnie modelowanie systemów, prototypów, dziedziny czegokolwiek, powinno opierać się wg mnie na dwóch zasadach.

Model powinien jak najwierniej odzwierciedlać rzeczywistość

Model powinien być stworzony na takim poziomie szczegółowości, na jaki zdecydujemy się w trakcie poznawania celu tworzenia modelu. (nie wiem czy to zrozumiałe- więc posłużę się przykładem)

Modelujemy samolot.

No i teraz jeśli chcielibyśmy skupić się na jego częściach mechanicznych to w modelu nie będziemy pokazywać miejsc siedzących, rozmieszczenia toalet czy wyjść ewakuacyjnych. Skupimy się na silnikach, turbinach, filtrach, okablowaniu, elektronice itp.

Dlaczego nie pokażemy tych naszych miejsc ?

Bo akurat dla tego modelu nie są one potrzebne i celowo je ignorujemy, żeby nie odwracać uwagi od tego co jest dla nas naprawdę istotne.

Na tym wg mnie powinno bazować modelowanie. Patrząc na model, diagram wiem o czym opowiada, jaki fragment rzeczywistości reprezentuje i na jego podstawie mogę odpowiedzieć sobie na wszystkie pytania związane z celem, który sobie ustaliłam.

No to teraz do rzeczy. Tytułowy diagram klas.

Żeby móc się zabrać za tworzenie diagramu musimy poznać jego składowe, jak pewnie każdy się domyśla, podstawową składową diagramu klas są:

KLASY! Co za niespodzianka!:)

No dobra tylko czym one tak naprawdę są?

Klasa to wzorzec, taka można powiedzieć matryca, na podstawie której będziemy tworzyć obiekty. 

Ha, tylko czym są obiekty?

Obiekt to bezpośrednia reprezentacja konkretnego zjawiska istniejącego w rzeczywistości. Przykładem obiektu może ulica, numer domu, kod pocztowy, klasą dla takich obiektów będzie Adres.

Podsumowując ten opis słownomuzyczny. Nie stworzymy poprawnych obiektów, jeśli źle określimy klasę. Bo nie wrzucimy do klasy „Lot” obiektu „ilość miejsc stojących” bo ich tam po prostu nie ma. 

Teraz trochę twardych elementów. Jak graficznie zaprezentujemy klasę ?

Nazwa klasy – No to chyba nie trzeba tłumaczyć 😊

Atrybuty – reprezentują cechy danej klasy, uwzględniające cel tworzenia danej klasy (miejmy z tyłu głowy modelowanie tego samolotu)

Operacje  – pokazujemy co tak naprawdę potrafią te nasze atrybuty, bo telewizor nie będzie umiał tańczyć.

Widoczność – można się spotkać z nazwą dostępność (ale mam wrażenie, że dużo rzadziej) określa w jaki sposób będzie widoczna dana cecha czy operacja dla pozostałych elementów naszego systemu.

Poniżej opis co oznaczają poszczególne znaczki 😊

# chroniony - widoczny wewnątrz klasy i jej podklas,

- prywatny - widoczny tylko wewnątrz swojej klasy,

~ publiczny w zakresie pakietu - widoczny wewnątrz własnego pakietu, czyli w obrębie pewnego zestawu klas.

+ publiczny - widoczny z każdego miejsca systemu.

Oczywiście jak wszystko w tym świecie IT możemy pokazać bardziej lub mniej szczegółowo.

Sposobów, w jaki możemy przedstawić klasę jest kilka:

Każdy z nich jest poprawny i każdy odpowiada na inne potrzeby.

No dobra, to mamy klasy, mamy obiekty, wiemy, co oznaczają poszczególne fragmenty klas, ale żeby mówić o modelu/diagramie warto byłoby pokazać zależności pomiędzy klasami. W jaki sposób można je ze sobą łączyć? Jak zaznaczamy relacje pomiędzy klasami ?

Zależność - najsłabsza relacja łącząca klasy. Informuje nas, że zmiana w jednej klasie powoduje zmianę w drugiej (chwilową). Relacja ta ma wiele typów, np. use, create, realize i inne.

Przykład: Klasa Tir używa klasy Autostrada.

Asocjacja  – w przypadku asocjacji wiemy, że klasy są ze sobą połączone, ale nie są od siebie zależne, usunięcie jednej z dwóch klas połączonych tą zależnością nie powoduje usunięcia drugiej.  Często do relacji asocjacji dodaje się nazwy asocjacji, krotności i role. Krotność informuje, jaka ilość obiektów jest zaangażowana w asocjację. Rola jak sama nazwa wskazuje, informuje klasę o roli jaką posiada druga klasa.

Przykład: Klasa Spotkanie i Klasa Sala

Agregacja  - nazywana również agregacją częściową. Jest relacją typu część - całość. Ważne jest, że część może należeć do kilku całości a jej istnienie jest od nich niezależne.

Przykład: Klasa Wydział zawiera od 10 do 100 Studentów. Zlikwidowanie klasy Wydział nie spowoduje skasowania klasy Student, ponieważ może ona być częścią innej klasy.

Kompozycja  - zawieranie, lub agregacja całkowita. Szczególnie na nazwa zawieranie dobrze pasuje do zrozumienia tego „połączenia”. Podobnie jak agregacja częściowa, informuje nas o tym, że jedna klasa zawiera obiekty innej (całość-część). Jest jednak pewna mała różnica, jeśli skasujemy klasę nadrzędną, klasa podrzędna znika.  

Przykład: Klasa człowiek i Klasa Serce. W momencie, kiedy usuniemy klase serce, człowiek będzie istniał (średnio będzi emu się żyło, ale istniał będzie😉) natomiast jeśli usuniemy człowieka to serce niekończenie będzie miało możliwość istnienia.

Generalizacja  - dziedziczenie, i ta druga nazwa również lepiej opisuje relacje między klasami. W tym wypadku klasą ogólną i klasami szczególnymi. Klasa Ogólna posiada swoje atrybuty, które są dziedziczone przez klasy szczególne.

Przykład:  Klasa ogólna Samochód, Klasy szczególne : Klasa Tir, Klasa Osobówka

Uff, mam nadzieje, że ktoś dotarł do końca i że choć trochę ułatwi to Wam prace w trakcie modelowania nowych, fantastycznych systemów.