Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

Problem

Bardzo czę­sto, na począt­ko­wym eta­pie pro­jek­to­wa­nia, chce­my poka­zać nie tyl­ko archi­tek­tu­rę, ale tak­że kon­cep­cję dzia­ła­nia sys­te­mu, mimo tego, że nie dopra­co­wa­li­śmy jesz­cze deta­li. Mamy kom­po­nen­ty ale nie mamy jesz­cze ich ope­ra­cji. Chcemy jed­nak udo­ku­men­to­wać nasz pomysł, poka­zać i omó­wić, zanim opra­cu­je­my deta­le (bo jeste­śmy agile).

Od począt­ku (powin­ni­śmy mieć) umo­wę czy­li zakres projektu:

Zakres pro­jek­tu czy­li usłu­ga apli­ka­cji (nota­cja UML, dia­gram Przypadków Użycia)

Wiemy kto: aktor, będzie uży­wał apli­ka­cji: sys­tem, i wie­my jaką usłu­gę ma ona świad­czyć akto­ro­wi: Use Case. 

UWAGA! Usługa sys­te­mu to nie cel akto­ra. Celem akto­ra jest np. kon­tro­la sprze­da­ży” albo nad­zór sprze­daw­ców”, a reali­zo­wa­na (wyma­ga­na) usłu­ga sys­te­mu to raport marży”. 

Pozostaje opra­co­wać pomysł na reali­za­cję tego roz­wią­za­nia, a deta­le opra­co­wa­ne będą póź­niej . Więcej o tym jak opi­sać deta­le: Przypadki uży­cia i ich deta­le oraz Paradygmat obiek­to­wy i Przypadki Użycia.

Dokumentowanie rozwiązania

Kolejny krok to opra­co­wać szkie­let architektury:

Architektura reali­za­cji usłu­gi apli­ka­cyj­nej (nota­cja UML, dia­gram klas)

Zgodnie z wzor­ca­mi i naj­lep­szy­mi prak­ty­ka­mi, dzie­li­my sys­tem na ele­men­ty o wąskiej i dobrze okre­ślo­nej spe­cja­li­za­cji, pro­jek­tu­je­my kom­po­nen­ty odpo­wie­dzial­ne za: reali­za­cję sce­na­riu­sza obsłu­gi akto­ra (Use Case), reali­za­cję logi­ki biz­ne­so­wej (Logika) oraz za zacho­wy­wa­nie danych (Repozytorium ) (patrz tak­że ). I chce­my na razie szyb­ko poka­zać nasz pomysł na to jak to ma działać:

Realizacja usłu­gi apli­ka­cji, model poglą­do­wy (dia­gram aktyw­no­ści, nota­cja UML)

Na dia­gra­mie aktyw­no­ści powy­żej, par­ty­cje repre­zen­tu­ją kom­po­nen­ty nasze­go sys­te­mu. Odpowiedzialności (role) poszcze­gól­nych kom­po­nen­tów opi­su­ją nazwy aktyw­no­ści jakie im przy­po­rząd­ko­wa­no. Całość poka­zu­je jaki kom­po­nen­ty, w jakiej kolej­no­ści i jak (za odpo­wia­da­ją), zre­ali­zu­ją naszą usłu­gę. Ten dia­gram peł­ni role opi­so­wą, poka­zu­je odpo­wie­dzial­ność kom­po­nen­tów oraz prze­bieg pro­ce­du­ry reali­za­cji usłu­gi aplikacji. 

W kolej­nym eta­pie pra­cy nad mode­lem może­my dodat­ko­wo poka­zać prze­pływ obiek­tów nio­są­cych dane (Formularz), uzu­peł­nia­my więc powyż­szy diagram:

Realizacja usłu­gi apli­ka­cji, model poglą­do­wy wraz z obiek­tem nio­są­cym dane (dia­gram aktyw­no­ści, nota­cja UML) 

Znakomita więk­szość wyma­gań biz­ne­so­wych i funk­cjo­nal­nych jest reali­zo­wa­na jako treść for­mu­la­rza (struk­tu­ra doku­men­tu) wraz z logi­ką rzą­dzą­cą ich tre­ścią (tak zwa­ne wali­da­cje) i związ­ka­mi mię­dzy atry­bu­ta­mi dokumentów:

Struktura Formularza (infor­ma­cji na doku­men­cie) (dia­gram struk­tur zło­żo­nych, nota­cja UML)

