Wykład 5 Model obiektowy (3)

Slides:



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

Programowanie obiektowe
Związki w UML.
Modelowanie klas i obiektów
Grafy spełniające nierówność Γ(G) < IR(G)
Projektowanie systemów informacyjnych
Agregacja Agregacja jest rodzajem asocjacji; zadaniem agregacji jest modelowanie związku całość-część. agregacja jest asocjacją: dla obu jej końców są.
Projektowanie systemów informacyjnych
PROGRAMOWANIE STRUKTURALNE
Badania operacyjne. Wykład 2
Kamil Łącki Dominik Strzelichowski
Implementacja asocjacji
Zrównoleglanie programu sekwencyjnego
Materiały pochodzą z Platformy Edukacyjnej Portalu
MS Access 2000 Normalizacja Paweł Górczyński 2005.
Co UML może zrobić dla Twojego projektu?
08: ERD – podencje, łuki i pułapki
C++ wykład 2 ( ) Klasy i obiekty.
Inteligentne Systemy Informacyjne
Projektowanie systemów informacyjnych
Projektowanie systemów informacyjnych
Diagramy klas w języku UML
Projektowanie systemów informacyjnych
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Projektowanie - wprowadzenie
Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie.
Wykład 4 Analiza i projektowanie obiektowe
Bazy Danych II prowadzący: mgr inż. Leszek Siwik
Zależności funkcyjne.
Diagramy ER (Entity-relationship diagrams)
Elementy Rachunku Prawdopodobieństwa i Statystyki
OMT - Model obiektów, cz.1.
Dziedziczenie Maciek Mięczakowski
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.
Wybrane zagadnienia relacyjnych baz danych
Związki Agregacje Związki n-arne Ograniczenia.
Zasady przywiązywania układów współrzędnych do członów.
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy klas
Intuicjonizm etyczny George’a E. Moore’a
Programowanie w języku C++
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Temat 3: Integralność danych. Integralność danych, określana również mianem spójności danych, jest to funkcja SZBD, która gwarantuje, że dane nie zostaną.
Michał Krawczykowski kl. IIIB
Programowanie strukturalne i obiektowe C++
Model obiektowy bazy danych
Diagram aktywności (czynności)
Diagram klas Kluczowymi elementami są: klasy (class)
Zagadnienia AI wykład 2.
Modelowanie obiektowe - system zarządzania projektami.
Projektowanie relacyjnych baz danych – diagramy związków encji
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Modelowanie model związków encji
Wstęp do systemów informatycznych Diagramy klas. Odbiór świata  Myślenie o dziedzinie problemu powinno być możliwie zbliżone do myślenia o systemie 
Modelowanie Danych (ERD) – część 1 (Wspomaganie Modelowania danych)
Asocjacja,Kompozycja,Agregacja
Implementacja asocjacji (z atrybutami i bez) przy użyciu: referencji (kolekcji referencji) tablic asocjacyjnych przygotował: Kamil Kowalczyk.
Pojęcia podstawowe c.d. Rachunek podziałów Elementy teorii grafów
 Formuła to wyrażenie algebraiczne (wzór) określające jakie operacje ma wykonać program na danych. Może ona zawierać liczby, łańcuchy znaków, funkcje,
Temat: Tworzenie bazy danych
Liczbami naturalnymi nazywamy liczby 0,1,2,3,..., 127,... Liczby naturalne poznaliśmy już wcześniej; służą one do liczenia przedmiotów. Zbiór liczb.
Projektowanie systemów informacyjnych
Projektowanie systemów informacyjnych
PGO - Projektowanie i implementacja pierwszych klas
Zapis prezentacji:

Wykład 5 Model obiektowy (3) dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Zagadnienia Asocjacja binarna Asocjacje pochodne Dziedziczenie asocjacji Role wielowartościowe Agregacja a kompozycja Agregacja rekursywna Asocjacja kwalifikowana Asocjacja n-arna

