Kolejna bar­dzo dobra książ­ka z obsza­ru pro­jek­to­wa­nia obiek­to­we­go. Poprzednia pozy­cja tego auto­ra (Agile Modeling. Effective…) trak­to­wa­ła o tym kie­dy, co i po co mode­lo­wać. Ta, to bar­dzo dobry kurs UML na przy­kła­dach. Tak, Scott Ambler (nie on jeden) uwa­ża, że mode­lo­wa­nie (szki­co­wa­nie) i testo­wa­nie pomy­słów jest tań­sze i szyb­sze na tabli­cy (papie­rze) niż w od razu w posta­ci kodu (przy­po­mnę, że jest on jed­nym z sygna­ta­riu­szy Agile Manifesto).

Ta książ­ka to jeden z lep­szych kur­sów metod obiek­to­wych i UML jaki mia­łem w rękach. Kluczem jest roz­dział o para­dyg­ma­cie obiek­to­wym, zro­zu­mie­nie obiek­tyw­no­ści i opis bazu­ją­cy na poję­ciach a nie kodzie. Większość auto­rów tego typu ksią­żek, to ludzie o pro­gra­mi­stycz­nym rodo­wo­dzie lub aktyw­ni pro­gra­mi­ści, obiek­to­wość postrze­ga­ją przez pry­zmat tak zwa­ne­go re-uży­cia kodu i kon­struk­cji kom­pi­la­to­rów, co jest kom­plet­nym nie­po­ro­zu­mie­niem, gdyż to języ­ki pro­gra­mo­wa­nia i kom­pi­la­to­ry (lepiej lub gorzej) imple­men­tu­ją para­dyg­mat obiek­to­wy a nie odwrotnie.

Ale nie był bym sobą, gdy­bym nie miał kil­ku uwag a raczej uzu­peł­nień, gdyż nale­ży zwró­cić uwa­gę, że książ­ka zosta­ła napi­sa­na w 2004 roku (o jej popu­lar­no­ści mogą świad­czyć dwa dodru­ki w 2005 roku). Ale po kolei.

Kilka uwag ode mnie

Popatrzmy na poniż­sze pojęcia:

rela­tion­ship – sto­su­nek do, powią­za­nie z (Oxford Dictionary: the way in which two or more things are con­nec­ted), (SJP powią­za­nie: wza­jem­na zależ­ność przy­czyn i skutków).

asso­cia­tion – dołą­cze­nie, sko­ja­rze­nie (Oxford Dictionary: a con­nec­tion betwe­en things whe­re one is cau­sed by the other), (SJP zwią­zek: sto­su­nek mię­dzy rze­cza­mi, zja­wi­ska­mi itp. połą­czo­ny­mi ze sobą w jakiś spo­sób, aso­cja­cja – auto­ma­tycz­ne sko­ja­rze­nie myślowe)

Jest wie­le nie­po­ro­zu­mień zwią­za­nych z tymi poję­cia­mi, ich angiel­skie i pol­skie tłu­ma­cze­nia są bli­sko spo­krew­nio­ne, dla­te­go war­to tu się­gnąć do źró­deł, czy­li spe­cy­fi­ka­cji (http://​www​.omg​.org/​s​p​e​c​/​U​ML/) a kon­kret­nie do czę­ści Infrastructure spe­ci­fi­ca­tion. Tam w roz­dzia­le 11.3 Classes Diagram, znaj­dzie­my mode­le poję­cio­we mię­dzy inny­mi związ­ków i dowie­my się, że aso­cja­cja (asso­cia­tion) dzie­dzi­czy po związ­ku (rela­tion­ship).

Popatrzmy na rodza­je powią­zań mię­dzy klasami:

Model obiektowy asocjacja a użycie

Zostały one usze­re­go­wa­ne od góry od naj­ogól­niej­sze­go. Nie będę uży­wał sło­wa rela­cja” bo w języ­ku pol­skim koja­rzy się (a ja zastrze­gam to w swo­ich doku­men­ta­cjach) z mode­lem danych, dia­gra­mem ERD (enti­ty rela­tion­ship dia­gram). Dlatego w UML mamy (jak wyżej):

A. aso­cja­cja, naj­ogól­niej­sza jej for­ma, ozna­cza powią­za­nie dwóch klas (w mode­lach poję­cio­wych jakie­kol­wiek),
B. aso­cja­cja skie­ro­wa­na, seman­tycz­nie poka­zu­je kie­ru­nek tego związ­ku, moż­na to inter­pre­to­wać tak, że kla­sa A wie o ist­nie­niu B, a kla­sa B nie wie o ist­nie­niu A (sło­wo wie” moż­na rozu­mieć tak­że jako ma w sobie zapi­sa­na taką infor­ma­cję”),
C. zwią­zek uży­cia (kolej­ny rodzaj związ­ku), seman­tycz­nie ozna­cza współ­pra­cę klas, tu kla­sa A korzy­sta z usłu­gi (wywo­łu­je ope­ra­cję) kla­sy B,
D. zwią­zek gene­ra­li­za ji, seman­tycz­nie ozna­cza, że kla­sa B jest spe­cjal­ną for­mą (spe­cja­li­za­cją) kla­sy A, lub że kla­sa A jest uogól­nie­niem kla­sy B, w mode­lu poję­cio­wym poję­cie A to uogól­nie­nie poję­cia B (pies jest uogól­nie­niem ratler­ka, lub ratle­rek, jest szcze­gól­nym przy­pad­kiem psa, kon­kret­ny Burek, jest instan­cją – wystą­pie­niem: obiek­tem – kla­sy ratle­rek),
E. zwią­zek reali­za­cji, seman­tycz­nie ozna­cza, że kla­sa B jest spe­cy­fi­ka­cją (spo­so­bem wyko­na­nia, reali­za­cji) abs­trak­cji jaką jest kla­sa A (np. inter­fejs jest reali­zo­wa­ny kon­kret­ną kla­są lub kom­po­nen­tem), reali­za­cja to nie jest for­ma dzie­dzi­cze­nia, jak twier­dzą nie­któ­rzy wykła­dow­cy i trenerzy :(.

Asocjacja jest naj­ogól­niej­szym związ­kiem (bez żad­nych dodat­ków repre­zen­tu­je jaki­kol­wiek zwią­zek). Warto też wie­dzieć, że związ­ki te są ina­czej reali­zo­wa­ne. Asocjacje, jako trwa­łe powią­za­nie klas (obiek­tów), to zapis w atry­bu­cie kla­sy. Związki uży­cia to wywo­ła­nia ope­ra­cji. Związki gene­ra­li­za­cji i reali­za­cji są związ­ka­mi abstrakcyjnymi. 

Przypadki użycia

UML to tak­że związ­ki gene­ra­li­za­cji na dia­gra­mach Przypadków Użycia (UC, ang. Use Case). Używanie ich jed­nak ma sens czy­sto poję­cio­wy, mimo to czę­sto widu­je kosz­mar­ki nazy­wa­ne nie raz dia­gram akto­rów”, gdzie np. pod­wład­ni dzie­dzi­czą” po swo­im prze­ło­żo­nym, co jest kom­plet­ną bzdu­rą. Menedżer rzad­ko ma umie­jęt­no­ści swo­ich pod­wład­nych, doty­czy to nie raz tak­że upraw­nień (szef zespo­łu praw­ni­ków nie raz nie ma upraw­nić rad­cow­skich czy adwo­kac­kich, żaden mój szef nie miał upraw­nień do infor­ma­cji taj­nej a ja mam od 2004 roku, itp.).

Kolejnym kosz­ma­rem jest sto­so­wa­nie dia­gra­mów UC do mode­lo­wa­nia upraw­nień. Generalnie upraw­nie­nia kogoś do cze­goś to regu­ła a nie sta­ty­stycz­ne trwa­łe powią­za­nie (nawet jeże­li jest to regu­ła dają­ca komuś do cze­goś pra­wo, jest to regu­ła a nie sta­ły zwią­zek dla­te­go, że upraw­nie­nia to coś co zawsze moż­na odebrać).

UML to tak­że związ­ki <extend> i <inc­lu­de>, a słu­żą one do mode­lo­wa­nia re-uży­cia kodu (o czym wspo­mi­na tak­że Ambler w tej książ­ce). Stosowanie ich na dia­gra­mach UC na eta­pie ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań jest tak­że bzdu­rą, gdyż o jakim­kol­wiek re-uży­ciu kodu moż­na mówić naj­wcze­śniej na eta­pie pro­jek­to­wa­nia imple­men­ta­cji. Po dru­gie mając w pla­nie wyko­na­nie mode­lu wewnętrz­nej struk­tu­ry apli­ka­cji (dia­gra­my klas i kom­po­nen­tów) mode­lo­wa­nie re-uży­cia kodu czy nawet re-uży­cia sce­na­riu­szy UC, jest pozba­wio­ne sen­su, bo jest nad­mia­ro­we i przed­wcze­sne. W razie wąt­pli­wo­ści pro­szę pod­jąć pró­bę sko­ja­rze­nia dia­gra­mów sekwen­cji z odpo­wia­da­ją­cy­mi im włą­czo­ny­mi (inc­lu­de) przy­pad­ka­mi użycia.

Dwa sło­wa na temat tak zwa­nych Systemowych przy­pad­ków uży­cia. Nie są to żad­ne wewnętrz­ne UC. Z zasa­dy UC to postrze­ga­na z zewnątrz (przez akto­ra sys­te­mu) usłu­ga sys­te­mu, moż­na się spo­tkać z tym poję­ciem (tu u Amblera tak­że) ale w kon­tek­ście, takim że sys­tem w rozu­mie­niu apli­ka­cja, reali­zu­je kon­kret­ne sce­na­riu­szo­we cele użyt­kow­ni­ka (akto­ra sys­te­mu). Innymi sło­wy usłu­gą sys­te­mu jakim jest np. mło­tek (to pro­sty sys­tem, ma dwa ele­men­ty: obuch i trzo­nek :)) jest ude­rza­nie, a wbi­ja­nie gwoź­dzia, wybi­ja­nie szy­by, ude­rza­nie w dzwon itp. to kon­tek­sty akto­ra. Jednak z per­spek­ty­wy defi­nio­wa­nia apli­ka­cji jest to jeden UC, ma jeden sce­na­riusz: weź do ręki mło­tek, ustal miej­sce ude­rze­nia, uderz, jeże­li nie osią­gną­łeś ocze­ki­wa­ne­go rezul­ta­tu, powtórz. 

Modelowanie tak zwa­nych sys­te­mo­wych przy­pad­ków uży­cia” jest tak­że pozba­wio­ne sen­su, gdyż dia­gram UC nie słu­ży do mode­lo­wa­nie wewnętrz­nej archi­tek­tu­ry sys­te­mu. Przypadki uży­cia to usłu­gi apli­ka­cji (pozy­cje w jej menu) i raczej jest jed­na usłu­ga np. Konfiguracja” a nie Ustaw, Włącz, Wyłącz, Zmień, itp… Te celo­we dzia­ła­nia to treść mody­fi­ko­wa­ne­go formularza.

Przypomnę, że książ­ka ta powsta­ła w 2004 roku (na co trze­ba brać popraw­kę czy­ta­jąc ją, poja­wia się w niej dzie­dzi­cze­nie), w cza­sie gdy nie było jesz­cze mowy o powszech­nym uży­ciu nota­cji BPMN, a dia­gra­my aktyw­no­ści są dość ułom­ne i zara­zem zbyt zło­żo­ne do tego celu (o czym świad­czy rosną­ca sta­le popu­lar­ność nota­cji BPMN i spa­dek popu­lar­no­ści dia­gra­mów czyn­no­ści do mode­lo­wa­nia pro­ce­sów biznesowych).

Niestety i w lite­ra­tu­rze i w mate­ria­łach szko­le­nio­wych, czy nawet dydak­tycz­nych na uczel­niach (o zgro­zo) moż­na się spo­tkać z taki­mi antyw­zor­ca­mi” jak wyżej. Jednym z naj­bar­dziej kurio­zal­nych jest obec­nie mode­lo­wa­nie danych z uży­ciem dia­gra­mu klas, nano­sząc na nie np. jesz­cze klu­cze głów­ne (zna­la­złem coś takie­go w pew­nym pod­ręcz­ni­ku aka­de­mic­kim!). Niestety bar­dzo czę­sto auto­rzy tych mate­ria­łów, wykła­dow­cy i tre­ne­rzy, zamiast korzy­stać ze źró­deł, prze­pi­su­ją jeden od dru­gie­go pogłę­bia­jąc marazm w tej dzie­dzi­nie, a pier­wo­wzo­rem wie­lu tych here­zji są nie­ste­ty mate­ria­ły publi­ko­wa­ne przez fir­mę SPARX (pro­du­cent opro­gra­mo­wa­nia Enterprise Architect) jak choć­by mój ulu­bie­niec: czas jako Aktor sys­te­mu (co opi­sa­łem tu).

Na zakończenie

Tak więc książ­kę Scott’a Amblera gorą­co pole­cam, ana­li­ty­kom szcze­gól­nie, pro­gra­mi­stom także.

The Object Primer 3rd EditionAgile Model Driven Development with UML 2Cambridge University Press, 2004 ISBN#: 0 – 521-54018 – 6 (Źródło: The Object Primer 3rd Ed: Agile Model Driven Development (AMDD) with UML 2)

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 4 komentarzy

  1. Pawel Zubkiewicz

    Witam,
    Tak się zło­ży­ło ze oma­wia­na pozy­cja wpa­dła w moje ręce jakiś mie­siąc temu. Generalnie zga­dzam się z Twoją opi­nią o książ­ce i o tym, że jed­nak trze­ba brać pod uwa­gę datę jej wyda­nia i nie trak­to­wać, jako wyrocz­ni (szcze­gól­nie wła­śnie pod kątem wyko­rzy­sta­nia tan­de­mu BPMN i UML w obec­nych czasach).

    Właśnie w tym kon­tek­ście mam parę pytań. W sowim tek­ście piszesz:
    UML to tak­że związ­ki i , a słu­żą one do mode­lo­wa­nia re-uży­cia kodu (o czym wspo­mi­na tak­że Ambler w tej książ­ce). Stosowanie ich na dia­gra­mach UC na eta­pie ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań jest tak­że bzdu­rą, gdyż o jakim­kol­wiek re-uży­ciu kodu moż­na mówić naj­wcze­śniej na eta­pie pro­jek­to­wa­nia implementacji”

    Osobiście przy mode­lo­wa­niu Use Casów nie myślę o kodzie, a o ustan­da­ry­zo­wa­niu pew­nej sekwen­cji kro­ków. Główna zale­ta jest tutaj ujed­no­li­ce­nie pew­nych stan­dar­do­wych czyn­no­ści dla koń­co­we­go użyt­kow­ni­ka, za czym zga­dzam się może iść w przy­szło­ści ustan­da­ry­zo­wa­na reali­za­cja. Dlatego jeśli w róż­nych miej­scach sys­te­mu będzie potrze­ba, aby użyt­kow­nik wybrał oso­bę z listy pra­cow­ni­ków to stwo­rzę taki use case i będę go re-„używał w wie­lu miej­scach, aby użyt­kow­nik, nie musiał wybie­rać tej oso­by za każ­dym razem inaczej.

    I w tym miej­scu po raz kolej­ny przy­to­czę Twoje słowa:
    Modelowanie więc tak zwa­nych ?sys­te­mo­wych przy­pad­ków uży­cia? jest dzi­siaj pozba­wio­ne sen­su, szcze­gól­nie gdy poprze­dza­my two­rze­nie mode­lu UC utwo­rze­niem mode­li pro­ce­sów biz­ne­so­wych. Na tych mode­lach będą wła­śnie czyn­no­ści i kon­tekst uży­cia młotka.”

    Nie mogę się zgo­dzić z taką opi­nią, szcze­gól­nie jeśli nie poda­łeś więk­szej ilo­ści infor­ma­cji do jakie­go pozio­mu szcze­gó­ło­wo­ści będziesz mode­lo­wał pro­ce­sy biz­ne­so­we. Tylko CIM czy tez PIM?
    Logicznym jest, że gdzieś gra­ni­ca sen­sow­no­ści uży­cia BPMNa się koń­czy i wła­śnie w tym miej­scu zaczy­na się obszar gdzie war­to uży­wać Use Caseów, sce­na­riu­szy lub/oraz dia­gra­mów aktyw­no­ści, aby zapro­jek­to­wać ten bar­dziej przy­ziem­ny poziom inte­rak­cji użyt­kow­ni­ka z systemem. 

    Moim zda­niem pro­ces biz­ne­so­wy, któ­ry jak mówisz powi­nien nadać kon­tekst dla Use Casea, nie zawsze będzie to robić, ponie­waż z per­spek­ty­wy celu pro­ce­su biz­ne­so­we­go wybór oso­by z listy pra­cow­ni­ków” jest mało­istot­nym kro­kiem w jed­nym z zadań (task) całe­go pro­ce­su i infor­ma­cja o takich szcze­gó­li­kach” tyl­ko by zaśmie­ci­ła dia­gram pro­ce­su. Natomiast dla Use Casea jest już odpowiedni. 

    Obrazowo cho­dzi mi o taki przy­kład: Mamy pro­ces, w któ­re­go skład wcho­dzi zada­nie Task A”. Task A” jest reali­zo­wa­ne przez Use Case 1” (tutaj uży­wa­my rela­cji Trace aby połą­czyć” BPMN i UML). Natomiast Use Case 1” wywo­łu­je (rela­cja inc­lu­de) jako jeden ze swo­ich kro­ków Use Case wybór oso­by z listy pra­cow­ni­ków”. Zatem jeśli już, to Use Case 1” nada­je kon­tekst dla ele­men­tar­nej czyn­no­ści: Twój mło­tek, mój wybór osoby.

    PS. Dla więk­szo­ści począt­ku­ją­cych pro­gra­mi­stów re-uży­cie” kodu to jest jego dzie­dzi­cze­nie, co w wie­lu przy­pad­kach powo­du­je wię­cej skut­ków ubocz­nych niż korzyści. 

    PS2. Copy-paste, lub jak to ktoś ład­niej opi­sał encap­su­la­te and reu­se” to też ponow­ne wyko­rzy­sta­nie kodu, dosłownie 😛

    PS3. Z cie­ka­wo­ści zaj­rza­łem na stro­ny Sparxa, jakoś nie zna­la­złem przy­kła­du akto­ra Czas. Może Sparx już zwe­ry­fi­ko­wał swo­je podejście?

    Pozdrawiam ser­decz­nie,
    Paweł

    1. Jaroslaw Zelinski

      Co do przy­pad­ków użycia:
      – kolej­ny krok, po powstaniu/zadeklarowaniu przy­pad­ku uży­cia (PU), to opi­sa­nie sce­na­riu­sza na dia­gra­mie sekwen­cji, jeże­li uży­je­my wyłą­cza­nia czę­ści do re-uży­cia” to jak to poka­żesz to na tych dia­gra­mach (sekwen­cji)?
      – dobrze zapro­jek­to­wa­ny PU nie dublu­je innych :), co naj­wy­żej poje­dyn­czy krok sce­na­riu­sza będzie się powta­rzał w kil­ku PU ale tyl­ko dla­te­go, że w mode­lu dzie­dzi­ny będzie go reali­zo­wa­ła ta sama kla­sa i jej ope­ra­cje, ale żeby to wie­dzieć musi być zna­na archi­tek­tu­ra, czy­li na eta­pie PU to falstart,
      – dia­gram PU to klu­czo­wy i ostat­ni zara­zem, zro­zu­mia­ły dla zama­wia­ją­ce­go mate­riał, nie pozna­łem zwy­kłe­go i zdro­we­go czło­wie­ka”, któ­ry bez pro­ble­mu popraw­nie rozu­mie” związ­ki extend i inc­lu­de, wiec po co?
      – model PIM to nie pro­ce­sy biz­ne­so­we a już archi­tek­tu­ra, co do szcze­gó­ło­wo­ści mode­li pro­ce­sów to robię to po boże­mu” czy­li pro­ces to co naj­wy­żej ato­mo­wa” kon­struk­cja wej­ście, aktyw­ność, wyj­ście” odpo­wia­da­ją­ca jeden do jed­ne­go przy­pad­ko­wi uży­cia rozu­mia­ne­mu jak w UML (stan począt­ko­wy i koń­co­wy, aktyw­ność dają­ca kom­plet­ny i war­to­ścio­wy pro­dukt aktorowi),
      – na mode­lach pro­ce­sów nie mode­lu­je się tego jak wypeł­nić nośnik danych” (for­mat­kę) więc na mode­lu pro­ce­sów nie powi­nien się poja­wić krok ?wybór oso­by z listy pra­cow­ni­ków?, na dia­gra­mie UC będzie to raczej wyma­ga­nie poza­fukn­co­nal­ne: łatwość wpro­wa­dza­nia danych”, a na makie­cie (mock-up) dopie­ro pro­to­typ: opa­da­ją­ca lista pracowników”. 

      P.S. część tego co powy­żej napi­sa­łem to przy­ję­ta kon­wen­cja, ale defi­ni­cja pro­ce­su biz­ne­so­we­go to jej część,

      P.S. O akto­rze-cza­sie mię­dzy inny­mi tu: czy­taj arty­kuł, co do SPARX’a, w EA wsa­dzi­li nawet przede­fi­nio­wa­ny ste­reo­typ dla akto­ra z zegar­kiem jako twa­rzą ;), a tu masz na ich stro­nie kurio­zum aktor to event” któ­rym może być czas…

      Osobiście już daw­no podzię­ko­wa­łem fir­mie SPARX i za ich mądro­ści” i za ich produkt 😉 

  2. Pawel Zubkiewicz

    Dzięki za odpowiedź.

    Jeśli cho­dzi o pierw­szy punkt, to nie uży­wam dia­gra­mów sekwen­cji do wizu­ali­za­cji dia­gra­mów, z racji tego, że w mojej opi­nii są one zbyt trud­ne do zro­zu­mie­nia dla zwy­kłe­go zja­da­cza chle­ba” szcze­gól­nie, gdy mamy alter­na­tyw­ne przebiegi.
    Osobiście wole uży­wać dia­gra­mów aktyw­no­ści, w momen­cie gdy mam w dia­gra­mie aktyw­no­ści krok reali­zo­wa­ny przez inc­lu­do­wa­ny” PU, uży­wam Call Behavior Action co pozwa­la mi zacho­wać spój­ność syn­tak­tycz­na mode­lu (ana­lo­gicz­nie jak w BPMN moż­na w pro­ce­sie odwo­łać się do podprocesu).

    Zgadzam się z twier­dze­niem, że ” dia­gram PU to klu­czo­wy i ostat­ni zara­zem, zro­zu­mia­ły dla zama­wia­ją­ce­go mate­riał”. Cieszę się, że wspo­mnia­łeś o kon­wen­cjach, ponie­waż też ich uży­wam. Osobiście podo­ba mi się podej­ście Volere, któ­re mówi o Business Use Case i Product Use Case. Moja kon­wen­cja jest taka, ze BUC to jesz­cze CIM, a PUC to już PIM. Dlatego w BUCach nie uży­wam ani inc­lu­de ani extend, z racji tego aby opi­sa­ne przy­pad­ki uży­cia były bar­dzo pro­ste do zro­zu­mie­nia dla laików. I tak w BUCach zda­rza się dupli­ko­wa­nie pew­nych kro­ków. Jednak PUCe, któ­re nie­ja­ko reali­zu­ją” i uszcze­gó­ło­wia­ją” BUCe to już dokumentacja/projekt dla tro­chę innej kate­go­rii inte­re­sa­riu­szy, dla­te­go w nich pozwa­lam sobie na szer­sze wyko­rzy­sta­nie tego, co UML ofe­ru­je (inc­lu­de, extend).

    Dalej piszesz na mode­lach pro­ce­sów nie mode­lu­je się ?tego jak wypeł­nić nośnik danych? (for­mat­kę) więc na mode­lu pro­ce­sów nie powi­nien się poja­wić krok ?wybór oso­by z listy pra­cow­ni­ków?” ? tak jak naj­bar­dziej się z tym zga­dzam. Chyba nie­pra­wi­dło­wo odczy­ta­łeś mój przy­kład, bo to nie było moją inten­cja. Chodzi mi o to, że w arty­ku­le piszesz, że pro­ces biz­ne­so­wy nada­je kon­tekst uży­cia młot­ka, a ja uwa­żam, że na ogół pro­ces biz­ne­so­wy jest (i powi­nien być) zbyt abs­trak­cyj­ny, aby ten kon­tekst jed­no­znacz­nie i dokład­nie okre­ślić. Innymi sło­wy pro­ces biz­ne­so­wy two­rze­nie rzeź­by” i pro­ces biz­ne­so­wy budo­wa alta­ny” nie zawie­ra­ją infor­ma­cji jak trzy­mać mło­tek, któ­ra stro­ną ude­rzać i z jaką siłą ? bo to po pro­stu zbęd­ne szcze­gó­ły na pozio­mie procesu.

    Odnośnie Post Scriptum:
    Co do IBMa to nawet nie chce mi się komen­to­wać, powiem tyl­ko, że uży­wa­łem tro­chę Rational Software Architect i mi wystar­czy na całe życie 🙂

    Co do Sparxa to fak­tycz­nie, nie zawsze trak­tu­ją spe­cy­fi­ka­cje UML dosłow­nie i nie zamie­rzam ich bro­nić pod tym wzglę­dem. Dla mnie EA ma wie­le innych zalet ? ale to już inna dyskusja. 

    Natomiast, jeśli cho­dzi Ci o wzmian­kę na stro­nie Sparxa, któ­ra poda­łeś „[Actors] There can also be events which are trig­ge­red witho­ut the invo­lved par­ties (e.g. time events).” ? to musze przy­znać, że cie­ka­wie się to łączy z kon­cep­cją Business Event”, czy­li bodź­ca wywo­łu­ją­ce­go Business Use Case w Volere.

    Polecam Ci książ­kę auto­rów podej­ścia Volere do ana­li­zy: Mastering the requ­ire­ments pro­cess. Moim zda­niem jed­na z lep­szych ksią­żek o ana­li­zie biz­ne­so­wej wyda­na w ostat­nich latach. Nawet jeśli pew­nie kon­cep­cje Ci nie będą paso­wa­ły (bo masz już wyro­bio­ny i doj­rza­ły warsz­tat) to war­to się zapo­znać z tym podejściem.

    Pozdrawiam

    1. Jaroslaw Zelinski

      Diagram sekwen­cji jest jedy­nym, pozwa­la­ją­cym prze­te­sto­wać logi­ką apli­ka­cji (tak­że inte­gra­cji). te dia­gra­my nie są adre­so­wa­ne do użyt­kow­ni­ka, to narzę­dzie ana­li­ty­ka, uwia­ry­gad­nia­ją­ce pro­jekt i jego logi­kę. Użytkownikowi poka­zu­ję co naj­wy­żej sce­na­riusz UC w posta­ci wypunk­to­wa­nej listy kro­ków dia­lo­gu aktor-sys­tem (dia­gra­mów aktyw­no­ści też nie raz nie rozu­mie­ją:)). Co do dia­gra­mów aktyw­no­ści są mało przy­dat­ne do doku­men­to­wa­nia sce­na­riusz PU, gdyż tu nale­ży poka­zać komu­ni­ka­cje obiek­tów: wywo­ła­nia ich ope­ra­cji, cze­go nie robi dia­gram aktywności. 

      Diagram aktyw­no­ści powstał w cza­sach gdy nie było BPMN, w zasa­dzie słu­ży to opi­so­we­go mode­lo­wa­nia wewnętrz­nych pro­ce­sów”, nie jest w sta­nie zastą­pić dia­gra­mu sekwen­cji: wywo­łań obiek­tów i ich operacji. 

      Z pro­sto­ty UML i powo­dów opi­sa­nych w MDA nie uży­wam UC ina­czej niż w spe­cy­fi­ka­cji UML: UC to usłu­ga apli­ka­cji i nic inne­go. Owszem w latach 90-tych, sto­so­wa­no w RUP dia­gram PU do mode­lo­wa­nia orga­ni­za­cji (aktor i UC biz­ne­so­wy), wte­dy aktor to był np. Klient fir­my, a zło­że­nie ofer­ty” to by przy­pa­dek uży­cia” tej orga­ni­za­cji, ale zarzu­ci­łem cał­ko­wi­cie to podej­ście jakieś 10 lat temu bo w doku­men­tach powsta­wa­ły nie­jed­no­znacz­no­ści i poja­wił się BPMN. Obecnie z zasa­dy sto­su­je jeden typ dia­gra­mu do kon­kret­nych zasto­so­wań, zgod­nych seman­tycz­nie z UML/BPMN/BMM.

      Proces biz­ne­so­wy to łań­cuch aktyw­no­ści, każ­da ma stan począt­ko­wy i koń­co­wy czy­li wej­ście i wyj­ście, ana­lo­gicz­nie jak przy­pa­dek uży­cia (OMG har­mo­ni­zu­je defi­ni­cje pojęć w nota­cjach). W efek­cie aktyw­ność wbi­cia gwoź­dzia wyma­ga uży­cia młot­ka, nada­je kon­tekst tej pra­cy. Inna aktyw­ność, np. wybi­cie szy­by tak­że wyma­ga uży­cia młot­ka. Młotek zosta­je uży­ty dokład­nie w ten sam spo­sób (sce­na­riusz przy­pad­ku uży­cia – usłu­gi jaką świad­czy mło­tek to zawsze ude­rza­nie) ale kon­tekst wyni­ka z pro­ce­su. Zbudowanie altan­ki to łań­cuch aktyw­no­ści mają­cych swo­je pośred­nie skut­ki (pro­duk­ty), to łań­cuch podprocesów. 

      Rationale… cóż, też nie uży­wam ;). Co do Volere, hm… nad­bu­do­wa, któ­rej nie uzna­ję bo moim zda­niem pro­sty” UML/MDA wystar­czy. Jestem zwo­len­ni­kiem Brzytwy Ockhama :). Z tego same­go powo­du cał­ko­wi­cie odsze­dłem od poję­cia z poza UML jakim jest Business Use Case” (j.w. RUP lat 90tych odszedł). 

      Mastering the requ­ire­ments pro­cess” znam, powsta­ło gdzieś 1995 roku i są kolej­ne wyda­nia (w 1995 r. nie było mowy o BPMN a UML racz­ko­wał), bazu­je na kon­cep­cji RUP Business Use Case i zna­nych z ana­li­zy struk­tu­ral­nej funk­cjach i danych. Tego typu metod jest dużo. Nie mam zaufa­nia to metod opar­tych na ana­li­zie struk­tu­ral­nej, pre­fe­ru­ję MDA. 

      Fakt, że mam chy­ba wyro­bio­ny warsz­tat” :). Z każ­dym kolej­nym pro­jek­tem uprasz­czam go a nie roz­bu­do­wu­ję ;). Obecnie jest to w 100% zestaw OMG (BMM/BMM/BPMN/UML/SysML/SoaML), któ­re OMG zhar­mo­ni­zo­wa­ło (doku­ment core con­cepts …, np. ele­men­tar­ny pro­ces bazu­ją­cy na aktyw­no­ści w BPMN to przy­pa­dek uży­cia o ile pla­nu­je­my tę aktyw­ność zawrzeć w zakre­sie wyma­gań wobec sys­te­mu – apli­ka­cji). Opisane i wyma­ga­ne w BABOK śla­do­wa­nie to prze­jaw tego podej­ścia (n. wypro­wa­dza­nie UC z aktyw­no­ści w pro­ce­sach, mapo­wa­nie nośni­ków danych BPMN na agre­ga­ty w mode­lu dzie­dzi­ny z uży­ciem UML/Diagram klas itp.). 

      Generalnie moż­na mieć okre­ślo­ne swo­je podej­ście i meto­dy pra­cy, jest wię­cej niż jed­na, jeże­li tyl­ko dają dobre efek­ty to OK :). Ja pre­fe­ru­ją meto­dy korzy­sta­ją­ce z moż­li­wie naj­prost­szych narzę­dzi, dla mnie to pure UML” itp. Dzięki temu pro­duk­ty są do wyko­na­nia w każ­dym narzę­dziu zgod­nym z nota­cja­mi OMG i są wymien­ne (tre­ści nie wykra­cza­ją poza stan­dar­dy), nie sto­su­ję metod obję­tych pra­wem autor­skim (ryzy­ko opłat licen­cyj­nych za pro­duk­ty pra­cy i szko­le­nia itp.., z tego powo­du cał­ko­wi­cie odsze­dłem od TOGAF/ArchiMAte), a nie­ste­ty Volere (jak i inne podob­ne) jest chro­nio­ne pra­wa­mi autor­ski­mi ich twór­ców (http://​www​.vole​re​.co​.uk/​l​i​c​e​n​s​ing).

Dodaj komentarz

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