Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Projektowanie - klasy i związki. Klasy w UML Projektowanie - klasy i związki 2 nazwa atrybuty operacje.

Podobne prezentacje


Prezentacja na temat: "Projektowanie - klasy i związki. Klasy w UML Projektowanie - klasy i związki 2 nazwa atrybuty operacje."— Zapis prezentacji:

1 Projektowanie - klasy i związki

2 Klasy w UML Projektowanie - klasy i związki 2 nazwa atrybuty operacje

3 Składnia atrybutu Projektowanie - klasy i związki 3 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 widoczność nazwa: typ[krotność] = wartość-domyślna {własności}

4 Składnia atrybutu - widoczność 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) Projektowanie - klasy i związki 4 widoczność – czy atrybut jest widoczny z poziomu innych klas

5 Składnia atrybutu - typ 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 Projektowanie - klasy i związki 5 typ – dziedzina wartości przechowywanych w atrybucie

6 Składnia atrybutu - krotność 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 Projektowanie - klasy i związki 6 krotność – ile danych może być jednocześnie przechowanych w atrybucie

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

8 Składnia atrybutu - własności 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) Projektowanie - klasy i związki 8 własności - definiują ograniczenia nałożone na atrybut

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

10 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 Projektowanie - klasy i związki 10

11 Atrybuty pochodne 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 Projektowanie - klasy i związki 11 Atrybut pochodny – wartość atrybutu może być obliczona na podstawie wartości innych atrybutów

12 Operacja 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 Projektowanie - klasy i związki 12 Operacja – specyfikacja usługi, jaka może wykonana na obiekcie

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

14 Składnia operacji 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 Projektowanie - klasy i związki 14 widoczność nazwa(param1, param2, …): zwracany-typ {własności}

15 Składnia parametru (1) 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 Projektowanie - klasy i związki 15 kierunek nazwa typ[krotność] = wartość domyślna

16 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 Projektowanie - klasy i związki 16

17 Składnia operacji – własności (1) 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 Projektowanie - klasy i związki 17 własności - definiują dodatkowe warunki nałożone na operację

18 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 Projektowanie - klasy i związki 18

19 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 Projektowanie - klasy i związki 19

20 Interfejs 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 Projektowanie - klasy i związki 20 Interfejs – zbiór operacji wyznaczających usługi oferowane przez klasę (lub komponent)

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; break; default: return; } Console.WriteLine("\n\nPole: " + wybrany.Pole() + " obwód: " + wybrany.Obwod); }

25

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

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

28 Zależność 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 Projektowanie - klasy i związki 28 Zależność – związek użycia jednego elementu przez inny

29 Zależność – skąd się bierze? Projektowanie - klasy i związki 29 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 1.używa klasy B jako parametru 2.zwraca obiekt klasy B 3.w swoim ciele zawiera jakiekolwiek odwołanie do klasy B (np. zmienne lokalne, wywołanie statycznej metody klasy B)

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 Asocjacja 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 Projektowanie - klasy i związki 34 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

35 Cechy asocjacji – nawigacja 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 Projektowanie - klasy i związki 35 Nawigacja – możliwość bezpośredniego przejścia z obiektu jednej klasy do obiektu drugiej klasy

36 Notacja UML Projektowanie - klasy i związki 36 asocjacja jednokierunkowa asocjacja dwukierunkowa

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

38 Asocjacja implementacja Projektowanie - klasy i związki 38 // 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 implementacja

40 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 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 implementacja

43

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

45 Projektowanie - klasy i związki 45 // 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... } Implementacja (2)

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

52

53

54 Agregacja 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) Projektowanie - klasy i związki 54 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

55 Agregacja - przykład Projektowanie - klasy i związki 55 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 Kompozycja - przykład 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ść Projektowanie - klasy i związki 56 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ść

57 Kompozycja - przykład Projektowanie - klasy i związki 57 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 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 Projektowanie - klasy i związki 58 Asocjacja kwalifikowana – asocjacja z wydzielonym atrybutem (jednym lub wieloma) jednoznacznie identyfikującym obiekt (lub grupę obiektów) po drugiej związku

