Projektowanie - klasy i związki

Prezentacja na temat: "Projektowanie - klasy i związki"— Zapis prezentacji:

1 Projektowanie - klasy i związki

2 Klasy w UML nazwa atrybuty operacje
Projektowanie - klasy i związki Klasy w UML nazwa atrybuty Oprócz powyższych sekcji (nazwa, atrybuty, operacje) klasa może zawierać sekcje zdefiniowane przez użytkownika, np. odpowiedzialność (opis w języku naturalnym zakresu odpowiedzialności klasy), zdarzenia (zdarzenia obsługiwane przez klasę) operacje

3 Projektowanie - klasy i związki
Składnia atrybutu widoczność nazwa: typ[krotność] = wartość-domyślna {własności} widoczność czy atrybut może być widoczny przez inne klasy nazwa nazwa atrybutu typ jaki rodzaj danych przechowuje atrybut krotność ile danych jest jednocześnie przechowywanych w atrybucie własności jakie są dodatkowe warunki nałożone na dane przechowywane w atrybucie wartość domyślna jaką wartość przyjmuje atrybut, jeśli nie została ona wprowadzona

4 Składnia atrybutu - widoczność
Projektowanie - klasy i związki Składnia atrybutu - widoczność widoczność – czy atrybut jest widoczny z poziomu innych klas Widoczność jest elementem opcjonalnym Widoczność nie posiada wartości domyślnej Poziomy widoczności: + publiczny (atrybut widoczny z dowolnego miejsca) # chroniony (atrybut widoczny dla własnej klasy i klas pochodnych) - prywatny (atrybut widoczny tylko wewnątrz własnej klasy) ~ publiczny wewnątrz pakietu (atrybut widoczny dla wszystkich klas zawartych w pakiecie) trzy pierwsze poziomy są zdefiniowane w UML UML pozwala na definiowanie poziomów widoczności zależnych od implementacji (np. publiczy wewnątrz pakietu)

5 Składnia atrybutu - typ
Projektowanie - klasy i związki Składnia atrybutu - typ typ – dziedzina wartości przechowywanych w atrybucie Typ jest opcjonalny i nie ma wartości domyślnej Typem atrybutu może być inny typ (klasa, interfejs) lub jeden z typów podstawowych UML definiuje 4 typy podstawowe typy danych: string - tekstowy integer - liczby całkowite real - liczby rzeczywiste boolean - wartości logiczne

6 Składnia atrybutu - krotność
Projektowanie - klasy i związki Składnia atrybutu - krotność krotność – ile danych może być jednocześnie przechowanych w atrybucie Krotność jest opcjonalna Wartością domyślną jest 1 Oznaczenia krotności: 1 – dokładnie 1 * – dowolna liczba 0..1 – co najwyżej 1 1..* – co najmniej 1

7 Składnia atrybutu – wartość początkowa
Projektowanie - klasy i związki Składnia atrybutu – wartość początkowa wartość-początkowa – wyrażenie określające wartość atrybutu zaraz po utworzeniu Wartości początkowe zapisuje się w postaci wyrażenia tekstowego Wartość początkowa jest opcjonalna

8 Składnia atrybutu - własności
Projektowanie - klasy i związki Składnia atrybutu - własności własności - definiują ograniczenia nałożone na atrybut Kolejność ordered – wartości atrybutów są uporządkowane unordered – wartości atrybutów mogą być nieuporządkowane (domyślna) Zmienność changable – wartości atrybutu mogą się zmieniać (domyślna) frozen – po inicjalizacji obiektu wartości atrybutu nie mogą być zmieniane, dodawane ani usuwane addOnly – kolejne wartości atrybutu mogą być dodawane, ale po dodaniu nie mogą być zmieniane i usuwane (ma znaczenie tylko dla krotności większych od jeden) Frozen = const, final

9 Projektowanie - klasy i związki
Zasięg Zasięg – wskazuje, czy występuję on w każdy obiekcie, czy też jest wspólny dla wszystkich obiektów instance – każdy obiekt przechowuje oddzielną wartość atrybutu (nie-statyczny) classifier – istnieje tylko jedna wartość atrybutu wspólna dla wszystkich obiektów (statyczny)

10 Zasięg Atrybuty statyczne (zasięg klasy)
Projektowanie - klasy i związki Zasięg Atrybuty statyczne (zasięg klasy) Nie wymaga utworzenia żadnego obiektu Służy do przechowywania danych odnoszących się do wszystkich obiektów Istnieje przez cały czas życia systemu Na diagramie oznacza się pokreśleniem Atrybuty nie-statyczne (zasięg obiektu) Wymaga utworzenia obiektu Służy do przechowywania danych odnoszących się do konkretnego obiektu Istnieje od momentu powstania do momentu usunięcia obiektu Na diagramie oznacza się zwykłym tekstem

