Od lat, pod­czas audy­tów i szko­leń, spo­ty­kam się z ​„dziw­ny­mi dia­gra­ma­mi” two­rzo­ny­mi w celu… no wła­śnie. Ale po kolei…

Najpierw przy­po­mnę, bar­dzo tu pomoc­ne, poję­cie archi­tek­tu­ry kor­po­ra­cyj­nej, któ­ra – śle­dząc lite­ra­tu­rę przed­mio­tu – jest mode­lem (doku­men­ta­cją) wią­żą­cym model biz­ne­so­wy orga­ni­za­cji z jej zaso­ba­mi infor­ma­cyj­ny­mi i infra­struk­tu­rą słu­żą­cą do zarzą­dza­nia infor­ma­cją. Posiadanie takie­go mode­lu ma sens nie tyl­ko po to by, wie­dzieć ​„co mamy” czy opi­sać wyma­ga­nia na to cze­go ​„jesz­cze nie nie mamy a potrze­bu­je­my mieć”. Model taki pozwa­la ana­li­zo­wać posia­da­ne zaso­by, ale tak­że oce­nić ich wpływ na dzia­ła­nie orga­ni­za­cji, wza­jem­ny wpływ, prze­wi­dzieć reak­cje sys­te­mu na nowe bodź­ce (lub awarie).

W arty­ku­le opi­su­ją­cym pro­ces mode­lo­wa­nia ​„od biz­ne­su do pro­jek­tu logi­ki sys­te­mu” opi­sa­łem prze­cho­dze­nie od mode­lu pro­ce­sów biz­ne­so­wych, przez przy­pad­ki uży­cia do mode­lu dzie­dzi­ny sys­te­mu (lub kom­po­nen­tów w przy­pad­ku zło­żo­nych sys­te­mów jak w arty­ku­le Przypadki uży­cia i gra­ni­ce sys­te­mu). Nie będę więc w tym miej­scu powta­rzał tych tre­ści, ale poka­że przykłady.

Opisywane tu podej­ście wyma­ga przy­ję­cia stan­dar­do­wych defi­ni­cji pojęć pro­ces biz­ne­so­wy i przy­pa­dek uży­cia oraz usłu­ga sys­te­mu (tak zwa­na prag­ma­ty­ka mode­li, powin­na być zawsze dołą­czo­na do doku­men­tów ana­li­zy). Dwie ostat­nie są w UML prak­tycz­nie toż­sa­me z pro­ce­sem biz­ne­so­wym (A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem – czyn­ność lub ich seria dają­ca jako efekt pro­dukt mają­cy war­tość dla akto­ra, źr. UML 2.4.1. 16.3.6 UseCase). W efek­cie zestaw dia­gra­mów opi­su­ją­cych orga­ni­za­cję z jej sys­te­mem infor­ma­cyj­nym, two­rzą Architekturę jak poniżej:

Usługa sys­te­mu (jego przy­pa­dek uży­cia) może wspie­rać jeden lub wie­le róż­nych pro­ce­sów biz­ne­so­wych, jed­nak na pozio­mie pro­ce­sów ele­men­tar­nych (tych któ­rych już nie dekom­po­nu­je­my), jeden pro­ces ​„ele­men­tar­ny” może być wspie­ra­ny wyłącz­nie jed­nym przy­pad­kiem uży­cia (bo na tym pozio­mie powsta­je jeden pro­dukt). Przykładem jed­nej usłu­gi wyko­rzy­sty­wa­nej w kil­ku pro­ce­sach może być przy­pa­dek zwa­ny CRUD (Create, Retrieve, Update, Delete, czy­li Utwórz, Przywołaj, Aktualizuj, Usuń), taka usłu­ga (przy­pa­dek uży­cia typu CRUD) może wspie­rać pro­ce­sy: two­rze­nia, aktu­ali­za­cji (w tym zmia­ny sta­tu­su) i usu­wa­nia dokumentów.

