Dzisiaj co nie­co o filo­zo­fii i przy­pad­kach użycia.

usecase pandora

Dzielenie przy­pad­ków uży­cia na rodza­je” zawsze budzi­ło mój sprze­ciw, w UML (w ory­gi­na­le) mamy jed­no poję­cie: przy­pa­dek uży­cia sys­te­mu”, gdzie sys­te­mem jest coś (przed­miot opi­su), czy­li analizowany/modelowany sys­tem” (patrząc na sys­tem w rozu­mie­niu teo­rii sys­te­mów, tu zwra­cam uwa­gę na fakt, że UML to nie tyl­ko IT). Wobec tego sko­ro sys­tem (wymien­nie przed­miot zain­te­re­so­wa­nia”, przed­miot ana­li­zy”), zanim będzie roz­pa­try­wa­ny, musi być okre­ślo­ny (gra­ni­ce sys­te­mu, któ­ry jest czę­ścią nad” (super) sys­te­mu, a skła­da się z pod­sys­te­mów, pole­cam Sienkiewicz, Teoria Systemów), otrzy­ma­my pro­stą rzecz: przy­pa­dek uży­cia ma jed­ną defi­ni­cję, ale w danym momen­cie roz­pa­try­wa­nym sys­te­mem (przed­miot ana­li­zy) jest np. opro­gra­mo­wa­nie ale też może nim być np. orga­ni­za­cja. Tak więc przy­pa­dek uży­cia opro­gra­mo­wa­nia” (np. wysta­wia­nie fak­tu­ry VAT) niczym się nie róż­ni od przy­pad­ku uży­cia” fir­my sprze­da­ją­cej rowe­ry dostar­cze­nie zamó­wio­ne­go rowe­ru”, to co tu robi róż­ni­cę” to gra­ni­ce sys­te­mu- kon­tekst: raz jest nią gra­ni­ca opro­gra­mo­wa­nia” a raz orga­ni­za­cji”.

Proste poję­cie przy­pad­ku uży­cia jest pięk­ne bo pro­ste. Popatrzmy do ory­gi­nal­nej spe­cy­fi­ka­cji (OMG Unified Modeling Language (OMG UML), Superstructure Version 2.4.1):

16. Use Cases

16.1 Overview

Use cases are a means for spe­ci­fy­ing requ­ired usa­ges of a sys­tem. Typically, they are used to cap­tu­re the requ­ire­ments of a sys­tem, that is, what a sys­tem is sup­po­sed to do. The key con­cepts asso­cia­ted with use cases are actors, use cases, and the sub­ject. The sub­ject is the sys­tem under con­si­de­ra­tion to which the use cases apply. The users and any other sys­tems that may inte­ract with the sub­ject are repre­sen­ted as actors. Actors always model enti­ties that are out­si­de the sys­tem. The requ­ired beha­vior of the sub­ject is spe­ci­fied by one or more use cases, which are defi­ned accor­ding to the needs of actors. […] Use cases, actors, and sys­tems are descri­bed using use case dia­grams.

9wytłuszczenia moje). Co my tu mamy:

  1. Przypadek uży­cia ozna­cza spe­cy­ficz­ne (kon­kret­ne) ocze­ki­wa­ne uży­cie sys­te­mu. Standardowo uży­wa­ny jest do zbie­ra­nia [J.Ż. doku­men­to­wa­nia] wyma­gań na sys­tem, pla­no­wa­ny do użycia. 
  2. Kluczowymi poję­cia­mi łączo­ny­mi z Przypadkiem uży­cia są aktor oraz przed­miot zain­te­re­so­wa­nia (sys­tem).
  3. Opisywanym z pomo­cą przy­pad­ków uży­cia przed­mio­tem jest sys­tem, któ­ry będzie wyko­rzy­sty­wa­ny zgod­nie z przy­pad­ka­mi uży­cia (w tym celu).
  4. Użytkownik lub inny sys­tem może oddzia­ły­wać na opi­sy­wa­ny przy­pad­ka­mi uży­cia przed­miot, nazy­wa­ny jest wte­dy akto­rem. Aktorem jest każ­dy zewnętrz­ny w sto­sun­ku do opi­sy­wa­ne­go sys­te­mu ele­ment (byt).
  5. Wymagane zacho­wa­nie opi­sy­wa­ne­go przed­mio­tu (sys­tem) może być opi­sa­ne jed­nym lub wie­lo­ma przy­pad­ka­mi uży­cia, defi­nio­wa­ny­mi jako potrze­by akto­ra (w sto­sun­ku do systemu).
  6. Przypadek uży­cia, aktor i sys­tem razem są okre­śla­ne jako dia­gram przy­pad­ków użycia. 

