Tag: diagram komponentów

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

12 komentarzy

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.

Czas nie jest aktorem dla Systemu c.d. czyli projekt

4 komentarze

? i uda­ło się. Ciąg dal­szy tek­stu Czas nie jest akto­rem dla Systemu, zapra­szam do lektury.

Prosty przy­kład (na opi­sa­nie bom­by w sie­ci inter­net się nie odwa­ży­łem ;)). Produkt jaki ma powstać to syre­na sygna­ło­wa. Wymaganie funk­cjo­nal­ne: sys­tem powi­nien pozwa­lać na zapro­gra­mo­wa­nie godzi­ny i cza­su trwa­nia sygna­łu. Wymaganie poza-funk­cjo­nal­ne: dokład­ność zega­ra pro­gra­ma­to­ra ma być nie gor­sza niż błąd rzę­du sekun­dy w ska­li roku (:)).

Wersja pierwsza

Diagram pro­sty (wprost mode­lo­wa­ne wyma­ga­nia zama­wia­ją­ce­go) za to imple­men­ta­cja już nie. Diagram przy­pad­ków uży­cia, jego celem jest opi­sa­nie wyma­gań funk­cjo­nal­nych, czy­li tego jakie sys­tem ma ofe­ro­wać usłu­gi albo jak kto woli serwisy:

Diagram enig­ma­tycz­ny ale do tego słu­ży ten typ dia­gra­mu: akto­rzy i usłu­gi dla nich (tak zwa­ny korzeń pro­jek­tu). W tej posta­ci (pierw­sza ite­ra­cja ana­li­zy i pro­jek­to­wa­nia) otrzy­ma­my np. taki pro­jekt archi­tek­tu­ry (logi­ki) systemu:

Jak widać sys­tem skła­da się z dwóch pod­sta­wo­wych kom­po­nen­tów: Sterownika i Generatora Dźwięku czy­li syre­ny wła­ści­wej ;). Sterownik jest imple­men­to­wa­ny (znak Realizacji) z pomo­cą gene­ra­to­ra sygna­łu cza­su i pro­gra­ma­to­ra. Programator ma inter­fejs użyt­kow­ni­ka (GUI), zapro­gra­mo­wa­ny wysy­ła do Syreny sygna­ły Start i Stop zgod­nie z usta­wio­nym (zapro­gra­mo­wa­nym) cza­sem (har­mo­no­gra­mem).

Generator sygna­łu cza­su ma wyśru­bo­wa­ne wyma­ga­nia, więc jego wyko­na­nie będzie raczej kosztowne.

Wersja dru­ga

Jak widać pro­gra­mo­wa­nia dużo, koszt cało­ści poten­cjal­nie wyso­ki, więc kom­bi­nu­je­my dalej. Czy aby na pew­no wszyst­ko trze­ba robić same­mu? Pierwsza rzecz po wstęp­nym pro­jek­cie to upew­nie­nie się, czy nie ma cze­goś goto­we­go na ryn­ku. Jak nie trud­no (chy­ba) się domy­śleć, zegar­ków na ryn­ku dosta­tek, więc chy­ba nie trze­ba go na nowo odkry­wać. Mamy coś takie­go jak COTS ([[Commercial off the shelf]]) czy­li ogól­nie dostęp­ne na ryn­ku kom­po­nen­ty lub usłu­gi. No to zmia­na projektu:

Zegarek mam goto­wy, kupu­je­my Zegar lub, tu, uży­je­my wzor­co­we­go sygna­łu cza­su, np. takie­go jakie­go uży­wa typo­wa domo­wa pogo­dyn­ka z radio­wo ste­ro­wa­nym zega­rem (to dar­mo­wa usłu­ga). Teraz nasz dia­gram UC wyglą­da tak:

Tu akto­rem abso­lut­nie nie jest Czas, akto­rem jest inny sys­tem, tu źró­dło sygna­łu cza­su. Diagram UC jest zgod­ny ze stan­dar­dem a my ​„zro­zu­mie­li­śmy isto­tę rze­czy”. Stosowanie w ana­li­zie stan­dar­dów pro­wa­dzi do rozu­mie­nia i ma taką wła­śnie zale­tę: ana­li­za i mode­lo­wa­nie pro­wa­dzi do zro­zu­mie­nia pro­ble­mu, łama­nie zasad nota­cji ukry­wa nie­zro­zu­mie­nie pro­ble­mu (o co cho­dzi z tym ocze­ki­wa­nym przez klien­ta czasem).

