MAS dr. Inż. Mariusz Trzaska

Podobne dokumenty
MAS dr. Inż. Mariusz Trzaska

Rysunek 1: Przykłady graficznej prezentacji klas.

Modelowanie danych, projektowanie systemu informatycznego

TECHNOLOGIE OBIEKTOWE. Wykład 3

Diagramy klas i obiektów

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

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

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

Podstawy projektowania systemów komputerowych

1 Projektowanie systemu informatycznego

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

Świat rzeczywisty i jego model

Diagramy klas. dr Jarosław Skaruz

5 Zagadnienia dotyczące asocjacji

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Modelowanie obiektowe

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Paweł Kurzawa, Delfina Kongo

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Diagramy klas. WYKŁAD Piotr Ciskowski

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

1. Mapowanie diagramu klas na model relacyjny.

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Systemy informatyczne. Modelowanie danych systemów informatycznych

Projektowanie baz danych

Język UML w modelowaniu systemów informatycznych

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

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

Podstawy modelowania w języku UML

UML w Visual Studio. Michał Ciećwierz

Projektowanie baz danych

UML. zastosowanie i projektowanie w języku UML

Podstawy inżynierii oprogramowania

Język UML w modelowaniu systemów informatycznych

Modelowanie obiektowe - Ćw. 3.

Język UML w modelowaniu systemów informatycznych

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

Podstawy Programowania Obiektowego

MODELOWANIE OBIEKTOWE Z UML

Bazy danych wykład trzeci. trzeci Modelowanie schematu bazy danych 1 / 40

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Podstawy programowania III WYKŁAD 4

Podstawy języka UML UML

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

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

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

MAS dr. Inż. Mariusz Trzaska

Modelowanie danych Model związków-encji

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

Projektowanie BD Diagramy związków encji

MAS dr. Inż. Mariusz Trzaska

TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

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

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

PLAN WYKŁADU BAZY DANYCH GŁÓWNE ETAPY PROJEKTOWANIA BAZY MODELOWANIE LOGICZNE

WYKŁAD 1. Wprowadzenie do problematyki baz danych

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

MODELOWANIE OBIEKTOWE

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

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

Wprowadzenie do UML, przykład użycia kolizja

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

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

Temat : SBQL 1 obiektowy język zapytań.

Informacje ogólne. Karol Trybulec p-programowanie.pl 1. 2 // cialo klasy. class osoba { string imie; string nazwisko; int wiek; int wzrost;

Projektowanie obiektowe oprogramowania Wykład 2 - UML Wiktor Zychla 2016

Diagramy UML, przykład problemu kolizji

Projektowanie logiki aplikacji

Modelowanie związków encji. Etapy budowy systemu informatycznego przedsiębiorstwa (1/4) Etapy budowy systemu informatycznego przedsiębiorstwa (2/4)

Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

Modelowanie Systemów informacyjnych (MSI)

Piotr Kopalko Warszawa System obsługi teatru

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Modelowanie danych Model związków-encji

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Wybrane problemy z dziedziny modelowania i wdrażania baz danych przestrzennych w aspekcie dydaktyki. Artur Krawczyk AGH Akademia Górniczo Hutnicza

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Podejście obiektowe - podstawowe pojęcia

Technologie baz danych

Podstawy modelowania programów Kod przedmiotu

Podrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy

Bazy danych. dr inż. Andrzej Macioł

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

4. Język UML Alfabet

UML. dr inż. Marcin Pietroo

Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego. Iwona Kochaoska

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp Podziękowania...

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

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

Transformacja modelu ER do modelu relacyjnego

Informatyzacja przedsiębiorstw WYKŁAD

Programowanie w Javie 1 Wykład i Ćwiczenia 3 Programowanie obiektowe w Javie cd. Płock, 16 października 2013 r.

Techniki modelowania programów Kod przedmiotu

Transkrypt:

MAS dr. Inż. Mariusz Trzaska Wykład 4 Model obiektowy cz. 2

Zagadnienia Asocjacja binarna Agregacja a kompozycja Modelowanie generalizacji-specjalizacji Obejście dziedziczenia wielokrotnego Asocjacja kwalifikowana Asocjacja n-arna Ograniczenia Wykorzystano materiały z wykładu PRI autorstwa dr inż. Ewy Stemposz oraz prof. Kazimierza Subiety 2

Powiązanie a asocjacja binarna Powiązanie Asocjacja Relacja zachodząca między obiektami, odwzorowywująca fizyczny lub pojęciowy związek istniejący między odpowiednimi bytami w analizowanej dziedzinie problemowej. Powiązanie łączące dwa obiekty nazywane jest powiązaniem binarnym. Opis grupy powiązań posiadających wspólną semantykę i strukturę. Powiązanie jest wystąpieniem asocjacji. Asocjacja, która łączy dwie klasy nazywana jest binarną. imię pracuje_w : imię=kasia pracuje_w : : imię=ewa imię=jasio pracuje_w pracuje_w Firma rodzaj :Firma rodzaj=krawiecka :Firma rodzaj=szewska Klasy i asocjacja na diagramie klas Obiekty i powiązania na diagramie obiektów Asocjacje mogą też łączyć więcej niż dwie klasy (asocjacje n-arne). 3