59 Asocjacja kwalifikowana - przykład Projektowanie - klasy i związki 59 public class Katalog {... private Hashtable produkty... } public class Produkt {... } 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 Klasa asocjacyjna 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 Projektowanie - klasy i związki 60 Klasa asocjacyjna – klasa posiadająca cechy asocjacji lub asocjacja posiadająca cechu klasy

61 Klasa asocjacyjna - przykład Projektowanie - klasy i związki 61 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 Uogólnienie 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 Projektowanie - klasy i związki 62 Uogólnienie (Generalizacja) – związek pomiędzy elementem ogólnym i jego specyficznym rodzajem

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

64 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 Projektowanie - klasy i związki 64

65 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 Projektowanie - klasy i związki 65

66 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 Projektowanie - klasy i związki 66

67 incomplete Projektowanie - klasy i związki 67 W UML incomplete oznacza: 1.Obiekt może nie należeć do żadnej z podklas: Aktor i Reżyser 2. można tworzyć nowe podklasy AktorReżyser 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 ) {incomplete} Małgorzata Foremniak Jerzy Stuhr Jan Kowalski Krzysztof Kieślowski Osoba

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

69 complete Projektowanie - klasy i związki 69 W UML complete oznacza: 1.Obiekt należy do co najmniej jednej podklasy: Dziecko lub Dorosły 2.wszystkie podklasy zostały już utworzone - nie można tworzyć nowych podklas 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 ) Zuzia, lat 8 Wiktoria, lat 4 Agnieszka, lat 25 Ryszard, lat 35 Osoba Dziecko Dorosły {complete}

70 complete - implementacja Projektowanie - klasy i związki 70 // klasa konkretna public class Dziecko : Osoba {... } // klasa konkretna public class Dorosly : Osoba {... } // klasa konkretna public abstract class 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 {complete}

71 overlapped Projektowanie - klasy i związki 71 W UML overlapped oznacza: 1.Obiekt może należeć do kliku podklas: Aktor i Reżyser AktorReżyser 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 ) {overlapped} Małgorzata Foremniak Jerzy Stuhr Jan Kowalski Krzysztof Kieślowski Osoba

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

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

74 disjoint Projektowanie - klasy i związki 74 W UML disjoint oznacza: 1.Obiekt może należeć do co najwyżej jednej podklasy: Dziecko albo Dorosły 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 ) Zuzia, lat 8 Wiktoria, lat 4 Agnieszka, lat 25 Ryszard, lat 35 Osoba Dziecko Dorosły {disjoint}

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

76 Własności uogólnienia – dopuszczalne kombinacje {incomplete, disjoint} – obiekt t należy do 0..1 podklas {complete, disjoint} – obiekt t należy do 1..1 podklas {incomplete, overalapped} – obiekt t należy do 0..* podklas {complete, overllaped} – obiekt t należy do 1..* podklas Projektowanie - klasy i związki 76

77 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ą Projektowanie - klasy i związki 77 jednokrotne wielokrotne obiekty klasy GrającyReżyser posiadają wszystkie składowe klas: Aktor i Reżyser

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

79 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) Projektowanie - klasy i związki 79 zawód wiek aspekty specjalizacji (dyskryminatory )

80 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 Projektowanie - klasy i związki 80 > 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 D orosły

81 dynamic – implementacja (3) Projektowanie - klasy i związki 81 public class Dorosły: IWiek {... } public class Dziecko : IWiek {... } public class Osoba {... private IWiek wiek;... } {dynamic} {XOR} public interface IWiek {... }

82 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 Projektowanie - klasy i związki 82

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

84 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 Projektowanie - klasy i związki 84


Pobierz ppt "Projektowanie - klasy i związki. Klasy w UML Projektowanie - klasy i związki 2 nazwa atrybuty operacje."

Podobne prezentacje


Reklamy Google