Projektowanie systemw informacyjnych Wykad 5 Diagram klas 2

Projektowanie systemów informacyjnych Wykład 5 Diagram klas (2) Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 1

Zagadnienia Czynności w fazie analizy Faza projektowania Perspektywy: pojęciowa, projektowa i implementacyjna Czynniki jakości modelu obiektowego Modularna budowa systemów Proces tworzenia modelu obiektowego Identyfikacja obiektów i klas DDD a RDD Metoda CRC Identyfikacja związków między klasami K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 2

Czynności w fazie analizy 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 rzeczywistości, które mogłyby być poddane procesowi informatyzacji. Efektem fazy analizy jest model wymagań, na który składają się: model przypadków użycia (opis funkcjonalności), model obiektów (opis statycznej struktury systemu) i model zachowań. Model, to abstrakcja opisująca spojrzenie na analizowaną rzeczywistość z pewnej perspektywy. Perspektywa ta uwzględnia niektóre elementy, a inne pomija. Środkiem do opisu modeli są diagramy wykorzystujące przyjętą notację. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 3

Projektowanie Określenie wymagań Faza strategiczna Projektowanie Implementacja Analiza Testowanie Konserwacja Instalacja Dokumentacja Celem fazy projektowania jest opracowanie szczegółowego opisu 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. Jest to realizowane, poprzez wykorzystanie podejścia obiektowego. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 4

Zadania wykonywane 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 składowych systemów nie związanych z dziedziną problemu. Optymalizacja systemu. Dostosowanie do ograniczeń i możliwości środowiska implementacji. Określenie fizycznej struktury systemu (projekt architektury systemu). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 5

Projektowanie składowych systemu nie związanych z dziedziną problemową Projekt skonstruowany przez uszczegółowienie modelu obiektowego (wyniku fazy nalizy) opisuje składowe programu odpowiedzialne za realizację podstawowych zadań systemu. Gotowe oprogramowanie musi się jednak składać z dodatkowych składowych: • składowej interfejsu użytkownika, • składowej zarządzania danymi (przechowywanie trwałych danych), • składowej zarządzania pamięcią operacyjną, • składowej zarządzania zadaniami (podział czasu procesora). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 6 Składowa zarządzania pamięcią (kompilator system operac. ) Składowa zarządzania zadaniami Składowa interfejsu użytkownika Składowa dziedziny problemu (do 90% nakładów; obecnie poprzez GUI) (SZBD) Składowa zarządzania danymi

