Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta, Ewa Stemposz.

Podobne prezentacje


Prezentacja na temat: "K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta, Ewa Stemposz."— Zapis prezentacji:

1 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wprowadzenie do obiektowości, cz. 2 Wykład 3

2 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 2 Zagadnienia Krótka charakterystyka UML Mechanizmy rozszerzalności: stereotypy i wartości etykietowane Klasy Metody jako przykład inwariantów klasy Struktury generalizacji-specjalizacji Bezpośrednie i pośrednie wystąpienia klasy Ekstensja klasy Klasa konkretna a klasa abstrakcyjna Rozszerzenia i ograniczenia w podklasie Interfejsy, zależności, uszczegółowienia Asocjacje

3 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 3 UML: Krótka charakterystyka UML (Unified Modeling Language) powstał w rezultacie połączonych wysiłków trzech znanych metodologów: G. Boocha, I. Jacobsona i J. Rumbaugha i cieszy się aktualnie bardzo dużą popularnością. Prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania. UML jest metodyką projektowania, tzn. zestawem pojęć, oznaczeń, diagramów oraz zaleceń praktycznych. Notacja UML, która opiera się o podstawowe pojęcia obiektowości może być wykorzystana w dowolnej metodyce. Pojęcia UML, wynikające z doświadczenia jej twórców, mają w założeniu przykrywać większość istotnych aspektów modelowanych systemów. UML jest składową standardu OMG (CORBA). Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za twór przereklamowany: niestabilny, zbyt ciężki, źle zdefiniowany. UML ma konkurentów w postaci metodyki i notacji OPEN, design by contracts oraz innych.

4 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 4 UML: Krótka charakterystyka (cd.) OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu implementacji (konstrukcji). OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji (konstrukcji). OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. Wady i zalety metodyk, których autorami są twórcy UML: Istnieje wiele aspektów projektowania systemów, które nie zostały przykryte przez żadną z wyżej wymienionych metodyk, np. włączenie prototypowania w cykl życiowy, rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów i inne. Celem UML jest przykrycie również tych aspektów.

5 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 5 Diagramy definiowane w UML Diagramy przypadków użycia (use case) Diagramy klas, w tym diagramy pakietów Diagramy zachowania się (behavior): Diagramy stanów Diagramy aktywności Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy, celem jej ułatwienia.

6 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 6 Mechanizmy rozszerzalności: stereotypy Stereotypy są jednym z mechanizmów rozszerzalności UML. Dają możliwość definiowania nowych elementów, co ułatwia przystosowanie UML do specyficznego procesu, do preferencji użytkownika oraz pozwala na uszczegóławianie semantyki modelu: Stereotypy są wyrażeniami językowymi umożliwiającymi meta-klasyfikację elementów modelu. Istnieje lista stereotypów dla każdego rodzaju elementu UML. Element modelu może mieć co najwyżej jeden stereotyp. Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne stereotypy. Stereotypy mogą mieć implikacje semantyczne (ograniczenia). Notacja: > lub ikona.

7 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 7 Stereotypy (cd.) Przykłady stereotypów: P1P2 > P3 P4 > Klient jest równoważne

8 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 8 Mechanizmy rozszerzalności: wartości etykietowane Wartość etykietowaną stanowi ciąg znaków o postaci: słowo kluczowe = wartość. Listę wartości etykietowanych (oddzielonych przecinkami) umieszcza się w {}. Dowolny element modelu, zbudowanego w UML, może być skojarzony z listą wartości etykietowanych. {autor = Jan Nowak, termin zakończenia = 31 Maja 1999, status = analiza} Przykłady list wartości etykietowanych: {abstrakcyjna = TRUE}{abstrakcyjna} można skrócić do W ten sposób można na diagramach umieścić dowolną dodatkową informację. Zakłada się, że narzędzia CASE umożliwią odszukanie odpowiedniego elementu na podstawie słowa kluczowego i skojarzonej z nim wartości.

