DIAGRAMY KLAS i obiektów Projektowanie w systemach UML DIAGRAMY KLAS i obiektów dr inż. Sławomir Nowak

Diagramy klas Wprowadzenie Największym atutem programowania, projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością – mózg ludzki jest w naturalny sposób najlepiej przystosowany do takiego podejścia przy przetwarzaniu informacji. Klasa jest podstawowym pojęciem z zakresu projektowania (programowania) zorientowanego obiektowo (OOP). Z pojęciem tym wiążą się także cechy: abstrakcja, hermetyzacja, polimorfizm i dziedziczenie. W programowaniu obiektowym klasa jest częściową lub całkowitą definicją dla obiektów. Definicja obejmuje dopuszczalny stan obiektów oraz ich zachowania. Na podstawie klasy tworzy się obiekty. Pytania Czym jest klasa w OOP? Źródło: Wikipedia

Diagramy klas Wprowadzenie Diagramy klas. Odwzorowanie klasy i relacji w UML. Do odwzorowania klas w UML służą diagramy klas. Są to statyczne diagramy, przedstawiający strukturę systemu w modelach obiektowych przez ilustrację struktury klas i zależności między nimi. Ewidentnie strukturalny!!!! Brak dynamiki. Pokazuje jakie zachodzą zjawiska, ale nie pokazuje kiedy i jak zachodzą. W ramach diagramów klas przedstawia się klasy i interfejsy oraz związki pomiędzy nimi, a także ograniczenia, notatki itp. Wykorzystywane są do modelowania struktury systemu. Pytania Do czego służą i co zawierają diagramy klas UML? Źródło: Wikipedia

Wprowadzenie Symbol klasy: Diagramy klas Korzystając z UML można przedstawić modelowane elementy na różnych poziomach szczegółowości. Ważne jest, aby dostosować poziom szczegółowości do potrzeb, ukrywając nieistotne elementy. Dokładniej klasę opisuje się przedstawiając właściwości klasy (atrybuty) oraz zachowanie (metody): Pytania Do czego służą i co zawierają diagramy klas UML? Źródło: Wikipedia

Wprowadzenie Diagramy klas – atrybuty (właściwości) Definiując właściwości najczęściej określa się ich typ i widoczność: + element publiczny - element prywatny # element chroniony ~ element pakietowy Ogólny format dla definicji właściwości jest następujący: [widoczność] [/] nazwa [: typ] [wielokrotność] [ = wartość domyślna] [{ustawienia}] Np.: imieKlienta + imieKlienta - imieKlienta: string # imieKlienta: string = \"Jan\" + imieKlienta: string = \"Jan\" {readOnly} imieKlienta = \"Jan\" klienci[1..10] Pytania Co oznaczają i jaki mają zasięg poszczególne poziomy widoczności? Źródło: Wikipedia

Diagramy klas – atrybuty (właściwości) Wprowadzenie Z atrybutem mogą być związane dodatkowe ograniczenia, które określają jego właściwości, np.: {ordered} – obiekty wewnątrz cechy są uporządkowane {unordered} – obiekty są nieuporządkowane {sorted} – obiekty uporządkowane {unique} – obiekty wewnątrz cechy nie powtarzają się {nonunique} – obiekty wewnątrz cechy mogą się powtarzać {readOnly} – wartość atrybutu służy tylko do odczytu {frozen} – wartość atrybutu nie może być zmodyfikowana po jej przypisaniu

Wprowadzenie Diagramy klas - operacje Definiując operację także określa się ich typ i widoczność: Ogólny format dla definicji operacji jest następujący: [widoczność] nazwa [(lista_parametrów)] [: typ_wyniku] [właściwość] gdzie lista parametrów: [tryb] nazwa : typ [=wartość_domyślna] tryb: in - wejściowy, nie może być modyfikowany out - wyjściowy, może być modyfikowany inout - wejściowy, wyjściowy, może być modyfikowany właściwość: leaf - funkcja niepolimorficzna (nie może być nadpisana) isQuerry - funkcja nie zmieniająca obiektu Konstruktor też może być operacją, ale tylko wyjątkowo powinno się je umieszczać Pytania Jak definiuje się operacje klasy?