Wprowadziłem dwa ste­reo­ty­py: czło­wiek i sys­tem, cel chy­ba jest oczy­wi­sty (czło­wiek ma ekra­ny GUI, sys­tem ​„jakiś inter­fejs” wymia­ny danych).

Rolą ana­li­ty­ka biz­ne­so­we­go jest zro­zu­mie­nie celu zama­wia­ją­ce­go ale też opra­co­wa­nie naj­ko­rzyst­niej­sze­go roz­wią­za­nia. Nie jest to wyrę­cza­nie pro­gra­mi­stów, a ana­li­za i pro­jek­to­wa­nie. Programiści (dostaw­ca opro­gra­mo­wa­nia) imple­men­tu­ją, roz­wią­zu­ją pro­ble­my techniczne.

Tak więc jedy­nym tak na praw­dę ele­men­tem (kom­po­nen­tem) wyma­ga­ją­cym szcze­gó­ło­we­go opra­co­wa­nia i imple­men­ta­cji jest Programator, war­to było pochy­lić się nad ana­li­zą i pro­jek­to­wa­niem, testy pomy­słu wyko­nać na mode­lach… bo taniej.

Pokazałem przy oka­zji tak zwa­ne zstę­pu­ją­ce podej­ście do ana­li­zy i pro­jek­to­wa­nia: od ogó­łu do szcze­gó­łu. Zanim zacznie­my pro­jek­to­wać model dzie­dzi­ny sys­te­mu war­to ogra­ni­czyć zakres pro­jek­tu do nie­zbęd­ne­go mini­mum (naro­bić to się każ­dy potra­fi .)). W sty­lu opar­tym na [[Domain Driven Design]] (DDD) nazy­wa się „[[core doma­in]]” i „[[boun­ded con­text]]” (o DDD innym razem).

Zapytany zosta­łem tak­że o testy akcen­ta­cyj­ne. Proste: nasta­wiam jakąś godzi­nę i czas ​„wycia” i cze­kam :), żeby dłu­go nie cze­kać nasta­wiam taką by cze­kać kil­ka minut a nie godzin … upły­wu cza­su się nie testu­je (ten pły­nie i bez nas) , testu­je­my pro­gra­ma­tor… Owszem moż­na się umó­wić, że testu­je­my sygna­ły Start Stop inter­fej­su a nie syre­nę (będzie ciszej).

Podsumowanie

Jak widać trosz­kę się, mam nadzie­ję, upo­rząd­ko­wa­ło i mamy nastę­pu­ją­ce wnioski:

  1. czas nie jest żad­nym akto­rem, akto­rem jest bene­fi­cjent sys­te­mu, ktoś kto z nie­go korzy­sta lub z nim współ­pra­cu­je, para­me­try takie jak godzi­na alar­mu i czas jego trwa­nia, to nie aktor czas, a treść danych wpro­wa­dza­nych do sys­te­mu (np. for­mu­larz kon­fi­gu­ra­cji alarmu),
  2. opra­co­wa­nie samej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych abso­lut­nie nie deter­mi­nu­je pro­jek­tu, czy­li tego co nam pro­gra­mi­ści dostar­czą (a może to być kosz­tow­ne lub nie, ale to wyni­ka z pro­jek­tu a nie dia­gra­mu UC),
  3. jedy­nym spo­so­bem dokład­ne­go posta­wie­nia zada­nia pro­gra­mi­stom (deve­lo­pe­ro­wi) jest opra­co­wa­nie pro­jek­tu tego co ma powstać (jego logi­ki), jest to już nie spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych a spe­cy­fi­ka­cja sys­te­mu (albo jak kto woli, wyma­ga­nie jest projektem),
  4. nie licz­cie na to, że dostaw­ca zawsze zro­bi wszyst­ko by to kosz­to­wa­ło jak naj­mniej… (patrz dru­ga wer­sja pro­jek­tu, jest tań­szy w wyko­na­niu – ryzyko),
  5. jeże­li ktoś umiesz­cza na dia­gra­mie UC akto­ra Czas, to naj­praw­do­po­dob­niej nie rozu­mie imple­men­ta­cji albo ukry­wa ją, lub odkła­da imple­men­ta­cję, to zna­czy, że odsu­wa jed­ną z naj­waż­niej­szych decy­zji pro­jek­to­wych (kosz­ty!) na później,
  6. zale­tą takie­go pro­jek­to­wa­nia (obiek­to­we ukie­run­ko­wa­ne na kom­po­nen­ty) jest moż­li­wość szyb­kie­go osią­ga­nia celu rela­tyw­nie niskim kosz­tem, w tym pro­jek­cie tak na praw­dę do napi­sa­nia jest sam pro­gra­ma­tor, resz­tę jako COTS kupu­je­my: goto­wą syre­nę, sygnał cza­su wyko­rzy­stu­je­my ​„cudzy” (w tym przy­pad­ku to przy oka­zji kla­sycz­ny clo­ud computing).

