Wprowadzenie
Permanentne dyskusje z wieloma programistami utrwalają we mnie pewien stereotyp: inżynier to dobry wykonawca ale żaden analityk. Czy to coś złego? Absolutnie nie, dobry inżynier jest na wagę złota ale dobry inżynier powinien mieć jedną kluczową cechę: nie dyskutuje z projektantem (jeżeli tylko projektant potrafi uzasadnić czego chce). Ale po kolei.
Popatrzmy do Wikipedii bo w znacznej mierze jest tworzona przez programistów i entuzjastów informatyki, choć chyba należy raczej powiedzieć: programowania (dodam, że w prawie każdej firmie obserwuję dwa syndromy: każdy kto nie jest informatykiem zna się na marketingu, pozostali znają się i na programowaniu i na marketingu).
Programowanie obiektowe (ang. object-oriented programming) ? paradygmat programowania, w którym programy definiuje się za pomocą obiektów ? elementów łączących stan (czyli dane, nazywane najczęściej polami) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów.
Największym atutem programowania, projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością – mózg ludzki jest w naturalny sposób najlepiej przystosowany do takiego podejścia przy przetwarzaniu informacji. Już Platon postulował dwoistość: “byt” – “idea (wzorzec) bytu”, np. książka jako idea ogólna – w terminologii platońskiej: doskonała (choć niedookreślona), i książka konkretna np. zbiór baśni leżący na piątej półce. Podobnie, choć później Arystoteles analizując rzeczywistość wprowadził pojęcia formy i materii. (źr. WIKI)
Mamy tu więc dwa wątki: techniczny czyli implementacja paradygmatu obiektowego w językach programowania oraz humanistyczny czyli opis (model) rzeczywistości: byty i ich postrzeganie przez człowieka (w zasadzie filozofia, a konkretnie fenomenologia: wśród ważnych pojęć fenomenologii znajduje się analiza eidetyczna, czyli dążenie do uchwycenia istoty tego, co dane, ideacja, docieranie do istoty zjawisk, widzenie istotnościowe. W naoczności istotnościowej dana jest czysta istota zjawiska. Uchwycenie tej istoty nie musi być przeprowadzone na wielu przykładach, wystarczy nawet jeden lub tylko naoczność wyobrażeniowa (przykład wyobrażony)).
Analiza i modelowanie
Modelowanie rzeczywistych bytów nie ma nic wspólnego z programowaniem czy informatyką (przypominam także, że teoria informacji i informatyka to nie tożsame dziedziny wiedzy) . Raczej potrzebna jest do tego teoria poznania czyli epistemologia, ontologia czy semantyka a także teoria komunikacji społecznej.
Model dziedziny więc, to nic innego jak zespół pojęć, związków między tymi pojęciami, tego jak człowiek postrzega te byty rzeczywiste na bazie nazw, których używa do ich oznaczania. Powszechnie podnoszony “brak wiedzy klienta o tym co chce”, to tak na prawdę brak kompetencji programistów do odczytania tego co swoimi pojęciami przekazuje im klient.
Nie piszę o tym dlatego, co mi się czasami zarzuca, by zamulić analizę teorią i udowadniać coś programistom. Piszę o tym dlatego, że analiza jako drążenie tego co chcą ludzie powiedzieć i co mówią, taka właśnie jest: nieinformatyczna.
Naturalnym więc biegiem wydarzeń w tworzeniu oprogramowania powinno być więc modelowanie “świata opisywanego” a potem “odtworzenie” go w kodzie oprogramowania. Wcześniej należy określić co i po co ma znaleźć odzwierciedlenie w programie. Być może ktoś dostrzeże tu elementy DDD (Domain Driven Design, ang. projektowanie sterowane modelem dziedziny) i słusznie bo tak właśnie jest.
Komponent oprogramowania odpowiedzialny za realizację wymagań funkcjonalnych, omówiony dalej Model, to nic innego jak programowa “symulacja” kawałka rzeczywistego świata. Nie można jej absolutnie upraszczać, w przeciwnym wypadku “psujemy program” oddalając go od rzeczywistości. Paradoksalnie przykładem takiego psucia jest normalizacja relacyjnej bazy danych (redundancje są typowym elementem rzeczywistości, usuwanie ich to niszczenie związku pomiędzy programem a światem jaki program modeluje).
Jak zwrócono uwagę w przytoczonej definicji: “Największym atutem programowania, projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością“. Tak więc należy “posiąść” tę zgodność i rzeczywistość i nie psuć jej.
Kto powinien modelować “nasz świat”? Dla programisty, jak sami to nie raz podkreślają, obiekt to struktura łącząca w kodzie dane przetwarzane z metodami ich przetwarzania. Ale wokół nas są obiekty rzeczywiste: świat i jego zawiłości. To sugeruje raczej, że analiza obiektowa i tworzenie modelu “rzeczywistości” nie ma nic wspólnego z programowaniem. To raczej jest tak, że programista powinien “odtworzyć” w kodzie otrzymany od analityka i projektanta, model. Po to powstały obiektowe narzędzia by właśnie ułatwić programistom implementacje obiektowych modeli a analitykom ich tworzenie, dać im wspólny (powszechny, ang. Ubiquitous Language) język.
A tu proszę: inżynier ze swoim “obiektowym językiem programowania, strukturami kodu i danych” zabiera się do tego, do czego nie ma żadnego przygotowania: modelowanie firmy (świata) i tego jak jest zarządzana. Rozumiem oburzenie: to my jesteśmy programistami i my wiemy jak programować. Owszem, JAK ale nie CO. Nie wystarczy że popytacie usera jak pracuje, trzeba zrozumieć: co i po co robi a potem stworzyć tego model. Dobry model musi “odzwierciedlać rzeczywistość”.
Z obiektowości programiści rozumieją tylko tyle, że to “coś co łączy dane i funkcje”. Ja niczego więcej nie oczekuję od programistów. Ilu programistów czytało ze zrozumieniem Druckera, Portera, Kottlera?
Wielu z nich jest (będzie jak to przeczyta ;)) jak obrażone dzieci bawiące się szachami: rozpoznają konika, wieże czy króla, trafiają figurami w pola szachownicy i nie dadzą sobie powiedzieć, że Goniec to tylko po skosie. Szachy to nie “jakieś drewniane piony i 64 pola do ich ustawiania”. Można zagrać tymi pionami na tej planszy w warcaby a nawet w zbijaka, ale to nadal są szachy i ta gra ma nieco inne zasady mimo, że to faktycznie tylko plansza i drewniane piony i faktycznie da się z powodzeniem zagrać “tym sprzętem” w warcaby, a nawet w chińczyka (w końcu to tylko drewniane figurki).
Tak więc obiektowe programowanie to narzędzie, można nim wiele zrobić na wiele sposobów, ale jeżeli powiemy sobie, że projektujemy jakąś rzeczywistość biznesową metodami obiektowymi, to z całym szacunkiem: oczekuję od programisty, że uzna fakt, że figurki i plansza to jednak szachy. Od stolarza nie oczekuję, że będzie mistrzem szachowym, oczekuję, że pod dyktando szachisty (wymagania) wykona najlepszą planszę i piony i nie będzie się wdawał w dyskusje na temat tego, dlaczego koń na szachownicy wycina takie śmieszne hołubce i forsował tezy by uznać, że ma “chodzić prosto” i będzie prościej. Szachista tak chce i już, ma prawo bo to on zamawia, to on tu jest szachistą a stolarz stolarzem.
Proces powstawania oprogramowania
Tu powołam się (po raz kolejny) na wzorzec projektowy MVC. Obrazuje on podział oprogramowania na trzy kluczowe podsystemy:
Stosowanie tego wzorca ma pewien głęboki sens: podział odpowiedzialności zgodnie z regułą obiektową mówiącą, że obiekt (także komponent i jego interfejs) ma wszystkie i tylko te kompetencje, które są wymagane do wywiązania się z kontraktu (projektowanie zorientowane na kontrakt). Tym kontraktem jest “to za co odpowiada obiekt i tylko to”. Powyższy diagram (nie jest to diagram klas, to schemat blokowy obrazujący wzajemne oddziaływanie na siebie komponentów: bloczek oznacza komponent, strzałka pokazuje kierunek oddziaływania) obrazuje zobowiązania tych trzech komponentów.
Nie wgłębiając się w szczegóły tego wzorca (opisy dostępne w sieci) istotne jest odrębne istnienie komponentów. Model zawiera w sobie (modeluje w projekcie i implementuje w kodzie) “świat rzeczywisty wyrażony w obiektowym paradygmacie” (kontrakt brzmi: wiem wszytko o tym czym jest i jak działa świat w otoczeniu użytkownika), zarówno dane jak i logikę ich zachowań. View ma kontrakt inny: biorę na siebie całą interakcję programu z użytkownikiem. Controller zaś mówi: biorę na siebie zapamiętywanie, całą komunikację, jej sprawność i niezawodność, w tym także pomiędzy View i Modelem.
Mamy prosty podział odpowiedzialności: Grafik odpowiada za projekt View, Analityk Biznesowy za Model (przypomnę: co i jak jest przetwarzane) a programista za technologię i ubranie tego wszystkiego w działający kod czyli za implementację. Jeżeli uznamy, że analityk opracuje Model metodami obiektowymi to mamy właśnie atut programowania, projektowania oraz analizy obiektowej czyli zgodność takiego podejścia z rzeczywistością.
No i teraz skoro tak, to samo się nasuwa:
- wykonaj analizę i opracuj obiektowy model rzeczywistości, upewnij się, że jest prawdziwy (zgodny z tą rzeczywistością),
- opracuj projekt tego co zobaczy użytkownik programu: ekrany,
- zapisz ograniczenia stosowania przyszłego programu,
- daj to programistom by stworzyli zgodny z tymi wymaganiami, działający program.
Czy inna kolejność jest możliwa? Czy widać, że bez projektów Modelu i ekranów nie ma się co brać za kodowanie? Co kodować? Jak na tym tle wyglądają metody polegające, na tym, że od razu po rozmowie z nierozumiejącym obiektowego paradygmatu użytkownikiem, przystępuje się do kodowania? Jak będzie przebiegało tworzenie kodu, jeśli wiemy na razie tylko to, że ma powstać faktura zaś o tym, że dotyczy zamówień z innego systemu i własnego magazynu dowiemy się jutro mając już “coś napisane”? Bo ja mam wrażenie, że to po protu stare funkcyjne podejście tyle, że z użyciem “klas obiektów, metod i atrybutów” bo nie raz, patrząc na prace niektórych programistów, nie przechodzi mi przez gardło “paradygmat obiektowy”.
Czym to grozi? Długim czasem kodowania, kolejnymi prototypami i dziesiątkami modyfikacji kodu, brakiem zrozumienia, uproszczeniami wymagań czyli jednym słowem: dużymi pieniędzmi za kiepski program (skąd to znamy??).
Dlatego proszę programistów: róbcie to co rozumiecie i nie wmawiajcie nikomu, że wiecie lepiej jak zarządzać firmą Waszych klientów. Róbcie to co każdy dobry stolarz: poproście klienta o rysunek tego co ma powstać i zróbcie. Nie zapominajcie, że dobry stolarz to nie to samo do dobry projektant, jak klient nie potrafi rysować (a najczęściej nie, bo nie to jest jego kompetencją), dobry stolarz zawsze odeśle do projektanta po rysunek. Między innymi dlatego, by później nie być posądzonym o stronniczość czyli rysowanie tylko tego co jest łatwe w wykonaniu. Rzecz w tym, że nie ma być łatwe dla stolarza a dobre dla klienta.
Pod tym wszystkim podpisuję się ja, Jarek Rysownik
P.S.
Ten artykuł powinien mieć chyba tytuł: Manifest analityka-projektanta ;).
