Wprowadzenie

Jednym z pod­sta­wo­wych pro­ble­mów w pro­jek­tach zwią­za­nych z sys­te­ma­mi infor­ma­cyj­ny­mi, jest komu­ni­ka­cja z eks­per­ta­mi dzie­dzi­no­wy­mi spon­so­ra pro­jek­tu. Osoby te sta­no­wią pod­sta­wo­we źró­dło infor­ma­cji i są tak­że klu­czo­wy­mi recen­zen­ta­mi powsta­ją­cej doku­men­ta­cji: potwier­dza­ją, że ana­li­tyk i pro­jek­tant zro­zu­miał dzie­dzi­nę problemu. 

Sformalizowane sys­te­my nota­cyj­ne są nie­jed­no­krot­nie dość boga­te w sym­bo­le, te zaś dla więk­szo­ści ludzi są mało intu­icyj­ne, a ich for­ma­lizm bywa nie­zro­zu­mia­ły. W efek­cie ana­li­ty­cy i pro­jek­tan­ci albo pro­wa­dzą szko­le­nia przy­go­to­wu­ją­ce zespo­ły pro­jek­to­we do pro­jek­tu albo ucie­ka­ją się do sto­so­wa­nia łatwo przy­swa­jal­nych nie­for­mal­nych sche­ma­tów blo­ko­wych. Obie dro­gi stwa­rza­ją ryzy­ko w pro­jek­cie. Pierwsza pod­no­si kosz­ty pro­jek­tu, a cza­sa­mi powo­du­je tak­że fru­stra­cję zespo­łu adre­sa­ta doku­men­tów pro­jek­to­wych. Druga dro­ga bar­dzo szyb­ko pro­wa­dzi do wie­lu nie­jed­no­znacz­no­ści i nie­spój­no­ści (nie­for­mal­ne sche­ma­ty blo­ko­we nie pod­da­ją się żad­nej kon­tro­li popraw­no­ści, w więk­szych pro­jek­tach nie­jed­no­znacz­ność, nie­spój­ność i nie­kom­plet­ność doku­men­ta­cji sta­ją się głów­ną przy­czy­ną niepowodzeń). 

W pro­jek­tach ana­li­zy biz­ne­so­wej i inży­nie­rii opro­gra­mo­wa­nia mamy lukę mię­dzy nota­cja­mi BPMN i UML, a jest nią spe­cy­fi­ka­cja logi­ki prze­twa­rza­nia infor­ma­cji. W nota­cji BPMN (ana­li­tycz­ne mode­le pro­ce­sów biz­ne­so­wych) prak­tycz­nie nie ma na nią miej­sca (Obiekt Danych jedy­nie sym­bo­li­zu­je doku­ment jako pro­dukt pra­cy), zaś w nota­cji UML jest ona już głę­bo­ko ukry­ta w posta­ci atry­bu­tów i metod ope­ra­cji klas. 

Uważam, że nale­ży wyko­rzy­sty­wać ist­nie­ją­cy doro­bek każ­dej dzie­dzi­ny wie­dzy. Tak więc, zanim zapro­po­nuj­my two­rze­nie kolej­ne­go sys­te­mu nota­cyj­ne­go (lub kom­pli­ko­wa­nie ist­nie­ją­ce­go), war­to się upew­nić, że jest to koniecz­ne (brzy­twa Ockhama w nauce). 

W tym arty­ku­le podej­mu­je pró­bę roz­wią­za­nia tego pro­ble­mu z pomo­cą dia­gra­mów DFD (dia­gram prze­pły­wu danych, ang.. DataFlow Diagram). Diagramy te to narzę­dzie pocho­dzą­ce z cza­sów sto­so­wa­nia metod struk­tu­ral­nych w ana­li­zie i pro­jek­to­wa­niu (lata 70-te XX wieku). 

Diagram przepływu danych (DFD)

W 2017 roku, przy nie­co innej oka­zji, 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 apli­ka­cji jako pierw­szy etap two­rze­nia opro­gra­mo­wa­nia – Jarosław Żeliński IT-Consulting).

Nie nama­wiam tu niko­go do powro­tu do struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia. Jednak same dia­gra­my DFD, jako sys­tem nota­cyj­ny, mają waż­ną zale­tę: mode­le logicz­ne (są tak­że fizycz­ne) są intu­icyj­ne. To zaś powo­du­je, że na okre­ślo­nym pozio­mie abs­trak­cji spraw­dza­ją się jako narzę­dzie komu­ni­ka­cji z eks­per­ta­mi dzie­dzi­no­wy­mi. Pozostaje tyl­ko zde­fi­nio­wa­nie tego pozio­mu abstrakcji. 

