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

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­wieksys­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.

Inne artykuły na podobny temat

Komentarze

  1. Daniel 15 października 2014 at 17:26

    Nie bar­dzo rozu­miem, cze­mu ?Generator sygna­łu cza­su? został tutaj przed­sta­wio­ny jako aktor sys­te­mu. Wszak:
    – aktor korzy­sta z usłu­gi sys­te­mu w celi reali­za­cji swo­je­go celu,
    – sys­tem ofe­ru­je usłu­gę pozwa­la­ją­cą na reali­za­cję celu aktora.
    Aktor ?Generator sygna­łu cza­su? oraz przy­pa­dek uży­cia ?Odbierz sygnał cza­su? prze­czą obu powyż­szym punk­tom. Trudno mi sobie wyobra­zić, żeby ?Generator sygna­łu cza­su? miał jakiś inte­res w wyko­rzy­sta­niu usłu­gi nasze­go sys­te­mu ?Odbierz sygnał cza­su?. Jak dla mnie zależ­ność jest odwrot­na – to ?Generator sygna­łu cza­su? świad­czy usłu­gę na rzecz nasze­go sys­te­mu (czy­li to nasz sys­tem jest dla nie­go akto­rem). W związ­ku z powyż­szym inter­fejs ?iSygnałCzasu? powi­nien być inter­fej­sem wyma­ga­nym, a ?Programowana Syrena Alarmowa? powin­na być od nie­go zależna.

    • Jaroslaw Zelinski 17 października 2014 at 00:54

      Generator cza­su jest czymś co sta­le emi­tu­je sygnał, jeże­li sys­tem” na nie­go reagu­je (i syn­chro­ni­zu­je się) to zna­czy, że po stro­nie sys­te­mu jest inter­fejs, któ­ry jest wywo­ły­wa­ny (odbierz ode mnie infor­ma­cję). Aktor co do zasa­dy to byt któ­ry ini­cju­je reak­cję sys­te­mu. kto komu świad­czy usłu­gę to kon­se­kwen­cja tego kto ini­cju­je dzia­ła­nie a ini­cju­je je gene­ra­tor cza­su, sys­tem bier­nie cze­ka na sygnał cza­su z gene­ra­to­ra, a nie pro­si go o sygnał.

  2. Daniel 23 listopada 2014 at 12:32

    A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is,
    typi­cal­ly, of value for one or more actors
    or other sta­ke­hol­ders of the system.

    To, kto ini­cju­je inte­rak­cję, nie ma żad­ne­go wpły­wu na iden­ty­fi­ka­cję akto­ra, naj­waż­niej­szy jest fakt świad­cze­nia usłu­gi. W przy­pad­ku naszej syre­ny, to nasz sys­tem korzy­sta z usług gene­ra­to­ra czasu.

    Ponadto przy­pa­dek uży­cia «Odbierz sygnał cza­su» to sztucz­ne wyma­ga­nie, któ­re zosta­ło doda­ne do dia­gra­mu po doko­na­niu pew­nej decy­zji pro­jek­to­wej (dot. wybo­ru zewnętrz­ne­go zegar­ka). Realizacja zegar­ka wła­sny­mi siła­mi rów­nież pozwo­li­ła by na osią­gnię­cie celu, ale przy­pad­ku «Odbierz sygnał cza­su» by nie było. Mamy tu do czy­nie­nia z sytu­acją, w któ­rej decy­zja pro­jek­to­wa wpły­nę­ła na zakres funk­cjo­nal­ny systemu!

    Generator sygna­łu cza­su jest sys­te­mem zewnętrz­nym, ale nie akto­rem (pro­szę wyba­czyć odro­bi­nę zło­śli­wo­ści, ale w tym momen­cie pozo­sta­je mi tyl­ko pole­cić Pański wła­sny tekst «Nie każ­dy współ­pra­cu­ją­cy sys­tem to aktor…») i to on (gene­ra­tor) posia­da inter­fejs ofe­ro­wa­ny – to ofe­ro­wa­ny przez nie­go spo­sób komu­ni­ka­cji z akto­ra­mi (m.in. naszą syre­ną). Interfejs ten obsłu­gu­je jakiś for­mat cza­su i jakiś kanał prze­ka­zy­wa­nia sygna­łu cza­su. Dlatego też to my w ramach pro­jek­tu musi­my stwo­rzyć inter­fejs, któ­ry się do tego for­ma­tu i kana­łu dosto­su­je (inter­fejs, któ­ry jest od nasze­go sys­te­mu wymagany)!

    • Jaroslaw Zelinski 23 listopada 2014 at 20:44

      To, że akto­rem sys­te­mu („aktor sys­te­mu” i aktor” na dia­gra­mie UC to dwa odręb­ne poję­cia) jest ten, któ­ry ini­cju­je inte­rak­cje wyni­ka z tego, że sys­tem reagu­je na akcję akto­ra (kom­pu­ter raczej nie zacze­pia księ­go­wej, to ona go zacze­pia). Każdy przy­pa­dek uży­cia to okre­ślo­ny stan począt­ko­wy 9dane wej­ścio­we) i reak­cja sys­te­mu na ten stan. Żaden sys­tem nie jest w sta­nie wyświad­czyć usłu­gi nie pro­szo­ny” o to… nie ma zna­cze­nia, to że o budze­nie mnie popro­si­łem dzień wcze­śniej, poda­jąc jako stan wej­ścio­wy godzi­nę pobud­ki to ja zażą­da­łem usługi. 

      PU odbierz sygnał” nie jest niczym sztucz­nym, tak dzia­ła odbior­nik sygna­łu cza­su na falach dłu­gich. I w tym kon­tek­ście zewnętrz­ny gene­ra­tor cza­su jest akto­rem, bo System reagu­je na nie­go. Nie ma znacz­nie kto budu­je inter­fejs, znacz­nie ma to czy to inter­fejs ofe­ro­wa­ny czy wyma­ga­ny, w przy­pad­ku gene­ra­to­ra sygna­łu cza­su i odbior­ni­ka sytu­acja jest pro­sta: budzik ma inter­fejs ofe­ro­wa­ny, któ­ry pozwa­la zażą­dać ode­bra­nia sygna­łu cza­su (nasz zmysł słu­chu to inter­fejs ofe­ro­wa­ny, usta jako gene­ra­tor mowy to inter­fejs wyma­ga­ny: żąda­my zro­zu­mie­nia naszej mowy – poleceń).

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.