MAS dr. Inż. Mariusz Trzaska

Podobne dokumenty
MAS dr. Inż. Mariusz Trzaska

Rysunek 1: Przykłady graficznej prezentacji klas.

Diagramy klas. dr Jarosław Skaruz

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Modelowanie danych, projektowanie systemu informatycznego

Diagramy klas. WYKŁAD Piotr Ciskowski

Język UML w modelowaniu systemów informatycznych

Podstawy projektowania systemów komputerowych

Podstawy modelowania w języku UML

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

1 Projektowanie systemu informatycznego

TECHNOLOGIE OBIEKTOWE. Wykład 3

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

Podstawy programowania III WYKŁAD 4

Bazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

UML cz. II. UML cz. II 1/38

Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

5 Zagadnienia dotyczące asocjacji

Język UML w modelowaniu systemów informatycznych

Inżynieria oprogramowania. Część 5: UML Diagramy klas

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Wykład 2. Relacyjny model danych

MAS dr. Inż. Mariusz Trzaska

Systemy informatyczne. Modelowanie danych systemów informatycznych

MSI dr. Inż. Mariusz Trzaska. obiektowych językach programowania

UML w Visual Studio. Michał Ciećwierz

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

MAS dr. Inż. Mariusz Trzaska

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Świat rzeczywisty i jego model

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Definicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.

Klasy abstrakcyjne i interfejsy

Modelowanie obiektowe systemów

Podstawy inżynierii oprogramowania

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

MAS dr. Inż. Mariusz Trzaska. Realizacja różnych modeli dziedziczenia w obiektowych językach programowania

Wykład 8: klasy cz. 4

Laboratorium z przedmiotu: Inżynieria Oprogramowania INP

UML. zastosowanie i projektowanie w języku UML

Analiza i projektowanie obiektowe

DEFINICJA. Definicja 1 Niech A i B będą zbiorami. Relacja R pomiędzy A i B jest podzbiorem iloczynu kartezjańskiego tych zbiorów, R A B.

MODELOWANIE OBIEKTOWE Z UML

MAS dr. Inż. Mariusz Trzaska. Realizacja asocjacji w obiektowych językach

UML. dr inż. Marcin Pietroo

Informatyka I. Klasy i obiekty. Podstawy programowania obiektowego. dr inż. Andrzej Czerepicki. Politechnika Warszawska Wydział Transportu 2018

Podstawy języka UML UML

Specyfikowanie wymagań przypadki użycia

Programowanie obiektowe i zdarzeniowe wykład 4 Kompozycja, kolekcje, wiązanie danych

Diagramy klas i obiektów

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Tworzenie warstwy zasobów projektowanie metodą strukturalną

MAS dr. Inż. Mariusz Trzaska

Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska

Wykład 9: Polimorfizm i klasy wirtualne

Technologie baz danych

PLAN WYKŁADU BAZY DANYCH INDEKSY - DEFINICJE. Indeksy jednopoziomowe Indeksy wielopoziomowe Indeksy z użyciem B-drzew i B + -drzew

JĘZYKI PROGRAMOWANIA Z PROGRAMOWANIEM OBIEKTOWYM. Wykład 6

MODELOWANIE OBIEKTOWE

1. Mapowanie diagramu klas na model relacyjny.

Bazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych

Algorytmy i struktury danych. Wykład 4 Tablice nieporządkowane i uporządkowane

Dziedziczenie. Zadanie 1

Programowanie obiektowe

Projektowanie baz danych

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Modelowanie obiektowe

Spis treúci. 1. Wprowadzenie... 13

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Mechanizm dziedziczenia

Technologie baz danych

Zasady transformacji modelu DOZ do projektu tabel bazy danych

Pakiety i interfejsy. Tomasz Borzyszkowski

Podstawy Programowania Obiektowego

Podstawy języka UML UML

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Modelowanie obiektowe - Ćw. 3.

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

Diagramy czynności. Widok logiczny. Widok fizyczny

APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.

Bazy danych TERMINOLOGIA

Bazy danych. Plan wykładu. Zależności funkcyjne. Wykład 2: Relacyjny model danych - zależności funkcyjne. Podstawy SQL.

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi

Podstawy języka UML2 w realnych projektach

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

Podstawy programowania skrót z wykładów:

Relacje. opracował Maciej Grzesiak. 17 października 2011

Jarosław Żeliński analityk biznesowy, projektant systemów

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Bazy danych. Wykład 4: Model SERM. dr inż. Magdalena Krakowiak

Język UML w modelowaniu systemów informatycznych

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Po lewej przykłady klas. Stereotypy zostały tu wykorzystane do metaklasyfikacji metod.

Bazy danych i usługi sieciowe

Transkrypt:

MAS dr. Inż. Mariusz Trzaska Wykład 5 Model obiektowy cz. 3

Zagadnienia Dziedziczenie asocjacji Asocjacje pochodne Redukcja liczności Role wielowartościowe Trochę więcej o agregacji Agregacja rekursywna Trochę więcej o asocjacji kwalifikowanej Trochę więcej o mechanizmach rozszerzalności Wykorzystano materiały z wykładu PRI autorstwa dr inż. Ewy Stemposz oraz prof. Kazimierza Subiety 2

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

