Wpadł mi w ręce, jakiś czas temu, krótki artykuł na temat [[rynku FMCG]]. Pomijając “nieczyste” praktyki reklamy porównawczej, pokazuje jaka arogancja panuje w świecie korporacji i “dużych firm”, którym się wydaje, że duży może więcej. Pogoń za zyskiem, pozbawiona nie tylko rozsądku ale także krzty etyki,  objawia się między innymi takimi próbami szantażu:

To jednak także efekt zapędzenia się przez branżę handlową w kozi róg. Bo wiadomo: klienci chcą kupować tanio. A sklepy chcą im to zapewnić. (za Wojna handlowa: Kaufland wyrzucił Danone ze sklepów).

W pewnym sensie cieszą mnie takie “zdarzenia”, bo jeden daje popalić drugiemu, do tego przy okazji ataku jednego giganta na drugiego wychodzą ich oszustwa  (przypomnę, że Danon wprowadzał reklamami w błąd i zakazano emisji niektórych z nich).

Swego czasu miałem do czynienia ze sklepami wielkopowierzchniowymi i ich metodami negocjacji: to tragedia etyczna. Nie mam zamiaru tu opisywać metod pracy kupców (negocjatorzy w tych sklepach), co gorsza uczą się tego na wewnętrznych, zamkniętych szkoleniach (szkolenia “skutecznych” negocjacji). Jednak jest światełko w tunelu: jeżeli coś jest na prawdę dobre i smak (jakość) ma dla kogoś znaczenie to do “duży” ze swoją siła perswazji jest bezsilny (dobre piwo kontra piwo z korporacji).

Powolutku na rynku IT zaczynam dostrzegać podobne zjawisko, choć “duży nadal może więcej”. Okazuje się, że wielkość firmy absolutnie nie przekłada się na jakość tego co dostarcza. Tu od razu dodam, że wniosek w rodzaju “małe firmy robią to lepiej” także nie działa. Po protu jakość nie zależy od wielkości firmy…

Poprzedni artykuł kończyły słowa:

Tak więc jest to moim zdaniem droga do modelowania wymagań metodą ?tak to ma działać? a nie tylko ?tak to ma wyglądać?, bo to drugie jest przyczyną wielu problemów?

Wielu developerów zaciekle broni się przed tezą, że wymagania to także ?żądana realizacja logiki biznesowej?, oczekują wyłącznie zestawu wymagań funkcjonalnych i poza-funkcjonalnych. Jest to moim zdaniem źródło dwóch ryzyk:

• jeżeli zamówienie jest opisem czarnej skrzynki tak na prawdę nie wiemy do dostaniemy jako jej realizację,
• jeżeli autorem realizacji jest dostawca, pozostaje mu niezbywalne prawo do projektu tej realizacji.

Dlatego warto, jako wymaganie przekazać projekt tak zwanej ?białej skrzynki?, bo zabezpiecza to nas przed powyższymi ryzykami. (Wzorzec analityczny Boundary Control Entity).

Czemu tak bronię tej tezy? Zarzuty developerów wobec mnie to: “wymuszasz implementację a to rola projektanta”. Jest to nie prawda, bo projekty wymagań zawierające wewnętrzną logikę to jeszcze nie implementacja, ale na pewno jest to oczekiwanie kupującego oprogramowanie. Gdybym kupował samochód nie chciał bym, by mi ktoś powiedział, że wolno mi powiedzieć tylko jak będę do niego wsiadał, wysiadał i po co, że będę zgodnie z  ogólnymi zasadami naciskał pedały i manipulował drążkiem zmiany biegów. Nie! Mam prawo i ochotą określić typ silnika, żądać ABS i wiele innych rzeczy. Jeżeli ja nie znam się aż tak na samochodach poproszę o pomoc kogoś kto się zna. Jest ryzyko? Jest, ale to ja o nim decyduję a nie sprzedawca samochodów!

Jeden z wielu powodów takiego podejścia

