Projektowanie systemów informacyjnych

Prezentacja na temat: "Projektowanie systemów informacyjnych"— Zapis prezentacji:

1 Projektowanie systemów informacyjnych
Wykład 6 Model obiektowy (3) Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2 Zagadnienia Faza analizy Faza projektowania
Perspektywy: pojęciowa, projektowa i implementacyjna Proces tworzenia modelu obiektowego Identyfikacja obiektów i klas DDD a RDD Metoda CRC Identyfikacja klas poprzez identyfikację rzeczowników Identyfikacja związków między klasami

3 Faza analizy Analiza Czynności wykonywane w fazie analizy to:
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja Czynności wykonywane w fazie analizy to: ustalenie kontekstu projektu (przyszłych użytkowników), ustalenie wymagań użytkowników, rozpoznawanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości będącej przedmiotem projektu (dziedziny problemowej/przedmiotowej). W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej celem jest rozpoznanie tych wszystkich aspektów dziedziny problemowej, które mogłyby być poddane procesowi informatyzacji.

4 Faza projektowania Projektowanie
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja Celem fazy projektowania jest opracowanie szczegółowego planu implementacji systemu. W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji. Projektanci muszą posiadać dobrą znajomość języków, bibliotek i narzędzi stosowanych w trakcie implementacji. Dąży się, by struktura modelu logicznego zachowywała strukturę modelu stworzonego w poprzedniej fazie (analizie) – podejście bezszwowe (seamless). Niewielkie zmiany w dziedzinie problemowej powinny implikować niewielkie zmiany w modelu logicznym. Może to być realizowane, np. poprzez wykorzystanie podejścia obiektowego.

5 Zadania fazy projektowania
Zadania stojące przed wykonawcami w fazie projektowania: Uszczegółowienie wyników analizy. Model logiczny musi być wystarczająco szczegółowy, aby mógł stanowić podstawę dla implementacji. Stopień szczegółowości zależy od poziomu zaawansowania programistów. Dostosowanie do ograniczeń i możliwości środowiska implementacji. Projektowanie tych składowych systemu, które nie są związane z dziedziną problemową. Optymalizacja systemu. Określenie fizycznej struktury systemu (projekt architektury systemu).

6 Uszczegóławianie wyników analizy (1)
Uszczegóławianie wyników analizy: poprzez podanie reguł odwzorowania notacji dla danych (notacji stosowanej w modelu pojęciowym – wyniku fazy analizy) w struktury tego języka programowania, który będzie wykorzystany do implementacji systemu. Dane z analizy Realizacja w C/C++ typedef struct { char Ulica[30]; int NumerDomu; int NumerMieszkania; char Miasto[30]; char Kod[5]; } TypAdres; char Imię[30]; char Nazwisko[30]; TypAdres Adres; } TypDaneOsobowe; Adres Ulica Numer domu Numer mieszkania Miasto Kod Dane osobowe Imię Nazwisko Adres

7 Uszczegóławianie wyników analizy (2)
Uszczegóławianie metod: Podanie pełnych sygnatur metod (wyspecyfikowanie typów argumentów oraz wartości zwracanej dla każdej metody). Zastąpienie niektórych prostych metod publicznym dostępem do atrybutów, np. metod: pobierzNazwisko, ustawNazwisko, etc. Zastąpienie niektórych atrybutów redundantnych (pochodnych) wyłącznie przez metody (usunięcie atrybutu z klasy), np. /wiek --> policzWiek() // wiek = bieżącaData - dataUrodzenia; /kwotaDochodu --> policzDochód() // dochód = przychód - koszty; Decyzję o usunięciu atrybutu pochodnego z klasy podejmujemy w oparciu o koszt liczenia, częstość zmian i częstość wykorzystywania, np. możemy zdecydować się na przechowywanie atrybutu o wysokim koszcie liczenia, rzadko zmienianej wartości i często wykorzystywanym.