9 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 9 Klasy 2. Klasa jest miejscem przechowywania tych cech grupy obiektów, które są niezmienne (inwariantów) dla wszystkich członków grupy. Klasa nie jest zbiorem obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus ewentualnie własne. 2. Klasa jest miejscem przechowywania tych cech grupy obiektów, które są niezmienne (inwariantów) dla wszystkich członków grupy. Klasa nie jest zbiorem obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus ewentualnie własne. Najważniejsze inwarianty to: Możliwe są inne inwarianty: Zdarzenia lub wyjątki, które mogą zachodzić w operacjach na obiekcie Obsługa zdarzeń lub wyjątków (reguły aktywne) Lista eksportowa określająca, co jest dostępne z zewnątrz Ograniczenia, którym może podlegać obiekt klasy Nazwa, czyli językowy identyfikator klasy obiektu Typ, czyli struktura (budowa) obiektu - poprzez atrybuty Metody, czyli operacje, które można wykonać na obiekcie Dwa rozumienia pojęcia klasa - niezbyt zgodne: 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze obiektów Osoba. 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze obiektów Osoba.

10 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 10 Metody jako przykład inwariantów klasy Zwykle, mamy do czynienia z wieloma obiektami tej samej klasy, np. z wieloma kontami. Nie byłoby zbyt celowe, aby każdy z takich obiektów przechowywał w sobie własną kopię metod lub informacji o swoim typie (budowie). Ta informacja jest przechowywa w jednym miejscu, w klasie. Nie byłoby zbyt celowe, aby każdy z takich obiektów przechowywał w sobie własną kopię metod lub informacji o swoim typie (budowie). Ta informacja jest przechowywa w jednym miejscu, w klasie. Numer: Stan konta: Właściciel: Jan Kowalski Upoważniony:.... Wypłać Wpłać Sprawdź stan Upoważnij Podaj osoby upoważnione Porównaj podpis Zlikwiduj konto Nalicz procent Numer: integer Stan konta: integer Właściciel: string Upoważniony: Numer: Stan konta: Właściciel: Adam Nowak Upoważniony:.... Klasa wszystkich kont Obiekty KONTO import inwariantów

11 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 11 Oznaczenia klas (1) Trzy pola: nazwy, atrybutów i metod. Możliwe są różne poziomy szczegółowości. Okno rozmiar czy_widoczne Okno rozmiar czy_widoczne wyświetl() schowaj() Okno rozmiar: Obszar czy_widoczne: Boolean wyświetl() schowaj() Pole nazwy: stereotyp nazwa_ klasy lista_wart_etyk Pole atrybutów: atrybuty są opisywane (w kolejności tak, jak podano) poprzez stereotyp dostępność nazwa_atrybutu : typ = wart_początkowa lista_wart_etyk Pole metod: metody są opisywane, jak poniżej stereotyp dostępność nazwa_metody (lista_arg) : typ_wart_zwracanej lista_wart_etykt lista_arg: rodzaj nazwa_arg : typ = wart_początkowa

12 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 12 Oznaczenia klas (2) gdzie: dostępność jest określana przez trzy symbole: rodzaj definiuje sposób, w jaki metoda korzysta z danego argumentu: in: metoda może czytać argument, ale nie może go zmieniać out: może zmieniać, nie może czytać inout: może czytać i zmieniać Wszystkie elementy specyfikacji klasy za wyjątkiem nazw (klasy, atrybutu, metody) są opcjonalne. + publiczna - prywatna # chroniona

13 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 13 Oznaczenia klas (3) Okno {abstrakcyjna, autor=Kowalski status=przetestowane} +rozmiar: Obszar = (100,100) #czy_widoczne: Boolean = false +rozmiar_domyślny: Prostokąt #rozmiar_maksymalny: Prostokąt -xwskaźnik: XWindow* +wyświetl() +schowaj() +utwórz() -dołączXWindow(xwin: XWindow*) > Prostokąt punkt1: Punkt punkt2: Punkt «konstruktor» Prostokąt(p1: Punkt, p2: Punkt) «zapytania» obszar(): Real aspekt(): Real... «aktualizacje» przesuń (delta: Punkt) przeskaluj(współczynnik: Real) Stereotypy mogą być użyte dla oznaczenia grupy elementów.