Powiązanie a asocjacja Fizyczny lub pojęciowy związek między obiektami, odwzorowywujący relację istniejącą między odpowiednimi bytami w analizowanej dziedzinie problemowej. Powiązanie: Grupa powiązań posiadających wspólną strukturę i semantykę. Powiązanie jest wystąpieniem asocjacji. Asocjacja, która łączy dwie klasy nazywana jest asocjacją binarną. Asocjacja: :Osoba imię=Zuzanna :Osoba imię=Ewa :Osoba imię=Jan Osoba imię pracuje w pracuje w pracuje w pracuje w Firma rodzaj :Firma krawiecka :Firma szewska Klasy i asocjacja na diagramie klas Obiekty i powiązania na diagramie obiektów Asocjacje, łączące więcej niż dwie klasy, nazywane są asocjacjami n-arnymi.

Oznaczanie asocjacji Nazwa asocjacji (np. pracuje_dla), wyznacza semantykę asocjacji w modelu pojęciowym opisującym daną dziedzinę przedmiotową. Czarny trójkącik określa kierunek czytania. Na diagramie poniżej oznacza to, że to osoba pracuje dla firmy, a nie firma dla osoby. pracuje_dla Firma Osoba Asocjacje mogą być wyposażone w oznaczenia liczności (ang. multiplicity). Liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy; zwykle określa się to poprzez parę liczb (całowite, nieujemne), oznaczających minimalną i maksymalną liczbę takich obiektów.

Liczność asocjacji (1) Cecha o dużym znaczeniu informacyjnym w analizie (i modelowaniu w ogóle). Jeżeli asocjacja wiąże klasy A i B, to istotne jest: jaka jest minimalna liczba obiektów B powiązana z jednym obiektem A, A --> B jaka jest maksymalna liczba obiektów B powiązana z jednym obiektem A, A --> B jaka jest minimalna liczba obiektów A powiązana z jednym obiektem B, B --> A jaka jest maksymalna liczba obiektów A powiązana z jednym obiektem B, B --> A. Zwykle, minimalna liczba jest 0 lub 1, maksymalna zaś 1 lub * (dowolnie dużo). a) b) a) b) A A A A A A A A A A A A 1,2 2,3 B B B B B B 0..1 1..3 A B: min = 0, max = 1 A B: min = 1, max = 3 B B B A: min = 1, max = 2 B A: min = 2, max = 3

Liczność asocjacji (2) UML znaczenie 1 1..* 2..* 3..5 2,4,18 0..1 0..* Liczność jest oznaczana na obu końcach asocjacji. Przykłady: UML znaczenie Państwo Stolica 1 1..* 2..* 3..5 2,4,18 0..1 0..* * 1 1,2,3,... 2,3,4,... 3,4,5 2,4,18 1, ? 0,1 0,1,2,... 1 * Firma Pracownik 0..* 0..1 Osoba Adres Oznaczać czy nie oznaczać liczność 1?

Asocjacje skierowane Zamówienie dataZłożenia czyZapłacone Klient sumaDoZapłaty realizuj() zamknij() Klient nazwisko adres wiarygodność() * 1 1 Na diagramach UML można oznaczać kierunek nawigowania wzdłuż danej asocjacji. W takim przypadku asocjacja jest rysowana w postaci strzałki; nawigacja jest możliwa zgodnie z jej kierunkiem, ale nie odwrotnie. * PozycjaZamówienia ilość cena czyZrealizowana * 1 Produkt

Role asocjacji (1) Asocjacje mogą być także wyposażone w nazwy ról (przy końcach asocjacji), np. pracodawca i pracownik. podwładny * pracuje_dla 1..* Firma * Osoba pracodawca pracownik 0..1 szef Role asocjacji są niezbędne, gdy powiązania łączą obiekty tej samej klasy. Jak oznaczać asocjacje binarne? (1) Można opuszczać nazwę asocjacji, gdy jest oczywista (?) i jest jedyną asocjacją łączącą dwie klasy. Firma 1 1..* Pracownik

