W arty­ku­le Ile przy­pad­ków uży­cia opi­sa­łem przy­pad­ki uży­cia jako narzę­dzie defi­nio­wa­nia zakre­su pro­jek­tu, czy­li spo­sób doku­men­to­wa­nia wyma­gań. Takie jego zasto­so­wa­nie jest zde­fi­nio­wa­ne w spe­cy­fi­ka­cji UML .

Tym razem chcę ostrzec przed bez­kry­tycz­nym ucze­niem się” ze stron inter­ne­to­wych, nawet tych uzna­wa­nych powszech­nie za dobre i popu­lar­ne”. Sam nie­któ­re z nich pole­cam, ale coraz czę­ściej, nie całe ser­wi­sy jako takie, a tyl­ko okre­ślo­ne arty­ku­ły. Modernanalyst​.com też do nich nale­ży. Dziś będzie to arty­kuł, któ­re­go nie pole­cam, a opi­szę go, bo autor powie­la w nim dość powszech­ne błę­dy nota­cyj­ne, błę­dy któ­re sta­ły się kano­nem” dla wie­lu auto­rów sto­su­ją­cych UML. 

Poniżej dia­gram przy­pad­ków uży­cia ze związ­ka­mi «inc­lu­de» i «extend».

W UML zależ­no­ści «inc­lu­de» i «extend» są relik­tem ana­li­zy struk­tu­ral­nej (dia­gra­my przy­pad­ków uży­cia wymy­ślo­no w latach 80-tych). Związek «inc­lu­de» słu­ży do wyłą­cza­nia czę­ści wspól­nej zacho­wań (sce­na­riu­szy) przy­pad­ków uży­cia, w kon­se­kwen­cji: (1) muszą być co naj­mniej dwa bazo­we przy­pad­ki uży­cia by moż­na było mówić o czę­ści wspól­nej, (2) część wspól­na jest jedy­nie frag­men­tem, więc sama (samo­dziel­nie) jako taka do nicze­go nie słu­ży, więc nie wol­no z nią łączyć żad­ne­go akto­ra . Powyższy rysu­nek łamie obie te zasa­dy. Zależność «extend», to zawar­te w przy­pad­ku uży­cia, warun­ko­we roz­sze­rze­nie okre­ślo­ne­go zacho­wa­nia i obli­ga­to­ryj­ne jest poda­nie warun­ku (zda­rze­nia) uru­cha­mia­ją­ce­go to dodat­ko­we zacho­wa­nie . Tu tak­że tę zasa­dę złamano. 

A gdy pro­jekt jest obiek­to­wy”? Specyfikacja UML jasno mówi: Use Case defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re . Tak więc tych związ­ków po pro­stu nie uży­wa­my w pro­jek­tach, o któ­rych mówi­my, że są obiek­to­we, bo łamią pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Kolejne nad­uży­cie to sto­so­wa­nie gene­ra­li­za­cji na dia­gra­mie przy­pad­ków uży­cia: nie jest prze­wi­dzia­na dla tego dia­gra­mu (a dzie­dzi­cze­nie zosta­ło słusz­nie z UML usu­nię­te w 2015 roku wraz z opu­bli­ko­wa­niem wer­sji 2.5 UML). Zachowania sys­te­mu to okre­ślo­ne odręb­ne (her­me­ty­za­cja) ele­men­ty, tu tak­że obo­wią­zu­je zasa­da nie sto­so­wa­nia dia­gra­mu UML do opi­su archi­tek­tu­ry systemu/kodu. Po dru­gie, nawet gdy­by autor miał na myśli sta­re dzie­dzi­cze­nie”, to co do zasa­dy nie łączy­my akto­rów z ele­men­ta­mi abs­trak­cyj­ny­mi mode­lu („woła­nie przod­ka” to daw­no temu opi­sa­ny antyw­zo­rzec obiektowy). 

