Wymagania na opro­gra­mo­wa­nie są czę­sto doku­men­to­wa­ne z pomo­cą Przypadków Użycia (PU), zwa­nych w ​„ory­gi­na­le” Use Case (UC). Wygodą sto­so­wa­nie tej kon­wen­cji jest trak­to­wa­nie Systemu jako tak zwa­nej czar­nej skrzyn­ki, czy­li cze­goś, cze­go wewnętrz­nej budo­wy nie zna­my, ale zna­my reak­cje na bodź­ce. W przy­pad­ku opro­gra­mo­wa­nia, nie wie­my jak jest ono zbu­do­wa­ne (w momen­cie zama­wia­nia go, może ono jesz­cze nie ist­nieć), ale wie­my jak reagu­je na ​„pole­ce­nia”. Jest to uzna­nie zasa­dy, że zama­wia­ją­cy defi­niu­je CO opro­gra­mo­wa­nie ma robić a nie to JAK ono to robi. W przy­pad­ku goto­we­go opro­gra­mo­wa­nia, lub na eta­pie poprze­dza­ją­cym pro­jek­to­wa­nie, ma to sens, jed­nak nale­ży pamię­tać, że przy­pad­ki uży­cia nie deter­mi­nu­ją tego co tak na praw­dę dosta­nie­my, co opi­sa­łem w arty­ku­le o tym co na praw­dę opi­su­ją przy­pad­ki uży­cia.

Przypadki uży­cia budzą jed­nak wie­le kon­tro­wer­sji, gdyż kon­wen­cja ta jest sfor­ma­li­zo­wa­na (jest to część nota­cji UML), uży­wa­nie jej ​„po swo­je­mu” pro­wa­dzi naj­czę­ściej do bez­u­ży­tecz­no­ści mode­li przy­pad­ków użycia.

Jeden z czy­tel­ni­ków spro­wo­ko­wał cie­ka­wą dyskusję:

…jakiej nota­cji uży­wa Pan, aby poka­zać wpływ jed­ne­go pro­ce­su na dru­gi? Konkretnie cho­dzi mi o przy­pa­dek, że pro­blem wystę­pu­je w pro­ce­sie roz­li­cza­nia płat­no­ści, ale żeby go napra­wić trze­ba wpro­wa­dzić zmia­ny w pro­ce­sie zaku­pów. Nie wiem czy samo roz­ry­so­wa­nie pro­ce­sów w BPMN jest wystar­cza­ją­ce czy moż­na to jakoś lepiej zamodelować.

Niektóre ana­li­zy wyma­ga­ją cze­goś ​„ponad” pro­ce­sa­mi”. Mamy dwa wyj­ścia: two­rze­nie nad­rzęd­nych map pro­ce­sów i na nich ​„szu­ka­nie” związ­ków albo zasto­so­wa­nie innej nota­cji na ​„wyż­szym pozio­mie abs­trak­cji”. Notacja np. BPMN wystar­czy, rzecz w tym by opi­sać pro­ces na odpo­wied­nio wyso­kim pozio­mie abs­trak­cji. Tego typu pro­ble­my wyma­ga­ją uogól­nie­nia i spoj­rze­nia z ​„wyż­szej” per­spek­ty­wy. Pomagają przy­pad­ki użycia.

Jeśli cho­dzi o mode­le PU, to przy­znam, że rzad­ko je sto­su­ję. W przy­pad­ku 1 czyn­ność – 1 PU, to jeśli mamy pro­ces w BPMN, to wg mnie model PU, to po pro­stu wrzu­ce­nie do jed­ne­go wor­ka wszyst­kich czyn­no­ści. Czyli jest to inna gra­ficz­nie (wg mnie słab­sza, bo brak kolej­no­ści) pre­zen­ta­cja tego same­go co w BPMN. Chyba że mamy czyn­no­ści, któ­re nie są wspie­ra­ne sys­te­mem albo wie­le pro­ce­sów, któ­re wyko­rzy­stu­ją tą samą czyn­ność (róż­ni akto­rzy dla tego same­go PU).