Tak więc war­to na eta­pie ana­li­zy biz­ne­so­wej wyko­nać nie ste­no­gram z życzeń zama­wia­ją­ce­go (potra­fi sobie nawet sam zro­bić krzyw­dę) i nagi­nać zasa­dy (czas to nie aktor!), ale wyko­nać pro­jekt logi­ki sys­te­mu by zro­zu­mieć pro­blem do roz­wią­za­nia i spraw­dzić jak go roz­wią­zać naj­efek­tyw­niej. Wybór wyko­naw­cy powi­nien być ostat­nim krokiem.

Poniżej ana­li­za (dia­gram poka­zu­ją­cy powyż­sze niu­an­se ana­li­zy i mode­lo­wa­nia czy­li zro­zu­mie­nia co tak na praw­dę jest isto­ta problemu):

Wyobraźmy się, że wie­lu poten­cjal­nych deve­lo­pe­rów dosta­ło wyma­ga­nie: dostar­czyć pro­gra­mo­wa­na syre­nę (lub pierw­szy dia­gram UC) jako zapy­ta­nie ofer­to­we, jaki będzie roz­rzut ofert?

Do zama­wia­ją­cych opro­gra­mo­wa­nie: oddzie­laj­cie ana­li­zę i pro­jek­to­wa­nie od wyko­na­nia :), to ma same zale­ty. Zastanów się teraz Czytelniku, jakie roz­wią­za­nie zapro­po­nu­je więk­szość firm programistycznych…

Na koniec pyta­nie z gatun­ku iro­nii: jak na tym tle wyglą­da­ją zwin­ne meto­dy­ki wytwa­rza­nia oprogramowania?

P.S.

Polecam dia­gram przy­pad­ków uży­cia z innej stro­ny: Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML …,

oraz ten sam pro­blem, opi­sa­ny z innej per­spek­ty­wy na stro­nach IBM.

Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. Przypadki użycia i granice systemu

3 komentarze

Pora na przy­pad­ki uży­cia i gra­ni­ce sys­te­mu. W poprzed­niej czę­ści (Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej) wska­za­łem na poten­cjal­ne ryzy­ka opi­su user sto­ry i narzę­dzie niwe­lu­ją­ce tę wadę czy­li model pro­ce­su jaki opi­sał Zamawiający (hipo­te­tycz­ny autor opi­su User sto­ry). Tworzenie mode­lu ma dwa zada­nia: wery­fi­ka­cja spój­no­ści i kom­plet­no­ści opi­su Zamawiającego oraz stwo­rze­nie pod­sta­wy do okre­śle­nia zakre­su pro­jek­tu i wyspe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych czy­li tak zwa­nych przy­pad­ków uży­cia. Czy tak się robi zawsze? Ja z zasa­dy (moja meto­dy­ka opra­co­wa­na na bazie doświad­czeń i lite­ra­tu­ry) trak­tu­ję KAŻDY opis, nawet w posta­ci struk­tu­ral­nej (tabe­le, punk­ty itp.), dostar­czo­ny przez Zamawiającego jako takie wła­śnie ryzy­kow­ne user sto­ry.

