Problem z wzorcem State Machine czyli ile Cię kosztuje workflow

Systemy zarzą­dza­nia prze­pły­wem doku­men­tów (docflow) lub pra­cy (work­flow), wzor­ce pro­jek­to­we i … pro­blem. Uwaga! Jeżeli nie jesteś ana­li­ty­kiem ani pro­jek­tan­tem sys­te­mów, zale­cam skok na koniec tek­stu do punk­tu Na zakoń­cze­nie biz­ne­so­wo.

Tym razem chcę zwró­cić uwa­gę na pewien pro­blem ze sto­so­wa­niem wzor­ca pro­jek­to­we­go State Machine Pattern. Wzorzec ten moim zda­niem sta­no­wi pułap­kę dla nie­do­świad­czo­nych pro­jek­tan­tów i pro­gra­mi­stów. Otóż wzo­rzec ten jest dość powszech­nie sto­so­wa­ny do imple­men­ta­cji usłu­gi zarzą­dza­nia prze­pły­wem doku­men­tów. Ale po kolei.

State machine pattern

Wzorzec ten jest dobrze opi­sa­ny w lite­ra­tu­rze więc tu tyl­ko klu­czo­we infor­ma­cje. Uproszczony model wzorca:

Kontekst to obiekt sta­tu­so­wy (cha­rak­te­ry­zu­ją­cy się pew­ną sta­no­wo­ścią). Jego czę­ścią jest zestaw (kom­po­zy­cja z obiek­ta­mi Status) sta­nów jakie może on przyj­mo­wać (KonkretneStany). Logikę zmian tych sta­tu­sów umiesz­cza się w obiek­cie Kontekst (ope­ra­cja ustaw kon­kret­ny sta­tus jako aktu­al­ny), spo­ty­ka­ną meto­dą imple­men­ta­cji jest umiesz­cza­nie ope­ra­cji reagu­ją­cych na kon­kret­ne zda­rze­nia w obiek­tach sta­no­wych. Ten dru­gi wariant jest w moich oczach trosz­kę nad­uży­ciem: wie­dza o sta­tu­sach jest wno­szo­na do sta­tu­sów, obiekt macie­rzy­sty nie panu­je nad nimi, a sta­tu­sy to jed­nak cecha (wła­sność) obiek­tu Kontekst i to on wiek jaki i dla­cze­go sta­tus chce przyjąć”.

Kiedy stosować

Model ten więc bazu­je na zało­że­niu, że wie­dza o sta­tu­sie (kie­dy jaki przy­jąć) tkwi w obiek­cie sta­tu­so­wym (przyj­mu­ją­cym te sta­ny). Przykładem może być np. woda i jej sta­ny sku­pie­nia, któ­re są cechą fizycz­ną wody – są więc zwią­za­ne z wodą. Woda może przy­jąć stan sku­pie­nia sta­ły (lód), cie­kły lub gazo­wy (para wod­na). Aktualny stan sku­pie­nia zale­ży wyłącz­nie od tem­pe­ra­tu­ry i ciśnie­nia. Żaden inny czyn­nik nie jest w sta­nie zmie­nić sta­nu kupie­nia wody (np. na pole­ce­nie czło­wie­ka ;)). Przykładów takich moż­na przy­to­czyć wiele.

Problem zaczy­na się gdy obiekt ma sta­tu­sy zależ­ne od pew­nej logi­ki zewnętrz­nej, jakiś inny obiekt ma wie­dzę o tym jaki sta­tus zosta­nie usta­wio­ny. Ciekawym przy­kła­dem jest np. nasze miesz­ka­nie (kon­kret­nie zamek w drzwiach) i my. Status Zamknięte i Otwarte nie jest cechą ani zam­ka, ani drzwi ani nawet miesz­ka­nia tyl­ko jest to efekt naszej woli (miesz­kań­ca). To my decy­du­je­my o tym czy miesz­ka­nie jest zamknię­te czy otwar­te i czy być może ma inny jesz­cze sta­tus (nie zna­ny pro­du­cen­to­wi drzwi!). W efek­cie logi­ka zmia­ny sta­tu­su jest poza drzwia­mi (miesz­ka­niem), któ­re dany stan przyj­mu­ją. Mieszkaniec w dowol­nym momen­cie może usta­wić swo­je miesz­ka­nie w stan nie pla­no­wa­ny wcze­śniej, więc imple­men­ta­cja powyż­sze­go wzor­ca napo­tka na poważ­ny pro­blem: jak usta­wić sta­tus nie­zna­ny w momen­cie pro­jek­to­wa­nia? Przykład? W hote­lach: posprzą­tać, nie prze­szka­dzać itp… Tu moż­na zary­zy­ko­wać zna­ną z góry listą takich zna­ków ale nasze drzwi w domu? Bierzemy tak zwa­ną żół­ta kar­tecz­kę i nakle­ja­my na drzwi z zewnątrz: jestem zaję­ty albo co nam tam do gło­wy przyj­dzie (domow­nik u sąsia­da). Implementacja sta­nów na żyw­ca” sta­je się poważ­nym ogra­ni­cze­niem bo wzo­rzec w tej posta­ci wyma­ga wie­dzy o wszyst­kich sta­nach już w momen­cie two­rze­nia systemu.

