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:

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

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:

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:

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:

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: