Przypadki użycia czy model procesu, czego używać?

Dość czę­sto spo­ty­kam sie z teza­mi, że uży­cie przy­pad­ków uży­cia nie wyma­ga mode­lo­wa­nia pro­ce­sów i odwrot­nie, albo że są to ​„narzę­dzia” ofe­ru­ją­ce podob­ne lub takie same korzy­ści, np. tak jak tu:

So, as you can see we used dif­fe­rent tech­ni­qu­es and basi­cal­ly the result is the same. It was not real­ly impor­tant what tech­ni­qu­es were used unless solu­tion design is com­ple­te. It?s just a mat­ter of a habit so if you?re more com­for­ta­ble with use cases then stick to them or if you?re more fami­liar with pro­cess maps then draw a map. But note that in some cases you may be requ­ested to use a spe­ci­fic tech­ni­que that is a cor­po­ra­te stan­dard or becau­se the­re is an agre­ement that all BAs on the pro­ject will use one tem­pla­te (tech­ni­que) for con­si­sten­cy. (Źródło: Use cases or busi­ness pro­cess maps, what tech­ni­que to use?)

Sugeruję naj­pierw zapo­znać się z cyto­wa­nym powy­żej tek­stem a po zapo­zna­niu się z nim zapra­szam do dal­szej lek­tu­ry. Jak się komuś nie chce powyż­sze­go czy­tać, może potrak­to­wać mój tekst jak zwy­kły post a nie jak polemikę ;). 

Zacznę od mode­lu pro­ce­sów w BPMN jaki pre­zen­tu­je jego autor;

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Pierwsza rzecz: co do zasa­dy Klient i Podmiot go obsłu­gu­ją­cy to dwa odręb­ne pod­mio­ty więc dia­gram ten powi­nien zawie­rać dwie pule, a nie jed­ną wspól­ną pulę (albo jak kto woli base­ny). Dalej. BPMN w spe­cy­fi­ka­cji trak­tu­je tory wyłącz­nie jak uni­wer­sal­ne ele­men­ty gru­pu­ją­ce (nie są one jed­nak eks­por­to­wa­ne do pli­ków wymia­ny XPBL czy BPEL4WS), nie ma zaka­zu sto­so­wa­nie torów do repre­zen­to­wa­nia ​„sys­te­mów”, model biz­ne­so­wy CIM (defi­ni­cja MDA) zaka­zu­je. Od sie­bie dodam, że to czym będą tory nale­ży zde­fi­nio­wać na począt­ku ana­li­zy (i powin­na to być jed­na spój­na definicja). 

Autor powyż­sze­go dia­gra­mu na jed­nym dia­gra­mie poka­zał wszyst­ko co wie, łamiąc nota­cyj­ne zasa­dy sto­so­wa­ni puli (base­nu) oraz dobre prak­ty­ki nie mie­sza­nia róż­nych kon­tek­stów na jed­nym modelu.

Model pro­ce­su powi­nien mieć zawsze kon­kret­ny kon­tekst i być osa­dzo­ny w jakiejś meto­dy­ce, bez tego trud­no pod­jąć decy­zję, któ­re infor­ma­cje są istot­ne i jakie deta­le poka­zy­wać (bo nota­cje są nad­mia­ro­we i nie są meto­dy­ką). Bez tego tak­że trud­no innej oso­bie taki dia­gram jed­no­znacz­nie zin­ter­pre­to­wać. Najgorsze wyj­ście to ​„nie wiem, więc poka­że wszyst­ko co wiem” z czym tu mamy moim zda­niem do czynienia.

Jak to robić? Przyjmuję postę­po­wa­nie zgod­ne MDA/MDE (pisa­łem tu o tym nie raz), więc naj­pierw two­rzy­my model CIM (Computation Independent Model), któ­re­go celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie mecha­ni­zmu – tu – reje­stra­cji kon­ta, typo­wy mecha­nizm opt-in:

Co do zasa­dy aktyw­ność w pro­ce­sie to coś co sta­no­wi kom­plet­nie wyko­na­ną pra­cę (bo pro­ces to aktyw­ność prze­kształ­ca­ją­ca wej­ście w wyj­ście), więc dzie­le­nie jej na kawał­ki nie ma żad­ne­go uza­sad­nie­nia. Detale aktyw­no­ści poka­zu­je­my na odręb­nym dia­gra­mie, a czę­ściej jako zapi­sa­ną tek­stem pro­ce­du­rę (jest nie­po­dziel­na bo aktyw­ność jest jed­na). Np. aktyw­ność Rejestracja po stro­nie (w puli) Klienta to:

  1. ini­cja­cja reje­stra­cji konta
  2. SYSTEM wyświe­tla for­mu­larz Dane użytkownika
  3. wypeł­nie­nie pól for­mu­la­rza i potwierdzenie
  4. jeże­li 
    1. dane są popraw­ne – SYSTEM potwier­dza przy­ję­cie danych
    2. dane są nie­po­praw­ne – SYSTEM pre­zen­tu­je for­mu­larz Dane użyt­kow­ni­ka i wyświe­tla komu­ni­kat (lub idź do punkt 2.) 
  5. (koniec)

(cza­sa­mi doda­ję pseu­do krok pro­ce­du­ry koniec aby czy­tel­nik miał pew­ność, że to ukoń­czo­na praca).

Po stro­nie (w puli) Organizacji zaini­cjo­wa­ne żąda­nie reje­stra­cji spo­wo­du­je obsłu­gę pierw­sze­go dia­lo­gu z Klientem, tu ostat­nim kro­kiem pro­ce­du­ry jest wysła­nie moni­tu mailem. Następnie Organizacja cze­ka, jeże­li dosta­nie potwier­dze­nie to akty­wu­je kon­to Klienta, zaś po trzech dniach bez­czyn­no­ści, Dane użyt­kow­ni­ka zosta­ną usu­nię­te, i pro­ces reje­stra­cji zosta­nie uzna­ny za zakoń­czo­ny (tu niepowodzeniem).

Na tym eta­pie prac wie­my co i jak Organizacja robi w przy­pad­ku reje­stra­cji Klienta. Cały ten amba­ras jed­nak do cze­goś słu­ży, słu­ży do udo­stęp­nia­nia Klientowi moż­li­wo­ści skła­da­nia zamó­wień i danych o sta­nie jego roz­ra­chun­ków. W przy­kła­dzie mamy dia­gram przy­pad­ków uży­cia, więc i ja pój­dę tym tro­pem (zakres projektowania).

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mamy tu czte­ry przy­pad­ki uży­cia. Skąd? O tym dalej. Pisałem już wcze­śniej o trans­for­ma­cji z mode­lu BPMN na model Przypadków uży­cia. Tu poka­że efekt końcowy. 

Dlaczego tak?

Przede wszyst­kim logo­wa­nie (wbrew wie­lu przy­kła­dom w sie­ci) nie jest przy­pad­kiem uży­cia, czy­li nie jest usłu­gą apli­ka­cji, jest cechą śro­do­wi­ska, jed­nym z wie­lu spo­so­bów auto­ry­zo­wa­nia użyt­kow­ni­ka do pra­cy (inne to LDAP, Activedirectory, odcisk pal­ca, itp., jest to meto­da reali­za­cji wyma­ga­nia poza­funk­cjo­nal­ne­go o nie­do­pusz­cza­niu do korzy­sta­nia z usług apli­ka­cji nie­au­to­ry­zo­wa­nych osób). Nie jest dobrym pomy­słem uzna­wa­nie takich czyn­no­ści jako usług apli­ka­cji (kto kupi coś co słu­ży wyłącz­nie do logo­wa­ni się?) 

Mamy tu przy­pa­dek uży­cia Zarządzanie kon­tem. Jest to usłu­ga pole­ga­ją­ca na two­rze­niu, aktu­ali­za­cji, pod­glą­dzie lub usu­nię­ciu danych użyt­kow­ni­ka (stan­dar­do­wo ozna­cza sie takie usłu­gi CRUD, ang. Create, Retrieve, Update, Delete, są to reje­stry pozba­wio­ne dzie­dzi­no­wej logi­ki biz­ne­so­wej, kon­tro­lu­je­my wyłącz­nie popraw­ność samych pól). Korzysta z niej Klient, pierw­sze uży­cie (kon­tekst Create) to nic inne­go jak reje­stra­cja w sys­te­mie, każ­de kolej­ne uży­cie to będzie kolej­na aktu­ali­za­cja danych (kon­tekst Update) lub osta­tecz­nie pole­ce­nie ich usu­nię­cia (kon­tekst Delete).

Scenariusz reje­stra­cji, opi­sa­ny wcze­śniej, wyglą­dał by tak:

To tu są poka­za­ne (udo­ku­men­to­wa­ne) kolej­ne kro­ki reali­zo­wa­ne przez pro­jek­to­wa­ny System. W tym przy­pad­ku cały pro­ces samo­ob­słu­gi Klienta (zarzą­dza­nie dany­mi o sobie) został zauto­ma­ty­zo­wa­ny (czy­li nie robią tego już pra­cow­ni­cy Organizacji a apli­ka­cja). W efek­cie model pro­ce­su biz­ne­so­we­go przy­bie­rze osta­tecz­ny kształt ​„to-be”:

Jedynie Klient uży­wa apli­ka­cji, to kto jest wła­ści­cie­lem opro­gra­mo­wa­nia nie ma żad­ne­go zna­cze­nia i nie mode­lu­je­my tego. Wskazane na wcze­śniej­szym dia­gra­mie regu­ły biz­ne­so­we (np. ocze­ki­wa­nie na powie­dze­nie reje­stra­cji wyga­sa po trzech dniach) moż­na zebrać w posta­ci zesta­wie­nia i dołą­czyć do doku­men­ta­cji przy­pad­ków uży­cia, albo po pro­stu prze­ka­zać deve­lo­pe­ro­wi całą doku­men­ta­cję (oso­bi­ście powie­lam zesta­wie­nia reguł biz­ne­so­wych przy przy­pad­kach uży­cia, co pole­cam, zaś nad­mia­ro­wa doku­men­ta­cja jest łatwiej­sza w uży­ciu dla developera).

Autor cyto­wa­ne­go arty­ku­łu umie­ścił w nim tak­że taki diagram:

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mogę to teraz sko­men­to­wać tak:

  1. jest to jakieś nie­for­mal­ne zesta­wie­nie ​„funk­cjo­nal­no­ści”
  2. funk­cjo­nal­no­ści ozna­czo­ne 1, 2 oraz 3 to nic inne­go jak uży­cie, w róż­nym kon­tek­ście, przy­pad­ku uży­cia (CRUD) Zarządzanie kon­tem. 

Nie mode­lo­wa­łem już pro­ce­su skła­da­nia zamó­wie­nia (mam nadzie­ję że nie trze­ba :)). Kalendarz to pew­na for­ma zobra­zo­wa­nia ter­mi­nów (np. zamó­wień, jeże­li było takie wyma­ga­nie), być może na stro­nie ​„panel Klienta” (robo­ta dla UX desi­gne­ra). Monitowanie (6. Notification) to nic inne­go jak kolej­ne poza­funk­cjo­nal­ne wyma­ga­nie (moni­to­wa­nie o czymś jako takie to nie jest przy­pa­dek uży­cia), reali­zo­wa­ne w spo­sób udo­ku­men­to­wa­ny na dia­gra­mie sekwen­cji (sce­na­riusz reali­za­cji przy­pad­ku uży­cia). Diagram sekwen­cji jak wyżej, po drob­nych korek­tach, będzie paso­wał do każ­dej ope­ra­cji z dany­mi Klienta, tak­że do aktyw­no­ści Zapoznanie się z tre­ścią danych w toku potwier­dza­nia reje­stra­cji (tu kon­tekst pro­ste­go potwier­dze­nia ope­ra­cji Retrive).

Przedstawiłem wer­sję, któ­ra nie wyma­ga uży­wa­nia żad­nych nie­for­mal­nych dia­gra­mów (UML i BPMN w zupeł­no­ści wystar­czą). Wersję, któ­ra jest zgod­na z MDA, więc wpi­su­je się dobrze w pro­ces ana­li­zy biz­ne­so­wej (model CIM), oddzie­lo­nej od pro­jek­to­wa­nia (model PIM) i imple­men­ta­cji (model PSM, tu pomi­nię­ty i real­nie rzad­ko wyko­ny­wa­ny u deve­lo­pe­ra). Wersję, któ­ra w 100% pozwa­la na śla­do­wa­nie wyma­gań. To co opi­sa­łem jest tak­że zgod­ne z zale­ce­nia­mi BABoK, two­rze­nia jako wyma­ga­nia mode­li ​„bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia (pro­duk­tu).

Jak widać, moż­li­we jest, że jeden przy­pa­dek przy­pa­dek uży­cia (doty­czy to szcze­gól­nie tych ozna­cza­nych CRUD) jako usłu­ga apli­ka­cji, będzie wyko­rzy­sty­wa­ny w wie­lu kon­tek­stach (podob­nie jak mło­tek i jego usłu­ga ​„uderz w to”, może być uży­ty zarów­no do wbi­ja­nia gwoź­dzia jak i do wybi­ja­nia szyby). 

Chciałem tak­że kolej­ny raz poka­zać, że zamiast doku­men­to­wa­nia wyma­gań meto­dą mon­stru­al­nych opi­sów pro­zą i zesta­wień w tabe­lach, z któ­ry­mi to opi­sa­mi auto­rzy mają nie raz ogrom­ne pro­ble­my z utrzy­ma­niem ich kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści zaś deve­lo­pe­rzy ogrom­ne pro­ble­my z inter­pre­ta­cją, war­to wyma­ga­nia prze­ka­zy­wać w posta­ci spój­ne­go i prze­te­sto­wa­ne­go i logicz­ne­go pro­jek­tu. Warto tak­że zadbać by sche­ma­ty blo­ko­we (mode­le) były two­rzo­ne zgod­ne z okre­ślo­ny­mi zasa­da­mi (nota­cje, dobre prak­ty­ki) bez cze­go będą trud­ne w jed­no­znacz­nej interpretacji. 

Moi zda­niem podej­ście MDA zapre­zen­to­wa­ne powy­żej jest znacz­nie sku­tecz­niej­sze i daje lep­sze zro­zu­mie­nie, niż wer­sja poka­za­na przez auto­ra arty­ku­łu Use cases or busi­ness pro­cess maps, what tech­ni­que to use?, ale oce­nę pozo­sta­wiam czy­tel­ni­kom (zachę­cam do zada­wa­nia pytań i dyskusji).

Co z tytu­ło­wym pyta­niem: Przypadki uży­cia czy model pro­ce­su, cze­go używać? 

Używać obu dia­gra­mów zgod­nie z ich przeznaczeniem…

