Na razie widzę, że kla­ru­ją się dwa podejścia:

- IDEF0 lub ICOM i pochod­ne (w tym EPC i eEPC)

- inne idą w kie­run­ku UML

IDEF0 to kom­plet­ny model logicz­ny uwzględ­nia­ją­cy zaso­by i cele biz­ne­so­we (któ­re nie­ste­ty czę­sto zatra­ca się w pro­ce­sie mode­lo­wa­nia!). UML to dro­ga do zapro­jek­to­wa­nia apli­ka­cji. Myślę, że tą dro­gą w środ­ku spo­tka­ją się ana­li­ty­cy i pro­gra­mi­ści. W miej­scu gdzie mamy model pro­ce­so­wy i pro­ce­du­ry (work­flow) na naj­niż­szym pozio­mie dekom­po­zy­cji pro­gra­mi­sta obiek­to­wy ma wszyst­kie infor­ma­cje by z pomo­cą UML zapro­jek­to­wać i napi­sać kod apli­ka­cji. Każdy pro­sty ?blo­czek? mode­lu oraz inter­fej­sy (for­mat­ki doku­men­tów) mogą teraz zostać zaim­ple­men­to­wa­ne w sys­te­mie. Być może od stro­ny mode­lo­wa­nia BPMN (Business Process Modeling Notation) a od stro­ny kodo­wa­nia BPEL wnio­są uła­twie­nie pole­ga­ją­ce na umoż­li­wie­niu pew­nej auto­ma­ty­za­cji two­rze­nia pro­gra­mów jed­nak w moim prze­ko­na­niu waż­niej­sze jest by pre­cy­zyj­nie wska­zać gra­ni­ce kom­pe­ten­cji pomię­dzy ana­li­ty­kiem a inży­nie­rem i dokład­nie na tej gra­ni­cy umie­ścić styk narzę­dzi ana­li­tycz­nych i inżynierskich.

Modelowanie to dzie­dzi­na pra­wie tak sta­ra jak sys­te­my infor­ma­tycz­ne dla biz­ne­su. Podstawowym celem mode­lo­wa­nia pro­ce­sów jest opi­sa­nie fir­my, okre­śle­nie celu pro­jek­tu reor­ga­ni­za­cyj­ne­go i jego zakre­su, okre­śle­nie wyma­gań na two­rzo­ne opro­gra­mo­wa­nia a wcze­śniej opty­ma­li­za­cji orga­ni­za­cji i przy­go­to­wa­nie jej do wdro­że­nia. Stworzenie opi­su funk­cjo­nal­ne­go tego co będzie­my opro­gra­mo­wy­wać zawsze było wyzwa­niem trud­nym. Drugim, być może jesz­cze trud­niej­szym jest (do dzi­siaj) nawią­za­nie nici poro­zu­mie­nia i zro­zu­mie­nia pomię­dzy sfe­rą biz­ne­su a inży­nie­ra­mi i programistami.

Jedna z ról jaką ma do ode­gra­nia wyko­na­ny przez ana­li­ty­ków model jest stwo­rze­nie szkie­le­tu apli­ka­cji lub przy­naj­mniej opi­su tego szkie­le­tu. Naturalnym dąże­niem jest tak­że pró­ba unik­nię­cia ręcz­ne­go ​„prze­pi­sy­wa­nia” pra­cy ana­li­ty­ków biz­ne­so­wych mode­lu i wyge­ne­ro­wa­nie na jego pod­sta­wie kodu apli­ka­cji lub przy­naj­mniej jej mode­lu np. w posta­ci UML.

Notacje i meto­dy­ki mode­lo­wa­nia moż­na podzie­lić na dwie grupy:

1. mode­lo­wa­nie do pro­wa­dze­nia ana­liz i opty­ma­li­za­cji pro­ce­sów i zda­rzeń gospo­dar­czych (pro­ce­sów biznesowych)
2. mode­lo­wa­nie do celów two­rze­nia oprogramowania

Na świe­cie nadal naj­po­pu­lar­niej­sze są: IDEF wśród ana­li­ty­ków i UML wśród programistów.

Modele analityczne

Tu się nie­wie­le zmie­ni­ło. Nadal w uży­ciu jest IDEF0 i jego odmia­ny a raczej warian­ty czy­li ICOM i mniej zna­ny IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czy­li Wejście, Sterowanie, Wyjście, Mechanizm (tu cho­dzi o zaso­by). Skrót IGOE ma roz­wi­nie­cie: Input, Guide (odpo­wied­nik ste­ro­wa­nia), Output, Enabler (tu cho­dzi o zaso­by w kon­tek­ście ini­cja­to­ra reali­za­cji danej funk­cji). W obu przy­pad­kach ogól­ny sche­mat pro­ce­su w tych kon­wen­cjach przed­sta­wia­ny jest za pomo­cą pro­sto­ką­ta sym­bo­li­zu­ją­ce­go funk­cję reali­zo­wa­ną przez pro­ces oraz strzał­ki obra­zu­ją­ce wymie­nio­ne czte­ry jego atrybuty :