8 Uszczegóławianie wyników analizy (3)
Określenie sposobów implementacji asocjacji: Asocjacje można zaimplementować na wiele sposobów, z reguły poprzez wprowadzenie dodatkowych atrybutów. Mogą one być następujące: obiekt (lub kolekcja obiektów) powiązanej klasy, wskaźniki (referencje) do obiektów powiązanej klasy, identyfikatory obiektów powiązanej klasy, klucze kandydujące obiektów powiązanej klasy. W zależności od przyjętego sposobu oraz od liczności związków (1:1, 1:wiele, wiele:wiele) możliwe są bardzo różne deklaracje w przyjętym języku programowania. * * Symbol graficzny Słowo kluczowe Tablica obiektów: Lista wskaźników: Tablica wskaźników: TypSłowoKluczowe SłowaKluczowe[100]; list<TypSłowoKluczowe*> SłowaKluczowe; char *WskaźnikiSłówKluczowych[100];

9 Raczej projektowanie niż analiza (1)
Asocjacje skierowane: oprócz oznaczenia asocjacji zaznacza się też kierunek przesyłania komunikatów (nawigację). Np. w systemie Systemie Informacji Graficznej nawigacja jest możliwa jedynie od obiektów klasy “Symbol graficzny” do obiektów “Słowo kluczowe”. Jest to jeden ze scenariuszy; w innym może być inaczej. * * Symbol graficzny Słowo kluczowe Oznaczenia dostępności dla atrybutów, metod i klas: (+) publiczny – dla wszystkich (#) zabezpieczony (protected) – dostęp dla obiektów danej klasy oraz jej specjalizacji (-) prywatny – dostęp tylko dla obiektów danej klasy Symbol graficzny # Nazwa # Rysuj + Wyświetl + Wyświetl_opis Słowo kluczowe + Nazwa - Stan + Pobierz_stan + Zmień_stan * *

10 Raczej projektowanie niż analiza (2)
Szczegółowe specyfikacje atrybutów i metod Wzorce klas (szablony) Metaklasy, tj. klasy zawierające atrybuty i metody dotyczące klasy jako całości, a nie pojedynczych obiektów, np. realizujące atrybuty i metody klasowe innej klasy (własności statyczne). Wolne funkcje – funkcje nie będące metodami żadnej z klas. Stereotypy (np.: «persistent», «constructor», «query») ? wartości etykietowane ?

11 Składowe nie związane z dziedziną problemową
Model logiczny skonstruowany drogą uszczegółowienia modelu pojęciowego (wyniku fazy analizy) opisuje składowe systemu odpowiedzialne za realizację podstawowych zadań systemu, związanych z daną dziedziną problemową. Gotowe oprogramowanie musi także zawierać składowe nie związane z dziedziną problemową: Składowa zarządzania pamięcią Składowa interfejsu użytkownika składową interfejsu użytkownika, składową zarządzania danymi (przechowywanie trwałych danych), składową zarządzania pamięcią operacyjną, składową zarządzania zadaniami (podział czasu procesora). (kompilator, system operac.) (do 90% nakładów; obecnie poprzez GUI) Składowa dziedziny problemowej (kompilator, system operac.) (SZBD) Składowa zarządzania zadaniami Składowa zarządzania danymi

12 Perspektywy (1) Można wyróżnić trzy perspektywy, które powinny być brane pod uwagę w trakcie w konstruowania dowolnego modelu (diagramu): Perspektywa pojęciowa (koncepcyjna) – model pojęciowy powinien w zasadzie przedstawiać jedynie te pojęcia, które funkcjonują w dziedzinie problemu (w analizowanej rzeczywistości), np. mówimy o operacjach wykonywanych na bytach, a nie o implementujących je metodach, atrybuty to cechy opisujące byty, z kolei asocjacje opisują związki semantyczne występujące pomiędzy bytami. Model pojęciowy w ogóle (lub w bardzo niewielkim stopniu) powinien interesować się implementującym go softwarem. Perspektywa projektowa (logiczna) – tu uwzględniamy już software, ale interfejs a nie implementację, czyli myślimy raczej o typach niż o klasach. Typ reprezentuje interfejs, który może mieć wiele implementacji, np. uzależnionych od środowiska programowania (przyjętej platformy), żądanych charakterystyk wydajnościowych czy nawet sprzedawcy. Chociaż podejście obiektowe kładzie wielki nacisk na rozróżnienie między interfejsem a implementacją, w praktyce w wielu językach obiektowych nie oddziela się wyraźnie interfejsu od implementacji, co się zresztą zmienia na lepsze (przykład: Java, Corba). Perspektywa implementacyjna

13 Perspektywy (2) Zrozumienie perspektywy, która była brana pod uwagę w trakcie konstruowania danego modelu, jest ważnym czynnikiem mającym wpływ na prawidłowe interpretowanie modelu. Prawidłowa interpretacja, dobre zrozumienie jest warunkiem koniecznym prawidłowego wykorzystania później. Niestety nie dość, że granice między perspektywami nie są wyraźnie zakreślone, to jeszcze wielu analityków i projektantów w ogóle lekceważy ten problem i konstruuje swoje modele od razu z perspektywy implementacyjnej, podczas gdy te inne mogłyby w danym momencie być znacznie bardziej użyteczne. Nadmiar informacji może też stanowić stanowić pewne ograniczenie. Zalecenia: jeśli konstruujesz model, konstruuj go z jednej, wyraźnie określonej perspektywy, perspektywę tę możesz opisać wykorzystując stereotypy lub wartości etykietowane, kiedy przeglądasz model musisz być świadom z jakiej perspektywy został skonstruowany, aby go poprawnie zinterpretować. Modele, tak jak i całość projektu, zawsze powstają (a przynajmniej powinny powstawać) w sposób iteracyjny i przyrostowy.

14 Tworzenie modelu obiektowego (dwie drogi)
1 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ży model przypadków użycia oraz analiza dynamiczna.

15 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 konstruowania 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. Oparcie oprogramowania o wykorzystanie klas ma fundamentalne znaczenie dla technologii ponownego użycia.

16 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 ma być przechowywana informacja (lądowanie samolotu, wysłanie zamówienia, dostawa) interakcje pomiędzy osobami i/lub systemami, o których mają być przechowywane 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)