11 Projektowanie - klasy i związki
Atrybuty pochodne Atrybut pochodny – wartość atrybutu może być obliczona na podstawie wartości innych atrybutów Formułę obliczającą wartość atrybutu definiuje się w postaci ograniczenia Mimo iż wprowadza redundancje jest używany zarówno w fazie analizy (może reprezentować jakieś znaczące pojęcie) jak i fazie projektowania (może przechowywać pewną wartość, której wielokrotne obliczanie jest kosztowne (optymalizacja)) Na diagramie oznacza się symbolem „/” przed nazwą atrybutu

12 Projektowanie - klasy i związki
Operacja Operacja – specyfikacja usługi, jaka może wykonana na obiekcie Wywołanie operacji może prowadzić do: zmiany stanu obiektu lub stanu systemu, tj. stanu innych obiektów uzyskania przez wywołującego określonych danych

13 Operacja a metoda operacja – specyfikacja usługi
Projektowanie - klasy i związki Operacja a metoda operacja – specyfikacja usługi metoda – implementacja operacji Operacja może posiadać wiele metod implementujących Operacja może być implementowana również w postaci procedury obsługi zdarzeń

14 Projektowanie - klasy i związki
Składnia operacji widoczność nazwa(param1, param2, …): zwracany-typ {własności} widoczność – czy operacja jest dostępna w innych klasach + publiczna # chroniona - prywatna ~ publiczna wewnątrz pakietu zwracany-typ – rodzaj wartości zwracanej przez operację typy podstawowe (string, integer, real, boolean) typy (klasy, interfejsy) zdefiniowane przez użytkownika

15 Składnia parametru (1) kierunek nazwa typ[krotność] = wartość domyślna
Projektowanie - klasy i związki Składnia parametru (1) kierunek nazwa typ[krotność] = wartość domyślna kierunek in - parametr jest przekazywany przez wywołującego, jego zmiana (w trakcie realizacji operacji) nie jest widoczna dla wywołującego (domyślnie) out – parametr nie jest ustawiany przez wywołującego, tylko przez operacje, a następnie zwracany do wywołującego inout - parametr jest przekazywany przez wywołującego, może być modyfikowany przez operację, a następnie przekazywany do wywołującego return – wartość parametru ustawiona przez wywołującego jest przekazywana z powrotem In – przekazujemy, operacja coś robi, ale efekt NIE jest dostępny (przekazywanie przez wartość) Out – nic nie przekazujemy, operacja cos robi i efekt JEST dostępny Inout – przekazujemy, operacja cos robi, efekt JEST dostępny Return – podobnie do out,

16 Projektowanie - klasy i związki
Składnia parametru (2) nazwa – nazwa operacji (musi być unikalna w obrębie listy parametrów) typ – rodzaj wartości przechowywanych w parametrze; dostępne są podstawowe typy danych (integer, string, real, boolean) oraz typy (klasy, interfejsy) zdefiniowane przez użytkownika krotność – określa ile wartości może być jednocześnie przechowanych w parametrze; możliwe wartości to: 0, 1, 0..1, *, 1..*, itp. wartość-domyślna – wyrażenie określające wartość parametru w sytuacji , gdy wywołujący jej nie przekaże

17 Składnia operacji – własności (1)
Projektowanie - klasy i związki Składnia operacji – własności (1) własności - definiują dodatkowe warunki nałożone na operację Współbieżność sequencial - obsługuje jednocześnie tylko jedno wywołanie - kolejne wywołanie może się pojawić po zakończeniu obsługi wcześniejszego guarded – obsługuje wiele jednoczesnych wywołań - będą one wstawione do kolejki i wykonywane sekwencyjnie concurrent – obsługuje wiele jednoczesnych wywołań – będą one wykonywane współbieżnie Domyślne ustawienie to sequencial. Sequencial NIE oznacza, że operacja nie może być jednocześnie wywoływana przez kilku klientów (wątków). Oznacza jedynie, że metoda implementująca operacje nie daje żadnej gwarancji tego co może się stać, jeśli kilku klientów będzie jednocześnie wywoływać operację (mogą sobie nawzajem przeszkadzać) Języki programowania posiadają mechanizmy do realizacji sekwencyjnego dostępu (quarded) –

18 Składnia operacji – własności (2)
Projektowanie - klasy i związki Składnia operacji – własności (2) Polimorfizm – czy implementacja operacji może być nadpisana w klasach pochodnych isPolimorphic = true – może być nadpisana isPolimorphic = false – nie może być nadpisana Zapytanie – czy operacja zmienia stan obiektów isQuery = true – operacja zmienia stan obiektu isQuery = false – operacja nie zmienia stanu obiektu

