Ten artykuł to odpowiedź na pewną dyskusję rozpoczętą od tezy, że na wielu stronach WWW (w niektórych książkach także) mamy niestety do czynienia z pseudowiedzą…

W artykule Cholerny diagram klas pisałem o modelu dziedziny. Modelowana jest diagramem klas (notacja to narzędzie), zawiera logikę biznesową. W konwencji DDD ([[Domain Driven Design]]), model ten jest szkieletem komponentu Model we wzorcu MVC.

Tym razem napisze kilka słów o pojedynczych klasach w modelu dziedziny. Błąd numer jeden: klasy w modelu dziedziny odwzorowują pojęcia modelu pojęciowego! Nie, model pojęciowy (słownik pojęć ich wzajemnych związków) to nie model dziedziny systemu. Tak się projektowało encje w modelach relacyjnych baz danych, przenoszenie tych doświadczeń na grunt obiektowy to powszechna, ciężka choroba, to rak toczący te projekty. Owszem, jeżeli ktoś zadeklaruje, że tworzy system metodami strukturalnymi już może przestać czytać, ale niech używa notacji i diagramy ERD a nie UML i nie nazywa tego metodami obiektowymi analizy i projektowania.

Niestety “przykłady diagramów klas” na stronach wielu firm doradczych, szkoleniowych i stronach wielu “konsultantów”, ‘trenerów” itp. pokazują, że duch analizy strukturalnej nadal żyje oraz, że mylenie notacji UML z metodami obiektowymi analizy i projektowania jest powszechne. Przypomnę tu tylko, że diagram klas to notacja, której można użyć do wielu rzeczy, w tym  do modelowania pojęć, struktury kodu oprogramowania obiektowego (zgodnego z obiektowym paradygmatem, a nie tylko korzystającego z polecenia class w użytym języku programowania), statycznych modeli organizacji i wielu innych. Tak więc zdanie “proszę zrobić diagram klas” nie znaczy nic, to coś jak “weź samochód o pojeździj troszkę”, z transportem nie ma to nic wspólnego.

Jeżeli jednak uznamy, że prowadzimy analizę obiektową to znaczy, że model rzeczywistości (modelowanej) budujemy jako “zespół współpracujących obiektów  realizujących określony cel”. Wtedy diagram klas to nie żadne dane, encje i inne nieobiektowe pomysły (znam takich co modelują klucze relacyjne w diagramach klas a to już jest tragedia niestety, jest nawet wydana w Polsce książka z takimi przykładami!). Projekt zaczynamy od klas i ich operacji a nie od atrybutów!

Uwaga dodatkowa. Sprawdzoną metodą analiz (w ogóle) jest analiza systemowa, jest to:

metoda rozwiązywania złożonych problemów wykorzystująca podejście systemowe (holistyczne). Polega na traktowaniu analizowanej organizacji (zjawiska) jako złożonego systemu, którego poszczególne części “pracują” na powodzenie całości”. Obejmuje ona cztery zasadnicze etapy rozwiązywania problemu: (1) identyfikacja i sformułowanie problemu, (2) badanie (analizowanie) sytuacji problemowej (gromadzenie informacji, wyjaśnianie kwestii, analizowanie faktów itp., (3) analiza problemu (dekompozycja złożonego problemu na mniejsze), (4) projektowanie rozwiązania (budowa modeli, specyfikacje, symulacja, warianty itp.).

Jak widać podobieństwo paradygmatu obiektowego i analizy systemowej jest bardzo duże, żeby nie powiedzieć uderzające.

Tak więc analiza i modelowanie (na etapie analizy) to rozłożenie analizowanej organizacji (analizowanego środowiska) na proste obiekty,  każdy o prostej “odpowiedzialności”. Wyłania się obraz modeli składających się z tych “części, które pracują na powodzenie całości”. Jakie powinny być owe części? Teraz pora na dwa cytaty z blogów pewnych programistów (lubię dobrych programistów, bo przytakują mi lub negują a nie raz mocno uczą pokory to co myślę czyli nie błądzę w chmurach):

Single Responsibility Principle mówi, że klasa powinna robić jedną rzecz, mieć jedną odpowiedzialność. Jeśli ma jedną odpowiedzialność to nie powinna raczej grzebać we wszystkich warstwach. Wątpliwe jest aby klasa, która ma jedną odpowiedzialność musiała sięgać do bazy danych i interfejsu użytkownika i plików i logiki biznesowej i Bóg raczy wiedzieć gdzie jeszcze. (za using – papierek lakmusowy Twojej architektury | arek online | Arkadiusz Benedykt).

 

…najbardziej trafną metaforą obiektów programistycznych jest organizm biologiczny. Podobnie jak komórki, obiekty “nie wiedzą”, co dzieje się wewnątrz innych obiektów, ale komunikują się z nimi realizując bardziej złożone cele. W przeciwieństwie do takiego organizmu program monolityczny przypomina mechanizm zegarka, zawierający nieprzeliczalną (sic!) liczbę trybików. Trybiki nie mają żadnej inteligencji i są bezużyteczne poza mechanizmem, w którym pracują. Taki projekt nie ma szans powodzenia. Budując mechanizmy zegarowe, dochodzisz w końcu do takiej złożoności, że całość przestaje funkcjonować. (Holistycznie o inżynierii oprogramowania: Bo najważniejsza jest odpowiedzialność Synu…).

i niestety to co widuję na wielu stronach WWW, w projektach itp. (druga wada często spotykanych modeli dziedzinowych):

Dopisujemy kolejne metody a tymczasem klasa puchnie. Przy osiągnięciu masy krytycznej, wprowadzenie jakiejkolwiek zmiany, nawet tej najmniejszej powoduje, że spędzamy godziny na debugowaniu kodu i sprawdzaniu dlaczego nie zawsze działa tak jak byśmy tego chcieli. (Single Responsibility Principle | arek online).

Swego czasu na jednej z konferencji o analizie wymagań, mówiłem  o potrzebie zrozumienia funkcjonowania analizowanej organizacji (firmy) o i tym jak to udokumentować:

…wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Pamiętajmy, że jedna z najtrudniejszych gier na świecie ? szachy ? to tylko kilkanaście figur i proste reguły ich przemieszczania, snooker – najtrudniejsza gra w bilarda – to to tylko proste kule i kij. Nawet największą organizację można, w toku analizy, rozłożyć na skończoną liczbę ról i reguł ich postępowania by zrozumieć jej funkcjonowanie. (żr. Jarosław Żeliński, referat na konferencji o systemach ERP).

Analiza biznesowa to etap opisu (zrozumienia) modelowanej organizacji (modele procesów itp.). Potem, powstaje model rozwiązania, którym jest nie raz właśnie oprogramowanie, jego logika (patrz powyższy cytat) to “obiektowy model dziedziny systemu”, a nie jakiś diagram klas nafaszerowany atrybutami i pozbawiony operacji bo jest dokładnie odwrotnie:

Anemic Domain Model: This is one of those anti-patterns that’s been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we’ve both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing. (AnemicDomainModel).

Dla kontrastu cytat z jednej ze stron WWW pewnej firmy szkoleniowej:

Zwróćmy uwagę, że na modelu dziedziny nie umieszczamy klas implementujących logikę aplikacji, jej interfejs użytkownika czy warstwę dostępu do danych. Nie warto też na modelu dziedziny umieszczać metod. (Diagramy klas – model dziedziny i projekt aplikacji).

I tyle mam dzisiaj do powiedzenia o niektórych konsultantach i wykładowcach … (a tu troszkę prawdy)

P.S.

Bardzo często spotykam się z tezą, że model dziedziny powinien opracowywać architekt by dokonać ewentualnych optymalizacji jeszcze przed implementacją. Stawianie takich tez ma w moich oczach dwa główne źródła:  dostawca usługi (developr) szuka okazji by projekt nagiąć do swoich potrzeb, do posiadanych gotowych komponentów nie spełniających jednak wymagań. Innym powodem jest zwykła niewiedza. O optymalizacji kilka prostych tez ustami programisty: 3 zasady optymalizacji. Więc powtórzę: na etapie analizy i projektowania niczego nie upraszczamy ani nie optymalizujemy bo nie wiemy czy w ogóle zaistnieje taka potrzeba, a optymalizacja ZAWSZE psuje model.