Separacja kon­tek­stu dzie­dzi­ny oraz sepa­ra­cja syno­ni­mów jako meto­da zapew­nie­nia jed­no­znacz­no­ści mode­li obiektowych. 

Streszczenie: Przedstawiono meto­dę pozwa­la­ją­cą zapew­nić jed­no­znacz­ność mode­li obiek­to­wych mimo ist­nie­nia syno­ni­mów w słow­nic­twie ana­li­zo­wa­ne­go pro­ble­mu. Wykorzystano zna­ną juz meto­dę sepa­ro­wa­nia kon­tek­stów, autor pro­po­nu­je dodat­ko­wy pro­sty meta­mo­del (pro­fil UML) pozwa­la­ją­cy na bez­piecz­ne uży­cie tego same­go poję­cia zarów­no jako nazwy obiek­tu jak i nazwy cechy obiektu.

Słowa klu­czo­we: UML, pro­fil, meto­dy obiek­to­we, kontekst 

___

Wprowadzenie

Wielu auto­rów piszą­cych o pro­jek­to­wa­niu opro­gra­mo­wa­nia zwra­ca uwa­gę na pro­ble­my zwią­za­ne z kon­tek­stem i syno­ni­ma­mi pojęć w bada­nej dzie­dzi­nie. Jednym z popu­lar­niej­szych auto­rów, zwra­ca­ją­cych uwa­gę na to, jest Martin Fowler, autor zna­ny mię­dzy inny­mi z książ­ki o wzor­cach pro­jek­to­wych w pro­gra­mo­wa­niu obiek­to­wym . Fowler opi­sał ten pro­blem na swo­jej stro­nie inter­ne­to­wej (FOWLER 2014).

W arty­ku­le na swo­im blo­gu Fowler opi­sał przy­czy­nę i kon­se­kwen­cje, zwró­cił uwa­gę na koniecz­ność sepa­ro­wa­nia kon­tek­stów w pro­ce­sie pro­jek­to­wa­nia opro­gra­mo­wa­nia, a kon­kret­nie tak zwa­ne­go mode­lu dzie­dzi­ny, czy­li kom­po­nen­tu odpo­wie­dzial­ne­go za reali­za­cję logi­ki dzie­dzi­no­wej (zwa­nej tak­że logi­ką biz­ne­so­wą), jed­nak nie opi­sał rozwiązania.

Autor w tej pra­cy pro­po­nu­je meto­dę roz­wią­zy­wa­nia takich pro­ble­mów opar­tą na mata­mo­de­lu roz­dzie­la­ją­cym kon­tekst zarów­no dzie­dzi­no­wy jak i zna­cze­nio­wy prze­twa­rza­nych informacji.

Metody

Do opi­sa­nia i roz­wią­za­nia pro­ble­mu wyko­rzy­sta­no ana­li­zę poję­cio­wą. Modele poję­cio­we, opi­su­ją­ce w posta­ci gra­ficz­nej struk­tu­ry pojęć, ich klas i ich wza­jem­ne związ­ki, zosta­ły zobra­zo­wa­ne z uży­ciem tak zwa­ne­go dia­gra­mu fak­tów nota­cji SBVR (SBVR, jest to dia­gram klas UML ogra­ni­czo­ny do związ­ków poję­cio­wych gene­ra­li­za­cji i nazwa­nej kon­tek­sto­wej asocjacji).

Z uwa­gi na popu­lar­ną w inży­nie­rii opro­gra­mo­wa­nia nota­cję UML (UML), sta­no­wią­cą stan­dard de fac­to w inży­nie­rii opro­gra­mo­wa­nia, zosta­ła ona wyko­rzy­sta­nia do zapre­zen­to­wa­nia efek­tów prac na sche­ma­tach blo­ko­wych opi­su­ją­cych struk­tu­ry infor­ma­cji i oprogramowania.

Język definicje i znaczenia

Na począ­tek kil­ka defi­ni­cji ogól­nych (wszyst­kie sł. j. pol­skie­go PWN):

język: utrwa­lo­ny spo­łecz­nie zespół zna­ków doty­czą­cych jakichś dzia­łań czło­wie­ka lub wyra­ża­ją­cych jego emo­cje oraz każ­dy układ ele­men­tów rze­czy­wi­sto­ści, któ­re­mu czło­wiek nadał jakąś treść