17 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 pewnym zbiorem konkretnych bytów? czy mamy do czynienia z opisem bytu (dokument, metadane)? Np. klasa Samochód. Może chodzić o: egzemplarz samochodu wyprodukowany przez pewną fabrykę historię stanów pewnego konkretnego samochodu model samochodu produkowany przez fabrykę pozycję w katalogu samochodów opisujący własności modelu Podobnie z klasą Gazeta. Może chodzić o: konkretny egzemplarz gazety kupiony przez czytelnika konkretne wydanie gazety (niezależne od ilości egzemplarzy) partię egzemplarzy danej gazety dostarczaną codziennie do kiosku tytuł i wydawnictwo, niezależne od egzemplarzy i wydań

18 Identyfikacja klas: RDD a DDD
Eksperci od obiektowego podejścia do procesu tworzenia oprogramowania dzielą się na dwa obozy w zależności od proponowanego przez nich sposobu identyfikacji klas: w oparciu o odpowiedzialności klas (RDD – Responsibility Driven Design), w oparciu o dane (DDD – Data Driven Design). Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy. 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. 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ń. Najbardziej efektywne, jak to z reguły w praktyce bywa, są techniki mieszane, wykorzystujące każdą dostępną metodę.

19 Metoda CRC (1) Metoda CRC (Class, Responsibilities, Collaborations) została zaprezentowana przez K. Beck’a i W. Cunningham’a w 1989 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.

20 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.