Na tym pozio­mie powsta­ło wie­le pro­duk­tów, któ­re nie­ste­ty zawie­ra­ją swo­je uni­kal­ne roz­sze­rze­nia sym­bo­li i reguł. Doprowadziło to powsta­nia wie­lu narzę­dzi do mode­lo­wa­nia, któ­rych pro­duk­ty są ze sobą nie­kom­pa­ty­bil­ne już na pozio­mie uży­tych sym­bo­li. Nie wymie­nia­jąc ich tu napi­sze, tyl­ko, że w dość powszech­nym uży­ciu jest ich pra­wie dzie­sięć a Gartner ziden­ty­fi­ko­wał ich na ryn­ku trzy­dzie­ści sześć. Z tego też powo­du uży­wam w pra­cy sym­bo­li ICOM pro­stych i zro­zu­mia­łych dla biz­ne­su zaś w przy­pad­kach bar­dziej ​„sfor­ma­li­zo­wa­nych” uży­wam IDEF0. Z uwa­gi na sta­ły roz­wój tak­że tych metod osta­nio zain­te­re­so­wą­łem się nota­cją BPMN.

Modelowanie do celów tworzenia oprogramowania

Ten temat jest dużo trud­niej­szy, gdyż dąże­nie do reali­za­cji ​„sprzę­gu” pomię­dzy ana­li­ty­kiem a infor­ma­ty­kiem to temat ist­nie­ją­cy od począt­ku cza­sów two­rze­nia opro­gra­mo­wa­nia do celów biz­ne­so­wych. Krótka histo­ria narzę­dzi do mode­lo­wa­nia na potrze­by two­rze­nia opro­gra­mo­wa­nia (rok powsta­nia i nazwa metody):

• 1962: sie­ci Petriego (Carl Petri Network)
• 1970: ANSI Flow charts
• 1979: DFD (Data Flow Diagram)
• 1982: ISO TC87 (ISO Conceptual Schema Model)
• 1992: Merise (Methode d’Etude et de Realisation Informatique pour les Systemes d’Enterprice)
• 1992; EPC (Eventdriven Process Chains)
• 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method)
• 2001: ebXML v.1.1 (elec­tro­nic busi­ness using eXtesible Markup Language)
• 2002: BPML v.1.1 (Busines Process Modeling Language)
• 2002: WSCi v.1.0
• 2003: BPEL4WS (Business Process Execution Language for Web Services)
• 2004: BPMN (Business Process Modeling Notation)

(na pod­sta­wie ​„Process mode­ling – A Maturing Discipline?”, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of tech­no­lo­gy Information).

Sieci Petriego są nadal uwa­ża­ne za jed­no z naj­sku­tecz­niej­szych narzę­dzi do mode­lo­wa­nia jed­nak ich głów­nym ogra­ni­cze­niem jest dość skom­pli­ko­wa­ny model mate­ma­tycz­ny oraz brak hie­rar­chi­za­cji funk­cji jak to ma miej­sce w real­nych orga­ni­za­cjach. Nie zawie­ra też w sobie narzę­dzi do opi­su archi­tek­tu­ry obiek­to­wej opro­gra­mo­wa­nia. Metody two­rze­nia opro­gra­mo­wa­nia zorien­to­wa­ne obiek­to­wo dopro­wa­dzi­ły do powsta­nia narzę­dzi typu UML jed­nak są one bar­dzo trud­ne do zasto­so­wa­nia w mode­lo­wa­niu biz­ne­so­wym gdyż natu­ra orga­ni­za­cji jest hie­rar­chicz­na a nie obiek­to­wa. Modele obiek­to­we są po pierw­sze prak­tycz­nie nie­zro­zu­mia­łe dla biz­ne­su po dru­gie nie spraw­dza­ją się jako narzę­dzie do opi­su orga­ni­za­cji, któ­ra żyje i ewo­lu­uje. Stale roz­wi­ja­ją­ce się meto­dy zarzą­dza­nia ewo­lu­ują w stro­nę pro­ce­sów biz­ne­so­wych ich natu­ra zaś jest jest hie­rar­chicz­na. Kolejną pró­bą roz­wią­za­nia pro­ble­mu jest powsta­nie BPMN.

BPMN – Business Process Modeling Notation

Ideą twór­ców BPMN jest stwo­rze­nie narzę­dzia dla ana­li­ty­ków ale takie­go, któ­re­go pro­duk­ty da się ​„tłu­ma­czyć” na BPEL4WS. Bazą dla BPMN są sie­ci Petriego i EPC. Dla tego z jed­nej stro­ny kom­plet­na lista sym­bo­li BPMN to 38 sym­bo­li obra­zu­ją­cych typo­we zda­rze­nia biz­ne­so­we dają­ce się odwzo­ro­wać za pomo­cą BPEL4WS, mode­lo­wać zaś moż­na już za pomo­cą sze­ściu pod­sta­wo­wych, któ­re pozwa­la­ją na zbu­do­wa­nie peł­ne­go mode­lu pro­ce­sów biz­ne­so­wych. Pozostałe sym­bo­le słu­żą do dodat­ko­we­go defi­nio­wa­nia zda­rzeń koniecz­nych z punk­tu widze­nia inży­nie­rii opro­gra­mo­wa­nia. Dlatego np. model wyko­na­ny za pomo­cą pod­sta­wo­we­go zesta­wu sym­bo­li przez ana­li­ty­ka da się łatwo uzu­peł­nić jako kon­ty­nu­acja pro­jek­tu o bra­ku­ją­ce ele­men­ty w celu wyge­ne­ro­wa­nia kodu dla BPEL. ten zaś być może będzie stan­dar­dem słu­żą­cych do gene­ro­wa­nia kodu apli­ka­cji jak daw­ne sys­te­mu typu CASE.

Notatka: W tym roku (2005) opu­bli­ko­wa­no wer­sję 1.0 nota­cji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odby­ła się kon­fe­ren­cja BPMN Foundation na któ­rej mię­dzy inny­mi ogło­szo­no połą­cze­nie Notation Working Group z OMG i spe­cy­fi­ka­cję BPMN v.1.0. W pla­nie jest RFC.