Poniżej dia­gram pro­fi­lu UML defi­niu­ją­cy poję­cie przy­pa­dek uży­cia (spraw­ne korzy­sta­nie z nota­cji UML wyma­ga umie­jęt­no­ści czy­ta­nia tego dia­gra­mu). I cóż my tu mamy? Należy to inter­pre­to­wać tak: związ­ki «extend» i «inc­lu­de» to inte­gral­ne czę­ści ich przy­pad­ków uży­cia, są to związ­ki skie­ro­wa­ne, przy­pa­dek roz­sze­rza­ny MUSI mieć punkt roz­sze­rze­nia (roz­sze­rza­ją­cy). Nie ma tu w ogó­le moż­li­wo­ści uży­cia gene­ra­li­za­cji mię­dzy ele­men­ta­mi na tym diagramie. 

Data publi­ka­cji tego arty­ku­łu: 5 sty­czeń 2020, czy­li jego autor pisał to pięć lat po publi­ka­cji UML v.2.5! Zaś, miej­sce publi­ka­cji tego tek­stu to zacny ser­wis Modern Analyst:

What can Modern Analyst do for YOU?
Let Modern Analyst help you gain an edge over your competition!Whether you are a tra­ining pro­vi­der, an expe­rien­ced prac­ti­tio­ner, a tool ven­dor, or a recru­iter focu­sing on busi­ness sys­tems ana­ly­sis, make Modern Analyst work for YOU. (źr.: What can Modern Analyst do for YOU?)

Autor sam o sobie:

Author: Mr. Monteleone holds a B.S. in phy­sics and an M.S. in com­pu­ting scien­ce from Texas A&M University. He is cer­ti­fied as a Project Management Professional (PMP?) by the Project Management Institute (PMI?), a Certified Business Analysis Professional (CBAP?) by the International Institute of Business Analysis (IIBA?), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA?) from George Washington University School of Business. Mark is also a mem­ber of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).

Nie rzad­ko sły­szę, że ale ten dia­gram ma poka­zać jak sys­tem dzia­ła”. Niestety ten dia­gram nie słu­ży do poka­za­nia” (doku­men­to­wa­nia) tego, jak dzia­ła apli­ka­cja. Do tego słu­żą inne dia­gra­my (ozna­czo­ne na poniż­szym sche­ma­cie blo­ko­wym, dia­gra­my aktyw­no­ści słu­żą obec­nie do mode­lo­wa­nia kodu wiec nie są uży­wa­ne na eta­pie ana­li­zy i pro­jek­to­wa­nia, lub tyl­ko do doku­men­ta­cji algo­ryt­mów) . Jest to – dia­gram przy­pad­ków uży­cia – od 2015 roku, dia­gram pomoc­ni­czy, słu­żą­cy wyłącz­nie do okre­śle­nia zakre­su pro­jek­tu, czy­li wyma­gań. Autorzy spe­cy­fi­ka­cji piszą: Use Case are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e. what sys­tems are sup­po­sed to do” (Przypadek uży­cia jest spo­so­bem na uchwy­ce­nie wyma­gań na sys­te­my, tj. tego CO sys­te­my mają zro­bić [dla akto­ra, a nie JAK]). 

Często sły­szę zarzu­ty, że dia­gra­my UML i doku­men­ty je zawie­ra­ją­ce, nie poma­ga­ją deve­lo­pe­rom, dla­te­go nie uży­wa­my UML”. No cóż, ale dia­gra­my, jak ten tu opi­sa­ny, i nie raz jak te na stro­nach Wikipedii czy Stackoverflow, pre­zen­tu­ją podob­ny poziom, i fak­tycz­nie nie są przy­dat­ne… A sto­so­wa­nie dia­gra­mów przy­pad­ków uży­cia do opi­su pro­ce­sów” (łań­cu­chy «extend» i «inc­lu­de») to wręcz epi­de­mia.. ;). Przypominam tak­że, że logo­wa­nie to nie przy­pa­dek uży­cia (use case) apli­ka­cji, a funk­cjo­nal­ność śro­do­wi­ska apli­ka­cji (są też inne meto­dy uwie­rzy­tel­nia­nia użytkownika). 

