Swego cza­su pod arty­ku­łem Business Model vs. System Model, wywią­za­ła się dys­ku­sja, po tym jak napi­sa­łem, że opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Karteka Pracowników a nie Pracownicy. Jeden z czy­tel­ni­ków napi­sał wte­dy (docie­kli­wym pole­cam w tym momen­cie cała tę dys­ku­sje pod artykułem):

… 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 jed­nak). Pracownik.pijeKaweRano().. prze­ciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model).

Gdzie pro­blem?

Regularnie na szko­le­niach i w pro­jek­tach mie­wam dys­ku­sje ini­cjo­wa­ne pyta­niem: Dlaczego nie podo­ba się Panu kla­sa Pracownik? No wła­śnie: Dlaczego nie podo­ba mi się kla­sa Pracownik?

Najpierw klu­czo­wy dla każ­de­go pro­jek­tu dia­gram przy­pad­ków uży­cia czy­li wyma­ga­nia i kon­tekst projektu:

Wymagania na system Kluczowy diagram projektu

Jest to hipo­te­tycz­ny dia­gram opi­su­ją­cy pro­sty pro­gram do sprze­da­ży. Tu pierw­sza uwa­ga, zanim coś nazwie­my «sys­tem» nale­ży pamię­tać, że

System (stgr. ??????? sys­te­ma ? rzecz zło­żo­na) ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność). (System ? Wikipedia, wol­na ency­klo­pe­dia).

Systemem więc może być opro­gra­mo­wa­nie i wte­dy mamy tu System wspo­ma­ga­ją­cy sprze­daż towa­rów. Ale pra­cow­ni­cy fir­my współ­dzia­ła­ją z tym opro­gra­mo­wa­niem, (korzy­sta­ją z nie­go), więc oni wraz z opro­gra­mo­wa­niem, jako cała fir­ma (orga­ni­za­cja) tak­że są sys­te­mem. Zgodnie z ogól­na teo­rią sys­te­mów sys­tem to sys­tem sys­te­mów”, z per­spek­ty­wy bada­ne­go Systemu mamy jesz­cze pod­sys­tem (sys­tem skła­do­wy) i super­sys­tem (sys­tem nad­rzęd­ny). Jeżeli więc nazy­wa­my nasze opro­gra­mo­wa­nie System to zna­czy, że fir­ma wraz z jej pra­cow­ni­ka­mi i wypo­sa­że­niem to Supersystem, a ewen­tu­al­ne kom­po­nen­ty Systemu wspo­ma­ga­ją­ce­go sprze­daż towa­rów to pod­sys­te­my. Innymi sło­wy mamy tu dwa sys­te­my: jeden obwie­dzio­ny linia prze­ry­wa­ną czy­li ludzie uży­wa­ją­cy opro­gra­mo­wa­nia do peł­nie­nia swo­ich obo­wiąz­ków, dru­gi będą­cy pro­jek­to­wa­nym oprogramowaniem.

Pierwsza uwa­ga: bar­dzo czę­sto obser­wu­ję, że już na eta­pie ana­li­zy zapo­mi­na się, że ana­li­zo­wa­na orga­ni­za­cja to ów Supersystem, do któ­re­go nale­ży sto­so­wać takie same zasa­dy jak do Systemu. To zna­czy, że chcąc opra­co­wać wyma­ga­nia na System nale­ży prze­ana­li­zo­wać Supersystem. Powodem wie­lu pora­żek wdro­żeń jest zigno­ro­wa­nie tego fak­tu, rzu­ca­my się na wdro­że­nie np. Systemu ERP nie mając poję­cia o jego roli” w Supersystemie (naszej orga­ni­za­cji), któ­ry tym wdro­że­niem moż­na nawet znisz­czyć. Z moich obser­wa­cji wyni­ka, że jest to jed­na z klu­czo­wych przy­czyn pora­żek wie­lu wdro­żeń Systemów CRM, któ­re na ich – tych CRM’ów – nie­szczę­ście czę­sto doty­czą całej organizacji.