Słowa kluczowe: , , , , , , ,

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

  1. MikeR 6 stycznia 2017 Odpowiedz

    Czy te ste­reo­ty­py (tu <>) w aktyw­no­ściach BPMN to jakiś autor­ski pomysł (dia­gram «BPMN Rejestracja kon­ta»)? Przejrzałem na szyb­ko książ­kę Sz. Drejewicza, B. Silvera i spe­cy­fi­ka­cję i nic takie­go tam nie widzę.
    Btw czy w «Diagram przy­pad­ków uży­cia 2» nie powi­nien być tyl­ko jeden przy­pa­dek «Zarządzanie kon­tem»? To «Sprawdzenie sal­da» to imho jest to R w CRUDzie 🙂

    1. Jaroslaw Zelinski 6 stycznia 2017

      BPMN od wer­sji 2.0 dopusz­cza doda­wa­nie nowych ​„zna­ków” pod warun­kiem popraw­ne­go ich zde­fi­nio­wa­nia (mecha­nizm ana­lo­gicz­ny do pro­fi­li w UML). W lite­ra­tu­rze spo­ty­ka­ne są róż­ne kon­wen­cje kla­sy­fi­ko­wa­nia aktyw­no­ści na mode­lach ana­li­tycz­nych (np. tych trans­for­mo­wa­nych na przy­pad­ki uży­cia): kolo­ro­wa­nie, koja­rze­nie z iko­ną ​„kom­pu­ter”, odpo­wied­ni­kiem kolo­ro­wa­nia jest ste­reo­ty­po­wa­nie (nie­któ­re narzę­dzia CASE mają wbu­do­wa­ne moż­li­wo­ści uży­cia wszyst­kich te moż­li­wo­ści). Moim zda­niem ste­reo­ty­po­wa­nie jest naj­wy­god­niej­sze bo poję­cie pro­fi­lu jest dobrze zde­fi­nio­wa­ne w OMG/UML. Generalnie OMG nor­ma­li­zu­je ​„swo­je” nota­cje (co widać bar­dzo w zmia­nach w UML 2.5). Co do zasa­dy nie sto­su­ję żad­nych ​„autor­skich” kon­struk­cji 🙂 bo nisz­czą komu­ni­ka­cję (inni mogą nie zro­zu­mieć) i prze­no­szal­ność dia­gra­mów mię­dzy narzędziami. 

      Co do przy­pad­ków uży­cia (PU): Konto Klienta to dane o nim (kar­to­te­ka), sal­do płat­no­ści to wyli­cze­nie aktu­al­ne­go sal­da na bazie fak­tur i np. prze­le­wów. To dwa róż­ne ​„obiek­ty biz­ne­so­we”. Z powo­dów czy­sto tech­nicz­nych (nie roz­pi­sy­wa­łem się) nie pre­cy­zo­wa­łem tego, wspo­mi­na o tym jed­nak autor arty­ku­łu cyto­wa­ne­go i mia­łem cichą nadzie­ję, że widać to na cyto­wa­nych dia­gra­mach. Niewątpliwie, pil­nu­jąc gra­nic kon­tek­stów, ​„kar­to­te­ka klien­ta”, czy­li jego dane reje­stra­cyj­ne, nie są obiek­tem, któ­ry prze­cho­wu­je dane finan­so­we. Dlatego sal­do klien­ta to Retrive inne­go obiek­tu więc i odręb­ny PU. Dodam, że nie widzę żad­ne­go uza­sad­nie­nia dla oddzie­le­nia reje­stra­cji klien­ta od aktu­ali­za­cji danych o nim, co pro­po­nu­je autor arty­ku­łu cyto­wa­ne­go. Kolejna wada pier­wo­wzo­ru to brak słow­ni­ka pojęć, ja oso­bi­ście zresz­tą uni­kam nazwy ​„kon­to” na dane rejestrowe ;)…

  2. MikeR 6 stycznia 2017 Odpowiedz

    Dzięki za wyczer­pu­ją­cą odpo­wiedź 🙂 Rzeczywiście to sło­wo ​„kon­to” mnie zmy­li­ło w kon­tek­ście tych przy­pad­ków użycia.

    1. Jaroslaw Zelinski 7 stycznia 2017

      Dlaczego ZAWSZE (tu już o tym nie pisa­łem) zwra­cam uwa­gę by zaczy­nać od słow­ni­ków pojęć i kon­tek­sto­wych mode­li poję­cio­wych (co autor arty­ku­łu tak­że pomi­nął). O złym nazew­nic­twie jako źró­dle wie­lu pro­ble­mów pisa­łem tu ​„Czym jest model…”

  3. Greg 9 stycznia 2017 Odpowiedz

    Czy czyn­no­ści reje­stra­cja i zapo­zna­nie się z tre­ścią będą reali­zo­wa­ne jako jeden pu?

    1. Jaroslaw Zelinski 9 stycznia 2017

      Zakładając kon­wen­cję sto­so­wa­nia CRUD tak. Za pierw­szym razem to dwa kro­ki: Create potem Retrive, każ­dy następ­ny raz to krok: Update i Retrive. Obiekt repre­zen­tu­ją­cy dane użyt­kow­ni­ka jest jeden… Za pierw­szym razem będzie ini­cjo­wa­ny, potem już tyl­ko aktu­ali­za­cja lub wgląd.., Dla pew­no­ści moż­na zosta­wić cykl koniecz­ność potwier­dza­nia (opt-in) każ­dej doko­na­nej zmia­ny (co czę­sto zalecam).

  4. Greg 11 stycznia 2017 Odpowiedz

    Dziękuję za informację.

  5. Greg 11 stycznia 2017 Odpowiedz

    Nie rozu­miem Pańskiego wytłu­ma­cze­nia, dla­cze­go muszą być 2 pu «zarzą­dza­nie kon­tem (crud)» i «spraw­dze­nie sal­da». Pisze Pan, że muszą być 2, gdyż doty­czą ope­ra­cji na róż­nych obiek­tach (kar­to­te­ka i dane finan­so­we). Z tego co wiem, pu repre­zen­tu­ją funk­cjo­nal­no­ści uży­tecz­ne dla akto­ra, co ozna­cza, że dana funk­cjo­nal­ność może ope­ro­wać na róż­nych obiek­tach. Inaczej, punk­tem wyj­ścia do spe­cy­fi­ko­wa­nia pu są funk­cjo­nal­no­ści, a nie obiek­ty. Czy się mylę?

    1. Jaroslaw Zelinski 11 stycznia 2017

      PU repre­zen­tu­ją usłu­gi (ja piszę wyłącz­nie o UML). PU nie repre­zen­tu­ją ​„funk­cjo­nal­no­ści”.
      Specyfiakcja UML 2.5:
      18 UseCases
      18.1 Use Cases
      18.1.1 Summary
      UseCases 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. The key concepts
      spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under
      con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are represented
      as Actors.
      A UseCase is a spe­ci­fi­ca­tion of beha­vior. An instan­ce of a UseCase refers to an occur­ren­ce of the emer­gent behavior
      that con­forms to the cor­re­spon­ding UseCase. Such instan­ces are often descri­bed by Interactions.
      18.1.3 Semantics
      18.1.3.1 Use Cases and Actors
      A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of behaviors
      per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the
      subject.

      Tak więc czym innym jest ​„aktu­ali­za­cja danych użyt­kow­ni­ka” (potocz­nie zwa­ne kon­tem w sys­te­mie) a czym innym ​„stan roz­ra­chun­ków” (któ­re doty­czą użyt­kow­ni­ka, jest to stan jego kon­ta finan­so­we­go, nie są to ​„dane go opisujące”).

      W UML, nie ma wyróż­nia­ne­go ści­słe­go poję­cia ​„funk­cjo­nal­ność”, za jest poję­cie ​„usłu­gi aplikacyjnej”. 

      Sugeruję w kon­tek­ście UML korzy­stać ze spe­cy­fi­ka­cji tego języka.

  6. Greg 12 stycznia 2017 Odpowiedz

    1. OK – PU repre­zen­tu­ją usłu­gi systemu.
    2. Nadal uwa­żam, że przy pro­jek­to­wa­niu PU wycho­dzę od usług, któ­re sys­tem świad­czy akto­ro­wi, a nie od obiek­tów, któ­re są zwią­za­ne z usługami.
    3. Nie rozu­miem zapi­su » ​”A UseCase may apply to any num­ber of sub­jects.” Myślałem, że kon­kret­ny PU nale­ży do kon­kret­ne­go sys­te­mu (sub­ject). Prośba o wyjaśnienie.

    1. Jaroslaw Zelinski 12 stycznia 2017

      1. ok 🙂

      2. tu waż­na uwa­ga: archi­tek­tu­ra nie jest obo­jęt­na, mamy to co nazy­wa­my wzor­ca­mi pro­jek­to­wy­mi i dobry­mi prak­ty­ka­mi, jed­nym z nich jest wzo­rzec archi­tek­to­nicz­ny ​„przy­pa­dek uży­cia jako mikro­ser­wis” a do tego mamy SOLID, w tym sepa­ra­cja kon­tek­stów czy her­me­ty­za­cja kom­po­nen­tów itp.. (temat na osob­ny wykład lub małe stu­dia), gene­ral­nie PU powi­nien być quasi nie­za­leż­ną usłu­gą (w dobrze zapro­jek­to­wa­nym sys­te­mie kolej­ność imple­men­ta­cji PU nie powin­na być ogra­ni­czo­na), w kon­se­kwen­cji PU to usłu­gi bazu­ją­ce na jed­nym obiek­cie biz­ne­so­wym (lub zło­żo­nym agre­ga­cie). Polecam np. te dwa wpi­sy Fowlera:
      https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml

      https://​mar​tin​fow​ler​.com/​a​r​t​i​c​l​e​s​/​m​i​c​r​o​s​e​r​v​i​c​e​s​.​h​tml

      3. to pro­ste: PU to usłu­ga i np. ​„System pozwa­la wysta­wić fak­tu­ry i zarzą­dzać nimi” a może to być usłu­ga sys­te­mu ERP, pro­ste­go FK, sys­te­mu CRM.… zda­rza­ły mi pro­jek­ty, gdzie gdzie fak­tu­ry wysta­wia­ne były w kil­ku sys­te­mach i inte­gro­wa­ne w cen­tral­nym ERP/FK…

  7. Greg 12 stycznia 2017 Odpowiedz

    Rozumiem, że w przy­pad­ku inte­gra­cji fak­tur w sys­te­mie cen­tral­nym był jeden PU «Wystawianie fak­tur», któ­ry był reali­zo­wa­ny w kil­ku systemach?

    1. Jaroslaw Zelinski 12 stycznia 2017

      Tak: fak­tu­rę mogła wysta­wić księ­go­wa w ERP i sprze­daw­ca w CRM (w kil­ku­na­stu oddzia­łach). Nie ma w tym nic niezwykłego.

  8. Greg 12 stycznia 2017 Odpowiedz

    1. Wystawienie fak­tu­ry rozu­mie­my jako wyge­ne­ro­wa­nie doku­men­tu z zapi­sa­nych danych w sys­te­mie ERP albo CRM.
    2. Rozumiem, że logi­ka gene­ro­wa­nia fak­tu­ry opi­sa­na w jed­nym PU zosta­ła zaim­ple­men­to­wa­na w 2 sys­te­mach (ERP i CRM) +- obsłu­ga pobie­ra­nia zapi­sa­nych danych.

    1. Jaroslaw Zelinski 12 stycznia 2017

      1. Wystawienie fak­tu­ry to utwo­rze­nie doku­men­tu będą­ce­go fak­tu­rą, myśle­nie bazo­da­no­we (wszyst­ko jest rapor­tem) jest bar­dziej szko­dli­we niż pomocne.
      2. PU to zewnętrz­ne obja­wy zacho­wa­nia sys­te­mu. Logika (wewnętrz­ny mecha­nizm) może być róż­na, np. tyl­ko w CRM będzie logi­ka upu­stów dla sta­łych klien­tów ale obie usłu­gi, w efek­cie, dadzą jako swój pro­dukt fak­tu­rę zgod­ną z prawem.

  9. Greg 13 stycznia 2017 Odpowiedz

    1. Dlaczego wysta­wie­nie fak­tu­ry jest czymś wię­cej niż wysta­wie­niem rapor­tu?, są dane sprze­da­żo­we, z któ­rych gene­ru­je­my dokument?
    2. Tak się zasta­na­wiam się, czy ERP i CRM trak­tu­je­my jako jeden sys­tem (gdzie ERP I CRM to kom­po­nen­ty), czy jako 2 nie­za­leż­ne systemy?

    1. Jaroslaw Zelinski 13 stycznia 2017

      1. bo mowa o ​„stwo­rze­niu doku­men­tu o okre­ślo­nej struk­tu­rze z uży­ciem okre­ślo­ne­go mecha­ni­zmu”, po dru­gie baza danych nie prze­cho­wu­je żad­nych doku­men­tów tyl­ko roz­dzie­lo­ne znor­ma­li­zo­wa­ne dane.… dla­te­go uży­wa­jąc rela­cyj­ne­go sys­te­mu i bazy danych ​„wszyst­ko jest rapor­tem”… a fak­tu­ra w rze­czy­wi­sto­ści jest (i powin­na być) zma­te­ria­li­zo­wa­nym bytem powsta­łym w dniu wysta­wie­nia, cze­go zresz­tą wyma­ga od sys­te­mów prawo.
      2. oczy­wi­ście jako dwa odręb­ne sys­te­mu, tym bar­dziej, że w dowol­nym momen­cie przy­szło­ści jeden z nich może wyma­gać zmia­ny lub nawet wymia­ny i nie powin­no to pocią­gać za sobą ​„zmia­ny całości”…

  10. Greg 13 stycznia 2017 Odpowiedz

    OK. Dziękuję za wyjaśnienie.

Dodaj komentarz

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