Język jest więc okre­ślo­nym zespo­łem norm, są nimi jed­nak nie tyl­ko zna­ki ale tak­że to, co zna­czą i jaką treść nio­są. Wyrażanie emo­cji czy myśli w ogó­le, rzad­ko jest moż­li­we z uży­ciem tyl­ko jed­ne­go zna­ku. Dlatego w toku ich wyra­ża­nia ope­ru­je­my raczej zdaniami:

zda­nie: log. sen­sow­ne wyra­że­nie oznaj­mia­ją­ce pod­le­ga­ją­ce falsyfikacji

Tu zaczy­na­my powo­li iść w porząd­ko­wa­nie tego o czym piszę. Każde zda­nie (w logi­ce) może być praw­dzi­we lub nie (tau­to­lo­gia jest zda­niem zawsze praw­dzi­wym, czy­li jest zna­ny fakt je fal­sy­fi­ku­ją­cy ale wie­my, że nigdy taki nie wystą­pi). Jeżeli więc, że treść naj­czę­ściej wyra­ża­my sło­wa­mi (a raczej rzad­ko nie jed­nym sło­wem) to zna­czy, że nale­ży umieć odczy­tać zna­cze­nie zło­że­nia wie­lu słów w jed­nym zda­niu. Jak wie­my o zro­zu­mia­ło­ści (zro­zu­mia­łość ozna­cza, że zda­nie ma dla czy­ta­ją­ce­go okre­ślo­ne zna­cze­nie) decy­du­je układ słów w zda­niu, zna­ki inter­punk­cyj­ne itp.

Jednoznaczność (zro­zu­mia­łość, zna­cze­nie) zdań jest tak­że efek­tem kontekstu:

kon­tekst: frag­ment tek­stu potrzeb­ny do dokład­ne­go rozu­mie­nia danych wyra­zów lub wyrażeń

Jeżeli napi­szę ?Te dwie kro­wy są paskud­ne? to nadal nie ma pew­no­ści o czym mowa. Bez wie­dzy o tym, czy to roz­mo­wa dwóch rol­ni­ków o inwen­ta­rzu, czy też dwóch kole­ża­nek o dwóch innych, nie wie­my .

Kluczowe pojęcia

Diagram: Kluczowe pojęcia

Opracowano model pojęciowy. Model ten pozwala uporządkować nazewnictwo wykorzystane do klasyfikacji obiektów w systemach.
        Oprogramowanie to system przetwarzający dane, te mogą nieść określone informacje. Dane to zapisane znaki (wartości), służą do stworzenia opisu (description), ten zaś niesie informacje. Treść to to, co te znaki (dane) znaczą czyli to co rozumie człowiek. W oprogramowaniu dane są organizowane w określone struktury, które jako opis opisują określony fakt (fact) lub podmiot (subject). Opis to określony zestaw atrybutów i ich wartości. Znaczenie atrybutu nadaje mu kontekst.
        Kluczowym ustaleniem jest tu pojęcie dokument (document) jako nazwana struktura zawierająca opis lub opisy. Oprogramowanie przechowuje dokumenty i przetwarza ich treść.
Diagram: Kluczowe pojęcia

Opracowano model poję­cio­wy. Model ten pozwa­la upo­rząd­ko­wać nazew­nic­two wyko­rzy­sta­ne do kla­sy­fi­ka­cji obiek­tów w systemach.

Oprogramowanie to sys­tem prze­twa­rza­ją­cy dane, te mogą nieść okre­ślo­ne infor­ma­cje. Dane to zapi­sa­ne zna­ki (war­to­ści), słu­żą do stwo­rze­nia opi­su (descrip­tion), ten zaś nie­sie infor­ma­cje. Treść to to, co te zna­ki (dane) zna­czą czy­li to co rozu­mie czło­wiek. W opro­gra­mo­wa­niu dane są orga­ni­zo­wa­ne w okre­ślo­ne struk­tu­ry, któ­re jako opis opi­su­ją okre­ślo­ny fakt (fact) lub pod­miot (sub­ject). Opis to okre­ślo­ny zestaw atry­bu­tów i ich war­to­ści. Znaczenie atry­bu­tu nada­je mu kontekst.

Kluczowym usta­le­niem jest tu poję­cie doku­ment (docu­ment) jako nazwa­na struk­tu­ra zawie­ra­ją­ca opis lub opi­sy. Oprogramowanie prze­cho­wu­je doku­men­ty i prze­twa­rza ich treść.

Profil UML

