Tytułowy problem ma chyba każdy początkujący . Jak słusznie zauważył autor poniższego tekstu:

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) – najpierw rozpoznawane są wszystkie odpowiedzialności systemu (na podstawie potrzeb przyszłych użytkowników), a następnie, bazując na tych odpowiedzialnościach, wyróżniane są klasy, którym przypisuje się odpowiedzialności systemu. W ten sposób definiuje się odpowiedzialności klas, które odpowiadają zbiorowi zachowań ich obiektów. Przykładem tego podejścia jest wykorzystywana w niektórych metodykach metoda CRC.

W oparciu o dane (DDD – Data Driven Design) – podejście to polega na identyfikowaniu 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ń użytkownika. )

Niestety dalej jest gorzej bo autor tekstu poświęcił się praktycznie w całości metodzie opartej na danych. Napisał “Wyróżnianie klas poprzez identyfikację rzeczowników i fraz rzeczownikowych w tekście specyfikującym wymagania użytkownika jest jedną z podstawowych i powszechnie stosowanych technik.“. Zgodzę z bólem z tym, że jest to metoda najczęściej stosowana, jednak nie jest to podstawowa metoda. Bazowanie, w analizie obiektowej, na danych prowadzi prostą drogą do powstania konstrukcji w postaci antywzorca o nazwie [[anemiczny model dziedziny]]. Ta metoda ma rodowód z relacyjnego modelu danych, gdzie dane identyfikowane były właśnie jako rzeczowniki, z tego powodu, że dane to z natury rzeczowniki.

Nieco dalej autor pisze: “Identyfikacja asocjacji. Sposób postępowania przy identyfikacji asocjacji jest podobny do sposobu identyfikacji klas, z tą różnicą, że w tekście wymagań zamiast rzeczowników (ogólnie: fraz rzeczownikowych) wyszukiwane są czasowniki (ogólnie: frazy czasownikowe). Zgodnie z tą zasadą z powyższego przykładu z biblioteką można wydedukować asocjacje: wypożyczyła (od frazy “wypożyczać”) oraz jest egzemplarzem (od frazy “może być kilka egzemplarzy tej samej książki”).“.  W konsekwencji pojawia się idea (i potrzeba) stosowania klas pośredniczących czyli  konstrukcji rodem z z modelu relacyjnego, stosowanych w celu rozwiązywania związków “wiele do wielu” (niedopuszczalnych w modelu relacyjnym a dopuszczalnych w modelu obiektowym). Niestety to podejście to konsekwencja traktowania diagramu klas jako modelu danych, co jest kompletnym nieporozumieniem, jeśli uznać, że paradygmat obiektowy to “uznanie,  że system to zbiór obiektów współpracujących w określonym celu” .

Autor kończy rozdział tego “podręcznika” dla studentów (PJWSTK) przykładem o nazwie “Diagram klas dla biblioteki”.

Jednak diagram klas to notacja, a model (wykonany z użyciem tej notacji) może być albo modelem pojęciowym albo modelem struktury systemu o określonym poziomie abstrakcji. Przykłady tam podane to w zasadzie antywzorce (patrz także M.Fowler: Anemic Domain Model): model z dziedziczeniem niespecjalnie nadaje się  na model dziedziny z uwagi na to, że dziedziczenie łamie zasady “unikania ścisłych zależności” (użycie dziedziczenia bardzo silnie uzależnia wszystkie klasy pochodne od uogólniających na szczycie hierarchii). Zaś kompozycje nie są stosowane w modelach pojęciowych, bo modele pojęciowe to słowniki pojęć w formie graficznej. Pojęcia mogą być z sobą powiązane (asocjacje) ale nie ma tu liczności czy zawierania się w sobie (czy “książka składa się z egzemplarzy książek”???).

Osobiście radzę analitykom i projektantom skupić się na projektowaniu obiektów, które współpracują: mają odpowiedzialności i komunikują się wywołując swoje operacje. Dane to problem na sam koniec analizy a nie jest to coś, od czego należy ja zaczynać. Karty CRC są doskonałym narzędziem dla początkujących, analiza rzeczowników chyba najgorszym.

Na koniec polecam jednak książki, które na stronach bloga cytuję (jeżeli już ktoś uważa, że moje teksty są mało wiarygodne ;)).

Źródła

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).