Elementy występujące raczej w projektowaniu niż w analizie (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 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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 7

Elementy występujące raczej w projektowaniu niż w analizie (2) Szczegółowe specyfikacje atrybutów i metod - określenie typów 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. Wolne funkcje - funkcje nie będące metodami żadnej z klas. Oznaczenia widoczności obiektu, do którego wysyłany jest komunikat. Obiekt ten może być widoczny, gdyż znajduje się w tym samym zakresie, jest przekazany przez parametr lub jest polem klasy, której metoda wysyła komunikat. Stereotypy (<<używa>>, <<rozszerza>>, <<trwała>>, <<konstruktor>>, <<zapytania>>) i wartości etykietowane K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 8

Uszczegóławianie wyników analizy (1) Dodawanie elementów takich, jak wymieniono na poprzednich foliach. Uszczegóławianie poprzez podanie reguł odwzorowania notacji dla danych w struktury języka programowania, który będzie wykorzystany do implementacji systemu. Dane z analizy: Realizacja w C/C++: Adres Ulica Numer domu Numer mieszkania Miasto Kod typedef struct { char Ulica[30]; char Numer. Domu[10]; char Numer. Mieszkania[10]; char Miasto[30]; char Kod[5]; } Typ. Adres; Dane osobowe Imię Nazwisko Adres typedef struct { char Imię[30]; char Nazwisko[30]; Typ. Adres; } Typ. Dane. Osobowe; K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 9

Uszczegóławianie wyników analizy (2) Uszczegóławianie metod • Podanie pełnych sygnatur metod (wyspecyfikowanie typu argumentów oraz wartości zwracanej). • Zastąpienie niektórych prostych metod bezpośrednim 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; K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 10

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

Perspektywy: pojęciowa, projektowa, implementacyjna (1) Można podać (za Stevem Cook’iem i Johnem Daniels’em) 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 a nalizowanej rzeczywistości (dziedzinie problemu), np. mówimy o operacjach wykonywanych na bytach, a nie o implementujących je metodach. Atrybuty to wyłącznie pewne cechy opisujące byt. Asocjacje opisują związki istniejące między bytami. Model pojęciowy w ogóle (lub w bardzo niewielkim stopniu) powinnien iteresować się implemetującym go softwarem. • Perspektywa projektowa - tu uwzględniamy już software, ale interface a nie imlementację, czyli myślimy tu raczej o typach niż o klasach. Typ reprezentuje interface, 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 interfacem a implementacją, w praktyce w wielu językach obiektowych nie oddziela się wyraźnie interface’u od implementacji, co się zresztą zmienia na lepsze (przykład: Java, Corba). • Perspektywa implementacyjna K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 12

Perspektywy: pojęciowa, projektowa, implementacyjna (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. 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 stanowić przeszkodę. Zalecenia powszechnie powtarzane w literaturze związanej z inżynierią oprogramowania: • 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ą w sposób iteracyjny i przyrostowy. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 13

Czynniki jakości modelu obiektowego (1) Konstruując system zawsze należy mieć na uwadze dwa główne cele, które powinny być 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 oraz zapewnienie sensownej realizacji wymagań klienta (przypadków użycia) - poprzez ustalenie dróg przesyłania komunikatów między obiektami w systemie. Cel drugi można osiągnąć budując system modularny, skomponowany z modułów o dużej kohezji (high cohesion) i słabych skojarzeniach wzajemnych (low coupling). Kohezja oznacza zwartość, spoistość. Terminu tego używa się np. w odniesieniu do komponentu oprogramowania (klasy, modułu, itp. ) na oznaczenie wzajemnego zintegrowania jego elementów składowych. Duża kohezja oznacza silną interakcję wewnątrz i relatywnie słabszą interakcję z zewnętrzem. Komponenty powinna cechować duża kohezja. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 14

Czynniki jakości modelu obiektowego (2) Duża kohezja oznacza, że komponent stanowi dobrą, intuicyjną abstrakcję “czegoś”, czyli posiada precyzyjnie określoną semantykę, jest dobrze wyizolowany z kontekstu (maksymalnie od niego niezależny) oraz posiada dobrze zdefiniowany interface. Skojarzenie określa stopień powiązania między komponentami, czyli np. dla klasy - jak często obiekty jednej klasy występują razem z obiektami innych klas, jak często obiekty jednej klasy wysyłają komunikaty do obiektów innej klasy, itp. Możliwe są skojarzenia mocne, słabe czy w ogóle brak skojarzenia. Inne określenie na skojarzenie to zależność (dependency). System z dużą ilością zależności jest mocno skojarzony (high coupling), co nie jest niestety zaletą. Analiza stopnia kohezji i wzajemnych skojarzeń stanowi podstawę do konstruowania architektury systemu, czyli wyróżniania elementów składowych systemu, określania ich wzajemnych interakcji oraz sposobów przesyłania między nimi danych. Dobry system oparty jest (tak dalece, jak tylko to jest 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 15

Jakie korzyści przynosi modularna budowa systemów Modularna budowa jest podstawowym środkiem do redukcji złożoności oprogramowania. “Nawet ubogi interface do źle skonstruowanego komponentu może uczynić system ( jako całość) łatwiejszym do zrozumienia, a przez to do modyfikacji. ” Jak należy to stwierdzenie rozumieć? Redukcja wysiłku poświęconego na rozpoznanie komponentu przez kogoś, kto go używa musi skutkować pozytywnie z wielu powodów: • Jeśli wystarczy jedynie rozpoznać interface, a nie szczegółową implementację, musi to zaowocować większą wydajnością pracy, • Jeśli można bezpiecznie zignorować niektóre aspekty systemu (objęte przez wykorzystywany komponent) większą uwagę można przyłożyć do swojej pracy - mniej błędów wprowadza się do systemu, • Dzięki modularnej budowie łatwiej znajduje się błędy (zarówno w trakcie budowania, jak i konserwacji systemu); nie wszystkie moduły muszą być testownae przy usuwaniu błędu, • Dobrze przetestowny, udokumentowany komponent może być wielokrotnie wykorzystywany (ponowne użycie), • Modularna budowa ułatwia podział pracy. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 16

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

Identyfikacja obiektów i klas (1) Właściwa identyfikacja klas, czyli 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. Proces ten ma ogromne znaczenie dla technologii ponownego użycia, gdyż jak wykazuje doświadczenie - to właśnie klasy są najbardziej stabilnym elementem dziedziny problemowej. Oprogramowanie wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne. Jedna z podstawowych technik identyfikacji klas: poprzez identyfikację rzeczowników i fraz rzeczownikowych w tekście specyfikującym wymagania na system. Proces ten przebiega w dwóch etapach: Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich rzeczowników i fraz rzeczownikowych w tekście wymagań. Nazwy przyszłych klas powinny być rozważane jako rzeczowniki w liczbie pojedynczej. Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka potrzeba. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 18

Identyfikacja obiektów i klas (2) Odrzucamy potencjalnego kandydata, gdy rzeczownik (fraza rzeczownikowa): • jest redundantny - różne rzeczowniki dla określenia tego samego bytu; trzeba tu jednak pamiętać, że byty mogą być podobne, ale niekoniecznie dokładnie takie same - wskazanie być może na związek generalizacji-specjalizacji istniejący między nimi; • jest nieuchwytny - trudno jest określić, co właściwie oznacza; • 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 meta-ję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. 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 ułatwia zachowywanie informacji. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 19

Identyfikacja obiektów i klas (3) Przykład wymagań: Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej książki. Książki mogą być wypożyczane przez członków biblioteki na okres trzech tygodni. 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 meta-języka), okres 3 tygodni, osoba pracująca w bibliotece oznacza to samo co personel), reguła, ograniczenie pozycja (? ), wypożyczenie (? ), zwrot (? ), Każdy rzeczownik, kandydat na przyszłą klasę, jest rozważany w liczbie pojedynczej. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 20

Identyfikacja obiektów i klas (4) wypożyczyła Egzemplarz Osoba Książki 0. . 1 * Wypożyczenie data wypożyczenia data zwrotu Osoba Uwaga - nie archiwizujemy tu wypożyczeń {data zwrotu - data wypożyczenia <= 3 tygod. } Wypożyczenie * data wypożyczenia 0. . 1 data zwrotu {data zwrotu - data wypożyczenia <= 3 tygod. } K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 21 Egzemplarz Książki Różnica między oba rozwiązaniami byłaby lepiej widoczna, gdyby nie rejestrowano dat.

Identyfikacja obiektów i klas (5) 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) K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 22

