Projektowanie systemw informacyjnych Wykad 6 Model obiektowy 3

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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 1

Zagadnienia Faza analizy Faza projektowania Perspektywy: pojęciowa, projektowa i implementacyjna Proces tworzenia modelu obiektowego Identyfikacja obiektów i klas DDD a RDD Identyfikacja klas poprzez identyfikację rzeczowników Metoda CRC Identyfikacja związków między klasami E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 2

Faza analizy Określenie wymagań Faza strategiczna Implementacja Projektowanie Analiza Testowanie Konserwacja Instalacja Dokumentacja Czynności wykonywane w fazie analizy to: § ustalenie kontekstu projektu, § ustalenie wymagań użytkowników, § rozpoznawanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości będącej przedmiotem projektu. 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 wszystkich tych aspektów dziedziny problemowej, które mogłyby być poddane procesowi informatyzacji. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 3

Faza projektowania Określenie wymagań Faza strategiczna Projektowanie Implementacja Analiza Testowanie Konserwacja Instalacja Dokumentacja a. Celem fazy projektowania jest opracowanie szczegółowego planu implementacji systemu. a. 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. a. Dąży się, by struktura projektu zachowywała strukturę modelu stworzonego w poprzedniej fazie (analizie) - podejście bezszwowe (seamless). Niewielkie zmiany w dziedzinie problemowej powinny implikować niewielkie zmiany w projekcie. a. Może to być realizowane, np. poprzez wykorzystanie podejścia obiektowego. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 4

Zadania fazy projektowania Zadania stojace przed wykonawcami w fazie projektowania: § Uszczegółowienie wyników analizy. Projekt musi być wystarczająco szczegółowy aby mógł być podstawą implementacji. Stopień szczegółowości zależy od poziomu zaawansowania programistów. § Projektowanie tych składowych systemu, które nie są związane z dziedziną problemową. § Optymalizacja systemu. § Dostosowanie do ograniczeń i możliwości środowiska implementacji. § Określenie fizycznej struktury systemu (projekt architektury systemu). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 5

Uszczegóławianie wyników analizy (1) a. 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 Adres Ulica Numer domu Numer mieszkania Miasto Kod Dane osobowe Imię Nazwisko Adres Realizacja w C/C++ typedef struct { char Ulica[30]; int Numer. Domu; int Numer. Mieszkania; char Miasto[30]; char Kod[5]; } Typ. Adres; typedef struct { char Imię[30]; char Nazwisko[30]; Typ. Adres; } Typ. Dane. Osobowe; E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 6

Uszczegóławianie wyników analizy (2) a. Uszczegóławianie metod: § Podanie pełnych sygnatur metod (wyspecyfikowanie typu argumentów oraz wartości zwracanej dla każdej metody). § Zastąpienie niektórych prostych metod publicznym dostępem do atrybutów, np. metod Pobierz. Nazwisko, Ustaw. Nazwisko, etc. § Zastąpienie niektórych atrybutów redundantnych (pochodnych) przez odpowiednie metody, np. Wiek = Bieżąca. Data - Data. Urodzenia; Kwota. Dochodu = Kwota. Przychodu - Kwota. Kosztów; E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 7

Uszczegóławianie wyników analizy (3) a. 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: n, m: n) możliwe są bardzo różne deklaracje w przyjętym języku programowania. Symbol graficzny Tablica obiektów: Lista wskaźników: Tablica wskaźników: * * Słowo kluczowe Typ. Słowo. Kluczowe Słowa. Kluczowe[100]; list<Typ. Słowo. Kluczowe*> Słowa. Kluczowe; char *Wskaźniki. Słów. Kluczowych[100]; E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 8

Raczej projektowanie niż analiza (1) a. 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 a Oznaczenia dostępności dla atrybutów i metod: (+) 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_opis * Słowo kluczowe + Nazwa + Stan + Pobierz_stan + Zmień_stan E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 9

Raczej projektowanie niż analiza (2) a. Szczegółowe specyfikacje atrybutów i metod a. Wzorce klas (szablony) a. Metaklasy, tj. klasy zawierające atrybuty i metody dotyczące klasy jako całości, a nie pojedynczych obiektów, np. atrybuty i metody statyczne (klasy). a. Wolne funkcje - funkcje nie będące metodami żadnej z klas. a. Stereotypy (np. : «persistent» , «constructor» , «query» ) awartości etykietowane ? E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 10

