Gdybym miał oce­nić sta­ty­stycz­nie dia­gram klas opi­sy­wa­ny w książ­kach o UML , pro­jek­tach jakie widu­ję nie tyl­ko w pra­cach stu­den­tów, to powie­dział bym, że jest jakiś pro­blem z nimi. Dlaczego? Pokaże to, co moim zda­niem jest chy­ba nie tak. Szczególnie jak ktoś uwa­ża, że dia­gram klas do model danych co wprost pro­wa­dzi do antyw­zor­ca obiek­to­we­go o nazwie ane­micz­ny model dzie­dzi­ny ?*?Ten arty­kuł to kon­ty­nu­acja poprzed­nie­go arty­ku­łu o mode­lach dzie­dzi­ny sys­te­mu.

Co można i należy pokazać w wynikach analizy – taksonomia

Przede wszyst­kim ana­li­za to nie pro­jekt, powin­na poka­zać obiek­tyw­ny stan fak­tycz­ny. Druga rzecz, o tym już nie­któ­rzy zapo­mi­na­ją: wyni­kiem ana­li­zy jest doku­men­ta­cja zro­zu­mie­nia, tak więc model ana­li­tycz­ny nie może być mode­lem poka­zu­ją­cym stan po uprosz­cze­niach. To powi­nien być model rze­czy­wi­sto­ści z nanie­sio­ny­mi, zasto­so­wa­ny­mi lokal­nie, ogra­ni­cze­nia­mi i uprosz­cze­nia­mi. Innymi sło­wy: dla fabry­ki spodni budu­je­my kom­plet­ny model czło­wie­ka (mane­kin) z komen­ta­rzem, że tu w uży­ciu jest część od pasa w dół a nie wma­wia­my niko­mu, że w tej fabry­ce czło­wiek skła­da sie wyłącz­nie z bio­der i nóg. W prze­ciw­nym wypad­ku, przy­szła roz­bu­do­wa sys­te­mu będzie co naj­mniej problematyczna.

Produkt ana­li­zy prze­ka­zu­je infor­ma­cję o tym co zasta­no, opi­su­je poję­cia i regu­ły jakie nimi rzą­dzą. Tak na praw­dę, opi­sać fir­mę (orga­ni­za­cję) to zna­czy stwo­rzyć listę pojęć jaki­mi się w niej ope­ru­je (jaki­mi moż­na ją opi­sać) i regu­ły jakie ogra­ni­cza­ją swo­bo­dę uży­cia (funk­cjo­no­wa­nia) tych pojęć. Model poję­cio­wy (ich spe­cy­fi­ka­cja) to seman­ty­ka sys­te­mu, ogra­ni­cze­nia swo­bo­dy ich wza­jem­ne­go koja­rze­nia to syn­tak­ty­ka, i na koniec dzie­dzi­no­we ogra­ni­cze­nie swo­bo­dy ich uży­cia to prag­ma­ty­ka. Wkrada się tu tak­że przy­dat­ne poję­cie jakim jest entro­pia czy­li mia­ra nie­upo­rząd­ko­wa­nia. Tak więc mamy sys­tem pojęć, jego entro­pia (sto­pień nie­upo­rząd­ko­wa­nia) jest ogra­ni­czo­na syn­tak­ty­ką i prag­ma­ty­ką spe­cy­ficz­ną dla dzie­dzi­ny i miej­sca (orga­ni­za­cji). Co to ozna­cza dla ana­li­zy przedwdrożniowej?

Jednym z celów tej ana­li­zy jest odkry­cie i zapi­sa­nie wie­dzy o pod­mio­cie infor­ma­ty­zo­wa­nym”. Jak ją zapi­sać? Ano wła­śnie tak: zbu­do­wać listę pojęć i wska­zać opi­sa­ne ogra­ni­cze­nia. Doskonałym narzę­dziem do tego jest dia­gram klas (odra­dzam dia­gram ERD, moż­na go póź­niej zbu­do­wać w opar­ciu o model poję­cio­wy, jeże­li zaj­dzie taka potrze­ba, ale nie nale­ży tych dwóch mode­li sto­so­wać zamien­nie). Diagram klas opi­su­ją­cy taki sys­tem poję­cio­wy to tak zwa­na prze­strzeń poję­cio­wa (name­spa­ce) . Jak to wygląda:

Diagram klas, taksonomia

Od razu uwa­ga: powyż­szy dia­gram jest nad­mia­ro­wy, w real­nym pro­jek­cie bym tego tak nie nary­so­wał, ale po kolei.???

Podstawowe poję­cia (seman­ty­ka) ana­li­zo­wa­ne­go sys­te­mu to kla­sy ozna­czo­ne nie­bie­skim kolo­rem. Bardzo czę­sto zda­rza się, że pew­ne poję­cia moż­na lub nale­ży pokla­sy­fi­ko­wać, by prze­ka­zać infor­ma­cję o ist­nie­niu tej kla­sy­fi­ka­cji. Diagram ten moż­na wiec uzu­peł­nić na dwa spo­so­by: sto­su­jąc tak zwa­ne super­kla­sy (uogól­nie­nie, zebra­nie kil­ku wspól­nych cech) oraz tak zwa­ne ste­reo­ty­py, czy­li zna­cząc dodat­ko­wo kla­sy. Klasa uogól­nia­na nazy­wa­na jest spe­cja­li­za­cją. Na powyż­szym dia­gra­mie Zamówienie (spe­cja­li­za­cja) jest spe­cy­ficz­nym rodza­jem Dokumentu (uogól­nie­nie) a każ­dy doku­ment to coś będą­ce­go jakąś tre­ścią np. na papie­rze. Zamówienie jed­nak jest tak­że «obiek­tem biz­ne­so­wym», utrwa­lo­nym i zro­zu­mia­łym poję­ciem (bytem) w fir­mie, do cze­goś kon­kret­ne­go służy.

Jest pew­na seman­tycz­na róż­ni­ca pomię­dzy super-kla­są a ste­reo­ty­pem, gdyż uwa­żam, że tych pojęć nie moż­na sto­so­wać zamien­nie. Super-kla­sa poka­zu­je, że pew­ne byty są uogól­nia­ne (mają one jakieś wspól­ne cechy zebra­ne w tym uogól­nie­niu) i uogól­nie­nie to – jako poję­cie – jest sto­so­wa­ne w roz­mo­wie”. Stereotyp wska­zu­je na pew­ne ist­nie­ją­ce i istot­ne (chce­my to zako­mu­ni­ko­wać w doku­men­ta­cji) roz­róż­nie­nie pomię­dzy poję­cia­mi jed­nak nie jest ono sto­so­wa­ne w roz­mo­wie”. Można więc uznać, że poję­cie Dokument funk­cjo­nu­je w roz­mo­wie” na rów­ni z poję­ciem Zamówienie choć jest to poję­cie (Dokument) abs­trak­cyj­ne. Nie ist­nie­je coś takie­go jak ogól­ny doku­ment” ale poję­cie to jest powszech­nie sto­so­wa­ne w fir­mach, abs­trak­cje takie ozna­cza­my pisząc nazwę takiej kla­sy kur­sy­wą. Można tak­że powie­dzieć, że Zamówienie jest «obiek­tem biz­ne­so­wym» (coś istot­ne­go, uży­wa­ne­go) jed­nak raczej nikt nie uży­wa tego poję­cia na co dzień. Ten ste­reo­typ infor­mu­je czy­tel­ni­ka ana­li­zy, że to coś istot­ne­go (jakimś kontekście).

Wpłata jest zda­rze­niem, jed­nak zda­rze­nie to coś, co na co dzień nie jest trak­to­wa­ne jako rów­no­praw­ne sło­wo” w biz­ne­sie. Dlatego w tym przy­pad­ku w mode­lu użył­bym tyl­ko ste­reo­ty­pu «zda­rze­nie», by wska­zać, że jest to coś inne­go niż «obiekt biz­ne­so­wy» ale już nie użył bym, abs­trak­cyj­nej super­kla­sy Zdarzenie. Jeżeli jed­nak w toku pro­jek­to­wa­nia (etap po ana­li­zie) uzna­my, że chce­my prze­twa­rzać dane o tych zda­rze­niach zapro­jek­tu­je­my dla sys­te­mu kla­sę Zdarzenie.