Oznaczanie asocjacji Nazwy asocjacji, takie jak np. pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę problemową (czy też pewien fragment dziedziny problemowej). Czarny trójkącik określa kierunek (czytania) wyznaczony przez nazwę asocjacji. Na przykład, na diagramie poniżej określa, że to osoba pracuje dla firmy, a nie firma pracuje dla osoby. Firma pracuje dla.. Asocjacje mogą być wyposażone w oznaczenia liczności. 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 (znaków, np. ), oznaczających minimalną i maksymalną liczbę takich obiektów. 4

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

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

Asocjacje skierowane Zamówienie datazłożenia czyzapłacone /sumadozapłaty realizuj() zamknij() PozycjaZamówienia ilość cena czyzrealizowana Klient nazwisko adres wiarygodność() Na diagramach UML można oznaczać kierunek nawigowania wzdłuż danej asocjacji. W takim przypadku asocjacja jest rysowana w postaci strzałki; nawigowanie jest możliwe tylko w kierunku wyznaczanym przez strzałkę. Produkt 7

Role asocjacji () Asocjacje mogą być wyposażone w nazwy ról (przy końcach), np. pracodawca i pracownik. Rola określa kierunek nawigowania, specyfikując klasę cel. Na przykład, rola pracodawca jako cel wyznacza kierunek nawigowania od obiektu klasy do powiązanych z nim obiektów klasy Firma (wyrażenie ścieżkowe: osoba.pracodawca zwraca zbiór pracodawców danej osoby). Liczność roli specyfikuje liczność jednego z końców asocjacji. Firma pracodawca pracuje dla.. pracownik podwładny szef Role asocjacji są niezbędne, gdy powiązania łączą obiekty tej samej klasy. Jak oznaczać asocjacje binarne? () Można opuszczać nazwę asocjacji, gdy jest oczywista (?) i jest jedyną asocjacją łączącą dwie te same klasy. Firma.. 8

Role asocjacji (2) jest_członkiem Komitet jest_przewodniczącym W sytuacji, gdy dwie te same klasy są połączone więcej niż jedną asocjacją, wszystkie asocjacje muszą być oznaczone. (2) Do oznaczania asocjacji można używać albo (I) nazwy asocjacji, albo (II) nazw obu ról albo (III) nazwy tylko jednej roli. Pracownik Z założenia, z diagramów usuwa się wszelką informację redundantną dla zwiększenia ich czytelności jednoczesne używanie nazwy i ról asocjacji nie jest tu zalecane. szef 9

Atrybuty asocjacji dostępny dla Plik Użytkownik dostęp { dostęp oznacza: czytanie lub czytanie-pisanie} Jeśli klasa asocjacji nie zawiera metod ani asocjacji do innych klas to jej nazwa może być opuszczona dla podkreślenia faktu, że chodzi tu wyłącznie o atrybuty asocjacji. szef nazwisko pesel adres.. zatrudnia Zatrudnienie zarobek stanowisko Firma nazwa adres Ocena wydajności ocena 0

Kiedy stosować atrybuty asocjacji? 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. nazwisko pesel adres.. pracuje_w Zatrudnienie zarobek stanowisko Firma nazwa adres Forma nie zalecana, mniej elastyczna: po zmianie asocjacji na wiele-do-wielu trzeba zmieniać położenie atrybutów. nazwisko pesel adres zarobek stanowisko.. pracuje_w Firma nazwa adres

Atrybuty i asocjacje pochodne Cecha pochodna jest zdefiniowana poprzez funkcję działającą na jednym lub więcej bytach modelu, które też mogą być pochodne. Cecha pochodna oznaczana jest ukośnikiem /. atrybut pochodny: /wiek data_urodzenia /wiek {wiek = data_bieżąca - data_urodzenia} asocjacja pochodna: /pracuje_w zatrudnia Wydział Sekcja Pracownik zlokalizowana_w Budynek /pracuje_w Asocjacja pracuje_w jest asocjacją pochodną, którą można wyznaczyć poprzez asocjacje zatrudnia i zlokalizowana_w. Asocjację pochodną można oznaczyć poprzedzając ukośnikiem nazwę lub rolę asocjacji. 2

Przykładowy diagram klas poprzedza zapisany_na.. Kurs zawiera następuje_po Student Pracownik Profesor prowadzi.... Wykład 3

