Agregacja jest rodzajem asocjacji zadaniem agregacji jest modelowanie

Agregacja jest rodzajem asocjacji; zadaniem agregacji jest modelowanie związku całość-część. aagregacja jest asocjacją: dla obu jej końców są określane liczności, a także może mieć atrybuty, np. Grupa * 1. . 15 Student Termin od do a agregacja jest wykorzystywana do modelowania związku całość-część Grupa * całość 1. . 15 część Student

Kompozycja jako mocna postać agregacji Pojęcie agregacji jest rozumiane na dwa sposoby: § Jako związek część-całość pomiędzy obiektami świata rzeczywistego; np. silnik jest częścią samochodu. § Jako pomocniczy środek do modelowania dowolnej innej sytuacji, kiedy trzeba wydzielić podobiekty w pewnych obiektach. np. informacja o ubezpieczeniach wewnątrz obiektów pracowników. W UML te dwie sytuacje zostały rozdzielone. Pierwszą formę nazwano kompozycją. Kompozycja oznacza, że cykl życiowy składowej zawiera się w cyklu życiowym całości, oraz że składowa nie może być współdzielona. K * agregacja * 1 Ks K kompozycja * Ks

Implementacja w Javie Roznica w implementacji pomiedzy agregacja a kompozycja polega na tym, ze w przypadku agregacji musimy odnosienia do obiektow pamietac w jakims zewmetrznym, stalym obiekcie i w samym obiekcie agregujacym. W ten sposob odsmiecacz nie skasuje naszych obiektow – czlonkow jesli przestanie istniec obiekt agregujacy. W przypadku kompozycji zabieg taki jest wrecz niewskazany. Jesli odniesienia do obiektow beda pamietane jedynie w obiekcie kompozycji, wowczas zysamy pewnosc, ze w przypadku usuniecia kompozycji usuniemy rowniez wszystkie zgrupowane w ten sposob obiekty.

Agregacja model pojęciowy i projektowy Osoba Imie nazwisko 1…* Osoba String imie String nazwisko Grupa. Osob grupa Grupa Osob 1 poziom Grupa. Osob int poziom Vector zapisani void dodaj() Model pojęciowy Model projektowy

Agregacja – implementacja class Program { public static void main(String[] args) { Osoba o 1=new Osoba("", ""), o 2=new Osoba("", ""); Vector v = new Vector(); v. add(o 1); v. add(o 2); Grupa. Osob(v); } } class Grupa. Osob { public Vector zapisani; public Grupa. Osob(Vector lista) { zapisani = lista; } public void dodaj(Osoba o) { zapisani. add(o); o. grupa = this; } } class Osoba { public String imie; public String nazwisko; public Grupa. Osob grupa; public Osoba(String imie, String nazwisko) { this. imie = imie; this. nazwisko = nazwisko; } } Pamiętanie- odniesień można zrealizować zarówno przy pomocy tablicy jak i kolekcji. Sposób jest zależny od liczności z jaka mamy do czynienia. Przy znanej liczbie lepiej jest zastosować tablice, przy nieznanej liczności musimy sięgać do kolekcji. Patrz wykład o asocjacjach.

Kompozycja model pojęciowy i projektowy Samochód Model Samochód String model Silnik silnik Silnik 1 rocznik typ Silnik int rocznik String typ Model pojęciowy Model projektowy

Kompozycja – implementacja public class Program { public static void main(String[] args) { Samochod s=new Samochod(); Samochod. silnik=new Silnik("diesel"); } } class Samochod { public Silnik silnik; public montuj. Silnik(Silnik s) { silnik = s; } } class Silnik { public int rocznik; public int pojemnosc; public String typ; public Silnik(String typ) { this. typ = typ; } } Pamiętanie odniesień można zrealizować zarówno przy pomocy tablicy jak i kolekcji. Sposób jest zależny od liczności z jaka mamy do czynienia. Przy znanej liczbie lepiej jest zastosować tablice, przy nieznanej liczności musimy sięgać do kolekcji. Patrz wykład o asocjacjach.

Asocjacja kwalifikowana (1) Katalog 1 Katalog nazwa pliku * Plik nazwa 1 0. . 1 { nazwa pliku jest unikatowa w ramach katalogu } Plik Perspektywa pojęciowa - plik jest w ramach katalogu jednoznacznie identyfikowany przez nazwę. Perspektywa projektowa - wskazanie na to, że katalog plików można zorganizować jako tablicę asocjacyjną lub słownik (przeszukiwanie za pomocą nazwy pliku).

Asocjacja kwalifikowana (2) 1 Tablica 100 Kwadrat rząd kolumna 1 1 Kwadrat Kwalifikator asocjacji może stanowić więcej niż jeden atrybut. Warunek - wartości tych atrybutów muszą pozwolić na jednoznaczną identyfikację obiektu w ramach pewnego zbioru obiektów (tutaj - w ramach zbioru kwadratów należących do jednej konkretnej tablicy, czyli jednego obiektu klasy Tablica). Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty. Bank * * nazwa nr konta data założ. Osoba imię nazwisko Bank nazwa Osoba nr. konta * 0. . 1 imię nazwisko data założ.

Asocjacja kwalifikowana modele pojeciowy i projektowy Uczelnia Nr Nazwa Indeksu Uczelnia String nazwa Hashtable studenci 1 1 Student Imię Nazwisko Student String imię String nazwisko String index

Asocjacja kwalifikowana - implementacja class Uczelnia { Hashtable studenci; public void dodaj. Studenta (String nr. Indeksu, Student student) { studenci. put (nr. Indeksu, student); } public void zlikwiduj. Studenta (String nr. Indeksu) { studenci. remove(nr. Indeksu); } } class Student { String nr. Indeksu; String imie; String nazwisko; }