Przytłaczająca większość developerów, z którymi się spotkałem, rozwiązuje problem wydajności np. pracy z listą produktów, podejmując kompromis pomiędzy szczegółowością i wiernością “opisu produktu” a wydajnością (czas odpowiedzi systemu) np. podczas prezentacji (generowania) uproszczonego cennika. Większość znanych mi developerów niestety prezentuje coś co nazywam “strukturalny model projektowania oprogramowania oparty na anemicznym modelu dziedziny”. Z reguły rozwiązują oni opisany wyżej problem cennika, upraszczając opis produktu (psują model!), umieszczają uproszczone dane o produkcie w modelu relacyjnym wraz z resztą danych i walczą z optymalizacją zapytań do tej relacyjnej bazy (upraszczanie i denormalizacja).

Nie raz prowadzi to do sytuacji, w której oprogramowanie jest “szybkie i nieprzydatne”. 

<–jeżeli nie jesteś analitykiem przejdź na koniec artykułu–>

Wygląda to wtedy np. tak (źr. Fowler CQRS):

Od prawej: interfejs użytkownika, model dziedziny, baza danych (podsystem utrwalania).

CQRS

Nie od dzisiaj znany jest wzorzec projektowy, który radzi sobie z tym problemem. Nazywa się CQRS, i tak jest opisywany przez  “guru” analizy i projektowania :), Martina Fowlera:

CQRS stands for Command Query Responsibility Segregation. It’s a pattern that I first heard described by Greg Young. At its heart is a simple notion that you can use a different model to update information than the model you use to read information. This simple notion leads to some profound consequences for the design of information systems. (źr. CQRS).

Idea tego pomysłu na tym, by nie optymalizować wydajności systemu metodą, nie raz zgniłego, kompromisu, a podejść do problemu dzieląc go na dwa problemy: zgodność modelu z rzeczywistością i wydajność całego systemu. Pierwszy problem rozwiązujemy tworząc wierny model struktury opisującej produkty, drugi problem – wydajności – rozwiązujemy tworząc drugi uproszczony model produktów, do celów szybkiej realizacji kilku ważnych “zapytań” (np. publikacja on line uproszczonej postaci cennika).

Powyższy diagram pokazuje: UI (interfejs użytkownika), pokazuje menu zgodne z opisem z przypadków użycia (wymagania funkcjonalne). Model dziedziny (część środkowa) pokazuje oczekiwane rozwiązanie (takiego żądam w wymaganiach). Polega ono właśnie na zaprojektowaniu w części dziedzinowej odrębnego modelu do zarządzania pojedynczymi produktami i odrębnego do wydajnego zarządzania ich kolekcją. Owszem, model się nieco skomplikował (jest nieco kosztowniejszy w implementacji),  ale jako zamawiający mam to czego potrzebuję: wydajny i użyteczny system.

<–jeżeli nie jesteś analitykiem tu zacznij czytać dalej–>

Opisując wymagania wyłącznie jako “czarną skrzynkę” nie wiem co dostanę. Większość developerów będzie dążyło do uproszczenia implementacji (ich koszt, nie raz brak wiedzy) by zaspokoić na minimalnym poziomie wymagania opisane przypadkami użycia. Nie raz klient słyszy “tu musimy to uprościć bo tak się nie da”, a zamawiający, nie mając kompetencji by polemizować z taką opinią, zgadza się i dostarczony w efekcie system staje się zgniłym kompromisem opartym właśnie na “czarnej skrzynce” jako specyfikacji zamówień: “dostaliśmy dokładnie to co zamówiliśmy ale zupełnie nie to czego naprawdę potrzebujemy”. 

Tak więc,

nie ma znaczenia fakt, że na pewno są  na rynku developerzy znający problem, który opisałem i stosujący opisane tu rozwiązanie takich problemów. Jednak nawet cień ryzyka (a jest ono na prawdę duże), że dostaniemy bubla, daje zamawiającemu prawo do szczegółowego definiowania wymagań jako “białej skrzynki”, bo dzięki temu zamawiający dostanie “to czego potrzebuje a nie tylko to co zamówił“.

Dla zainteresowanych także do pobrania książka z MSDN:

The CQRS pattern and event sourcing are not mere simplistic solutions to the problems associated with large-scale, distributed systems. By providing you with both a working application and written guidance, we expect you’ll be well prepared to embark on your own CQRS journey. (za CQRS Journey).

