Nie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy

Pojęcie akto­ra, inte­gra­cji, inter­fej­sów itp. sta­le się prze­wi­ja w doku­men­tach wyma­gań, nie­jed­no­krot­nie w spo­sób błęd­ny co wpro­wa­dza zamęt w doku­men­ta­cji i zamęt w zro­zu­mie­niu pro­ble­mu do rozwiązania.

Co znaj­dzie­my w doku­men­ta­cji UML (UML 2.4.1. Superstructure 2011-08-05, rozdz. 16):

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.

Ogólnie: Przypadek Użycia ozna­cza kon­kret­ne (w okre­ślo­nym celu) uży­cie Systemu. Standardowo Przypadków Użycia uży­wa się do opi­sa­nia wyma­gań wobec przy­szłe­go Systemu. Kluczowe poję­cia sko­ja­rzo­ne z Przypadkami Użycia to Aktor i przed­miot opi­su czy­li System. Użytkownik lub inny sys­tem może wcho­dzić w inte­rak­cje z Systemem jako Aktor. Aktor to zawsze byt zewnętrz­ny wzglę­dem Systemu (ale nie każ­dy nam zna­ny). Wymagane zacho­wa­nia (reak­cje) Systemu są spe­cy­fi­ko­wa­ne z pomo­cą jed­ne­go lub wie­lu przy­pad­ków uży­cia repre­zen­tu­ją­cych potrze­by Aktorów.

Aktorem jest więc zewnętrz­ny byt, któ­ry ma potrze­bę uży­cia Systemu w kon­kret­nym celu. Innymi sło­wy: Przypadek Użycia opi­su­je usłu­gą świad­czo­ną przez System dla jego Otoczenia. Użytkownicy tych usług to Aktorzy. Tak więc gene­ral­nie Przypadki Użycia to usłu­gi Systemu jakie świad­czy i są one ini­cjo­wa­ne przez jego Aktorów czy­li żąda­ją­cych obsłu­gi. Kluczowe tu jest stwier­dze­nie: Aktor to ten, któ­ry ini­cju­je dia­log z Systemem żąda­jąc obsługi.

Aby poka­zać gdzie są pro­ble­my poka­że to dokład­nie od koń­ca. Jak ktoś nie jest ana­li­ty­kiem może od razu przejść na koniec :).

Integracja czy­li kom­po­nen­ty i podsystemy 

Powyżej mamy dość typo­wą sytu­ację, w któ­rej mamy System pro­jek­to­wa­ny, inny Zewnętrzny System 1, któ­ry już u nas funk­cjo­nu­je. Z sys­te­mu pro­jek­to­wa­ne­go będzie korzy­stał Użytkownik oraz kolej­ny inny Zewnętrzny System 2. Zewnętrzny ozna­cza tu już ist­nie­ją­cy” (zewnętrz­ny wzglę­dem projektowanego).

Na dia­gra­mie (UML, dia­gram kom­po­nen­tów) uży­to sym­bo­li kom­po­nent i inter­fejs. Warto wie­dzieć, że inter­fej­sy mają dwa obli­cza”. Co do zasa­dy w UML (i meto­dach obiek­to­wych) wystę­pu­je poję­cie uży­cia” to zna­czy, że coś żąda reali­za­cji usłu­gi od cze­goś” albo jak kto woli coś uży­wa cze­goś do reali­za­cji swo­ich zadań”. Dlatego inter­fej­sy dzie­li­my na ofe­ro­wa­ne i wyma­ga­ne. Użytkownik uży­wa Systemu (jest on dla nie­go narzę­dziem pra­cy) do reali­za­cji swo­ich celów. Może to tak­że robić (żądać obsłu­gi) inny System.

Dwa typy interfejsów

Interfejs ofe­ro­wa­ny i wyma­ga­ny to dwa róż­ne byty”. Ogólnie, jeże­li jeden sys­tem wysy­ła żąda­nie wyko­na­nia jakiejś usłu­gi do dru­gie­go, to pierw­szy ma inter­fejs wyma­ga­ny a dru­gi ofe­ro­wa­ny (i muszą być zgod­ne ;)). Zestaw pole­ceń rozu­mia­nych” przez inter­fejs ofe­ro­wa­ny to język”, któ­ry musi znać inter­fejs wyma­ga­ny (sys­tem wywo­łu­ją­cy). W prak­ty­ce wyglą­da to tak, że inter­fejs ofe­ro­wa­ny ma doku­men­ta­cję, któ­rą powi­nien dostać pro­gra­mi­sta inter­fej­su wyma­ga­ne­go (wywo­łu­ją­ce­go zdal­ny System).

