Ten post ma 6 komentarzy

1. 

   Tomasz Nazar 23 sierpnia 2012 Odpowiedz

   OK.

   ..Ale roz­róż­nij­my repre­zen­ta­cję oso­by pra­cow­ni­ka, od jego danych. Dane pra­cow­ni­ka moż­na sobie trzy­mac w obiek­tach Kartoteka. Nawet nie on je bedzie posia­dal, ale moze Kierownik depar­ta­men­tu, w któ­rym pra­cu­je Pracownik. A nawet nie Kierownik, a jego SzafaZKartotekami.

   Ale, byt Pracownik jak naj­bar­dziej ma sens. Przecież tu jest zde­fi­nio­wa­ne jego zacho­wa­nie (część jedy­nie z real world, ale jednak).
   Pracownik.pijeKaweRano().. prze­ciez nie KartotekaPracownika.pijeKaweRano()

   Może to być jakieś mini­mum odzwier­cie­dla­ją­ce real world busi­ness model, ale być musi. 

   Również Pracownik korzy­sta­ja­cy z sys­te­mu infor­ma­tycz­ne­go, prze­by­wa w danym momen­cie w jakiejś jego czę­ści. Coś robi, prze­cho­dzi po dzia­łach, zle­ca wyko­na­nie akcji. 

   Pracownik lubi inne­go Pracownika. Nawiazują się mię­dzy nimi róż­ne relacje.

   Ma sens odzwier­cie­dle­nie 1:1 real world => sys­tem objects. Nie widzę prze­szkód, aby model biz­ne­so­wy zaim­ple­men­to­wać w sys­te­mie odzwier­cie­dla­jąc 1:1 obiek­ty biz­ne­so­we na systemowe.

   Nic nas rów­nież nie zwal­nia z dzie­le­nie sys­te­mu wg odpo­wie­dzial­no­ści (aka SRP). Jeśli dane pra­cow­ni­ka zasłu­gu­ją na oddziel­ny byt, to jak najbardziej.

   Przejrzałem źró­dło­wy blog. W zasa­dzie dużo z tego nie wyni­ka, oprócz jasno okre­ślo­nych defi­ni­cji business/system. Z tego z pew­no­ścią nie moż­na wysu­nąć wnio­sków, że nie ma Pracownika 😉

   1. 

      Jarek Żeliński 23 sierpnia 2012

      Ogólnie jest to przy­kład myle­nia Modeli Dziedziny sys­te­mu z ​„mode­lem jakiejś rze­czy­wi­sto­ści”. Dodam pyta­nie: co mode­lu­je­my pro­jek­tu­jąc oprogramowanie?

      Cytuję: ​„Ale, byt Pracownik jak naj­bar­dziej ma sens. Przecież tu jest zde­fi­nio­wa­ne jego zacho­wa­nie (część jedy­nie z real world, ale jednak).
      Pracownik.pijeKaweRano().. prze­ciez nie KartotekaPracownika.pijeKaweRano()”

      Ok, ale o jaki model cho­dzi? O obiek­to­wy model jakiejś rze­czy­wi­sto­ści? Wtedy owszem, ma sens Pracownik.pijeKaweRano(). Ale jeże­li pro­jek­tu­je­my np. sys­tem HR to taki ele­ment kom­plet­nie nie ma sen­su, z powo­dów chy­ba oczy­wi­stych: sys­tem HR to nie gra kom­pu­te­ro­wa o nazwie ​„Moja Korporacja” a System mają­cy zastą­pić papie­ro­we meto­dy doku­men­to­wa­nia danych o pra­cow­ni­ku, więc Pracownik Pije kawę, ale w swo­im poko­ju. System HR co naj­wy­żej zawie­ra dane o tym pra­cow­ni­ku (w tym np. numer tego poko­ju) ale System HR nie słu­ży do gra­ficz­ne­go zobra­zo­wa­nia na ekra­nie fak­tu picia kawy przez tegoż pracownika. 

      „Nie widzę prze­szkód, aby model biz­ne­so­wy zaim­ple­men­to­wać w sys­te­mie odzwier­cie­dla­jąc 1:1 obiek­ty biz­ne­so­we na sys­te­mo­we.” A ja widzę, bo sys­tem biz­ne­so­wy to nie gra kom­pu­te­ro­wa. Druga waż­na uwa­ga: model biz­ne­so­wy i model dzie­dzi­ny to zupeł­nie odręb­ne poję­cia. Model biz­ne­so­wy opi­su­je to co robi fir­ma (w tym jej pra­cow­ni­cy a raczej role jakie peł­nią bo nie obcho­dzi mnie kon­kret­ny Kowalski a co naj­wy­żej to ​„co robi Dyrektor Handlowy”. Model Dziedziny Systemu to model tego co System ma zastą­pić, w koń­cu to nowe narzę­dzie pra­cy, czy­li Model Dziedziny to model narzę­dzia jakie­go uży­je Aktor. 

      Wskazałem na ten blog, bo poru­szył waż­ną kwe­stię zaś mój post to nie tłu­ma­cze­nie czy inter­pre­ta­cja tego wpi­su a moje wnio­ski i doświad­cze­nie. Moim zda­niem wie­le szkód w pro­jek­tach pro­gra­mi­stycz­nych przy­no­si myle­nie (może nawet mie­sza­nie) stron: świat akto­rów (poza Systemem) i świat sys­te­mu (to czym jest System). Bardzo przy­dat­ny dia­gram przy­pad­ków uży­cia ma magicz­ny i naj­waż­niej­szy chy­ba ele­ment: pro­sto­kąt System. Tak więc co, jaką kla­sę, będzie zawie­rał System: Pracownik czy KartotekaPracownika? Pracownik to Aktor Systemu, jest poza nim (bo to aktor), System zawie­ra ele­men­ty prze­twa­rza­ne (sko­ro Pracownik jest Aktorem to nie jest Obiektem w Systemie, to zasa­da wyłą­czo­ne­go środ­ka dla prze­strze­ni pojęciowych).

      Bo tak na praw­dę: co ma zro­bić pro­gra­mi­sta współ­two­rzą­cy System HR z kla­są i ope­ra­cją: ​„Pracownik.pijeKaweRano()”?

2. 

   Tomasz Nazar 23 sierpnia 2012 Odpowiedz

   Hmm.. wie­le nie­pra­wi­dlo­sci, wie­le… chy­ba ktoś musi wró­cić do real­ne­go pro­jek­to­wa­nia i reali­za­cji (imple­men­ta­cji) mode­lów ze świa­ta rzeczywistego 🙂

   a) oczy­wi­ście, że obiekty/klasy. A co inne­go? To pasu­je naj­bar­dziej do odzwier­cie­dle­nia świa­ta, acz i tak ułom­ne w jego odzworowaniu. 

   b) nie wiem czym sys­te­my HR się cha­rak­te­ry­zu­ją, ale jak naj­bar­dziej jeśli prze­twa­rza­ją dane ludzi i ich doświad­cze­nie zawo­do­we, prze­szłych pra­co­daw­ców, ich hob­by, to wszyst­kie te mode­le ze świa­ta biz­ne­so­we­go mają 1:1 odpo­wied­nik w mode­lu sys­te­mo­wym (kla­sach dane­go języ­ka programowania).
   To czy ktoś, gdzieś, u kogoś pra­co­wał programuje/projektuje się naj­zwy­czaj­niej i naj­nor­mal­niej two­rząc te (Pracodawca, Osoba, Stanowisko) kla­sy, te usecase’y ..

   c) To, że sys­tem HR pre­zen­tu­je się ​„wido­ko­wo” jako sys­tem zarzą­dza­nia doku­men­ta­mi (tak?), w niczym nie prze­szka­dza. To tyl­ko war­stwa pre­zen­ta­cji dla osób obsłu­gu­ją­cych sys­tem. To tyl­ko to, co wyplu­wa drukarka.
   Ale aby to zapre­zen­to­wać, koniecz­ne jest 1:1 zapro­jek­to­wa­nie sys­te­mu _wewnątrz_, tak jak dzia­ła i wyglą­da biz­nes. Inaczej się nie da.

   Skrótów i uprosz­czeń robić nie wol­no i nie ma sensu.

   d) A co złe­go jest w grze kom­pu­te­ro­wej? Może dalej za bar­dzo sku­piasz się na pre­zen­ta­cji? Tam rów­nież jest jakis model biz­ne­so­wy zapro­jek­to­wa­ny (infan­tyl­ny, ale jakiś)

   e) rela­cja mię­dzy Janem Kowalskim, któ­ry jest Dyrektorem Handlowym, jest oczy­wi­sta, i oba mają byt w świe­cie rze­czy­wi­stym, jak i w systemie

   f) jeśli zało­ży­my, że nie mogę imple­men­to­wać ​„jakoś” p.wypijKawę(), bo wla­nie wody do moni­to­ra zwią­że się z przy­kro­ścią wizy­ty co naj­mniej inspek­to­ra BHP, to rów­nież nie mogę i Pracownik i Osoba – bo to nie smer­fy i się na dysk twar­dy nie zmieszczą.
   Ale to bez sensu.

   Przy takim ogra­ni­cze­niu, zosta­ją nam fak­tycz­nie BitoweKartotekiWRamieLubDyskuOOsobie… ojej! Wyjeżdżam stąd pierw­szym autobusem

   🙂

   I na koniec odpo­wiedź na pyta­nie: mode­lu­je­my świat real­ny. Robimy to pro­gra­mu­jąc, bo takie nam Bóg dał narzę­dzia, a nie inne.
   Ułomności nie­umie­jęt­no­ści zro­bie­nia tego może­my odło­żyć na bok i zało­żyć, że się da to zrobić.

   Jak już czy­tać, to http://​www​.lean​so​ftwa​re​ar​chi​tec​tu​re​.com/ Copliena

   1. 

      Jarek Żeliński 24 sierpnia 2012

      a. kon­kret­ne opro­gra­mo­wa­nie, jako narzę­dzie pra­cy, odwzo­ro­wu­je narzę­dzie pra­cy a nie jego użyt­kow­ni­ka bo ten może być być tyl­ko po jed­nej stro­nie monitora…
      b. sys­te­my HR cha­rak­te­ry­zu­ją się tym, że poma­ga­ją w pro­wa­dze­niu spraw kadro­wych, inny­mi sło­wy zastę­pu­ją papie­ro­wą doku­men­ta­cję (jej część) i auto­ma­ty­zu­ją np. nali­cza­nie wyna­gro­dze­nia, tak więc pyta­nie o cel pro­jek­tu brzmi: ma powstać opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie dany­mi o pra­cow­ni­kach czy pracownikami?
      c. oczy­wi­ście, że nie ma sen­su robie­nie skró­tów, ale jest coś co się nazy­wa w nie­któ­rych tech­ni­kach pro­jek­to­wa­nia ​„boun­ded con­text” (DDD), dla sys­te­mu HR nie mode­lu­je­my więc ​„całe­go świa­ta” a jedy­nie to co jest zwią­za­ne z zada­nia­mi (odpo­wie­dzial­no­ścią) tego sys­te­mu, a to nie jest uprosz­cze­nie tyl­ko selekcja.
      d. nie ma nic złe­go w grach kom­pu­te­ro­wych, po pro­tu do cze­go inne­go służą,
      e. w świe­cie real­nym jest Dyrektor Handlowy, zapew­ne jest akto­rem sys­te­mu HR, w Systemie mamy jego dane i histo­rie zatrud­nie­nia ale nie jego samego,
      f. jak wyżej.

      Obracamy się w sfe­rze pro­ble­mu ​„jak nazwać kla­sę repre­zen­tu­ją­cą imię, nazwi­sko, datę uro­dze­nia i potra­fią­cą wyli­czyć aktu­al­ny wiek tej oso­by”, ja ją nazwę ​„InformacjeOOsobie”, owszem moż­na ją nazwać ​„Osoba”. W czym tkwi pro­blem? Ano orga­ni­za­cja uży­wa sło­wa Osoba w sto­sun­ku do żywych ludzi (swo­ich pra­cow­ni­ków, klien­tów itp.), po dru­gie Aktorem Systemu (jest jego użyt­kow­ni­kiem) jest tak­że Osoba. Patrząc na to z per­spek­ty­wy orga­ni­za­cji zaczy­na zacie­rać się zna­cze­nie sło­wa Osoba. Do tego ​„wczo­raj” Pani Kadrowa uży­wa­ła na swo­im biur­ku ​„KartotekiOsobowejPracownika” a od jutro ktoś mówi jej, że ma przed sobą Pracownika. Wdrożenie takie sta­je się dla wie­lu bene­fi­cjen­tów nowe­go opro­gra­mo­wa­ni prze­ży­ciem trau­ma­tycz­nym. Po dru­gie MUSZĄ się nauczyć nowe­go zna­cze­nia wie­lu ​„sta­rych” pojęć, a to tyl­ko utrud­nia cały pro­ces wdro­że­nia. Nie rozu­miem co zna­czy ​„BitoweKartotekiWRamieLubDyskuOOsobie”.

      W kwe­stii ksią­żek ja dla odmia­ny gorą­co pole­cam ści­śle obiek­to­we i bar­dzo prak­tycz­ne podej­ście w:
      – E.Evansa (DDD) – o mode­lo­wa­niu dzie­dzi­ny sys­te­mu w kon­wen­cji ​„mode­lo­wa­nia tego co repre­zen­tu­je i prze­twa­rza dane oprogramowanie”
      – Heinz Züllighoven, Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach – o pięk­nej meta­fo­rze two­rze­nia opro­gra­mo­wa­nia: pro­gram to ​„narzę­dzia i mate­ria­ły” w rękach użytkownika
      – Rebecca Wirfs-Brock, Alan McKean, Projektowanie obiek­to­we. Role, odpo­wie­dzial­ność i współ­pra­ca, dosko­na­ła książ­ka o ana­li­zie obiek­to­wej i projektowaniu.
      – Fowler albo Go4, Wzorce Projektowe, wska­zów­ki roz­wią­zy­wa­nia wie­lu pro­ble­mów pro­jek­to­wych, ze szcze­gól­nym uwzględ­nie­niem wzor­ców ana­li­tycz­nych domenowych.
      – gorą­co pole­cam tak­że prze­czy­ta­nie jed­nak krót­kie­go arty­ku­łu, któ­ry cyto­wa­łem na począt­ku tego postu.

      Zapewne róż­ni­my się bar­dzo sty­lem ana­li­zy i pro­jek­to­wa­nia. Autobusów mamy wie­le, cele i dro­gi ich osią­ga­nia róż­ne… nie ma problemu 🙂