Diagram: Profil UML

Profilowanie w notacji UML to metoda pozwalająca rozszerzyć metaklasy notacji UML w celu dostosowania ich do różnych celów. Obejmuje ono możliwość dostosowania metamodelu UML dla różnych platform (takich jak J2EE lub .NET) lub domen (takich jak architektura czasu rzeczywistego lub architektura zorientowana na usługi) (patrz UML).
        W tym przypadku stworzono zestaw stereotypów (metaklas) pozwalających dodatkowo klasyfikować elementy na modelach UML, nadając im określony kontekst i znaczenie. Użyto tu nazw opisanych powyżej w części Kluczowe pojęcia. Package i class to pojęcia z notacji UML oznaczające określone elementy na diagramach.
Diagram: Profil UML

Profilowanie w nota­cji UML to meto­da pozwa­la­ją­ca roz­sze­rzyć meta­kla­sy nota­cji UML w celu dosto­so­wa­nia ich do róż­nych celów. Obejmuje ono moż­li­wość dosto­so­wa­nia meta­mo­de­lu UML dla róż­nych plat­form (takich jak J2EE lub .NET) lub domen (takich jak archi­tek­tu­ra cza­su rze­czy­wi­ste­go lub archi­tek­tu­ra zorien­to­wa­na na usłu­gi) (patrz UML).

W tym przy­pad­ku stwo­rzo­no zestaw ste­reo­ty­pów (typów klas) pozwa­la­ją­cych dodat­ko­wo kla­sy­fi­ko­wać ele­men­ty na mode­lach UML, nada­jąc im okre­ślo­ny kon­tekst i zna­cze­nie. Użyto tu nazw opi­sa­nych powy­żej w czę­ści Kluczowe poję­cia. Package i class to poję­cia z nota­cji UML ozna­cza­ją­ce okre­ślo­ne ele­men­ty na diagramach.

Rezultaty

Efektem prac jest meto­da mode­lo­wa­nia struk­tur doku­men­tów (infor­ma­cji) w spo­sób pozwa­la­ją­cy prze­twa­rzać je w łatwy do inter­pre­ta­cji spo­sób, dzie­ląc doku­ment na spój­ne kon­tek­sto­we sek­cje lub kla­sy­fi­ku­jąc cały doku­ment jako jed­ną kon­tek­sto­wą sekcję.

Dokument i jego struktura

Diagram: Dokument

Istotą strukturyzacji kontekstowej jest rozwiązywanie problemów jakie stwarzają interpretacje zależne od dziedziny i kontekstu. Jak już napisano, Dokument i jego ewentualne sekcje niosą dane, te podlegają interpretacji zależnej od kontaktu. Kontekst ma tu dwa poziomy: znaczenie pojęć, zgodnie z semiotyką, nadaje im dziedzina zaś znaczenie pojęcia w rozumieniu jest ono nazwą obiektu lub jego atrybutu, nadaje mi położenie w strukturze.
Diagram: Dokument i jego struktura

Istotą struk­tu­ry­za­cji kon­tek­sto­wej jest roz­wią­zy­wa­nie pro­ble­mów jakie stwa­rza­ją inter­pre­ta­cje zależ­ne od dzie­dzi­ny i kon­tek­stu. Jak już napi­sa­no, Dokument i jego ewen­tu­al­ne sek­cje nio­są dane, te pod­le­ga­ją inter­pre­ta­cji zależ­nej od kon­tak­tu. Kontekst ma tu dwa pozio­my: zna­cze­nie pojęć, zgod­nie z semio­ty­ką, nada­je im dzie­dzi­na zaś zna­cze­nie poję­cia w rozu­mie­niu jest ono nazwą obiek­tu lub jego atry­bu­tu, nada­je mi poło­że­nie w strukturze.

Fowler Problem zmiany kontekstu

Diagram: Problem granicy kontekstu Fowlera