Tak więc mamy już świa­do­mość ról uży­wa­ją­cy i uży­wa­ny (w UML poka­zu­je to zwią­zek uży­cia: strzał­ka z linii kre­sko­wej z gro­tem wska­zu­ją­cym na system/obiekt wywo­ły­wa­ny, świad­czą­cy usłu­gę, patrz pierw­szy diagram).

Od środ­ka

Popatrzmy na stwo­rzo­ny sys­tem”. System już po napi­sa­niu” mógł by wyglą­dać tak (uży­to [[wzor­ców pro­jek­to­wych, w tym wzor­ca MVC]]):

Co tu mamy? Użytkownik to oso­ba korzy­sta­ją­ca z Systemu Projektowanego. Każdy przy­pa­dek uży­cia ma swo­ją dedy­ko­wa­ną kla­sę, któ­ra wie jak świad­czyć daną usłu­gę”. Model dzie­dzi­ny odwzo­ro­wu­je prze­twa­rza­ne dane (Jakaś kla­sa, agre­ga­ty itp.), są kla­sy świad­czą­ce jakieś wewnętrz­ne usłu­gi. W trak­cie ana­li­zy i pro­jek­to­wa­nia może się oka­zać, że jakaś potrzeb­na wewnątrz Systemu Projektowanego usłu­ga jest już dostęp­na w sie­ci Zamawiającego, zna­my Zewnętrzny System 1, któ­ry ją ma, spraw­dza­my czy System ten ma inter­fejs do tej usłu­gi lub czy moż­na go napi­sać. (np. mamy już sys­tem kadro­wo-pla­co­wy więc nie musi­my po raz dru­gi imple­men­to­wać listy pra­cow­ni­ków, może­my o dane pra­cow­ni­ka pro­sić ten ist­nie­ją­cy już zewnętrz­ny system).

W ramach pro­jek­tu więc nie imple­men­tu­je­my dru­gi raz takiej usług (nie dublu­je­my jej w naszej sie­ci) tyl­ko two­rzy­my inter­fejs, kla­sę któ­ra będzie wywo­ły­wa­ła Zewnętrzny System 1, za każ­dym razem gdy usłu­ga ta będzie wyma­ga­na. Nie pozwa­la­my na bez­po­śred­nie wywo­ła­nia z wnę­trza nasze­go Systemu Projektowanego, bo to uza­leż­ni całe jego wnę­trze od szcze­gó­łów obce­go Systemu. Tworzymy adap­ter” czy­li masku­je­my” obcy sys­tem (Klasa «Interfejs» to ten adap­ter). Dzięki temu jego, Zewnętrznego Systemu 1, ewen­tu­al­na wymia­na nie zaowo­cu­je prze­rób­ka­mi nasze­go Systemu Projektowanego. Gdyby trze­ba było zre­zy­gno­wać z Zewnętrznego Systemu 1, kla­sę adap­te­ra wypeł­ni­my imple­men­ta­cją potrzeb­nych funk­cji a resz­ta Systemu Projektowanego nie odczu­je zmiany.

Mamy więc już pro­jekt. A teraz wra­ca­my do począt­ku i narysujemy

Diagram przy­pad­ków użycia

któ­ry obra­zu­je powyż­szy projekt:

To jest to co zro­zu­mie Klient, naj­prost­szy dia­gram do poka­za­nia, zawie­ra zakres pro­jek­tu, gra­ni­ce sys­te­mu (naj­waż­niej­sza rzecz) i akto­rów (część różo­wa tyl­ko dla lep­sze­go zro­zu­mie­nia tre­ści arty­ku­łu). Inny System, jeże­li ini­cju­je akcję czy­li żąda usłu­gi tak­że jest akto­rem, ale System reali­zu­ją­cy na nasze zle­ce­nie jakieś usłu­gi nie jest akto­rem, jest tyl­ko wywo­ły­wa­ny, sam z sie­bie nie ini­cju­je żad­nej akcji. On reali­zu­je jakąś potrzeb­ną nam funkcję.