Opisywałem ostatnio wzorzec DDD jako narzędzie dokumentowania analizy i tworzenia modeli analitycznych. Faktycznie, czytelnicy mają wiele racji twierdząc, że często jest on zbyt bliski implementacji (zbyt szczegółowy a więc trudny dla nieprogramistów). Niejednokrotnie “lepszym pomysłem” jest opis logiki systemu na nieco wyższym poziomie abstrakcji, pozostawiając tym samym więcej swobody developerowi.

Od czasu do czasu używam wzorca BCE (Boundary, Control Entity) do modelowania logiki biznesowej. Jego rodowód sięga chyba jeszcze czasów początków [[metodyki RUP]]. Pierwotnie był traktowany jako wzorzec analityczny do modelowania architektury kompatybilnej z MVC, w swej oryginalnej postaci nawiązuje do EJB/DAO ([[Enterprise JavaBeans/Data Access Object]]). Przykładowe standardowe użycia (źr. wiki):

Wzorzec BCE kojarzony jest głównie z architekturą EJB (Enterprise Java Beans). Od tamtej pory EJB jednak nieco odeszło w “niepamięć”, nie mamy już J2EE a JEE. Wzorzec MVC doczekał się sensownej moim zdaniem mutacji do wersji MVVMC (Model-View-ViewModel Contoler), MVP, i kilku innych odmian. Diagram w tej konwencji jest także nazywany “robustness diagram” i kojarzony jest z metodyką ICONIX, jednak osobiście polecam stosowanie zasad UML i używanie diagramu klas zgodnie z jego “zasadami” czyli używanie  związków użycia (linia przerywana z grotem a nie ciągła) i uznanie, że robustness diagram to po prostu diagram klas.

Podstawowa pierwotna wersja interpretacji wzorca BCE opisana jest zwięźle tutaj:

This pattern is similar to the Model View Controller pattern (described here [BUS96] and here [WIKP-MVC] among other places), but the Entity Control Boundary pattern is not solely appropriate for dealing with user interfaces and it gives the controller a slightly different role to play. (za Entity-Control-Boundary Pattern).

Stosuję go jednak w “nieco zmienionej” formie.

Boundary, Control, Entity

Jak widać na powyższym, BCE nawiązuje bezpośrednio do wzorca MVC, klasy boundary są w tej wersji już elementami komponentu View. Starając się oddzielić (hermetyzować) logikę biznesową od części “niebiznesowej” kodu, będącej w większości przypadków elementami środowiska ([[framework]]) aplikacji.

Nieco inne podejście, to które stosuję obecnie, opisuję poniżej. Zachowując podstawowe znaczenia tych trzech klas (BCE), nawiązałem do wzorca MVVM. Powstaje więc konstrukcja, w której Model ma strukturę M-VM, pozostałe elementy View i Controler mają konkretne zadania:

• M-VM to struktura części dziedzinowej (Model-ViewModel),
• View – tradycyjnie odpowiada za prezentację,
• Controler – tradycyjnie odpowiada za zarządzanie całością, w tym poza-funkcjonalne wymagania (np. kodowanie transferu danych nie jest elementem dziedziny systemu, itp.)

Pewna ciekawostką jest w tym wzorcu właśnie element VM (ViewModel). Jego idea polega na umieszczeniu w obszarze dziedziny dodatkowej wiedzy (logiki), sterującej tym jakie (chodzi o ich “bogactwo”) informacje są podawane na urządzenia prezentujące o różnych możliwościach np. mały lub duży ekran, rozdzielczość czy wręcz komunikacja z pomocą SMS.

Powyższy diagram pokazuje schemat budowania modelu na bazie tego wzorca. Jak widać element dziedziny Model zachowuje się zawsze tak samo, reprezentuje wiedzę i logikę dziedzinową (np. komplet informacji o osobie), Dziedzina (Model) jest  dodatkowo wyposażona w wiedzę o możliwościach prezentowania pełnej lub okrojonej wersji wiedzy publikowanej przez obiekt dziedzinowy (klasy ViewModel). Dzięki temu View nie zawiera żadnej logiki np. filtrowania pełnej informacji, dostaje  tylko prosty przygotowany zestaw danych do prezentacji poza samą prezentacją (dla uproszczenia pomięto komponent Controller).