3. 

   Tomasz Nazar 24 sierpnia 2012 Odpowiedz

   Ciekawe..

   To na co chcę zwró­cić uwa­gę, to, że pre­zen­ta­cja w posta­ci kartotekiPracownika dla Pani Ewy, któ­rej trau­my nikt nie chce doświad­czyć nie ma nic wspól­ne­go z tym jak mode­lu­je­my sys­tem wewnątrz.
   Ta kla­sa tyl­ko kwe­stia war­stwy prezentacji.

   Kto powie­dział, że spo­sób reali­za­cji wnętrz­no­ści sys­te­mu ma mieć wpływ na to jak pre­zen­tu­je­my to na ekranie/drukarce dla Pani Ewy.

   Mnie inte­re­su­je jak prze­no­sić świat real­ny w sys­te­mo­wy i nie widzę tu żad­nych ogra­ni­czeń wspomnianych.
   A wnętrz­no­ści sys­te­mu pro­gra­mu­je­my my, i aby to robi­ło się naj­ła­twiej, było jak naj­bli­żej real­nym wyma­ga­niom, i less bugs, i był gdzieś kod, któ­ry i oso­ba biz­ne­so­wa może łatwo przeczytać/zmodyfikować (z pomo­cą IT) – to i nazwy i obiek­ty muszą być jak naj­bar­dziej 1:1

   W moim sys­te­mie ​„KartotekaPracownika”, to była­by jedy­nie wart­stwa pre­zen­ta­cji. A do tego, aby ja wyge­ne­ro­wać potrze­bo­wał­bym klas/obiektów: Pracownik, Osoba, Kraj (pol­ska), UrządMiasta (do trzy­ma­nia pese­li, nazwisk i imion), Czas (do trzy­ma­nia even­tów, kie­dy oso­ba się urodziła).

   Z tego wyni­ka, że u mnie nie ma potrze­by w sys­te­mie posia­da­nia kla­sy InformacjeOOsobie, jako, że jest to jedy­nie kwe­stia pre­zen­ta­cji i tyl­ko w tej war­stwie wystę­pu­je, powiedz­my jako szablon/template do gene­ro­wa­nia pli­ku html/pdf.

   Aby ją wyge­ne­ro­wać na ekran, pyta­my ​„urządMiasta.podajPesel(osoba)”, ​„czas.narodziny.kiedy(osoba)”, itd.. 

   Tak to wyglą­da w świe­cie rzeczywistym 🙂

   Można sobie upro­ścić, że to ja mam pesel, ale w rze­czy­wi­sto­ści ja o nim wiem przez to, że gdzieś, ktoś mi go wyge­ne­ro­wał w Urzędzie Miasta.
   Podbnie z imionami..

   I wie­le, wie­le innych atry­bu­tów, któ­re przez lata wylą­do­wa­ły w kla­sie Person, co jest oczy­wi­stym zła­ma­niem SRP, a nawet same­go RP 😉

   1. 

      Jarek Żeliński 24 sierpnia 2012

      Ogólnie to tyl­ko, moim zda­niem – prag­ma­ty­ka mode­lu dzie­dzi­ny. Można, nie ma zaka­zu, zbu­do­wać model dzie­dzi­ny zawie­ra­ją­cy kla­sę Osoba, rzecz w tym, że (cytat z lin­ko­wa­ne­go arty­ku­łu) jest to jed­nak tyl­ko ​„suro­gat”, bo praw­dzi­wa Osoba jest czło­wie­kiem z krwi i kości, zapew­ne korzy­sta z tego opro­gra­mo­wa­nia… Prezentacja danych ​„imię i nazwi­sko” na ekra­nie (poza sfor­ma­to­wa­niem) wyma­ga wywo­ła­nia ope­ra­cji JakSięNazywasz kla­sy Osoba, lub w kon­wen­cji, któ­rą pre­fe­ru­ję, wywo­ła­nie ope­ra­cji PodstawoweDaneOsoby kla­sy KartotekaPracownika. Pojęcie ​„real world” ma sens ;), jeże­li opro­gra­mo­wa­nie HR zastę­pu­je papie­ro­wy sys­tem kadro­wy, to czym tu jest ​„real world”? Klasą repre­zen­tu­ją­cą papie­ro­wą kar­to­te­kę, któ­ra zastę­pu­ję nowym oprogramowaniem…

      Przykład z PESEL jest OK, bo pyta­nie o PESEL mogę zadać oso­bie jak i Urzędowi, pyta­nie czy pytam o to żywe­go kowal­skie­go czy Urząd, czy klasę/komponent SystemPESEL, to samo pyta­nie moż­na zadać róż­nym ​„bytom”. Kto ma PESEL? Ja nie, jest atry­bu­tem moje­go dowo­du oso­bi­ste­go, pomi­ja­jąc ewen­tu­al­ne zapa­mię­ta­nie go, jak ktoś zapy­ta mnie mnie o PESEL, muszę naj­pierw ​„zapy­tać” o to mój dowód. Tyle w kwe­stii ​„real world”. W moich pro­jek­tach nie ma klas DowódOsobisty, jest kla­sa DaneDowoduTożsamości z atry­bu­ta­mi rodzajDokumentu, numerSerii (i pew­nie inne).

      Obracamy się wokół tego jaką kon­wen­cję mode­lo­wa­nia sto­su­je­my… ja o tej, któ­rą sto­su­je (nie ja jeden) powiem, że jest inna niż Twoja, nie że lep­sza czy gor­sza… co naj­wy­żej bro­nie tezy, że ​„real world” w opro­gra­mo­wa­niu pole­ga na tym, że opro­gra­mo­wa­nie jest narzę­dziem w rękach czło­wie­ka podob­nie jak kal­ku­la­tor, papier, ołó­wek, papie­ro­we for­mu­la­rze itp. a nie symu­la­to­rem fir­my dla któ­rej pro­jek­tu­ję opro­gra­mo­wa­nie, no chy­ba, że fak­tycz­nie ma być symu­la­to­rem ale wte­dy nazy­wa się GRA BIZNESOWA lub SYMULATOR BIZNESU. 

      SRP (o ile rozu­miem: Single Responsibility Principle) jest bar­dzo wygod­ne i pomoc­ne w pro­jek­to­wa­niu, zaś zamia­na moje­go dowo­du oso­bi­ste­go, pasz­por­tu, tecz­ki z papie­ra­mi i mojej sza­fy w poko­ju na jeden obiekt z dzie­siąt­ka­mi atry­bu­tów to wła­śnie szko­dli­we nad­mier­ne uprosz­cze­nie, któ­re o ile pamię­tam krytykowałeś.

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