I teraz wyja­śnie­nie: Supersystem (zazna­czo­ny jako Współdziałanie) ma Magazyniera i Sprzedawcę wiec System ich już nie ma (oni są Aktorami na zewnątrz). Magazynier (pamię­ta­my, że nie wol­no w jed­nym sys­te­mie – prze­strze­ni nazw – uży­wać twe­go same­go poję­cia w wię­cej niż jed­nym zna­cze­niu) to oso­ba przyj­mu­ją­ca i wyda­ją­ca towa­ry z maga­zy­nu” więc to sło­wo już zare­zer­wo­wa­li­śmy w pro­jek­cie, nie nale­ży go więc uży­wać powtór­nie w innym zna­cze­niu. Tak więc nasz Supersystem to nasi pra­cow­ni­cy uży­wa­ją­cy do pra­cy Systemu wspo­ma­ga­ją­ce­go sprze­daż towarów.

Pora na model dzie­dzi­ny sys­te­mu. Tu deli­kat­nie przy­po­mnę, wcze­śniej­szy arty­kuł: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu. Jeżeli ktoś go nie czy­tał to to jest wła­ści­wy moment. Drugi sce­na­riusz to prze­czy­ta­nie go po tym, wte­dy zapew­ne tezy tam pre­zen­to­wa­ne będą oczywiste.

Model dzie­dzi­ny nasze­go Sytemu (to jakaś wstęp­na, zapew­ne wyma­ga­ją­ca jesz­cze pra­cy wer­sja ale cho­dzi o zasady :)):

System wspomagący sprzedaż towarów - Model dziedziny systemu

Przypominam, że powyż­sze to model dzie­dzi­ny sys­te­mu czy­li nie model poję­cio­wy i na pew­no nie model danych. Jest to dia­gram klas (zasto­so­wa­łem iko­ny wzor­ca BCE) opi­su­ją­cy współ­pra­cę obiek­tów, bo zgod­nie z defi­ni­cją obiek­to­we­go paradygmatu:

Program obiek­to­wy nale­ży postrze­gać jako kolek­cję współ­dzia­ła­ją­cych obiek­tów, w prze­ci­wień­stwie do kon­wen­cjo­nal­ne­go mode­lu pro­gra­mo­wa­nia, gdzie pro­gram to lista pole­ceń (zadań, pod­pro­gra­mów) [przyp. mój] ope­ru­ją­cych na okre­ślo­nym zesta­wie danych (baza danych). (Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu).

Klasy nie mają więc na tym eta­pie ana­li­zy i pro­jek­to­wa­nia atry­bu­tów, bo do ana­li­zy i zro­zu­mie­nia pro­ble­mu są zupeł­nie zbęd­ne. Mają zaś ope­ra­cje, bo te są nie­zbęd­ne dla zro­zu­mie­nia pro­ble­mu i opra­co­wa­nia jego modelu.

No więc dla­cze­go nie podo­ba mi się kla­sa Pracownik? Bo pra­cow­nik to Aktor Systemu, a System ten prze­cho­wu­je wybra­ne dane o tym pra­cow­ni­ku. Są to dane potrzeb­ne np. do iden­ty­fi­ko­wa­nia osób wysta­wia­ją­cych doku­men­ty z Systemu, a do tego potrzeb­ne są jedy­nie Karty Pracowników a nie Pracownicy. System (opro­gra­mo­wa­nie) zastą­pił papie­ro­we Kartoteki Magazynowe dla­te­go są one teraz w Systemie, ale towa­ry są w nadal maga­zy­nie (a nie w Systemie), sys­tem ma w środ­ku” Kartę Towaru (zastą­pi­ła papie­ro­wą) zawie­ra­ją­cą opis towa­ru i jego ilość w maga­zy­nie. Kartoteka Magazynowa to pudło zawie­ra­ją­ce Karty Towarów. Faktura VAT to obiekt w sys­te­mie, moż­na ją wydru­ko­wać lub wysłać jej egzem­plarz w posta­ci elek­tro­nicz­nej kontrahentowi.