Pojęcie systemu

Dowolny sys­tem, tak­że infor­ma­cyj­ny, moż­na spro­wa­dzić do archi­tek­tu­ry skła­da­ją­cej się trzech typów ele­men­tów: byt poza sys­te­mem oraz sys­tem, któ­ry zbu­do­wa­ny jest z ele­men­tów repre­zen­tu­ją­cych: inter­fejs (sen­sor, efec­tor), pro­ce­sy prze­twa­rza­nia danych (ope­ra­cje na danych) i repo­zy­to­ria danych (pamięć) .

Istotą dia­gra­mów prze­pły­wu danych jest uprosz­cze­nie pole­ga­ją­ce na przy­ję­ciu zało­że­nia, że model sys­te­mu to pro­ces prze­twa­rza­nia i repo­zy­to­rium danych zaś jego oto­cze­nia to okre­ślo­ny byt zewnętrzny.

W meto­dach struk­tu­ral­nych poję­cie «pro­ces» doty­czy każ­dej, nawet bar­dzo deta­licz­nej, ope­ra­cji na danych (patrz tytu­ły daw­nych pod­ręcz­ni­ków infor­ma­ty­ki: ​„algo­ryt­my + struk­tu­ry danych = pro­gra­my”). Moja pro­po­zy­cja zasto­so­wa­nia mode­li prze­pły­wu danych doty­czy wyłącz­nie pozio­mu, na któ­rym ope­ru­je­my wyłącz­nie poję­cia­mi (nazew­nic­two) z ana­li­zo­wa­nej dzie­dzi­ny a mode­le zawie­ra­ją wyłącz­nie nazwa­ne biz­ne­so­we ope­ra­cje i doku­men­ty jako nośni­ki danych. Cały czas cho­dzi wyłącz­nie o komu­ni­ka­cję z eks­per­ta­mi dzie­dzi­no­wy­mi, wiec uży­wa­ne na tych dia­gra­mach słow­nic­two nie może wykra­czać poza dzie­dzi­nę problemu. 

Notacja Gane’a-Sarsona

Kluczowe ele­men­ty dia­gra­mów prze­pły­wu danych omó­wię sto­su­jąc popu­lar­ną nota­cję Gane’a-Sarsona . Semantyka nota­cji (sym­bo­le i ich zna­cze­nie) ope­ru­je trze­ma symbolami: 

1. byt zewnętrz­ny (External Entity): jest to źró­dło lub adre­sat tre­ści (danych) czy­li zewnętrz­ne sys­te­my (oto­cze­nie sys­te­mu modelowanego), 
2. pro­ces (Process): miej­sce (meto­da) prze­twa­rza­nia tre­ści (danych) czy­li ele­ment reali­zu­ją­cy logi­kę dzia­ła­nia systemu, 
3. repo­zy­to­rium (Data Store): miej­sce prze­cho­wy­wa­nia tre­ści (danych) czy­li pamięć systemu, 
4. jed­nost­ka danych (Note, treść prze­ka­zy­wa­na): treść (zestaw danych).

Syntaktyka nota­cji jest tak­że pro­sta, obo­wią­zu­je jed­na zasa­da: w prze­ka­zy­wa­niu danych z miej­sca w miej­sce zawsze pośred­ni­czy pro­ces. Graficznie przed­sta­wia to diagram:

Przykłady nie­po­praw­nych (po lewej stro­nie) i popraw­nych (po pra­wej) konstrukcji:

W opi­sy­wa­nej tu meto­dzie, Data Stor (repo­zy­to­rium) repre­zen­tu­je zbiór doku­men­tów, te zaś trak­tu­je­my tu «obiek­to­wo» jako doku­men­ty (poje­dyn­czy kla­sy­fi­ka­tor lub agre­gat w nota­cji UML, w meto­dach struk­tu­ral­nych dane prze­cho­wy­wa­ne są rela­cyj­nych bazach). Pojęcie Proces na dia­gra­mach DFD utoż­sa­mia­my z kom­plet­ną ope­ra­cją na doku­men­cie lub jego czę­ści (na danych). W ten spo­sób uzy­sku­je­my zgod­ność pojęć Proces i Data Stor odpo­wied­nio z poję­cia­mi Operacja i Repozytorium w nota­cji UML i wzor­cu pro­jek­to­wym DDD (Domain Driven Design )

Kontekst użycia diagramów DFD