14 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 14 Struktury generalizacji-specjalizacji (1) Generalizacja/specjalizacja jest związkiem pomiędzy klasami. Związek ten łączy klasę bardziej ogólną (nadklasę) z jedną lub więcej klas będących jej specjalizacjami (podklasami). Klasy mogą tworzyć hierarchię lub inną strukturę bez pętli. Import inwariantów do klas (dziedziczenie) jest tranzytywny (przechodni). specjalizacja generalizacja Pracownik Osoba AsystentAdiunkt Profeso r DocentAsystentAdiunkt Profeso r Docent Pracownik Osoba

15 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 15 Struktury generalizacji-specjalizacji (2) K1 K2 K3 Struktura typu pętla jest zabroniona PracownikStudent Osoba Student_asystent Struktura typu krata jest dopuszczalna

16 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 16 Struktury generalizacji-specjalizacji (3) OSOBA NAZWISKO ROK_UR Wiek() PRACOWNIK ZAROBEK DZIAŁ FOTO ZarobekNetto() ZmieńZarobek(...) STUDENT NR_INDEKSU WYDZIAŁ WstawOcenę(...) ZaliczSemestr() JPEGGIF GRAFIKA ROZMIAR Wyświetl(...) Atrybut PRACOWNIKa FOTO należy do własnej klasy. Generalnie, struktura klas może być semantycznie bardziej złożona niż hierarchia. Atrybut PRACOWNIKa FOTO należy do własnej klasy. Generalnie, struktura klas może być semantycznie bardziej złożona niż hierarchia.

17 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 17 Struktury generalizacji-specjalizacji (4) Pompa ciśnienie ssania ciśnienie tłoczenia przepływ Wymiennik ciepła powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie typ wyposażenia typ pompy typ zbiornika aspekt generalizacji (dyskryminator) Wyposażenie nazwa wytwórca koszt Dyskryminator jest atrybutem opcjonalnym

18 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 18 Struktury generalizacji-specjalizacji (5) Wyposażenie nazwa wytwórca koszt ciśnienie ssania ciśnienie tłoczenia przepływ powierzchnia wymiany średnica rury objętość ciśnienie typ wyposażenia Pompa ciśnienie ssania ciśnienie tłoczenia przepływ Wymiennik ciepła powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie typ wyposażenia Wyposażenie nazwa wytwórca koszt

19 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 19 Wieloaspektowe generalizacje-specjalizacje Pojazd {overlapping} Pojazd wiatrowy Pojazd silnikowy Pojazd lądowy Pojazd wodny napęd teren {overlapping} Drzewo DąbBrzozaSosna {disjoint, incomplete} gatunek drzewa disjont - rozłączny (domyślne) overlapping - pokrywające się complete - zupełny (domyślne) incomplete - niezupełny

20 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 20 Bezpośrednie i pośrednie wystąpienia klasy Wystąpienie klasy (instancja klasy) oznacza obiekt, który jest podłączony do danej klasy, jest jej członkiem. Wystąpienia mogą być: bezpośrednie i pośrednie. Obiekt jest wystąpieniem bezpośrednim swojej klasy i wystąpieniem pośrednim wszystkich jej nadklas. nazwa_obiektu : nazwa_klasy nazwa_atrybutu = wart_atrybutu... :nazwa_klasy nazwa_atrybutu = wart_atrybutu... nazwa_obiektu : nazwa_klasy : nazwa_klasy W zależności od poziomu szczegółowości możliwe są następujące oznaczenia obiektu:

21 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 21 Ekstensja klasy Ekstensja klasy (class extent) = aktualny (zmienny w czasie) zestaw wszystkich wystąpień tej klasy. Niektóre metody zawarte w ramach klasy odnoszą się do jej wystąpień: pracownik.wiekpracownik.zwolnijKONTO.Oblicz_procent Niektóre metody zawarte w ramach klasy odnoszą się do jej ekstensji: KL_pracownik.nowyKL_pracownik.zliczKL_KONTO.Oblicz_sumę Klasa może mieć nie jedną lecz wiele ekstensji.