Powyższy dia­gram to nasz doku­ment nio­są­cy dane (Formularz), będą­cy zara­zem mode­lem danych (w meto­dach obiek­to­wych nazy­wa­my to tak­że agre­ga­tem). Jeżeli poja­wia sie wyma­ga­nie np. System ma infor­mo­wać dłuż­ni­ka SMS-em o sal­dzie rachun­ku”, to ozna­cza to (reali­za­cja tego wyma­ga­nia), że w doku­men­cie (zestaw danych) Karta Klienta, ma sie poja­wić tak­że pole (atry­but) numer tele­fo­nu komór­ko­we­go”, a nasz sys­tem (dia­gram przy­pad­ków uży­cia) ma mieć dodat­ko­we­go akto­ra jakim jest ser­wer SMTP i wska­zu­je­my, któ­ry kom­po­nent zre­ali­zu­je to zadanie. 

W meto­dach (para­dyg­mat) obiek­to­wych nie two­rzy­my rela­cyj­nych mode­li danych i nie uży­wa­my SQL na eta­pie ana­li­zy i projektowania. 

Po uzu­peł­nie­niu pro­jek­tu Formularza o deta­le (atry­bu­ty) otrzy­mu­je­my (dia­gram poni­żej pra­wa stro­na: Document):

Architektura reali­za­cji usłu­gi apli­ka­cyj­nej uzu­peł­nio­na o atry­bu­ty for­mu­la­rza (nota­cja UML, dia­gram klas) 

Kolejny etap ana­li­zy i pro­jek­to­wa­nia, czy­li pora na kolej­ne deta­le: pre­cy­zyj­ny sce­na­riusz, jego celem jest test logi­ki pro­ce­du­ry i uzu­peł­nie­nie powyż­szych klas o wyma­ga­ne do tego operacje:

Scenariusz przy­pad­ku uży­cia udo­ku­men­to­wa­ny jako pro­ce­du­ra (dia­gram sekwen­cji, nota­cja UML)

Operacje klas to nazwy ich wywo­łań na powyż­szym dia­gra­mie. Na tym eta­pie, pro­jek­tu­je­my deta­le komu­ni­ka­cji kom­po­nen­tów, pro­jek­tu­jąc tę komu­ni­ka­cję wyzna­czy­li­śmy ope­ra­cje dla poszcze­gól­nych klas. Powyższy dia­gram to pro­jekt i zara­zem test logi­ki reali­za­cji usłu­gi, mode­lo­wa­nej jako przy­pa­dek uży­cia apli­ka­cji. Po opra­co­wa­niu tego mode­lu mamy wię­cej danych o kom­po­nen­tach, zna­my też już ich ope­ra­cje i ich parametry:

Architektura reali­za­cji usłu­gi apli­ka­cyj­nej uzu­peł­nio­na o atry­bu­ty for­mu­la­rza i ope­ra­cje klas (nota­cja UML, dia­gram klas) 

Mamy już więc archi­tek­tu­rę oraz ope­ra­cje klas, dla reali­za­cji nazwa­nej na dia­gra­mie Przypadków Użycia usłu­gi apli­ka­cyj­nej. Całość jest spój­na, bo dia­gram sekwen­cji jest pro­jek­tem i zara­zem dowo­dem popraw­no­ści i spój­no­ści komu­ni­ka­cji klas.

Kolejny etap to doku­men­to­wa­nie metod ope­ra­cji (algo­rytm), tu meto­da ope­ra­cji Zachowaj” kla­sy Repozytorium” (to tak­że pro­ce­du­ra ale niż­szym pozio­mie abstrakcji):

Procedura wyko­na­nia ope­ra­cji Zachowaj wyra­żo­na dia­gra­mem aktyw­no­ści (nota­cja UML).

