Separacja kontekstu i znaczeń w metodach obiektowych

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 rozwiązania.

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.

Wymagania pozafunkcjonane czyli jaka architektura

Poza wyma­ga­nia­mi funk­cjo­nal­ny­mi, poda­je­my tak zwa­ne wyma­ga­nia poza-funk­cjo­nal­ne. Mają one, mię­dzy inny­mi, waż­na rolę do speł­nie­nia. Jaką?

Najpierw cytat:

Technologia klient/serwer jest zależ­na od komu­ni­ka­cji pomię­dzy poszcze­gól­ny­mi kom­pu­te­ra­mi. Sieci LAN i WAN sta­ją się znacz­nym wydat­kiem oraz wyma­ga­ją dużych nakła­dów pra­cy w związ­ku z zarzą­dza­niem nimi. Co wię­cej, zmia­na wer­sji opro­gra­mo­wa­nia na wie­lu kom­pu­te­rach, co szcze­gól­nie widocz­ne jest w przy­pad­ku prze­twa­rza­nia roz­pro­szo­ne­go, sta­je się istot­nym pro­ble­mem. Wielokrotnie dzia­ły IT zasta­na­wia­ją się nad przej­ściem na struk­tu­rę Internet/Intranet w celu roz­wią­za­nia tego pro­ble­mu. (Wstęp do ERP – tech­no­lo­gia u pod­wa­lin przedsiębiorstwa).

Pomijając pro­sto­tę” tego tłu­ma­cze­nia, chcę zwró­cić uwa­gę na waż­ną rzecz: bar­dzo duże znacz­nie ma archi­tek­tu­ra sys­te­mu, nie­ste­ty wie­lu pro­du­cen­tów ukry­wa zasto­so­wa­ną tech­no­lo­gię i archi­tek­tu­rę. Jedną z przy­czyn jest to, że są to nie raz tech­no­lo­gie rodem z lat 90-tych a bywa, że nawet wcze­śniej­sze. Jedną z takich sta­ro­ci” jest archi­tek­tu­ra client-server (tak zwa­ny gru­by klient). Innym typem dino­zau­ra” tech­no­lo­gicz­ne­go jest two­rze­nie opro­gra­mo­wa­nia, w któ­rym logi­ka biz­ne­so­wa jest w jakiejś czę­ści w pro­ce­du­rach wbu­do­wa­nych bazy danych (w rozu­mie­niu kon­kret­ne­go tak zwa­ne­go moto­ra SQL bazy).

Jaki mamy wybór?

Zanim powie­my sobie o wybo­rze, kil­ka słów na temat kla­sycz­nej trój­war­stwo­wej archi­tek­tu­ry jako fun­da­men­cie dal­szych roz­wa­żań. Struktura taka wyglą­da następująco:

Architektura trójwarstwowa

Mamy tu trzy war­stwy: Warstwa pre­zen­ta­cji, czy­li kom­po­nent odpo­wie­dzial­ny za wyświe­tla­nie infor­ma­cji na ekra­nie użyt­kow­ni­ko­wi i ich przyj­mo­wa­nie. Warstwa logi­ki apli­ka­cji podzie­lo­na na Logikę dzie­dzi­no­wą (część spe­cy­ficz­na dla dzie­dzi­ny pro­ble­mu, tu są np. fak­tu­ry, spo­sób nali­cza­nia podat­ków, raba­tów itp. ta część reali­zu­je wyma­ga­nia funk­cjo­nal­ne) oraz Logikę poza-dzie­dzi­no­wą (wydaj­ność, nie­za­wod­ność, bez­pie­czeń­stwo, inte­gra­cja z inny­mi apli­ka­cja­mi itp.). Najniżej jest war­stwa Utrwalania, coraz czę­ściej w para­dyg­ma­cie obiek­to­wym pomi­ja­na na tym pozio­mie abs­trak­cji (utoż­sa­mia­na z reali­za­cją wyma­gań poza-funk­cjo­nal­nych zwią­za­nych z zacho­wy­wa­niem informacji).

Praca w sie­ci wie­lu użyt­kow­ni­ków to wie­lo­do­stęp (wie­le sta­cji robo­czych korzy­sta z jed­ne­go serwera):

Wielodostęp

Gruby klient

Gruby klient to archi­tek­tu­ra w któ­rej każ­dy użyt­kow­nik ma na swo­im lokal­nym kom­pu­te­rze nie tyl­ko war­stwę pre­zen­ta­cji ale tak­że całą logi­kę apli­ka­cji. Każde takie sta­no­wi­sko komu­ni­ku­je się z ser­we­rem danych:

Architektura Gruby klient

Do powyż­szej archi­tek­tu­ry odno­szą się głów­ne uwa­gi o wadach z cyta­tu na począt­ku. Cechy archi­tek­tu­ry po lewej stro­nie: kosz­tow­ne sta­cje robo­cze (muszą, każ­da, udźwi­gnąć całe opro­gra­mo­wa­nie), kosz­tow­na admi­ni­stra­cja (nie­zgod­ność wer­sji na sta­cjach robo­czych może pro­wa­dzić do kra­chu sys­te­mu), kosz­tow­ne mody­fi­ka­cje (tak­że z uwa­gi na wyma­ga­ną zgod­ność opro­gra­mo­wa­nia na sta­cjach robo­czych), bar­dzo duże wyma­ga­nia na pasmo i nie­za­wod­ność sie­ci (duże trans­fe­ry danych pomię­dzy sta­cja­mi robo­czy­mi i ser­we­rem, zerwa­nie połą­cze­nia powo­du­je blo­ka­dy dostę­pu do danych) powo­du­ją, że pra­ca w sie­ci roz­le­głej tery­to­rial­nie może być wręcz nie­moż­li­wa (wte­dy wyma­ga powie­la­nia insta­la­cji w każ­dej loka­li­za­cji i syn­chro­ni­za­cji danych, kolej­ne nie­ma­łe kosz­ty). Pewną odmia­ną jest wariant po pra­wej stro­nie, gdzie część logi­ki apli­ka­cji jest umiesz­czo­na na ser­we­rze danych (kon­kret­nie bazy danych), powo­du­je to nie­co zmniej­szo­ny ruch w sie­ci ale dodat­ko­wo kom­pli­ku­je wszel­kie roz­sze­rze­nia funk­cjo­nal­no­ści i upgra­de oraz prak­tycz­nie unie­moż­li­wia zmia­nę (wybór) pro­du­cen­ta bazy danych. Duże kosz­ty tej archi­tek­tu­ry dodat­ko­wo potę­gu­je wymóg wyku­pie­nia licen­cji na bazę danych dla każ­de­go użytkownika.

W więk­szo­ści przy­pad­ków tej archi­tek­tu­ry, logi­ka biz­ne­so­wa (dzie­dzi­no­wa) nie jest sepa­ro­wa­na od resz­ty, w efek­cie dodat­ko­wo wszel­kie pra­ce dosto­so­waw­cze są bar­dzo kosz­tow­ne (inge­ren­cja w całą aplikację).

Architektura internetowa – cienki klient

Taką nazwę od pew­ne­go cza­su nada­je się archi­tek­tu­rze opar­tej na dostę­pie do apli­ka­cji z pomo­cą prze­glą­dar­ki WWW:

Architektura Cienki klient

Powyższa archi­tek­tu­ra prak­tycz­nie nie ma żad­nej wady poprzed­nie­go roz­wią­za­nia. Dodatkowo baza danych licen­cjo­no­wa­na jest z regu­ły na apli­ka­cję a nie na każ­de­go użyt­kow­ni­ka (czy­li jest taniej). Stosując tak zwa­ne meto­dy i archi­tek­to­nicz­ne wzor­ce obiek­to­we (naj­po­pu­lar­niej­szy to MVC: Model, View, Controller) sepa­ru­je się kom­po­nent logi­ki biz­ne­so­wej od logi­ki ste­ro­wa­nia apli­ka­cją. W efek­cie dosto­so­wa­nie apli­ka­cji nie pole­ga na kosz­tow­nym mody­fi­ko­wa­niu logi­ki apli­ka­cji, doda­je się i inte­gru­je nie­za­leż­ny kom­po­nent Logiki biz­ne­so­wej, co dodat­ko­wo pozwa­la zacho­wać sepa­ra­cję praw autor­skich do kodu logi­ki biz­ne­so­wej (know-how fir­my). Korzyścią takiej archi­tek­tu­ry jest tak­że moż­li­wość łatwe­go doda­wa­nia moż­li­wo­ści dostę­pu z innych niż kom­pu­ter PC, urzą­dzeń (smart­fo­ny, table­ty, itp.) gdyż wyma­ga to wyłącz­nie nowej war­stwy pre­zen­ta­cji, logia pozo­sta­je spój­na na serwerze.