Co uzy­sku­je­my dzię­ki temu:

  • Nie ma pro­ble­mu z tym co ozna­cza w doku­men­ta­cji pro­jek­tu np. sło­wo Pracownik (wia­do­mo, że to aktor a nie kla­sa dziedzinowa).
  • System ten jest tym czym jest, czy­li narzę­dziem pra­cy czło­wie­ka a nie np. człowiekiem.
  • Model dzie­dzi­ny, z nie­wiel­ka pomo­cą, jest zro­zu­mia­ły dla biz­ne­su (tu ewen­tu­al­na ewo­lu­cja mode­lu do wzor­ców DDD).
  • Model ten nada­je się do bez­po­śred­niej imple­men­ta­cji (no prawie ;))

Kilka słów komen­ta­rza do prak­tyk i uży­tych wzor­ców. Cały pro­blem został roz­ło­żo­ny na trzy ana­li­tycz­ne skład­ni­ki: obiek­ty gra­nicz­ne (Boundary, kla­sy z pozio­ma liter­ką T) odpo­wie­dzial­ne za to jak System świad­czy usłu­gi swo­im akto­rom (Aktor to Użytkownik Systemu). Obiekty posia­da­ją­ce wie­dzę o wybra­nych aspek­tach dzia­ła­nia Systemu i świad­czą­ce wewnątrz sys­te­mu takie usłu­gi, np. o tym jak utwo­rzyć Fakturę czy Kartotekę (strzał­ka zawi­nię­ta w kształt koła). Obiekty repre­zen­tu­ją­ce uni­kal­ne, zapa­mię­ty­wa­ne ist­nie­nia” takie jak fak­tu­ry, kar­to­te­ki itp. (Entity, kla­sy w posta­ci koła z pozio­mą linią u dołu).

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

  1. Joanna

    Pytanie – czy fak­tycz­nie każ­dy pra­cow­nik jest Aktorem?

    1. Jarek Żeliński

      A kto tu mówi, że każ­dy :), wska­za­łem dwóch. Po dru­gie jed­nak patrząc na Organizacje jak na sys­tem, to to że jakiś pra­cow­nik nie jest akto­rem nie zna­czy, że nie jest współ­dzia­ła­ją­cym” ele­men­tem sys­te­mu i nale­ży go w ana­li­zie zigno­ro­wać. Pani na recep­cji nie jest akto­rem sys­te­mu FK, ale odbie­ra fak­tu­ry od listo­no­sza i przy­no­si, w kate­go­rii całej fir­my ma wpływ na to jak dłu­go potrwa pro­ces biz­ne­so­wy od dorę­cze­nia fak­tu­ry do jej zapła­ce­nia. Problem wie­lu pro­jek­tów to przed­wcze­sne okre­śle­nie zakre­su pro­jek­tu na bazie hipo­te­zy”, np. wyda­je nam się, ze chce­my CRM. I cała ana­li­za ogra­ni­cza się np. do dzia­łu han­dlo­we­go. Całość strasz­nie kule­je bo odkry­wa­ne są jakieś potrzeb­ne dane z innych dzia­łów, albo oka­zu­je się, że np. fak­tu­ry wysta­wia­ne są jed­nak w dzia­le księ­go­wo­ści a potrzeb­ne są w CRM. Dlatego znacz­nie lep­sza jest kolej­ność: okre­śle­nie celu biz­ne­so­we­go, ana­li­za (na okre­ślo­nym pozio­mie szcze­gó­ło­wo­ści) dzia­ła­nia całej orga­ni­za­cji, okre­śle­nie zakre­su pro­jek­tu na bazie pozy­ska­nej wie­dzy i celu biz­ne­so­we­go, ana­li­za wyma­gań i pro­jek­to­wa­nie opro­gra­mo­wa­nia. Większość firm star­tu­je od ostat­nie­go punk­tu… A zda­rza­ło mi się, że pro­jekt o począt­ko­wej nazwie CRM skoń­czył się jako pro­jekt Elektroniczny obieg dokumentów. 

  2. Joanna

    Pytam, bo tekst na to wskazuje:
    No więc dla­cze­go nie podo­ba mi się kla­sa Pracownik? Bo pra­cow­nik to Aktor Systemu, a System ten prze­cho­wu­je wybra­ne dane o tym pracowniku.”
    ORAZ:
    Nie ma pro­ble­mu z tym co ozna­cza w doku­men­ta­cji pro­jek­tu np. sło­wo Pracownik (wia­do­mo, że to aktor a nie kla­sa dziedzinowa).”
    Jeżeli są pra­cow­ni­cy, któ­rzy nie są akto­ra­mi (pani na recep­cji), to powyż­sze argu­men­ty prze­ciw­ko kla­sie Pracownik nie są przekonujące.

    Czym się róż­ni pra­cow­nik – użyt­kow­nik sys­te­mu od pra­cow­ni­ka – nie­użyt­kow­ni­ka? Wyłącznie upraw­nie­nia­mi, któ­re z dnia na dzień mogą być nada­ne lub ode­bra­ne. Nie uza­leż­nia­ła­bym więc struk­tu­ry mode­lu od tak ete­rycz­ne­go para­me­tru. Pierwsze sko­ja­rze­nie z nazwą Pracownik”: oso­ba zatrud­nio­na w danym przed­się­bior­stwie – czy­li defi­ni­cja SZERSZA, niż Aktor sys­te­mu. W kla­sie Pracownik mogą się więc zna­leźć infor­ma­cje takie jak: Imię, Nazwisko, Zatrudniony_od, Rola itp. atry­bu­ty pracownika.

    1. Jarek Żeliński

      Czym się róż­ni pra­cow­nik ? użyt­kow­nik sys­te­mu od pra­cow­ni­ka ? nie­użyt­kow­ni­ka?” – Niczym, jeden z nich jest Aktorem sys­te­mu, obaj są ele­men­ta­mi sys­te­mu” jaki jest cała orga­nia­acja z jej zaso­ba­mi (pra­cow­nik i opro­gra­mo­wa­nie to zaso­by fir­my). pro­blem w tym, że Pracownik to żywy czło­wiek, jeże­li System (nasze opro­gra­mo­wa­nie) prze­cho­wu­je jakieś dane o pra­cow­ni­kach (HR o wszyst­kich), to są to ich dane a nie oni.

      Tu nie cho­dzi o to, czy Pracownik jest czy nie jest Aktorem sys­te­mu ale o to, że poję­cie Pracownik zosta­ło zare­zer­wo­wa­ne dla pra­cow­ni­ków w rozu­mie­niu ludzi. będą­cych poza opro­gra­mo­wa­niem”. Mówiąc (pisząc) Pracownik Kowalski mam na myśli oso­bę. Jeżeli kla­sa nazy­wa się tak­że Pracownika to po pierw­sze to sło­wo ma teraz dwa zna­cze­nia: kla­sa oraz oso­ba mimo tego, ze nie to toż­sa­me byty. Po dru­gie opro­gra­mo­wa­nie ma w sobie” dane opis tego pra­cow­ni­ka a nie jego samego…

      Pierwsze sko­ja­rze­nie z nazwą ?Pracownik?: oso­ba zatrud­nio­na w danym przed­się­bior­stwie ? czy­li defi­ni­cja SZERSZA, niż Aktor sys­te­mu.” – Aktor (użyt­kow­nik opro­gra­mo­wa­nia) to pod­zbiór zbio­ru Pracownik, wszyst­ko jest w porząd­ku. Jednak Pracownik owszem ma imię i nazwi­sko, to jego cechy. Oprogramowanie zawie­ra elek­tro­nicz­ną kar­to­te­kę pra­cow­ni­ka, w któ­rej zapi­sa­no jego imię i nazwi­sko, a to nie to samo. Jest ogrom­na róż­ni­ca pomię­dzy mną a moją kar­to­te­ką w Urzędzie Skarbowym.

  3. Jarek Żeliński

    Innymi sło­wy, w meto­dach struk­tu­ral­nych moż­na pew­nie obro­nić tezę, że encja repre­zen­tu­ją­ca dane o pra­cow­ni­ku (dane pra­cow­ni­ka) może się nazy­wać Pracownik. W meto­dach obiek­to­wych jed­nak już raczej nie, gdyż pro­gram to narzę­dzie pra­cy czło­wie­ka (tegoż pra­cow­ni­ka), wewnętrz­na, obiek­to­wa, struk­tu­ra opro­gra­mo­wa­nia to nadal zaso­by repre­zen­to­wa­ne przez obiek­ty (imple­men­ta­cje dzie­dzi­ny). Jeżeli więc papie­ro­wą kar­to­te­kę pra­cow­ni­ka zastę­pu­je­my elek­tro­nicz­ną, to nadal jest to Kartoteka Pracownika a nie Pracownik 😉

    1. ayeo

      Z punk­tu widze­nia apli­ka­cji Magazynier czy Księgowa to jakiś szcze­gól­ny rodzaj obiek­tu Uzytkownika. Nie jest to struk­tu­ra danych tyl­ko obiekt wła­śnie, któ­ry oprócz kon­kret­nych danych zawie­ra rów­nież meto­dy. Kartoteka pra­cow­ni­ka miał­by sens jeśli roz­pa­tu­je­my to w kate­go­riach mode­lu (struk­tu­ry danych), a nie peł­no­praw­ne­go obiektu.

    2. Jarek Żeliński

      Semantycznie, co do zasa­dy, punk­tem widze­nia apli­ka­cji jest jej aktor, to zresz­tą klu­czo­wy pun­ku wyj­ścia: model przy­pad­ków uży­cia poka­zu­je sys­tem postrze­ga­ny przez Aktora bo dla nie­go on powsta­je. Dla każ­de­go użyt­kow­ni­ka opro­gra­mo­wa­nia np. ERP czy­li jego Aktora, Magazynier to zawsze będzie kole­ga z Magazynu a nie obiekt w Systemie (no może poza przy­pad­kiem pisa­nia gry kom­pu­te­ro­wej symu­lu­ją­cej maga­zyn :)). Podejście uzna­ją­ce nazy­wa­nie kla­sy i obiek­ty jak ludzi budzi ogrom­ne nie­po­ro­zu­mie­nia a nie wno­si żad­nej nowej war­to­ści do pro­jek­tu: Magazynier dla użyt­kow­ni­ka to kole­ga z pra­cy dla pro­gra­mi­sty kla­sa i tu koń­czy się komu­ni­ka­cja w pro­jek­cie pomię­dzy biz­ne­sem a deve­lo­pe­rem – stan­dar­do­wy pro­blem w pro­jek­tach tego typu.

      W meto­dach obiek­to­wych nie ist­nie­je poję­cie struk­tu­ry danych”, a KartotekaPracownika to obiekt odpo­wia­dzial­ny za prze­cho­wy­wa­nie wie­dzy o pra­cow­ni­ku i ma ope­ra­cje np. PodajDanePracowmnika, CzyPracownikMadziśDzieńWolny.

    3. ayeo

      Aktor powi­nien być odwzo­ro­wa­ny w sys­te­mie jako obiekt. System musi potra­fić roz­po­znać akto­ra. Aktora w sys­te­mie coś musi repre­zen­to­wać po pro­stu. Nikt nie chce trak­to­wać czło­wie­ka (użyt­kow­ni­ka) jako obiek­tu. Nie uzy­je­my KartorekaMagazyniera.wyloguj() tyl­ko Magazynier.wyloguj().

      Czemu poję­cie struk­tu­ry danych nie ist­nie­je? To nie­po­ro­zu­mie­nie, że wszyst­ko powin­no być obiek­tem. Przykładowo Adres jest struk­tu­rą danych (a nie obiek­tem). Zawiera publicz­ne wła­ści­wo­ści i zero logi­ki biz­ne­so­wej. Obiekty nato­miast ukry­wa­ją swo­ją imple­men­ta­cję udo­stęp­nia­jąc wyłącz­nie nie­zbęd­ne metody.

    4. Jarek Żeliński

      Aktor powi­nien być odwzo­ro­wa­ny w sys­te­mie jako obiekt.” Skąd ta teza? Ochrona roz­po­zna­je mnie w biu­rze bo ma moje­go klo­na w szu­fla­dzie czy tyl­ko pew­ne dane iden­ty­fi­ka­cyj­ne i sta­tus? A może po pro­stu uży­je­my ListaZalogowanych.Wyloguj(identyfikator_zalogowanego_uzytkownika)?

      Adres jest (może być, lepiej gdy jest) obiek­tem, ma atry­bu­ty: uli­ca, pose­sja, lokal, mia­sto, kod, ma ope­ra­cje wali­du­ją­ce popraw­ność adre­su i jest to wzo­rzec ValueObject: obiekt pozba­wio­ny toż­sa­mo­ści repre­zen­tu­ją­cy pewien zło­żo­ny typ infor­ma­cji mają­cy swo­ja wewnętrz­ną logi­kę (np. pose­sja musi wystą­pić ale lokal już nie musi, mia­sto bez kodu nie ma sen­su, jest moż­li­wość spraw­dze­nia popraw­no­ści pary mia­sto kod itp.) 

      W OOAP wszyst­ko jest obiek­tem, ale cza­sa­mi moż­na obiekt obcią­żyć odpo­wie­dzial­no­ścią za zarzą­dza­nie np. całą tabli­ca danych czy pli­kiem na dysku…

    5. ayeo

      Nie cho­dzi o odwzo­ro­wa­nie Magazyniera (jako oso­by) w sys­te­mie. Chodzi o obiekt, któ­ry go tam repre­zen­tu­je. Z punk­tu widze­nia apli­ka­cji chce­my mieć dostep do zalo­go­wa­ne­go użyt­kow­ni­ka. Magazynier (jako fasa­da) może mieć meto­dy typu pobierzPrzypisaneMagazyny() co odróż­nia go od innych typów użytkowników.

      Co do adre­su to jego wali­da­cją powi­nien zaj­mo­wać się zewnętrz­ny obiekt. Różne kra­je róż­nie wali­du­ją adres. W Irlandi nie ma kodów pocz­to­wych (chy­ba) przy­kła­do­wo. Adres ma tyl­ko zapew­nić spój­ność. Literalnie stur­ku­ra jest obiek­tem oczy­wi­ście, cho­dzi mi o idee. Obiekt nie pozwa­la na dostep do swo­ich wła­ści­wo­ści i jest her­me­tycz­ny, sturk­tu­ra danych przeciwnie.

      Nie wszyst­ko jest obiek­tem. Nie chce kopio­wać Internetu bo ten pro­blem został poru­szo­ny już w wie­lu miejscach.

    6. Jarek Żeliński

      Moim prze­sła­niem” jest teza, że dobrze jest trak­to­wać cały pro­jekt jako prze­strzeń nazw, wte­dy sło­wo Magazynier może mieć tyl­ko jed­no zna­cze­nie: albo oso­ba albo kla­sa… i o to tu głów­nie cho­dzi, ja tak­że nie chce tu brnąc w pomy­sły na implementacje.

  4. jacek2v

    Zawsze mia­łem pro­blem czy mode­lo­wać: Pracownik, Pracownicy czy też KartotekaPracowników.
    Te wyja­śnie­nie ma dla mnie sens. Dzięki.

  5. ayeo

    Gwoli wyja­śnie­nia, nie negu­ję tego co Pan suge­ru­je. Po pro­stu nie do koń­ca umiem sobie tę wizję wyobra­zić. Przedstawiam więc swój punkt widze­nia na sytu­ację. Dziękuję za rze­czo­we odpowiedzi.

Dodaj komentarz

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