Asocjacja n-arna to asocjacja, której wystąpienia łączą n obiektów, będących instancjami co najwyżej n klas: 3 -arna - 3 obiekty (inna nazwa dla tej asocjacji to ternarna), 4 -arna - 4 obiekty, itd. Dana klasa może pojawić się na więcej niż jednej pozycji w asocjacji. Asocjacja binarna ze swoją uproszczoną notacją i pewnymi dodatkowymi własnościami (takimi jak możliwość ustalania kierunku nawigowania, kwalifikatorów, związków agregacji czy kompozycji) jest specjalnym rodzajem asocjacji n-arnej (dla n=2). Asocjacja binarna i 2 arna są równoważne, nie istnieje między nimi różnica semantyczna, inny jest tylko sposób reprezentowania. Wymienione wyżej dodatkowe własności asocjacji binarnych są zabronione dla asocjacji n-arnych, gdzie n > 2. asocjacja 3 -arna Notacja K 1 asocjacja 4 -arna K 3 K 1 nazwa asocjacji K 2 K 3 K 2

Asocjacja n-arna; liczności Liczności Specyfikowanie liczności dla asocjacji n-arnych nie jest tak oczywiste, jak dla asocjacji binarnych i różni autorzy wygłaszają na ten temat różne zdania. UML odrzuciła poglądy, że liczność danej roli powinna być ustalana w odniesieniu do liczności pozostałych ról, traktowanych oddzielnie. Przyjęto zasadę, że liczność n-tej roli jest opisana przez zbiór możliwych wartości liczności, gdy sytuacja na n-1 końcach asocjacji jest ustalona. Np. dla ternarnej asocjacji łączącej klasy A, B i C liczność roli C specyfikuje, ile obiektów klasy C jest powiązanych z każdą możliwą parą obiektów klas A i B. Taka reguła jest zgodna z regułą przyjętą dla specyfikowania liczności asocjacji binarnych. Atrybuty Rok * Zespół * sezon * Gracz bramkarz Mecz Zapis gole nasze gole ich

Obejście asocjacji n-arnej Asocjacje n-arne mają sens wtedy, gdy do identyfikacji powiązania (n-arnego) potrzebne są wszystkie obiekty, tzn. gdy liczność każdej z ról jest “wiele”. W pozostałych przypadkach asocjację n-arną warto jest zastępować asocjacjami binarnymi, które są łatwiejsze do implementacji i wyposażone w dodatkowe własności, o których była mowa poprzednio. Niestety traci się informację o związku, łączącym grupę obiektów w pewną całość. K 2 A K 1 K 3 KA a 1 a 2 m 1 KA a 1 a 2 K 3 m 1 Asocjacja n-arna zostaje zamieniona na klasę i n asocjacji binarnych.

Asocjacja n-arna • Reprezentuje związek zachodzący pomiędzy n obiektami. Wykładowca * Student * * Sala Zajęcia Przedmiot Data

Asocjacja n-arna cd. . • Asocjacje n-arne przydatne są w przypadku obiektów powiązanych ze sobą licznościami wiele do wiele. • Obejście asocjacji n-arnej poprzez dodanie klasy: Wykładowca 1 Student * Zajęcia * * Data Przedmiot sprawdz. Obecnosc() * 1 Sala

Implementacja class Wykladowca { String imie; String nazwisko; String tytul. Naukowy; } class student { String imie; String nazwisko; String nr. Indeksu; } Wykładowca 1 Student class sala { int numer; } class Zajecia { Date data; String przedmiot; Wykladowca prowadzacy; Student[] studenci; Sala sala; boolean sprawdz. Obecnosc() {. . . } } * * * Zajęcia Data Przedmiot boolean sprawdz. Obecnosc() * 1 Sala

Ograniczenia specyfikują restrykcje nakładane na elementy modelu. Mogą stanowić wyrażenia języka naturalnego czy języka formalnego (np. OCL w UML), mogą też przyjmować postać formuły matematycznej lub fragmentu kodu (czy też pseudokodu). Notacja: są zawarte wewnątrz {} i umieszczane za elementem w klasie, lub poza klasą. Mogą też być umieszczane w komentarzu (przykład na następnej folii). Pracownik imię nazwisko pensja {<=10 000} Pracownik String imię String nazwisko int pensja -int max_podwyzka ograniczenie statyczne {pensja <=10 000} {pensja nie wzrasta o więcej niż 300} Void zmień pensję (nowa) ograniczenie Ograniczenie dynamiczne - tu interesuje nas poprzedni stan elementu, na który jest nałożone ograniczenie. dynamiczne Czy powiedzie się próba zmiany pensji z 2500 na 5500?

class Pracownik { private int max_pensja=10000; private int max_podwyzka=300; import java. util. *; String imie, nazwisko; int pensja; class Program { void zmien. Pensje(int suma) throws Pensja. Exception { public Program() { if (suma>max_pensja) //ograniczenie statyczne Pracownik p=new Pracownik(); throw new Pensja. Exception("Pensja za duza"); try { if (suma>pensja+max_podwyzka) //dynamiczne p. zmien. Pensje(2000); throw new Pensja. Exception("Podwyzka za duza"); } catch (Pensja. Exception exc) { pensja=suma; System. out. println(exc); } } class Pensja. Exception extends Exception { } public Pensja. Exception(String przyczyna) { super(przyczyna); } } Pracownik String imię String nazwisko int pensja -int max_podwyzka zmień pensję (nowa)