jest_przewodniczącym Role asocjacji (2) 1..* jest_członkiem * Osoba Komitet 1 jest_przewodniczącym * Na diagramie powyżej, dwie asocjacje łączą te same klasy; w takim wypadku (dwie klasy połączone więcej niż jedną asocjacją) wszystkie asocjacje muszą być oznaczone. (2) Do oznaczenia asocjacji można użyć nazwy, dwóch ról lub jednej roli. * Pracownik 0..1 szef Z diagramów, dla zwiększenia czytelności, usuwa się wszelką informację redundantną –dlatego jednoczesne używanie zarówno nazwy, jak i ról asocjacji nie jest zalecane.

Atrybuty asocjacji Przykład 1: Plik Prawo dostępu Przykład 2: dostęp Użytkownik Prawo dostępu dostęp dostępny dla { dostęp oznacza: czytanie lub czytanie-pisanie} * Przykład 2: Osoba nazwisko pesel adres Firma nazwa Zatrudnienie zarobek stanowisko szef pracuje_w Ocena wydajności ocena 0..1 * 1..*

Kiedy wykorzystywać atrybuty asocjacji? pracuje_w Zalecane jest, by przypisywać do klasy tylko te atrybuty, które są dla tej klasy stabilne. Eksperyment myślowy: co będzie, jeżeli liczność asocjacji się zmieni? Dość często okazuje się wtedy, że atrybut jest atrybutem asocjacji, a nie klasy. Osoba nazwisko pesel adres Firma nazwa adres 1..* 0..1 Zatrudnienie zarobek stanowisko pracuje_w Osoba nazwisko pesel adres zarobek stanowisko Firma nazwa adres 1..* 0..1 Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów.

Atrybuty i asocjacje pochodne Własność pochodna jest zdefiniowana poprzez funkcję działającą na jednym lub więcej elementach modelu, które też mogą być pochodne. Własność pochodna oznaczana jest przez poprzedzenie jej nazwy ukośnikiem /. atrybut pochodny: /wiek data_urodzenia /wiek Osoba wiek = data_bieżąca - data_urodzenia 1 1 zatrudnia Wydział * Sekcja * Pracownik * * zlokalizowana_w 1 1 /pracuje_w Budynek asocjacja pochodna: /pracuje_w Asocjacja pracuje_w jest asocjacją pochodną, którą można wyznaczyć poprzez asocjacje zatrudnia i zlokalizowana_w. Asocjację pochodną oznacza się poprzedzając ukośnikiem nazwę asocjacji lub jej rolę.

Dziedziczenie asocjacji (1) K1 K2 K3 K4 K a ? K1 a K2 K3 K Aby obie asocjacje a (diagram po lewej stronie) mogły zostać zastąpione jedną asocjacją a poprowadzoną od nadklasy K1 do klasy K (diagram po prawej stronie), asocjacje a z diagramu po lewej stronie muszą spełniać następujące warunki: muszą mieć tę samą semantykę, muszą mieć tę samą strukturę, asocjacja a musi łączyć klasę K z wszystkimi podklasami klasy K1 (?).

Dziedziczenie asocjacji (2) Nazwa dla klasy asocjacji ? Ograniczenia dla przeniesienia brakującej informacji. Termin Referat {abstract} godz. tytuł 1..* wygłaszany autorzy: [1..*] 0..1 Sesja nazwa 0..1 Referat zwykły wygłaszany Referat Zaproszony data 1..* 0..1 1 ocena Termin godz. Zastosowanie dziedziczenia asocjacji spowodowało, że część informacji nie została przeniesiona na nowy diagram (zmiany zostały oznaczone czerwonym kolorem). wygłaszany Termin godz.

Redukcja liczności Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu K1 K2 x y K a1 K1 K2 1 y a2 x 1 K a1 a2 gdzie: x, y oznaczają liczności wiele Przykład: Osoba 1..* pracodawca Firma * 1..* /pracodawca Zatrudnienie * 1 Osoba stanowisko Firma Zatrudnienie 1 * 1..* pensja stanowisko pensja