Składowe nie związane z dziedziną problemową Projekt skonstruowany drogą uszczegółowienia modelu obiektowego (wyniku fazy analizy) opisuje składowe systemu odpowiedzialne za realizację podstawowych zadań systemu. Gotowe oprogramowanie musi także zawierać składowe nie związane z dziedziną problemową: § 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). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 11 Składowa zarządzania pamięcią (kompilator, system operac. ) Składowa zarządzania zadaniami Składowa interfejsu użytkownika Składowa dziedziny problemowej (do 90% nakładów; obecnie poprzez GUI) (SZBD) Składowa zarządzania danymi

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 przedstawia wyłącznie pojęcia funkcjonujące w dziedzinie problemu (w analizowanej rzeczywistości ): np. mówimy o operacjach wykonywanych na bytach, a nie o implementujących je metodach, a atrybuty to cechy opisujące byty. Asocjacje opisują związki semantyczne istniejące między bytami. Model pojęciowy w ogóle (lub w bardzo niewielkim stopniu) powinnien interesować się implementującym go softwarem. § Perspektywa projektowa - tu uwzględniamy już software, ale interfejs a nie implementację, czyli myślimy tu 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 12

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ć 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 13

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. 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 14

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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 15

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) E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 16

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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 17

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ę. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 18

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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 19

Metoda CRC (2) a 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. a 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). a 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. a 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 20

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: 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. 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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 21

Redukcja zbioru potencjalnych kandydatów Odrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza rzeczownikowa): ajest 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; ajest 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; aoznacza wydarzenie lub operację - tutaj pomocnicze może być zadanie pytania, czy obiekty przyszłej klasy miałyby atrybuty, zachowanie i tożsamość; astanowi 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; aoznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy - z reguły nie istnieje potrzeba do modelowania ich w postaci klasy; aoznacza atrybut - coś prostszego niż klasa, bez interesującego zachowania. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 22

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 musi 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 tu rozważany w liczbie pojedynczej. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 23

CRC- identyfikacja klas; przykład Członek bibl. Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi członka biblioteki kontrola wypełniania ograniczeń narzuconych na liczbę egzemplarzy Książka. Odpowiedzialności egzemplarz Współpracownicy zarządzanie danymi dotyczącymi książki sprawdzanie, czy są egzemplarze możliwe do wypożyczenia E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 24 egzemplarz

Identyfikacja generalizacji-specjalizacji Identyfikacja związków generalizacji-specjalizacji Osoba Pozycja Personel Członek bibl. Książka Egzemplarz książki nie jest rodzajem pozycji wydawniczej, jaką oznacza tu każde wystąpienie klasy Książka. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 25 Czasopismo

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. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 26

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. Osoba wypożyczyła 0. . 1 1 * Egzemplarz Książki * Wypożyczenie 0. . 1 1 Egzemplarz Książki Preferowane jest rozwiązanie pierwsze - klasa Wypożyczenie posiada żadnych własności, ani atrybutów ani operacji. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 27

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. Osoba wypożyczyła * Egzemplarz * Książki Wypożyczenie data wypożyczenia data zwrotu Osoba 1 {data zwrotu - data wypożyczenia <= 3 tygod. } Wypożyczenie * data wypożyczenia * data zwrotu {data zwrotu - data wypożyczenia <= 3 tygod. } Oba rozwiązania są tu poprawne. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 28 1 Egzemplarz Książki

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

Diagram klas dla przykładowych wymagań Osoba * Pozycja /liczba wyp. akt. pozycji Czasopismo Członek bibl. Personel { liczba wyp. akt. pozycji <= 6 } 0. . 1 wypożyczył * { liczba wyp. akt. pozycji <= 12 } Książka 1. . * * Egzemplarz książki Wypożyczenie data wypożyczenia data zwrotu { data zwrotu - data wypożyczenia <= 3 tygodnie } E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 30

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ń. 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. Cel drugi można osiągnąć budując system modularny, złożony z komponentów oprogramowania (klas, modułów, …) o wysokiej kohezji (high cohesion) i słabych skojarzeniach wzajemnych (low coupling). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 31

Model obiektowy - uwagi (2) Ważne: Identyfikując klasy, asocjacje np. poprzez wyszukiwanie rzeczowników, czasowników w tekście wymagań, 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 daną dziedzinę nie mogą być narażone na nieprzyjemne niespodzianki! E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 32