19 Operacja statyczne i nie-statyczne
Projektowanie - klasy i związki Operacja statyczne i nie-statyczne Operacja statyczna (zasięg klasy) – operacja wywoływana na rzecz klasy a nie poszczególnych obiektów nie może korzystać z atrybutów i operacji nie-statycznych może korzystać jedynie z danych globalnych i statycznych operacji i atrybutów na diagramie oznaczana zwykłym tekstem Operacja nie-statyczna (zasięg obiektu) – operacja wywoływana na rzecz konkretnego obiektu może korzystać z atrybutów i operacji statycznych jak i nie-statycznych na diagramie oznaczana tekstem pokreślonym

20 Projektowanie - klasy i związki
Interfejs Interfejs – zbiór operacji wyznaczających usługi oferowane przez klasę (lub komponent) Interfejs zawiera tylko specyfikację operacji, a nie atrybutów Klasa realizująca interfejs musi dostarczyć implementacji dla wszystkich operacji interfejsu Interfejs jest równoważny klasie abstrakcyjnej pozbawionej atrubutów i metod (implementujących) Klasa może realizować wiele interfejsów Powinno się używać terminu „klasa realizuje interfejs” lub „klasa implementuje interfejs”, a nie „klasa dziedziczy po interfejsie” Interfejs pełni rolę SPECYFIKACJI, klasa realizująca interfejs – rolę IMPLEMENTACJI, a sam związek pomiędzy specyfikacją a implementacją nosi nazwę REALIZACJI W przypadku interfejsu istotne jest rozróżnienie pomiędzy operacją a metodą, ponieważ interfejs zawiera specyfikację (czyli operacje) , a NIE MOŻĘ zawierać implementacji (czyli metod)

21 using System; interface Figury { double Obwod get; } double Pole();

22 class Kwadrat : Figury { public int bok_a; public Kwadrat(int a) bok_a = a; } public double Pole() return bok_a * bok_a; public double Obwod get return 4 * bok_a;