Fowler pisze na swoim blogu: "Podczas próby modelowania większej domeny coraz trudniej jest zbudować pojedynczy zunifikowany model. Różne grupy ludzi będą używać subtelnie różnych słowników w różnych częściach dużej organizacji. Brak precyzji modelowania szybko prowadzi do wielu nieporozumień. Zazwyczaj to zamieszanie koncentruje się na kluczowych pojęciach danej domeny. Na początku mojej kariery pracowałem w branży narzędzi elektrycznych - tutaj słowo ?licznik? oznaczało różne rzeczy w różnych obszarach organizacji: raz było to połączenie między siecią a lokalizacją, raz siecią i klientem, innym razem było konkretnym miernikiem fizycznym (wymienianym w razie uszkodzenia). Te subtelne różnice znaczeń nie szkodzą w rozmowie, ale w precyzyjnym świecie programów komputerów tak. Raz po raz widzę, że to zamieszanie powtarza się w przypadku problemów z pojęciami ?Klient? i ?Produkt?."
        Opis ten i powyższy schemat, zawierający skojarzone z sobą pojęcia, są typowym przykładem problemu zapisu informacji z wielu dziedzin. Po lewej stronie mamy kontekst sprzedaży produktów po prawej kontakt obsługi zgłoszeń uszkodzeń. Problematyczne pojęcia to Klient (Customer) i Produkt (Product) oraz Zgłoszenie (Ticket): w obu kontekstach mają inne znaczenie: w kontekście sprzedaży Klient i produkt to odrębne, mające tożsamość obiekty, w kontekście zgłoszeń uszkodzeń obiektem jest Zgłoszenie (Ticket) a Klient i Produkt sa wartościami atrybutów Zgłoszenia. W tym drugim przypadku są to nie mające tożsamości wartości atrybutów ("Value objects, wartość, patrz EVANS, UML). W konsekwencji nie jest możliwe umieszczenie tych danych w jednej relacynej bazie danych.
        Fowler wskazuje jako rozwiązanie rozdzielenie tych dwóch, stanowiących różne konteksty, obszarów dziedzinowych, jednak nie opisuje tego rozwiązania.
Diagram: Fowler Problem zmia­ny kontekstu

Fowler pisze na swo­im blo­gu: Podczas pró­by mode­lo­wa­nia więk­szej dome­ny coraz trud­niej jest zbu­do­wać poje­dyn­czy zuni­fi­ko­wa­ny model. Różne gru­py ludzi będą uży­wać sub­tel­nie róż­nych słow­ni­ków w róż­nych czę­ściach dużej orga­ni­za­cji. Brak pre­cy­zji mode­lo­wa­nia szyb­ko pro­wa­dzi do wie­lu nie­po­ro­zu­mień. Zazwyczaj to zamie­sza­nie kon­cen­tru­je się na klu­czo­wych poję­ciach danej dome­ny. Na począt­ku mojej karie­ry pra­co­wa­łem w bran­ży narzę­dzi elek­trycz­nych – tutaj sło­wo ?licz­nik? ozna­cza­ło róż­ne rze­czy w róż­nych obsza­rach orga­ni­za­cji: raz było to połą­cze­nie mię­dzy sie­cią a loka­li­za­cją, raz sie­cią i klien­tem, innym razem było kon­kret­nym mier­ni­kiem fizycz­nym (wymie­nia­nym w razie uszko­dze­nia). Te sub­tel­ne róż­ni­ce zna­czeń nie szko­dzą w roz­mo­wie, ale w pre­cy­zyj­nym świe­cie pro­gra­mów kom­pu­te­rów tak. Raz po raz widzę, że to zamie­sza­nie powta­rza się w przy­pad­ku pro­ble­mów z poję­cia­mi ?Klient? i ?Produkt?.”

Opis ten i powyż­szy sche­mat, zawie­ra­ją­cy sko­ja­rzo­ne z sobą poję­cia, są typo­wym przy­kła­dem pro­ble­mu zapi­su infor­ma­cji z wie­lu dzie­dzin. Po lewej stro­nie mamy kon­tekst sprze­da­ży pro­duk­tów po pra­wej kon­takt obsłu­gi zgło­szeń uszko­dzeń. Problematyczne poję­cia to Klient (Customer) i Produkt (Product) oraz Zgłoszenie (Ticket): w obu kon­tek­stach mają inne zna­cze­nie: w kon­tek­ście sprze­da­ży Klient i pro­dukt to odręb­ne, mają­ce toż­sa­mość obiek­ty, w kon­tek­ście zgło­szeń uszko­dzeń obiek­tem jest Zgłoszenie (Ticket) a Klient i Produkt sa war­to­ścia­mi atry­bu­tów Zgłoszenia. W tym dru­gim przy­pad­ku są to nie mają­ce toż­sa­mo­ści war­to­ści atry­bu­tów nazy­wa­ne Value Object . W kon­se­kwen­cji nie jest moż­li­we umiesz­cze­nie tych danych w jed­nej rela­cyj­nej bazie danych.

Fowler wska­zu­je jako roz­wią­za­nie roz­dzie­le­nie tych dwóch, sta­no­wią­cych róż­ne kon­tek­sty, obsza­rów dzie­dzi­no­wych, jed­nak nie opi­su­je tego roz­wią­za­nia. Inna cie­ka­wa for­ma zobra­zo­wa­nia problemu:

Jeden model dwa konteksty

Diagram: Jeden model dwa konteksty

Diagram przedstawia obiekty biznesowe - dokumenty (<<document>>) pochodzące z dwóch różnych kontaktów. Na schemacie mamy trzy klasyfikatory reprezentujące dokumenty i ich struktury. W celu usunięcia kolizji pojęć opisanej przez Fowlera (FOWLER 2014) obiekty funkcjonujące w dwóch różnych kontaktach zostały rozdzielone na dwie kontekstowe przestrzenie pojęciowe: Sprzedaż oraz Serwis. W kontekście Sprzedaż pojęcia Klient i Produkt zostały użyte do nazwania obiektów biznesowych będących przedmiotami mającymi tożsamość. W kontekście Serwis pojęcia te (klient i produkt) ca jedynie cechami (atrybutami) obiektu biznesowego Uszkodzenie, słowa te (pojęcia) stanowią jedynie nazwy atrybutów a konkretne nazwy klienta i produktu stanowią wartość tych atrybutów i jako obiekty nie mają tu tożsamości (value UML i value object w DDD).
        Tak więc problem kolizji nazewnictwa została rozwiązany, warto tu zwrócić, że zbudowanie jednej spójnej relacyjnej bazy danych dla wszystkich pojęć obu tych dziedzin jest niemożliwe bez dodatkowych zabiegów z nazewnictwem.
Diagram: Jeden model dwa konteksty

Diagram przed­sta­wia obiek­ty biz­ne­so­we – doku­men­ty («docu­ment») pocho­dzą­ce z dwóch róż­nych kon­tak­tów. Na sche­ma­cie mamy trzy kla­sy­fi­ka­to­ry repre­zen­tu­ją­ce doku­men­ty i ich struk­tu­ry. W celu usu­nię­cia koli­zji pojęć opi­sa­nej przez Fowlera (FOWLER 2014) obiek­ty funk­cjo­nu­ją­ce w dwóch róż­nych kon­tak­tach zosta­ły roz­dzie­lo­ne na dwie kon­tek­sto­we prze­strze­nie poję­cio­we: Sprzedaż oraz Serwis. W kon­tek­ście Sprzedaż poję­cia Klient i Produkt zosta­ły uży­te do nazwa­nia obiek­tów biz­ne­so­wych będą­cych przed­mio­ta­mi mają­cy­mi toż­sa­mość. W kon­tek­ście Serwis poję­cia te (klient i pro­dukt) ca jedy­nie cecha­mi (atry­bu­ta­mi) obiek­tu biz­ne­so­we­go Uszkodzenie, sło­wa te (poję­cia) sta­no­wią jedy­nie nazwy atry­bu­tów a kon­kret­ne nazwy klien­ta i pro­duk­tu sta­no­wią war­tość tych atry­bu­tów i jako obiek­ty nie mają tu toż­sa­mo­ści (value UML i value object w DDD).

Tak więc pro­blem koli­zji nazew­nic­twa zosta­ła roz­wią­za­ny, war­to tu zwró­cić, że zbu­do­wa­nie jed­nej spój­nej rela­cyj­nej bazy danych dla wszyst­kich pojęć obu tych dzie­dzin jest nie­moż­li­we bez dodat­ko­wych zabie­gów z nazewnictwem.

Dalsze Badania

Opisane zagad­nie­nia sta­no­wią mate­riał dal­szych badań w obsza­rze two­rze­nie gene­ra­li­za­cji mode­lu danych opar­te­go na doku­men­cie i jego struk­tu­rze i wyko­rzy­sta­niu tej meto­dy do mode­lo­wa­nia danych i meta­mo­de­li doku­men­tów jak okre­ślo­nych struk­tur infomacji. 

Bibliografia

Fowler, M., & Rice, D. (2005). Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem: wzor­ce pro­jek­to­we (P. Koronkiewicz & P. Rajca, Trans.). Helion.
Eco, U. (1979). A the­ory of semio­tics.
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.

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).

Dodaj komentarz

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