Identyfikacja obiektów i klas (6) 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ę • model samochodu produkowany przez fabrykę • pozycję w katalogu samochodów opisujący własności modelu • historię stanów pewnego konkretnego samochodu 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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 23

Identyfikacja obiektów i klas (7) Ważnym jest, by zdawać sobie sprawę z tego, co każdy termin dokładnie oznacza. Większość metodyk postuluje, by już na etapie identyfikacji klas rozpocząć organizowanie słownika pojęć. Eksperci od podejścia obiektowego w procesie konstrukcji oprogramowania dzielą się na dwa obozy w zależności od proponowanego przez nich sposobu identyfikacji klas: • bazując na danych (DDD - Data Driven Design), • bazując na tzw. odpowiedzialnościach klas (RDD - Responsibility Driven Design). DDD - polega na zidentyfikowaniu wszystkich danych w systemie i podziale ich na klasy bez uwzględniania 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 są techniki mieszane, wykorzystujące każdą dostępną metodę. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 24

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: • nazwę klasy, u góry kartki • odpowiedzialności (zobowiązania) danej klasy (responsibilities), po lewej stronie kartki, • współpracowników, czyli klasy, które pomagają danej klasie w wypełnianiu jej zobowiązań (collaborators), po prawej stronie kartki. 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ą bardziej ogólne. Np. akceptowalne jest zobowiązanie, takie jak “zarządzanie danymi dotyczącymi ksiązki”, 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 (mała 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 mocne skojarzenie klas. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 25

Metoda CRC (2) - przykład Członek bibl. Odpowiedzialności zarządzanie danymi dotyczącymi wypożyczanych egzemplarzy Współpracownicy egzemplarz kontrola wypełniania ograniczeń narzuconych na wypożyczenie i zwrot egzemplarzy Książka. Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi książki sprawdzanie, czy są egzemplarze możliwe do wypożyczenia K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 26 egzemplarz

Metoda CRC (3) • 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. 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 albo błąd w modelu albo brak czegoś. Być może trzeba wtedy dodać nową klasę albo zmienić odpowiedzialności lub współpracowników klasy już istniejącej (albo 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 27

Identyfikacja związków między klasami (1) Identyfikacja związków generalizacji-specjalizacji Osoba Personel bibl. Pozycja Członek bibl. Książka 1. . * Egzemplarz książki K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 28 Egzemplarz książki Czasopismo

Identyfikacja związków między klasami (2) 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: “jest egzemplarzem”, “wypożycza”, “zwraca”. Nie wszystkie wystąpiły “jawnie” - w postaci czasowników (czy fraz). 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 - obiekt klasy A musi mieć możliwość dostępu do danych pewnego obiektu klasy B. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 29

Konstrukcja modelu - uwagi ogólne Identyfikując klasy, asocjacje 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! Po skonstruowaniu wstępnego modelu obiektowego, opartego o byty i relacje istniejące w analizowanej rzeczywistości, należy rozważyć sensowną realizację funkcjonalności systemu (przesyłanie komunikatów) w czym będą pomocne także diagramy zachowania się. Na tym etapie bardziej przydatne są perspektywy: projektowa i implementacyjna. Takie iteracyjne, przyrostowe podejście do rozwoju systemu daje pewną gwarancję, że system będzie łatwy do zrozumienia i przez to łatwiejszy do utrzymania, a w tym do modyfikacji. Model a diagram? Model reprezentuje spojrzenie na system z jakiejś perspektywy, na pewnym poziomie abstrakcji. Diagram (y) przedstawia ten model graficznie. Niestety, w praktyce oba terminy, mimo że różne (np. klasa, która pojawia się jeden raz w danym modelu, może pojawiać się na wielu diagramach opisujących ten model), są używane zamiennie. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 30

Diagram klas dla przykładowych wymagań (biblioteka) Osoba 0. . 1 Pozycja /liczba wyp. pozycji Personel bibl. Członek bibl. 0. . 1 { liczba wyp. pozycji <= 12 } Czasopismo Książka * { liczba wyp. pozycji <= 6 } 1. . * * Egzemplarz książki Wypożyczenie data wypożyczenia data zwrotu { data zwrotu - data wypożyczenia <= 3 tygodnie } K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 5, Folia 31