Analiza procesowa, a obiektowa czyli niedopasowanie oporu

Katgoria: IT SOLUTIONS / Utworzono: 19 czerwiec 2013

Analiza procesowa, a obiektowa czyli niedopasowanie oporu

Swego czasu w artykule o Wścipskim Analityku uzasadniałem potrzebę panowania nad wymaganiami od momentu pojawienia się potrzeby biznesowej aż do implementacji. Nie znaczy to absolutnie, że analityk ma programować, znaczy to jednak, że analityk powinien dokumentować to czego żąda w wymaganiach.

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 obiekty czyli struktury łączące dane i metody ich przetwarzania. 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! 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ść.

Na zakończenie, poniższy „potwór” (przykładów nie tylko w sieci, na pęczki) nie ma nic wspólnego z obiektowym paradygmatem, to typowy przykład strukturalnego (a nie obiektowego) projektowania w UML (użycie notacji UML bez błędów składni nie czyni tego projektu obiektowym, to bardzo zły projekt obiektowy, być może poprawny diagram UML):

Źródło: IT-Consulting
Autor: Jarosław Zieliński

Najnowsze wiadomości

Europejski przemysł cyfryzuje się zbyt wolno – ERP, chmura i AI stają się koniecznością

Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.

Czytaj całość

Nowa era komunikacji biznesowej, KSeF stał się faktem

Od 1 lutego 2026 roku, w Polsce z sukcesem rozpoczęła się nowa era elektronicznej komunikacji w biznesie. Od tego dnia przedsiębiorcy zaczynają posługiwać się wspólnym standardem we wzajemnej wymianie dokumentów – fakturą ustrukturyzowaną, znaną jako FA(3) lub po prostu faktura KSeF.

Czytaj całość

Smart Factory w skali globalnej: jak MOWI porządkuje produkcję dzięki danym w czasie rzeczywistym

Cyfryzacja produkcji w skali globalnej wymaga dziś spójnych danych, jednolitych standardów i decyzji podejmowanych w czasie rzeczywistym. W środowisku rozproszonych zakładów produkcyjnych tradycyjne raportowanie i lokalne narzędzia IT przestają wystarczać. Przykład MOWI pokazuje, jak wdrożenie rozwiązań Smart Factory i systemu MES może uporządkować zarządzanie produkcją w wielu lokalizacjach jednocześnie, zwiększając przejrzystość procesów, efektywność operacyjną oraz stabilność jakości.

Czytaj całość

Hakerzy nie kradną już tylko haseł. Oni kradną Twój czas i przyszłość. Jak chronić ERP przed paraliżem?

Hakerzy coraz rzadziej koncentrują się wyłącznie na kradzieży haseł. Ich prawdziwym celem jest dziś sparaliżowanie kluczowych systemów biznesowych, przejęcie kontroli nad danymi i wymuszenie kosztownych decyzji pod presją czasu. System ERP, jako centralny punkt zarządzania finansami, produkcją i logistyką, stał się dla cyberprzestępców najbardziej atrakcyjnym celem. Ten artykuł pokazuje, dlaczego tradycyjne zabezpieczenia przestają wystarczać i jak realnie chronić ERP przed atakami, które mogą zatrzymać firmę z dnia na dzień.

Czytaj całość

PSI automatyzuje logistykę Rossmanna: Wdrożenie WMS i MFC w Czechach

Nowoczesne centrum logistyczne Rossmann w Czechach to przykład, jak strategiczne inwestycje w automatykę i systemy IT wspierają skalowanie biznesu w handlu detalicznym. Projekt realizowany przez PSI Polska obejmuje wdrożenie zaawansowanego systemu WMS oraz sterowania przepływem materiałów, tworząc w pełni zintegrowane środowisko dla obsługi rosnących wolumenów sprzedaży i dynamicznego rozwoju e-commerce. To wdrożenie pokazuje, jak technologia staje się fundamentem efektywnej, przyszłościowej logistyki.

Czytaj całość

RAPORT ERP

Katalog rozwiązań IT

Katalog firm

Najnowsze artykuły

