Analiza zorientowana obiektowo (Object-Oriented Analysis, OOA)

Prezentacja na temat: "Analiza zorientowana obiektowo (Object-Oriented Analysis, OOA)"— Zapis prezentacji:

1 Analiza zorientowana obiektowo (Object-Oriented Analysis, OOA)
Bartosz Baliś, Na podstawie Slajdy Iana Sommerville’a Slajdy E. Stemposz i K. Subieta „Analiza i projektowanie systemów informatycznych” Źródła: 1. Russel Kay, QuickStudy: System Development Life Cycle, Computerworld, May 2. 3. Ian Sommerville, Inżynieria Oprogramowania 4. Wikipedia

2 Wybrane zagadnienia obiektowości

3 Podstawowe pojęcia obiektowości
Obiekt – struktura danych, występująca łącznie z operacjami dozwolonymi do wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanej rzeczywistości. Hermetyzacja – rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić. Klasa – Zgrupowanie obiektów o tych samych charakterystykach. Dziedziczenie – Wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy) plus cechy nowe. Polimorfizm – Wybór nazwy dla operacji jest określony wyłącznie semantyką operacji. Decyzja o tym, która metoda implementująca daną operację, zależy od przynależności obiektu do odpowiedniej klasy.

4 Własności obiektu Obiekt jest charakteryzowany poprzez:
Tożsamość (identity), która odróżnia go od innych obiektów. Tożsamość obiektu jest niezależna zarówno od wartości atrybutów obiektu, jak i od lokacji bytu odwzorowywanego przez obiekt w świecie rzeczywistym czy też lokacji samego obiektu w przestrzeni adresowej komputera. (W praktyce: tożsamość = trwały wewnętrzny identyfikator obiektu) Programista używa nie bezpośrednio identyfikatora, ale np. nazwy obiektu Stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu). Stan obiektu w danym momencie jest określony przez aktualne wartości jego atrybutów i powiązań z innymi obiektami. Obiekt ma przypisane zachowanie, tj. zestaw operacji, które wolno do stosować do danego obiekru.

5 Przykład obiektu Wypłać Wpłać Porównaj Sprawdź podpis stan
Numer: Stan konta: PLN Właściciel: Jan Kowalski Upoważniony: ... Podpis: … .... Nalicz procent Zlikwiduj konto Obiekt KONTO Podaj osoby upoważnione Upoważnij

6 Przykład obiektu złożonego
Pracownicy Pracownik Pracownik Nazwisko Zatrudnienia Nazwisko Zatrudnienia Zatrudnienie Zatrudnienie Dzieci Dzieci ..... ... ... Dziecko Dziecko Dziecko Dziecko Zatrudnienie Zatrudnienie Stanowisko Stanowisko ..... .....

7 Powiązania pomiędzy obiektami
Możliwe jest tworzenie bezpośrednich powiązań prowadzących od jednego obiektu do innego. Powiązanie jest daną zawierającą identyfikator obiektu. Unika się tu pojęcia wskaźnika, na rzecz czegoś “bardziej abstrakcyjnego” - powiązania. PRACOWNIK FIRMA Nazwisko Nowak Szef o Nazwa Relax Ltd. Zarobek 1500 Zatrudnia o Zatrudnia o Pracuje_w o Zatrudnia o Zalety powiązań: naturalne odwzorowanie semantycznych związków istniejących w dziedzinie problemowej między analizowanymi bytami poprzez powiązania między obiektami; łatwe nawigowanie dzięki wyrażeniom ścieżkowym; zwiększenie szybkości działania. Wady: zwiększona “sztywność” struktury danych; możliwość utraty spójności wskutek “zwisających” wskaźników; możliwość naruszenia reguł hermetyzacji.

8 Klasa a obiekt Klasa = reprezentacja bytu ogólnego („idei” – samochód jako samochód) Klasa przechowuje niezmienne własności grupy obiektów („inwarianty”) Np. każdy samochód ma jakąś markę, jakiś silnik, jakiś typ i kolor nadwozia, można go tankować, otwierać, zamykać, wymieniać olej, ... Obiekt = reprezentacja bytu indywidualnego (ten oto samochód) Konkretne Audi A6, nr rejestracyjny AAA, nr seryjny silnika BBB, właściciel CCC, kolor nadwozia DDD, ...