Może się oka­zać, że Zewnętrzny sys­tem ma zarów­no inter­fejs ofe­ro­wa­ny jak i wyma­ga­ny, wte­dy w pro­jek­cie, na dia­gra­mie przy­pad­ków uży­cia, war­to ope­ro­wać nie nazwą zewnętrz­ne­go sys­te­mu (np. ERP któ­ry może mieć dzie­siąt­ki inter­fej­sów ofe­ro­wa­nych i wyma­ga­nych) a nazwą usłu­gi (inter­fejs ofe­ro­wa­ny) lub zda­rze­nia (inter­fejs wyma­ga­ny) będą­cych przed­mio­tem takich akcji i zakre­su projektu.

Diagram przy­pad­ków uży­cia to pierw­szy test zro­zu­mie­nia tego co i po co ma powstać. Jest to bar­dzo pro­sty dia­gram i dla­te­go każ­de uprosz­cze­nie lub nie­zro­zu­mie­nie, pro­wa­dzi nie raz do poważ­nych nie­po­ro­zu­mień a bywa, że do kra­chu pro­jek­tu. To bar­dzo waż­ny dia­gram. Powie nam do cze­go Systemy Projektowany będzie uży­wa­ny, to cel spon­so­ra. Na tej pod­sta­wie moż­na wybrać goto­we opro­gra­mo­wa­nie i testu­jąc je oce­nić przy­dat­ność (nie radze wybie­rać goto­we­go opro­gra­mo­wa­nia na bazie pre­zen­ta­cji!). Ale dia­gram ten nigdy nie powie jaką logi­kę nale­ży zaim­ple­men­to­wać, dla­te­go w przy­pad­ku two­rze­nia opro­gra­mo­wa­nia koniecz­ny jest jego pro­jekt: model dzie­dzi­ny sys­te­mu, jako kolej­ny etap pro­jek­tu na opro­gra­mo­wa­nie dedy­ko­wa­ne. Przypomnę tak­że, że przy­pad­ki uży­cia w wer­sji mini­mal­nej powin­ny mieć opis:

  • cel jego uży­cia (co Aktor chce osiągnąć)
  • stan począt­ko­wy (wej­ście, dane wej­ścio­we, itp.)
  • stan koń­co­wy (wyj­ście, dane wyj­ścio­we itp.)

Tu zwra­cam uwa­gę, że powyż­sze to zara­zem testy akcep­ta­cyj­ne otrzy­ma­ne­go oprogramowania.

Inne artykuły na podobny temat

