Wprowadzenie

Jednym z podstawowych problemów w projektach związanych z systemami informacyjnymi, jest komunikacja z ekspertami dziedzinowymi sponsora projektu. Osoby te stanowią podstawowe źródło informacji i są także kluczowymi recenzentami powstającej dokumentacji: potwierdzają, że analityk i projektant zrozumiał dziedzinę problemu.

Sformalizowane systemy notacyjne są niejednokrotnie dość bogate w symbole, te zaś dla większości ludzi są mało intuicyjne, a ich formalizm bywa niezrozumiały. W efekcie analitycy i projektanci albo prowadzą szkolenia przygotowujące zespoły projektowe do projektu albo uciekają się do stosowania łatwo przyswajalnych nieformalnych schematów blokowych. Obie drogi stwarzają ryzyko w projekcie. Pierwsza podnosi koszty projektu, a czasami powoduje także frustrację zespołu adresata dokumentów projektowych. Druga droga bardzo szybko prowadzi do wielu niejednoznaczności i niespójności (nieformalne schematy blokowe nie poddają się żadnej kontroli poprawności, w większych projektach niejednoznaczność, niespójność i niekompletność dokumentacji stają się główną przyczyną niepowodzeń).

W projektach analizy biznesowej i inżynierii oprogramowania mamy lukę między notacjami BPMN i UML, a jest nią specyfikacja logiki przetwarzania informacji. W notacji BPMN (analityczne modele procesów biznesowych) praktycznie nie ma na nią miejsca (Obiekt Danych jedynie symbolizuje dokument jako produkt pracy), zaś w notacji UML jest ona już głęboko ukryta w postaci atrybutów i metod operacji klas.

Uważam, że należy wykorzystywać istniejący dorobek każdej dziedziny wiedzy. Tak więc, zanim zaproponujmy tworzenie kolejnego systemu notacyjnego (lub komplikowanie istniejącego), warto się upewnić, że jest to konieczne (brzytwa Ockhama w nauce).

W tym artykule podejmuje próbę rozwiązania tego problemu z pomocą diagramów DFD (diagram przepływu danych, ang.. DataFlow Diagram). Diagramy te to narzędzie pochodzące z czasów stosowania metod strukturalnych w analizie i projektowaniu (lata 70-te XX wieku).

Diagram przepływu danych (DFD)

W 2017 roku, przy nieco innej okazji, pisałem:

Metody struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia bazu­ją na uzna­niu, że opro­gra­mo­wa­nie to stos funk­cji ope­ru­ją­cych na bazach (skła­dach) danych. Innymi sło­wy pod­sta­wo­we zało­że­nie to ist­nie­nie odręb­nych bytów jaki­mi są baza danych oraz funk­cje, któ­re na tych danych wyko­nu­ją ope­ra­cje. W meto­dach struk­tu­ral­nych two­rzy dwa się rodza­je mode­li: model pro­ce­su prze­twa­rza­nia i model struk­tu­ry danych. Pierwszy wyko­rzy­stu­je nota­cję DFD (Data Flow Diagram, np. nota­cja Gane?a- Sarsona) a dru­gi nota­cja ERD (Entity Relationship Diagram, np. nota­cja Martina) do mode­lo­wa­nia struk­tur rela­cyj­nych baz danych. (blog: Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania – Jarosław Żeliński IT-Consulting).

Nie namawiam tu nikogo do powrotu do strukturalnych metod analizy i projektowania. Jednak same diagramy DFD, jako system notacyjny, mają ważną zaletę: modele logiczne (są także fizyczne) są intuicyjne. To zaś powoduje, że na określonym poziomie abstrakcji sprawdzają się jako narzędzie komunikacji z ekspertami dziedzinowymi. Pozostaje tylko zdefiniowanie tego poziomu abstrakcji.

Pojęcie systemu

Dowolny system, także informacyjny, można sprowadzić do architektury składającej się trzech typów elementów: byt poza systemem oraz system, który zbudowany jest z elementów reprezentujących: interfejs (sensor, efector), procesy przetwarzania danych (operacje na danych) i repozytoria danych (pamięć) .

Istotą diagramów przepływu danych jest uproszczenie polegające na przyjęciu założenia, że model systemu to proces przetwarzania i repozytorium danych zaś jego otoczenia to określony byt zewnętrzny.

W metodach strukturalnych pojęcie 'proces’ dotyczy każdej, nawet bardzo detalicznej, operacji na danych (patrz tytuły dawnych podręczników informatyki: „algorytmy + struktury danych = programy”). Moja propozycja zastosowania modeli przepływu danych dotyczy wyłącznie poziomu, na którym operujemy wyłącznie pojęciami (nazewnictwo) z analizowanej dziedziny a modele zawierają wyłącznie nazwane biznesowe operacje i dokumenty jako nośniki danych. Cały czas chodzi wyłącznie o komunikację z ekspertami dziedzinowymi, wiec używane na tych diagramach słownictwo nie może wykraczać poza dziedzinę problemu.