Role wielowartościowe (1) Rola wielowartościowa: to taka rola, dla której górna granica liczności jest większa od 1. Przyjmuje się domyślnie: 1 * K1 K2 zbiór obiektów, opisujący daną rolę, jest nieuporządkowany, dany obiekt pojawia się tylko jeden raz w w zbiorze obiektów opisującym rolę, powyższe reguły mogą zostać zmienione dzięki ograniczeniom {ordered}, {bag} i stereotypowi «history ». r1 r2 Rola r2 jest tu rolą wielowartościową. W sensie dosłownym, liczności obu końców asocjacji oznaczają liczności obu ról. Uwaga: a Ograniczenie {ordered} pozwala na uporządkowanie zbioru obiektów, który opisuje daną rolę. a :K2 :K1 źle :K2 a {ordered} * dobrze :K1 a 1..2 K1 K2 :K2 a

Role wielowartościowe (2) Między dwoma tymi samymi obiektami może wystąpić więcej niż jedno powiązanie (np. jak na diagramie poniżej), ale nie mogą to być – jak poprzednio – powiązania o tej samej semantyce. Osoba Firma pracuje jest dyrektorem 0..1 1 * Nowak : Osoba IBM : Firma pracuje jest dyrektorem {subset} pracuje Ograniczenie: {bag} :Zatrudnienie 01.01.1990 15.12.1995 programista 2000 {bag} pracuje Osoba Firma 1..* * Y:Firma X:Osoba pracuje Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja :Zatrudnienie 01.01.1998 NULL analityk 5000

Role wielowartościowe (3) Stereotyp: «history» dla oznaczenia roli pracodawca pracuje Osoba * Firma 1..* «history» pracodawca pracuje :Zatrudnienie Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja 01.01.1990 15.12.1995 programista 2000 :Firma :Osoba pracuje :Zatrudnienie 01.01.1998 NULL analityk 5000 Stereotyp «history» – podobnie jak ograniczenie {bag} – pozwala na utworzenie więcej niż jednego powiązania (o danej semantyce) między dwoma obiektami; wykorzystywanie go jest ukierunkowane na rejestrowanie zmian w czasie.

Role wielowartościowe (4) Zatrudnienie 1 1 Osoba data zatrudnienia data zwolnienia stanowisko pensja * 1..* Firma :Zatrudnienie 01.01.1990 15.12.1995 programista 2000 :Firma :Osoba Zastosowanie klasy pośredniczącej Zatrudnienie wprawdzie pozwala na utworzenie wielu powiązań pracuje między dwoma tymi samymi obiektami, wystąpieniami klas Osoba i Firma, ale nie uwidacznia tego faktu. :Zatrudnienie 01.01.1998 NULL analityk 5000

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

Agregacja (2) Inne nazwy dla ról agregacji: całość część Nazwa agregacji i nazwy jej ról, jako oczywiste, są zazwyczaj pomijane. składa się z zawiera obejmuje, itp. wchodzi w skład jest zawarta w należy, itp. Własności agregacji: jest relacją niesymetryczną, tzn. jeśli B jest częścią A, to A nie jest częścią B A B jest relacją przechodnią (tranzytywną), tzn. jeśli C jest częścią B i B jest częścią A, to C jest częścią A A B C

Agregacja (3) Kryteria służące analitykowi pomocą w podjęciu decyzji czy do modelowania pojęciowego wykorzystać agregację, czy też zwykłą asocjację: kryterium istnienia (część nie istnieje samodzielnie bez całości), kryterium wstawiania (nie ma sensu wstawianie części do systemu, jeśli nie wstawiono do niego całości), kryterium usuwania (usuwanie całości powinno skutkować usunięciem wszystkich powiązanych z tą całością części), kryterium fizycznej części. Wszystkie kryteria zawiodły, a mimo to zdecydowano się zastosować agregację, bo lepiej niż zwykła asocjacja modeluje związek część-całość – pewne operacje można wykonywać na całości, a nie na każdej z części oddzielnie. zmień plan Student zmień plan Grupa * 1..15 plan plan zmień plan Termin od do Operacja zmień plan została oznaczona jako ta, która będzie automatycznie wykonana dla wszystkich części, wtedy gdy zostanie wywołana dla całości (tzw. propagacja operacji).