22 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 22 Operacja abstrakcyjna Operacja abstrakcyjna jest to operacja wyspecyfikowana w nadklasie, której implementacja musi znaleźć się w ramach podklasy. UML pozwala na oznaczenie bytu abstrakcyjnego za pomocą wartości etykietowanej abstrakcyjna = TRUE (TRUE można opuścić) lub napisanie nazwy bytu italikami. Pracownik już-zarobił-w-tym-roku oblicz wypłatę {abstrakcyjna} Pracownik godzinowy stawka godzinowa stawka świąteczna oblicz wypłatę Pracownik etatowy zarobek tygodniowy oblicz wypłatę Pracownik na zlecenie zarobek miesięczny oblicz wypłatę Specyfikacja metody oblicz wypłatę znajduje się w klasie abstrakcyjnej Pracownik. Każda klasa konkretna zawiera właściwą dla siebie implementację tej metody.

23 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 23 Klasy abstrakcyjne, klasy konkretne Klasa abstrakcyjna nie ma (nie może mieć) bezpośrednich wystąpień i służy wyłącznie jako nadklasa dla innych klas. Jest wspólną częścią definicji innych klas. Klasa abstrakcyjna może (ale nie musi) zawierać abstrakcyjne operacje. Klasa konkretna może mieć (ma prawo mieć) wystąpienia bezpośrednie. Klasa konkretna może zawierać implementacje abstrakcyjnych operacji, ale nie musi, ponieważ implementacje mogły być już zawarte w nadklasach. Klasa konkretna nie może posiadać operacji abstrakcyjnych. Klasa abstrakcyjna nie ma (nie może mieć) bezpośrednich wystąpień i służy wyłącznie jako nadklasa dla innych klas. Jest wspólną częścią definicji innych klas. Klasa abstrakcyjna może (ale nie musi) zawierać abstrakcyjne operacje. Klasa konkretna może mieć (ma prawo mieć) wystąpienia bezpośrednie. Klasa konkretna może zawierać implementacje abstrakcyjnych operacji, ale nie musi, ponieważ implementacje mogły być już zawarte w nadklasach. Klasa konkretna nie może posiadać operacji abstrakcyjnych. Osoba prawna Osoba fizyczna Firma Sekwencja pierwszy następny Sekwencja int... implementacje Sekwencja char...implementacje Klasyczne klasyfikacje w biologii: tylko liście w drzewie klas mogą być klasami konkretnymi.

24 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 24 Klasy abstrakcyjne, klasy konkretne (cd.) A - klasa abstrakcyjna K - klasa konkretna K1 K2K3 K4K5 K A,K K K Klasa abstrakcyjna nie może znaleźć się w liściu drzewa. Klasa konkretna może zająć każde położenie.

25 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 25 Rozszerzenia i ograniczenia w podklasie Obiekt będący bezpośrednim wystąpieniem danej klasy jest jednocześnie wystąpieniem pośrednim wszystkich jej nadklas. Podklasa nie może omijać lub zmieniać atrybutów nadklasy. Podklasa może zmienić (przesłonić) metodę nadklasy, ale bez zmiany jej specyfikacji. Podklasa może dowolnie dodawać nowe atrybuty i metody (rozszerzać). Podklasa może ograniczać wartości atrybutów. Np. Koło jest podklasą klasy Elipsa, gdzie obie średnice elipsy są sobie równe. Ograniczenia mogą spowodować, że część metod przestanie być poprawna. Np. zmiana jednej ze średnic obiektu - dozwolona dla obiektu klasy Elipsa - jest niedopuszczalna w obiekcie podklasy Koło, gdyż muszą tam być zmienione obie średnice.

26 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 26 Interfejsy, zależności, uszczegółowienia Osoba {abstrakcyjna} Pracownik IPracownik > Firma zależność uszczegółowienie Uszczegółowienie (refinement), o notacji z premedytacją podobnej do generalizacji, oznacza zgodnie z nazwą, większy poziom szczegółowości. Stereotyp > poprzedza nazwę klasy, która zawiera jedynie specyfikacje metod, bez ich implementacji. Wszystkie metody są tu publiczne. W UML interfejs nie zawiera atrybutów. Implementacje metod wyspecyfikowanych w Ipracownik zawiera klasa Pracownik. Zależność (dependency) wskazuje tu na klasę, która korzysta z danego interfejsu.