Czy to brak zaufa­nia dla Zamawiającego? Przecież to dla nie­go sys­tem, Zamawiający powi­nien umieć okre­ślić cze­go potrze­bu­je. Hm… każ­dy z nas potra­fi powie­dzieć do cze­go i jaki chce samo­chód, czy to zna­czy że potra­fi wyspe­cy­fi­ko­wać kon­struk­cję tego samo­cho­du? (mój mecha­nik jest bar­dziej dosad­ny, zawsze mówi: nie nic gor­sze­go od face­ta, któ­re­mu wyda­je się, że zna się na samo­cho­dach). Aby kupić goto­we opro­gra­mo­wa­nie o stan­dar­do­wej, powszech­nie sto­so­wa­nej funk­cjo­nal­no­ści, w zasa­dzie żaden ana­li­tyk nie jest nam potrzeb­ny. Jeżeli jed­nak chce­my coś, co choć trosz­kę ma paso­wać do nasze­go biz­ne­su i nie jest try­wial­ne nale­ży do tego podejść z więk­sza rezer­wą do wsze­la­kich oczy­wi­sto­ści, bo nie mówi­my już o prze­cięt­nym samo­cho­dzie ale o samo­cho­dzie, któ­rym wystar­tu­je­my w zawo­dach. Te zawo­dy to Wolny Rynek, star­cie z Konkurencją. Może nie zawsze jest to Formuła 1, ale też pra­wie nigdy nie jest to też jaz­da spa­ce­ro­wa na święta.

Wróćmy do nasze­go mode­lu pro­ce­sów. Ten, powsta­ły na bazie opi­su Zamawiającego pozwo­lił zna­leźć luki i nie­spój­no­ści, jest jed­nak zbyt szcze­gó­ło­wy. To rzad­ki u mnie przy­pa­dek ana­li­zy bot­tom-up (od szcze­gó­łu do ogó­łu) jed­nak pierw­sza sztyw­na zasa­da ana­li­ty­ka mówi: nie ist­nie­ją sztyw­ne zasa­dy ana­li­zy i pro­jek­to­wa­nia. Po drob­nych popraw­kach, uogól­nie­niu, model wyglą­da tak:

W zakre­sie pro­jek­tu mamy wszyst­kie czyn­no­ści, któ­re wraz z ich pro­duk­ta­mi sta­no­wią pro­ce­sy biz­ne­so­we, zosta­ły ona ozna­czo­ne ste­reo­ty­pem «usłu­ga apli­ka­cji» (ste­reo­ty­py nie są czę­ścią BPMN, moż­na je sto­so­wać do wska­za­nia powią­zań pomię­dzy obiek­ta­mi na mode­lach BPMN i UML gdzie będą im odpo­wia­da­ły przy­pad­ki użycia).

Po stro­nie Klienta (użyt­kow­ni­ka, dalej zwa­ne­go tak­że akto­rem) zasto­so­wa­no uprosz­cze­nie: jest mode­lo­wa­ny jak tak zwa­na czar­na skrzynka.

Będziemy bazo­wa­li na defi­ni­cji pro­ce­su biz­ne­so­we­go: pro­ces biz­ne­so­wy to czyn­ność lub logicz­nie powią­za­ny łań­cuch czyn­no­ści prze­kształ­ca­ją­cy pro­dukt na swo­im wej­ściu w pro­dukt (jego stan) na wyj­ściu. Różnica pomię­dzy tymi pro­duk­ta­mi sta­no­wi war­tość wno­szo­ną biz­ne­so­wą przez pro­ces.

Po stro­nie Sklepu mamy więc teraz pro­ce­sy (czyn­no­ści): Rejestracja Zamówienia, Rejestracja wpła­ty, Pakowanie i wysył­ka oraz Utworzenie rapor­tu o sta­nie zamówienia.

