Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Transkrypt

1 Umiejętność czytania oraz tworzenia diagramów klas UML jest podstawą w przypadku zawodu programisty. Z takimi diagramami będziesz spotykał się w przeciągu całej swojej kariery. Diagramy klas UML są zawsze obecne we wszelkiego rodzaju dokumentacjach. Diagramy klas UML Język UML jest językiem służącym do graficznego modelowania różnego rodzaju aplikacji oraz systemów. Najczęściej wykorzystywany jest do modelowania diagramów klas. Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego. Diagramy klas UML mogą pokazywać strukturę całego systemu bądź tylko jego części (i najczęściej tak jest). Doskonale obrazują one poglądową strukturę programu. Definiują jakie metody i pola powinna zawierać dana klasa. Pokazują one także część ich implementacji. Oczywiście diagram przedstawia tylko typy obiektów bez ich instancji za to odpowiedzialny jest diagram obiektów UML. Należy pamiętać, że informacje zawarte w diagramie klas UML są poglądowe. Mają ułatwić implementację klas oraz ukazać zasadę funkcjonowania systemu. Jasne jest, że nie da się zawrzeć na diagramie wszystkich informacji o danej klasie. Gdyby tak było, wtedy diagramy klas byłyby graficzną reprezentacją kodu a tak nie jest. Jeżeli w diagramie klas nie ma jakiegoś składnika, to nie można zakładać że takowy nie istnieje w modelowanej aplikacji. Jeżeli w diagramie klas UML brakuje jakiegoś składnika, nie oznacza to, że taki nie istnieje w systemie. Poprawne jest także całkowite ukrycie składników klasy, pozostawiając tylko jej nazwę, ale tylko w wypadku gdy nie jest to klasa silnie decydująca o modelu systemu (o wysokim priorytecie). Reprezentacja klas w UML W języku UML istnieją pewne standardy, mówiące w jaki sposób przedstawiać różne elementy. Każdy obiekt reprezentowany jest przez jeden prostokąt, w którym zawarte są jego składniki. W prostokącie może znajdować się tylko nazwa elementu, tylko nazwa elementu wraz z polami bądź wszystkie składniki czyli nazwa, pola i metody. Dodatkowo do składników Karol Trybulec p-programowanie.pl 1

2 elementu można dołączać informacje o typie, typie zwracanym lub argumentach. Dobrym zwyczajem jest także określanie poziom dostępu do składników klasy. 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. Przykładowa diagram klasy na dwa sposoby: Reprezentacja klas abstrakcyjnych i interfejsów w UML Jeżeli chodzi o klasy abstrakcyjne sytuacja jest prosta, przedstawia się ją tak jak zwykłą klasę ale jej nazwa napisana jest kursywą. To jedyna różnica w przedstawianiu klas abstrakcyjnych za pomocą UML. Interfejsy przedstawia się w UML tak jak klasy, jednak ich nazwa musi zostać poprzedzona słowem kluczowym <<interface>>. Słowo to jest stereotypem będącym standardem języka UML. Dobrym zwyczajem, który osobiście stosuję, jest rozpoczynanie nazwy interfejsu od dużej litery i. Nie wynika to absolutnie ze standardu UMLa, jednak pozwala łatwiej analizować diagram. Implementację interfejsu do danej klasy oznacza się pustym białym grotem strzałki, który znajduje się na końcu przerywanej linii. Oto przykład: Karol Trybulec p-programowanie.pl 2

3 Klasa implementująca interfejs musi implementować jego metody. W przypadku klasy abstrakcyjnej, klasa która dziedziczy, musi implementować metody abstrakcyjne. Metody w klasie abstrakcyjnej pochyliłem i podkreśliłem. Chyba najczęściej spotykane są te pochylone. Związki pomiędzy klasami w UML Diagramy klas UML byłyby bezużyteczne, gdyby nie można było określać powiązań jakie między nimi występują. Poniżej opiszę wszystkie rodzaje związków między klasami w UML oraz dołączę do nich przykłady. Krótka infografika podsumowująca: Karol Trybulec p-programowanie.pl 3

4 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. Przykładem na zobrazowanie zależności między klasami jest przekazywanie argumentów do Karol Trybulec p-programowanie.pl 4

5 funkcji: 1 class Portfel 2 3 // zależność Portfel od Pieniądze 4 void Dodaj(Pieniadze p) 5 6 /*...*/ 7 8 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 Karol Trybulec p-programowanie.pl 5

6 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. Najlepiej agregację częściową zobrazować sobie na przykładzie typów referencyjnych w języku C#. Jeżeli utworzysz instancję klasy częściowej to pamięć zostanie zarezerwowana na stercie. Naszą klasą częściową jest Dokument. Klasą główną jest klasa Katalog. Zgodnie z diagramem UML jest ona w relacji z klasą Dokument, jednak ponieważ jest to agregacja częściowa to klasa Dokument nie jest od niej zależna. Oznacza to, że klasa Katalog przechowuje jedynie referencję do klasy Dokument, która znajduje się na stercie. Usunięcie klasy Katalog a wraz z nią referencji, spowoduje usunięcie jej ze stosu. Na stercie dalej będzie znajdować się klasa częściowa. Prosty kod w C# obrazujący agregację częściową: class Katalog private Dokument _swiadectwo; public void SetSwiatectwo(Dokument swiadectwo) // relacja agregacji częściowej _swiadectwo = swiadectwo; 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. Karol Trybulec p-programowanie.pl 6

7 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. 1 class System 2 3 // relacja agregacji całkowitej 4 private Plik _plik1 = new Plik(); 5 Rzecz jasna, nie ma znaczenia w którym miejscu odbywa się tworzenie instancji klasy. Jeżeli klasa główna tworzy jakiekolwiek referencje wewnątrz, to zawsze będzie to relacja agregacji całkowitej class System private Plik _plik1; public System() // relacja agregacji całkowitej _plik1 = new Plik(); Dziedziczenie Nie ma sensu rozpisywać się na ten temat. Dziedziczenie jest głównym filarem paradygmatu programowania obiektowego. Dziedziczenie umożliwia wyodrębnienie Karol Trybulec p-programowanie.pl 7

8 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ą. Przykładowy kod C#: class Osoba public string Imie get; set; class Student : Osoba public string NazwaUczelni get; set; /*...*/ 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. Przykładowy kod: Karol Trybulec p-programowanie.pl 8

9 class Samochod private int _waga; private class Silnik private int _moc; Przykłady diagramów Po krótkim omówieniu podstawowych elementów diagramów klas UML umieszczę kilka praktycznych schematów do przeanalizowania. Do schematów dołączę kody źródłowe napisane w języku C#. Karol Trybulec p-programowanie.pl 9