Niestety firmy oferujące gotowe oprogramowanie, pokazują jedynie menu, na którym zobaczymy np. Cennik, ale bez wiedzy jak wygląda wnętrze, nie ma żadnej możliwości oceny przydatności konkretnego programu (nie licząc próbnej eksploatacji). To wyjdzie najczęściej (jego wewnętrzny model i ograniczenia jakie powoduje) dopiero podczas wdrożenia, a to już za późno. Pojawia się tak zwana kastomizacja jako zalecenie w efektach analizy przedwdrożeniowej (wykonanej dopiero po zawarciu umowy przez dostawce programu czyli już za późno!). Ale teraz to już po prostu tak zwana rzeźnia. Przejście, w gotowym oprogramowaniu, pomiędzy opisanymi niżej modelami wymaga jego gruntownej przeróbki, lub negocjacji: z których wymagań kupujący zrezygnuje.

Przeciętny system ERP to naście setek funkcjonalności, nie da się racjonalnie (ale da się w ogóle, widuje takie specyfikacje) i nie ma sensu tworzyć takiej listy. Sposobem minimalizującym ryzyko złego wyboru jest dobra analiza biznesowa w celu wychwycenia tych obszarów firmy, które są jej specyfiką oraz opracowanie dla tego obszaru modelu dziedziny, a nie listy funkcjonalności. Nowe funkcjonalności spokojnie można “dodać”, jest to łatwe, pod warunkiem, że model dziedziny systemu i jego implementacja jest “właściwy”. W drugą stronę kompletnie to nie działa. 

Bardzo często obserwuję w projektach pewne “niedomówienie”, polega ono na nazywaniu “bytów” w oprogramowaniu tak jak coś rzeczywistego. W czym problem? Po kolei, bo problem, że tak powiem “jest szerzej dostrzegany”:

The ?Real? World. The problem with the ?real? world is that you are limited by the laws of physics. (za Don?t try to model the real world, it doesn?t exist. – Udi Dahan).

There are different operations on the hard disk in different spaces: in the physical space, such as the motor rotation and the magnetic head movement; in the computational space, such as the data accessing; in the conceptual space, such as the thinking activities. There is a nature of the three spaces: each space has its own operations by its own mechanisms.

 

(za Some Basic Topics and Judgment of Ownership to the Three Spaces ? THINK IN MODELS ).

Udi Dahan sugeruje zastanawianie się nad tym, jaki jest kontekst użycia, np. jeżeli szklanka jest produktem to modelujemy ją przez pryzmat tego, że to coś co ma nazwę, cenę itp., jako kontekst ograniczający wierność modelowania wskazuje np. prawa fizyki.  TY (autor bloga THINK IN MODELS) poszedł w stronę trzech przestrzeni (nazw): fizyczna, pojęciowa (conceptual) i apalikcyjna (computational).  Jak widać jest problem w nazwaniu (zrozumieniu) relacji pomiędzy modelem pojęciowym a bytem w oprogramowaniu. Myślę, że założenie brzmiące, że model dziedziny “reprezentuje” świat rzeczywisty jest mylący, jeżeli nie określimy kontekstu i pragmatyki. Pokażę to na innym przykładzie:

Celem jest opracowanie modelu dziedziny systemu, jest to serce systemu (przypominam [[wzorzec MVC]]). Praca “ręczna” to np. wprowadzanie danych do kart magazynowych. Mamy krzesło oraz kartotekę produktu zawierającą wybrane cechy tego krzesła: poza nazwą (krzesło), zapewne będzie cena, kolor itp.

Teraz pora na analizę biznesową i modelowanie dziedziny systemu.  Tworzymy klasę Dane produktu oraz Usługa (to enigmatyczna nazwa klasy ale…), która będzie “wiedziała” co wolno robić i jak, z kartami produktów.

Klasa Dane produktu jest realizacją prawdziwej kartoteki w systemie, klasa Usługa reprezentuje pewną umiejętność użytkownika (zapewne jakieś żmudne obliczenia i sprawdzenia, to element automatyzacji, wartość dodana tworzonego oprogramowania). Tak więc w modelu dziedziny pojawi się reprezentacja kartoteki produktu a nie produkt! Komputer wspiera zarządzanie  magazynem, ale nie zarządza towarami w nim, tylko zastępuje (usprawnia) ręcznie prowadzone kartoteki.

W opisanej metodzie analiza polega na zrozumieniu tego co tak na prawdę reprezentuje sobą projektowane oprogramowanie.   Nie tworzymy więc klasy Produkt, bo produktem tym jest krzesło, które jest i będzie realnym krzesłem.  Tworzymy klasę Dane produktu, bo tak na prawdę obiekt realizuje (zastępuje w aplikacji) papierową kartę, dane konkretnego produktu. Usługa  to ta część programu, która wykona coś za użytkownika (wyręczy go, wesprze go).