Klasycznym jed­nak przy­kła­dem tego pro­ble­mu są

Systemy obiegu dokumentów

Dokument (obiekt) biz­ne­so­wy może przyj­mo­wać sta­ny w zasa­dzie nie­prze­wi­dy­wal­ne na eta­pie ana­li­zy. Stany te mogą być (i nie raz są!) skut­kiem wpro­wa­dza­nia lub zmian reguł biz­ne­so­wych a nie cech doku­men­tu. Tak więc zna­ne na począt­ku wdro­że­nia sta­tu­sy fak­tu­ry: przy­ję­ta, zaksię­go­wa­na, zapła­co­na. Mogą się zmie­nić po wpro­wa­dze­niu np. wewnętrz­ne­go zarzą­dze­nia o tre­ści: doku­men­ty rodzą­ce kosz­ty prze­kra­cza­ją­ce 10 tys. zło­tych muszą być dodat­ko­wo zatwier­dza­ne przed Zarząd. Jaki mamy efekt? Wiele doku­men­tów, nie tyl­ko fak­tu­ry ale i umo­wy czy rekla­ma­cje nagle muszą obsłu­żyć nowy sta­tus: do zatwier­dze­nia przez Zarząd. Mamy tu lawi­no­wą mody­fi­ka­cję sys­te­mu. Zmiana zasad wyma­ga inge­ren­cji we wszyst­kie obiek­ty sta­no­we mogą­ce pod­paść” pod nową regu­łę. Pytanie dru­gie: jak je wszyst­kie szyb­ko i jed­no­znacz­nie ziden­ty­fi­ko­wać w systemie?

Już czu­je­my? Kto ma sys­tem obie­gu doku­men­tów wyma­ga­ją­cy inge­ren­cji dostaw­cy przy każ­dej zmia­nie zasad albo dowia­du­je się, że tego nie­ste­ty nie moż­na zrobić”?

Problem maszy­ny sta­no­wej: obcią­że­nie doku­men­tu odpo­wie­dzial­no­ścią za jego sta­tus, jest w takich przy­pad­kach zła­ma­niem zasa­dy wła­ści­we­go przy­dzia­łu odpo­wie­dzial­no­ści w pro­jek­to­wa­niu obiek­to­wym. Tak więc w takich przy­pad­kach nale­ży zre­zy­gno­wać z wzor­ca State machine.

Pewnym roz­wią­za­niem w obsza­rze pro­ce­sów biz­ne­so­wych i zarzą­dza­nia prze­pły­wem pra­cy jest

Metamodel procesu WfMC

Workflow Management Coalition (WfMC) to orga­ni­za­cja stan­da­ry­zu­ją­ca (wię­cej w odno­śni­ku). Proponuje ona taki oto meta­mo­del (tu dia­gram nie­co uproszczony):

