Wstęp

Przyszła w końcu pora na model dziedziny systemu i model sekwencji dla przypadków użycia. Wspomnę także o wymaganiach niefunkcjonalnych. W poprzednim artykule: Diagram klas – czyli “re-inżynieria” analizy biznesowej c.d. Przypadki użycia i granice systemu opisałem proces do powstania opisu przypadków użycia. Mamy za sobą podstawową pracę z dziedziny jaką jest analiza systemowa. Postawiliśmy problem do rozwiązania: jakie oprogramowanie powinno powstać. Pod pojęciem jakie należy rozumieć: co powinno ono robić. Opracowano model, przetestowano go. Oceniono dwa warianty (w dużym skrócie ;)), w drugim wariancie obsługa płatności została zlecona partnerowi (outsourcing) i podjęto racjonalną decyzje o wyborze tego wariantu.

Po tej decyzji mamy zamknięty zakres wymagań: system ma rejestrować zamówienia  i pozwalać na natychmiastowe dokonanie płatności. Wiemy także, że nasz system jest częścią większej całości. Outsourcing to decyzja hipotetycznego sponsora projektu na bazie otrzymanych informacji. Koniec analizy biznesowej.

Pora iść dalej. Tym razem problem brzmi: kto i w jakiej technologii ma wykonać to oprogramowanie. Znowu przydały by się warianty czyli różne oferty wykonania tego oprogramowania. Czego nam brakuje by oferty były porównywalne? Modelu tego co należy wykonać! Czy można jako element takiego zapytania dać model przypadków użycia?  Z jednej strony można powiedzieć, że owszem. W końcu mamy dokładny opis tego, jakimi cechami (funkcjonalności) ma się charakteryzować to co otrzymamy.  I robi tak większość firm. Gdzie widzę kłopot? Zapewne część czytelników zauważyła już, że pominąłem wymagania poza-funkcjonalne.

Dygresja budowlana – pouczająca przygoda

Wyobraźmy sobie, że chcemy zlecić budowę domu. Jego funkcjonalności to między innymi: oddzielne miejsca do spania oraz czytania i oglądania telewizji (tak zwany salon). Kuchnia złączona z salonem. Łazienka na każdym piętrze. Wejście z zewnątrz do salonu poprzez mały przedpokój. Garaż połączony z przedpokojem. I jeszcze wiele innych. Wymagania poza-funkcjonalne, tych może być ogrom! Dom ma być ładny, nie może być podobny do domu sąsiada, musi spełniać wymagania prawa budowlanego, kolorystyka dachu powinna być skorelowana z elewacją, bieżące koszty ogrzewania powinny być możliwie jak najniższe, dom powinien dać się w przyszłości łatwo rozbudować o dwa nowe pomieszczenia. Dom powinien być przygotowany do potencjalnej instalacji komputera w każdym pokoju. Powinno być możliwe zainstalowanie klimatyzacji w ciągu trzech lat od zakończenia inwestycji.

Taki dokument może mieć dziesiątki stron, weryfikacja jego treści (spójność, techniczna niesprzeczność, inne)  może być trudna. Opracowanie go w gronie np. czteroosobowej rodziny będzie wyzwaniem już tylko w kategoriach negocjacji ;).  Żeby zabezpieczyć się przed “interpretacją” wykonawcy dokument będzie obrastał w szczegóły, ale takie o których pomyślą autorzy dokumentu: rodzina. Jakie mają w tym doświadczenie? Większość tych oczekiwań to własnie poza funkcjonalne życzenia!.

Jak uniknąć tej benedyktyńskiej pracy, której ryzyko rośnie wraz z rozrostem dokumentu? Idziemy do architekta. Nasza rodzina idzie do architekta, ten na bazie powyższych opowieści doprowadza do jakiejś koncepcji rozwiązania (projekt wstępny, koncepcyjny). W momentach sporu pełni role mediatora (łazienka ma być przy salonie czy przy pokoju dzieci), pokazuje na modelu (projekt koncepcyjny, który ewoluuje w trakcie takiej rozmowy) wady i zalety obu rozwiązań, pozwala rodzinie podjąć świadomą decyzje. Zaletą wizyty u architekta, zanim zapytamy jakiegokolwiek developera, jest to, że architekt jest wolny od jakichkolwiek uprzedzeń czy przyzwyczajeń. W każdej dziedzinie inżynierii wykonawcy są wyspecjalizowani, jeśli damy im wybór, będą stosowali technologie najmniej ryzykowne dla siebie (najlepiej poznane) a nie optymalne dla inwestora i to jest oczywiste.