Obiektem biz­ne­so­wym jest jed­nak Dowód Wpłaty (tak na praw­dę repre­zen­tu­je on to zda­rze­nie ale nie jest to toż­sa­me poję­cie: stwier­dze­nie wpła­ty nie jest dowo­dem wpła­ty). Te niu­an­se są bar­dziej oczy­wi­ste (mam nadzie­ję :)) na przy­kła­dzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu tak­że ewi­dent­nie, że Klient jest wyłącz­nie Osobą.

Diagram ten zawie­ra tak­że pew­ne regu­ły biz­ne­so­we (ogra­ni­cze­nia entro­pii, czy­li swo­bo­dy). Są to liczeb­no­ści nanie­sio­ne na sko­ja­rze­nia (aso­cja­cje), linie łączą­ce kla­sy. Zaznaczono np. że Sprzedawca może mieć pod opie­ką klien­tów, tak­że żad­ne­go, jed­nak klient musi mieć i tyl­ko jed­ne­go opie­ku­na. Brak linii łączą­cej dwie kla­sy świad­czy zaś o tym, że nie ogra­ni­cza­ją się one nawza­jem w żaden spo­sób np. Wpłaty w żaden spo­sób nie wpły­wa­ją na Sprzedawcę i odwrot­nie. Istnieje jedy­nie pośred­ni zwią­zek mówią­cy, że moż­na sko­ja­rzyć Wpłatę ze Sprzedawcą, ele­men­tem koja­rzą­cym jest Faktura i jest ona tak­że kon­tek­stem tego sko­ja­rze­nia: Faktura jest pro­duk­tem pro­ce­su Sprzedaży, za któ­ry odpo­wia­da Sprzedawca. To jest powód, dla któ­re­go model pro­ce­sów powi­nien tak­że powstać jako jeden z pro­duk­tów takiej ana­li­zy bo to on zawie­ra tę wła­śnie informację.

Model dziedziny to model mechanizmu działania

A teraz model dzie­dzi­ny, przy­to­czę dia­gram uży­ty w poprzed­nim artykule:

Diagram klas, model dziedziny systemu

Jak widać jest pomię­dzy nimi istot­na róż­ni­ca. Jej źró­dłem jest to, że tak­so­no­mia to model poję­cio­wy zaś model dzie­dzi­ny (w rozu­mie­niu Model z wzor­ca MVC) to opis prze­twa­rza­nia. Przede wszyst­kim model dzie­dzi­ny nie zawie­ra pojęć abs­trak­cyj­nych. Dlaczego? No bo ich nie zapi­su­je­my i nie prze­twa­rza­my :)! Po dru­gie pew­ne poję­cia znik­nę­ły z mode­lu (Klient, jest akto­rem) bo Klient nie jest prze­twa­rza­ny, ale dane klien­ta będą atry­bu­ta­mi (nie zazna­czo­no) Zamówienia: jest on tu, Klient, zama­wia­ją­cym. Czytaj wię­cej o two­rze­niu i testo­wa­niu mode­lu dzie­dzi­ny.

Tak więc war­to zwró­cić uwa­gę na to, że dia­gram klas dia­gra­mo­wi nie rów­ny, to samo narzę­dzie może posłu­żyć do dwóch róż­nych celów w tej samej doku­men­ta­cji. Widać tak­że (mam nadzie­ję), że pró­ba poka­za­nia na jed­nym dia­gra­mie zarów­no sys­te­mu pojęć jak i spo­so­bu ich prze­twa­rza­nia, jako infor­ma­cji w sys­te­mach infor­ma­tycz­nych, jest raczej błęd­nym podej­ściem. Wydaje mi się, że podej­mo­wa­nie takich prób świad­czy o nie­zro­zu­mie­niu róż­ni­cy pomię­dzy sys­te­mem poję­cio­wym a mode­lem prze­twa­rza­nia infor­ma­cji. W szcze­gól­no­ści gdy doty­czy to sys­te­mów obiektowych.