(źr. WfMC: http://​www​.wfmc​.org/​s​t​a​n​d​a​r​d​s​/​d​o​c​s​/​T​C​-​1​0​1​1​_​t​e​r​m​_​g​l​o​s​s​a​r​y​_​v​3​.​pdf)

Nasz obiekt sta­tu­so­wy, np. doku­ment, to DanePowiązane. Jednak sta­tu­sy usta­wia mu nie on sam sobie” a Aktywność na bazie wie­dzy” zapi­sa­nej w obiek­cie WarunekPrzekształcenia (WywołanaAplikacja to przy­pa­dek, gdy sta­tus uru­cha­mia jakieś prze­twa­rza­nie Danych, tu nie będzie to oma­wia­ne, przy­da­je się np. przy pro­jek­tach SOA). Aktualny sta­tus DanychPowiązanych to ich atry­but. Jak go usta­wić? Poleceniem ustaw sta­tus na …” gdzie para­me­trem jest kod sta­tu­su” (lub obiekt go repre­zen­tu­ją­cy, o czym za moment). Mógł by ktoś zarzu­cić mi upu­blicz­nie­nie dostę­pu do atry­bu­tów (jest zasa­da by tego nie robić) ale to wła­śnie jeden z tych przy­pad­ków gdy atry­but obiek­tu nie jest jego wła­sno­ścią. Po dru­gie nie upu­blicz­niam dostę­pu do atry­bu­tu. Zarządza nim ope­ra­cja obiek­tu ustaw sta­tus na…” i nie jest to nie­bez­piecz­ne get/set. Tu nie udo­stęp­niam atry­bu­tu a ujaw­niam jego ist­nie­nie a to nie to samo. Po dru­gie kon­tro­lu­ję błę­dy wła­śnie dedy­ko­wa­ną ope­ra­cją, któ­ra może kon­tro­lo­wać popraw­ność wyko­na­nia (np. spraw­dza­jąc czy prze­ka­zy­wa­ny para­metr jest dopusz­czal­ny). Kompletny opis (prze­pis) takiej logi­ki to Proces a odpo­wie­dzial­ność za Aktywności ma Rola czy­li jakiś aktor systemu.

Ta pro­po­zy­cja jest zgod­na z zada­mi sztu­ki OOAD” a roz­bie­ra­jąc ją na czyn­ni­ki pierw­sze tak­że z DDD. Zwróćmy uwa­gę, że model, w któ­rym Aktywność usta­wia sta­tus Danych jest zgod­ny z tym, że wie­dzę o sta­tu­sach ma Aktywność i ma swo­bo­dę ich usta­wia­nia. Po dru­gie taki pro­jekt ma w jed­nym tyl­ko miej­scu zgro­ma­dzo­na wie­dzę o regu­łach i dopusz­cza­nych sta­tu­sach. W takiej sytu­acji nawet jeże­li poja­wi się nowy, nie zna­ny nam wcze­śniej obiekt biz­ne­so­wy, może­my go łatwo stwo­rzyć bez potrze­by wbu­do­wy­wa­nia mu z góry jego sta­tu­sów. Zmiany zesta­wu moż­li­wych sta­tu­sów (nowe zarzą­dze­nie) doku­men­tów nie wyma­ga­ją prze­ró­bek całe­go zesta­wu zaim­ple­men­to­wa­nych obiek­tów biz­ne­so­wych. Takie podej­ście daje tak­że moż­li­wość pra­cy ad-hoc (usta­wie­nie sta­tu­su doku­men­tu lub spra­wy z palca”).

O DDD. Status doku­men­tu (doku­ment to Encja w DDD) nie musi mieć toż­sa­mo­ści więc może być imple­men­to­wa­ny jako VO (Value Object) co pozwo­li np. wbu­do­wać mu test (wali­da­cję). W dowol­nym momen­cie obiekt taki moż­na pod­mie­nić” na obiekt sta­tu­so­wy zgod­ny z omó­wio­ną na począt­ku Maszyna sta­no­wą, wte­dy obcią­ży­my” bazo­wy obiekt biz­ne­so­wy wie­dzą o jego dopusz­czal­nych statusach.

Na zakończenie biznesowo

Systemy zarzą­dza­nia prze­pły­wem doku­men­tów, prze­pły­wem pra­cy lub szum­nie nazy­wa­ne (i na wyrost) syte­ma­mi zarzą­dza­nia pro­ce­sa­mi biz­ne­so­wy­mi, spra­wia­ją wie­le pro­ble­mów. Zaryzykuje tezę, że ich wdra­ża­nie jest ryzy­kiem nie mniej­szym niż wdra­ża­nie sys­te­mów CRM (podob­no tu odse­tek prze­kro­czo­nych budże­tów i ter­mi­nów prze­kra­cza 90%).

Nawet jeże­li ktoś prze­pro­wa­dzi rze­tel­ną ana­li­zę potrzeb i tak dosto­su­je (zapro­jek­tu­je i wytwo­rzy) wdra­ża­ny sys­tem, że będzie speł­niał pier­wot­ne wyma­ga­nia, oka­zu­je się nie raz, że jego życie” (cykl życia) jest bar­dzo kosz­tow­ne. Problem tkwi w mode­lu zja­wi­ska jakim jest prze­pływ pra­cy. Nie raz wie­lu z Państwa (mają­cych takie sys­te­my) sły­sza­ło po wdro­że­niu, że coś wyma­ga wie­le pra­cy albo jest wręcz nie moż­li­we już po roz­po­czę­ciu eks­plo­ata­cji sys­te­mu. Albo, że pro­ces może obsłu­żyć tyl­ko jeden doku­ment” i złą­cze­nie w jeden kon­tro­lo­wa­ny bieg wypad­ków cze­goś takie­go jak opra­co­wa­nie ofer­ty w odpo­wie­dzi na przy­ję­te zapy­ta­nie jest nie­moż­li­we albo wyma­ga sztucz­ne­go połą­cze­nia dwóch pro­ce­sów w jeden” (czy­li dwóch doku­men­tów Zapytanie i Oferta w jeden ciąg). Inny przy­pa­dek to nie da się dowol­nie zmie­niać sta­tu­sów doku­men­tów, pro­szę okre­ślić dokład­nie jakie sta­tu­sy będzie miał doku­ment oraz kie­dy i jak będą się one zmieniały”.

Specyfikacja w posta­ci listy wyma­gań funk­cjo­nal­nych i nie­funk­cjo­nal­nych nie­ste­ty nie chro­ni przed ryzy­kiem kosz­tow­nych zmian w przy­szło­ści. Jedynym wyj­ściem jest wyspe­cy­fi­ko­wa­nie w doku­men­cie wyma­gań szcze­gó­łów logi­ki biz­ne­so­wej w posta­ci pro­jek­tu (mode­lu struk­tu­ry wzor­ca) jakie­go ocze­ku­je­my od dostawcy.

Wiele doku­men­tów ana­liz zawie­ra sta­tycz­ne tabe­le dopusz­czal­nych sta­nów obiek­tów imple­men­to­wa­ne na żyw­ca” czy­li wprost, ich zmia­na wyma­ga pra­cy pro­gra­mi­sty. W efek­cie sys­tem jest bar­dzo kosz­tow­ny w samym posia­da­niu i korzy­sta­niu z nie­go, a jak wie­my śro­do­wi­sko biz­ne­so­we jest zmien­ne. Środowisko doku­men­tów biz­ne­so­wych jest szcze­gól­nie zmien­ne. Tu wyma­ga­nie (doku­ment wyma­gań) nie może sta­no­wić tabli­cy (skoń­czo­nej listy) dopusz­czal­nych sta­tu­sów, cze­go nie raz żąda wie­lu dostaw­ców oprogramowania.

To są skut­ki sto­so­wa­nia (czę­sto) wzor­ca State Machine do budo­wy sys­te­mów wspo­ma­ga­ją­cy prze­pływ pra­cy. Wzorzec ten jest czę­sto sto­so­wa­ny w sys­te­mach ERP do kon­tro­li poje­dyn­czych doku­men­tów ale moim zda­niem kom­plet­nie nie nada­je się do imple­men­ta­cji sys­te­mów zarzą­dza­ją­cych prze­pły­wem pra­cy. To nie jest przy­pa­dek, że wie­lu dostaw­ców sys­te­mów ERP zale­ca jed­nak inte­gra­cję z jakimś dobrym work­flow” zamiast bar­dzo kosz­tow­nej kasto­mi­za­cji (o tym już tu nie raz pisałem).

Co z tym zro­bić? Kupujący nie ma moż­li­wo­ści spraw­dze­nia wnę­trza pro­gra­mu (tego jak zosta­ło zapro­jek­to­wa­ne) jeże­li kupu­je goto­we. Musi bar­dzo inte­li­gent­nie” sta­wiać wyma­ga­nia na opro­gra­mo­wa­nie by wychwy­cić wady jego pro­jek­tu mogą­ce wywo­łać lawi­nę kosz­tów pod­czas zwy­kłe­go uży­wa­nia”. Jeżeli zapa­da decy­zja o pro­jek­cie dedy­ko­wa­nym war­to poku­sić się o dobre­go ana­li­ty­ka i projektanta.

A co gdy kupu­je­my sami i goto­we? Proponuję np. umiesz­cze­nie w spe­cy­fi­ka­cji wyma­gań zgod­no­ści z wzor­cem (meta­mo­de­lem) WfMC oraz wyma­ga­nie moż­li­wo­ści pra­cy (dekre­tu) ad-hoc, a potem spraw­dzać czy nas nie oszu­ka­no… Ale zwra­cam uwa­gę na ryzy­ko, że nie ma pro­stej zasa­dy zawsze taki wzorzec” …

P.S.

Do czy­ta­ją­cych to pro­gra­mi­stów: jak znaj­dzie­cie jakieś uchy­bie­nie – pro­szę o litość 😉 i wska­za­nie błę­dów w posta­ci komentarzy 🙂

Inne artykuły na podobny temat

Komentarze

  1. Sławek Sobótka 23 stycznia 2012 at 18:16

    Maszyna sta­nów – jak każ­dy pat­tern – słu­ży w pew­nym kon­tek­ście, w innym prze­szka­dza a w jesz­cze innym szkodzi.
    Kiedy war­to: 1) obiekt ma kil­ka odpo­wie­dzial­no­ści, któ­rych spo­sób reali­za­cji zale­ży od wewnętrz­ne­go sta­nu, oraz 2) w przy­szło­ści spo­dzie­wam się poja­wia nowych sta­nów ale nie spo­dzie­wam się poja­wia­nia nowych odpowiedzialności.

    Jeżeli zacho­dzi jedy­nie 1) wów­czas na pozio­mie impl. wystar­czy pro­sty switch. Wprowadzanie maszy­ny jest nad­mia­ro­we. Chyba, że chce­my w fan­cy spo­sób zwięk­szyć testa­bi­li­ty. Maszyna zaczy­na się opła­cać” gdy zacho­dzi rów­nież 2).

    W Twoim przy­kła­dzie mamy kon­tekst na pozio­mie sta­tu­su w struk­tu­rze danych, dla­te­go podam przy­kład gdzie poja­wia się zachowanie:
    Otwórzmy sobie wdzię­czy pro­gram Paint. Swego cza­su two­rzy­łem apli­ka­cje tej kla­sy, więc zdra­dzę jaką mają wewnętrz­ną mechanikę.
    Klikając na kan­wę, wysy­ła­my do niej jeden z kil­ku sygna­łów: naci­śnię­to kla­wisz mysz­ki, prze­su­nię­to mysz­kę, zwol­nio­no kla­wisz mysz­ki. Kanwa ma 3 odpo­wie­dzial­no­ści – reak­cja zda­rze­nia mysz­ki. Jak powin­na zare­ago­wać? A to zale­ży od jej sta­nu. Przy pomo­cy przy­bor­ni­ka prze­łą­cza­my kan­wę w sta­ny: spray, ołó­wek, gum­ka itd.

    Wiem, że nor­mal­ny czło­wiek nie postrze­ga inte­gra­cji z Paintem w kate­go­riach zmia­ny sta­nu kan­wy, ale tak jest naj­wy­god­niej imple­men­to­wać. Dlaczego?
    Bo odpo­wie­dzial­no­ści kan­wy są sta­łe (kil­ka­na­ście zda­rzeń z mysz­ki i z kla­wia­tu­ry) i w tym wypad­ku wręcz niezmienne.
    Natomiast spo­so­by obsłu­że­nia tych odpo­wie­dzial­no­ści (sta­ny) – w tym wypad­ku przy­bor­nik narzę­dzi – może roz­bu­do­wy­wać. W zaawan­so­wa­nych pro­gra­mach może­my insta­lo­wać plu­igny, któ­re po pro­stu wno­szą nowe sta­ny (wraz z logi­ką obsłu­gi) do kan­wy, któ­ra jest nie­zmien­na – pocho­dzi z core”.

    Tak więc maszy­na sta­nów zaczy­na mieć sens, gdy mamy odpowiedzialności.

    Kolejna kwe­sta to prze­łą­cza­nie się sta­nów. Gdzie powin­na znaj­do­wać się logi­ka mówią­ca o tym w jaki kolej­ny stan przejść po wyko­na­niu logi­ki z dane­go sta­nu. Czyli przy­kła­do­wo gdy jestem w StanieSaznaczania, wów­czas zwol­nie­nie kla­wi­sza mysz­ki może sko­pio­wać do pamię­ci zazna­czo­ny frag­ment, obry­so­wać go na kan­wie prze­ry­wa­ną linią i… zasu­ge­ro­wać kan­wie aby prze­łą­czy­ła się w StanPrzesuwania. Kanwa może to oczy­wi­ście zigno­ro­wać. Ale war­to zwró­cić uwa­gę, że trzy­ma­nie logi­ki decy­du­ją­cej o przej­ściach w sta­nach pozwa­la doda­wać nowe sta­ny (plu­gi­ny) bez mody­fi­ka­cji kan­wy (core).

    • Jarek Żeliński 23 stycznia 2012 at 19:56

      Rozumiem, ale chy­ba opi­sa­łeś wła­śnie sytu­acje gdy logi­ka zmia­ny sta­nów jest zamknię­ta w obiek­cie (agre­ga­cie) sta­no­wym bo tu ma to jak naj­bar­dziej sens. Dokumenty mają pew­ną spe­cy­fi­kę: nie wie­dzą jak będą prze­twa­rza­ne. Każda fir­ma robi to po swo­je­mu. Do tego regu­ły mogą być zmie­nia­ne. Pierwszy raz się spo­tka­łem z pro­ble­mem gdy musia­łem opra­co­wać model logi­ki instruk­cji kan­ce­la­ryj­nej w pew­nym urzę­dzie. Potem oka­za­ło się, że to pro­blem każ­dej sytu­acji gdy to np. aktor ma wie­dzę jaki sta­tus ma uzy­skać obiekt. Klasyczna sytu­acja dekre­to­wa­nia doku­men­tu: sta­tu­sem jest mię­dzy inny­mi tak zwa­ny punkt zatrzy­ma­nia, a usta­wia go (do kogo prze­ka­zać doku­ment) oso­ba dekre­tu­ją­ca. Tu widzę raczej zwią­zek z wzor­cem stra­te­gii (saga?): stra­te­gia sko­ja­rzo­na z doku­men­tem daje jego zapla­no­wa­ną ścieżkę.

  2. Sławek Sobótka 23 stycznia 2012 at 21:31

    Logika jest zamknię­ta w agre­ga­cie w sen­sie takim, że z zewnątrz nie moż­na usta­wić agre­ga­to­wi sta­nu. Wykonujemy na nim ope­ra­cje, któ­re skut­ku­ją zmia­ną sta­nu – tak to wyglą­da z zewnątrz.

    Ale wybór kolej­ne­go sta­nu tak na praw­dę nale­ży do sta­nu aktualnego.
    Przykład:

    class Canvas{
    pri­va­te State state;
    public void mouseClick(x,y){
    //wspólna logika
    sta­te = state.handleClicking(x,y)
    //wspólna logika
    }
    }

    aku­rat w tym wypad­ku Kanwa musi mieć *dodat­ko­wo* moż­li­wość usta­wia­nia aktu­al­ne­go sta­nu, ponie­waż takie są wymagania.

    Co do stra­te­gii, to patrząc z odpo­wied­nie­go dystan­su taki stan to nic inne­go jak muli-stra­te­gia, któ­ra dodat­ko­wo prze­łą­cza strategie:)

    Czyli bar­dziej ogól­nie: czyn­ność jest obiektem.

  3. jacek2v 24 stycznia 2012 at 11:32

    Status Zamknięte i Otwarte nie jest cechą ani zam­ka, ani drzwi ani nawet miesz­ka­nia tyl­ko jest to efekt naszej woli (miesz­kań­ca). ”
    Jak dla mnie to jest kla­sycz­ny pro­blem foku­sa”, tzn. na czym się sku­pia­my pod­czas pro­jek­to­wa­nia, co jest istot­ne dla projektu.
    Jeśli sys­tem obej­mu­je tyl­ko drzwi z zam­kiem (O, Z) to nie inte­re­su­je nas kto, co i jak je zmie­nia – daje­my meto­dy Otwórz i Zamknij – nie waż­ne czy to zro­bio­no klu­czem czy wytry­chem (pomi­jam wej­ście na rympał :))
    Jeśli inte­re­su­je nas kto otwo­rzył i czym to gra­ni­cą sys­te­mu” będzie oso­ba i wte­dy mode­lu­je­my, zawie­ra­my w pro­jek­cie jej interakcję.
    Podsumowując, wszyst­ko zale­ży od tego jakie wyzna­czy­my gra­ni­ce sys­te­mu, a te zale­żą od wyma­gań i celu jaki chce się osiągnąć.

    • Jarek Żeliński 24 stycznia 2012 at 11:40

      Dokładnie tak, dla­te­go celo­wo zwró­ci­łem uwa­gę na kon­tekst sys­te­mów work­flow bo tu gra­ni­ca sys­te­mu nie zawsze jest łatwa do usta­le­nia, po dru­gie pro­sty Przypadek Użycia dla Systemu, jeże­li mode­lu­je­my drzwi to jak naj­bar­dziej sta­tu­sy są w drzwiach” (Aktor nie ma wpły­wu na kon­struk­cje drzwi, może ich wyłącz­nie uży­wać), jeże­li mode­lu­je­my układ miesz­ka­nie jako sys­tem ‑miesz­ka­niec jako aktor” to sta­tus jest usta­la­ny przez miesz­kań­ca i on usta­la jakie mogą być sta­ny jego miesz­ka­nia bo ma nad tym wła­dzę”. Bardzo waż­ne jest zro­zu­mie­nie w toku ana­li­zy isto­ty rze­czy” oraz, jak słusz­nie zauwa­ży­łeś, usta­le­nie gra­ni­cy systemu.

  4. jacek2v 24 stycznia 2012 at 12:08

    Wzorzec ten jest czę­sto sto­so­wa­ny w sys­te­mach ERP do kon­tro­li poje­dyn­czych doku­men­tów ale moim zda­niem kom­plet­nie nie nada­je się do imple­men­ta­cji sys­te­mów zarzą­dza­ją­cych prze­pły­wem pra­cy. To nie jest przy­pa­dek, że wie­lu dostaw­ców sys­te­mów ERP zale­ca jed­nak inte­gra­cję z jakimś ?dobrym work­flow? zamiast bar­dzo kosz­tow­nej kasto­mi­za­cji (o tym już tu nie raz pisałem).”
    Stosowanie StateMachine do WF nie wyda­je mi się pro­ble­mem same­go mode­lu, ale spo­so­bu reali­za­cji SM w apli­ka­cji (w tym przy­pad­ku ERP) – wspo­mnia­ny nakład pra­cy programisty. 

    Widzę tu pewien pod­sta­wo­wy pro­blem, któ­ry będzie boleć: zbyt dokład­ną pró­bę odwzo­ro­wa­nia dyna­mi­ki sys­te­mu w mode­lu sta­tycz­nym. To bar­dzo dużo kosz­tu­je – w pie­nią­dzach, wydaj­no­ści, utrzy­ma­niu w ruchu itd.
    Proponuję inne spoj­rze­nie: nie­waż­ne, czy w rze­czy­wi­sto­ści obiekt jest doku­men­tem, czy też aktyw­no­ścią (dla mnie to inna nazwa zada­nia) i takie zało­że­nie wystar­czy. Można wte­dy sto­so­wać SM do obu przypadków.
    Zamek: Otwarte/Zamknięte
    Zadanie: W trakcie/Zakończono

    BTW: Niezależnie od mode­lo­wa­nia, SM zawsze musi być uży­ty (nie­jaw­nie) na pozio­mie imple­men­ta­cji – gdzieś musi­my trzy­mać stan :).

    • Jarek Żeliński 24 stycznia 2012 at 13:02

      Owszem, ale trzy­ma­nie sta­nu a logi­ka i meto­da jego usta­wia­nia to dwa odręb­ne pro­ble­my :). SM to nie trzy­ma­nie sta­nu (do tego wystar­czy np. jeden atry­but) a logi­ka (spo­sób) jego zmien­no­ści. Masz rację, trak­to­wa­nie takie­go ERP jako sta­tycz­ne­go sys­te­mu jest chy­ba głów­ną bolącz­ką wie­lu sys­te­mów ERP. Moim zda­niem jest to kon­se­kwen­cja kon­struk­cji baza danych i funk­cje prze­twa­rza­ją­ca te dane”. Jeżeli naście lat temu fir­my były sta­tycz­ne” i moż­na je było opi­sać rela­tyw­nie pro­stym mode­lem rela­cyj­nym, tak dzi­siaj jest to już wg. mnie nie moż­li­we. Jeżeli uznać, że wie­le doku­men­tów jest prze­twa­rza­nych ad-hoc to zna­czy, że każ­dy z nich jest uni­kal­ną maszy­ną sta­no­wą gdzie sta­ny są usta­wia­ne dyna­micz­nie i co gor­sza nie są z góry zna­ne. I tu widzę pro­blem sto­so­wa­nie pro­stych wzor­ców SM.

    • jacek2v 25 stycznia 2012 at 08:31

      SM to nie trzy­ma­nie sta­nu (do tego wystar­czy np. jeden atry­but) a logi­ka (spo­sób) jego zmienności”
      Tu się nie zgo­dzę. Podstawą SM jest wła­śnie trzy­ma­nie sta­nu. Zgadzam się cza­sa­mi wystar­czy jeden atry­but, ale cza­sa­mi 🙂 Gorzej jak nie ma gdzie atry­bu­tu wstawić 🙂
      Moim zda­niem, każ­dy WF moż­na zaim­ple­men­to­wać za pomo­cą SM. Wystarczy zasto­so­wać wzo­rzec SM do SM 🙂 Czyli utwo­rzyć oddziel­ny byt (obiekt) któ­ry jest stanem.
      Podobnie opi­sy­wa­na tu zmia­na w mode­lu biz­ne­so­wym (nowe sta­ny fak­tu­ry). Wystarczy zasto­so­wać SM do ist­nie­ją­ce­go mode­lu, czy wer­sjo­no­wać stany/system/model/obiekty – zależ­nie od potrzeb.
      Takim dobrym przy­kła­dem jest biblio­te­ka pre­vay­ler (Java) w któ­rej sam kod metod jest zarzą­dza­ny przez SM.

    • Jarek Żeliński 25 stycznia 2012 at 11:10

      Racja pod warun­kiem, że wią­że­my logi­kę zacho­wa­nia obiek­tu z nim samym a nie zawsze tak jest, typo­wym przy­kła­dem są obce doku­men­ty prze­twa­rza­ne w spo­sób ad-hoc narzu­co­ny przez użyt­kow­ni­ka, zary­zy­ku­ję tezę, że im bar­dziej kom­pe­tent­ny użyt­kow­nik tym mniej nada­je się work­flow bazu­ją­cy mode­lu SM… nie potę­piam wzor­ca SM, zwra­cam uwa­gę, że nie jest spo­so­bem na wszyst­ko”… zawsze może­my spo­tkać się z sytuacją:
      1. zacho­wa­nie obiek­tu jest jego wła­sną cechą, reagu­je na swo­je oto­cze­nie – wzo­rzec SM
      2. zacho­wa­nie obiek­tu jest mu narzu­co­ne z zewnątrz – obiekt jest zwy­kłem” obiek­tem o sta­nie zależ­nym od wyko­na­nych na nim operacji

      Przypadek 1. to stan­dar­do­we pro­ste i prze­wi­dy­wal­ne wnio­ski urlo­po­we, fak­tu­ry kosz­to­we itp. Przypadek 2. to pozo­sta­łe sytu­acje gdy pro­ces jest ste­ro­wa­ny przez wyko­naw­cę. Przykładem tego typu sys­te­mów są roz­wią­za­nia zbu­do­wa­ne dwóch pod­sys­te­mów: repo­zy­to­rium i motor pro­ce­so­wy. Repozytorium prze­cho­wu­je doku­men­ty i ich meta­da­ne ale to jakie będą one przyj­mo­wa­ny sta­tu­sy wie” motor pro­ce­su a nie doku­ment. Co cie­ka­we samo repo­zy­to­rium pozwa­la obsłu­żyć wie­le przy­pad­ków zarzą­dza­nia prze­pły­wem doku­men­tów, szcze­gól­nie tych ad-hoc.

      Aha… moż­na (tak sądzę) reali­zo­wać model, w któ­rych obiekt biz­ne­so­wy będzie miał wstrzy­ki­wa­ną odpo­wied­nią” maszy­nę sta­no­wą SM… 

    • jacek2v 25 stycznia 2012 at 12:11

      2. zacho­wa­nie obiek­tu jest mu narzu­co­ne z zewnątrz ? obiekt jest ?zwy­kłem? obiek­tem o sta­nie zależ­nym od wyko­na­nych na nim operacji”
      Na to też jest pro­ste roz­wią­za­nie roz­wią­za­ne zna­ne z pro­jek­tów inte­gra­cyj­nych: koper­ta. Opakowujemy obiekt obcy, wła­snym obiek­tem i trzy­ma­my wła­sne sta­ny, któ­re oczy­wi­ście mogą lub muszą wyni­kać ze sta­nów obcych, ale są zmie­nia­ne przez nasze metody.
      Uważam, że my powin­ni­śmy zawsze wie­dzieć jakie sta­ny chce­my prze­cho­wy­wać – jeże­li nie wie­my to jak może­my na nie reago­wać :). Jeśli jed­na nie zna­my sta­nów, to może­my budo­wać obiek­ty ze sta­na­mi abs­trak­cyj­ny­mi (string, obiekt typu object itp.), ale wte­dy model jest nieczytelny.
      Jak dla mnie: SM everywhere 🙂

    • Jarek Żeliński 25 stycznia 2012 at 19:47

      Uważam, że my powin­ni­śmy zawsze wie­dzieć jakie sta­ny chce­my prze­cho­wy­wać ? jeże­li nie wie­my to jak może­my na nie reagować”
      Wyobraźmy sobie, że Zarząd fir­my na zmia­nę z usta­wo­daw­cą ser­wu­ją nam co jakiś nowe lub zmie­nio­ne regu­ły” biz­ne­so­we (nowe pro­gi zatwier­dza­nia kosz­tów, nowe sta­ny w pro­ce­sie win­dy­ka­cji, zmia­na instruk­cji kan­ce­la­ryj­nej i nowe kody JRWA w Urzędzie itp.). Nazwy (kody) tych sta­nów (sta­tu­sów) więc poja­wia­ją się ad-hoc, nie będzie­my ich zna­li na eta­pie pro­jek­to­wa­nia sys­te­mu ale musi­my je póź­niej obsłu­gi­wać np. w celu prze­ka­zy­wa­nia wła­ści­wym (nowym) oso­bom czy po pro­stu do wyszu­ki­wa­nia spraw na danym eta­pie”. To kla­sycz­na sytu­acja gdy obiekt sta­no­wy nie jest panem” swo­ich sta­tu­sów (to przy­kła­dy z projektów).

  5. jacek2v 25 stycznia 2012 at 22:12

    To kla­sycz­na sytu­acja gdy obiekt sta­no­wy nie jest ?panem? swo­ich sta­tu­sów (to przy­kła­dy z projektów)”
    On nadal jest panem” swo­ich sta­tu­sów, tyl­ko nastę­pu­je zmia­na sta­tu­sów i zacho­wa­nia (bo nowe sta­tu­sy) – de fac­to nastę­pu­je zmia­na obiek­tu pan” :). Nie ma co się oszu­ki­wać, każ­da zmia­na typu (kla­sy) prze­twa­rza­nych danych pocią­ga za sobą zmia­nę dzia­ła i koniecz­ne jest pro­gra­mo­wa­nie. Cała sztucz­ka pole­ga na tym, aby prze­wi­dzieć moż­li­wość roz­bu­do­wy mode­lu danych bez jego kom­pli­ko­wa­nia (nale­ży cały czas pamię­tać, że pro­gra­mo­wa­nia się nie unik­nie). Dlatego moim zda­nie jest to jeden z tych momen­tów, w któ­rych projektowanie/programowanie obiek­to­we przy­no­si korzy­ści, a dokład­nie powią­za­nie danych z dzia­ła­nia­mi. Przy peł­nym obiek­to­wym podej­ściu oraz paru algorytmom/wzorcom (np. lazy upda­tes) bar­dzo łatwo jest roz­bu­do­wy­wać nawet duże i roz­bu­do­wa­nie apli­ka­cje, uzy­sku­jąc sta­bil­ne jako­ścio­wo dzia­ła­nie. Co prze­szka­dza i utrud­nia ? Mapowanie na bazy SQL 🙂

  6. Bartek 1 lutego 2012 at 09:04

    Witam,

    Świetny wpis i jesz­cze lep­sza dys­ku­sja w komen­ta­rzach. Tak się zło­ży­ło, że od 4 lat budu­ję sys­te­my w któ­rych obieg doku­men­tów, pra­cy lub ogól­nie pew­nych bytów jest głów­nym pro­ble­mem. W pew­nym roz­wią­za­niu zasto­so­wa­li­śmy kla­sycz­ną SM, ale obieg był bar­dzo szcze­gó­ło­wo zde­fi­nio­wa­ny. Kiedy jed­nak w innym pro­jek­cie oka­za­ło się, że obie­gi są na tyle skom­pli­ko­wa­ne i nie­prze­wi­dy­wal­ne, że nie dało się ich mode­lo­wać z wyko­rzy­sta­niem SM. Po pro­stu użyt­kow­nik nie był w sta­nie okre­ślić co się może wyda­rzyć w następ­nym eta­pie i jak będzie wyglą­da­ło prze­twa­rza­nie obiek­tu. Zwykle stan trzy­ma­ny był w obiek­cie w posta­ci atry­bu­tu, a jego zmia­ny wywo­ły­wa­ły róż­ne inne obiek­ty, np. kla­sa Dekretacja. Powoduje to jed­nak strasz­ny bała­gan i pro­ble­my z zarzą­dza­niem funkcjonalnościami.

    Teraz już tro­chę za póź­no, ale wyda­je mi się, że podej­ście przed­sta­wio­ne we wpi­sie, w przy­pad­ku powyż­szym dało­by nie­złe wyniki.

  7. Tomasz Framski 8 lutego 2012 at 09:44

    Byłem na Pana wystą­pie­niu pod­czas kon­fe­ren­cji Gigacon w Krakowie. Na tej kon­fe­ren­cji wła­śnie poru­szył Pan ten temat. Naprawdę byłem pod wra­że­niem w jaki spo­sób Pan przed­sta­wił róż­ni­ce pomie­dzy maszy­ną sta­no­wą a sys­te­mem work­flow w kon­tek­ście doku­men­tów (obiek­tów).
    Mam za sobą parę wdro­żeń opar­tych na sil­ni­kach work­flow (zgod­nych z wfmc​.org) i życzył­bym sobie po stro­nie Klienta takiej wła­śnie wiedzy.
    A obieg doku­men­tów opar­tych na ich sta­nach – to począ­tek kla­py pro­jek­tu zanim się zaczął.
    Pozdrawiam.

    • Jarek Żeliński 8 lutego 2012 at 21:23

      Witam. Pozostaje mi podzię­ko­wać za dobre sło­wo i życzyć wszyst­kie­go dobre­go. Mamy podob­ne doświad­cze­nia, nie wiem cze­mu ludzie się tak upie­ra­ją pzrey tej maszy­nie sta­no­wej w pro­jek­tach work­flow… mogę się tyl­ko domy­ślać, że więk­szość korzy­sta z gotow­ców a te maja dobre 15 lat.…wtedy maszy­na sta­no­wa się przy­da­wa­ła do pro­stych FK/magazyn…

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.