Istotą uży­cia dia­gra­mów DFD jest dia­log z dzie­dzi­no­wym eks­per­tem, któ­ry jest bene­fi­cjen­tem pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia. Jak już wspo­mi­na­łem, poszcze­gól­ne nota­cje (nie raz opi­sy­wa­ne na tym blo­gu) to spe­cja­li­zo­wa­ne sys­te­my poję­cio­we. Specjalizowane dla kon­kret­nych eta­pów pro­jek­tu i dzie­dzi­ny (obsza­ru) mode­lo­wa­nia. Spotykam się nie raz z pró­ba­mi two­rze­nia wła­snych, uni­wer­sal­nych ​„super nota­cji” do wszyst­kie­go lub tak zwa­nym prze­cią­ża­niem (nad­uży­wa­niem i nie­wła­ści­wym uży­ciem) ist­nie­ją­cych nota­cji (uwa­żam, że nota­cja ArchiMate jest tego przykładem). 

Kiedy moż­na użyć nota­cji DFD? Proces od roz­po­czę­cia ana­li­zy do dostar­cze­nia opro­gra­mo­wa­nia to: 

1. ana­li­za tek­stów dzie­dzi­no­wych (mate­ria­ły źródłowe)
2. opra­co­wa­nie mode­li pro­ce­sów biz­ne­so­wych orga­ni­za­cji ana­li­zo­wa­nej (nota­cja BPMN),
3. opra­co­wa­nie zakre­su pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia (nota­cja UML, dia­gram przy­pad­ków użycia),
4. opra­co­wa­nie logi­ki dzia­ła­nia apli­ka­cji (nota­cja DFD, zestaw mode­li w nota­cji UML). 
5. opra­co­wa­nie doku­men­tu Specyfikacja Wymagań (Opis Przedmiotu Zamówienia, Opis Techniczny Rozwiązania),
6. Odebranie i wdro­że­nie opro­gra­mo­wa­nia (Aplikacja).

Schematycznie poka­za­no to na dia­gra­mie poniżej:

Wszystko jest «w tle» (nie poka­za­no na dia­gra­mie) uzu­peł­nio­ne biz­ne­so­wym słow­ni­kiem pojęć i reguł.. 

Stosowanie sfor­ma­li­zo­wa­nych nota­cji daje nam narzę­dzie do kon­tro­li spój­no­ści, popraw­no­ści i kom­plet­no­ści całe­go pro­jek­tu: pro­jekt może być (a nawet dobrze by było aby był) w cało­ści pro­wa­dzo­ny i doku­men­to­wa­ny z uży­ciem narzę­dzi CASE (a nie pro­sty­mi narzę­dzia­mi biu­ro­wy­mi taki­mi jak edy­tor tek­stu czy arkusz kal­ku­la­cyj­ny). Dobór nota­cji daje nam moż­li­wość sku­tecz­nej, z uży­ciem dzie­dzi­no­we­go słow­nic­twa, komu­ni­ka­cji z klu­czo­wy­mi akto­ra­mi: Beneficjent oraz Dostawca.

Diagram DFD peł­ni rolę abs­trak­cji sys­te­mu. Jest (powi­nien być) zro­zu­mia­ły dla Beneficjenta i dla Dostawcy goto­we­go opro­gra­mo­wa­nia. Jeżeli dostęp­ne na ryn­ku ist­nie­ją­ce opro­gra­mo­wa­nie nie speł­nia (wszyst­kich) wyma­gań (nie reali­zu­je wszyst­kich potrzeb­nych ope­ra­cji na doku­men­tach i ich tre­ści), powsta­je dodat­ko­wy pro­jekt archi­tek­tu­ry (model dzie­dzi­ny sys­te­mu) z uży­ciem nota­cji UML i na jego pod­sta­wie zama­wia­ne jest dedy­ko­wa­ne oprogramowanie. 

Harmonizacja notacji

Jak widać na powyż­szym dia­gra­mie, uży­tych zosta­ło kil­ka nota­cji. W inży­nie­rii jest to, wbrew pozo­rom, dość powszech­ne zja­wi­sko. To co nazy­wa­my popu­lar­nie «rysun­kiem tech­nicz­nym» to sche­ma­ty blo­ko­we. Zależnie od eta­pu pro­jek­to­wa­nia i bran­ży, uży­wa­ne są róż­ne dzie­dzi­no­we sys­te­my poję­cio­we i biblio­te­ki sym­bo­li opi­sa­ne nor­ma­mi ISO/IEEE. Zapewniam, że uży­wa­nie kil­ku nota­cji w jed­nym pro­jek­cie nie jest abso­lut­nie żad­nym ewe­ne­men­tem w inży­nie­rii. Istotne jest zapew­nie­nie spój­no­ści cało­ści dokumentacji. 