23 class Trojkat : Figury { public int bok_a, bok_b, bok_c, h; public Trojkat(int a, int b, int c, int wysokosc) bok_a = a; bok_b = b; bok_c = c; h = wysokosc; } public double Pole() { return 0.5 * bok_a * h; public double Obwod get return bok_a + bok_b + bok_c;

24 class Pokaz { public static void Main() Kwadrat kw = new Kwadrat(5); Trojkat troj = new Trojkat(10, 5, 7, 8); Figury wybrany; string wybor; Console.Write("1- KWADRAT\n2- TRÓJKĄT\nWyboór: "); wybor = Console.ReadLine(); switch (wybor) case "1": wybrany = kw; break; case "2": wybrany = troj; default: return; } Console.WriteLine("\n\nPole: " + wybrany.Pole() + " obwód: " + wybrany.Obwod);

25

26 Interfejs - przykłady lub
Projektowanie - klasy i związki Interfejs - przykłady specyfikacja lub realizacja implementacja Interfejs ISortowalny zawiera specyfikację operacji Sortuj() Klasa KatalogAutorski musi zawierać implementację operacji Sortuj()

27 Związki między klasami
Projektowanie - klasy i związki Związki między klasami Zależność Asocjacja Agregacja Kompozycja Generalizacja

28 Zależność Zależność – związek użycia jednego elementu przez inny
Projektowanie - klasy i związki Zależność Zależność – związek użycia jednego elementu przez inny Jeśli klasy są zależne, to zmiany dokonane w specyfikacji jednej z klas mogą mieć wpływ na drugą klasę Związki typu asocjacja, agregacja, kompozycja, czy uogólnienie również oznaczają zależność (terminu „zależność” używamy wtedy, gdy związek nie ma charakteru strukturalnego; jeśli jest to związek strukturalny, wówczas mówimy o asocjacji, agregacji, itd.) Zależność jest najsłabszym rodzajem związku Na diagramie zależność przedstawia się przerywaną linią z grotem wskazującym kierunek zależności

29 Zależność – skąd się bierze?
Projektowanie - klasy i związki public class KlasaB { ... public static void Metoda1() { } public class KlasaA { //zależy od klasy KlasaB // używa argumentu typu Klasa B public void Metoda1(KlasaB b) {   // zwraca obiekt typu KlasaB public KlasaB Metoda2() {   // zawiera zmienną typu KlasaB public void Metoda3() { KlasaB b   // wywołuje statyczną metodę na klasaB public void Metoda4() { KlasaB.Metoda1(); Zależność A od B: jeśli metoda klasy A używa klasy B jako parametru zwraca obiekt klasy B w swoim ciele zawiera jakiekolwiek odwołanie do klasy B (np. zmienne lokalne, wywołanie statycznej metody klasy B)  Przykłady zawierają jedynie kilka najczęściej spotykanych źródeł zależności Na oznaczenie zależności używa się stereotypów <<use>> <<instantiate>> i wiele wiele innych. Nie sa jednak zbyt często stosowane w praktyce

30

31 class Kolory { public enum Kolor czerwony, żółty, zielony }

32 public partial class Formularz : Form
{ public Formularz() InitializeComponent(); } private void Formularz_Load(object sender, EventArgs e) foreach (string wartosc in Enum.GetNames(typeof(Kolory.Kolor))) Lista.Items.Add(Enum.Parse(typeof(Kolory.Kolor), wartosc));

33

34 Projektowanie - klasy i związki
Asocjacja Asocjacja – związek o charakterze strukturalnym między dwiema lub większą liczbą klas wynikający z istnienia powiązań między obiektami tych klas Cechy asocjacji: Nazwa – znaczenie związku Rola – powinność jaką pełni obiekt jednej klasy wobec obiektu innej klasy Krotność - maksymalna i minimalna liczbę obiektów jednej klasy powiązanych z jednym obiektem innej klasy

35 Cechy asocjacji – nawigacja
Projektowanie - klasy i związki Cechy asocjacji – nawigacja Nawigacja – możliwość bezpośredniego przejścia z obiektu jednej klasy do obiektu drugiej klasy Kierunek nawigacji: asocjacja jednokierunkowa asocjacja dwukierunkowa (domyślnie) W dużej części zastosowań wystarcza, by asocjacja była jednokierunkowa Asocjacja jednokierunkowa nie oznacza automatycznie, że nie ma możliwości przejścia w kierunku przeciwnym niż kierunek nawigacji. Oznacza jedynie, że takie przejście nie jest możliwe bezpośrednio, może być jednak możliwe poprzez inne związki Zaleca się używanie unikanie asocjacji dwukierunkowych. Utrzymanie nawigacji dwustronnej jest kosztowne – wymaga większych nakładów programistycznych

36 Notacja UML asocjacja jednokierunkowa asocjacja dwukierunkowa
Projektowanie - klasy i związki Notacja UML asocjacja jednokierunkowa Asocjacje dwukierunkową oznacza się również strzałkami w obydwu kierunkach asocjacja dwukierunkowa

37 Asocjacja 1-1 – przykładowa realizacja
Projektowanie - klasy i związki Asocjacja 1-1 – przykładowa realizacja asocjacja 1-1 jednokierunkowa realizacja poprzez dodanie atrybutu w klasie A asocjacja 1-1 dwukierunkowa realizacja poprzez dodanie atrybutów w obydwu klasach

38 Asocjacja 1-1 - implementacja
Projektowanie - klasy i związki Asocjacja implementacja // jednokierunkowa public class KlasaA { ... private KlasaB b } public class KlasaB { // dwukierunkowa public class KlasaA { ... private KlasaB b } public class KlasaB { private KlasaA a

39 Asocjacja 1-1 - implementacja

40 Asocjacja 1-1 - implementacja
public class Student { public string Nazwisko; public string Imie; public Adres AdresStudenta; } public class Adres { public String Miasto; public String KodPocztowy; public String Ulica; public String nrDomu; }

41 Asocjacja 1-1 - implementacja
public partial class Form1 : Form { Student _student = new Student(); public Form1() InitializeComponent(); } private void button1_Click(object sender, EventArgs e) _student.Nazwisko = Nazwisko.Text; WynikNazwisko.Text = _student.Nazwisko; _student.AdresStudenta = new Adres(); _student.AdresStudenta.Miasto = Miasto.Text; WynikMiasto.Text = _student.AdresStudenta.Miasto;

42 Asocjacja 1-1 - implementacja

43 Asocjacja 1-1 - implementacja

44 Asocjacja 1-* - przykładowa realizacja
Projektowanie - klasy i związki Asocjacja 1-* - przykładowa realizacja realizacja poprzez dodanie atrybutu w klasie A asocjacja 1-* jednokierunkowa asocjacja 1-* jednokierunkowa realizacja poprzez dodanie atrybutu w klasie B asocjacja 1-* jednokierunkowa realizacja poprzez dodanie atrybutów w obydwu klasach

45 Implementacja (2) // jednokierukowa od 1 do * public class KlasaA {
Projektowanie - klasy i związki // jednokierukowa od 1 do * public class KlasaA { ... private KlasaB b[10] } public class KlasaB { // jednokierukowa od * do 1 public class KlasaA { ... private KlasaB b } public class KlasaB { // dwukierunkowa public class KlasaA { ... private KlasaB b[10] } public class KlasaB { private KlasaA a

46 Asocjacja 1-* - przykład

47 public partial class ListaStudentow : Form
{ public ListaStudentow() InitializeComponent(); } private void button1_Click(object sender, EventArgs e) Studenci _dodajstudenta = new Studenci(); _dodajstudenta.ShowDialog(); private void button2_Click(object sender, EventArgs e) foreach (Student _student in Studenci.listaStudentow) Lista.Text += _student.Imie + " " + _student.Nazwisko + " " + _student.adres.Miasto + "\r" + "\n";

48 public partial class Studenci : Form
{ protected Adres _adres = new Adres(); public static ArrayList listaStudentow = new ArrayList(); public Studenci() InitializeComponent(); } private void button1_Click(object sender, EventArgs e) string _nazwisko = Nazwisko.Text; string _imie = Imie.Text; _adres.Miasto = Miasto.Text; Student _student = new Student(_nazwisko, _imie, _adres); WynikNazwisko.Text = _student.Nazwisko; WynikImie.Text = _student.Imie; WynikMiasto.Text = _student.adres.Miasto; listaStudentow.Add(_student);

49 public class Student { protected string _imie; public string Imie get { return this._imie; } } protected string _nazwisko; public string Nazwisko get { return this._nazwisko; } protected Adres _adres; public Adres adres get { return _adres; } public Student(string nazwisko, string imie, Adres adres) this._imie = imie; this._nazwisko = nazwisko; this._adres = adres;

50 Asocjacja 1-* - przykład

51 Asocjacja 1-* - przykład

52 Asocjacja 1-* - przykład

53 Asocjacja 1-* - przykład

54 Projektowanie - klasy i związki
Agregacja Agregacja – rodzaj asocjacji, gdzie obiekty jednej klasy pełnią rolę całości a obiekty innej klasy rolę części, przy obiekty pełniące rolę części mogą należeć do kilku obiektów pełniących rolę całości Obiekt cześć może istnieć niezależnie od obiektu typu całość Agregacja jest związkiem niesymetrycznym (samochód zawiera silnik, ale silnik nie zawiera samochodu) i przechodnim (samochód zawiera silnik, silnik zawiera cylinder  samochód zawiera cylinder) Pod względem syntaktycznym agregacja jest zwykłą asocjacją, różnice istnieją jedynie w sferze semantycznej (znaczeniowej)

55 Projektowanie - klasy i związki
Agregacja - przykład Obiekt klasy KatalogAutorski jest agregatem (całość) dla obiektów typu Autor (część) Obiekt klasy Autor nie jest wyłączną własnością obiektu klasy KatalogAutorski, Może np. istnieć obiekt klasy Książka zawierający obiekty klasy Autor (na diagramie zaznaczono zwykłą asocjację, ale może to być również agregacja)

56 Projektowanie - klasy i związki
Kompozycja - przykład Kompozycja - rodzaj asocjacji, gdzie obiekty jednej klasy pełnią rolę całości a obiekty innej klasy rolę części, przy obiekt pełniące rolę części może w danym momencie należeć tylko do jednego obiektu typu całość Cykl życia obiektu część zawiera się w cyklu życia obiektu całość Obiekt całość jest wyłącznym właścicielem obiektów część Obiekt całość jest odpowiedzialny za tworzenie, inicjowanie i usuwanie obiektów cześć

57 Projektowanie - klasy i związki
Kompozycja - przykład Obiekt klasy Tom jest wyłączną własnością obiektu klasy Książka Obiekt klasy Tom nie może być powiązany z obiektami klas innych niż Książka Czas życia obiektu klasy Tom mieści się w czasie życia obiektu klasy Książka

58 Asocjacja kwalifikowana
Projektowanie - klasy i związki Asocjacja kwalifikowana Asocjacja kwalifikowana – asocjacja z wydzielonym atrybutem (jednym lub wieloma) jednoznacznie identyfikującym obiekt (lub grupę obiektów) po drugiej związku Atrybut realizujący asocjacje kwalifikowaną nazywa się kwalifikatorem asocjacji W roli kwalifikatorów najczęściej występują identyfikatory obiektów (np. idProdukt, idStudent) Kwalifikator może odnosić się tylko do asocjacji o krotnościach jeden-do-wiele lub wiele-do-wiele

59 Asocjacja kwalifikowana - przykład
Projektowanie - klasy i związki Asocjacja kwalifikowana - przykład public class Katalog { ... private Hashtable produkty } public class Produkt { ... } Zmiana krotności po zastosowaniu asocjacji kwalifikowanej: Krotność związku Katalog-Produkt wynosi 1-*. Jeśli w miejsce Katalog podstawimy konstrukcję „Katalog+idProdukt” to krotność związku „Katalog+idProdukt”-”Produkt” zredukuje się do Do implementacji asocjacji kwalifikowanej używa się tablic asocjacyjnych (tablic haszujących ) Krotność po zastosowaniu asocjacji kwalifikowanej 1-* ulega redukcji do 1-1 lub

60 Projektowanie - klasy i związki
Klasa asocjacyjna Klasa asocjacyjna – klasa posiadająca cechy asocjacji lub asocjacja posiadająca cechu klasy Pozwala na dodanie do asocjacji nowych składowych, takich jak atrybuty i operacje Klas asocjacyjnych używa się do modelowania bardziej złożonych asocjacji, tj. asocjacji posiadających pewne cechy, które nie mogą być przypisane do żadnej z klas uczestniczących w asocjacji Dla każdego powiązania (instancji asocjacji) istnieje jeden obiekt klasy asocjacyjnej

61 Klasa asocjacyjna - przykład
Projektowanie - klasy i związki Klasa asocjacyjna - przykład Każdy obiekt klasy PozycjaZamówienia jest wynikiem istnienia powiązania pomiędzy konkretnym obiektem klasy Zamówienie a konkretny obiektem klasy Produkt Klasa PozycjaZamówienia posiada cechy (np. ilość), które nie mogą być przypisane do żadnych z klas Zamówienie i Produkt

62 Projektowanie - klasy i związki
Uogólnienie Uogólnienie (Generalizacja) – związek pomiędzy elementem ogólnym i jego specyficznym rodzajem Element ogólny nazywany jest nadklasą (rodzic), element specyficzny – podklasą (dziecko) Dziecko dziedziczy strukturę i zachowanie rodzica, może również posiadać swoje własne cechy strukturalne i zachowanie Każda instancja podklasy jest jednocześnie instancją nadklasy – stąd instancja podklasy może być użyty w miejsce instancji nadklasy Uogólnienie tworzy hierarchę klas, od najbardziej ogólnych do najbardziej szczegółowych

63 Notacja UML nadklasa (rodzic) Uogólnienie podklasy (dzieci)
Projektowanie - klasy i związki Notacja UML nadklasa (rodzic) Uogólnienie podklasy (dzieci)

64 Uogólnienie a dziedziczenie
Projektowanie - klasy i związki Uogólnienie a dziedziczenie uogólnienie – związek pomiędzy elementem ogólnym i jego specyficznym rodzajem dziedziczenie – sposób realizacji związku uogólnienia, tj. mechanizm konstrukcji klasy potomnej na podstawie klasy bazowej poprzez dodawanie/przesłanianie składowych. Dziedziczenie to rozszerzanie klasy bazowej 1. Pojęcia uogólnienia i dziedziczenia mimo iż nie znaczą dokładnie to samo, są jednak blisko spokrewnione i bywają używane zamiennie, i nie jest to poważne nadużycie 2. Warto jednak zaznaczyć, że dziedziczenie jest tylko jednym z możliwych sposobów na realizację związku uogólnienia

65 Właściwości klasy w kontekście uogólnienia -
Projektowanie - klasy i związki Właściwości klasy w kontekście uogólnienia - Czy klasa może posiadać instancje? abstract=true – klasa nie może posiadać instancji (klasa abstrakcyjna) abstract=false – klasa może posiadać instancje (klasa konkretna) root – klasa nie może posiadać klasy nadrzędnej (nadklasy) – klasa znajdująca się na szczycie hierarchii leaf – klasa nie może posiadać klas pochodnych (podklas) – klasa znajdująca się dole hierarchii Formalnie rzecz ujmując również root i leaf przyjmują wartość true i false. W praktyce użycie root, leaf i abstract jest traktowane jak root=true, leaf=true i abstract=true Klasy abstrakcyjne oznacza się pismem pochyłym Klasa jest abstrakcyjna jeśli użyjemy {abstract} przynajmniej jedna z operacji jest abstrakcyjna (automatycznie jest abstrakcyjna)

66 Uogólnienie - właściwości
Projektowanie - klasy i związki Uogólnienie - właściwości Czy podział jest kompletny? complete – nie można tworzyć nowych podklas incomplete – można tworzyć nowe podklasy Czy podział jest rozłączny? disjoint – obiekt może należeć tylko do jednej klasy overlapping – obiekt może należeć do kilku klas

67 incomplete Aktor Reżyser Osoba {incomplete}
Projektowanie - klasy i związki incomplete Jerzy Stuhr Małgorzata Foremniak Krzysztof Kieślowski Osoba Aktor Reżyser {incomplete} Jan Kowalski Problem: Rozważmy zbiór osób i dwa jego podzbiory: aktorzy i reżyserzy Q: Czy istnieją osoby nie należące do żadnego z tych podzbiorów? A: Istnieje osoba (Jan Kowalski), która nie jest ani aktorem ani reżyserem Wniosek: Podział na podzbiory nie jest kompletny (incomplete) W UML incomplete oznacza: Obiekt może nie należeć do żadnej z podklas: Aktor i Reżyser można tworzyć nowe podklasy

68 incomplete - implementacja
Projektowanie - klasy i związki incomplete - implementacja // klasa konkretna public class Osoba { ... } {incomplete} // klasa konkretna public class Aktor : Osoba { ... } Wszystkie klasy są konkretne Można utworzyć obiekt (klasy Osoba), który nie należy do żadnej z podklas Aktor i Reżyser // klasa konkretna public class Rezyser : Osoba { ... }

69 complete Osoba Dorosły {complete} Dziecko
Projektowanie - klasy i związki complete Wiktoria, lat 4 Zuzia, lat 8 Ryszard, lat 35 Osoba Dorosły {complete} Dziecko Agnieszka, lat 25 Problem: Rozważmy zbiór osób i dwa jego podzbiory: dzieci i dorośli Q: Czy istnieją osoby nie należące do żadnego z tych podzbiorów? A: Nie istnieje takie osoby Wniosek: Podział na podzbiory jest kompletny (complete) W UML complete oznacza: Obiekt należy do co najmniej jednej podklasy: Dziecko lub Dorosły wszystkie podklasy zostały już utworzone - nie można tworzyć nowych podklas

70 complete - implementacja
Projektowanie - klasy i związki complete - implementacja // klasa konkretna public abstract class Osoba { ... } {complete} // klasa konkretna public class Dziecko : Osoba { ... } Klasy Dziecko i Dorosły są konkretne, klasa Osoba jest abstrakcyjna (nie może mieć wystąpień) Każdy utworzony obiekt musi należeć do jednej z dwóch klas Dziecko i Dorosły // klasa konkretna public class Dorosly : Osoba { ... }

71 overlapped Aktor Reżyser Osoba {overlapped}
Projektowanie - klasy i związki overlapped Jerzy Stuhr Małgorzata Foremniak Krzysztof Kieślowski Osoba Aktor Reżyser {overlapped} Jan Kowalski Problem: Rozważmy zbiór osób i dwa jego podzbiory: aktorzy i reżyserzy Q: Czy istnieją osoby, które są jednocześnie aktorem i reżyserem? A: Istnieje osoba (Jerzy Stuhr), która jest aktorem i reżyserem Wniosek: podzbiory nakładają się na siebie (overlapped) W UML overlapped oznacza: Obiekt może należeć do kliku podklas: Aktor i Reżyser

72 overlapped – implementacja (1)
Projektowanie - klasy i związki overlapped – implementacja (1) public class Osoba { ... } {overlapped} public class Aktor : Osoba { ... } public class Rezyser : Osoba { ... } {disjoint} Nowa klasa GrającyRezyser dziedziczy po klasie Osoba Osoba będąca jednocześnie reżyserem i aktorem należą do klasy GrajacyRezyser public class GrajacyRezyser : Osoba { ... }

73 overlapped – implementacja (2)
Projektowanie - klasy i związki overlapped – implementacja (2) public class Osoba { ... private Aktor aktor; private Rezyser rezyser; } {overlapped} public class Aktor { ... } public class Rezyser { ... } Klasa Osoba zawiera atrybuty typu Aktor i Reżyser W miejsce kompozycji można użyć agregację lub zwykłą asocjację

74 disjoint Osoba Dorosły {disjoint} Dziecko
Projektowanie - klasy i związki disjoint Wiktoria, lat 4 Zuzia, lat 8 Ryszard, lat 35 Osoba Dorosły {disjoint} Dziecko Agnieszka, lat 25 Problem: Rozważmy zbiór osób i dwa jego podzbiory: dzieci i dorośli Q: Czy istnieją osoby, które są jednocześnie dzieckiem i dorosłym? A: Nie istnieją takie osoby Wniosek: Podział na podzbiory jest rozłączny (disjoint) W UML disjoint oznacza: Obiekt może należeć do co najwyżej jednej podklasy: Dziecko albo Dorosły

75 disjoint - implementacja
Projektowanie - klasy i związki disjoint - implementacja public class Osoba { ... } {disjoint} // klasa konkretna public class Dziecko : Osoba { ... } W języku C# (tak jak wielu innych) podklasy z definicji są rozłączne // klasa konkretna public class Dorosly : Osoba { ... }

76 Własności uogólnienia – dopuszczalne kombinacje
Projektowanie - klasy i związki Własności uogólnienia – dopuszczalne kombinacje {incomplete, disjoint} – obiekt t należy do podklas {complete, disjoint} – obiekt t należy do podklas {incomplete, overalapped} – obiekt t należy do 0..* podklas {complete, overllaped} – obiekt t należy do 1..* podklas Interpretacja {incomplete, disjoint} obiekt może nie należeć do żadnej podklasy (incomplete) lub może należeć do jakiejś podklasy, ale tylko do jednej (disjoint) {complete, disjoint} każdy obiekt należy do jakiejś poklasy (complete) i tylko do jednej (disjoint) {incomplete, overlapped} – obiekt może nie należeć do żadnej z podklas (incomplete) lub może też należeć do kilku (overlapped) {complete, overlapped} – każdy obiekt należy do jakiejś poklasy (complete), może też należeć do kilku (overlapped)

77 Dziedziczenie wielokrotne
Projektowanie - klasy i związki Dziedziczenie wielokrotne dziedziczenie jednokrotne (jednobazowe) – klasa posiada tylko jedną klasę bezpośrednio nadrzędną dziedziczenie wielokrotne (wielobazowe) – klasa posiada więcej niż jedną klasę bezpośrednio nadrzędną jednokrotne Dziedziczenie wielokrotne (w odniesieniu do klas) nie posiadają takie języki jak C# i Java. wielokrotne obiekty klasy GrającyReżyser posiadają wszystkie składowe klas: Aktor i Reżyser

78 Dziedziczenie wielokrotne - implementacja
Projektowanie - klasy i związki Dziedziczenie wielokrotne - implementacja public class Osoba { ... private Aktor aktor; private Rezyser rezyser; } public class Aktor { ... } public class Rezyser { ... } Klasa Osoba zawiera atrybuty typu Aktor i Reżyser Dziedziczenie wielokrotne implementujemy tak jak overlapped

79 Dziedziczenie wieloaspektowe
Projektowanie - klasy i związki Dziedziczenie wieloaspektowe dziedziczenie jednoaspektowe – istnieje jedno kryterium tworzenia klas pochodnych (jeden aspekt specjalizacji) dziedzicznie wieloaspektowe – istnieje więcej niż jedno kryterium tworzenia klas pochodnych (kilka aspektów specjalizacji) 1. Aspekt specjalizacji (dyskryminator) musi być użyty w dziedziczeniu wieloaspektowym. 2. W dziedziczeniu jednoaspektowym dyskryminator jest opcjonalny aspekty specjalizacji (dyskryminatory ) zawód wiek

80 Klasyfikacja dynamiczna
Projektowanie - klasy i związki Klasyfikacja dynamiczna klasyfikacja statyczna – obiekt w trakcie swojego cyklu życiowego przypisany jest do jednej klasy klasyfikacja dynamiczna – obiekt w trakcie swojego cyklu życia może zmieniać przynależność do klas <<dynamic>> Związek przynależność obiektów do określonych klas określa się terminem KLASYFIKACA. Ze względu jednak na to, że w UML do tego celu można użyć generalizacji/dziedziczenia – klasyfikację statyczna i dynamiczną określa się często terminem dziedziczenie statyczne i dynamiczne np. Zuzia (lat 8): do momentu ukończenia przez Zuzie 18 lat przedstawiana jest w systemie jako obiekt klasy Dziecko, po ukończeniu 18 lat staje się obiektem klasy Dorosły

81 dynamic – implementacja (3)
Projektowanie - klasy i związki dynamic – implementacja (3) public class Osoba { ... private IWiek wiek; } {dynamic} public class Dorosły: IWiek { ... } {XOR} Współczesne języki programowania nie wspierają bezpośrednio mechanizmu dynamicznej klasyfikacji public class Dziecko : IWiek { ... } public interface IWiek { ... }

82 Związki - podsumowanie
Projektowanie - klasy i związki Związki - podsumowanie używa  ZALEŻNOŚĆ jest rodzajem  GENERALIZACJA jest powiązany  ASOCJACJA całość-część (bez wyłączności)  AGREGACJA całość-część (wyłączność)  KOMPOZYCJA

83 Siła związków Zależność Asocjacja Agregacja Kompozycja Uogólnienie
Projektowanie - klasy i związki Siła związków najsłabsze Zależność Asocjacja Agregacja Kompozycja najmocniejsze Uogólnienie

84 Projektowanie - klasy i związki
Litaratura Grady Booch, James Rumbaugh, Ivar Jacobson: UML Przewodnik użytkownika Grady Booch, James Rumbaugh, Ivar Jacobson: UML Reference Manual Kazimierz Subieta: Projektowanie systemów informatycznych – wykłady ria_oprogramowania