Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.

Podobne prezentacje


Prezentacja na temat: "E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta."— Zapis prezentacji:

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

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

3 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 3 Faza analizy 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. Czynności wykonywane w fazie analizy to: Określenie wymagań Projektowanie ImplementacjaTestowanieKonserwacja Faza strategiczna Analiza Instalacja Dokumentacja

4 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 4 Faza projektowania 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 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. Może to być realizowane, np. poprzez wykorzystanie podejścia obiektowego. Określenie wymagań Projektowanie ImplementacjaTestowanieKonserwacja Faza strategicznaAnaliza Instalacja Dokumentacja

5 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 5 Zadania fazy 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). Zadania stojace przed wykonawcami w fazie projektowania:

6 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 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 osobowe Imię Nazwisko Adres Ulica Numer domu Numer mieszkania Miasto Kod typedef struct { char Ulica[30]; int NumerDomu; int NumerMieszkania; char Miasto[30]; char Kod[5]; } TypAdres; typedef struct { char Imię[30]; char Nazwisko[30]; TypAdres Adres; } TypDaneOsobowe; Dane z analizy Realizacja w C/C++

7 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 7 Uszczegóławianie wyników analizy (2) 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 PobierzNazwisko, UstawNazwisko, etc. Zastąpienie niektórych atrybutów redundantnych (pochodnych) przez odpowiednie metody, np. Wiek = BieżącaData - DataUrodzenia; KwotaDochodu = KwotaPrzychodu - KwotaKosztów;

8 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 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:n, m:n) możliwe są bardzo różne deklaracje w przyjętym języku programowania. TypSłowoKluczowe SłowaKluczowe[100]; list SłowaKluczowe; char *WskaźnikiSłówKluczowych[100]; Tablica obiektów: Lista wskaźników: Tablica wskaźników: Symbol graficznySłowo kluczowe **

9 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 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 graficznySłowo kluczowe 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 + Wyświetl_opis Słowo kluczowe + Nazwa + Stan + Pobierz_stan + Zmień_stan ** **

10 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 10 Raczej projektowanie niż analiza (2) Wzorce klas (szablony) 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). Wolne funkcje - funkcje nie będące metodami żadnej z klas. Stereotypy (np.: « persistent », « constructor », « query » ) wartości etykietowane ? Szczegółowe specyfikacje atrybutów i metod

11 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 11 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). Składowa dziedziny problemowej Składowa dziedziny problemowej Składowa zarządzania danymi Składowa zarządzania danymi Składowa zarządzania zadaniami Składowa zarządzania zadaniami Składowa interfejsu użytkownika Składowa interfejsu użytkownika Składowa zarządzania pamięcią Składowa zarządzania pamięcią (do 90% nakładów; obecnie poprzez GUI) (kompilator, system operac.) (kompilator, system operac.) (SZBD)

12 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 12 Perspektywy (1) 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. Można wyróżnić trzy perspektywy, które powinny być brane pod uwagę w trakcie w konstruowania dowolnego modelu (diagramu): 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

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

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

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

17 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 17 Obiekty, zbiory obiektów, metadane W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego rodzaju bytem mamy do czynienia. 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ę 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 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? Podobnie z klasą gazeta. Może chodzić o: Np. klasa samochód. Może chodzić o: Należy zwrócić uwagę na następujące aspekty:

18 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 18 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). 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ę. Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy.

19 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 19 Metoda CRC (1) Metoda CRC (Class, Responsibilities, Collaborations) została zaprezentowana przez K. Becka i W. Cunninghama 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 21 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.

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

23 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 23 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) Każdy rzeczownik, kandydat na przyszłą klasę, jest tu rozważany w liczbie pojedynczej. pozycja (?), wypożyczenie (?), zwrot (?),

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

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

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

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

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

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

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

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

32 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 32 Model obiektowy - uwagi (2) 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! Ważne:


Pobierz ppt "E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 6, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta."

Podobne prezentacje


Reklamy Google