Poglądowo opi­sa­na har­mo­ni­za­cja pojęć i notacji:

1. ana­li­za tek­stów źró­dło­wych (mate­ria­łów) pro­wa­dzi do powsta­nia mode­li pro­ce­sów biz­ne­so­wych, słow­ni­ka pojęć, spe­cy­fi­ka­cji doku­men­tów, iden­ty­fi­ka­cji reguł biz­ne­so­wych (nota­cje BPMN oraz SBVR),
2. ele­men­tar­ny pro­ces biz­ne­so­wy to zada­nie (atomowa/elementarna aktyw­ność) zwień­czo­ne pro­duk­tem (wyj­ście pro­ce­su: zestaw danych zebra­nych jako doku­ment), (BPMN)
3. zada­nie to jed­na lub wię­cej ope­ra­cji na danych obję­tych jed­nym doku­men­tem (BPMN),
4. uzgod­nie­nie z zama­wia­ją­cym zakre­su pro­jek­tu (co sys­tem ma robić) pro­wa­dzi do powsta­nia dia­gra­mu przy­pad­ków uży­cia UML (model sys­te­mu jako czar­na skrzynka),
5. dla zakre­su pro­jek­tu powsta­je opis logi­ki biz­ne­so­wej jako lista doku­men­tów oraz ope­ra­cji na nich i metod wyko­na­nia tych ope­ra­cji w posta­ci mode­lu prze­pły­wu danych (DFD), model sys­te­mu jako bia­ła skrzynka,
6. ope­ra­cje na danych są wyko­ny­wa­ne wg. okre­ślo­nej meto­dy (np. algo­rytm) (róż­ne for­my: wzo­ry mate­ma­tycz­ne, pro­ce­du­ry, dia­gra­my aktyw­no­ści UML, inne),
7. jeże­li ma powstać dedy­ko­wa­ne opro­gra­mo­wa­nie, nale­ży zapro­jek­to­wać jego archi­tek­tu­rę (model PIM UML), czy­li podzie­lić sys­tem na kom­po­nen­ty i każ­de­mu z nich przy­po­rząd­ko­wać opi­sa­ne ope­ra­cje na doku­men­tach i danych jakie ma wyko­ny­wać, model sys­te­mu jako bia­ła skrzynka.

Podsumowanie

Analiza i pro­jek­to­wa­nie to zło­żo­ny pro­ces mode­lo­wa­nia. Utrzymanie spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści doku­men­ta­cji zawie­ra­ją­cej wie­le sche­ma­tów blo­ko­wych jest bar­dzo trud­ne, dla­te­go sto­su­je się do tego narzę­dzia CASE i sfor­ma­li­zo­wa­ne nota­cje. Bez tego utrzy­ma­nie wyma­ga­nej jako­ści doku­men­tów w inży­nie­rii opro­gra­mo­wa­nia gra­ni­czy z nie­moż­li­wo­ścią, lub sta­je się klu­czo­wym kosz­tem samo w sobie (pamię­taj­my, że zła doku­men­ta­cja gene­ru­je kosz­ty wpro­wa­dza­nia popra­wek na eta­pie imple­men­ta­cji i wdrożenia).

Opisana meto­da i miej­sce sto­so­wa­nia dia­gra­mów DFD poza­wa­la wpro­wa­dzić for­ma­lizm do spe­cy­fi­ko­wa­nia logi­ki biz­ne­so­wej, jesz­cze zanim zacznie­my uży­wać nota­cji UML, któ­ra dla więk­szo­ści bene­fi­cjen­tów jest nie­zro­zu­mia­ła. Stosowanie dia­gra­mów DFD wyma­ga jed­nak okre­śle­nia pozio­mu abs­trak­cji oraz przy­ję­cia defi­ni­cji pojęć ope­ra­cja (pro­ces w DFD) i meto­da zgod­nych z defi­ni­cja­mi tych pojęć w nota­cji UML (to narzu­ca poziom abs­trak­cji dla mode­li DFD).

Podobne mode­le, nie­ste­ty chy­ba mniej intu­icyj­ne w per­cep­cji dla osób nie­do­świad­czo­nych w UML , moż­na two­rzyć z uży­ciem dia­gra­mów aktywności :

Wybór pozo­sta­wiam czytelnikom ;). 

[przy­kład w przygotowaniu]

Źródła