Projektowanie systemw informacyjnych Wykad 3 Wprowadzenie do obiektowoci

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

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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 2

UML: Krótka charakterystyka • UML (Unified Modeling Language) powstał w rezultacie połączonych wysiłków trzech znanych metodologów: G. Booch’a, I. Jacobsona i J. Rumbaugh’a 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 3

UML: Krótka charakterystyka (cd. ) Wady i zalety metodyk, których autorami są twórcy UML: 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. 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 4

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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 5

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: <<nazwa stereotypu>> lub ikona. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 6

Stereotypy (cd. ) Przykłady stereotypów: P 1 <<używa>> P 2 P 3 <<aktor>> jest równoważne Klient K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 7 Klient <<rozszerza>> P 4

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. Przykłady list wartości etykietowanych: {autor = “Jan Nowak”, termin zakończenia = “ 31 Maja 1999”, status = analiza} {abstrakcyjna = TRUE} można skrócić do {abstrakcyjna} 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 8

Klasy 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. 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: Nazwa, czyli językowy identyfikator klasy obiektu Typ, czyli struktura (budowa) obiektu - poprzez atrybuty Metody, czyli operacje, które można wykonać na obiekcie 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. . . K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 9

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. Obiekty KONTO Klasa wszystkich kont Wpłać Sprawdź stan Nalicz procent Wypłać Numer: integer Stan konta: integer Właściciel: string Upoważniony: . . . . Upoważnij Porównaj podpis import inwariantów Zlikwiduj konto Podaj osoby upoważnione K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 10 Numer: 1234321 Stan konta: 34567 Właściciel: Jan Kowalski Upoważniony: . . Numer: 1234567 Stan konta: 454545 Właściciel: Adam Nowak Upoważniony: . .

Oznaczenia klas (1) Trzy pola: nazwy, atrybutów i metod. Możliwe są różne poziomy szczegółowości. 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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 11

Oznaczenia klas (2) gdzie: dostępność jest określana przez trzy symbole: + publiczna - prywatna # chroniona 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 12

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łącz. XWindow(xwin: XWindow*) <<trwała>> Prostokąt punkt 1: Punkt punkt 2: Punkt «konstruktor» Prostokąt(p 1: Punkt, p 2: Punkt) «zapytania» obszar(): Real aspekt(): Real. . . «aktualizacje» przesuń (delta: Punkt) przeskaluj(współczynnik: Real) Stereotypy mogą być użyte dla oznaczenia grupy elementów. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 13

Struktury generalizacji-specjalizacji (1) Asystent Osoba Pracownik Adiunkt Docent Profeso r K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 14 Asystent Adiunkt Docent generalizacja specjalizacja 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). Profeso r

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

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

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

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

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

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. W zależności od poziomu szczegółowości możliwe są następujące oznaczenia obiektu: nazwa_obiektu : nazwa_klasy nazwa_atrybutu = wart_atrybutu. . . nazwa_obiektu : nazwa_klasy K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 20 : nazwa_klasy nazwa_atrybutu = wart_atrybutu. . . : nazwa_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. wiek pracownik. zwolnij KONTO. Oblicz_procent Niektóre metody zawarte w ramach klasy odnoszą się do jej ekstensji: KL_pracownik. nowy KL_pracownik. zlicz KL_KONTO. Oblicz_sumę Klasa może mieć nie jedną lecz wiele ekstensji. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 21

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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 22

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. Sekwencja Klasyczne klasyfikacje w biologii: tylko liście w drzewie klas mogą być klasami konkretnymi. Osoba prawna Osoba fizyczna K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 23 pierwszy następny Firma Sekwencja int Sekwencja char . . . implementacje

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

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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 25

Interfejsy, zależności, uszczegółowienia zależność Osoba {abstrakcyjna} <<interfejs>> IPracownik Firma uszczegółowienie Pracownik Uszczegółowienie (refinement), o notacji z premedytacją podobnej do generalizacji, oznacza zgodnie z nazwą, większy poziom szczegółowości. Stereotyp <<interfejs>> 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 26

Interfejsy, zależności, uszczegółowienia (cd. ) Dla poprzedniego diagramu można zastosować inną, bardziej zwięzłą notację. IPracownik Firma Pracownik 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. Osoba K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 27

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 Pracuje_dla 1. . * Osoba 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 28

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

Asocjacje skierowane Zamówienie data. Złożenia czy. Zapłacone suma. Do. Zapłaty realizuj() zamknij() * 1 Klient nazwisko adres wiarygodność() 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. * Pozycja. Zamówienia ilość cena czy. Zrealizowana * K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 30 1 Produkt

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

Oznaczanie asocjacji (cd. ) Jest_członkiem * * Osoba Komitet 1 Jest_przewodniczącym * 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 0. . 1 szef 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 jest polecane. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 32

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

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. Osoba nazwisko pesel adres Osoba Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 34 nazwisko pesel adres zarobek stanowisko Pracuje_w 1. . * 0. . 1 Firma nazwa adres Zatrudnienie zarobek stanowisko Pracuje_w 1. . * 0. . 1 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 Osoba data_urodzenia /wiek Wydział {wiek = data_bieżąca - data_urodzenia} * Sekcja zatrudnia * 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 też oznaczyć poprzedzając ukośnikiem rolę asocjacji. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 35

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