Jak widać, nie ma tu żad­nych kom­bi­na­cji, dowol­ny sys­tem, jego oto­cze­nie oraz inte­rak­cje tego oto­cze­nia z nim samym opi­su­je­my (mode­lu­je­my) z pomo­cą trzech pojęć pokry­wa­ją­cych wszyst­kie wyma­ga­ne ele­men­ty: kto/co, z czym i jakie ma interakcje.

Teraz pro­szę naj­pierw prze­czy­tać to:

schopenhauer_czworaki_korzen_zasady_racji_dostatecznej

Dwie waż­ne rze­czy: nie nale­ży bez potrze­by mno­żyć licz­by bytu­ją­cych istot” to zna­na bar­dziej jako brzy­twa Ockhama zasa­da: Nie nale­ży mno­żyć bytów ponad potrze­bę” (Brzytwa Ockhama nazy­wa­na tak­że zasa­dą eko­no­mii myśle­nia, zgod­nie z któ­rą w wyja­śnia­niu zja­wisk nale­ży dążyć do pro­sto­ty, wybie­ra­jąc takie wyja­śnie­nia, któ­re opie­ra­ją się na jak naj­mniej­szej licz­bie zało­żeń i pojęć. Tradycyjnie wią­za­na jest z nazwi­skiem Williama Ockhama). Druga: nie wol­no nie­po­trzeb­nie umniej­szać odmian bytu­ją­cych istot” . Razem są zwa­ne jako naj­wyż­sze pra­wa rozu­mu” (filo­zo­fa, badacza).

Powyższy wkle­jo­ny cytat pocho­dzi z roz­pra­wy Czworaki korzeń zasa­dy racji dosta­tecz­nej Schopenhauera. Cytuję go, gdyż gorą­co pole­cam filo­zo­fię ana­li­ty­kom (uczy logicz­ne­go myśle­nia i ana­li­zy), tę zaś zasa­dę pole­cam szcze­gól­nie, gdyż pozwa­la ona unik­nąć nie­po­trzeb­ne­go mno­że­nia bytów np. w posta­ci róż­nych rodza­jów przy­pad­ków uży­cia” (doty­czy to tak­że akto­rów). W jed­nej z prac inne­go filo­zo­fa (nie pamię­tam teraz któ­re­go), moż­na zna­leźć, że łama­nie powyż­szej zasa­dy (nada­wa­nie nowych nazw nowym postrze­ga­nym rze­czom) to wraz nie­zro­zu­mie­nia”: cze­go nie rozu­miem nadam mu nową nazwę”. To zła droga…

Zacytuje frag­ment moje­go refe­ra­tu z pew­nej konferencji:

…wszyst­ko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia, sno­oker – naj­trud­niej­sza gra w bilar­da – to tyl­ko kule i kij i pra­wa fizy­ki. Nawet naj­więk­szą orga­ni­za­cję moż­na, w toku ana­li­zy, roz­ło­żyć na skoń­czo­ną licz­bę ról i reguł ich postę­po­wa­nia by zro­zu­mieć jej funk­cjo­no­wa­nie. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji o sys­te­mach ERP).

Tak więc, tyl­ko trzy poję­cia: sys­tem, aktor i przy­pa­dek uży­cia zupeł­nie wystar­czą by opi­sać sys­tem i jego (przy­szłe, pla­no­wa­ne) wyko­rzy­sta­nie czy­li wyma­ga­nia. I zawsze powin­ny wystą­pić te trzy ele­men­ty na mode­lu. Mnożenie bytów na tym dia­gra­mie to raczej przy­zna­nie się do porażki…

Na koniec pole­cam tak­że Prezentacja (skrót) książ­ki Rebeki Wirfs-brock. Uwaga o pro­jek­to­wa­niu i przy­pad­kach użycia:

What?s Missing From Use Cases:

- Use cases are descrip­ti­ve, not pre­scrip­ti­ve [przy­pad­ki uży­cia są opi­so­we a nie nakazowe]

- There is a gap betwe­en the­se descrip­tions and a design [są wypeł­nie­niem luki pomię­dzy opi­sem a projektem]