9 Hermetyzacja; ukrywanie informacji
Hermetyzacja (encapsulation): zgromadzenie elementów struktury i implementacji obiektu w postaci jednej manipulowalnej bryły; oddzielenie specyfikacji obiektu od jego implementacji. Hermetyzacja pośrednio oznacza także ukrycie struktury i implementacji obiektu. Tę własność określa się jako ukrywanie informacji. Hermetyzacja i ukrywanie informacji są różnymi pojęciami, choć mocno powiązanymi. Zasada inżynierii oprogramowania (Parnas, 1972): programista ma tyle wiedzieć o obiekcie programistycznym, ile potrzeba, aby go efektywnie użyć. Wszystko, co może być przed nim ukryte, powinno być ukryte. Hermetyzacja i ukrywanie informacji jest podstawą pojęć: modułu, klasy i ADT. Hermetyzacja ortogonalna (C++) Hermetyzacja ortodoksyjna (Smalltalk) Dowolna własność obiektu (atrybut, metoda,...) może być prywatna (ukryta) lub publiczna Na zewnątrz są widoczne metody; atrybuty obiektu są ukryte. Ergo: prawie każdy atrybut atr jest obsługiwany przez dwie metody: get_atr, set_atr Specjalne środki do specyfikowania własności prywatnych i publicznych.

10 Operacja a metoda (1) Operacja jest funkcją, która może być zastosowana do obiektu. Operacja jest własnością klasy obiektów, ponieważ jest przechowywana w klasie zatrudnij zwolnij wypłać dewidendę możliwe operacje na obiektach klasy Firma Wszystkie obiekty, będące członkami danej klasy, podlegają tym samym operacjom. Dana operacja może być stosowana do obiektów wielu różnych klas, połączonych związkiem generalizacji-specjalizacji. Metoda jest implementacją operacji w jednej z klas połączonych związkiem generalizacji-specjalizacji, co oznacza, że może być wiele metod implementujących daną operację.

11 Operacja a metoda (2) Plik ASCII
Jedna operacja drukuj, ale różne sposoby drukowania. Trzy metody implementujące operację drukuj – polimorfizm (metod). drukuj Plik postscript Plik graficzny Plik Plik ASCII Plik postscript Plik graficzny drukuj drukuj drukuj

12 Komunikat Cccco proszę...? Graj Wypłać 1000 PLN OK, wypłaciłem Wypłać
Numer: Stan konta: PLN Właściciel: Jan Kowalski Upoważniony: ... Podpis: … Wypłać Wpłać Sprawdź stan Upoważnij Podaj osoby upoważnione Porównaj podpis Zlikwiduj konto Nalicz procent Wypłać 1000 PLN OK, wypłaciłem Graj Cccco proszę...?

13 Komunikat a wołanie funkcji (1)
Komunikat: obiekt-adresat poprzedza wywołanie operacji: obiekt.operacja (arg1, arg2,...) - obiekt jest tu domyślnym argumentem metody Wołanie funkcji: obiekt jest komunikowany jako parametr: funkcja (obiekt, arg1, arg2,...) Nie jest to wyłącznie różnica syntaktyczna, gdyż: Dla metody, środowisko na którym działa, może zmieniać się dynamicznie (późne wiązanie metod, w odróżnieniu od wczesnego wiązania dla funkcji). Komunikat nie określa, która z metod implementujących daną operację ma być wywołana; wysłanie komunikatu do konkretnego obiektu powoduje wywołanie metody, implementującej żądaną operację, związanej z danym obiektem. Przykład: operacja drukuj wykonywana iteracyjnie dla zbioru plików o różnym formacie.

14 Komunikat a wołanie funkcji (2)
X = dochody( emeryt ) Y = dochody( pracownik ) Przełączanie, związane z rodzajem obiektu, następuje w ciele funkcji dochody. Funkcję zwykle pisze jeden programista, na wszystkie okazje. Każda zmiana, związana z nowym rodzajem obiektów, wymaga zmian w ciele funkcji. X = emeryt.dochody() Y = pracownik.dochody() Nie ma przełączenia; za każdym razem, w zależności od rodzaju obiektu – adresata komunikatu, wywoływana jest inna metoda dochody. Obie metody implementują operację dochody. Obie metody (i ich programiści) nie muszą nic o sobie wiedzieć.