Relacje Wprowadzenie Relacje Czym są relacje pomiędzy klasami??? Relacje: klasa samochód i klasa koło są ze sobą jakoś powiązane Relacje mogą być wyrażane przez atrybuty lub asocjacje. Jest to zamienne. Asocjacje mogą mieć strzałki, wskazujące kierunek asocjacji. Pytania Co to są relacje w UML i jak się je odwzorowuje? Źródło: Wikipedia

Relacje Wprowadzenie Relacje są symbolizowane przez różne rodzaje linii. Mogą być wyrażane przez atrybuty lub asocjacje. Jest to zamienne. Wybór, które atrybuty mają być wpisane, a które asocjacyjne zależy od tego, na czym chcemy ”skupić” nasz diagram.

Asocjacje Wprowadzenie Asocjacja (ang. association) informuje, że jednak z klas „używa” obiektów innej klasy. Oznacza, że klasa będzie w rzeczywistości zawierać odwołanie do tej klasy w postaci atrybutu. Zależność asocjacji może zawierać grot kierunku (kierunek nawigacji), opisujący która klasa zawiera atrybut opisujący związek.

Krotności Wprowadzenie Z zależnościami, z których wynikają atrybuty klasy, wiąże się określenie krotności. Krotność pozwala określić minimalną i maksymalną liczbę obiektów, jakie można powiązać z daną cechą: dolna granica..górna granica – przedział od-do Np.: 1 – dokładnie jeden obiekt 0..1 – opcjonalnie jeden obiekt 1..* - przynajmniej jeden obiekt 1, 3, 5 – konkretne liczby obiektów * - dowolna liczba obiektów

W kodzie typowych języków programowania obiektowego brak jest Asocjacje Wprowadzenie Jeśli jakaś klasa jest częścią innego bytu można to wyróżnić poprzez zastosowanie: Agregacji całkowitej - zniszczenie obiektu nadrzędnego nie niszczy obiektu podrzędnego (samochód -> koło) Kompozycji - zniszczenie obiektu nadrzędnego niszczy obiekt podrzędny (dom -> pokój) W kodzie typowych języków programowania obiektowego brak jest Rozróżnienia dla agregacji częściowej i całkowitej. Występuje po prostu nowy atrybut.

Przykład Wprowadzenie Przykład agregacji całkowitej:

Uogólnienie (dziedziczenie) Wprowadzenie Uogólnienie (ang. generalization) opisuje klasy, które są szczególnym rodzajem innej klasy (posiada, jest rodzajem). W programowaniu klasę bardziej ogólną nazywa się klasą bazową.

Wprowadzenie Dziedziczenie wielokrotne i wielobazowe. Uogólnienie (dziedziczenie) Wprowadzenie Dziedziczenie wielokrotne i wielobazowe. Nie we wszystkich językach programowania obiektowego dziedziczenie wielobazowe jest wspierane.

Zależność Wprowadzenie Zależność: jeśli zmiany w jednej klasie mogą pociągać za sobą konieczność zmian w drugiej: Jedna klasa wysyła komunikat do drugiej Jednak klasa zawiera w sobie inną klasę Jedna klasa jest użyta w parametrach operacji innej klasy Zależności pozwalają na uchwycenie skali zmian związanych ze zmianami danej klasy. Można bardziej szczegółowo opisywać zależności za pomocą stereotypów. Może być skierowana lub nieskierowana.

Zależność Wprowadzenie Zależności można doprecyzować notatkami: Można także skorzystać z predefiniowanych stereotypów: «call» - operacje w klasie A wywołują operacje w klasie B «create» - klasa A tworzy instancje klasy B «instantiate» - obiekt A jest instancją klasy B «use» - do zaimplementowania klasy A wymagana jest klasa B

