Przejdź do głównej zawartości

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. 

Komentarze

Popularne posty z tego bloga

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊
Proszę napisać wymganie w formie user stories. 
Proszę zapisać wymaganie w formie przypadku użycia.
Czym są sytuacje wyjątkowe w opisie przypadków użycia ?
No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories, a czym Use Case.

User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2]
User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy)[3].
Ważne jest to, aby User Stories przedsta…

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy!
Takie podobno cieszą się największym zainteresowaniem 😊
Jakie Pani zna rodzaje diagramów UML ?
No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.

 Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.  
Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu niepotrzebne struktury i di…

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego.
Przejdź do pytań
Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.  
Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych.
No to lecimy :) pytanie na dziś to 
Jak Pani przeprowadza analizę?
Pierwsze co mi się nasunęło na myśl: „To zależy” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy.
Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- Jak właściwie zabrać się za analizę i…