Kolejna korzyść to łatwa inte­gra­cja z inny­mi apli­ka­cja­mi. Oprogramowanie w tej archi­tek­tu­rze ukry­wa” dane, dostęp do nich jest wyłącz­nie przez Logikę apli­ka­cji za pośred­nic­twem tak zwa­nych API (inter­fejs pro­gra­mi­stycz­ny) meto­da­mi zna­ny­mi w sie­ci WWW, uni­ka­my kosz­tow­nych i ryzy­kow­nych łączy bez­po­śred­nich do baz danych (niska pra­co­chłon­ność inte­gra­cji, bar­dzo wyso­kie kosz­ty utrzy­ma­nia i rozwoju).

W efek­cie reko­men­do­wa­na archi­tek­tu­ra mogła by wyglą­dać tak:

Rekomendowana architektura aplikacji

Zalety: niskie kosz­ty utrzy­ma­nia sys­te­mu i infra­struk­tu­ry, sepa­ra­cja logi­ki biz­ne­so­wej (dzie­dzi­no­wej) dedy­ko­wa­nej od kupio­nej”, łatwość i niski koszt upgra­de, pra­ca z pomo­cą prze­glą­dar­ki WWW, łatwa inte­gra­cja z inny­mi apli­ka­cja­mi, łatwość pra­cy w sie­ci lokal­nej i roz­le­głej (w tym łatwy zdal­ny dostęp z dowol­ne­go cudze­go kom­pu­te­ra). To tyl­ko głów­ne korzyści.

Wymagania pozafunkcjonalne

Jak wspo­mnia­łem, wie­lu dostaw­ców opro­gra­mo­wa­nia jak Rejtan, bro­ni się przed ujaw­nia­niem archi­tek­tu­ry, swo­ich pro­duk­tów. Głównym powo­dem jest zapo­bie­ga­nie przed­wcze­sne­go wyja­wie­nia opi­sa­nych wyżej wad sys­te­mów z gru­bym klien­tem (znacz­nie rza­dziej spek­ta­ku­lar­ny pomysł, w koń­cu mamy jed­nak jakieś stan­dar­dy). Przypadki, w któ­rych zakup sys­te­mu był rela­tyw­nie niski ale koszt utrzy­ma­nia, roz­wo­ju i dosto­so­wa­nia nie raz wręcz ogrom­ny, to z regu­ły wła­śnie zakup sys­te­mu w tej kosz­tow­nej architekturze.

Jak sta­rać się tego uni­kać? Na eta­pie defi­nio­wa­nia wyma­gań poza-funk­cjo­nal­nych, żądać takich cech jak opi­sa­ne powy­żej czy­li wła­snie: dostęp do cało­ści przez prze­glą­dar­kę WWW, niskie wyma­ga­nia na łącza przy zdal­nej pra­cy i pra­cy w sie­ci roz­pro­szo­nej tery­to­rial­nie, oddzie­le­nie kom­po­nen­tu z wła­sną dedy­ko­wa­ną logi­ką biznesową.

[2015]

Polecam poga­dan­ke M.Fowlera na temat roli architektury:

Krótki wpis o śladowaniu

Często jestem pyta­ny: a co to jest to śla­do­wa­nie”? Artykuł adre­su­je nie tyl­ko ana­li­ty­kom, ale tak­że oso­bom zle­ca­ją­cym wyko­na­nie ana­li­zy, pro­jek­tu i ich doku­men­ta­cji. W arty­ku­le poda­je przy­kła­dy bazu­ją­ce na obiek­to­wych meto­dach i wzor­cach ana­li­tycz­nych jed­nak nie jest to wie­dza wyma­ga­na do jego zrozumienia.

Po kolei…

Jedną z cech doku­men­ta­cji wyso­kiej jako­ści, jest wywo­dze­nie (kon­stru­owa­nie) każ­de­go wyma­ga­nia i pozo­sta­łych ele­men­tów mode­li od ogó­łu do szcze­gó­łu (meto­da ana­li­zy top-down) i wery­fi­ko­wa­nie ich w dru­gą stro­nę (meto­da ana­li­zy bot­tom-up). Nazywane jest to coraz czę­ściej jako tak zwa­ne śla­do­wa­nie (zależ­ność «tra­ce» na mode­lach popu­la­ry­zo­wa­na przez orga­ni­za­cję IIBA). Śladowanie pozwa­la przede wszystkim:

  1. uza­sad­nić każ­de wymaganie,
  2. uza­sad­nić każ­dy ele­ment pro­jek­tu implementacji,
  3. zwe­ry­fi­ko­wać kom­plet­ność i spój­ność całej dokumentacji,
  4. zapo­biec nie kon­tro­lo­wa­ne­mu roz­ro­sto­wi zakre­su projektu,
  5. umoż­li­wia oce­nę ren­tow­no­ści pro­jek­tu per każ­de wyma­ga­nie niezależnie.

Cóż to jest śladowanie? 

