Model dziedziny jako mechanizm

W 2013 roku, arty­kuł o tym czym jest model dzie­dzi­ny, zakoń­czy­łem słowami:

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) ?świat? w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) ?dru­kuj?. Ale to temat na inny wpis :). (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc czte­ry lata czekało 😉 … 

Wprowadzenie

Do napi­sa­nia tego krót­kie­go arty­ku­łu skło­ni­ły mnie moje bada­nia w obsza­rze sty­ku ogól­nej teo­rii sys­te­mów i mode­lo­wa­nia sys­te­mów oraz dys­ku­sje w sie­ci na temat obiek­to­wo­ści” w pro­gra­mo­wa­niu i jak się do tego ma UML. Przypomnę defi­ni­cję sys­te­mu z ory­gi­na­łu, czy­li z książ­ki twór­cy ogól­nej teo­rii systemów:

…zło­żo­ny obiekt wyróż­nio­ny w bada­nej rze­czy­wi­sto­ści, sta­no­wią­cy całość two­rzo­ną przez zbiór obiek­tów ele­men­tar­nych (ele­men­tów) i powią­zań (związ­ków) mię­dzy nimi (Źródło: Ogólna Teoria Systemów a ana­li­za | | Jarosław Żeliński IT-Consulting

Pojęcie sys­tem ozna­cza albo deta­licz­ną struk­tu­rę okre­ślo­nej rze­czy­wi­sto­ści albo abs­trak­cję ją repre­zen­tu­ją­cą (model systemu).

Świat rzeczywisty a jego model

Popatrzmy jak w natu­rze wyglą­da zegar:

Implementacja to kon­struk­cja kon­kret­ne­go zega­ra, to współ­pra­cu­ją­ce ele­men­ty mecha­nicz­ne wyglą­da­ją­ce np. tak:

Opis mecha­ni­zmu dzia­ła­nia zega­ra to abs­trak­cja opi­su­ją­ca ten mecha­nizm i wyja­śnia­ją­ca dzia­ła­nie zaob­ser­wo­wa­ne­go zega­ra, wyglą­da np. tak (tu dia­gram klas UML):

Powyższe trzy ilu­stra­cje to od góry: widok czar­nej skrzyn­ki, o któ­rej wie­my co poka­zu­je (spo­glą­da­my na tar­czę zega­ra dość czę­sto), na zdję­ciu mamy kon­kret­ny mecha­nizm zega­ro­wy czy­li jakąś kon­kret­ną rze­czy­wi­stość. Trzeci obraz to abs­trak­cyj­ny model opi­su­ją­cy mecha­nizm dzia­ła­nia zega­ra. Mechanizm ozna­cza to nie kon­struk­cję a mecha­nizm dzia­ła­nia” rozu­mia­ny jako sposób/zasada dzia­ła­nia” .

Ten model: to jest wła­śnie model dzie­dzi­ny, czy­li opis mecha­ni­zmu dzia­ła­nia systemu.

Nauka i naukowe metody

To była ana­li­za i odkry­cie” (w tym udo­ku­men­to­wa­nie czy­li opis teo­rii) mecha­ni­zmu dzia­ła­nia zega­ra. A jak wyglą­da pro­jek­to­wa­nie? Po pro­stu to samo od koń­ca”. Projektem wyma­ga­ne­go sys­te­mu jest abs­trak­cyj­ny model mecha­ni­zmu. Kolejnym eta­pem two­rze­nia real­ne­go (fizycz­ne­go) sys­te­mu będzie inży­nier­ski, szcze­gó­ło­wy pro­jekt wyko­naw­czy i wyko­na­nie real­ne­go zega­ra (imple­men­ta­cja jego mode­lu), taką imple­men­ta­cją jest np. zegar na powyż­szym zdję­ciu (ale mógł by to być kom­pu­ter wraz odpo­wied­nim programem).

Opisany tu spo­sób ana­li­zy i zro­zu­mie­nia okre­ślo­nej rze­czy­wi­sto­ści, to tak na praw­dę nauko­wa meto­da odkry­wa­nia i opi­su mecha­ni­zmu bada­ne­go zja­wi­ska: fak­ty są wyja­śnia­ne z pomo­cą opi­su mecha­ni­zmu opi­su­ją­ce­go dane zja­wi­sko, a nie z pomo­cą deta­licz­ne­go opi­su kon­struk­cji bada­nej rze­czy­wi­sto­ści. Odkrycie w nauce ozna­cza wyja­śnie­nie a nie skon­stru­owa­nie czy odtwo­rze­nie. Widać to szcze­gól­nie w fizy­ce, gdzie zapew­ne ato­mów nie zoba­czy­my nigdy, ale potra­fi­my wyja­śnić zacho­wa­nie się mate­rii opi­su­jąc ją abs­trak­cyj­nym modelem.

Co tu jest mode­lem dzie­dzi­ny sys­te­mu? Każdy sys­tem moż­na zobra­zo­wać jako model mecha­ni­zmu jego dzia­ła­nia, moż­na go uzu­peł­nić o ele­men­ty, któ­re decy­du­ją o jego cechach poza-funk­cjo­nal­nych taki­mi jak jakość, kon­tro­la dostę­pu do nie­go i cała masy innych cech spe­cy­ficz­nych dla kon­kret­ne­go śro­do­wi­ska i celu uży­cia innych niż sam mecha­nizm działania.

Analiza ma na celu zro­zu­mie­nie, dokład­nie tak samo jak nauka, któ­ra wyja­śnia obser­wo­wa­ne zja­wi­ska. W przy­pad­ku pro­jek­tów z zakre­su inży­nie­rii opro­gra­mo­wa­nia zaczy­na­my od zro­zu­mie­nia jak dzia­ła­ją ele­men­ty orga­ni­za­cji”, a póź­niej wybra­ne z nich zle­ca­my do wyko­na­nia w posta­ci opro­gra­mo­wa­nia jako np. ele­men­ty auto­ma­ty­za­cji pra­cy fir­my lub w celu zastą­pie­nia kon­struk­cji mecha­nicz­nej opro­gra­mo­wa­niem (księ­go­wość papie­ro­wa” zamie­nio­na na kom­pu­te­ro­wą”, sza­fy z akta­mi na elek­tro­nicz­ne archi­wum itp.).

Dostrzegam jed­nak czę­sto w pra­cach ana­li­ty­ków myle­nie cech jako­ścio­wych z mecha­ni­zmem dzia­ła­nia. Typowe jest np. pisa­nie wyma­gań poza­funk­cjo­nal­nych jako sys­tem powi­nien pozwa­lać na kon­tro­lę popraw­no­ści… [cze­goś tam]”… To jest jed­nak cecha mecha­ni­zmu (a nie jako­ścio­wa”), któ­ry nie powi­nien na coś pozwa­lać, np. na sprze­daż pro­duk­tów fir­mie, któ­ra prze­kro­czy­ła war­tość kre­dy­tu kupiec­kie­go. Cecha ta jest ele­men­tem mecha­ni­zmu dzia­ła­nia sys­te­mu (ele­men­ty sys­te­mu reali­zu­ją jego logi­kę dzia­ła­nia). Mechanizm to opis dzia­ła­nia sys­te­mu, w zasa­dzie jest to skoń­czo­ny zestaw reguł (tak jak pra­wa fizy­ki okre­śla­ją zacho­wa­nie się ciał sta­łych), zna­jąc (rozu­mie­jąc) mecha­nizm dzia­ła­nia sys­te­mu jeste­śmy w sta­nie prze­wi­dzieć każ­de jego zacho­wa­nie w okre­ślo­nej sytu­acji (odpo­wiedź na bodziec). Tymi bodź­ca­mi, w przy­pad­ku opro­gra­mo­wa­nia, są dane wej­ścio­we, dane wyj­ścio­we to efekt zacho­wa­nia sys­te­mu (abs­tra­hu­ję tu od for­my ich pre­zen­ta­cji). Dokładnie tak samo teo­ria wyja­śnia­ją­ca w nauce pozwa­la na pre­dyk­cję reak­cji sys­te­mu na bodźce.

W tym miej­scu gorą­co pole­cam książ­kę Filozofia mate­ma­ty­ki i infor­ma­ty­ki, pra­cę zbio­ro­wą pod redak­cją Romana Murawskiego. To co nazy­wa­my mode­lem dzie­dzi­ny sys­te­mu, nie jest pro­stym opi­sem dome­ny pro­ble­mu”, to nie tyl­ko jeden pro­sty dia­gram. Aby opi­sać sys­tem nale­ży co najmniej:

  1. opi­sać jego wewnętrz­ną strukturę,
  2. opi­sać jego zacho­wa­nie w odpo­wie­dzi na okre­ślo­ne bodźce,
  3. zagwa­ran­to­wać zestaw pojęć (słow­nic­two) by go jed­no­znacz­nie opi­sać, czy­li nazwać każ­dy jego ele­ment (nazwy obiek­tów i klas obiek­tów, nazwy ope­ra­cji, nazwy atrybutów).

Powyższe to mecha­nizm dzia­ła­nia sys­te­mu (nazew­nic­two słu­ży do roz­róż­nia­nia ele­men­tów sys­te­mu oraz ich opi­su, zde­fi­nio­wa­ne poję­cie jako nazwa, mówi nam czym jest nazwa­ny element).

Czy musi­my znać opis wszel­kich zacho­wań sys­te­mu? Nie, i z regu­ły nie jeste­śmy w sta­nie ich wszyst­kich opi­sać, zresz­tą nie ma takiej potrze­by. Jednak mecha­nizm (wie­dza jak coś dzia­ła) pozwa­la nam wyja­śnić zaob­ser­wo­wa­ne zacho­wa­nia oraz prze­wi­dzieć przy­szłe (dokład­nie tak jak teo­ria naukowa).

Niewątpliwie mło­tek został stwo­rzo­ny do wbi­ja­nia gwoź­dzi i ten jego przy­pa­dek uży­cia” był przy­czy­ną (wyma­ga­nie) jego skon­stru­owa­nia, jed­nak wie­dząc jak jest skon­stru­owa­ny i zna­jąc pra­wa fizy­ki, jeste­śmy w sta­nie prze­wi­dzieć prak­tycz­nie wszel­kie inne skut­ki nawet nie obser­wo­wa­ne wcze­śniej, np. nie musi­my usły­szeć od niko­go user sto­ry” by prze­wi­dzieć co się sta­nie gdy rzu­ci­my młot­kiem w szy­bę okna sąsiada.

Wewnętrzna struk­tu­ra sys­te­mu i powią­za­nia mię­dzy jego ele­men­ta­mi to jego model (model dzie­dzi­ny sys­te­mu). Każdy ele­ment sys­te­mu – obiekt – ma nazwę, listą zacho­wań czy­li ope­ra­cje, o każ­dej ope­ra­cji wie­my jak jest reali­zo­wa­na, czy­li zna­my meto­dę wytwo­rze­nia odpo­wie­dzi na bodziec. Taki model, jako abs­trak­cja okre­ślo­nej rze­czy­wi­sto­ści, nie zawie­ra ele­men­tów gene­ra­li­zu­ją­cych! (struk­tu­ra sys­te­mu to zależ­no­ści uży­cia, błę­dem jest uży­wa­nie tu związ­ków gene­ra­li­za­cji-spe­cja­li­za­cji jako dziedziczenia!).

Ważne! Opracowanie tego mode­lu to zada­nie ana­li­ty­ka pro­jek­tan­ta, bo nie jest rolą deve­lo­pe­ra znać i rozu­mieć dome­nę (mecha­nizm dzia­ła­nia) danej orga­ni­za­cji, zada­niem deve­lo­pe­ra jest imple­men­ta­cja mecha­ni­zmu i speł­nie­nie wyma­gań jakościowych! 

Zachowanie sys­te­mu moż­na przed­sta­wić dla skoń­czo­nej licz­by kon­kret­nych bodź­ców (przy­pad­ki uży­cia), są to sce­na­riu­sze. Każdy taki sce­na­riusz to przed­sta­wie­nie tego w jaki spo­sób współ­pra­cu­ją obiek­ty sys­te­mu by poka­zać, jak powsta­je sku­tek w odpo­wie­dzi na bodziec. W opro­gra­mo­wa­niu tak zwa­nym biz­ne­so­wym”, bodziec i sku­tek to okre­ślo­ny zestaw danych.

Scenariusze przy­pad­ków uży­cia to tak­że pla­ny testów, goto­wy sys­tem musi się zacho­wy­wać zgod­nie z przewidywaniami.

Kluczem do zro­zu­mie­nia i jed­no­znacz­no­ści cało­ści jest nazew­nic­two. Istotny jest nie tyl­ko sam zestaw pojęć (słow­nik), ale i związ­ki mię­dzy nimi.

O zna­cze­nie słów nale­ży pytać tyl­ko w ich związ­kach zda­nio­wych, nie zaś oddzie­le­nie .

Dlatego kom­plet­ny model poję­cio­wy to nie tyl­ko pła­ska alfa­be­tycz­na lista, to struk­tu­ra poka­zu­ją­ca poję­cia i fak­ty łączą­ce je w jeden kon­tekst w danej dome­nie (spo­ry o to czy onto­lo­gia jest opi­sem rze­czy­wi­sto­ści czy jed­nak nie jest). Taki model moż­na zobra­zo­wać jako dia­gram klas nota­cji UML lub jako dia­gram fak­tów nota­cji SBVR. W tym miej­scu poja­wia się wie­le nie­po­ro­zu­mień i złych mode­li (inter­net jest pełen złych mode­li zali­cza­nych do antyw­zor­ca ane­micz­ny model dzie­dzi­ny opi­sa­ne­go przez Fowlera):

  1. model dzie­dzi­ny sys­te­mu to dia­gram klas opi­su­ją­cy struk­tu­rę sys­te­mu: to jak współ­pra­cu­ją jego ele­men­ty (obiek­ty),
  2. model poję­cio­wy dla sys­te­mu, to zestaw pojęć defi­nio­wa­nych w okre­ślo­nym kon­tek­ście, słu­żą­cych do nada­wa­nia nazw ele­men­tem tego systemu.

Oba powyż­sze mode­le to dia­gra­my klas. Większość nie­po­ro­zu­mień ma swo­je źró­dło w myle­niu (nie raz wręcz utoż­sa­mia­niu!) rela­cyj­nych mode­li danych z obiek­to­wy­mi mode­la­mi sys­te­mu (kla­sy­ka tego błę­du to model bazy danych z uży­ciem dia­gra­mu klas UML i nazwa­nie go mode­lem dziedziny).

Podsumowanie

Kończąc ten arty­kuł przy­to­czę kolej­ną tezę z obsza­ru filo­zo­fii informatyki:

Komputer to uni­wer­sal­ny mecha­nizm

W cyto­wa­nej powy­żej książ­ce trak­tu­je o takim podej­ściu do kom­pu­te­ra (w prze­ci­wień­stwie do patrze­nia na nie­go jak na har­dwa­re i softwa­re”) jej ostat­ni roz­dział Komputer jako maszy­na abs­trak­cyj­na.

Czym więc jest tak zwa­ny obiek­to­wy para­dyg­mat pro­gra­mo­wa­nia? Moim zda­niem moż­na to scha­rak­te­ry­zo­wać tak:

Kod pro­gra­mu jest struk­tu­ral­ny, obiek­to­wa jest jego archi­tek­tu­ra.

Dlatego ana­li­za i pro­jek­to­wa­nie to two­rze­nie opi­su (pro­jek­tu) mecha­ni­zmu przy­szłe­go sys­te­mu. Struktura wyra­żo­na np. w nota­cji UML, to archi­tek­tu­ra tego sys­te­mu (obiek­ty mają­ce nazwy, ope­ra­cje i cza­sa­mi dane czy­li pamięć). Jednak meto­dy, czy­li opis ope­ra­cji (zacho­wań obiek­tów), to algo­ryt­my, regu­ły itp. któ­re mogą zostać zre­ali­zo­wa­ne (zaim­ple­men­to­wa­ne) z uży­ciem kom­pu­te­ra, w któ­rym o jego zacho­wa­niu decy­du­je kod pro­gra­mu uru­cha­mia­ne­go w tym kom­pu­te­rze a pro­gra­my to prze­cież algo­ryt­my + dane”. Metody obiek­to­we to podzie­le­nie całe­go struk­tu­ral­ne­go kodu na nie­za­leż­ne (her­me­ty­za­cja) współ­pra­cu­ją­ce ele­men­ty czy­li obiekty.

To dla­te­go pro­ces two­rze­nia kon­struk­cji inży­nier­skich nazy­wa­ny MDA czy MDE to opra­co­wa­nie (ana­li­za i zapro­jek­to­wa­nie) wyma­ga­ne­go mecha­ni­zmu dzia­ła­nia sys­te­mu a potem jego imple­men­ta­cja w wybra­nej tech­no­lo­gii: zegar może być zega­rem mecha­nicz­nym lub elek­tro­nicz­nym ale w obu przy­pad­kach wska­zu­je godzi­nę zgod­nie z opi­sa­nym mechanizmem.

Powszechnym błę­dem jest więc zama­wia­nie” opro­gra­mo­wa­nia meto­dą spe­cy­fi­ko­wa­nia wyma­gań, jako wie­lu przy­pad­ko­wo, lub nawet sys­te­ma­tycz­nie, opi­sa­nych reak­cji na bodź­ce, bez zro­zu­mie­nia mecha­ni­zmu ich powsta­wa­nia. Implementacja tak opi­sa­nych wyma­gań bar­dzo czę­sto jest reali­zo­wa­na jako bar­dzo roz­bu­do­wa­ny sys­tem poka­zu­ją­cy co sekun­dę kolej­ny obraz tar­czy zega­ra zamiast imple­men­ta­cji pro­ste­go mecha­ni­zmu zmie­nia­ją­ce­go poło­że­nie wska­zó­wek na nie­ru­cho­mej tar­czy zega­ra. Większość zna­ne­go mi opro­gra­mo­wa­nia jest bar­dziej zło­żo­na niż mogła by być…

Polecam tak­że Filozofię mate­ma­ty­ki i informatyki:

Prace zebra­ne w niniej­szym tomie obra­zu­ją pro­wa­dzo­ne aktu­al­nie w Polsce bada­nia filo­zo­ficz­ne nad mate­ma­ty­ką i infor­ma­ty­ką. Ich auto­rzy repre­zen­tu­ją róż­ne ośrod­ki aka­de­mic­kie i róż­ne spe­cjal­no­ści ? są wśród nich mate­ma­ty­cy, logi­cy, filo­zo­fo­wie a nawet teo­lo­go­wie.
Artykuły poświę­co­ne są mię­dzy inny­mi bada­niu kla­sycz­nych kie­run­ków filo­zo­fii mate­ma­ty­ki, roz­wa­ża­niom na temat roz­wo­ju i zmian w mate­ma­ty­ce, zna­cze­niu meto­dy aksjo­ma­tycz­nej, pro­ble­mom zwią­za­nym z epi­ste­mo­lo­gią mate­ma­ty­ki i wresz­cie związ­kom mate­ma­ty­ki i infor­ma­ty­ki ze świa­tem realnym. 

Źródła

Żeliński, J. (2017). Architektura kodu apli­ka­cji jako pierw­szy etap two­rze­nia opro­gra­mo­wa­nia. Materiały pokon­fe­ren­cyj­ne III Ogólnopolskiej Konferencji Interdyscyplinarnej Współczesne zasto­so­wa­nia infor­ma­ty­ki”, 6 – 14. https://​www​.wzi​.uph​.edu​.pl/​o​k​i​w​z​i​3​/​w​p​-​c​o​n​t​e​n​t​/​u​p​l​o​a​d​s​/​2​0​1​7​/​0​9​/​2​017 – 08-22 – 22-22.pdf#page=7
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Frege, G. (2014). Pisma seman­tycz­ne (Wydawnictwo Naukowe PWN, Ed.; B. Wolniewicz, Trans.). Wydawnictwo Naukowe PWN.
Miłkowski, M. (2014). Computational Mechanisms and Models of Computation. Philosophia Scientae, 18 – 3, 215 – 228. https://​doi​.org/​1​0​.​4​0​0​0​/​p​h​i​l​o​s​o​p​h​i​a​s​c​i​e​n​t​i​a​e​.​1​019

(czy­taj ciąg dal­szy…)

Inne artykuły na podobny temat

Komentarze

  1. Cezar 6 października 2018 at 12:12

    Jaka jest (jeśli w ogó­le jest) róż­ni­ca pomię­dzy mode­lem dzie­dzi­no­wy­mi a dome­ną mode­lu w kon­tek­ście DDD. Często sa sto­so­wa­ne zamien­nie, acz­kol­wiek w więk­szo­ści publi­ka­cji poja­wia się domena.

    • Jaroslaw Zelinski 6 października 2018 at 12:48

      Tu nie cho­dzi tyl­ko o DDD. Znaczenie poję­cia dzie­dzi­ny” (ang. doma­in) zale­ży od kontekstu:
      1. W kon­tek­ście wzor­ca MVC model dzie­dzi­ny to model struk­tu­ry kom­po­nen­tu Model reali­zu­ją­ce­go logi­kę biz­ne­so­wą (logi­kę dzie­dzi­ny pro­ble­mu), DDD to wzor­ce pro­jek­to­we słu­żą­ce do two­rze­nia mode­lu dzie­dzi­ny w rozu­mie­niu MVC.
      2. w kate­go­riach nazew­nic­twa i mode­li poję­cio­wych (name­spa­ce) dzie­dzi­na” problemu/systemu to słow­nik pojęć, czy­li tak­so­no­mie i syn­tak­ty­ka pojęć danej dzie­dzi­ny pro­ble­mu, tak­że moż­li­we do zobra­zo­wa­nia (nota­cja SBVR dia­gram fak­tów, albo UML dia­gram klas jako model pojęciowy).

      Z per­spek­ty­wy ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (tak­że potem implementacji):
      1. doma­in model to sta­tycz­na struk­tu­ra kom­po­nen­tu Model, reali­zu­ją­ce­go logi­kę dzie­dzi­no­wą (biz­ne­so­wą), doce­lo­wo kod kom­po­nen­tu Model.
      2. doma­in name­spa­ce to słow­nic­two (zbiór pojęć, słow­nik) uży­te do nada­wa­nia nazw kla­som, atry­bu­tom, ope­ra­cjom, enu­me­ra­tyw­nym war­to­ściom atry­bu­tów itp., spe­cy­ficz­ne dla danej dziedziny.

      Tak więc nie nale­ży sto­so­wać pojęć model dzie­dzi­no­wy” ani dome­na mode­lu” a odpo­wied­nio: model dzie­dzi­ny sys­te­mu” (tu Model opi­su­je kom­po­nent sys­te­mu) oraz model poję­cio­wy dzie­dzi­ny sys­te­mu” (tu model to struk­tu­ra pojęć – seman­ty­ka i syn­tak­ty­ka – spe­cy­ficz­na dla danej dziedziny).

  2. Cezar 6 października 2018 at 13:27

    Jeśli dobrze rozu­miem ozna­cza to, iż w 90% miej­scach w sie­ci błęd­nie uży­wa sie sło­wa dome­na zamiast dzie­dzi­na. Cały czas mam na myśli kon­tekst DDD (Domain Driven Design). Wychodzi na to, ze sło­wo ?Domain? powin­no być tłu­ma­czo­ne na język pol­ski jako ?dzie­dzi­na?, a nie ?dome­na?.

    • Jaroslaw Zelinski 6 października 2018 at 16:50

      Słowo doma­in w j.ang. to dzie­dzi­na, dome­na, w j. pol­skim poję­cie dzie­dzi­na o dome­na mają podob­ne znaczenie:

      dome­na
      1. ?zakres zain­te­re­so­wań lub dzia­łal­no­ści jakiejś oso­by, insty­tu­cji lub dzie­dzi­ny wiedzy?
      2. ?ele­ment adre­su inter­ne­to­we­go wska­zu­ją­cy na kraj i rodzaj organizacji?

      ale już”

      dzie­dzi­na ?zakres czy­je­goś dzia­ła­nia w obrę­bie nauki, gospo­dar­ki, tech­ni­ki, kul­tu­ry itp.?

      Kontekst jed­nak jest taki: w opro­gra­mo­wa­niu (kon­kret­ny sys­tem, apli­ka­cja) dzie­dzi­na to okre­ślo­ny obszar zasto­so­wa­nia (sprze­daż, pro­duk­cja, zarzą­dza­nie lota­mi samo­lo­tów pasa­żer­skich, itp.) dla­te­go mamy na myśli obszar dzia­ła­nia” i raczej nale­ży uży­wać poję­cia model dzie­dzi­ny sys­te­mu” a nie «dome­na sys­te­mu”… Dlatego sto­ję po stro­nie tych, któ­rzy w sto­sun­ku do opro­gra­mo­wa­nia uży­wa­ją poję­cia dzie­dzi­ny, bo nie powo­du­je nieporozumień.

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.