15 Polimorfizm Z greckiego, polimorfizm – oznacza “wiele form” (postaci) jednego bytu. Słowo “polimorfizm” też jest polimorficzne. Polimorfizm metod – (co zostało już wyjaśnione wcześniej w punkcie „Operacja a metoda”) polega na tym, że operacja wywoływana za pośrednictwem komunikatu może być różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został wysłany; innymi słowy: może istnieć wiele metod implementujących daną operację. Polimorfizm typów (z teorii typów) – polimorfizm w tzw. polimorficznych językach programowania – oznacza istnienie funkcji, które mogą zarówno przyjmować wartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów. Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy, niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy lista rekordów, czy też inna.

16 Obiektowość a redukcja złożoności (1)
Modelowanie świata rzeczywistego jest ułatwione dzięki zastosowaniu podejścia obiektowego. Klasy, grupujące obiekty odwzorowujące byty ze świata rzeczywistego, są najbardziej stabilnym elementem dziedziny problemu. Doświadczenie wykazuje, że oprogramowanie oparte o klasy powstałe w wyniku analizy dziedzinowej jest bardziej odporne na zmiany wymagań niż oprogramowanie skonstruowane w oparciu o jednostki funkcjonalne. Hermetyzacja wspomaga redukcję złożoności poprzez zachęcanie konsumentów, by opierali się raczej na interfejsie do obiektu niż jego wewnętrznej organizacji. Abstrahowanie od szczegółów implementacyjnych znacząco ułatwia proces rozumienia. Ponadto, hermetyzacja pozwala na ukrycie poprawek czy modyfikacji przed konsumentem oprogramowania.

17 Obiektowość a redukcja złożoności (2)
Dziedziczenie pozwala na specjalizowanie strukury i zachowania obiektu podklasy bez ingerowania w struktury i zachowania obiektów nadklas. Poprzez dostarczenie opisu wyjaśniającego zasady organizacji struktury dziedziczenia, można pośrednio wpływać na jej racjonalny rozwój, nawet nie zawsze w kierunku przewidzianym przez jej twórcę. Polimorfizm metod wspiera redukcję złożoności pozwalając, by nowe bardziej wyspecjalizowane komponenty mogły być wykorzystywane w tym samym środowisku, co mniej wyspecjalizowane, bez potrzeby zmiany środowiska przy każdej zmianie komponentów. Polimorfizm parametryczny wspomaga redukcję złożoności umożliwiając definiowanie rodziny klas o takim samym interfejsie i implementacji, różniących się jedynie typem wyspecyfikowanym jako parametr klasy, np. klasa WEKTOR(int) czy WEKTOR(char).

18 Tworzenie modelu obiektowego

19 Analiza vs. projektowanie
Analiza koncentruje się na problemie, projektowanie na rozwiązaniu Celem analizy jest budowa modelu dziedziny, celem projektowania – modelu systemu dla konkretnej platformy, technologii, narzędzi i sprzętu

20 1 2 Tworzenie modelu obiektowego (dwie drogi) Zadania:
Identyfikacja obiektów i klas Identyfikacja związków pomiędzy klasami (generalizacji-specjalizacji oraz asocjacji) Identyfikacja i definiowanie atrybutów Identyfikacja i definiowanie metod i komunikatów Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu. 2 Inny schemat realizacji procesu budowy modelu obiektowego polega na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model przypadków użycia.

21 Identyfikacja klas Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o podobnych własnościach, wyróżnialnych w analizowanej rzeczywistości), to kluczowa umiejętność w obiektowym podejściu do procesu konstrukcji oprogramowania. Klasy są najbardziej stabilnym elementem dziedziny problemowej. Dobry system oparty jest tak dalece, jak tylko jest to możliwe, na klasach reprezentujących grupy bytów wyróżnialnych w dziedzinie problemowej, a nie na funkcjonalności potrzebnej dziś i to dla specyficznego być może zastosowania. Oprogramowanie wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne. Ma to, tzn. oparcie oprogramowania o wykorzystanie klas, duże znaczenie dla technologii ponownego użycia.