Kompozycja jako mocna postać agregacji Pojęcie agregacji jest rozumiane na dwa sposoby: Jako „silny” związek część-całość pomiędzy obiektami świata rzeczywistego; np. silnik jest częścią samochodu. Jako „słabszy” związek część-całość wykorzystywany najczęściej do modelowania w sytuacjach, takich jak np. gdy informacja o części jest współdzielona przez wiele całości (np. jeden student może wchodzić w skład wielu grup). W UML te dwie sytuacje zostały rozdzielone. Pierwszą formę nazwano kompozycją. Kompozycja oznacza, że: cykl życiowy części zawiera się w cyklu życiowym całości, część nie może być współdzielona – co wynika z (1). Kc * Ks Kc * Ks * kompozycja agregacja

Agregacja a kompozycja; przykład {ordered} 1 Punkt 3..* * {alternatywnie} {alternatywnie} * 0..1 0..1 Wielobok Okrąg promień * * Styl kolor czyWypełniony 1 1 W przedstawionym rozwiązaniu, punkt na płaszczyźnie, w którym przecina się wiele środków Okręgów i wierzchołków Wieloboków, jest odwzorowywany w wiele (?) obiektów klasy Punkt, natomiast mniej problemów nastręcza usuwanie punktów.

Alternatywne sposoby prezentowania kompozycji Samochód Koło Silnik 4..5 1 Samochód k: Koło [4..5] s: Silnik 4..5 k: Koło 1 s: Silnik Samochód k: Koło s: Silnik Samochód 4..5 1

Agregacja rekursywna (1) ? K ? Obiekt klasy K może zarówno wchodzić w skład innych obiektów klasy K, jak i zawierać obiekty klasy K. K 0..1 :K 1 Co by było, gdyby któryś z końców tej agregacji (lub oba końce) oznaczyć licznością dokładnie 1 zamiast liczności opcjonalnej 0..1 ? Jakie zmiany wprowadziłoby do powyższego diagramu zastosowanie zwykłej asocjacji zamiast agregacji ? Czy można tu zastosować kompozycję?

Agregacja rekursywna (2) 0..1 K :K 2 * :K :K :K :K :K :K Czy można tu zastosować liczność dokładnie 1 zamiast 0..1 i liczność 1..* zamiast liczności * ? I Część nazwa materiał rozmiary 0..1 * II Firma Oddział 1 * 0..1 Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji wydaje się być bezdyskusyjna?

Agregacja rekursywna (3) * :K 3 Przykłady agregacji rekursywnych: Jak wyglądałby diagram obiektowy dla wyrażenia, np. (x + y/2) * (x/3 - y) Program 1..* Blok Instrukcja złożona prosta 0..1 1 * I II 2-gi operand Człon * Wyrażenie operator binarny Zmienna nazwa 1 Stała wartość 1-szy operand

Asocjacja kwalifikowana (1) Bank Osoba nr konta 0..1 kwalifikator asocjacji 1 Bank * 0..1 Osoba nr konta Bank Osoba * Bank/Osoba nr konta Bank Osoba nr konta * 0..1 Kwalifikator jest atrybutem asocjacji (lub zestawem atrybutów), którego wartości służą do podziału zbioru obiektów definiowanych przez klasę znajdującą się na przeciwległym do kwalifikatora końcu asocjacji.

Asocjacja kwalifikowana (2) Zamówienie WierszZamówienia nazwa produktu ilość * pozycja 1 nazwa produktu Zamówienie WierszZamówienia ilość 0..1 pozycja 1

Asocjacja n-arna 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 4-arna Notacja: asocjacja 3-arna K1 K2 K3 r1 r2 K1 K3 A K2

Asocjacja n-arna (cd.) Liczność asocjacji: 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 asocjacji: Zespół Gracz Rok Zapis gole nasze gole ich * bramkarz Mecz

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ść. K1 K3 K2 KA a1 a2 m1 A K1 K3 K2 A a1 a2 m1 Asocjacja n-arna zostaje zamieniona na jedną klasę i n asocjacji binarnych.