Dlatego pole­cam źró­dła rze­tel­nej wie­dzy o nota­cjach, a są to ory­gi­nal­ne spe­cy­fi­ka­cje, któ­rych umie­jęt­ność czy­ta­nia jest pod­sta­wo­wą umie­jęt­no­ścią dobre­go ana­li­ty­ka i pro­jek­tan­ta. Tu nie cho­dzi o głu­pie bycie orto­dok­sem”, cho­dzi o JEDNOZNACZNOŚĆ doku­men­ta­cji, czy­li i autor doku­men­tu i jego adre­sat, powin­ni uży­wać tego same­go kodu”, czy­li sto­so­wać się do spe­cy­fi­ka­cji uży­wa­nej nota­cji. Bez tego mamy wyłącz­nie nie­po­ro­zu­mie­nia i dodat­ko­we kosz­ty w projektach. 

W ran­kin­gach przy­czyn pora­żek pro­jek­tów, nie­jed­no­znacz­ność doku­men­ta­cji zawsze jest w pierw­szej trójce. 

Źródła

Object Management Group (2017) Unified Modeling Language (UML), UML. Available at: https://​www​.omg​.org/​s​p​e​c​/​U​ML/ (Accessed: 5 December 2019).
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. IGI Global, pp. 78 – 89. Available at: 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 (Accessed: 18 December 2019).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 4 komentarzy

  1. Adrian

    >Poniżej dia­gram pro­fi­lu UML defi­niu­ją­cy poję­cie przy­pa­dek uży­cia (spraw­ne korzy­sta­nie z nota­cji UML wyma­ga umie­jęt­no­ści czy­ta­nia tego dia­gra­mu). I cóż my tu mamy? Należy to inter­pre­to­wać tak: związ­ki ?extend? i ?inc­lu­de? to inte­gral­ne czę­ści ich przy­pad­ków uży­cia, są to związ­ki skie­ro­wa­ne, przy­pa­dek roz­sze­rza­ny MUSI mieć punkt roz­sze­rze­nia (roz­sze­rza­ją­cy). Nie ma tu w ogó­le moż­li­wo­ści uży­cia gene­ra­li­za­cji mię­dzy ele­men­ta­mi na tym diagramie.

    Idąc tym tro­pem myśle­nia tak samo nie ma moż­li­wo­ści uży­wa­nia gene­ra­li­za­cji w przy­pad­ku klas (ang. Class). W spe­cy­fi­ka­cji UML w roz­dzia­le 11.4.2 znaj­du­je się rysu­nek ana­lo­gicz­ny do przed­sta­wio­ne­go dia­gra­mu dla przy­pad­ków uży­cia. Na tym rysun­ku tak­że nie ma opi­sa­nej moż­li­wo­ści uży­wa­nia generalizacji.

    Czy w związ­ku z tym autor arty­ku­łu nie dopusz­cza uży­wa­nia gene­ra­li­za­cji na dia­gra­mach klas?

    1. Jarosław Żeliński

      Generalizacja to zwią­zek poję­cio­wy a nie struk­tu­ral­ny. Diagram klas może być uży­ty do poka­za­nia struk­tu­ry poję­cio­wej i wte­dy uży­wa­my aso­cja­cji i gene­ra­li­za­cji (tak­so­no­mie). Diagram klas może być uży­ty do poka­za­nia struk­tu­ry archi­tek­tu­ry apli­ka­cji, nie wte­dy może zawie­rać gene­ra­li­za­cji a jedy­nie związ­ki zależ­no­ści, ewen­tu­al­nie kom­po­zy­cje i reali­za­cje. Pojęcie dzie­dzi­cze­nia zosta­ło usu­nię­te z UML.

      Zwracam uwa­gę, że w UML wszyst­ko jest kla­są, a każ­dy dia­gram to dia­gram klas tyle, że z ewen­tu­al­nym pro­fi­lem (patrz spe­cy­fi­ka­cja MOF oraz pro­fi­le stan­dar­do­we w załącz­ni­kach do UML).

    2. Adrian

      Dziękuję za roz­róż­nie­nie tych spraw. 

      >Pojęcie dzie­dzi­cze­nia zosta­ło usu­nię­te z UML.

      Ciekaw jestem w jakim zakre­sie poję­cie dzie­dzi­cze­nia zosta­ło usu­nię­te? Niestety, UML pozna­łem dopie­ro od wer­sji 2.5.1 i nie rozu­miem na czym pole­ga­ło to usu­nię­cie, bo nie znam wcze­śniej­szych jego wersji.

      W bie­żą­cej spe­cy­fi­ka­cji UML w roz­dzia­le 9.2.3.2 Generalization znal­za­łem poję­cie dzie­dzi­cze­nia człon­ków (ang. mem­ber), więc może szcząt­ko­wo zosta­ło ono zachowane?

    3. Jarosław Żeliński

      Dziedziczenie zosta­ło cał­ko­wi­cie usu­nię­te z UML 🙂 (ale patrz koniec tej notat­ki), tak więc gene­ra­li­za­cja pozo­sta­je wyłącz­nie związ­kiem mię­dzy poję­cia­mi, inny­mi sło­wy: nie uży­wa­my związ­ku gene­ra­li­za­cji w innych mode­lach (np. architektury). 

      Member ozna­cza przy­na­leż­ność” a nie dzie­dzi­cze­nie, i tłu­ma­czo­ne jest jako prze­nie­sie­nie cech” ale defi­ni­cji. W języ­ku pol­skim jest to poję­cie defi­ni­cji spra­woz­daw­czej”. Przykład:
      – czwo­ro­no­gi to zwie­rzę­ta poru­sza­ją­ce się na czte­rech nogach
      – pies to szcze­ka­ją­cy czworonóg
      To ozna­cza, że pies, to szcze­ka­ją­ce zwie­rze poru­sza­ją­ce się na czte­rech nogach” (w tre­ści defi­ni­cji, pies ma cechę poru­sza się na czte­rech nogach”). Tu poję­cie dzie­dzi­cze­nia ozna­cza wyłącz­nie prze­ję­cie (zawie­ra­nie się) ogól­niej­szej defi­ni­cji przez defi­ni­cję szcze­gó­ło­wą. Pojęcie mem­ber” ozna­cza zaś bycie ele­men­tem cze­goś” i tak w tak­so­no­miach (drze­wa gene­ra­li­za­cji) poję­cia są ele­men­tem drze­wa gene­ra­li­za­cji, a w mode­lach np. archi­tek­tu­ry, jej ele­men­ty mogą być ele­men­tem drze­wa kom­po­zy­cji. Innymi sło­wy atry­but” to mem­ber” swo­jej kla­sy, każ­dy ele­ment zawar­ty w pakie­cie to jego mem­ber”. Może dzie­dzi­czyć” (przej­mo­wać a nie współ­dzie­lić) pew­ne cechy gru­py do któ­rej należy. 

      W języ­kach pro­gra­mo­wa­nia poję­cie dzie­dzi­cze­nia ozna­cza włącz­nie współ­dzie­le­nie (re-uży­cie) kodu (np. kla­sy biblio­tecz­nej). Używanie tego związ­ku jest jed­nak łama­niem her­me­ty­za­cji, pod­sta­wo­wej cechy para­dyg­ma­tu obiek­to­we­go (dla­te­go mię­dzy inny­mi został usu­nię­ty z UML).

Dodaj komentarz

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