Troszkę o tym (przy­pad­ki uży­cia w skró­cie PU) tu: https://it-consulting.pl//?s=przypadki+u%C5%BCycia

Ogólnie PU to usłu­ga sys­te­mu, czyn­ność w pro­ce­sie to ele­ment pew­ne­go łań­cu­cha takich czyn­no­ści (pro­ces ma swój cel, pew­ne czyn­no­ści mogą się powta­rzać w róż­nych pro­ce­sach, np. archi­wi­za­cja doku­men­tu). System (opro­gra­mo­wa­nie) rzad­ko wspo­ma­ga wszyst­kie czyn­no­ści w pro­ce­sach. Model pro­ce­su słu­ży do zro­zu­mie­nia (i prze­te­sto­wa­nia) tego co i po co się dzie­je w orga­ni­za­cji, część czyn­no­ści (zakres pro­jek­tu) jest (ma być) wspie­ra­na opro­gra­mo­wa­niem (usłu­ga systemu).

Po dru­gie model PU to tak na praw­dę korzeń struk­tu­ry opi­su opro­gra­mo­wa­nia. Rolą mode­lu PU nie jest opis pro­ce­sów a spe­cy­fi­ka­cja ​„usług sys­te­mu” z per­spek­ty­wy ​„zewnętrz­ne­go użyt­kow­ni­ka”, jest to opis funk­cji narzę­dzia a nie proces.

Rzecz zasa­dza się w tym, jak zosta­ną zde­fi­nio­wa­ne poję­cia ​„przy­pa­dek uży­cia” i ​„czyn­ność” (w pro­ce­sie). Ciekawe jest to, że obie te defi­ni­cje są (PU w UML i czyn­ność w BPMN) per­ma­nent­nie zanie­dby­wa­ne (łama­ne) w doku­men­ta­cjach pro­jek­to­wych. W moich oczach jest to nie­zro­zu­mie­nie celo­wo­ści mode­lo­wa­nia, któ­re ma być lekar­stwem na nie­jed­no­znacz­ność pro­zy a nie jej inną firmą.

Dziękuję, za takie pre­cy­zyj­ne (łopa­to­lo­gicz­ne) wyja­śnie­nie. Mimo, że czy­ta­łam wcze­śniej Pana arty­ku­ły (oczy­wi­ście nie wszyst­kie) to dopie­ro teraz to do mnie wyraź­nie dotar­ło. Nadal nie wiem jak sen­sow­nie za pomo­cą mode­lu PU przed­sta­wić peł­ny zakres sys­te­mu np. ERP/CRM. Na takim dia­gra­mie powin­no być chy­ba kil­ka­dzie­siąt ele­men­tów i taki dia­gram nie będzie wg mnie przej­rzy­sty. Czy może dla jed­ne­go sys­te­mu nale­ży zro­bić kil­ka mode­li PU, ale z podzia­łem na aktorów…

A czy ma Pan może jakiś przy­kład PU gdzie akto­ra­mi są 2 sys­te­my tzn. nie ma udzia­łu oso­by fizycznej?

Duże sys­te­my war­to podzie­lić na tak zwa­ne blo­ki funk­cjo­nal­ne ogra­ni­czo­ne dzie­dzi­no­wo (tak zwa­ne [[boun­ded con­text]]) i ​„pra­co­wać nad nimi” nie­za­leż­nie (każ­dy ma swój inter­fejs). Duży sys­tem może mieć set­ki UC, dzie­li się je na pakie­ty ale nie ​„per aktor” a raczej ​„per kon­tekst” (np. księ­go­wa­nie dowo­dów księ­go­wych w jed­nym pod­sys­te­mie, nie­za­leż­nie od tego ilu jest akto­rów). Nie ma sen­su upy­cha­nie na jed­nym dia­gra­mie wszyst­kich UC…

