Swego czasu w artykule o Wścipskim Analityku uzasadniałem potrzebę panowania nad wymaganiami od momentu pojawienia się potrzeby biznesowej aż do jej implementacji. Nie znaczy to absolutnie, że analityk ma programować, znaczy to jednak, że analityk powinien dokumentować to czego żąda w wymaganiach a potem nadzorować realizację.
Developerzy uzurpują sobie prawa do wszystkiego co wiąże się z implementacją. Z jednej strony często żądają szczegółowych danych np. o danych z drugiej strony sami chcą opisać ich logikę biznesową (tak, bo dane biznesowe to logika biznesowa a nie technologia). Do tego bardzo wielu developerów stosuje metody pracy rodem z przed kilkunastu lat… We wspomnianym wyżej artykule napisałem między innymi o tak zwanym paradygmacie obiektowym i wiedzy o nim u developerów, szukam hasła „analiza procesowa” i „paradygmat obiektowy”:
Tradycyjnie idziemy do WIKI:
Przepraszamy, ale nie ma jeszcze artykułu ?Analiza procesowa? w Wikipedii. (24 Maj 2011)
No cóż, szukamy dalej:
Process analysis presents a chronological sequence of steps that explain how something is done, how something happens, or how readers can do something. (źr. http://www.tcc.edu/students/resources/writcent/handouts/writing/process.htm).
Coś mamy: analiza procesowa prezentuje w postaci chronologicznej sekwencji kroków, to jak coś powstaje, co się wydarza lub jak można coś zrobić. Piękna definicja. Ta prezentacja to, w kontekście biznesowym, model (mapa) procesów biznesowych.
Mamy wiec uporządkowaną wiedzę o firmie (organizacji) zamawiającego oprogramowanie. Tu także powstaje opis tego po co i gdzie tego oprogramowania chcemy używać: model procesowy.
Tak zwane niedopasowanie oporu
Tak jest nazywana w literaturze różnica pomiędzy paradygmatem procesowym a obiektowym. Paradygmat procesowy operuje takimi pojęciami jak: proces, wejście procesu, wyjście procesu, zdarzenie, wykonawca procesu (zasoby), czynność (lub ich sekwencja). Paradygmat obiektowy to wspomniane współpracujące obiekty. W czym problem? W przejściu z modelu procesowego na obiektowy. Czy to łatwe? Nie. Jak to zrobić? Hm… usiąść i popracować nad tym.
Należy przeprowadzić analizę obiektową i wykonać model obiektowy. Czego? Kodu? Nie! Logiki działania i organizacji zamawiającego!
Tak właśnie jest: analiza obiektowa i modelowanie obiektowe to nie programowanie. Programowanie (wraz z projektowaniem elementów czysto technicznych) to implementacja modelu.
Jak można radzić sobie z tym „niedopasowaniem”. Pomagają w tym zasady SOLID (w szczególności zasada otwartości na rozszerzenia i zamknięcia na modyfikacje oraz projektowanie zorientowane na zobowiązania klas) oraz wzorce DDD w analizie i projektowaniu.
To co tu opiszę nie jest „prostym algorytmem modelowania”, z pracy myślowej nikogo tu nie zwolnię. Moim celem jest uzupełnienie artykułu o szachownicy i artykułu o zbyt Niskim poziomie analizy o wskazanie, że model dziedziny jest bardziej elementem analizy i modelowania biznesowego niż projektowania i implementacji. Model ten to jedno z kluczowych wymagań: system ma realizować logikę opisaną w modelu dziedziny.
Jeżeli uznamy, że można (taki) model dziedziny implementować to jego opracowanie to także projektowanie. Nadal uważam, że nie jest to robota dla programisty, bo na jakiej podstawie on miał by taki model opracować?
Jak wygląda więc praca analityka biznesowego zgodnie z modelem kompetencyjnym IIBA (IIBA competency model). Kluczowym elementem pracy Analityka Biznesowego (w konwencji IIBA) jest prowadzenie (analiza) wymagań od momentu określenia potrzeby biznesowej aż do implementacji uzyskania właściwego rozwiązania. Jednak uzyskanie to nie to samo co własnoręczne wykonanie. Znowu analogia do budownictwa: architekt na bazie biznesowych celów swojego klienta opracowuje nie tylko wizualizację budynku ale także jego konstrukcję, do takiego poziomu by developer miał jednoznacznie postawione wymagania, nie blokuje to jednak developerowi „realizacji” wszelkich poza-funkcjonalnych wymagań.
Więc po kolei, opracowujemy.
Model procesu biznesowego
Mamy tu proces składający się z dwóch elementarnych procesów biznesowych (czynności). Każda czynności, zgodnie z definicją procesu biznesowego, ma dane wejściowe i dane wyjściowe. Dokument 2 i Dokument 3 powstają w tych procesach. Mamy także Procedury tworzenia dokumentów, czyli jakąś logikę ich tworzenia. Pojawia się także reguła biznesowa. Jest to to element z poza notacji BPMN (notacja ta zawiera jednak możliwość oznaczania czynności wymagających użycia takiej reguły). Na diagramie pokazano, regułę biznesową oraz jej powiązanie z konkretną czynnością.
Czas zacząć analizować czyli projektować nasz System. Założenie: wymagane jest by System (oprogramowanie) wspierało oba procesy: 1 i 2 (przypomnę, że proces biznesowy to jedna czynność lub ich sekwencja, więc jedną czynność mającą wejście i wyjście także z definicji, utożsamiany z procesem biznesowym).
Usługi systemu
Usługi systemu to korzeń analizy obiektowej. Stanowią szkielet całego obiektowego projektu. tworzymy bardzo ważny diagram: diagram przypadków użycia.
Często słyszę, że ten diagram nic nie wnosi do projektu. To nie prawda. Wnosi kluczową informację: wyznacza granice Systemu i wskazuje ewentualne powiązania z innymi systemami. Ale też nie prawdą jest, że służy do pokazania czegokolwiek ponad to, np. kolejności korzystania z usług czy struktury wewnętrznej. To ostatnie robimy w postaci modelu dziedziny.
Na powyższym diagramie udokumentowano:
- System oferuje użytkownikowi dwie usługi (to wymaganie by Czynność 1 i Czynność 2 procesu były wspierane przez System).
- System będzie korzystał z danych innego oprogramowania (Zewnętrznego źródła danych), wymagana jest więc integracja.
- Usługa 2 jest realizowana w całości przez inny, zewnętrzny system, wymagane jest od systemu więc by obsługiwał przekierowanie na inny system (np. realizacja płatności na stronie Banku).
Zakres projektu to wyłącznie to „co w środku”, albo lepiej: wszystko to co jest poza prostokątem System jest poza zakresem projektu. Nie dostarczamy ani Zewnętrznego źródła danych ani Systemu Zewnętrznego usługodawcy ale musimy na liście wymagań zapisać, że integracja z nimi jest wymagana i jaka ona ma być.
Logika działania Systemu – model dziedziny
Zabawa zaczyna się tu: zamieniamy „scenariusze” na „narzędzia i materiały”:
Celowo zachowałem nazwy tak by możliwe było „śladowanie” co z czego powstało. Kilka komentarzy, czyli dobre praktyki, wzorce i styl projektowania.
Każda usługa ma swoją dedykowaną klasę, zmiany realizacji jednej nie przeniosą się na inne. Usługi są więc od siebie niezależne. Oddzielono tworzenie dokumentów od ich przechowywania, dzięki czemu łatwo w przyszłości zmienić metody ich tworzenia bez potrzeby ingerencji w repozytorium. Wszelkie reguły biznesowe (w tym validacji) są „zamknięte” w tak zwanych złożonych typach danych (valueObject, sytuacja idealna to całkowity brak typów prostych (typy proste, primitives) w projekcie, wyłącznie typy złożone). W zasadzie zastąpienie wszystkich typów prostych na złożone w obszarze modelu dziedziny, otwiera w przyszłości drogę do ich rozbudowy bez potrzeby wprowadzania innych zmian w programie. Realnie pomiędzy Aktorem a usługą istnieją klasy widoku (GUI, View w MVC), tu nie umieszczone, bo klasy te nie realizują (nie powinny) żadnej logiki biznesowej.
Powyższy model:
- Spełnia zasady SOLID (w szczególności System jest łatwy w rozszerzaniu i nie wymaga w tym celu zmian)
- Jest zgodny z DDD czyli struktura modelu odwzorowuje strukturę i pojęcia biznesowe.
Co zyskujemy? Niskie koszty dalszego rozwoju, łatwość wyceny projektu przez developera (zna architekturę). Powstanie takiego projektu daje mi gwarancję, że panuje nad nim. Owszem mogę założyć, że developer także taki model opracuje, jednak życie pokazuje, że prawie na pewno nie…
Powyższe z oczywistych powodów (mało miejsca i uogólnienie) nie zawiera szczegółów, ale te należy zawsze w projekcie odkładać na sam koniec. Dzięki temu możemy skupić się na rzeczach na prawdę ważnych (ważne jest by zrozumieć cel tworzenia dokumentu a nie spisać jego zawartość, ta ostatnia wynika z tego do czego służy).
Ostatni wpis na blogu, o Niskim poziomie analizy zawiera akapit:
Istnieje niestety także bardzo duże ryzyko, którego źródłem jest stosowanie starych, strukturalnych metod wytwarzania oprogramowania czyli „rozbiór” (i projekt) systemu na bazę danych i procedury. Ta praktyka (metoda) niestety daje jako efekt oprogramowanie bardzo kosztowne w projektowaniu i rozwoju. Od metod strukturalnych znacznie lepsze są metody obiektowe, niestety samo deklarowanie korzystania z .NET czy Java albo notacji UML nie czyni stosowanych metod obiektowymi.
Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.
A gdzie baza danych? Nie tu! Implementacja przechowywania danych to praca developera, nie wolno mu jedynie znormalizować powyższego modelu. Zaprojektowanie relacyjnego modelu i użycie mapowania obiektowo-relacyjnego zniszczy wszystkie zalety tego projektu a dodatkowo strasznie skomplikuje całość.
(przedruk ukazał się w ERP-View)
Przewagę DDD widać gołym okiem, gdy porównujemy oba podejścia na tym samym przykłądzie pod kątem precyzji modelu i czasu pracy.
Gdy próbujemy analizować „po powierzchni” czyli z perspektywy procesów, to ilość możliwych kombinacji powoduje paraliż.
Wyjście od domeny pozwala na wyłonienie bazowych reguł biznesowych i skupienie się na nich. Dopiero później pracujemy nad warstwą aplikacji, która orkiestruje building blocks domenowe.
To trochę tak jak modelowanie gry w snookera. Możemy wyjść od wariantów rozbić, albo od bazowej „fizyki” (np. kąt padania równa się kąt odbicia). W drugim przypadku mam do czynienia z mniejszą ilością kombinacji stanów.
Dotykamy tutaj kolejnej kwestii: ograniczenia kognitywne ludzkiego mózgu. Przy nietrywialnym systemie analiza „po powierzchni” daje nam styczność z problemem o złożoności niemożliwej do ogarnięcia.
Ano, ja to nazywam „analiza jako kręcenie filmu”, a wyjściem z sytuacji jest jak najszybsze dotarcie do reguł biznesowych i tego czym zarządzają. Dlatego procesy biznesowe do analizy wymagań powinny być na dość wysokim poziomie, szczegóły i tak będą opisane w przypadkach użycia. Mapy procesów na setki stron, szczegółowość na poziomie „przekazanie dokumentu przełożonemu” to masakra projektowa.…
Czytam twój blog od jakiś kilku miesięcy i podsumowując krótko to naprawdę dużo bym dał żeby mieć kiedyś szanse na współpracę z analitykiem twojego kalibru 🙂 Niestety większość „modeli” z którymi zetknąłem się w swojej karierze to były poematy na 1000 stron w wordzie albo diagramy podobne do tego który zamieściłeś w tym artykule. Wynika to chyba z braku znajomości podstaw modelowania/projektowania obiektowego. Niestety dotyczy to również większości developerów, którzy stosują metody strukturalne, twierdzą uparcie że programują obiektowo. Wiele razy widuję w projektach „model dziedziny”, który w kodzie wygląda mniej więcej tak:
public class Employee
{
public string Name {get; set;}
public string Surname {get; set;}
public Company WorkingPlace {get; set;}
}
Oczywiście cała logika i implementacja reguł jest rozsmarowana obok, po całej solucji. Zastanawiam się z czego to się bierze. Jest masa materiałów, traktujących o projektowaniu/modelowaniu/programowaniu obiektowym, z których naprawdę można wynieść dużą wiedzę przy minimum wysiłku.
PS. Jedna mała techniczna uwaga: wydaje mi się że to co oznaczyłeś na diagramie z modelem dziedziny jako <> nie jest serwisem domenowym (w sensie DDD) lecz raczej serwisem aplikacyjnym spełniającym rolę kontrolera. Serwis domenowym powinien odzwierciedlać jakąś koncepcję z modelu i moim zdaniem jak najbardziej zalicza się do tej „relatywnie wolno zmiennej części dziedzinowej systemu”.
Co do literatury to jest, i jak się chce to się ma, faktem jest niestety, że ginie ona w masie bełkotu (nawet drukiem, mój ulubiony: książka podręcznik akademicki z diagramami klas zawierającymi klucze główne i obce, masakra). Co do ostatniego zdania, „definicje” usługi (serwisu) są różne ale jak na razie przemawia do mnie najbardziej ta z DDD, która po protu uznaje za serwis każda logikę „działania” (ja to nazywam, „umiejętność pracy z innymi obiektami”). Jako elementy domenowe traktuję wszystko to co dotyczy „biznesu”. W komponencie Model nie mam podziału na „aplikacja i inne”. Bardzo fajnie taka „konwencja” opisana w ksiązke „Tools & materials…” gdzie model dziedziny opisano jako metaforę „narzędzia i materiały” (narzędzie to także automaty czyli klasa realizująca sama jaką usługę). Ale jestem otwarty na dyskusje :), ale poruszyłeś ważną rzecz: coraz częściej „badam” wzorzec MVVM/MVC, i byś może faktycznie usługa w części «szybkozmiennej” jest «poza domeną” ale z drugiej strony to nadal logika biznesowa bo implementuje (i nadzoruje) scenariusz przypadku użycia.
Dyskutować można rzeczywiście dużo i długo bo pojęcie serwisu jest dosyć często (nad)używane, co tym samym powoduje jego spore przeładowanie. Ja wyróżniam dwa rodzaje serwisów: aplikacyjne i domenowe. Domenowe to te, które stanowią nieodłączną cześć domeny, zawierając logikę która „nie pasuje” do żadnej z encji/VO lub innych bytów. Serwis aplikacyjny to natomiast fasada dla naszego modelu, która orkiestruje operacje wykonywane na podstawowych składowych modelu domeny (encje, serwisy domenowe itd.), nadzorując ich użycie w celu spełnienia konkretnego przypadku użycia. Temat został dobrze rozwinięty w następujących postach:
http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/
http://gorodinski.com/blog/2012/04/14/services-in-domain-driven-design-ddd/
Najpierw małe wyjaśnienie: nie umieściłem na modelu elementów View, realnie pomiędzy Aktorem a „serwisem” odpowiedzialnym za realizację przypadku użycia, jest część obsługująca «ekran”, jednak nie ma w warstwie View żadnej logiki dlatego została pomięta na modelu (poprawię to). Ja w projektach przyjąłem zasadę rodem z TDD: komponent Model dziedziny (MVC) realizuje 100% wymagań funkcjonalnych (przechodzi wszystkie testy funkcjonalne). Taka klasyfikacja jasno wskazuje co jest a co nie jest elementem dziedziny systemu. W efekcie 100% wymagań poza-funkcjonalnych realizują pozostałe komponenty i infrastruktura.
Bardzo fajne linki, ale pojawiło się coś czego tu nie wiem: co jest „aplikacją” a nie jest elementem dziedziny? Bo ja po lekturze Evansa traktuję Model z MVC jako 100% logiki biznesowej, View i Controler to elementy realizujące pozabiznesowe funkcje (np. ergonomię GUI, AJAX, kodowanie transmisji, webserwisy itp.)
Siedzę sobie na konferencji o systemach ERP i pewna firma IT, ustami swojej złotoustej sprzedawczyni, młodej ładnej dziewczyny (panowie szefowie IT wpatrzeni jak w obrazek), zachwala swój produkt: relacyjna baza danych jako platforma i jej język 4GL jako narzędzie w jakim powstał ich „nowoczesny” system ERP. Tak więc technologia rodem z późnych lat 80-tych! Skąd się tacy biorą????
Sporo analityków których ja spotkałem miało bardzo duży background z baz danych. Tym samym często próbują przenosić to doświadczenie na pole analizy i modelowania systemów. Efektem są oczywiście modelu uwzględniające głównie strukturę danych, co pośrednio przekłada się na technologię, w której realizowany jest projekt.
Apropos podziału na serwisy domenowe i aplikacyjne to po głębszym zastanowieniu wydaje mi się że jest on bliższy samej implementacji. Z perspektywy modelowania biznesowego «serwis» to to coś realizuje przypadek użycia poprzez orkiestracje elementów z modelu domeny. Dla mnie (z perspektywy implementacji) serwis aplikacyjny to adapter w rozumieniu architektury ports&adapters.
http://c2.com/cgi/wiki?PortsAndAdaptersArchitecture
Ja patrze na model dziedziny systemu jak na obiektowy model „danego biznesu”, innymi słowy jest to w 100% oderwane od implementacji, jak na razie się sprawdza ;), czy to ideał… nie wiem 😉
A w kwestii „tych analityków” to po prostu robią klasyczną strukturalną analizę z użyciem UML, która z metodami obiektowymi nie ma nic wspólnego, gorzej bo upierają się, że „to diagram klas UML więc jest OK”.