Diagram aktywności UML – kiedy

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 PIMPSM 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

Kama, N., French, T., & Reynolds, M. (2011). Design Patterns Consideration in Class Interactions Prediction Development. International Journal of Advanced Science and Technology, 28, 21.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
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
Object Management Group. (2008, kwie­cie). 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/
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.

Inne artykuły na podobny temat

Komentarze

  1. Joanna Usidus 28 lipca 2021 at 20:17

    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”…

    • Jarosław Żeliński 28 lipca 2021 at 22:47

      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 31 lipca 2021 at 23:31

    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.

    • Jarosław Żeliński 1 sierpnia 2021 at 00:16

      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 1 sierpnia 2021 at 09:39

    Ż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.?

    • Jarosław Żeliński 1 sierpnia 2021 at 17:30

      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 1 sierpnia 2021 at 10:28

    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?

    • Jarosław Żeliński 1 sierpnia 2021 at 17:19

      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.

  5. Jarosław Żeliński 13 czerwca 2022 at 10:46

    Artykuł uzu­peł­nio­no o sta­ty­sty­kę pojęć UML i BPMN w literaturze.

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.