___
Transcendentalny – będą­cy warun­kiem (moż­li­wo­ści) zaist­nie­nia cze­goś. W filo­zo­fii Kanta i jego kon­ty­nu­ato­rów doty­czą­cy aprio­rycz­nych form pozna­nia, teo­re­tycz­nie wykra­cza­ją­cych poza przed­miot i treść pozna­nia, a odno­szą­cy się do warun­ków pozna­nia peł­nej rze­czy­wi­sto­ści poznaw­czej tzn. praw­dy abso­lut­nej poj­mo­wa­nej uni­wer­sal­nie przez wszyst­kie pod­mio­ty poznaw­cze. Innymi sło­wy, taka for­ma pozna­nia ota­cza­ją­cej rze­czy­wi­sto­ści, by każ­dy bez wzglę­du na jego umiej­sco­wie­nie w niej, mógł stwier­dzić jed­no­znacz­ność poznaw­czą, czy­li praw­dę – uni­wer­sal­ną dla wszyst­kich istot poznaw­czych we wszechświecie.

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

  1. Łukasz

    There is a gap betwe­en the­se descrip­tions and a design” zna­czy: Istnieje luka pomię­dzy tymi opi­sa­mi (t.j. przy­pad­ka­mi uży­cia) a pro­jek­tem”, a nie „[przy­pad­ki uży­cia] są wypeł­nie­niem luki pomię­dzy opi­sem a pro­jek­tem”. A to zasad­ni­cza różnica :).

    1. Jarek Żeliński

      Coś w tym jest, od stro­ny języ­ko­wej mia­łem pro­blem z tym jak to prze­tłu­ma­czyć, bo fakt (kon­tekst) pole­ga na tym, że pomię­dzy opi­sem pro­zą” a pro­jek­tem (np. model dzie­dzi­ny) są wła­śnie przy­pad­ki uży­cia czy­li pierw­sza struk­tu­ra wypeł­nia­ją­ca lukę pomię­dzy nie­upo­rząd­ko­wa­nym opi­sem a pro­jek­tem obiek­to­wym. Chętnie podej­mę dys­ku­sję o tym, bo nie jest to moim zda­niem oczy­wi­ste (Twoje tłu­ma­cze­nie wprost jak naj­bar­dziej poprawne)…

    2. Łukasz

      To praw­da, że przy­pad­ki uży­cia są pierw­szą struk­tu­rą wypeł­nia­ją­cą lukę pomię­dzy nie­upo­rząd­ko­wa­nym opi­sem a pro­jek­tem obiek­to­wym. Jednakże poszcze­gól­ne przy­pad­ki uży­cia są pier­wot­nie spe­cy­fi­ko­wa­ne tak­że z uży­ciem pro­zy (co praw­da ustruk­tu­ry­zo­wa­nej, ale zawsze pro­zy). Z tej opi­so­wej natu­ry przy­pad­ków uży­cia wyni­ka powsta­nie luki pomię­dzy nimi a pro­jek­tem, któ­rą nale­ży wypeł­nić w pro­ce­sie ana­li­zy i pro­jek­to­wa­nia. Wydaje mi się, że wła­śnie tę oczy­wi­stość mia­ła na myśli Rebecca.
      ?Przypadki uży­cia to doku­men­ty pisa­ne czy­stym tek­stem, a nie dia­gra­my, zaś mode­lo­wa­nie z wyko­rzy­sta­niem przy­pad­ków uży­cia pole­ga na pisa­niu tek­stu, a nie ryso­wa­niu dia­gra­mów.? [Larman C., ?UML i wzor­ce pro­jek­to­we?, s. 94]

    3. Jarek Żeliński

      I mamy źró­dło pro­ble­mu”, ja domyśl­nie” potrak­to­wa­łem Przypadki uży­cia jako ele­men­ty dia­gra­mu UML…:). To tyl­ko upew­nia nas, że słow­nik pojęć i kon­tekst do pod­sta­wa jed­no­znacz­nej doku­men­ta­cji. Co do Rebeki W. to teraz nie jestem pewien o czym myśla­ła, ale z jej książ­ki wnio­sku­ję”, że cho­dzi­ło jej o UML … chy­ba…;). Możliwe też, że mia­ła na myśli popu­lar­ną wte­dy (pisa­ła to w roku 2000) kon­cep­cję przy­pad­ków uży­cia Cocbourna (któ­rej oso­bi­ście nie lubię bo wpro­wa­dza strasz­ny zamęt ;))

    4. Jarek Żeliński

      Co do Larmana, to w jego książ­ce podo­ba mi się tok pro­ce­su mode­lo­wa­nia dzie­dzi­ny, sekwen­cji itp.. poza jed­nak tym jak trak­tu­je przy­pad­ki uży­cia: po pierw­sze uzna­je je za część nie­for­mal­ną a po dru­gie uzna­je, że są dobre” w momen­cie powsta­nia i nie poka­zu­je jak spraw­dzić że są dobre”. Myślę, że raczej postrze­ga je jako user story”. 

      Ja zaś trak­tu­ję przy­pad­ki uży­cia jako pierw­szy for­ma­lizm (UML i jej seman­ty­ka) w pro­jek­cie (wyda­je mi się, że w książ­ce R.W. też tak to widzi) czy­li wła­śnie wypeł­nie­nie owej luki… ale to moja wersja 🙂

  2. Łukasz Pasek

    Przypadek uży­cia to przede wszyst­kim opis inte­rak­cji zacho­dzą­cych mię­dzy akto­rem a sys­te­mem i opis ten ma cha­rak­ter pro­zy. Często mylo­ne są poję­cia Use Case i Use Case Diagram. Use Case zawie­ra w sobie cel akto­ra, sce­na­riusz głów­ny i jego roz­sze­rze­nia czy­li samo sed­no tego do cze­go słu­ży: mode­lo­wa­nia danej funk­cjo­nal­no­ści w spo­sób któ­ry krok po kro­ku pro­wa­dzi do celu. Zastosowanie jedy­nie dia­gra­mów UML do two­rze­nia Use Case’ów bez pisa­nia fak­tycz­nych sce­na­riu­szy mija się z celem.
    Co do mno­że­nia use case­’ów to nale­ży zwró­cić uwa­gę na poziom szcze­gó­ło­wo­ści kro­ków use case­’a i sta­rać się two­rzyć tzw. Strategic Use Case’s. O tym moż­na poczy­tać w książ­ce «Writing Effective Use Cases» autor­stwa Alistair’a Cockburn’a. Zbyt duża licz­ba use casów świad­czy o koniecz­no­ści więk­sze­go uogólniania.

    1. Jaroslaw Zelinski

      Prawdą jest, że opi­sów tego czym jest Przypadek uży­cia jest wie­le, chy­ba naj­lep­sza” moim zda­niem jest pro­sta defi­ni­cja mówią­ca, że przy­pa­dek uży­cia to ini­cjo­wa­na przez akto­ra jego inte­rak­cja z sys­te­mem, któ­rej celem jest z góry okre­ślo­ny rezul­tat. To czy przy­pa­dek uży­cia będzie jajecz­kiem na dia­gra­mie UML czy tabel­ką w doku­men­ta­cji w zasa­dzie nie ma zna­cze­nia (ta tabel­ka to jakaś doku­men­ta­cja tego przy­pad­ku użycia).

      W moich oczach książ­ka Writing Effective Use Cases” autor­stwa Alistair?a Cockburn?a to naj­gor­sza książ­ka o przy­pad­kach uży­cia jaką czy­ta­łem (i nie jestem w tej opi­nii odosob­nio­ny), bo nie dość, że total­nie abs­tra­hu­je od UML mimo, że uży­wa poję­cia UML jakim jest Use Case, to autor dopro­wa­dził to narzę­dzie” do gra­nic absur­du usi­łu­jąc zastą­pić swo­imi meto­da­mi doku­men­to­wa­nia przy­pad­ków uży­cia wszyst­kie inne ele­men­ty pro­jek­tu takie jak opi­su dzie­dzi­ny czy regu­ły biz­ne­so­we. Nie zmie­nia to fak­tu, że ta książ­ka fak­tycz­nie świe­ci trium­fy wśród nie zna­ją­cych UML. 

      Wprowadzenie róż­nych pozio­mów UC (stra­te­gicz­ne itp…) to już poję­cio­wy kosmos nie do obro­ny bio­rąc pod uwa­gę, że przy­pa­dek uży­cia to nic inne­go jak usłu­ga sys­te­mu świad­czo­na akto­ro­wi, czy­li nie ma tu żad­nej hie­rar­chii (poza prio­ry­te­ta­mi) a jest linio­wa lista tego co moż­na od sys­te­mu dostać. Poziom szcze­gó­ło­wo­ści kro­ków to jedy­nie to, jak drob­no roz­pi­sze­my tę inte­rak­cję, co nie zmie­nia fak­tu, że i tak spro­wa­dza się to do dia­lo­gu: aktor naci­snął, sys­tem zwró­cił (tabel­ka lub dia­gram sekwen­cji). Kwestia pro­jek­tan­ta jest to, że imple­men­ta­cja for­mu­la­rza to dia­log pole po polu (bar­dzo pra­co­chłon­ne) czy tyl­ko wypeł­nij for­mu­larz i naci­śnij OK” (bar­dzo wygod­ne i mało pracochłonne).

      I to co jest w tym wszyst­kie­go naj­gor­sze, to pró­by mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z pomo­cą przy­pad­ków uży­cia. Np. nazwa­nie przy­pad­kiem uży­cia np. Przyjęcia zamó­wie­nia czy Stworzenie oprogramowania. 

  3. Łukasz Pasek

    Panie Jarosławie,
    nie do koń­ca się z panem zga­dzam. Wg Cockburn’a szkie­let spe­cy­fi­ka­cji wyma­gań powi­nien być opar­ty na Use Case’ach. Jednak on sam twier­dzi, że Use Case’y to tyl­ko frag­ment spe­cy­fi­ka­cji, model dzie­dzi­ny i regu­ły biz­ne­so­we to prze­cież jej osob­na część. 

    Większość czy­tel­ni­ków tej książ­ki uwa­ża ją za przy­dat­ną co moż­na zoba­czyć w recen­zjach na ama­zo­nie: http://​www​.ama​zon​.com/​W​r​i​t​i​n​g​-​E​f​f​e​c​t​i​v​e​-​C​a​s​e​s​-​A​l​i​s​t​a​i​r​-​C​o​c​k​b​u​r​n​/​p​r​o​d​u​c​t​-​r​e​v​i​e​w​s​/​0​2​0​1​7​0​2​2​5​8​/​r​e​f​=​c​m​_​c​r​_​p​r​_​h​i​s​t​_​5​?​i​e​=​U​T​F​8​&​f​i​l​t​e​r​B​y​=​a​d​d​F​i​v​e​S​t​a​r​&​s​h​o​w​V​i​e​w​p​o​i​n​t​s​=​0​&​s​o​r​t​B​y​=​b​y​S​u​b​m​i​s​s​i​o​n​D​a​t​e​D​e​s​c​e​n​d​ing

    Jest też ona cyto­wa­na przez innych auto­rów np. Karl Wiegers, Larry Constantine. Jednak przede wszyst­kim, use case­’y pisa­ne pro­zą są bar­dzo dobrym narzę­dziem do mode­lo­wa­nia funk­cjo­nal­no­ści sys­te­mu. Istnieją co praw­da lep­sze meto­dy np. Task & Support. Alistair Cockburn daje w swo­jej książ­ce wie­le przy­kła­dów i dobrych rad, któ­re w prak­ty­ce są przy­dat­ne. Przykładowo to chy­ba on wpro­wa­dził do use case­’ów poję­cie defi­nio­wa­nia celu i radzi by każ­dy krok use case­’a przy­bli­żał nas do celu. Dodatkowo radzi on w tej książ­ce jak dbać o cele inte­re­sa­riu­szy, któ­rzy nie są wprost akto­rai w danym przy­pad­ku użycia. 

    Pojęcie pozio­mów szcze­gó­ło­wo­ści i two­rze­nie stra­te­gicz­nych use case­’ów jest trud­ne i w prak­ty­ce znaj­du­je zasto­so­wa­nie w bar­dzo dużych pro­jek­tach. Ja oso­bi­ście zasto­so­wa­łem to w jed­nym nie­zbyt dużym pro­jek­cie po to, by pomóc czy­tel­ni­kom lepiej zro­zu­mieć zakres pro­jek­tu. Natomiast oso­bi­ście uwa­żąm, że do pozio­mów szcze­gó­ło­wo­ści znacz­nie epiej nada­je się mode­lo­wa­nie za pomo­cą dia­gra­mów Warniera.

    Z powa­ża­niem,
    Łukasz Pasek

    1. Jaroslaw Zelinski

      Doskonale wiem, że ta książ­ka jest powszech­nie lubia­na i cyto­wa­na”. Doskonale też wiem, że jest uwiel­bia­na za to, że wystar­czą nie­we­ry­fi­ko­wal­ne tabel­ki) (UML dla wie­lu jest trud­ny, podob­nie zresz­tą jak cały obiek­to­wy para­dyg­mat)… Przypadki uży­cia (mówię o czymś co defi­niu­je się jako usłu­ga sys­te­mu dla akto­ra”) to pro­sta i pła­ska struk­tu­ra. Komplikowanie jej np. w pozio­my nie ma żad­ne­go uza­sad­nie­nia i odzwier­cie­dle­nia w kodzie, zaś pró­by opi­sa­nia w ten spo­sób zło­żo­ne­go biz­ne­su” to na dzi­siaj (i to nie tyl­ko moja opi­nia) nie­udol­ne pró­by sto­so­wa­nia metod z pierw­szej poło­wy lat 90-tych (sta­ry RUP: biz­ne­so­we przy­pad­ki uży­cia, ich dzie­dzi­cze­nie itp.), gdy nie zna­no jesz­cze np. metod mode­lo­wa­nia pro­ce­sów (BPMN). Proszę tego nie trak­to­wać jako ata­ko­wa­nie” Pana opi­nii a jako porów­na­nie ze sta­nem dzi­siej­szym wie­dzy :). Cocbourn i jego przy­pad­ki uży­cia nie mają nic wspól­ne­go z UML, co zresz­tą on sam przy­zna­je i momen­ta­mi nawet drwi z ludzi­ków i jaje­czek”, któ­rych on sam, moim zda­niem, po pro­tu nie rozumie.

      Przy oka­zji gru­po­wa­nia, jeże­li już gru­po­wać przy­pad­ki uży­cia to raczej tema­tycz­nie” na kom­po­nen­ty czy modu­ły, i robi się to z pomo­cą pakie­tów UML.

  4. Łukasz Pasek

    Krytyka jaką Cockburn pro­wa­dzi wobec UMLa pole­ga na wła­ści­wym zro­zu­mie­niu następstw tego co zacy­to­wał Pan wcześniej:
    Use cases, actors and sys­tems are descri­bed using use case diagrams».
    Cockburn ma rację twier­dząc, że dia­gram przy­pad­ków uży­cia to tyl­ko spis tre­ści, pod­czas gdy isto­ta mode­lo­wa­nia inte­rak­cji w jakie czło­wiek wcho­dzi z sys­te­mem może być opi­sa­na wła­śnie krokami.
    Zbierając wyma­ga­nia klien­ta i decy­du­jąc co ma robić sys­tem, a co użyt­kow­nik potrze­bu­je­my napi­sać kro­ki use case’a.
    Celem ana­li­zy biz­ne­so­wej jak i pro­jek­to­wa­nia uży­tecz­no­ści jest by użyt­kow­nik (aktor, rola) osią­gał swój cel w spo­sób zgod­ny ze swo­imi inten­cja­mi i ocze­ki­wa­nia­mi. Właśnie o to cho­dzi Cockburnowi i dla­te­go tak wie­le osób doce­nia tę książ­kę. Proszę nie mylić Analizy Systemowej, któ­rą się Pan zaj­mu­je z okre­śla­niem wyma­gań, któ­ra jest przed­mio­tem Analizy Biznesowej. Obiektowość czy UML to świat imple­men­ta­cji a nie biz­ne­su. Nie roz­ma­wia­my z klien­tem o para­dyg­ma­cie obiek­to­wym ale raczej o zada­niach i pra­cy jaką będzie wyko­ny­wał przy uży­ciu oprogramowania.
    Sama wery­fi­ka­cja kro­ków przy­pad­ków uży­cia, zamo­de­lo­wa­nych przez ana­li­ty­ka biz­ne­so­we­go i zaak­cep­to­wa­nych z inte­re­sa­riu­sza­mi pole­ga na czymś innym niż two­rze­nie struk­tu­ry implementacji.
    Stare nie zawsze zna­czy gor­sze. Pośród sta­ro­ci moż­na cza­sem zna­leźć wyso­ce uży­tecz­ne narzę­dzia praz spo­so­by na roz­wią­zy­wa­nie pro­ble­mów. Czy do mode­lo­wa­nia logi­ki jest coś lep­sze­go niż dia­gra­my Warniera – lata 60-te i 70-te? Czy do zapew­nie­nia jako­ści danych jest coś lep­sze­go niż Output-Oriented Systems Design – spo­sób porzu­co­ny w latach 80-tych?
    Same Use Case’y tak jak opi­sa­ne wg Cockburn’a mają jed­nak jeden dość poważ­ny minus. Zbyt wcze­śnie nast epu­je decy­do­wa­nie o tym co robi użyt­kow­nik a co sys­tem. Ale to temat na osob­ną dyskusję.
    Nie chciał­bym się z Panem spie­rać i sza­nu­ję Pana poglą­dy i sze­ro­ką wie­dzę. Jednak pro­szę zauwa­żyć, że Cockburn wyraź­nie pra­gnie odciąć się od imple­men­ta­cji w swo­ich pró­bach mode­lo­wa­nia funk­cjo­nal­no­ści. Nieszczęście, Pana, moje i wie­lu ludzi pole­ga na nazy­wa­niu róż­nych rze­czy tą samą nazwą. Ludzie mylą use case­’y z use case dia­gra­ma­mi. Use case­’y rze­czy­wi­ście pocho­dzą z cza­sów sprzed powsta­nia obiek­to­wo­ści i jak pisze Larry Constantine były tema­tem tabu, w świe­cie obiek­to­wo­ści, aż do cza­su, gdy Ivar Iacobson wpro­wa­dził je do UMLa.

    1. Jaroslaw Zelinski

      Celem dia­gra­mu Use Case (UML) nigdy nie było mode­lo­wa­nie żad­nych inte­rak­cji (od tego jest dia­gram inte­rak­cji), dia­gram Use Case to tyl­ko (i aż) kon­tekst i zakres pro­jek­tu, jego ogrom­ną zale­tą jest, zarzą­dza­nie zakre­sem pro­jek­tu, inte­re­sa­riu­sza­mi. Nieoceniona role peł­ni w narzę­dziach CASE jako korzeń pro­jek­tu (mode­li). Nie jestem ana­li­ty­kiem sys­te­mo­wym” w rozu­mie­niu tyl­ko kla­sy na dia­gra­mach” i tu nie­ste­ty nie mogę się zgo­dzić, że obiek­to­wość” to tyl­ko świat UML i imple­men­ta­cji. Organizacje, do celów ana­li­zy, mode­lu­je się jako zespół obiek­tów, jako pro­ce­sy biz­ne­so­we czy jako struk­tu­ry orga­ni­za­cyj­ne, to zale­ży od celu ana­li­zy. Dobry model obiek­to­wy orga­ni­za­cji (lub jej czę­ści) jest potem dosko­na­łym mode­lem dzie­dzi­ny (wzor­ce DDD). Co do wady Zbyt wcze­śnie nastę­pu­je decy­do­wa­nie o tym co robi użyt­kow­nik a co sys­tem.” to fakt, dru­gą jest przed­wcze­sne suge­ro­wa­nie archi­tek­tu­ry w tabel­kach, co nie­sie nie raz złe kon­se­kwen­cje w posta­ci złe­go mode­lu dzie­dzi­ny. Co do myle­nia to praw­da, przy­pad­ki uży­cia” mają nie­ste­ty wie­le róż­nych potocz­nych zna­czeń, a tak na praw­dę są to usłu­gi apli­ka­cji”, jeże­li uży­wać peł­nej nazwy np. Diagram przy­pad­ków uży­cia, Scenariusz przy­pad­ku uży­cia, Interakacja aktor-sys­tem dla przy­pad­ku uży­cia itp. pomy­łek było znacz­nie mniej 😉

  5. Jaroslaw Zelinski

    Przy oka­zji dia­gra­mów Warniera i następ­nych: w obiek­to­wym podej­ście dia­gra­my Warniera nie mają racji bytu, one i nie tyl­ko to pró­by radze­nia sobie ze zło­żo­no­ścią gene­ro­wa­ną lawi­no­wo przez logi­kę dekom­po­no­wa­na algo­ryt­micz­nie, świet­nie opi­sa­no to w Object-Oriented Analysis and Design with Applications (3rd Edition), Grady Booch (Author), Robert A. Maksimchuk (Author), Michael W. Engle (Author), Bobbi J. Young (Author), Jim Conallen (Author), Kelli A. Houston (Author). OOAD popraw­nie sto­so­wa­ne dosko­na­le sobie radzi ze zło­żo­no­ścią dużych sys­te­mów (dla­te­go wygry­wa z meto­da­mi struk­tu­ral­ny­mi i baza­mi relacyjnymi).

Dodaj komentarz

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