22 Typowe klasy Typowe klasy: przedmioty namacalne (samochód, czujnik)
grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części) role pełnione przez osoby (pracownik, wykładowca, student) zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa) interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (pożyczka, spotkanie, sesja) lokalizacje – miejsce przeznaczone dla ludzi lub przedmiotów organizacje (firma, wydział, związek) wydarzenia (posiedzenie sejmu, demonstracja uliczna) koncepcje i pojęcia (zadanie, miara jakości) dokumenty (faktura, prawo jazdy)

23 Obiekty, zbiory obiektów, metadane
W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego rodzaju bytem mamy do czynienia. Należy zwrócić uwagę na następujące aspekty: czy mamy do czynienia z konkretnym bytem w danej chwili czasowej? czy mamy do czynienia z konkretnym bytem w pewnym odcinku czasu? czy mamy do czynienia z opisem tego bytu (dokument, metadane)? czy mamy do czynienia z pewnym zbiorem konkretnych bytów? Np. klasa „samochód”. Może chodzić o: egzemplarz samochodu wyprodukowany przez pewną fabrykę historię stanów pewnego konkretnego samochodu pozycję w katalogu samochodów opisujący własności modelu model samochodu produkowany przez fabrykę Podobnie z klasą „gazeta”. Może chodzić o: konkretny egzemplarz gazety kupiony przez czytelnika konkretne wydanie gazety (niezależne od ilości egzemplarzy) tytuł i wydawnictwo, niezależne od egzemplarzy i wydań partię egzemplarzy danej gazety dostarczaną codziennie do kiosku

24 DDD a RDD Eksperci od podejścia obiektowego do procesu tworzenia oprogramowania dzielą się na dwa obozy w zależności od proponowanego przez nich sposobu identyfikacji klas: w oparciu o dane (DDD – Data Driven Design), w oparciu o odpowiedzialności klas (RDD – Responsibility Driven Design). Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy. DDD – polega na zidentyfikowaniu wszystkich danych w systemie i podziale ich na klasy bez specjalnego rozważania ich odpowiedzialności; przykładem tej techniki jest identyfikacja rzeczowników i fraz rzeczownikowych w tekście wymagań. RDD – tutaj rozpoznaje się wszystkie odpowiedzialności systemu (w oparciu o potrzeby przyszłych użytkowników) i bazując na nich wyróżnia się klasy; przykładem jest tu metoda CRC wykorzystywana w kilku metodykach. Najbardziej efektywne, jak to z reguły w praktyce bywa, są techniki mieszane, wykorzystujące każdą dostępną metodę.

25 Metoda CRC (1) Metoda CRC (Class, Responsibilities, Collaborations) została zaprezentowana przez K. Beck’a i W. Cunningham’a w r. w celu ułatwienia programistom “nie-obiektowym” naukę “myślenia obiektowego”. Okazała się być przydatna na wczesnych etapach rozwoju systemu do identyfikacji klas. Metoda CRC nie jest częścią UML. Na małej kartce papieru notuje się następujące elementy: u góry kartki – nazwę klasy, po lewej stronie – odpowiedzialności (responsibilities), czyli obowiązki danej klasy, po prawej stronie – współpracowników (collaborators), czyli klasy, które pomagają danej klasie w wypełnianiu jej obowiązków. Odpowiedzialności danej klasy opisywane są na wysokim poziomie abstrakcji – jako podstawa (główny powód, cel) zaistnienia danej klasy. Są powiązane z operacjami, które można wykonywać na obiektach tej klasy, ale są wyrażone w bardziej ogólny sposób. Np. akceptowalna jest odpowiedzialność, taka jak “zarządzanie danymi dotyczącymi książki”, co implikuje operacje, które czytają i zapisują dane. Klasa nie powinna mieć więcej niż trzy, cztery odpowiedzialności (wiele klas ma tylko jedną lub dwie). Jeśli klasa ma zbyt dużo odpowiedzialności (niska kohezja), należy zastanowić się czy zostały one dostatecznie zwięźle określone lub czy nie rozdzielić odpowiedzialności i mieć więcej klas. Zbyt wielu współpracowników sugeruje zbyt silne skojarzenie klas.