Dlatego warto najpierw iść do architekta, ten nieskażony technologiami (bo nie ma w tym żadnego interesu), opracuje nam projekt funkcjonalny, ale zawierający pewne szczegóły rozwiązań (np. zabroni budowy betonowej ściany w miejscu gdzie my oczekujemy przyszłej rozbudowy).  Popatrzymy na coś, co potrafimy szybko ocenić nie tylko od strony wymagań funkcjonalnych (muszla pod półką spełnia stawiane jej wymagania ale czy jest to wygodne?) Na projekcie od razu wychwycimy, czego w tekście opisu raczej nigdy: elementy estetyki, wygody, podjęte kompromisy będą dla wszystkich zrozumiałe i nie będą w przyszłości podważane.

Diagram klas czy model dziedziny – co ma powstać?

Otóż [[diagram klas]] ([[UML]]) to narzędzie podobne do rysunku technicznego. Ważne jest to co on przedstawia i to należy najpierw zdefiniować (dopóki nie wiem czy mam napisać: książkę czy rozdział podręcznika, nie wiem co mam w tym języku wyrazić). Tak więc coś należy założyć. Podstawowym założeniem jakie tu przyjmę jest: nie tworzymy oprogramowania od zera. A wiec od czego? Wiele firm programistycznych używa gotowych szkieletów oprogramowania, tak zwanych [[framework]]ów. Są to gotowe, najczęściej dziedzinowe (adresowane dla konkretnej dziedziny zastosowań) biblioteki podprogramów (klas w technologiach obiektowych).

Obejmują zazwyczaj typowe,uniwersalne funkcjonalności takie jak logowanie, wyświetlanie treści na ekranie, zapis do bazy danych (a tak na prawdę utrwalanie, bo baza danych to nie jedyny sposób) , sterowanie zachowaniem się aplikacji, elementy bezpieczeństwa i wiele innych. Funkcjonalności większości biznesowych aplikacji można podzielić na trzy grupy: sterowanie programem, obsługa interfejsu użytkownika oraz funkcjonalności specyficzne dla dziedziny (miejsca) zastosowania. Mamy więc dziedzinę problemu, interfejs użytkownika i sterowanie całością. Innymi słowy mamy: Model, View (widoki), Controller (sterowanie) czyli najpopularniejszy obiektowy wzorzec projektowy aplikacji o wdzięcznej nazwie [[MVC]].

Wniosek z tego taki, że jeśli założymy, że taki szkielet zostanie użyty (a możemy to zapisać w wymaganiach poza-funkcjonalnych dla wykonawcy) to pozostaje po zakończonej analizie biznesowej dokonać analizy obiektowej i zaprojektować [[model dziedziny systemu]]. Narzędziem do jego pokazania jest właśnie diagram klas notacji UML.

Model dziedziny systemu Zamówienia

Tak więc wszystko jasne 🙂 wiec do roboty. Pierwszy etap to opracowanie listy obiektów biznesowych. Tu wkracza kolejna metoda, która stosuję: obiekty dzielimy na narzędzia i przedmioty przetwarzane z pomocą tych narzędzi, pamiętamy, że tego wszystkiego ktoś używa: nasz aktor. Prosty przykład: Do wystawienia faktury potrzebne są: formularz faktury (oczywiste) i fakturzysta (ktoś musi wiedzieć co należy zrobić). Pierwszy stopień innowacji: kalkulator dla fakturzysty. Kolejny stopień to elektroniczny formularz. Obiekty biznesowe: wzór formularza faktury, kalkulator, fakturzysta oraz oczywiście kuwetka na wystawione faktury. Dlaczego tak?