Magazyn bez błędów? Sprawdź, jak system WMS zmienia codzienność logistyki

Współczesna logistyka wymaga nie tylko szybkości działania, lecz także maksymalnej precyzji – to właśnie te czynniki coraz częściej decydują o przewadze konkurencyjnej firm. Nawet drobne pomyłki w ewidencji stanów magazynowych, błędy przy przyjmowaniu dostaw czy nieprawidłowe rozmieszczenie towarów, mogą skutkować poważnymi stratami finansowymi i opóźnieniami w realizacji zamówień. W jaki sposób nowoczesne rozwiązania do zarządzania pomagają unikać takich sytuacji? Czym właściwie różni się tradycyjny system magazynowy od zaawansowanych rozwiązań klasy WMS (ang. Warehouse Management System)? I w jaki sposób inteligentne zarządzanie procesami magazynowymi realnie usprawnia codzienną pracę setek firm?

Czytaj całość

Jak maksymalizować zyski z MTO i MTS dzięki BPSC ERP?

Zysk przedsiębiorstwa produkcyjnego zależy nie tylko od wydajności maszyn, ale przede wszystkim od precyzyjnego planowania, realnych danych i umiejętnego zarządzania procesami. Dlatego firmy, które chcą skutecznie działać zarówno w modelu Make to Stock (MTS), jak i Make to Order (MTO), coraz częściej sięgają po rozwiązania klasy ERP, takie jak BPSC ERP.

Czytaj całość

Warsztaty analityczne i sesja discovery. Jak wygląda pierwszy etap współpracy z partnerem wdrożeniowym ERP

Wdrożenie systemu ERP to jedna z najważniejszych strategicznych decyzji, jakie może podjąć firma. To inwestycja, która ma zrewolucjonizować procesy, zwiększyć efektywność i dać przewagę konkurencyjną. Jednak droga do sukcesu jest pełna potencjalnych pułapek. Wielu menedżerów obawia się nieprzewidzianych kosztów, oporu zespołu czy niedopasowania systemu do realnych potrzeb. Jak zminimalizować to ryzyko? Kluczem jest solidne przygotowanie. Zanim padnie słowo „wdrażamy”, konieczne jest przeprowadzenie trzech fundamentalnych etapów: warsztatów analitycznych, sesji discovery oraz analizy przedwdrożeniowej ERP. To nie są zbędne formalności, ale fundament, na którym zbudujesz sukces całego projektu.

Czytaj całość

Strategia migracji danych do nowego systemu ERP. Metody, ryzyka i najlepsze praktyki

Wdrożenie nowego systemu ERP to dla wielu firm nie tylko krok w stronę unowocześnienia procesów biznesowych, ale także ogromne przedsięwzięcie logistyczne i technologiczne. Aby nowy system ERP zaczął efektywnie wspierać działalność organizacji, kluczowe jest odpowiednie przygotowanie danych, które muszą zostać bezpiecznie i precyzyjnie przeniesione ze starego systemu. Migracja danych ERP to skomplikowany proces, wymagający zarówno zaawansowanej wiedzy technologicznej, jak i dokładnego planowania na poziomie strategicznym. W tym artykule przybliżymy najlepsze metody, wskażemy najczęstsze ryzyka oraz podpowiemy, jak przeprowadzić migrację krok po kroku.

Czytaj całość

Strategiczna przewaga czy kosztowny mit? Kto wygrywa dzięki chmurze?

Chmura miała być odpowiedzią na wyzwania sektora finansowego: przestarzałą infrastrukturę, rozproszone dane, rosnące oczekiwania klientów i klientek. Dziś korzysta z niej już 91% instytucji, a mimo to tylko nieliczne mówią o realnych efektach. Zaledwie 12% firm maksymalizuje potencjał chmury – tworzy skalowalne platformy, wdraża GenAI, monetyzuje dane. Reszta? Często grzęźnie w kosztach, integracjach i braku kompetencji. Różnica nie tkwi w technologii, ale w strategii – i to ona może zadecydować o miejscu w sektorze, który właśnie wchodzi w kolejną fazę transformacji.

Czytaj całość