26 Metoda CRC (2) CRC wykorzystuje się wspólnie z przypadkami użycia – postępując w zgodzie ze scenariuszem identyfikuje klasy, których odpowiedzialności włączają potrzebną operację i znajduje ewentualnych współpracowników, zaangażowanych w realizację danego przypadku użycia. Upraszczając – odpowiedzialności każdej klasy mogą być postrzegane jako suma operacji, które można wykonywać na obiektach tej klasy. Kiedy brakuje klasy, która mogła by wykonać potrzebną operację, oznacza to błędy lub braki w modelu. Być może trzeba dodać nową klasę lub zmienić odpowiedzialności lub współpracowników klasy już istniejącej (być może jedno i drugie). Związek generalizacji-specjalizacji jest tu wyjaśniany w kategoriach współdzielenia odpowiedzialności i współpracowników. Klasa specjalizowana ma te własności odpowiednio większe. Sytuacja ta może też być postrzegana w drugą stronę – jeśli dwie klasy mają nakładające się odpowiedzialności i współpracowników, to może to być sugestia dla wydzielenia dla nich nadklasy.

27 DDD; identyfikacja klas poprzez rzeczowniki
Identyfikacja klas poprzez identyfikację rzeczowników i fraz rzeczownikowych w tekście specyfikującym wymagania użytkownika jest jedną z podstawowych, powszechnie stosowanych technik. Proces ten przebiega w dwóch etapach: 1 Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich rzeczowników i fraz rzeczownikowych w tekście wymagań. Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka potrzeba. Nazwy przyszłych klas powinny być rozważane jako rzeczowniki w liczbie pojedynczej. 2 Niektórzy analitycy konstruują dwie listy potencjalnych kandydatów: silnych i słabych. Kandydaci są przenoszeni w razie potrzeby z listy na listę. Taka technika chroni przed utratą informacji, być może przydatnej krok dalej.

28 Redukcja zbioru potencjalnych kandydatów
Odrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza rzeczownikowa): jest redundantny – tzn. gdy istnieją różne rzeczowniki dla określenia tego samego bytu; trzeba tu brać pod uwagę następujący fakt: byty mogą być podobne, ale niekoniecznie dokładnie takie same, a to z kolei może wskazywać na związek generalizacji-specjalizacji istniejący między nimi; jest nieuchwytny – trudno jest określić, co właściwie oznacza i w jaką klasę miałby być odwzorowany – być może inne elementy notacji byłyby bardziej użyteczne do opisania go; oznacza wydarzenie lub operację – tutaj pomocnicze może być zadanie pytania, czy obiekty przyszłej klasy miałyby atrybuty, zachowanie i tożsamość; stanowi wyrażenie metajęzyka, tzn. służy do definiowania czegoś, np. rzeczowniki wymagania czy system używane są raczej w procesie modelowania niż do reprezentowania bytów istniejących w analizowanej dziedzinie problemowej; oznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy – z reguły nie istnieje potrzeba do modelowania ich w postaci klasy; oznacza atrybut – coś prostszego niż klasa, bez interesującego zachowania.

29 DDD – identyfikacja klas; przykład
Przykład wymagań dla biblioteki: Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej książki. Tylko personel może wypożyczać czasopisma. Wypożyczający może mieć jednocześnie wypożyczonych sześć pozycji, podczas gdy osoba pracująca w bibliotece może mieć ich wypożyczonych dwanaście. System musi rejestrować wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł (ograniczeń). Zostawiamy: książka, czasopismo, egzemplarz książki, wypożyczający, personel Odrzucamy: biblioteka (1 obiekt i to znajdujący się na zewnątrz systemu ), system (wyrażenie metajęzyka), osoba pracująca w bibliotece oznacza to samo co personel, reguła (nieuchwytne), ograniczenie (nieuchwytne) ? pozycja (?), wypożyczenie (?), zwrot (?), . Każdy rzeczownik, kandydat na przyszłą klasę, jest tu rozważany w liczbie pojedynczej.

30 CRC – identyfikacja klas; przykład
Pracownik Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi pracownika biblioteki kontrola wypełniania ograniczeń narzuconych na liczbę egzemplarzy egzemplarz Książka Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi książki sprawdzanie, czy są egzemplarze możliwe do wypożyczenia egzemplarz