Kolejna metoda analizy i projektowania powiązana z wzorcem MVC: [[Domain Driven Design]] (projektowanie oprogramowania bazujące na modelu dziedziny systemu) czyli DDD. O co tu chodzi? Ogólnie o to by projektować oprogramowanie dość wiernie symulując (a raczej odwzorowując) poznaną rzeczywistość. Dlaczego? Bo osiągamy bardzo ważną korzyść: nawet jeżeli nie uda nam się odkryć sensu istnienia jakiegoś obiektu, mimo wszystko modelujemy go bez uproszczeń, dzięki temu w przyszłości, rozwijając system,  nie nadziejemy się na problem wywołany takim uproszczeniem gdyż takie początkowe uproszczenie staje się nie raz poważnym ograniczeniem. Druga zaleta: model taki jest relatywnie łatwiejszy do percepcji niż model z uproszczeniami, w szczególności totalnie niestrawny dla zwykłych ludzi (czyta: nieweryfikowalny przez zamawiającego) [[model relacyjny w trzeciej postaci normalnej]]. Tu bardzo przepraszam czytelników biznesowych, że użyłem niezrozumiałych zapewne dla nich pojęć, ale to właśnie pokazuje, że na tym etapie zamawiający traci kontakt (zrozumienie) z wykonawca tego co sam zamówił zamawiający.

Z modelu procesu dowiadujemy się, że następujące obiekty biorą udział w realizacji potrzebnych nam funkcjonalności: Formularz Zamówienia i koniec! Na pewno? Nie 🙂 bo chcemy by jednak by był to automatyczny system internetowy, wiec potrzebny jest Zarządca. On wie: jak przyjmować Zamówienia oraz skąd brać dane i gdzie je wysyłać. Klient (zamawiający) jest tu aktorem i nie jest on absolutnie obiektem biznesowym do implementacji. Mamy więc dwa obiekty biznesowe: Zarządca i FormularzZamówienia. Do tego mamy interfejsy dla ERP i do Płatności. A gdzie baza danych? Nie ma! Co robić? Wiem! Kuwetka :), potrzebna mi kuwetka. Baza danych to dla biznesu słowo obrzydliwe i nie używamy go. Mamy więc: Zarządca, Kuwetka, FormularzZamówienia, …. aaaaaaaa, a same Zamówienia? :). Komplet:

1. FormularzZamówienia
2. GeneratorDruczków
3. Kuwetka
4. Zarządca
5. Zamówienia

Nie zapominamy, że mamy Framework i interfejsy (ERP i Płatności). Pojawił się jeszcze GeneratorDruczków. Skąd się wziął? Kolejna metoda projektowania: [[Role, odpowiedzialność, współpraca]]. Otóż, warto Zarządcę zwolnić z obowiązku posiadania wiedzy o aktualnych wzorach dokumentów. Te wiedzę o aktualnie stosowanych wzorach dokumentów  (i rolę) posiada GeneratorDruczków. I mógł by ktoś powiedzieć, że niepotrzebnie komplikuje program. Owszem, skomplikował się. Jeśli jednak w programie pojawią się kiedyś nowe funkcjonalności, inni Zarządcy, wszyscy będą pobierali druczki z jednego miejsca bez zastanawiania się czy są właściwe bo mamy tylko jedno ich źródło, które odpowiada za to by zawsze były właściwe.

Jak wygląda diagram klas:

Tak więc co my tu mamy, po kolei: Klient (nasz aktor) kontaktuje się wyłącznie z Zarządcą, który go obsługuje. Zarządca korzysta z usług GeneratoraDruczków, Kuwetki, zewnętrznych systemów poprzez interfejsy. Koniec. Co dalej? Ano wypadało by pokazać jak Zarządca, zdaniem projektanta (:)) realizuje nasz przypadek użycia. Na potrzeby usystematyzowania projektu przytocze jeszcze raz scenariusz w firmie troszkę sformalizowanej:

Taka postać scenariusza (dialog) pozwala upewnić się, że zamawiający i projektant myślą tak samo. Mały komentarz: Klient ma przed sobą Ekran Startowy i wybiera opcję (polecenie) Nowe Zamówienie. System pyta o NIP, Klient wpisuje NIP i potwierdza. Możliwe jest nie wpisanie NIP. System wyświetla formatkę nowego zamówienia. Formatka ma wypełnione dane Zamawiającego lub nie, jeśli nie podano NIPu albo nie znaleziono go na liście kontrahentów. Klient wprowadza dane poprzez zaznaczenie tego co chce zamówić, wpisuje ilości itp. na koniec potwierdza. System sprawdza i wyświetla kompletne zmówienie. Klient zatwierdza lub rezygnuje (pominąłem, ewentualną edycję dla uproszczenia, jeżeli firma oferuje tysiące produktów także będzie inaczej :)).

W tym momencie Klient ma jedno lub więcej zamówień do opłacenia, w kolejnym przypadku użycia może zaznaczyć zamówienia do opłacenia i wybrać opcję Inicjacja Płatności, System przygotuje niezbędne dane i przekaże sterowanie do Systemu obsługi Płatności. Nie będzie tu tego opisu, celem artykułu jest pokazanie metody a nie wykonanie kompletnego projektu.

Powyższy scenariusz posłuży teraz do przetestowania i uzupełnienia modelu dziedziny i uzupełnienia go (ten etap nazywany jest często proof-of-concept). Narzędziem do testowania będzie diagram sekwencji.

Samo wykonanie diagramu pozwala na sprawdzenie poprawności pomysłu i jego logiki oraz od razu daje nam możliwość weryfikacji atrybutów i operacji. Po tym teście (opracowanie tego diagramu jest testem koncepcji) uzupełniamy model dziedziny o atrybuty i operacje. Diagram klas to statyczny opis, który sam z siebie niczego nie mówi o współpracy obiektów. Jego poprawna interpretacja  (nie licząc systemu pojęć) jest niemożliwa bez tego modelu dynamiki (diagram sekwencji to model dynamiki systemu). Zaryzykował bym nawet tezę, że sam diagram klas nie niesie prawie żadnej informacji wykonawcy.

Model dziedziny wzbogacił się:

Podsumowanie

Przytoczę ponownie cytowany diagram klas:

Powyższy diagram w moim mniemaniu jest raczej pewnym modelem pojęciowym. Bez kilku słów o metodyce projektowania trudno go w ogóle oceniać dlatego pokazałem swój diagram klas, i sposób w jaki powstał. Kluczowe różnice:

1. W moim modelu typ płatności będzie atrybutem Zamówienia
2. Obiekt Zamówienie, poza zawartością druku zamówienia, obsługuje także inne dodatkowe zadania (pamiętanie o sposobie płatności, przygotowanie serializacji XML do “wsadzenia” obiektu do ERP, może coś jeszcze…)
3. Klient w ogóle się nie pojawia, chyba już wiadomo dlaczego…
4. Pozycja zamówienia została “ukryta” w zamówieniu, zależnie od koncepcji były by to elementy agregatu (pozycjezamówienia u mnie były by w relacji kompozycji do obiektu bazowego DrukZamówienia), nie ma klasy Produkt (magazyn), jest to obiekt za który odpowiada system ERP.
5. U mnie pojawia się Kuwetka, obiekt odpowiedzialny za składowanie Zamówień, pytania o konkretne Zamówienie, ostatnie zamówienie, zestawienie zamówień za okres to potencjalne operacje obiektu Kuwetka.
6. Pojawia się także Zarządca, obiekt odpowiedzialny za obsługę przypadku użycia (byc może także innych). Na diagramie sekwencji pojawiła się klasa System obsługi…jest to abstrakcja elementu View wzorca MVC.

Powyższy projekt jest bardzo uproszczony i na pewno ma wiele wad, kilka iteracji projektowania i testów warto by jeszcze przeprowadzić. Celem moim jednak było pokazanie samej metody analizy i projektowania, tego do czego można użyć notacji UML. Pokazać, że można zaprojektować logikę oprogramowania i ją przetestować nie pisząc nawet linijki kodu.

Na koniec chciałem pokazać, że w projektach dedykowanych, jeżeli jest nawet cień ryzyka, że wykonawca będzie błądził realizując nasz projekt (nie oczekujmy od programistów, że będą znali i rozumieli naszą firmę, nie taka jest ich rola) warto wykonać taki właśnie projekt. Po pierwsze przetestujemy nasze życzenia, po drugie powstanie materiał, na bazie którego kilku wykonawców dokona wyceny z niewielkim błędem i bez dużych narzutów na niespodzianki. Czy takie projekty robią developerzy? Ich o to pytajcie. Czy ma to sens? Testowanie diagramów jest co najmniej o rząd wielkości tańsze niż testowanie prototypów przez programistów.

Kto powinien opracować taki projekt? Osobiście uważam, że nie powinien to być wykonawca projektu. Powodem jest po pierwsze to, o czym wspomniałem: każdy się specjalizuje w jakiejś jednej technologii. Po drugie w przypadku jakichkolwiek problemów Zamawiający, jako niespecjalista, nie ma żadnej możliwości merytorycznej oceny wykonawcy, nawet gdyby był szkodliwy dla zamawiającego. Nie twierdzę, że wszyscy developerzy to niekompetentni naciągacze ale też nie dam głowy, że takich nie ma. Sugeruję naśladowanie rynku budowlanego: zarządzanie ryzykiem czyli oddzielenie projektowania od wykonania.

Developer także odnosi tu pewną korzyść: jest zwolniony z odpowiedzialności i posądzania go o kombinowanie, zyskuje dodatkowo mediatora pomiędzy sobą i zamawiającym. Minus jest taki, że wynagrodzenie za analizę i projekt nie wpłynie do jego kieszeni ale cóż… to koszt komfortu pracy ale z reguły nie przekracza on 10-20% budżetu na powstanie oprogramowania.

Podsumowanie drugie

Czy to ma sens w przypadku gotowych ERP? Moim zdaniem:

1. Ingerencja (tak zwana kastomizacja) w gotowe oprogramowanie ERP kończy się bardzo często destabilizacją pierwotnie dobrego oprogramowania.
2. Jeżeli system ERP jest zamknięta bryłą (z reguły świadczy o tym fakt pracy na relacyjnej, znormalizowanej bazie danych) nie warto go kastromizować bo to kosztowny i bardzo ryzykowny proces, do tego pozbawiamy się możliwości prostego jego upgrade’owania.

Brakujące w firmie funkcjonalności lepiej tworzyć osobno, jako dedykowane projekty bo to po pierwsze chroni inwestycję w ERP, po drugie z reguły kosztuje znacznie mniej i znacznie szybciej jest gotowe do użycia (stworzenie małego oprogramowanie jest dużo prostsze niż modyfikacja dużego). Po drugie pojawiają się już systemy ERP mające strukturę własnie szkieletu opartego na wzorcu MVC i zaprojektowanie nowej funkcjonalności polega na analizie i projektowaniu takim jak wyżej opisane, z tą różnicą że implementacja ma miejsce w środowisku tego ERP a nie w środowisku odrębnego narzędzia programistycznego. Tak więc, paradoksalnie,

powyższe analiza i projektowanie powinny być zawsze pierwszym etapem projektu programistycznego niezależnie od tego  czy ma powstać nowe oprogramowanie czy tylko nowe funkcjonalności do istniejącego.

A gdzie się podziały wymagania pozafunkcjonalne?

Generalnie w mojej metodyce są one ograniczeniami dokumentowanymi dla każdego przypadku użycia indywidualnie. Powstaje repozytorium ograniczeń i mapowanie ich na przypadki użycia. Bardzo restrykcyjne ograniczenia (np. wysoka dostępność) mogą być wydzielone z ich przypadkami użycia do osobnego podsystemu i implementowane nawet na osobnej platformie jeśli taka będzie potrzeba związana z rentownością. To jednak temat na osobny artykuł :).

Konkluzja biznesowa: Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi  w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.