Jest to o tyle wygodne i ważne, że stosowanie wzorca BCE wyłącznie do modelowania logiki biznesowej wymaga zachowania hermetyzacji komponentu Model. Spotkać się można z diagramami, w których boundary będzie elementem komponentu  Model (jako ViewModel). Jego rola to stworzenie dedykowanego interfejsu np. pomiędzy komponentem View (lub Controller) a Model. Dzięki temu możliwe jest np. stworzenie odrębnego interfejsu dla View na duży ekran i odrębnego dla View na np. małych ekranach smartfonów. Takie podejście wygląda tak:

Znaczenie (semantyka) stereotypów:

Boundary to klasa oznaczona stereotypem <<boundary>>, na diagramach reprezentowana może być ikoną jak po lewej.  Odpowiedzialność klas boundary to separacja modelu dziedziny od innych komponentów (to często adapter, fasada, interfejs). Dzięki temu ewentualne zmiany Modelu nie przeniosą się na komponenty View i Controller oraz możemy zbudować  np. różne dedykowane i bezpieczne dziedzinowe adaptery dostępowe do Modelu (np. w systemie nawigacyjnym boundary dostarczy Modelowi koordynaty geograficzne, View pozwoli wprowadzić je z klawiatury a Controller z odbiornika – interfejs – GPS, Model staje nieczuły na źródło tych koordynatów).

Control. Klasy  oznaczone stereotypem <<control>> lub ikoną jak po lewej. Są to klasy odpowiedzialne za wewnętrzne usługi specyficzne dla dziedziny, “umiejętności”.  Nie są to klasy utrwalane. Ta klasa będzie obliczała np. czas przejazdu na bazie wytyczonej w systemie nawigacji strasy.

Entity. Najbardziej kontrowersyjna klasa, w pierwotnej wersji interpretacji wzorca BCE (EJB) oznaczała tylko dane utrwalane, nawiązując do EJB  stanowiła “materiał” na tak zwany [[antywzorzec obiektowy o nazwie anemiczny model dziedziny]]. Klas oznaczonych stereotypem <<entity>> używamy do modelowania wiedzy, czyli zgromadzonych danych, nie są to jednak anemiczne klasy bez operacji. Będą to np. punkty na mapie cyfrowej.

Trzy powyższe typy klas są tu elementami komponentu Model.  Przejście na poziom DDD, drogę w kierunku implementacji tego modelu przy powyższych założeniach, można realizować np. tak:

Interpretacja ta pozwala zachować główny cel czyli rozłożenie logiki Modelu na “prostą” mapę trzech elementów: kontaktu z otoczeniem (boundary), realizacji  logiki i reguł (control) oraz zachowywania “biernych” obiektów biznesowych (entity). Mała adaptacja konwencji do wzorca MVVM-V-C pozwala uzyskać komfort całkowitej separacji tak modelowanego Modelu od jego otoczenia.

Tak więc jest to moim zdaniem droga do modelowania wymagań metodą “tak to ma działać” a nie tylko “tak to ma wyglądać”, bo to drugie jest przyczyną wielu problemów…

Wielu developerów zaciekle broni się przed tezą, że wymagania to także “żądana realizacja logiki biznesowej”, oczekują wyłącznie zestawu: wymagania funkcjonalne i poza-funkcjonalne. Jest to moim zdaniem źródło dwóch ryzyk:

• jeżeli zamówienie jest opisem czarnej skrzynki tak na prawdę nie wiemy do dostaniemy jako jej realizację,
• jeżeli autorem realizacji jest dostawca pozostaje mu niezbywalne autorskie prawo osobiste do projektu tej realizacji (majątkowego nie musi wydać).

Dlatego warto, jako wymaganie przekazać projekt tak zwanej “białej skrzynki”, bo zabezpiecza to nas przed powyższymi ryzykami. 

Literatura

Polecam ciekawy artykuł na podobny temat:

As we have seen, the fundamental idea of MVC is a separation of the domain logic and the GUI objects into the Model and the View. These two are linked indirectly by using the Publish-Subscribe mechanism known as the Observer pattern. Another element of this design is a Controller that implements a particular strategy for the View. (Model View Controller, Model View Presenter, and Model View ViewModel Design Patterns – CodeProject).

Oraz (apropo MVVM iMVC):

Warto pisać aplikacje w taki sposób, żeby można było je w całości obsługiwać za pomocą testów jednostkowych. Jak należy to rozumieć? Budując aplikację w taki sposób, że cała jej funkcjonalność dostępna jest bez interfejsu użytkownika, możesz każdy jej aspekt opisać za pomocą testów jednostkowych. To pozwala na wstępne testowanie zgodności aplikacji z wymaganiami wstępne, bo cały czas należy pamiętać, że testy jednostkowe to narzędzie, wspierające programistów, a nie testerów i jako takie nie może zastąpić testów aplikacji. (Wykorzystanie TDD wraz ze wzorcem MVVM).

Kiedy i po co robimy te modele?

Tu nawiążę do MDA (tu co nieco o Model Driven Architecture). W łańcuchu modeli MDA mamy trzy modele: CIM->PIM->PSM. Analiza biznesowa na pierwszym etapie to tworzenie modelu organizacji pomijającego istnienie jakiegokolwiek oprogramowana (CIM – [[Computation Independent Model]]), celem jest pełne zrozumienie i opisanie funkcjonowania organizacji.

Kolejny etap to opracowanie modelu dziedziny projektowanego (wymaganego) oprogramowania. To model PIM ([[Platform Independent Model]]). Jego celem jest udokumentowanie logiki oprogramowania, wymagania poza funkcjonalne są realizowane niezależnie od tej logiki. Tak więc model PIM do coś co nazywane bywa: “wymagania dziedzinowe”. Wymagania funkcjonalne nie opisują w ogóle logiki biznesowej, same przypadki użycia nie są wystarczające do napisania oprogramowania, potrzebna jest wiedza o logice biznesowej. Funkcjonalność “system sprzedaży automatycznie uwzględnia upusty dla klientów” nic nie mówi. Ale gdzie definicja logiki udzielania tych upustów? Gdzie jest wiedza o upustach a gdzie o towarach? Przy kliencie czy przy towarze? Nie wiadomo, trzeba to jakoś zrozumieć i udokumentować, w sposób pozwalający na implementacją czyli jednoznacznie. I po to się tworzy modele PIM.

Tu jednak należy się mała uwaga (bo nigdy nie mów nigdy): bywa, że ograniczenie o treści “maksymalny czas oczekiwania na ofertę nie może przekroczyć progu cierpliwości 80%  klientów”. Pozostaje zbadanie “progu cierpliwości”, ten parametr nie jest elementem reguły biznesowej gdyż jest właśnie “parametrem” a nie “zasadą” (reguły biznesowe to zasady postępowania a nie reguły podejmowania decyzji czy mierniki). Ta reguła może stać się elementem dziedziny projektowanego systemu jeżeli np. jej spełnienie jest elementem budowy przewagi rynkowej. Co to znaczy? Że nie należy optymalizować obecnego modelu dziedziny (np. podnoszenie wydajności poprzez uproszczenie struktury opisu produktów) a dodać do dziedziny strukturę pozwalającą na wykonywanie pewnych wybranych czynności prościej i szybciej. To jednak temat o wzorcu projektowym CQRS ale to temat na inny artykuł.

(inne źródła:

basic rules apply: Actors can only talk to boundary objects.Figure 3. Robustness Analysis RulesBoth boundary objects and entity objects are nouns, and controllers are verbs. Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs. Boundary objects can only talk to controllers and actors. Entity objects can only talk to controllers. Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors

źr. Memorandum).

Poprzedni artykuł kończył się odpowiedzią na tytułowe pytanie (wg. mojej oceny):

Jest to ktoś, kto potrafi analizowaną organizację ?rozłożyć na elementy składowe?. Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie ?rysunek?, to model w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję  i zasady wzajemnego łączenia i oddziaływania.

Analiza Biznesowa to rozłożenie analizowanego ?przedmiotu? na skończony zestaw elementów, który z określoną dokładnością zachowuje się tak, jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania. (Poziomy szczegółowości wymagań ? wzorce DDD ? czyli czym jest analiza obiektowa).

Po tym artykule pojawiły się dyskusje na temat roli analityka (analizuje czy także projektuje) i dostawcy (czy tylko on ma kompetencje projektowe).

“Moje przesłanie” w tym tekście:

Skoro logikę biznesową “programuje się” (implementuje się) z użyciem obiektowych wzorców projektowych, to ideałem było by wskazać te wzorce, które wg. najlepszych praktyk są wykorzystywane do implementacji logiki biznesowej i uczynić z nich “klocki”, na które należy, na etapie analizy biznesowej, rozłożyć problem. To się np. nazywa DDD czyli siedem wzorców spośród wielu.

Korzyści są ogromne, bo “wycinamy” etap głuchego telefonu między Zamawiającym i wymaganiami w postaci prozy i tabel a developerem, który ma zrobić obiektowy model czegoś czego tak na prawdę nie rozumie, a opis prozą jest niestety bardzo niejednoznaczny i podatny na przekłamania (głuchy telefon).

Pytanie (jedno z wielu) jakie dostałem:

Jarku, zgodzę się, że dobry analityk “potrafi analizowaną organizację rozłożyć na elementy składowe”. Ale projektant? Projektant, to ktoś kto potrafi powiedzieć, jak elementy składowe złożyć w całość. Człowiek od syntezy, a nie od analizy 🙂

I generalnie jest w tym sporo racji, jednak odpisałem z pewnym “ale”:

OK, ale stety/niestety role analiza/synteza zacierają na tym etapie, gdy narzędzia jakich używa analityk do udokumentowania wyników analizy to te same narzędzia, które służą do projektowania… i tu jest “problem”, skoro analiza potrzeb przed wybudowaniem domu daje w efekcie projekt tego domu to mamy architekta który pyta “po co ten dom” i projektuje go.. realizuje dopiero developer

A tak to ogólnie wygląda:

[[Analiza wymagań]] to temat rzeka, metody są różne ale nie będę pisał o znanych mi, tylko o pewnym podejściu “systemowym” zorientowanym na modele i wzorce projektowe. Ale po kolei.

Ile mamy poziomów szczegółowości wymagań

Poziom szczegółowości wymagań jest tematem wielu dyskusji, pisałem tu już nie raz na ten temat. Tym razem nie o tym, że zarządzanie tysiącami detali dużych pakietów oprogramowania jest niemożliwe (i nieracjonalne). Tym razem o tym, że stosowane wzorców, tu analitycznych i projektowych, pomaga. Najpierw kilka słów o poziomach szczegółowości, które stosuję:

• Najwyższy poziom abstrakcji to nazwanie celu biznesowego np. chcemy sprawnie wystawiać faktury VAT. Jedno zdanie, bez szczegółów. To najczęściej jest cel sponsora projektu, którym jest niejednokrotnie ktoś z zarządu.
• Kolejny etap to doprecyzowanie tego wymagania, w tym momencie powołujemy się albo na przepisy, które opisują to wymaganie wystarczająco szczegółowo (np. Ustawa o podatku VAT i Ustawa o rachunkowości). Jeżeli nie mamy na co się powołać poszerzamy ten opis sami. Tu mamy do czynienia z usługą systemu z perspektywy zamawiającego a z [[przypadkiem użycia]] z perspektywy oprogramowania.
• Jeżeli oprogramowanie miało by być wykonane na zamówienie,  powstaje dodatkowo uszczegóławiający opis każdej usługi zawierający: dane wejściowe i oczekiwane dane wyjściowe, wzory formularzy do wprowadzania danych i wzór produktu (tu wzór faktury) oraz scenariusz użycia czyli oczekiwania zamawiającego co do sposobu pracy z przyszłym programem. Opis taki robi analityk-projektant a jako źródło informacji występuje ekspert dziedzinowy (często przyszły użytkownik).

I tu zaczyna się ciekawszy ciąg dalszy. [[Przypadki użycia]] to tak zwany [[opis czarnej skrzynki]], nic nie mówi o logice jaką chcemy odtworzyć, wbudować do nowego oprogramowania. Pojawia się ważne pytanie: jaką “wiedzę” ma mieć to oprogramowanie? Przypadki użycia kojarzy się z tak zwanymi Aktorami systemu. Są to określone role, które będą wykonywane przez użytkowników (np. Specjalista ds. Handlowych może pełnić rolę fakturzysty – aktorem jest Fakturzysta). Dopiero po zdefiniowaniu wiedzy jaką ma (ma mieć) Aktor, mamy podstawy definiować “wiedzę” jakiej oczekujemy do oprogramowania (to czego nie potrafi Aktor).

Czarna skrzynka (wyłącznie przypadki użycia) jako wymaganie jest bardzo ryzykownym narzędziem, bo nie definiuje tego jaką “wiedzę” ma mieć (odtwarzać) to oprogramowanie. Tu potrzebne jest określenie z czego będą powstawały oczekiwane produkty (co jest potrzebne do wystawiania faktury VAT, np. produkty i usługi zna fakturzysta czy ma je podpowiadać oprogramowanie).

Potrzebny jest więc opis logiki biznesowej, którą chcemy zaimplementować. Ten opis to sedno problemu pracy analityka.

I przyszła pora na “analizę”. Powszechnie nadużywane słowo analiza oznacza:

analiza [gr. análysis ?rozłożenie?, ?rozbiór?], rozłożenie pewnego obiektu na elementy składowe (części, cechy, relacje); może być zabiegiem fizycznym lub czynnością myślową; (za Encyklopedia PWN).

Słowo klucz: “elementy składowe”. W metodach pracy, które stosuję, powyższe jest podstawowym “narzędziem” pracy. Ale tu małe wyjaśnienie: niestety większość spotykanych dokumentów analitycznych, nie wiele ma wspolnego z analizą. Dlaczego? Skoro analiza to “rozłożenie na elementy składowe”, to czym jest zapis życzeń i oczekiwań wyartykułowany ustami pracowników jakiejś firmy czy organizacji na spotkaniach, w postaci tekstu, tabel lub nieformalnych obrazków ? Jest po prostu jakimś spisem ale na pewno nie analizą.

Żeby dokonać jakiejkolwiek analizy musimy sobie najpierw zdefiniować jakieś “elementy składowe”. Analiza zdania polega na wyodrębnieniu słów, kojarzeniu ich w związki itp. ale początkiem jest istniejący słownik i reguły gramatyczne. Analiza chemiczna to rozłożenie substancji na z góry znane pierwiastki (pomijam ich odkrywanie). Czym jest analiza biznesowa czy analiza wymagań?

Analiza procesów biznesowych wymaga zrozumienia tego co dzieje się w analizowanej firmie i rozłożenie tego na predefiniowane elementy składowe. W zasadzie mamy jeden: proces biznesowy. Jego definicja określa atomowy element takiej analizy.  Jeżeli patrzymy więc diagram zawierający prostokąty i linie będące graficznym zapisem tego “co powiedziano”, nie jest to żaden wynik analizy ani model a jedynie obrazkowy zapis opowieści.

Dalej: projektowanie oprogramowania. Na czym polega analiza obiektowa i projektowanie? Po pierwsze znowu potrzebne są “elementy składowe” (przypominam, że ma być ich skończona liczba, mają zdefiniowane znaczenia, które się na siebie nie nakładają (nic nie może pasować do dwóch definicji jednocześnie) i pozwalają, z ustalona dokładnością, na zbudowanie analizowanej całości.

Przykład

Opiszę jak można prowadzić analizę i budować część wymagań o nazwie model dziedziny (model logiki biznesowej).

Zgodnie z powyższym należy zacząć od zdefiniowana sobie skończonej liczby klocków (ich typów). Np. LEGO, można z nich zbudować “wszystko” akceptując pewną granice w odtwarzaniu uszczegółów. Typów podstawowych klocków jest kilka a jednak można z nich zbudować dom, samolot czy kaczkę:

Analiza polega na tym, by realny dom lub kaczkę rozłożyć na skończona liczbę (z reguły nie wielką) prostych elementów składowych, których “słownikiem” jest posiadany zestaw LEGO. Wynikiem analizy jest “dokument” w postaci instrukcji “jak złożyć domek z LEGO”. Innymi słowy, mamy skończoną liczbę elementów “budulcowych” analiza polega na zrozumieniu problemu, rozłożeniu go na takie właśnie elementy.

Osobiście jestem zwolennikiem stosowania [[wzorca projektowego MVC]] oraz stylu analizy i projektowania zwanego DDD (ang. [[Domain Driven Design]], projektowanie sterowane dziedziną systemu, artykuł o DDD). DDD to wzorce zarówno analityczne jak i projektowe. Te wzorce to właśnie takie atomowe “klocki”.

Na etapie analizy, “rozkładamy” analizowaną firmę (jej część) na elementarne składniki. W DDD są to pojedyncze encje i ich agregaty, typy (value-object), usługi, fabryki, repozytoria. Analiza polega na opisaniu (rozłożeniu jej ) całej logiki oprogramowania z pomocą tych kilku standardowych “klocków”. Model taki dla developera staje się projektem, a te klocki wzorcami projektowymi.

Poniżej “zabawowy” przykład takiej analizy.

Aktorem jest użytkownik. Potrzebny mu jest “system” który da mu przedmiot wykonany z klocków LEGO (domek). System całkowicie izoluje Aktora od swojego wnętrza z pomocą Recepcji (View w modelu MVC). Wewnątrz mamy zestaw klocków (encje, agregaty), delikwenta wiedzącego jak wykonać domek (usługa) oraz fabrykę klocków (na bazie wzorców tworzymy ich tyle ile potrzebujemy, ile zażąda usługodawca).

Aby zachować wytworzone klocki a także wyniki prac czy półprodukty, musimy mieć pudełko na klocki: repozytorium. Nad całością czuwa Kontroler, ekipa ludzi zajmująca się wszystkimi “poza specjalistycznymi” (poza-dziedzinowymi) zadaniami.  Z racji tego, że takie pojęcia jak wydajność, zasoby, bezpieczeństwo itp. są uniwersalne, taka ekipa back office (skrzynka na zabawki, recepcja, kontroler) może zostać wynajęta niemalże dla każdej firmy bez względu na branże (to się nazywa framework). Specyficzna jest tylko dziedzina, tu typ klocków.

Tak więc analiza wymagań na oprogramowanie to lista wymaganych usług. Wymagania na dedykowane oprogramowanie zaś to nie jest spisanie i sortowanie oczekiwań. Analiza to rozłożenie problemu (firma klienta) na klocki zgodne z uznaną (używaną) metodyką i wzorcami. DDD (opis wzorców projektowych DDD) to właśnie jeden z takich zestawów klocków.

Wynikiem analizy jest model (a nie tylko obrazek) opisujący jak działa analizowana firma, zbudowany z klocków, tu opisanych w DDD.

Dla developera taki model jest projektem logicznym ([[Platform Independent Model w nomenklaturze OMG/MDA]]).  W efekcie analityk nie tylko zrozumiał i udokumentował problem, analityk zaprojektował logikę biznesową oprogramowania, możliwą do bezpośredniej implementacji przez developera (przy założeniu, że stosuje metody obiektowe i zna użyte wzorce). Taki efekt dają metody obiektowe i pragmatyki np. DDD. Za to właśnie bardzo lubię obiektowy paradygmat i DDD: “obiektowość” zrównuje wynik analizy z projektem, DDD daje nam zestaw klocków: słownik pojęć,  zrozumiały dla “biznesu” i dla developera. DDD to zestaw wzorców pozwalający na dogłębne zrozumienie analizowanego problemu i będące zarazem projektem jego implementacji.

Kim więc jest dobry analityk?

Jest to ktoś, kto potrafi analizowaną organizację “rozłożyć na elementy składowe”. Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie “rysunek”, to model w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję  i zasady wzajemnego łączenia i oddziaływania.

Analiza Biznesowa to rozłożenie analizowanego “przedmiotu” na skończony zestaw elementów, który z określoną dokładnością zachowuje się tak, jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania.

Więc poziomy szczegółowości wymagań to:

• cele biznesowe (produkty procesów biznesowych)
• opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania)
• opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)

P.S.

Artykuł ma charakter “badawczy”, wszelkie uwagi mile widziane.