Co do zasa­dy, model PU zawie­ra poję­cie System (abs­trak­cja mode­lo­wa­ne­go opro­gra­mo­wa­nia), w nim przy­pad­ki uży­cia (PU) oraz poza nim akto­rów tego Systemu. Co jest waż­ne: model PU to model ​„Jednego sys­te­mu i jego oto­cze­nia”, jeden model PU nie może zawie­rać wie­lu rów­no­rzęd­nych Systemów.

Co do zasa­dy model PU to: System mode­lo­wa­ny, przy­pad­ki jego uży­cia (jego usłu­gi świad­czo­ne na zewnątrz) oraz akto­rzy, akto­rem jest każ­dy zewnętrz­ny byt żąda­ją­cy obsłu­gi. Możliwe jest więc, że sys­tem nie ma żad­ne­go ​„ludz­kie­go” akto­ra. Nie prze­sa­dzał bym z tym, że PU to ​„głów­nie roz­mo­wy sys­te­mów” choć pro­jek­tu­jąc ​„głów­nie” sys­te­my mid­dle­wa­re i ele­men­ty inte­gra­cji moż­na mieć ​„takie wrażenie” 🙂

O narzę­dziach

Agilian ogól­nie wspie­ra każ­de ​„śla­do­wa­nie”. Każda ope­ra­cja utwo­rze­nia PU z czyn­no­ści BPMN, po dro­dze ma etap wska­za­nia jaki dia­gram UC oraz jaki Model jest doce­lo­wy (a może ich być wie­le). Tu trze­ba bar­dzo uwa­żać, bo jeże­li mam pro­ces (np. w BPMN) obsłu­gi rekla­ma­cji, to poja­wią się czyn­no­ści z obsza­ru FK (spraw­dze­nia czy sprze­da­no taki towar), z obsza­ru logi­sty­ki (spraw­dze­nia kie­dy wyda­no lub dostar­czo­no) oraz CRM (czyn­no­ści ​„biu­ro­we” obsłu­gi klien­ta, tu obsłu­ga rekla­ma­cji). W zasa­dzie jeden pro­ces ​„użył” co naj­mniej trzy narzę­dzia (sys­te­my) z róż­nych obsza­rów dziedzinowych.

Co do adre­sa­tów dia­gra­mów, ja tak­że skła­niam się ku tezie, że dla biz­ne­su jest BPMN a PU to już dia­gram ​„sys­te­mo­wy”, jed­nak wie­le meto­dyk (w tym RUP) trak­tu­je dia­gram PU jako pierw­szy powsta­ją­cy (?!) i jako adre­so­wa­ny do zama­wia­ją­ce­go… cóż…

Generalnie dia­gram PU jest bar­dzo dobrym ​„korze­niem” do ana­li­zy i two­rze­nia pozo­sta­łych mode­li, ale bez powsta­ją­ce­go ​„natych­miast” mode­lu dzie­dzi­ny nie jest moż­li­we zapro­jek­to­wa­nie gra­nic (boun­ded con­text) dla komponentów.

Spotykam się w lite­ra­tu­rze z teza­mi, któ­re uwa­żam za słusz­ne, że jeden sys­tem (pod­sys­tem) nie powi­nien prze­kra­czać 50 klas biz­ne­so­wych w dzie­dzi­nie (licz­ba bli­ska 100 to ogrom­ny sys­tem). Praca nad opro­gra­mo­wa­niem powin­na zacząć się od ana­li­zy i roz­bi­cia pro­ble­mu na ​„straw­ne” kawał­ki. Najpierw podział na pod­sys­te­my, potem na kom­po­nen­ty, a na koń­cu kon­kret­ne kla­sy i ich realizacje.

Nie ma tu mowy o podzia­le z per­spek­ty­wy akto­ra, bo jeże­li wie­my jaka jest kon­struk­cja zapro­jek­to­wa­ne­go młot­ka albo kal­ku­la­to­ra, to nie może­my ogra­ni­czyć (bo nie mamy pod­staw) licz­by ich użyt­kow­ni­ków, bo każ­dy ma swo­je uza­sad­nio­ne powo­dy by wziąć do ręki np. młotek.…