Usługi są reali­zo­wa­ne przez okre­ślo­ne kom­po­nen­ty (apli­ka­cje), któ­re są insta­lo­wa­ne na kon­kret­nych plat­for­mach. Z uwa­gi na to, że kom­po­nen­ty mogą współ­pra­co­wać (wymie­niać mię­dzy sobą dane) mają udo­ku­men­to­wa­ne interfejsy.

Jak pokazać, które komponenty są wykorzystywane w określonych procesach?

Teraz przy­szedł moment, w któ­rym poja­wia­ją się czę­sto nie­stan­dar­do­we dia­gra­my ​„wymy­śla­ne” w celu ​„jakie­goś spo­so­bu” na poka­za­nie związ­ków pomię­dzy biz­ne­sem (pro­ce­sy biz­ne­so­we) a kom­po­nen­ta­mi opro­gra­mo­wa­nia. Poważną wadą tych pomy­słów jest przede wszyst­kim to, że są nie­stan­dar­do­we. Po dru­gie wyma­ga­ją ​„ręcz­ne­go” wytwo­rze­nia, są pra­co­chłon­ne, mno­żą się dodat­ko­we stro­ny doku­men­ta­cji, pod­no­szą jej zło­żo­ność i pogar­sza­ją zro­zu­mia­łość całości.

Jak sobie z tym pora­dzić? Tu nie­oce­nio­ne są wła­śnie dobre pakie­ty opro­gra­mo­wa­nia CASE. Poniżej pro­sty przykład:

Model pro­ce­su biz­ne­so­we­go (pro­ces skła­da się z ele­men­tar­nych pro­ce­sów, każ­dy ma produkt):

Model przy­pad­ków uży­cia (zacho­wa­no nazwy z mode­lu pro­ce­sów dla orientacji):

Przykładowa reali­za­cja (sce­na­riusz) wybra­ne­go przy­pad­ku uży­cia (na pozio­mie kom­po­nen­tów, tu celem jest spe­cy­fi­ko­wa­nie inter­fej­su czy­li wywo­łań jed­ne­go kom­po­nen­tu przez drugi):

Jak teraz spraw­dzić i poka­zać związ­ki pomię­dzy pro­ce­sa­mi, przy­pad­ka­mi uży­cia apli­ka­cji (usłu­ga­mi sys­te­mu) i kom­po­nen­ta­mi (apli­ka­cja­mi)? Zamiast two­rzyć nowe sztucz­ne i nie­stan­dar­do­we dia­gra­my znacz­nie lepiej jest poka­zać to w for­mie macie­rzy nie psu­jąc np. mode­li pro­ce­sów nie­for­mal­ny­mi zapi­sa­mi o systemach:

Gdyby potrzeb­ne były bar­dziej wyra­fi­no­wa­ne ana­li­zy zależ­no­ści, może­my stwo­rzyć, zamiast dwu­wy­mia­ro­wej macie­rzy, taki diagram:

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Uzupełnieniem powyż­szych mode­li może być mapo­wa­nie doku­men­tów z dia­gra­mów pro­ce­sów biz­ne­so­wych na kla­sy (agre­ga­ty) repre­zen­tu­ją­ce je w opro­gra­mo­wa­niu (kom­po­nen­ty). Tu nie­ste­ty nie widzę sen­su mapo­wa­nia na ​„dane w bazie danych” bo celem jest doku­men­to­wa­nie miej­sca prze­cho­wy­wa­nia infor­ma­cji (kom­po­nent) a nie imple­men­ta­cji (baza RDBMS, któ­ra jest jed­ną z wie­lu moż­li­wych imple­men­ta­cji utrwalania).

Ważne jest by narzę­dzie bar­dzo dobrze wspie­ra­ło spe­cy­fi­ka­cje nota­cji oraz meto­dy wery­fi­ko­wa­nia spój­no­ści mode­li takie jak śla­do­wa­nie, pod­le­głość mode­li, zależ­no­ści ​„parent-child” i zagnieżdżanie.

(Artykuł powstał z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm Agilian, pakiet ten ma moduł do pro­wa­dze­nia ana­liz wpły­wu i zależ­no­ści).