Projektowanie - klasy i związki

Slides:



Advertisements
Podobne prezentacje
C++ wykład 2 ( ) Klasy i obiekty.
Advertisements

C++ wykład 4 ( ) Przeciążanie operatorów.
Programowanie obiektowe
Związki w UML.
Programowanie obiektowe
Programowanie obiektowe
Modelowanie klas i obiektów
Wzorce.
Agregacja Agregacja jest rodzajem asocjacji; zadaniem agregacji jest modelowanie związku całość-część. agregacja jest asocjacją: dla obu jej końców są.
Sposoby implementacji asocjacji
Sposoby obejścia dziedziczenia
Kamil Łącki Dominik Strzelichowski
Implementacja asocjacji
Programowanie obiektowe w Javie
Bartosz Walter Prowadzący: Bartosz Walter
Mapowanie różnych typów dziedziczenia do Javy
Struktury.
C++ wykład 2 ( ) Klasy i obiekty.
Zasady zaliczenia Warunki uzyskania zaliczenia:
Unified Modeling Language Wykład 3 Diagram klas
DIAGRAMY KLAS i obiektów
Diagramy klas w języku UML
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Hibernate relacje.
Projektowanie - wprowadzenie
Projektowanie dynamiki - diagramy interakcji
Wykład 4 Analiza i projektowanie obiektowe
Nadstruktura języka UML w wersji 2.2
1 Wykład 8 Podprogramy. 2 Pojęcie i istota stosowania dzielenie programu na części (logicznie spójne) - nazwane - niezależne od pozostałych części - z.
JAVA c.d.. Instrukcji wyboru SWITCH używamy, jeśli chcemy w zależności od wartości pewnego wyrażenia wykonać jeden z kilku fragmentów kodu. Jest to w.
Java – coś na temat Klas Piotr Rosik
Dziedziczenie Maciek Mięczakowski
Inicjalizacja i sprzątanie
Programowanie obiektowe Wykład 3 dr Dariusz Wardowski, Katedra Analizy Nieliniowej, WMiI UŁ 1/21 Dariusz Wardowski.
Programowanie obiektowe Wykład 6 dr Dariusz Wardowski, Katedra Analizy Nieliniowej, WMiI UŁ 1/14 Dariusz Wardowski.
Związki w UML Do zrobienia jest: -Przerysować jak ktoś ma Visio te dwa diagramy tak żeby podmienić tylko nazwy a reszta Taka sama, -I dodać po jednym zdaniu.
Programowanie obiektowe – język C++
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Modelowanie obiektowe Diagramy klas
EcoCondens Kompakt BBK 7-22 E.
Programowanie w języku C++
User experience studio Użyteczna biblioteka Teraźniejszość i przyszłość informacji naukowej.
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski informatyka +
Testogranie TESTOGRANIE Bogdana Berezy.
Jak Jaś parował skarpetki Andrzej Majkowski 1 informatyka +
Programowanie strukturalne i obiektowe C++
Model obiektowy bazy danych
Diagram klas Kluczowymi elementami są: klasy (class)
Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.
Elementy geometryczne i relacje
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Programowanie Zaawansowane
Dziedziczenie Wykład 7 Dziedziczenie sekwencyjne
Unified Modeling Language
Partnerstwo dla Przyszłości 1 Lekcja 28 Dziedziczenie i rodzaje dziedziczenia.
E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 1/18 Wykład 3 Model obiektowy (1) dr inż. Ewa Stemposz
Asocjacja,Kompozycja,Agregacja
Implementacja asocjacji (z atrybutami i bez) przy użyciu: referencji (kolekcji referencji) tablic asocjacyjnych przygotował: Kamil Kowalczyk.
Inżynieria systemów informacyjnych
Programowanie Obiektowe – Wykład 6
Klasy, pola, obiekty, metody. Modyfikatory dostępu, hermetyzacja
(według:
Programowanie Obiektowe – Wykład 2
PGO Dziedziczenie Michail Mokkas.
Zapis prezentacji:

Projektowanie - klasy i związki

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

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

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)

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

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

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

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

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)

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

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

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

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ń

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

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,

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

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) –

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

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

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)

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

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;

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;

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);

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()

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

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

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

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

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));

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

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

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

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

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

Asocjacja 1-1 - implementacja

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; }

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;

Asocjacja 1-1 - implementacja

Asocjacja 1-1 - implementacja

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

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

Asocjacja 1-* - przykład

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";

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);

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;

Asocjacja 1-* - przykład

Asocjacja 1-* - przykład

Asocjacja 1-* - przykład

Asocjacja 1-* - przykład

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)

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)

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ść

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

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

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 1-0..1 Do implementacji asocjacji kwalifikowanej używa się tablic asocjacyjnych (tablic haszujących ) Krotność po zastosowaniu asocjacji kwalifikowanej 1-* ulega redukcji do 1-1 lub 1-0..1

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

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

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

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

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

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)

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

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

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 { ... }

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

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 { ... }

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

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 { ... }

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ę

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

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 { ... }

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 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 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)

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

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

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

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

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 { ... }

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

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

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 http://mediawiki.ilab.pl/index.php/Inżynie ria_oprogramowania