Notacja Gane’a-Sarsona

Kluczowe elementy diagramów przepływu danych omówię stosując popularną notację Gane’a-Sarsona . Semantyka notacji (symbole i ich znaczenie) operuje trzema symbolami:

1. byt zewnętrzny (External Entity): jest to źródło lub adresat treści (danych) czyli zewnętrzne systemy (otoczenie systemu modelowanego),
2. proces (Process): miejsce (metoda) przetwarzania treści (danych) czyli element realizujący logikę działania systemu,
3. repozytorium (Data Store): miejsce przechowywania treści (danych) czyli pamięć systemu,
4. jednostka danych (Note, treść przekazywana): treść (zestaw danych).

Syntaktyka notacji jest także prosta, obowiązuje jedna zasada: w przekazywaniu danych z miejsca w miejsce zawsze pośredniczy proces. Graficznie przedstawia to diagram:

Przykłady niepoprawnych (po lewej stronie) i poprawnych (po prawej) konstrukcji:

W opisywanej tu metodzie, Data Stor (repozytorium) reprezentuje zbiór dokumentów, te zaś traktujemy tu 'obiektowo’ jako dokumenty (pojedynczy klasyfikator lub agregat w notacji UML, w metodach strukturalnych dane przechowywane są relacyjnych bazach). Pojęcie Proces na diagramach DFD utożsamiamy z kompletną operacją na dokumencie lub jego części (na danych). W ten sposób uzyskujemy zgodność pojęć Proces i Data Stor odpowiednio z pojęciami Operacja i Repozytorium w notacji UML i wzorcu projektowym DDD (Domain Driven Design )

Kontekst użycia diagramów DFD

Istotą użycia diagramów DFD jest dialog z dziedzinowym ekspertem, który jest beneficjentem projektu dostarczenia oprogramowania. Jak już wspominałem, poszczególne notacje (nie raz opisywane na tym blogu) to specjalizowane systemy pojęciowe. Specjalizowane dla konkretnych etapów projektu i dziedziny (obszaru) modelowania. Spotykam się nie raz z próbami tworzenia własnych, uniwersalnych „super notacji” do wszystkiego lub tak zwanym przeciążaniem (nadużywaniem i niewłaściwym użyciem) istniejących notacji (uważam, że notacja ArchiMate jest tego przykładem).

Kiedy można użyć notacji DFD? Proces od rozpoczęcia analizy do dostarczenia oprogramowania to:

1. analiza tekstów dziedzinowych (materiały źródłowe)
2. opracowanie modeli procesów biznesowych organizacji analizowanej (notacja BPMN),
3. opracowanie zakresu projektu dostarczenia oprogramowania (notacja UML, diagram przypadków użycia),
4. opracowanie logiki działania aplikacji (notacja DFD, zestaw modeli w notacji UML).
5. opracowanie dokumentu Specyfikacja Wymagań (Opis Przedmiotu Zamówienia, Opis Techniczny Rozwiązania),
6. Odebranie i wdrożenie oprogramowania (Aplikacja).

Schematycznie pokazano to na diagramie poniżej:

Wszystko jest 'w tle’ (nie pokazano na diagramie) uzupełnione biznesowym słownikiem pojęć i reguł..

Stosowanie sformalizowanych notacji daje nam narzędzie do kontroli spójności, poprawności i kompletności całego projektu: projekt może być (a nawet dobrze by było aby był) w całości prowadzony i dokumentowany z użyciem narzędzi CASE (a nie prostymi narzędziami biurowymi takimi jak edytor tekstu czy arkusz kalkulacyjny). Dobór notacji daje nam możliwość skutecznej, z użyciem dziedzinowego słownictwa, komunikacji z kluczowymi aktorami: Beneficjent oraz Dostawca.

Diagram DFD pełni rolę abstrakcji systemu. Jest (powinien być) zrozumiały dla Beneficjenta i dla Dostawcy gotowego oprogramowania. Jeżeli dostępne na rynku istniejące oprogramowanie nie spełnia (wszystkich) wymagań (nie realizuje wszystkich potrzebnych operacji na dokumentach i ich treści), powstaje dodatkowy projekt architektury (model dziedziny systemu) z użyciem notacji UML i na jego podstawie zamawiane jest dedykowane oprogramowanie.

Harmonizacja notacji