C++, Java i podobne języki

Paradygmat obiek­to­wy to her­me­ty­za­cja i komu­ni­ka­cja, a nie dzie­dzi­cze­nie i łącze­nie danych i funk­cji w obiek­ty”. C++/C# czy Java nie są repre­zen­ta­cją obiek­to­we­go para­dyg­ma­tu i nio­są ze sobą nara­sta­ją­cy dług technologiczny:

Popatrzmy tak­że na to:

W tym fil­mie przed­sta­wia­my nie­któ­re z tech­nik sto­so­wa­nych przez auto­rów kom­pi­la­to­rów w celu osią­gnię­cia mecha­ni­zmów języ­ków obiek­to­wych. Ciekawie jest zoba­czyć, jak bli­sko C++ jest do C i jak pro­ste są te mecha­ni­zmy pod maską. Chociaż film kon­cen­tru­je się na C++, podob­ne tech­ni­ki są sto­so­wa­ne przez wir­tu­al­ną maszy­nę Javy, wir­tu­al­ną maszy­nę .Net w C# i wie­le innych języ­ków OO.

https://​youtu​.be/​H​C​l​S​f​u​T​2​b​F​A​?​s​i​=​b​5​W​7​d​L​O​k​j​R​T​P​L​Gbf

Od pew­ne­go cza­su [2024] sły­szę od dewe­lo­pe­rów: Teraz w Javie kró­lu­je Spring. Słyszał pan o nim? Jestem cie­kaw opinii

Tak, sły­sza­łem:

The Spring Framework is an appli­ca­tion fra­me­work and inver­sion of con­trol con­ta­iner for the Java platform.[2] The fra­me­wor­k’s core featu­res can be used by any Java appli­ca­tion, but the­re are exten­sions for buil­ding web appli­ca­tions on top of the Java EE (Enterprise Edition) plat­form. The fra­me­work does not impo­se any spe­ci­fic pro­gram­ming model.[citation needed]. The fra­me­work has beco­me popu­lar in the Java com­mu­ni­ty as an addi­tion to the Enterprise JavaBeans (EJB) model.[3] The Spring Framework is free and open sour­ce software.[4]: 121 – 122 [5]”

[https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​p​r​i​n​g​_​F​r​a​m​e​w​ork]

Czym jest Enterprise JavaBeans (EJB) model?

Java Beans, As part of the stan­dar­di­za­tion, all beans must be seria­li­za­ble, have a zero-argu­ment con­struc­tor, and allow access to pro­per­ties using get­ter and set­ter methods.” 

[https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​J​a​v​a​B​e​ans]

To oce­nia­ne jako naj­gor­sze meto­dy w posta­ci access to pro­per­ties using get­ter and set­ter methods”.

Every get­ter and set­ter in your code repre­sents a failu­re to encap­su­la­te and cre­ates unne­ces­sa­ry coupling. A pro­fu­sion of get­ters and set­ters (also refer­red to as acces­sors, acces­sor methods, and pro­per­ties) is a sign of a poor­ly-desi­gned set of classes.”