Przede wszyst­kim potrzeb­ny jest szczyt”, korzeń drze­wa śla­do­wa­nia. Powinien nim być cel biz­ne­so­wy pro­jek­tu, jak nie trud­no się domy­śleć, dla jed­ne­go pro­jek­tu powi­nien być zde­fi­nio­wa­ny jeden cel głów­ny, on wyzna­cza kie­ru­nek. Możliwe są cele skła­do­we, pod­rzęd­ne, ale jeden głów­ny jest wymagany.

Jednym z pod­sta­wo­wych ele­men­tów stra­te­gii osią­ga­nia celów biz­ne­so­wych jest ulep­sza­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cji. w tym celu wyko­nu­je się audyt orga­ni­za­cji, któ­re­go pro­duk­tem jest jej peł­ny model, ten zawie­ra mię­dzy inny­mi, jako skła­do­we, mode­le pro­ce­sów biznesowych.

Każdy pro­ces biz­ne­so­wy to jed­na lub sze­reg powią­za­nych czyn­no­ści. Wymagania są koja­rzo­ne (wywo­dzo­ne) z tych czyn­no­ści, któ­re pla­nu­je­my uspraw­nić np. z pomo­cą narzę­dzia jakim jest pla­no­wa­ne nowe lub roz­bu­do­wy­wa­ne oprogramowanie.

W przy­pad­ku opro­gra­mo­wa­nia dedy­ko­wa­ne­go, to jest two­rzo­ne­go na zamó­wie­nie, tymi wyma­ga­nia­mi są ocze­ki­wa­ne usłu­gi, tak zwa­ne przy­pad­ki uży­cia, opro­gra­mo­wa­nia (sys­te­mu). Są one wywo­dzo­ne z tych czyn­no­ści, któ­re nowe opro­gra­mo­wa­nie ma wspie­rać. Tak się okre­śla zakres pro­jek­tu, któ­ry jak widać, też wywo­dzo­ny jest z mode­lu (pro­ce­sów).

Kolejny pro­jek­to­wa­ny ele­ment to model dzie­dzi­ny sys­te­mu. Zawiera on obiek­ty biz­ne­so­we oraz ele­men­ty odpo­wie­dzial­ne za reali­za­cje każ­dej usłu­gi nowe­go opro­gra­mo­wa­nia. Są to kla­sy (i obiek­ty) w mode­lu dzie­dzi­ny. Każdy przy­pa­dek uży­cia jest wywo­dzo­ny z czyn­no­ści w pro­ce­sie, kla­sy ste­ru­ją­ce są wywo­dzo­ne z przy­pad­ków uży­cia, kla­sy repre­zen­tu­ją­ce obiek­ty prze­twa­rza­ne, są wywo­dzo­ne z doku­men­tów i zdarzeń.

Dalej z przy­pad­ków uży­cia wywo­dzo­ne są dia­gra­my sekwen­cji mode­lu­ją­ce sce­na­riu­sze zacho­wa­nia sys­te­mu w reak­cji na dzia­ła­nia użyt­kow­ni­ka (tak zwa­ne­go akto­ra). Klasy na mode­lach sekwen­cji są wywo­dzo­ne z mode­lu dziedziny.

Jeżeli model pro­ce­sów biz­ne­so­wych zawie­ra defi­ni­cje reguł biz­ne­so­wych, wywo­dzo­ne są z nich kla­sy lub ich ope­ra­cje, odpo­wie­dzial­ne za prze­strze­ga­nie” tych reguł.

Śladowanie w opi­sa­nej powy­żej kon­wen­cji ma nastę­pu­ją­ca postać:

Jak widać nad­zo­ro­wa­nych jest (śla­do­wa­nie) wie­le logicz­nych sko­ja­rzeń. Tego rodza­ju dia­gra­mów w pro­jek­cie jest nie mało, nie raz kil­ka­dzie­siąt i wię­cej, logicz­nych połą­czeń (czer­wo­ne linie prze­ry­wa­ne obra­zu­ją­ce śla­do­wa­nie) są więc set­ki. Jak nie­trud­no się domy­śleć, ręcz­ne” śle­dze­nie tych powią­zań jest prak­tycz­nie nie moż­li­we. (podob­nie zresz­tą jak ręcz­ne opra­co­wy­wa­nie zło­żo­nych rapor­tów finan­so­wych z tysię­cy danych).