Jak widać na powyższym diagramie, użytych zostało kilka notacji. W inżynierii jest to, wbrew pozorom, dość powszechne zjawisko. To co nazywamy popularnie 'rysunkiem technicznym’ to schematy blokowe. Zależnie od etapu projektowania i branży, używane są różne dziedzinowe systemy pojęciowe i biblioteki symboli opisane normami ISO/IEEE. Zapewniam, że używanie kilku notacji w jednym projekcie nie jest absolutnie żadnym ewenementem w inżynierii. Istotne jest zapewnienie spójności całości dokumentacji.

Poglądowo opisana harmonizacja pojęć i notacji:

1. analiza tekstów źródłowych (materiałów) prowadzi do powstania modeli procesów biznesowych, słownika pojęć, specyfikacji dokumentów, identyfikacji reguł biznesowych (notacje BPMN oraz SBVR),
2. elementarny proces biznesowy to zadanie (atomowa/elementarna aktywność) zwieńczone produktem (wyjście procesu: zestaw danych zebranych jako dokument), (BPMN)
3. zadanie to jedna lub więcej operacji na danych objętych jednym dokumentem (BPMN),
4. uzgodnienie z zamawiającym zakresu projektu (co system ma robić) prowadzi do powstania diagramu przypadków użycia UML (model systemu jako czarna skrzynka),
5. dla zakresu projektu powstaje opis logiki biznesowej jako lista dokumentów oraz operacji na nich i metod wykonania tych operacji w postaci modelu przepływu danych (DFD), model systemu jako biała skrzynka,
6. operacje na danych są wykonywane wg. określonej metody (np. algorytm) (różne formy: wzory matematyczne, procedury, diagramy aktywności UML, inne),
7. jeżeli ma powstać dedykowane oprogramowanie, należy zaprojektować jego architekturę (model PIM UML), czyli podzielić system na komponenty i każdemu z nich przyporządkować opisane operacje na dokumentach i danych jakie ma wykonywać, model systemu jako biała skrzynka.

Nadal aktualne zastosowania czyli hurtownie danych i raportowanie

Diagramy DFD znajdują nadal – polecam – zastosowanie w projektowaniu systemów raportowania, a konkretnie do analizy i modelowania zasilania systemów raportowych takich jak hurtownie danych. Poniżej typowa sekwencja:

Po lewej stronie mamy różne źródła danych: typowe bazy danych, pliki np. CSV, inne źródła (arkusze kalkulacyjne itp.). Pierwszy etap to normalizacja tych danych. Polega on na opracowanie wspólnego słownika definicji pojęć i metadanych (master data) i przekształceniu danych źródłowych do jednej, ustalonej postaci i formatu (Pobranie i normalizacja). Powstają znormalizowane obrazy danych źródłowych, nie są tu jeszcze przekształcane czy przeliczane. Kolejny etap to opracowanie, na bazie potrzeb raportowych Adresata raportów, kostek analitycznych (Hurtownia danych). Mając te kostki, projektujemy proces ETL (zasilanie hurtowni, ang. extract transform load).

Mając hurtownię danych (zdenormalizowane repozytorium danych gotowe do generowania raportów) można do niej podłączyć dowolny system raportowania z tego typu danych (na diagramie powyżej oznaczony na niebiesko).

Dane (zbiory danych) modelujemy najczęściej z użyciem diagramów ER. Przekształcenia najłatwiej dokumentować jako algorytmy, np. z użyciem diagramów aktywności UML, ewentualnie z użyciem pseudokodu (jednak tego niestety raczej nie będzie rozumiał użytkownik).

Więcej o hurtowniach danych: Hurtownie danych i analizy – jak je robić?

Podsumowanie

Analiza i projektowanie to złożony proces modelowania. Utrzymanie spójności, kompletności i niesprzeczności dokumentacji zawierającej wiele schematów blokowych jest bardzo trudne, dlatego stosuje się do tego narzędzia CASE i sformalizowane notacje. Bez tego utrzymanie wymaganej jakości dokumentów w inżynierii oprogramowania graniczy z niemożliwością, lub staje się kluczowym kosztem samo w sobie (pamiętajmy, że zła dokumentacja generuje koszty wprowadzania poprawek na etapie implementacji i wdrożenia).

Opisana metoda i miejsce stosowania diagramów DFD pozawala wprowadzić formalizm do specyfikowania logiki biznesowej, jeszcze zanim zaczniemy używać notacji UML, która dla większości beneficjentów jest niezrozumiała. Stosowanie diagramów DFD wymaga jednak określenia poziomu abstrakcji oraz przyjęcia definicji pojęć operacja (proces w DFD) i metoda zgodnych z definicjami tych pojęć w notacji UML (to narzuca poziom abstrakcji dla modeli DFD).

Podobne modele, niestety chyba mniej intuicyjne w percepcji dla osób niedoświadczonych w UML , można tworzyć z użyciem diagramów aktywności :

Wybór pozostawiam czytelnikom ;).

[przykład w przygotowaniu]

Źródła