[https://​typi​cal​pro​gram​mer​.com/​d​o​i​n​g​-​i​t​-​w​r​o​n​g​-​g​e​t​t​e​r​s​-​a​n​d​-​s​e​t​t​ers]

(patrz tak­że: https://​www​.info​world​.com/​a​r​t​i​c​l​e​/​2​0​7​3​7​2​3​/​w​h​y​-​g​e​t​t​e​r​-​a​n​d​-​s​e​t​t​e​r​-​m​e​t​h​o​d​s​-​a​r​e​-​e​v​i​l​.​h​tml)

Anemiczny model dzie­dzi­ny (ang. Anemic Domain Model): Antywzorzec opi­sa­ny przez Martina Fowlera. W tym przy­pad­ku model dzie­dzi­ny skła­da się z klas z atry­bu­ta­mi bez metod, nie jest więc obiek­to­wy. Logika biz­ne­so­wa prze­nie­sio­na jest do innych klas, któ­re trans­for­mu­ją kla­sy dzie­dzi­ny zmie­nia­jąc ich stan (stąd nazwa Fowlera: skryp­ty trans­ak­cyj­ne). Antywzorzec ten przed­mio­tem wie­lu dys­ku­sji – znacz­na część meto­dyk two­rze­nia opro­gra­mo­wa­nia w Javie (w tym EJB) ope­ru­je na takim mode­lu. Duża część pro­jek­tan­tów prze­no­si też swo­je przy­zwy­cza­je­nia z mode­lo­wa­nia baz danych mode­lu­jąc sys­tem w ten sposób.” 

https://​pl​.wiki​pe​dia​.org/​w​i​k​i​/​A​n​t​y​w​z​o​r​z​e​c​_​p​r​o​j​e​k​t​owy

znacz­na część meto­dyk two­rze­nia opro­gra­mo­wa­nia w Javie (w tym EJB) ope­ru­je na takim mode­lu (patrz https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​A​n​e​m​i​c​D​o​m​a​i​n​M​o​d​e​l​.​h​tml, pro­gra­mi­stom pole­cam tak­że te stro­ny). Warto też pamię­tać, że w 2015 roku zmie­ni­ła się spe­cy­fi­ka­cja UML, usu­nię­to poję­cie dzie­dzi­cze­nia i agre­ga­cji, suge­ru­ję uzu­peł­nić wie­dzę wpi­sa­mi na blo­gu, któ­re powsta­ły po 2015 roku.

Źródła

Zelinski, J. (2020) Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns’, in Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. IGI Global, pp. 78 – 89. Available at: https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699 (Accessed: 18 December 2019).
Fowler, M. (1997) Analysis pat­terns: reu­sa­ble object models. Menlo Park, Calif: Addison Wesley (The Addison-Wesley series in object-orien­ted softwa­re engineering).
Usman, M. et al. (2017) Taxonomies in softwa­re engi­ne­ering: A Systematic map­ping stu­dy and a revi­sed taxo­no­my deve­lop­ment method’, Information and Software Technology, 85, pp. 43 – 59. Available at: https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​1​7​.​0​1​.​006.
Stevens, P. (2007) UML Inżynieria opro­gra­mo­wa­nia. Translated by I. Jakóbik. Gliwice: Helion.
Booch, G., Rumbaugh, J. and Jacobson, I. (2002) UML prze­wod­nik użyt­kow­ni­ka. dru­gie wyda­nie. Warszawa: WNT (inży­nie­ria oprogramowania).

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

  1. Czyli tak­so­no­mię (nie­bie­skie) przy­go­to­wu­je­my na wcze­snym eta­pie i zatwier­dza­my z zama­wia­ją­cym, a model dzie­dzi­ny (żół­te) przy­go­to­wu­je­my dla sie­bie (nie poka­zu­je­my klien­to­wi, ale prze­ka­zu­je­my zespo­ło­wi wykonawców)?

    1. Jarek Żeliński

      mniej wię­cej, cho­ciaż coraz czę­ściej zastę­pu­ję tak­so­no­mię w posta­ci dia­gra­mu klas, sfor­ma­li­zo­wa­nym słow­ni­kiem poję­cio­wym i spe­cy­fi­ka­cją reguł biz­ne­so­wych, spraw­dza się znacz­nie lepiej (to klient powi­nien ze zro­zu­mie­niem zatwier­dzić, dia­gram klas tu nie­ste­ty nie jest łatwy dla biz­ne­su), z tego klient potra­fi korzy­stać (np. upo­rząd­ko­wa­nie zarzą­dzeń wewnętrz­nych otp..) http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les

  2. Piotrek

    Z jakich rela­cji nale­ży korzy­stać przy budo­wa­niu mode­lu poję­cio­wym (tak­so­no­mii)? Na przed­sta­wio­nym sche­ma­cie są tyl­ko aso­cja­cje i uogól­nie­nia. Czy zazna­cza­nie na tym eta­pie kom­po­zy­cji czy agre­ga­cji jest zasadne?
    I dru­ga spra­wa – na ile głę­bo­ko scho­dzić na eta­pie mode­lu poję­cio­we­go. Przykład: zarów­no Zamówienie jak i Faktura skła­da się z pozy­cji. Na poda­nym przy­kła­dzie zosta­ło to pomi­nię­te. Pytanie czy celo­wo czy dla uproszczenia?

    1. Jarek Żeliński

      Model poję­cio­wy to nic inne­go jak słow­ni­ko­we podej­ście do tema­tu” podob­ne do pod­ręcz­ni­ko­wej kla­sy­fi­ka­cji roślin czy psów. Stosując dia­gram klas do tego, nale­ży się wystrze­gać cho­ro­by rela­cyj­nej” czy­li trak­to­wa­nia pojęć (klas) jak encji (tabel) na dia­gra­mach baz danych (ERD) bo mają tu one zupeł­nie inny sens. Przedstawiony przy­kład poka­zu­je wyłącz­nie logi­kę poję­cio­wą więc Faktura jest jakoś” powią­za­na logicz­nie z Zamówieniem. Ale! Tu (model poję­cio­wy) Faktura i Zamówienie to nie doku­men­ty” z ich tre­ścią, a poję­cia np. Faktura do doku­ment, który…”.

      Głębokość uszcze­gó­ło­wie­nia. Więc wyja­śni­ło się jed­no: na mode­lu poję­cio­wym Faktura to zde­fi­nio­wa­ne poję­cie – ter­min, więc nie ma żad­nych pozy­cji fak­tu­ry itp. Można zde­fi­nio­wać poję­cie pro­dukt” itp. ale wte­dy dia­gram klas jako model poję­cio­wy (chcąc poka­zać każ­dy zwią­zek logicz­ny) sta­nie się nie­czy­tel­nym tale­rzem spa­get­ti” albo będzie nie­kom­plet­ny (w zasa­dzie w biz­ne­sie wszyst­kie poję­cia jakoś się ze sobą wią­żą). Dlatego od jakie­goś cza­su dia­gra­mu klas nie uży­wam do mode­lo­wa­nia sys­te­mu pojęć, poprze­sta­jąc na słow­ni­ku pojęć i spe­cy­fi­ka­cji doku­men­tów (obiek­tów biz­ne­so­wych). Diagramów klas uży­wam wyłącz­nie do mode­lo­wa­nia dzie­dzi­ny sty­lem opi­sa­nym jako DDD, cza­sa­mi do zobra­zo­wa­nia metamodeli.

  3. MikeR

    Mam pyta­nie ponie­waż w książ­ce B. Bruegge i A.H. Duttoit Inżynieria opro­gra­mo­wa­nia w uję­ciu obiek­to­wym” auto­rzy wspo­mi­na­ją o mode­lach dzie­dzi­ny apli­ka­cyj­nej i reali­za­cyj­nej. Na stro­nie 40 piszą, że: Istotą podej­ścia zorien­to­wa­ne­go obiek­to­wo jest połą­cze­nie mode­li obu dzie­dzin(…)”. Czy zatem wspo­mnia­ny w tym arty­ku­le (i innych arty­ku­łach na tym blo­gu) model dzie­dzi­ny mamy utoż­sa­miać z oby­dwo­ma mode­la­mi ze wspo­mnia­ne­go opracowania?

    1. Jaroslaw Zelinski

      Hm… dobre pyta­nie… Generalnie mamy model logi­ki sys­te­mu” czy­li jego mecha­nizm dzia­ła­nia”. Myślę, że inten­cją auto­ra było oddziel­nie logi­ki sys­te­mu” od logi­ki inte­rak­cji z nim”. Jeżeli tak, to odpo­wia­da temu wzo­rzec MVC-MV-VM. Model dzie­dzi­ny to taki e„prawa fizy­ki w tym sys­te­mie”. To pod­sta­wa jego dzia­ła­nia. Ale już model” inte­rak­cji z apli­ka­cją na kom­pu­te­rze a model inte­rak­cji na smart­fo­nie mają swo­ją specyfikę.

    2. MikeR

      Dzięki za info. Teraz jest to dla mnie bar­dziej jasne.

Dodaj komentarz

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