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

Kwantowy przełom w cyberochronie - nadchodząca dekada przepisze zasady szyfrowania na nowo

Przez długi czas cyfrowe bezpieczeństwo opierało się na prostym założeniu: współczesne komputery potrzebowałyby ogromnych zasobów i wielu lat, aby złamać silne algorytmy szyfrowania. Rozwój technologii kwantowej zaczyna jednak tę regułę podważać, a eksperci przewidują, że w perspektywie 5–10 lat może nadejść „dzień zero”. Jest to moment, w którym zaawansowana maszyna kwantowa będzie w stanie przełamać większość aktualnie stosowanych zabezpieczeń kryptograficznych w czasie liczonym nie w latach, lecz w godzinach.

Czytaj całość

PSI prezentuje nową identyfikację wizualną

W ramach realizowanej strategii transformacji PSI Software SE zaprezentowała nową identyfikację wizualną. Odświeżony wizerunek w spójny sposób oddaje technologiczne zaawansowanie firmy, jej głęboką wiedzę branżową oraz silne ukierunkowanie na potrzeby klientów. Zmiany te wzmacniają pozycję PSI jako innowacyjnego lidera technologicznego w obszarze skalowalnych rozwiązań informatycznych opartych na sztucznej inteligencji i chmurze, rozwijanych z myślą o energetyce i przemyśle.

Czytaj całość

PROMAG S.A. rozpoczyna wdrożenie systemu ERP IFS Cloud we współpracy z L-Systems

PROMAG S.A., lider w obszarze intralogistyki, rozpoczął wdrożenie systemu ERP IFS Cloud, który ma wesprzeć dalszy rozwój firmy oraz integrację kluczowych procesów biznesowych. Projekt realizowany jest we współpracy z firmą L-Systems i obejmuje m.in. obszary finansów, produkcji, logistyki, projektów oraz serwisu, odpowiadając na rosnącą skalę i złożoność realizowanych przedsięwzięć.

Czytaj całość

F5 rozszerza portfolio bezpieczeństwa o narzędzia do ochrony systemów AI w środowiskach enterprise

F5 ogłosiło wprowadzenie dwóch nowych rozwiązań - F5 AI Guardrails oraz F5 AI Red Team - które mają odpowiedzieć na jedno z kluczowych wyzwań współczesnych organizacji: bezpieczne wdrażanie i eksploatację systemów sztucznej inteligencji na dużą skalę. Nowa oferta łączy ochronę działania modeli AI w czasie rzeczywistym z ofensy

Czytaj całość

Snowflake + OpenAI: AI bliżej biznesu

Snowflake przyspiesza wykorzystanie danych i sztucznej inteligencji w firmach, przenosząc AI z fazy eksperymentów do codziennych procesów biznesowych. Nowe rozwiązania w ramach AI Data Cloud integrują modele AI bezpośrednio z danymi, narzędziami deweloperskimi i warstwą semantyczną. Partnerstwo z OpenAI, agent Cortex Code, Semantic View Autopilot oraz rozwój Snowflake Postgres pokazują, jak budować skalowalne, bezpieczne i mierzalne wdrożenia AI w skali całej organizacji.

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ść

Migracja z SAP ECC na S4 HANA: Ryzyka, korzyści i alternatywne rozwiązania

W ostatnich latach wiele firm, które korzystają z systemu SAP ECC (Enterprise Central Component), stoi przed decyzją o przejściu na nowszą wersję — SAP S4 HANA. W obliczu końca wsparcia dla ECC w 2030 roku, temat ten staje się coraz bardziej aktualny. Przemiany technologiczne oraz rosnące oczekiwania związane z integracją nowych funkcji, jak sztuczna inteligencja (AI), skłaniają do refleksji nad tym, czy warto podjąć tak dużą zmianę w architekturze systemu. Przyjrzyjmy się głównym powodom, dla których firmy rozważają migrację do S4 HANA, ale także argumentom, które mogą przemawiać za pozostaniem przy dotychczasowym systemie ECC, przynajmniej na krótki okres.

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ść

Ponad połowa cyberataków zaczyna się od błędu człowieka

Ponad 2/3 firm w Polsce odnotowała w zeszłym roku co najmniej 1 incydent naruszenia bezpieczeństwa . Według danych Unit 42, zespołu analitycznego Palo Alto Networks, aż 60% ataków rozpoczyna się od działań wymierzonych w pracowników – najczęściej pod postacią phishingu i innych form inżynierii społecznej . To pokazuje, że w systemie ochrony organizacji pracownicy są kluczowym ogniwem – i że firmy muszą nie tylko edukować, ale też konsekwentnie egzekwować zasady cyberhigieny. Warto o tym pamiętać szczególnie teraz, w październiku, gdy obchodzimy Europejski Miesiąc Cyberbezpieczeństwa.

Czytaj całość

MES - holistyczne zarządzanie produkcją

Nowoczesna produkcja wymaga precyzji, szybkości i pełnej kontroli nad przebiegiem procesów. Rosnąca złożoność zleceń oraz presja kosztowa sprawiają, że ręczne raportowanie i intuicyjne zarządzanie coraz częściej okazują się niewystarczające. Firmy szukają rozwiązań, które umożliwiają im widzenie produkcji „na żywo”, a nie z opóźnieniem kilku godzin czy dni. W tym kontekście kluczową rolę odgrywają narzędzia, które porządkują informacje i pozwalają reagować natychmiast, zamiast po fakcie.

Czytaj całość