21 CRC- identyfikacja klas; przykład
Biblioteka: Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej książki. Tylko personel może wypożyczać czasopisma. Członek biblioteki 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 ma rejestrować wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł (ograniczeń). Osoba Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi osoby książka czasopismo wypełnianie ograniczeń narzuconych na liczbę wypożyczanych pozycji Książka Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi książki egzemplarz sprawdzanie, czy są wolne egzemplarze do wypożyczenia

22 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 np. 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.

23 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 języka 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.

24 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. Członek biblioteki 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 ma rejestrować wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł (ograniczeń). Zostawiamy: książka, czasopismo, egzemplarz książki, członek biblioteki, 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 rozważany w liczbie pojedynczej.

25 Identyfikacja generalizacji-specjalizacji
Identyfikacja związków generalizacji-specjalizacji Osoba ? Pozycja . Personel Członek bibl. Książka Czasopismo Książka Egzemplarz książki Egzemplarz książki nie jest rodzajem pozycji wydawniczej, jaką oznacza tu każde wystąpienie klasy Książka.

26 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). Klasę A z klasą B powinna połączyć asocjacja (o pewnej semantyce) 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. Podsumowywując: jeśli obiekt klasy A musi mieć możliwość dostępu do danych pewnego obiektu klasy B, to klasy A i B powinna połączyć asocjacja (w większości przypadków).

27 Identyfikacja asocjacji (2)
Uwaga – nie archiwizujemy tu wypożyczeń; fakt zwrotu książki jest rejestrowany poprzez usunięcie powiązania wypożyczyła między obiektami klas Osoba i Egzemplarz książki (przypadek 1-szy) lub tego obiektu klasy Wypożyczenie, który opisuje zwrócony egzemplarz – wraz z odpowiednimi powiązaniami (przypadek 2-gi). 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.

28 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, co implikuje 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.} Jak wyglądałby diagram, gdyby nie archiwizowano wypożyczeń? Oba rozwiązania są poprawne, aczkolwiek oba diagramy nie przenoszą dokładnie takiej samej informacji.

29 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. wypożyczył Personel Czasopismo 0..1 * Asocjacja jest egzemplarzem między klasami Książka i Egzemplarz książki Książka Kompozycja silniej podkreśla tu związek istniejący między książką (byt wirtualny, metadane), a konkretnym egzemplarzem. Książka 1 1..* 1..* Egzemplarz książki Egzemplarz książki

30 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

31 Model obiektowy – uwagi (1)
Konstruując system zawsze należy mieć na uwadze dwa główne cele, które powinny zostać osiągnięte: zbudowanie systemu (który spełni aktualne potrzeby klienta) tak szybko i tanio, jak tylko jest to możliwe, zbudowanie systemu, który będzie łatwy do utrzymania (konserwacji) i łatwo adaptowalny do przyszłych wymagań. 1 Pierwszy cel można osiągnąć poprzez wyróżnienie obiektów, przypisanie im własności (atrybutów i zachowań), zgrupowanie ich w klasy, czyli skonstruowanie modelu obiektowego, a następnie zapewnienie sensownej realizacji wymagań klienta (wyspecyfikowanych w modelu przypadków użycia) – poprzez ustalenie dróg przesyłania komunikatów między obiektami w systemie – tu będą pomocne diagramy dynamiczne. 2 Cel drugi można osiągnąć budując system modularny, złożony z komponentów oprogramowania (klas, modułów, …) o wysokiej kohezji (ang. high cohesion) i słabych skojarzeniach wzajemnych (ang. low coupling).

32 Model obiektowy - uwagi (2)
Ważne: Identyfikując klasy (np. poprzez wyszukiwanie rzeczowników w tekście wymagań) i asocjacje (poprzez wyszukiwanie czasowników), nigdy nie należy tracić z oczu perspektywy pojęciowej – skonstruowany model obiektowy nie może zniekształcać relacji istniejących w analizowanej rzeczywistości, tzn. w tym fragmencie dziedziny problemowej, którym zajmuje się tworzony system. Osoby, znające dziedzinę problemową, nie mogą być narażone na nieprzyjemne niespodzianki !