I tym spo­so­bem opra­co­wa­li­śmy pro­jekt reali­za­cji jed­nej usłu­gi naszej apli­ka­cji. Można już zle­cić jej imple­men­ta­cję (kodo­wa­nie), a w tym cza­sie zająć się ana­li­zą i pro­jek­to­wa­niem kolej­nej. To się nazy­wa orien­ta­cja na mikro­ser­wi­sy i ite­ra­cyj­no-przy­ro­sto­we kon­stru­owa­nie opro­gra­mo­wa­nia. Metoda ana­li­zy i pro­jek­to­wa­nia od ogó­łu do szcze­gó­łu, z podzia­łem na kom­po­nen­ty, nie jest nowa. Pierwsze opi­sy podzia­łu dużych sys­te­mów na sepa­ro­wa­ne kom­po­nen­ty to lata 90-te a pro­jek­to­wa­nie zorien­to­wa­ne na odpo­wie­dzial­ność klas to począt­ki lat 2000 . Rosnąca zło­żo­ność opro­gra­mo­wa­nia i wyma­ga­nia na krót­ki czas dostar­cze­nia pro­duk­tu, w zasa­dzie nie pozwa­la już na inny styl pro­jek­to­wa­nia i imple­men­ta­cji, bez tego cofa­my sie do metod z lat 70-tych zwa­nych water­fall”.

Podsumowanie

Jednym z naj­więk­szych kosz­tów pro­jek­tów jest pro­to­ty­po­wa­nie na żywym cie­le”, czy­li roz­po­czy­na­nie pra­cy od razu na kodzie. Etap ana­li­zy i pro­jek­to­wa­nia z uży­ciem UML jest co naj­mniej o rząd wiel­ko­ści tań­szy. Opracowanie powyż­sze­go mode­lu przez oso­bę mają­cą doświad­cze­nie i dobre narzę­dzie (ja uży­wam Visual Paradigm) zaj­mu­je ok. godzi­ny (to jest oczy­wi­ście poprze­dzo­ne ana­li­zą biz­ne­so­wą czy­li okre­ślo­no i zro­zu­mia­no problem). 

Diagramy aktyw­no­ści dosko­na­le się spraw­dza­ją na eta­pie poprze­dza­ją­cym opra­co­wa­nie deta­li (dia­gram sekwen­cji). Można opra­co­wać, prze­te­sto­wać i skon­sul­to­wać kon­cep­cję reali­za­cji usłu­gi (pomysł), bez stra­ty cza­su na bar­dziej wyma­ga­ją­cy dia­gram sekwencji. 

Po dru­gie dia­gram aktyw­no­ści w opi­sa­nej tu posta­ci, jest two­rzo­ny (ety­kie­ty) z uży­ciem języ­ka natu­ral­ne­go (co bar­dzo pole­cam), dzię­ki cze­mu spon­sor pro­jek­tu i inte­re­sa­riu­sze, są w sta­nie aktyw­nie uczest­ni­czyć nawet na tym eta­pie pro­jek­tu, co zna­ko­mi­cie uspraw­nia pro­ces zgła­sza­nia uwag, zanim doj­dzie­my do naj­kosz­tow­niej­sze­go eta­pu czy­li do zaan­ga­żo­wa­nia programistów. 

Stosowanie sche­ma­tów blo­ko­wych jak wyżej, pro­wa­dzi do powsta­nia bar­dzo pre­cy­zyj­nej spe­cy­fi­ka­cji. Nie raz już wyka­za­no, że opi­sy wyma­gań wyko­na­ne języ­kiem natu­ral­nym bez sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych, tak zwa­ne histo­ryj­ki użyt­kow­ni­ka czy wyma­ga­nia pisa­ne języ­kiem natu­ral­nym, są tak bar­dzo nie­jed­no­znacz­ne, że są uzna­wa­ne za jed­ną z klu­czo­wych przy­czyn pora­żek pro­jek­tów infor­ma­tycz­nych .

Projekt udo­ku­men­to­wa­ny powyż­szy­mi meto­da­mi sta­no­wi pre­cy­zyj­ny logicz­ny opis, jest to Opis Techniczny Oprogramowania. Taki doku­ment jest chro­nio­ny pra­wem autor­skim, jego treść to logi­ka biz­ne­so­wa, czy­li pre­cy­zyj­nie opi­sa­ne know-how spon­so­ra pro­jek­tu. Developer two­rzą­cy imple­men­ta­cję na pod­sta­wie takiej doku­men­ta­cji, two­rzy utwór zależ­ny, co zna­czy, że ma autor­skie pra­wa oso­bi­ste do napi­sa­ne­go kodu, ale nie ma pra­wa do dys­po­no­wa­nia nim. Innymi sło­wy w umo­wie zwy­kłą for­mal­no­ścią jest to, że pro­gra­mi­sta w ramach wyna­gro­dze­nia pokry­wa­ją­ce­go koszt powsta­nia kodu, prze­ka­zu­je pra­wa mająt­ko­we do nie­go (albo po pro­stu nie dosta­nie tego zle­ce­nia, patrz tak­że arty­kuł Ochrona war­to­ści inte­lek­tu­al­nych i know-how w orga­ni­za­cji).