Ograniczenia Wprowadzenie Ograniczenia, np. krotność, uogólnienie Czasami na etapie projektowania klas projektant chce ograniczyć sposób działania klasy, czyli określone reguły, które powinny być spełnione. Ograniczenia zależą od specyfiki problemu. UML dopuszcza dowolną formę innych ograniczeń, np. poprzez notatki. Jedynym wymaganiem jest używanie nawiasów klamrowych do opisu ograniczenia.

Ograniczenia Wprowadzenie W zakresie projektowania systemów informatycznych zdefiniowany został specjalny format (język) OCL (Object Constraint Language) Zawiera trzy grupy ograniczeń: Niezmienniki, warunki wstępne, warunki końcowe

Klasy abstrakcyjne Wprowadzenie Klasa abstrakcyjna nie może mieć instancji. Aby wskazać, że kwestie implementacji danych operacji bądź całej klasy pozostawiamy do rozstrzygnięcia w klasach potomnych, zapisujemy te operacje czcionką pochyłą. Jeśli klasa jest abstrakcyjna, wszystkie jej operacje także są abstrakcyjne.

Interfejs Wprowadzenie Interfejs: nie posiada implementacji. Oznacza się stereotypem <<interface>> Interfejs może być wymagany (używany) przez klasę lub implementowany przez klasę. Klasa B realizuje klasę A, wtedy gdy implementuje jej wszystkie metody. Zazwyczaj klasa A jest interfejsem. Istnieje też „notacja piłeczkowa”.

Klasy szablonowe Wprowadzenie Szablony to inaczej sparametryzowane operacje (lub klasy) są przydatne wtedy, gdy chcemy opóźnić podjęcie decyzji, z jakimi klasami dana klasa ma współpracować.

Wykorzystanie diagramów klas Wprowadzenie Jak używać diagramów klas? Notacja jest bardzo bogata. Należy uważać, aby nie „przesadzić” W zastosowaniach biznesowych używa się diagramów klas aby „zrozumieć” pojęciowo zagadnienia biznesowe. W tej dziedzinie należy unikać dyskusji o oprogramowaniu. Znów – oszczędnie. Można same byty i powiązanie, bez atrybutów, metod. Zrozumieć biznes. Technicznie: Modelowanie struktury programu obiektowego – notacja dziedzinowa.

Wprowadzenie Zależność: Asocjacja: Agregacja częściowa: Związki pomiędzy klasami - posumowanie Wprowadzenie Zależność: Asocjacja: Agregacja częściowa: Agregacja całkowita: Dziedziczenie: Realizacja:

Przykład Wprowadzenie System zamówień

Przykład Wprowadzenie Symulator zdarzeń dyskretnych

Diagramy obiektów

Diagramy obiektów (object diagram) Obiekt (ang. object) może być opisany za pomocą: tożsamości, stanu i zachowania (zgodnie z definicją – jeśli istnieje – danego typu klasy). Moja_pralka Typ: Frania Nazwa modelu: kt100 Numer fabryczny: 012412 1976 Pojemność:7 kg Co można robić? Włożyć pranie Nasypać proszek Wyjąć ubrania

Diagramy obiektów (object diagram) Diagramy obiektów obrazują zbiór obiektów i związków między nimi. Przedstawia się na nich egzemplarze elementów z diagramów klas istniejące w wybranym momencie działania systemu. Instancje obiektów Notacja dla diagramów obiektów jest stosunkowo prosta. Wykorzystuje się je dla ukazania współdziałania ze sobą obiektów w określonej sytuacji. Instancja obiektu wyglądają następująco: Obiekt anonimowy

Diagramy obiektów (object diagram) Diagram klas a diagram obiektów:

Diagramy obiektów (object diagram) Diagramy obiektów – połączenia pomiędzy obiektami Diagramy obiektów (object diagram) Połączenia pomiędzy obiektami tworzy się aby wykazać możliwość ich wzajemnej komunikacji i współdziałania. Do połączenia można dołączyć etykietę oznaczającą przeznaczenie połączenia.

Diagramy obiektów (object diagram) Diagramy obiektów - przykład Diagramy obiektów (object diagram)

Diagramy obiektów (object diagram) Podsumowanie Diagramy obiektów (object diagram)