27 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 27 Interfejsy, zależności, uszczegółowienia (cd.) Dla poprzedniego diagramu można zastosować inną, bardziej zwięzłą notację. Pracownik IPracownik Osoba Firma Klasa abstrakcyjna i interfejs zostały tu potraktowane w podobny sposób - jako definicje interfejsów do klasy Pracownik. Jednakże, istnieje między nimi pewna różnica. Klasy abstrakcyjne, w przeciwieństwie do interfejsu, mogą zawierać implementacje metod.

28 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 28 Asocjacje Oznaczenia klas są połączone liniami oznaczającymi asocjacje, czyli zbiory powiązań pomiędzy obiektami tych klas, np. asocjacja Pracuje_dla pomiędzy klasą Osoba i klasą Firma. Czarny trójkącik określa kierunek (czytania) wyznaczony przez nazwę asocjacji. W danym przypadku określa on, że osoba pracuje dla firmy, a nie firma pracuje dla osoby. Nazwy asocjacji, takie jak np. Pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę przedmiotową. Firma Osoba Pracuje_dla 1..* 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), oznaczającą minimalną i maksymalną liczbę takich obiektów.

29 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 29 Liczność asocjacji Liczność jest oznaczana na końcach asocjacji binarnych, tzn. takich, które łączą dwie lub jedną klasę. 1 1,2,3,... 2,3,4,... 3,4,5 2,4,18 1 0,1 0,1,2, * 2..* 3-5 2,4, * * UML znaczenie PaństwoStolica FirmaPracownik OsobaAdres 1 * 0..* 0..1

30 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 30 Asocjacje skierowane Zamówienie dataZłożenia czyZapłacone sumaDoZapłaty realizuj() zamknij() Klient nazwisko adres wiarygodność() *1 Produkt *1 1 * Na diagramach UML można zaznaczać kierunek nawigacji 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

31 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 31 Role asocjacji, oznaczanie asocjacji Asocjacje mogą być także wyposażone w nazwy ról (przy odpowiednich końcach), np. pracodawca i pracownik. Firma Osoba Pracuje_dla * 1..* pracodawca pracownik szef podwładny * 0..1 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 klasy FirmaPracownik 1..*

32 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 32 Oznaczanie asocjacji (cd.) Osoba Komitet Jest_członkiem ** Jest_przewodniczącym 1* Na diagramie powyżej dwie asocjacje łączą te same klasy; w takim wypadku obie asocjacje muszą być oznaczone. do oznaczenia asocjacji można użyć nazwy lub dwóch ról lub jednej roli. Pracownik szef * 0..1 Z diagramów, z założenia, usuwa się wszelką informację redundantną (dla zwiększenia ich czytelności) - dlatego używanie nazwy i ról asocjacji jednocześnie nie jest polecane.

33 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 33 Atrybuty asocjacji W odróżnieniu od OMT, w UML atrybuty asocjacji muszą tworzyć nową klasę. Plik Użytkownik Prawo dostępu Dostęp Dostępny dla { dostęp oznacza: czytanie lub czytanie-pisanie} * * Osoba nazwisko pesel adres Firma nazwa adres Zatrudnienie zarobek stanowisko szef pracownik Pracuje_w Ocena wydajności ocena Kieruje 0..1 * 1..*

34 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 34 Kiedy stosować atrybuty asocjacji Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutó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 Pracuje_w Zatrudnienie zarobek stanowisko * Osoba nazwisko pesel adres zarobek stanowisko Firma nazwa adres Pracuje_w *

35 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 35 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 /. Osoba data_urodzenia /wiek {wiek = data_bieżąca - data_urodzenia} WydziałSekcjaPracownik Budynek zatrudnia zlokalizowana_w pracuje_w * * * * Asocjacja pracuje_w jest asocjacją pochodną, którą można wyznaczyć poprzez asocjacje zatrudnia i zlokalizowana_w. Asocjację pochodną można też oznaczyć poprzedzając ukośnikiem rolę asocjacji. atrybut pochodny: /wiek

36 K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 36 Przykładowy diagram klas poprzedza następuje_po zawiera jest_składową zapisany_na prowadzony_dla prowadzony_przez prowadzi PracownikStudent Osoba Kurs Profesor Wykład 1..* * * *


Pobierz ppt "K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta, Ewa Stemposz."

Podobne prezentacje


Reklamy Google