Polecam tak­że arty­kuł zawie­ra­ją­cy wię­cej deta­li o eta­pie pro­jek­to­wa­nia, zawie­ra­ją­cy kom­plet­ny pro­jekt: Biblioteka.

Źródła

Object Management Group. (2008). About the Software & Systems Process Engineering Metamodel Specification Version 2.0 (SPEM). https://​www​.omg​.org/​s​p​e​c​/​S​P​E​M​/​2​.​0​/​A​b​o​u​t​-​S​P​EM/
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Kama, N., French, T., & Reynolds, M. (2011). Design Patterns Consideration in Class Interactions Prediction Development. International Journal of Advanced Science and Technology, 28, 21.
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Halpin, T. A., Krogstie, J., & Proper, E. (Eds.). (2009). Innovations in infor­ma­tion sys­tems mode­ling: methods and best prac­ti­ces. Information Science Reference.
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
Steve Burbeck. (2012, July 29). How to use Model-View-Controller (MVC). https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
Miller, J., & Wirfs-Brock, R. (1999). How Can a Subsystem Be Both a Package and a Classifier? https://​doi​.org/​1​0​.​1​0​0​7/3 – 540-46852 – 8_41
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Shishkov, B. (2020). Designing enter­pri­se infor­ma­tion sys­tems mer­ging enter­pri­se mode­ling and softwa­re spe­ci­fi­ca­tion.
Wirfs-Brock, R., & McKean, A. (2009). Object design: roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 9 komentarzy

  1. Joanna Usidus

    W Specyfikacji OMG UML z 2017 roku jest zapis: Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and work­flow.” Jak się to ma do tezy, że nie mode­lu­je­my już pro­ce­sów biz­ne­so­wych dia­gra­mem aktyw­no­ści? Kto taką tezę propaguje?
    W dodat­ku, każ­dy ma pra­wo mode­lo­wać czym potra­fi oraz przy uży­ciu takich dia­gra­mów, jakie są zro­zu­mia­łe dla odbior­cy. Tak więc moc takie­go zale­ce­nia” była­by ade­kwat­na do poten­cjal­nie ogło­szo­ne­go zale­ce­nia nie cho­dzi­my już w klap­kach, cho­dzi­my w sandałach”…

    1. Jarosław Żeliński

      Ten zapis jest wyję­ty z kon­tek­stu, cały UML jest obec­nie wyłącz­nie nota­cją do mode­lo­wa­nia opro­gra­mo­wa­nia. Cały ten aka­pit brzmi:

      An Activity is a kind of Behavior (see sub clau­se 13.2) that is spe­ci­fied as a graph of nodes inter­con­nec­ted by edges. A
      sub­set of the nodes are exe­cu­ta­ble nodes that embo­dy lower-level steps in the ove­rall Activity. Object nodes hold data
      that is input to and out­put from exe­cu­ta­ble nodes, and moves across object flow edges. Control nodes specify
      sequ­en­cing of exe­cu­ta­ble nodes via con­trol flow edges. Activities are essen­tial­ly what are com­mon­ly cal­led ?con­trol and
      data flow? models. Such models of com­pu­ta­tion are inhe­ren­tly con­cur­rent, as any sequ­en­cing of acti­vi­ty node execution
      is mode­led expli­ci­tly by acti­vi­ty edges, and no orde­ring is man­da­ted for any com­pu­ta­tion not expli­ci­tly sequenced.
      Activities may descri­be pro­ce­du­ral com­pu­ta­tion, for­ming hie­rar­chies of Activities invo­king other Activities, or, in an
      object-orien­ted model, they may be invo­ked indi­rec­tly as methods bound to Operations that are direc­tly invoked.”

      Specyfikację inte­pre­tu­je­my w cało­ści, a nie fragmentami. 

      W dodat­ku, każ­dy ma pra­wo mode­lo­wać czym potra­fi oraz przy uży­ciu takich dia­gra­mów, jakie są zro­zu­mia­łe dla odbior­cy. Tak więc moc takie­go ?zale­ce­nia? była­by ade­kwat­na do poten­cjal­nie ogło­szo­ne­go zale­ce­nia ?nie cho­dzi­my już w klap­kach, cho­dzi­my w sandałach??”

      Notacje for­mal­ne nie słu­żą do uma­wia­nia się z odbior­ca­mi bo same z sie­bie są umo­wą, tak jak Kodeks Drogowy: jest iden­tycz­ny dla każ­de­go a nie jak my się uma­wia­my z inny­mi kie­row­ca­mi”. Po to OMG stan­da­ry­zu­je nota­cje by nie uma­wiać się z odbior­ca­mi”. Po dro­gach jeź­dzi­my tak jak każe Kodeks Drogowy a nie tak jak potrafimy”.

      Notacje mają taki sam sta­tus jak Normy, więc jeże­li audy­tor spor­nej doku­men­ta­cji stwier­dzi w niej nie­zgod­no­ści ze spe­cy­fi­ka­cją, ma pra­wa uznać doku­men­ta­cją za wadliwą.

      Zacytuje jed­ne­go z człon­ków OMG: UML to nie kolej­na biblio­te­ka sym­bo­li PowerPoint. 

  2. Joanna Usidus

    Zdanie któ­re zacy­to­wa­łam rów­nież jest w tej spe­cy­fi­ka­cji i jak je w takim razie nale­ży rozumieć?
    Gdyby nawet noto­wa­nie pro­ce­sów było zabro­nio­ne za pomo­cą UML, to i tak będzie to pra­wo mar­twe… jak to się w przy­ro­dzie z prze­pi­sa­mi zda­rza. Oczywiście moż­na mode­lo­wać pro­ce­sy w ide­al­nej do tego nota­cji (BPMN), tyl­ko z uwa­gi na jej skom­pli­ko­wa­nie, dia­gram może być nie­zro­zu­mia­ły dla odbior­cy. Powstaną ide­al­ne, skom­pli­ko­wa­ne i … niko­mu nie­po­trzeb­ne dia­gra­my (cze­go sama była świad­kiem w prak­ty­ce). To nota­cja ma słu­żyć czło­wie­ko­wi, a nie czło­wiek notacji.

    1. Jarosław Żeliński

      Gdyby nawet noto­wa­nie pro­ce­sów było zabro­nio­ne za pomo­cą UML, to i tak będzie to pra­wo martwe?”
      Nie jest i nigdy nie było zabro­nio­ne, w OMG nikt nicze­go nie zabrania. 

      Wszystkie sym­bo­le BPMN z ich opi­sem to rozdz. 7. spe­cy­fi­ka­cji, zaj­mu­ją­cy łącz­nie 28 stron. Rozdziały spe­cy­fi­ka­cji UML: 15.Action i 16.Activities, zaj­mu­ją łącz­nie 192 stro­ny. Nadal Pani uwa­ża, że dla odbior­cy BPMN jest bar­dziej skom­pli­ko­wa­ny i trud­niej­szy niż dia­gra­my aktyw­no­ści UML?

  3. Joanna Usidus

    Żebyśmy się dobrze zro­zu­mie­li: mówię o rze­czy­wi­sto­ści i prak­tycz­nym wie­lo­let­nim doświad­cze­niu i obser­wa­cji w pra­cy nad dia­ga­ma­mi z klien­ta­mi. Nie ma tutaj zna­cze­nia to, co ja uwa­żam”, co jest dla mnie wygod­niej­sze, co bar­dziej lubię, czy jak bym sobie życzy­ła. Diagram aktyw­no­ści jest pro­sty w odbio­rze i intu­icyj­nie rozu­mia­ny. W przy­pad­ku zło­żo­nych pro­ce­sów, gdzie koniecz­ne są pew­ne deta­le – bar­dziej ade­kwat­ny jest BPMN ale powsta­je barie­ra zrozumienia.
    Ponownie pro­szę o odpo­wiedź na pyta­nie, jak rozu­mieć to zda­nie ze Specyfikacji OMG w zesta­wie­niu z Pana twier­dze­niem, iż mode­lo­wa­nie pro­ce­sów dia­gra­mem aktyw­no­ści jest nie­zgod­ne ze spe­cy­fi­ka­cją : ?Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and workflow.?

    1. Jarosław Żeliński

      Jeżeli roz­ma­wia­my o doświad­cze­niu, to łama­nie norm jest jest jed­ną z głów­nych przy­czyn pora­żek pro­jek­tów. Gdyby dia­gra­my UML były łatwe dla biz­ne­su” BPMN by nigdy nie powstał, bo po co… 

      Ponownie pro­szę o odpo­wiedź na pyta­nie, jak rozu­mieć to zda­nie ze Specyfikacji OMG w zesta­wie­niu z Pana twier­dze­niem, iż mode­lo­wa­nie pro­ce­sów dia­gra­mem aktyw­no­ści jest nie­zgod­ne ze spe­cy­fi­ka­cją : ?Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and workflow.?”

      Odpowiedź w aka­pi­tach poprze­dza­ją­cych ten, któ­ry Pani cytu­je. a tak­że w następnych:

      15.2 Activities
      15.2.1 Summary
      An Activity is a Behavior spe­ci­fied as sequ­en­cing of sub­or­di­na­te units, using a con­trol and data flow model.”

      A tak­że tu;

      15.2.3 Semantics
      15.2.3.1 Activities
      The exe­cu­tion of one ActivityNode within an Activity may affect, and may be affec­ted by, the exe­cu­tion of other
      ActivityNodes in the Activity. Such edges are repre­sen­ted by ActivityEdges that inter­con­nect the ActivityNodes. The
      effect of one ActivityNode on ano­ther is spe­ci­fied by the flow of tokens over the ActivityEdges betwe­en the
      ActivityNodes.”

      Generalnie Aktywności repre­zen­tu­ją wyko­ny­wal­ne ele­men­ty kodu, a Czynności pozwa­la­ją mode­lo­wać ich szczegóły.

      Bo UML (obec­nie) słu­ży tyl­ko do mode­lo­wa­nia sys­te­mów (mode­le PIM), a tak­że do mode­lo­wa­nia wyko­ny­wal­ne­go kodu (mode­le PSM). Owszem zaszło­ści miał szer­sze” (UML powstał w latach 90-tych jako zle­pek 3. nota­cji) ale mamy już rok 2021 i ogrom­ne porząd­ki” w spe­cy­fi­ka­cji w roku 2015. 

      Niestety EA fir­my SPARX to relikt cza­sów począt­ku UML (od lat są na run­ku znacz­nie lep­sze pro­duk­ty). Jego popu­lar­ność to efekt tego, że jest sta­ry, a nie tego że jest dobry.

  4. Joanna Usidus

    Sparx Systems (A Contributing Member of the Object Management Group (OMG)) w Specyfikacji EA z lip­ca tego roku rów­nież nie odże­gnu­je się od dia­gra­mów aktyw­no­ści dla celów mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Opisując Activity poda­je: An Activity orga­ni­zes and spe­ci­fies the par­ti­ci­pa­tion of sub­or­di­na­te beha­viors, such as sub-Activities or Actions, to reflect the con­trol and data flow of a pro­cess. Activities are used in Activity dia­grams for vario­us mode­ling pur­po­ses, from pro­ce­du­ral-type appli­ca­tion deve­lop­ment for sys­tem design, to busi­ness pro­cess mode­ling of orga­ni­za­tio­nal struc­tu­res or workflow.”

    Sparx pro­po­nu­je też zasto­so­wa­nie uprosz­czo­ne­go dia­gra­mu aktyw­no­ści dla celów mode­lo­wa­nia pro­ce­su biz­ne­so­we­go: You can cre­ate Analysis dia­grams (Simplified Activity dia­grams) con­ta­ining the ele­ments most use­ful for busi­ness pro­cess mode­ling, using the «New Diagram» dialog”.

    Proszę rów­nież spoj­rzeć na przy­kład, któ­ry Sparx zamie­ścił jako ilu­stra­cję zasto­so­wa­nia dia­gra­mu aktyw­no­ści (https://​spa​rxsys​tems​.com/​r​e​s​o​u​r​c​e​s​/​u​s​e​r​-​g​u​i​d​e​s​/​1​5​.​2​/​m​o​d​e​l​-​d​o​m​a​i​n​s​/​u​m​l​-​m​o​d​e​l​s​.​pdf str. 32): czym­że jest obszar «Contact Sales Staff» na tym dia­gra­mie, jeśli nie pro­ce­sem biznesowym?

    1. Jarosław Żeliński

      Produkt fir­my SPARX (EA) ma poważ­ne pro­ble­my z kom­pa­ty­bil­no­ścią z UML/XMI a ich publi­ka­cje nie są normami.

Dodaj komentarz

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