Kolejna rzecz to gra­ni­ce sys­te­mu. Dwa zało­że­nia, któ­re wyda­ją się bar­dzo roz­sąd­ne: Firma posia­da sys­tem ERP oraz płat­no­ści elek­tro­nicz­ne będą przed­mio­tem out­so­ur­cin­gu. Tak więc wyma­ga­nia na sys­tem to:

  1. przyj­mo­wa­nie zamówień,
  2. przyj­mo­wa­nie płat­no­ści dro­ga elektroniczną,
  3. inte­gra­cja z ERP: sys­tem ten odpo­wia­da za księ­go­wa­nie fak­tur i zarzą­dza­nie magazynem,
  4. uży­cie zewnętrz­ne­go ope­ra­to­ra płat­no­ści elektronicznych.

Powyższe wyda­je się roz­sąd­ne i bywa czę­sto spo­ty­ka­ne (sta­ram się by ten przy­kład aż tak nie odbie­gał od rze­czy­wi­sto­ści ;)). Wymagania powin­ny być zwię­złe ale tez nie powin­ny wykra­czać poza opis co powin­no być moż­li­we z nowym sys­te­mem. Tak więc dia­gram przy­pad­ków jaki stwo­rzy­łem uży­cia wyglą­da tak:

Kilka słów na temat tego dia­gra­mu. Mamy przy­pa­dek uży­cia dla każ­dej aktyw­no­ści. Każdy przy­pa­dek uży­cia powi­nien zostać udo­ku­men­to­wa­ny co naj­mniej trze­ma elementami:

  1. stan począt­ko­wy (warun­ki początkowe)
  2. sce­na­riusz
  3. ocze­ki­wa­ny stan końcowy

Kontekst sta­no­wi model pro­ce­sów wiec nie musi­my tu pisać czym są poprze­dza­ne i jakich mają następ­ców poszcze­gól­ne przy­pad­ki uży­cia. Wystarczy w mode­lach zacho­wać tak zwa­ne tra­ce­abi­li­ty (ja sto­su­ję pro­stą zasa­dę: nazwa przy­pad­ku uży­cia jest taka sama jak czyn­no­ści na mode­lu pro­ce­sów, z któ­rej został wypro­wa­dzo­ny, nazwy te są uni­kal­ne). Nie musi­my tak­że two­rzyć dia­gra­mów sce­na­riu­szy nad­rzęd­nych łań­cu­chów przy­pad­ków uży­cia bo zastę­pu­je je wła­śnie model BPMN. Na koniec uwa­ga: przy­pa­dek uży­cia powi­nien być samo­wy­star­czal­ny, inny­mi sło­wy musi mieć sens jako sam jeden (sam z sie­bie słu­ży do wyko­na­nia jakiejś logicz­nej czyn­no­ści dają­cej przy­dat­ny produkt).

Scenariusz naj­pro­ściej i naj­sku­tecz­niej jest opi­sy­wać w posta­ci dia­lo­gu Aktor <-> System. Ja sto­su­ję np. pro­sta tabe­lę z kolum­na­mi Aktor i System:

AKTOR                            SYSTEM
Inicjuje pracę                   Wyświetla listę produktów
Zaznacza wybrane produkty i OK   Wyświetla treść zamówienia
Potwierdza zamówienie            Wyświetla dane o płatności
Wybiera system płatności i OK    Kończy i ewentualnie przekazuje sterowanie

Tworzenie dia­gra­mów przy­pad­ków uży­cia w zasa­dzie war­to trak­to­wać tyl­ko jako spe­cy­fi­ka­cję kon­cep­cji zacho­wu­jąc zro­zu­mia­łość dla laika. Bąbelki powin­ny być tyl­ko spe­cy­fi­ka­cją funk­cjo­nal­ną i niczym ponad to. Ten dia­gram i tak nie zastą­pi dia­gra­mu klas, sekwen­cji czy tym bar­dziej opi­su pro­ce­su (tu był BPMN). Jak nie trud­no chy­ba już zauwa­żyć, doku­men­ta­cja zmie­rza w kie­run­ku kil­ku pro­stych mode­li (dia­gra­mów) zamiast jed­ne­go spa­ge­tii-mode­lu. Często spo­ty­kam się z doku­men­ta­mi, w któ­rych autor ana­li­zy wyma­gań wszyst­ko udo­ku­men­to­wał (sta­rał się) na dia­gra­mie przy­pad­ków uży­cia. To bywa straszne.