Tą metodą analizy i modelowania nie popadamy w problem modelu pojęciowego reprezentującego (tu) krzesło, bo krzesła nie odwzorujemy w kodzie, co najwyżej coś co je reprezentuje w pewnym kontekście (jego opis a może model 3D w programie CAD/CAM ale nie drewniane krzesło).

Tak więc nie Produkt a Opis produktu, nie User a Dane użytkownika, nie Pracownik a Dane pracownika itp. A usługi? Koniecznie Twórca kart produktu, Zarządca kartoteki itp, bo karta sama się nie utworzy, jeżeli te karty powstają zgodnie z jakimś scenariuszem (procedurą), to Usługa go nadzoruje, Wie jaki to scenariusz i realizuje go lub pomoże w tym użytkownikowi programu.

Tyle o modelach, a teraz polecam studiowanie DDD ([[Domain Driven Design]]) …:) bo analiza i modelowanie dziedziny systemu to ciężka i trudna praca polegająca na zrozumieniu i uchwyceniu istoty rzeczy. Dlatego leży na mojej półce, na bardzo eksponowanym miejscu [[książka Kazimierza Ajdukiewicza: Język i poznanie]]. Należy właściwie interpretować słowa (znaczenia jakie niosą).

Jakie są praktyczne efekty takich przemyśleń? Poniżej pewien hipotetyczny model manufaktury meblowej:

W tym przypadku: model krzesła jako wzorzec jego konstrukcji agregat Krzesło składający się z czterech nóg, siedziska i oparcia (tu faktycznie “modeluje” krzesło). W magazynie (Zarządca magazynu) mamy elementy składowe kzreseł (w rozumieniu dane o tych częściach w magazynie) i gotowe wyroby. Do składania ofert potrzebny jest Cennik, tu potrzebne są dane produktu (a nie one same). Zarządzanie cennikami korzysta z usług Zarządcy magazynu w celu pozyskania wiedzy o dostępności produktów, ale nie koniecznie taki parametr jak cena musi być u Magazyniera!

Ten model operuje pojęciem egzemplarza w magazynie (obiektów jest tyle ile egzemplarzy w magazynie). Jest to koncepcja może rzadziej stosowana w meblarstwie, ale często np. w AGD (konieczność operowania numerem seryjnym egzemplarza) do obsługi gwarancji.

Inne rozwiązanie:

Podstawowa różnica to rezygnacja z obsługi egzemplarzy na rzecz kartotek produktów. W tym przypadku modelujemy kartę z ilością rzeczy w magazynie (karta taka jest jedna dla każdego produktu).

To tylko prosty przykład, który obrazuje, że nie istnieje coś takiego jak “referencyjny model” dla każdego (prawie każdego). Specyfika pracy danej firmy może się przenieść na projekt. Co ciekawe, oba modele nie są wymienne (mimo bardzo podobnego wyglądu np. w dokumentacji). Jeżeli pierwszy model (egzemplarze) będziemy próbowali wdrażać w firmie posługującej się kartoteką będzie problem, której klasy użyć jako kartoteki? Kosztowna kastomizacja? Drugi model jest bezużyteczny tam, gdzie wymagana jest wiedza o egzemplarzach (np. do celów reklamacji).

Na koniec dodam: implementacja tego systemu z użyciem bazy relacyjnej SQL i znormalizowanie jej zniszczy ten model i ograniczy (o ile nie uniemożliwi) jego przyszły rozwój lub zmiany . Tu są i mają być redundancje oraz brak trwałych połączeń (asocjacje). Jedyne asocjacje to kompozycja. Związek pomiędzy cennikiem a stanem w magazynie polega wyłącznie na “zapytaniu” (relacja użycia w UML) Zarządcy magazyny ile ma krzeseł.

(Powyższe modele to poglądowe konstrukcje, nie należy ich traktować jako kompletne projekty. Gorąco polecam książkę: [[Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approa, Heinz Züllighoven, Morgan Kaufmann; 1 edition, October 13, 2004]])

Po co to? Bo zły model to złe oprogramowanie….

Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]:  grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią.

Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną “obsłużone”.

Na koniec nowy dodatek, cytat z pewnego bloga :):

Podstawową wartością biznesową jest nasza aplikacja. To tutaj jest miejsce na logikę biznesową i na umieszczenie wszystkiego tego co chcemy aby aplikacja robiła. To jak dostarczymy tą aplikację użytkownikowi jest sprawą wtórną ? dostarczymy w sensie jak użytkownik będzie konsumował nasz produkt. (Koncepcja elastycznej architektury | arek online | Arkadiusz Benedykt).