Komentarze

  1. Mateusz Kurleto 10 października 2012 at 11:34

    System 1 rów­nie dobrze może być akto­rem, któ­re­go na dia­gra­mie przy­pad­ków uży­cia połą­czy­my z PU rela­cją zależ­no­ści – tzn wska­że­my, że spo­sób reali­za­cji przy­pad­ku uży­cia zale­ży od inne­go systemu.
    Mam też wąt­pli­wość odno­śnie umiej­sco­wie­nia kla­sy inter­fej­su do systemu_1 w war­stwie mode­lu. To chy­ba tro­chę pro­te­za. Moim zda­niem inter­fejs to winien w swo­jej war­stwie wido­ku udo­stęp­niać System 1, my zaś z pozio­mu mode­lu w kla­sach reali­zu­ją­cych funk­cjo­nal­no­ści wyma­ga­ją­ce współ­pra­cy z sys­te­mem 1 powin­ni­śmy za pomo­cą kon­tro­le­ra wywo­ły­wać odpo­wied­nie kla­sy inter­fej­su sys­te­mu 1. Jak znaj­dę chwi­lę, to uzu­peł­nię niniej­szy komen­tarz o sto­sow­ne diagramy.

    • Jarek Żeliński 10 października 2012 at 22:10

      Pokazanie na dia­gra­mie Systemu 1 widać na ostat­nim dia­gra­mie (moż­na tak nary­so­wać, rzad­ko się to jed­nak robi), jed­nak on nie ini­cju­je akcji (nie żąda obsłu­gi) więc seman­tycz­nie nie jest akto­rem, jest zewnętrz­ną imple­men­ta­cją wewnętrz­nej wyma­ga­nej usłu­gi. Prostym testem jest fakt napi­sa­nia wła­snej imple­men­ta­cji tego inter­fej­su, dia­gram przy­pad­ków uży­cia nie powi­nien ulec zmia­nie bo zakres funk­cjo­nal­ny sys­te­mu nie uległ zmianie. 

      Diagramy te powsta­ły na bazie pro­ste­go zało­że­nia: usłu­gi to inter­fejs a jego imple­men­ta­cja leży” w naszym” sys­te­mie lub jest na zewnątrz”. Czyli jeże­li System pro­jek­to­wa­ny w swo­im wnę­trzu wyma­ga wie­dzy o pra­cow­ni­kach to budu­ję kla­sę z taka usłu­gą jako ele­ment dome­ny. Rzeczą wtór­ną jest to, czy ta kla­sa ma imple­men­ta­cję reje­stru pra­cow­ni­ków lokal­nie czy jest jedy­nie adap­te­rem do zewnętrz­nej apli­ka­cji (potocz­nie inter­fejs do inne­go pro­gra­mu) dostęp do danych pra­cow­ni­ka zawsze jest ele­men­tem dzie­dzi­ny tego sys­te­mu (na tym pole­ga tu her­me­ty­za­cja imple­men­ta­cji reje­stru pra­cow­ni­ków). Reszta Systemu nie ma o tym poję­cia” a decy­zję o uży­ciu COTS podej­mu­je­my (może­my pod­jąć) póź­niej. To jest moim zda­niem pięk­ne” w meto­dach obiek­to­wych, że moż­na opra­co­wać pro­jekt logi­ki sys­te­mu nawet w 100% na pozio­mie inter­fej­sów czy­li opra­co­wać pro­jekt abs­trak­cyj­ny, a potem mar­twić się o imple­men­ta­cję czy­li szu­kać gotow­ców na ryn­ku zanim podej­mie­my decy­zje o samo­dziel­nym kodowaniu.

  2. Sławomir Niemiec 10 października 2012 at 13:50

    Zastanawiam się czy moż­na wyko­rzy­stać wzo­rzec MVC do mode­lo­wa­nia sys­te­mów opar­tych na para­dyg­ma­cie SOA? Jak wyglą­dał­by wów­czas jakiś pro­sty przy­pa­dek uży­cia np. sys­te­mu słu­żą­ce­go do webo­we­go podej­mo­wa­nia decy­zji w opar­ciu o gło­so­wa­nie (przy­kła­do­we usłu­gi: reje­stra­cja gło­su­ją­ce­go, zgła­sza­nie tema­tów, spraw­dze­nie popraw­no­ści odda­wa­nia gło­sów itp.)

    • Jarek Żeliński 10 października 2012 at 21:44

      Model przy­pad­ków uży­cia zawie­ra pro­sto­kąt” System (w UML jest to sub­ject” czy­li przed­miot mode­lo­wa­ny) i na tym pozio­mie jest to czar­na skrzyn­ka. Projektowanie sys­te­mów i ich inte­gra­cji, zaczy­na­jąc je od Przypadków Użycia i ich Aktorów w szcze­gól­no­ści, wyma­ga wła­śnie zro­zu­mie­nia roli każ­de­go inte­gro­wa­ne­go” pod­sys­te­mu. Należy roze­brać” je na usłu­gi świad­czo­ne i żąda­ne. Szyna ESB jest jedy­nie imple­men­ta­cją narzę­dzia do prze­sy­ła­nia żądań. 

      Co do MVC zaś, to jest to już wnę­trze” naszej czar­nej skrzyn­ki i nie ma tu zna­cze­nia co jest inte­gro­wa­ne, ESB to sys­te­my wymia­ny komu­ni­ka­tów i nic wię­cej. MVC w sytu­acji gdy akto­ra­mi są inne sys­te­mu to głów­nie Model (kano­nicz­ny model danych cało­ści) oraz Controller czy­li obsłu­ga interfejsów.

  3. Robert Nowakowski 11 października 2012 at 11:42

    Moim zda­niem, zgod­nie ze spe­cy­fi­ka­cją UML, System 1 może być aktorem(nieinicjującym, a wspie­ra­ją­cym reali­za­cje przy­pad­ku użycia). 

    Zgodnie z doku­men­ta­cją UML 2.4.1 (stro­na 622):
    Each use case spe­ci­fies some beha­vior, possi­bly inc­lu­ding variants, that the sub­ject can per­form in col­la­bo­ra­tion with one or more actors.”
    These beha­viors, invo­lving inte­rac­tions betwe­en the actor and the sub­ject, may result in chan­ges to the sta­te of the sub­ject and com­mu­ni­ca­tions with its environment.

    Przykład: model PU dla ban­ko­ma­tu z tej doku­men­ta­cji przed­sta­wia bank jako wła­śnie takie­go aktora.

    To tak, w nawią­za­niu do spe­cy­fi­ka­cji UML. Nie, negu­je pro­po­no­wa­ne­go tu spo­so­bu opi­su inter­fej­sów, wyda­je się dość przekonywujące.

    • Jarek Żeliński 11 października 2012 at 13:28

      Bank jest akto­rem ban­ko­ma­tu bo ini­cju­je nie tyl­ko wkła­da­nie kasy ale i rapor­ty itp… Po dru­gie zmia­na sta­nu w Systemie nie wyda­rzy się sama z sie­bie, System reagu­je na bodź­ce a bodź­ce gene­ru­je Aktor, nie wprost ale z tego tak­że opi­su moż­na wypro­wa­dzić wnio­sek, że Aktor to coś” co ini­cju­je zacho­wa­nia Systemu. 

      Pojęcie Aktor sup­por­tu­ją­cy” jest poza UML, bez­piecz­niej jest użyć poję­cia imple­men­ta­cja zewnętrz­na” jakiejś wyma­ga­nej funk­cji. Po dru­gie jak napi­sać sce­na­riusz dla przy­pad­ku uży­cia ini­cjo­wa­ne­go przez two­rzo­ny System? System świad­czy usłu­gi na żąda­nie z oto­cze­nia… sam z sie­bie nic nie zro­bi. Analogicznie (jest to kon­se­kwen­cja) do inter­fej­su ofe­ro­wa­ne­go i wyma­ga­ne­go, aktor korzy­sta wyłącz­nie z oferowanego. 

      W moich oczach restryk­cyj­ne podej­ście do defi­ni­cji Aktora pozwa­la unik­nąć nie­po­ro­zu­mień mię­dzy inny­mi na pozio­mie inter­fej­sów. Bardzo poma­ga pil­no­wa­nie zakre­su pro­jek­tu, pro­sto­kąt” System to gra­ni­ce zakre­su, w kon­se­kwen­cji Aktor jest zawsze poza zakre­sem a wyko­naw­ca ma pra­wo żądać doku­men­ta­cji Aktora: raz jest to opis co potra­fi użyt­kow­nik (w swo­ich pro­jek­tach wymu­szam spe­cy­fi­ko­wa­nie tego jaka wie­dzą i umie­jęt­no­ścia­mi dys­po­nu­je Aktor-Użytkownik) innym razem spe­cy­fi­ka­cja API inne­go inte­gro­wa­ne­go Systemu. Wykonawca Systemu, Aktorów dosta­je na tacy” oraz defi­niu­je lub imple­men­tu­je inter­fej­sy do innych sys­te­mów zależ­nie od tego czy są wyma­ga­ne czy ofe­ro­wa­ne. To poma­ga pano­wać na tym kto i co dostarcza.

  4. Robert Nowakowski 11 października 2012 at 15:42

    Wracają do przy­pad­ku uży­cia opi­su­ją­ce­go wypła­tę gotów­ki z ban­ko­ma­tu. Aktorem ini­cju­ją­cym jest tu klient. Aktorem sup­por­tu­ją­cym” jest sys­tem ban­ko­wy, wspie­ra­ją­cy reali­za­cję przy­pad­ku uży­cia, np: wery­fi­ka­cje wpro­wa­dzo­ne­go kodu PIN.
    W związ­ku z tym na dia­gra­mie przy­pa­dek uży­cia powią­za­ny będzie rela­cją z klien­tem (aktor ini­cju­ją­cy) i sys­tem ban­ko­wym (aktor sup­por­tu­ją­cy”).
    Szczegóły komu­ni­ka­cji zwią­za­nej z wery­fi­ka­cją kodu PIN są uję­te w tre­ści przy­pad­ku uży­cia. Ten sam sys­tem ban­ko­wy może w innej sytu­acji peł­nić rolę akto­ra ini­cju­ją­ce­go np: pobie­ra­nie rapor­tów z bankomatu.

    Wydaje się że, aktor sup­por­tu­ją­cy” czę­sto poja­wia się w lite­ra­tu­rze zwią­za­nej z przy­pad­ka­mi uży­cia, więc może z auto­ma­tu” przy­ją­łem, że UML wspie­ra poję­cie akto­ra sup­por­tu­ją­ce­go”.
    Cytując frag­ment spe­cy­fi­ka­cji UML zało­ży­łem, że ta komu­ni­ka­cja z oto­cze­niem powin­na być przed­sta­wio­na za pomo­cą akto­ra sup­por­tu­ją­ce­go”.

    Dodam jesz­cze że, nie jestem zwo­len­ni­kiem ini­cjo­wa­nia przy­pad­ków uży­cia wewnątrz sys­te­mu, przez zda­rze­nia cza­so­we itp.

    Rozumiem że, w pro­po­no­wa­nym podej­ściu na dia­gra­mach nie poja­wia­ją się akto­rzy sup­por­tu­ją­cy”, a usłu­gi zewnętrz­ne są doku­men­to­wa­na za pomo­cą inter­fej­sów wyma­ga­ne­go i oferowanego.

    • Jarek Żeliński 11 października 2012 at 21:02

      Bankomat nie jest samo­wy­star­czal­ny więc nie ist­nie­je System Bankomat tyl­ko moduł sys­te­mu ban­ko­we­go słu­żą­cy do wypła­ca­nia gotów­ki z wła­sne­go kon­ta zarzą­dza­ne­go Systemem Bankowym. Tu jed­nak zazna­czam, ze posłu­gu­je się zasa­da­mi” ogól­nej teo­rii sys­te­mów, któ­ra rygo­ry­stycz­nie trak­tu­je poję­cie sys­te­mu i jego gra­nic. Z dru­giej stro­ny Bankomat uzna­ny jako System” (pod­sys­tem więk­szej cało­ści) ma w sobie inter­fejs wyma­ga­ny do Systemu Bankowego imple­men­tu­ją­ce­go wie­dzę o moim sta­nie rachun­ku” potrzeb­nej do spraw­dze­nia ile wol­no mi wypła­cić (gra­ni­ce sys­te­mu są względne:każdy sys­tem może być pod­sys­te­mem sys­te­mu nad­rzęd­ne­go i odwrotnie) . 

      Niewątpliwie jest to kwe­stia przy­ję­tej kon­wen­cji, ja przyj­mu­je tę nauko­wą” (meto­da nauko­wa) a w ramach pra­cy nauko­wej porząd­ku­ję” ogól­ni­ki, tu w UML (ta nota­cja, jak każ­da inna, do wyko­na­nia kon­kret­ne­go mode­lu wyma­ga stwo­rze­nia prag­ma­ty­ki, cza­sem w posta­ci tak zwa­ne­go pro­fi­lu). Ja sta­ram się restryk­cyj­nie zacho­wy­wać w mode­lach regu­ły prze­strze­ni nazw, to jest nie nada­je poję­ciom UML dodat­ko­wych” zna­czeń roz­sze­rza­ją­cych, raczej szu­kam powo­du dla któ­re­go coś nie pasu­je” i z regu­ły oka­zu­je się, że pro­blem tkwi nie w bra­kach UML” a w zro­zu­mie­niu problemu. 

      Faktem jest, że lite­ra­tu­ra jest róż­na”, po wie­lu prze­czy­ta­nych książ­kach z tej dzie­dzi­ny widzę, że wie­lu auto­rów ksią­żek i meto­dyk nacią­ga” na wła­sną potrze­bę zna­cze­nia pojęć, skut­ki są takie, że pro­wa­dzi to nie raz do wie­lo­znacz­no­ści doku­men­ta­cji”… cze­go ja aku­rat nie lubię” 😉 I fak­tycz­nie w pro­mo­wa­nym” prze­ze mnie podej­ściu ści­śle roz­róż­niam np. Aktora Systemu od zewnętrz­nej (dostęp­nej nam) imple­men­ta­cji potrzeb­nych funk­cji two­rzo­ne­go Systemu.

      Dla przy­kła­du jed­nym z auto­rów, któ­rych nie lubię” jest A.Cockbourn i jego książ­ka o przy­pad­kach uży­cia (jest on w wie­lu krę­gach uzna­wa­ny za guru use casów).

      P.S.
      W tej kon­wen­cji inter­fejs ofe­ro­wa­ny jest wła­śnie dla Aktorów, inter­fejs wyma­ga­ny dla sys­te­mów sup­por­tu­ją­cych” ;), ten sam duży sys­tem” (np. Bankowy) może być zależ­nie od kon­tek­stu akto­rem lub wspar­ciem zależ­nie od kon­tek­stu i dobrze jest te kon­tek­sty odkryć bo pozwa­la to lepiej pro­jek­to­wać te Systemy, w szcze­gól­no­ści odpo­wie­dzial­no­ści klas z jakich się skła­da­ją (mowa o obiek­to­wym para­dyg­ma­cie, ana­li­za i pro­jek­to­wa­nie poprzez odpo­wie­dzial­ność klas to kolej­na kon­wen­cja któ­rą lubię” 😉 ).

  5. Sławomir Sobótka 16 października 2012 at 18:18

    Dodam tyl­ko, że lep­szą meta­fo­rą niż MVC może być archi­tek­tu­ra Ports & Adapters (daw­niej Hexagonal). Mamy w niej por­ty (inter­fej­sy ofe­ro­wa­ne i wej­ścio­we) oraz adap­te­ry do tych interfejsów.

    Porty ofe­ro­wa­ne pozwa­la­ją być SOA Ready” oraz wspie­ra­ją mod­ny ostat­nio mul­ti­scre­en”. Natomiast adap­te­ry są już szcze­gó­łem pro­to­ko­łu komu­ni­ka­cyj­ne­go” – może być to web servis, rest, a w szcze­gól­no­ści liste­ner nasłu­chu­ją­cy zda­rzeń z inne­go hexagonu.

    W cen­trum hexa­go­nu rezy­du­je Mico Kernej, któ­ry chro­ni dome­nę – oczy­wi­ście w sty­lu DDD:]

    • Jarek Żeliński 16 października 2012 at 20:45

      Patrze na ten hexa­go­nal i jakoś nie czu­ję tego pomysłu :)…

  6. Michał Mroczek 4 listopada 2012 at 21:50

    Panie Jarosławie,

    Zgadzając się z Panem co do pro­po­zy­cji roz­wią­za­nia jed­no­cze­śnie uwa­żam, że argu­men­ta­cja typu posłu­gu­ję się ogól­ną teo­rią sys­te­mów”, rygo­ry­stycz­nie trak­tu­ję poję­cie sys­te­mu”, ja przyj­mu­ję meto­dę nauko­wą” (co suge­ru­je, że są jakieś inne,nienaukowe, ergo gor­sze?) jest trosz­kę nie na miej­scu i pach­nie bufo­na­dą (bez urazy).
    Żadna teo­ria sys­te­mów nie zawie­ra infor­ma­cji o tym, czy sys­tem ban­ko­ma­to­wy jest samo­wy­star­czal­ny czy nie i czy ma być trak­to­wa­ny jako część cało­ści czy też rów­no­rzęd­na całość. Inaczej bowiem może wyglą­dać model jeśli np. ban­ko­mat jest zarzą­dza­ny przez nie­za­leż­ne­go bro­ke­ra, współ­pra­cu­ją­ce­go z wie­lo­ma ban­ka­mi, a ina­czej jeśli jest to ban­ko­mat kon­kret­ne­go ban­ku. Nie wie­dząc tego nie deza­wu­ował­bym od razu innych pomy­słów na roz­wią­za­nie problemu.

    Inna rzecz to taka, że widzę w arty­ku­le lek­ką nie­kon­se­kwen­cję. Końcowy model poka­zu­je, że sys­tem pro­jek­to­wa­ny żąda inter­fej­su od Systemu 1, ale rela­cja jest sys­tem-sys­tem. A to powo­du­je, że gubi­my infor­ma­cję pod­czas reali­za­cji któ­rej usłu­gi dla akto­ra sys­tem pro­jek­to­wa­ny będzie potrze­bo­wał tego inter­fej­su. Zgodzi się Pan, że taka infor­ma­cja jest bar­dzo waż­na cho­ciaż­by przy przy­go­to­wy­wa­niu i reali­zo­wa­niu testów. Taka infor­ma­cja jest też przy­dat­na przy dzie­le­niu pra­cy pomię­dzy programistów.

    Jeśli więc miał­bym już mode­lo­wać tak jak Pan, zwią­zek reali­za­cji przy­piął­bym do kon­kret­ne­go przy­pad­ku uży­cia, a nie gra­ni­cy sys­te­mu, ponie­waż to czy System 1 jest akto­rem czy nie zale­ży od kon­kret­nej usłu­gi, a nie sys­te­mu per se (rysu­nek nr 2 wyraź­nie poka­zu­je, że 2 sys­te­my mogą być dla sie­bie nawza­jem i akto­ra­mi i wyko­naw­ca­mi”, a wszyst­ko zale­ży od tego jaki aku­rat roz­pa­tru­je­my przy­pa­dek użycia).

    p.s.
    Jeśli już Pan przy­wo­łu­je nazwi­sko guru use case­’ów, to pro­szę o przy­wo­ła­nie go popraw­nie, tj. A. Cockburn. I wca­le nie dzi­wię się, że Pan za nim nie prze­pa­da, ponie­waż roz­je­cha­li­ście się na pozio­mie defi­ni­cji pod­sta­wo­wych pojęć. Czytając Pana wpi­sy dot. ana­li­zy biz­ne­so­wej odno­szę wra­że­nie, że dla Pana celem ana­li­zy jest zbu­do­wa­nie mode­lu, napi­sa­nie doku­men­tu”, co waż­ne przy pury­stycz­nym uży­ciu nota­cji UML. Dla Alistair’a przy­pa­dek uży­cia (nie mają­cy nic wspól­ne­go z UMLem) jest jedy­nie narzę­dziem, jed­nym z wie­lu moż­li­wych, sto­so­wa­nym w celu roz­wią­za­nia posta­wio­ne­go pro­ble­mu. Celem ana­li­zy biz­ne­so­wej (sys­te­mo­wej tak, ale nie biz­ne­so­wej) nie jest pro­du­ko­wa­nie kolej­nych dia­gra­mów tyl­ko dostar­cze­nie roz­wią­za­nia o ocze­ki­wa­nej war­to­ści (korzy­ści).

    • Jarek Żeliński 5 listopada 2012 at 22:59

      Od koń­ca: Cockburn – za lite­rów­kę prze­pra­szam obu Panów. Dla mnie celem ana­li­zy jest zro­zu­mie­nie zja­wi­ska” i zbu­do­wa­nie jego mode­lu. Dokumentacja to tyl­ko gadżet. Notacja UML czy BPMN to język, łama­nie zasad jakie­go­kol­wiek języ­ka pro­wa­dzi do utra­ty komu­ni­ka­cji. Problem z AC to fakt uży­cia poję­cia Przypadek Użycia w zupeł­nie innym zna­cze­niu niż w UML. Nie ma to żad­ne­go znacz­nie nie licząc pew­ne­go cha­osu poję­cio­we­go jaki wpro­wa­dził, w zasa­dzie strze­lił sobie tym w kola­no. AC mode­lu­je” struk­tu­rę opro­gra­mo­wa­nia tabel­ka­mi, jeże­li tak nie jest to po co ta cała wiel­ka kon­struk­cja opisowa.

      Co do inter­fej­sów: pakiet opro­gra­mo­wa­nia może mieć zarów­no ofe­ro­wa­ne jak i żąda­ne inter­fej­sy, war­to je roz­pa­try­wać w osob­nych kon­tek­stach, sam fakt ist­nie­nia boga­te­go API” jako jed­na sztu­ka” ukry­wa sens poszcze­gól­nych poleceń. 

      Metoda nauko­wa, owszem jest pew­ną bufo­na­dą”, wyma­ga posta­wie­nia tezy, ta jest praw­dzi­wa do momen­tu jej oba­le­nia, nie trze­ba jej udo­wad­niać” (Popper, fal­sy­fi­ka­cja, meto­da naukowa).

      Bankomat: zależ­nie od kon­tek­stu jest pod­sys­te­mem sys­te­mu ban­ko­we­go lub samo­dziel­nym sys­te­mem. Teoria sys­te­mów zwra­ca uwa­gę na kon­tekst: sys­tem to sys­tem sys­te­mów, kon­tekst kon­kret­nej ana­li­zy (mode­lo­wa­nia) jest istotny. 

      Informacja (dane) to para­metr wywo­ła­nia usługi…

      No i na koniec waż­ne :): opi­su­ję jed­no z moż­li­wych podejść a nie jedy­nie słuszne … 

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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