Agregacja aagregacja jest szczególnym rodzajem asocjacji wyrażającym zależność częśćcałość. Np. silnik jest częścią samochodu. anie istnieje jedna powszechnie akceptowana definicja agregacji. P. Coad podaje jako przykład agregacji związek pomiędzy organizacją i jej pracownikami; dla odmiany J. Rumbaugh twierdzi,że firma nie jest agregacją jej pracowników. aw wielu przypadkach związki agregacji są oczywiste. Jednakże wątpliwości powstają nawet w przypadku samochodu i silnika. Np. silnik może być towarem w sklepie nie związanym z żadnym samochodem. Ponadto, czy chodzi o konkretny samochód i silnik, czy też o typ samochodu i typ silnika? amętlik dookoła pojęcia agregacji wynika również z tego,że jest ona nadużywana w celu usprawiedliwienia pewnych ograniczeń modelu obiektowego. anp. popularne wyjaśnienie powodów braku dziedziczenia wielokrotnego podaje, że można je obejść przez agregację, co jest nonsensem z punktu widzenia celów modelowania pojęciowego, tak samo jak zdanie: asocjacje są zbędne, bo można je obejść przez atrybuty. Wszystko można obejść... w assemblerze! 4

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 pomocniczy środek do modelowania dowolnej innej sytuacji, kiedy grupę obiektów warto w pewnych sytuacjach potraktować jako całość. W UML, te dwie sytuacje zostały rozdzielone. Pierwszą formę, tzw. silniejszą postać agregacji, nazwano kompozycją. Kompozycja oznacza, że (I) cykl życiowy składowej zawiera się w cyklu życiowym całości, orazże (II) składowa nie może być współdzielona (co wynika z I). Kc Ks Kc Ks kompozycja agregacja 5

Agregacja a kompozycja; przykład {alternatywnie} Wielobok {ordered} 3.. Punkt {alternatywnie} Okrąg promień Styl kolor czywypełniony Wada: 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. Zaleta: mniej problemów nastręcza usuwanie wieloboków (związane z usuwaniem punktów wchodzących w ich skład). 6

Modelowanie generalizacji-specjalizacji zastosowano dziedziczenie zastosowano kompozycję Student Pracownik {xor} Student Pracownik {overlapping} Student Pracownik Student Pracownik Dzięki kompozycji, podobiekty Student czy Pracownik są mocniej związane z obiektem, niż gdyby do modelowania użyto zwykłej asocjacji. 7

Obejście dziedziczenia wielokrotnego nie polecane Student Pracownik Student Pracownik Student/Pracownik Student/Pracownik Student Pracownik 8

Asocjacja kwalifikowana () Bank Bank nr konta.. nr konta kwalifikator asocjacji Bank Bank nr konta Bank/ nr konta Kwalifikator jest atrybutem (lub zestawem atrybutów), którego wartości służą do podziału zbioru obiektów definiowanych przez klasę znajdującą się na jednym z końców tej asocjacji. 9

Asocjacja kwalifikowana (2) Zamówienie pozycja WierszZamówienia nazwa produktu ilość Zamówienie nazwa produktu pozycja WierszZamówienia ilość 20

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 (wtedy należy oznaczać role asocjacji). Asocjacja binarna ze swoją uproszczoną notacją (linia prosta) i pewnymi dodatkowymi własnościami (takimi jak możliwość ustalania kierunku nawigowania, wykorzystywania kwalifikatorów, związków agregacji czy kompozycji) jest specjalnym rodzajem asocjacji n-arnej (gdzie n=2). Asocjacja binarna i asocjacja 2-arna są równoważne, nie istnieje między nimi różnica semantyczna, inny jest tylko sposób reprezentowania. Własności dodatkowe, wymienione powyżej (możliwe dla asocjacji binarnych), są zabronione dla asocjacji n- arnych, gdzie n > 2. asocjacja 2-arna asocjacja 3-arna asocjacja 4-arna K K3 K nazwa asocjacji K3 r K r2 nazwa asocjacji K3 K2 K2 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. W UML przyjęto zasadę,że liczność n-tej roli jest opisana przez zbiór możliwych wartości liczności, gdy sytuacja na n- końcach asocjacji jest ustalona. Np. dla ternarnej asocjacji łączącej klasy A, B i C liczność roli klasy 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 sezon Zespół Mecz bramkarz Gracz Zapis gole nasze gole ich 22

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, każda taka zamiana związana jest z utratą informacji o związku, zachodzącym w obrębie pewnej grupy obiektów. K2 K2 K A K3 K a a2 A K3 KA m a a2 m Asocjacja n-arna zostaje zamieniona na klasę i n wzajemnie niezależnych asocjacji binarnych. 23

Ograniczenia; przykład () Pracownik dane osobowe stanowisko pensja {pensja <= 5000} {nigdy nie maleje} ograniczenie statyczne Ograniczenia stanowią kolejny z mechanizmów rozszerzalności w UML (po stereotypach i wartościach etykietowanych). ograniczenie dynamiczne (ważny jest poprzedni stan bytu, na który jest nakładane ograniczenie) Konto {xor} Firma 24

Ograniczenia; przykład (2) jest_członkiem {subset} Komitet jest_przewodniczącym podwładny pracownik pracodawca Firma szef {.pracodawca =.szef.pracodawca} Ograniczenie lub adnotacja 25