Bez spe­cjal­ne­go narzę­dzia utrzy­ma­nie wyso­kiej jako­ści pro­jek­tu jest prak­tycz­nie nie moż­li­we przy zacho­wa­niu roz­sąd­ne­go nakła­du pra­cy. Narzędzia te to pakie­ty opro­gra­mo­wa­nia wspo­ma­ga­ją­ce pro­jek­to­wa­nie CASE (ang. com­pu­ter aided sys­tems engi­ne­ering lub com­pu­ter aided softwa­re engi­ne­ering, oso­bi­ście pre­fe­ru­je to pierw­sze roz­wi­nię­cie tego skrótu).

Jak zapew­ne czy­tel­ni­cy już zauważyli,…

…mode­le bez sys­te­mu śla­do­wa­nia są prak­tycz­nie nie­we­ry­fi­ko­wal­ne, ich jako­ści nie da się oce­nić a ich sto­so­wa­nie jest wyso­ce ryzy­kow­ne o ile w ogó­le sensowne.

Po co to wszystko? 

Jak wspo­mnia­no na począt­ku, do zapa­no­wa­nia na zło­żo­no­ścią pro­jek­tu i jego ren­tow­no­ścią. Kolejny powód to moż­li­wość wery­fi­ka­cji kom­plet­no­ści wyma­gań. Odkrywanie wyma­gań dopie­ro w trak­cie reali­za­cji pro­jek­tu (wery­fi­ka­cja wyma­gań dopie­ro z pomo­cą kolej­nych jego pro­to­ty­pów) to powszech­nie zna­ny zabój­ca projektów”.

Dobrze opra­co­wa­ny, kom­plet­ny model orga­ni­za­cji, jego wyko­na­nie poprze­dza opi­sa­ny powy­żej model, łączy w sobie:

  1. model moty­wa­cji biz­ne­so­wej,
  2. model struk­tu­ry organizacyjnej,
  3. model pro­ce­sów biz­ne­so­wych (wymie­nio­ny już powyżej),
  4. model reguł biz­ne­so­wych.

Elementy każ­de­go z tych mode­li są ze sobą powią­za­ne: role w pro­ce­sach są wywo­dzo­ne ze sta­no­wisk w mode­lu orga­ni­za­cyj­nym, ana­li­zo­wa­ne pro­ce­sy są wywo­dzo­ne ze stra­te­gii w mode­lu moty­wa­cji, regu­ły biz­ne­so­we są koja­rzo­ne z czyn­no­ścia­mi w pro­ce­sach i wywo­dzo­ne z aktów praw­nych i wewnętrz­nych zarządzeń.

Mając tak opra­co­wa­ny kom­plet­ny model orga­ni­za­cji, zawie­ra­ją­cy śla­do­wa­nie, i odpo­wied­nie opro­gra­mo­wa­nie CASE moż­na prze­pro­wa­dzić ana­li­zę oddzia­ły­wa­nia, np. spraw­dzić na jakie oso­by w orga­ni­za­cji prze­nie­sie się zmia­na wybra­nych reguł biz­ne­so­wych. Mając model sys­te­mu infor­ma­tycz­ne­go sko­ja­rzo­ny z pro­ce­sa­mi, moż­na spraw­dzić wpływ awa­rii poszcze­gól­nych pod­sys­te­mów na pro­ce­sy biz­ne­so­we i ich skut­ki dla fir­my. Takich ana­liz moż­na wyko­nać wie­le, nie było by to moż­li­we bez tak skon­stru­owa­ne­go modelu.

Dlatego, pod­sta­wo­wą war­to­ścią popraw­nie wyko­na­nych mode­li orga­ni­za­cji i uży­cia wła­ści­wych narzę­dzi, jest nie tyl­ko opra­co­wa­nie wyma­gań np. na opro­gra­mo­wa­nie. Możliwe jest testo­wa­nie reak­cji ele­men­tów struk­tu­ry orga­ni­za­cji na zda­rze­nia np. awa­rie. Możliwe jest opra­co­wa­nie pro­jek­tów inte­gra­cji, wymia­ny opro­gra­mo­wa­nia. Możliwe jest spraw­dze­nie na co ma wpływ np. nie­ocze­ki­wa­na nie­obec­ność pra­cow­ni­ka. To tyl­ko wybra­ne przy­kła­dy, jed­nak moż­li­we jest to wyłącz­nie pod warun­kiem posia­da­nia popraw­nie wyko­na­ne­go modelu.

Wartość doda­na takiej ana­li­zy może być bar­dzo duża. Jeżeli podej­mu­je się decy­zje o inwe­sty­cjach rzę­du setek tysię­cy a nie raz dzie­sią­tek milio­nów zło­tych to wspar­cie tych decy­zji ana­li­za­mi, któ­rych war­tość jest o rząd albo dwa rzę­dy mniej­sza ma głę­bo­ki sens…