Dziedziczenie asocjacji (2) 0.. Referat {abstract} tytuł autorzy[..] Zaproszony Zwykły ocena Termin godz... wygłaszany wygłaszany.. 0.. 0.. Sesja nazwa data Nazwa dla klasy asocjacji? wygłaszany Termin godz. Termin godz. Wykorzystanie faktu, że asocjacje są dziedziczone spowodowało, że część informacji nie została przeniesiona na nowy diagram (zmiany oznaczono czerwonym kolorem). Aby zapobiec utracie informacji, do diagramu należałoby wprowadzić odpowiednie ograniczenia. 4

Asocjacje pochodne pracownik Osoba.... mieszka Miasto ) Jeśli Osoba mieszka w mieście, w którym pracuje, to jedna z asocjacji: mieszka lub znajduje się albo powinna zostać oznaczona jako pochodna albo powinna być usunięta z diagramu. 0..? pracodawca Firma znajduje się.. Możliwe asocjacje pochodne: /mieszka lub /znajduje się 2) Jeśli liczność roli pracodawca zmienimy na 0.., to asocjacja mieszka nie będzie pochodna, ponieważ nie dla wszystkich obiektów powiązania mieszka będą mogły być wydedukowane. Podobnie, jeśli liczność roli pracownik zmienimy na, to asocjacja znajduje się nie będzie pochodna. 5

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

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

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 pracuje {subset} jest dyrektorem Ograniczenie: {bag} pracuje Osoba.. Firma Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja 0.. Firma 0.. Nowak : Osoba pracuje jest dyrektorem pracuje :Zatrudnienie 0.0.990 5.2.995 programista 2000 IBM : Firma {bag} X:Osoba Y:Firma pracuje :Zatrudnienie 0.0.998 NULL analityk 5000 8

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

Role wielowartościowe (4) Zatrudnienie Osoba data zatrudnienia data zwolnienia stanowisko pensja.. Firma :Zatrudnienie :Osoba 0.0.990 5.2.995 programista 2000 :Firma 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 pozwala na uwidocznienie tego faktu. :Zatrudnienie 0.0.998 NULL analityk 5000 0

Agregacja () 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, ponadto (jak każda asocjacja) może mieć atrybuty, np. Grupa..5 Termin od do Student agregacja jest wykorzystywana do modelowania związku całość-część Grupa..5 całość część Student

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

Agregacja (3) Kryteria służące analitykowi pomocą w podjęciu decyzji czy do modelowania pojęciowego wykorzystać agregację/kompozycję, czy też zwykłą asocjację: plan 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, w drugą stronę ta reguła nie obowiązuje), kryterium fizycznej części. Grupa zmień plan zmień plan..5 Termin od do Student plan zmień plan Wszystkie kryteria zawiodły, a mimo to zastosowano agregację, gdyż 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. 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). 3

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

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

Agregacja rekursywna (3) o Modelowanie nie ogranicza się tylko do opisywania kwestii biznesowych, np. produktów, klientów, pracowników. o Jak wyglądałby diagram klas służący do przechowywania wyrażeń matematycznych, np.: (x + y/2) (x/3 - y) 6

Agregacja rekursywna (4) K :K :K :K :K Czy tu można zastosować kompozycję? :K :K :K Przykłady agregacji rekursywnych I Program II.. Blok 2-gi operand -szy operand Człon a Jak wyglądałby diagram obiektowy dla wyrażenia, np. (x + y/2) (x/3 - y) Instrukcja złożona Instrukcja prosta Wyrażenie 0.. operator binarny Gdzie można by tu zastosować kompozycję w I czy w II? Zmienna nazwa Stała wartość 7

Asocjacja kwalifikowana () Katalog Plik nazwa { nazwa pliku jest unikatowa w ramach katalogu } Katalog nazwa pliku 0.. 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ą (słownik) (przeszukiwanie za pomocą nazwy pliku). 8

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

Ograniczenia 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: Ograniczenia są zawarte wewnątrz {} i umieszczane za elementem w klasie, lub poza klasą. Z reguły są umieszczane w komentarzu (przykład na następnej folii). ograniczenie statyczne Pracownik Pracownik imię {<=0 000} imię nazwisko nazwisko {pensja nie wzrasta o pensja pensja {<=0 000} więcej niż 300} zmień pensję (pensja) ograniczenie dynamiczne W przypadku ograniczenia dynamicznego w przeciwieństwie do ograniczenia statycznego interesuje nas poprzedni stan elementu, dla którego wyspecyfikowano ograniczenie. Czy powiedzie się próba zmiany pensji z 2500 na 5500, przy ograniczeniach jak powyżej? 20

Ograniczenia; przykłady Symbole, takie jak - - - - oraz - - - - > są używane do wskazywania elementów, na które zostały nałożone ograniczenia. Konto należy do {xor} 0.. 0.. Firma Osoba podwładny 0.. szef Osoba.. pracownik 0.. pracodawca Firma {Osoba.pracodawca = Osoba.szef.pracodawca} ograniczenie w komentarzu 2

Ograniczenia predefiniowane; przykłady j. angielski j. polski {complete} {incomplete} {disjoint} {overlapping} {or} {xor} {ordered} {subset} {bag} {hierarchy} {dag} dag - directed acyclic graph {podział całkowity} {podział nie całkowity} {podział rozłączny} {podział nierozłączny} {lub} (suma logiczna) {albo} (różnica symetryczna) {uporządkowane} {podzbiór} {wielozbiór} {hierarchia} {graf acykliczny skierowany} 22