31 Identyfikacja generalizacji-specjalizacji
Identyfikacja związków generalizacji-specjalizacji Osoba ? Pozycja . Personel Wypożyczający Książka Czasopismo Książka Egzemplarz książki nie jest rodzajem pozycji wydawniczej, jaką oznacza tu każde wystąpienie klasy Książka. Egzemplarz książki

32 Identyfikacja asocjacji (1)
Identyfikacja asocjacji: podobnie, jak klasy można identyfikować poprzez wyszukiwanie rzeczowników (czy fraz rzeczownikowych) w tekście wymagań, tak asocjacje mogą być identyfikowane poprzez wyszukiwanie w tym tekście czasowników (fraz czasownikowych). Z przykładu z biblioteką moglibyśmy wydedukować następujące asocjacje: “wypożyczył”, “zwrócił”, “jest egzemplarzem”. Nie wszystkie wystąpiły “jawnie” – w postaci czasowników (czy fraz czasownikowych). Asocjacja (o danej semantyce) musi połączyć Klasę A z klasą B jeżeli w czasie działania programu: obiekt klasy A wysyła komunikat do obiektu klasy B, obiekt klasy A tworzy obiekt klasy B (wywołuje konstruktor), obiekt klasy A posiada atrybut będący obiektem (lub kolekcją obiektów) klasy B, obiekt klasy A otrzymuje komunikat z argumentem będącym obiektem klasy B. W skrócie – jeśli obiekt klasy A musi mieć możliwość dostępu do danych pewnego obiektu klasy B, to klasy A i B musi połączyć asocjacja.

33 Identyfikacja asocjacji (2)
Uwaga – nie archiwizujemy tu wypożyczeń; fakt zwrotu jest rejestrowany poprzez usunięcie powiązania wypożyczyła między obiektami klas Osoba i Egzemplarz Książki. wypożyczyła Egzemplarz Książki 1 Osoba 0..1 * Wypożyczenie 1 0..1 1 Egzemplarz Książki Osoba * 2 Preferowane jest rozwiązanie pierwsze – klasa Wypożyczenie nie posiada żadnych własności, ani atrybutów ani operacji.

34 Identyfikacja asocjacji (3)
Sytuacja ulegnie zmianie, gdy do poprzednich wymagań dołożymy sformułowanie: Książki mogą być wypożyczane na okres trzech tygodni, wypożyczanie książek jest archiwizowane. Implikuje to konieczność pamiętania obu dat: wypożyczenia i zwrotu. wypożyczyła Egzemplarz Książki 1 Osoba * * Wypożyczenie data wypożyczenia data zwrotu {data zwrotu - data wypożyczenia <= 3 tygod.} Wypożyczenie 1 * 1 Egzemplarz Książki Osoba * data wypożyczenia data zwrotu 2 {data zwrotu - data wypożyczenia <= 3 tygod.} Oba rozwiązania są tu poprawne.

35 Identyfikacja asocjacji (4)
asocjacja wypożyczył między klasami Personel i Czasopismo nie archiwizuje się wypożyczeń dla czasopism, ani nie zostały nałożone żadne ograniczenia na długość okresu wypożyczenia Personel Czasopismo wypożyczył 0..1 * asocjacja jest egzemplarzem między klasami Książka i Egzemplarz książki Książka Książka kompozycja silniej podkreśla tu związek istniejący między książką (byt wirtualny), a konkretnym egzemplarzem 1 1..* 1..* Egzemplarz książki Egzemplarz książki

36 Diagram klas dla przykładowych wymagań
Osoba Pozycja * /liczba wyp. akt. pozycji Czasopismo Członek bibl. Książka * 0..1 wypożyczył Personel { liczba wyp. akt. pozycji <= 6 } { liczba wyp. akt. pozycji <= 12 } 1..* Egzemplarz książki * Wypożyczenie { data zwrotu – data wypożyczenia <= 3 tygodnie } data wypożyczenia data zwrotu

37 Dalsza lektura Coad, Yourdon – OOA, OOD, OOP
Sommerville – r. „Projektowanie obiektowe”