BAZA ZNANJA

Kurs: Softverski dizajn

Modul: Softverski dizajn

Autor: Test Instruktor

Naziv jedinice: Softverski arhitekturalni stilovi

U ovoj lekciji obrađivaćemo:

• softverske arhitekturalne stilove i
• njihove karakteristike

Kao što zgrade odražavaju određeni arhitektonski stil, tako postoje i stilovi arhitekture softvera. Stil obuhvata komponente, veze i ograničenja u kombinovanju komponenti. Shaw i Garlan (1996) primećuju da postoji najčešće korišćeni stilovi:

• cevi i filteri
• objektno orijentisani dizajn
• implicitno pozivanje
• slojevi
• skladišta
  
• interpreteri

Prema njihovim tumačenjima razumevanje karakteristika pojedinih stilova pomoći će da se lakše donese odluka o izboru onog koji je najpogodniji.

Cevi i filteri

Tokovi podataka koje nazivamo cevima. U ovoj vrsti sistema filtri su nezavisni i nisu svesni postojanja niti funkcija ostalih filtara u sistemu. Ispravnost izlaza iz sistema ne zavisi od redosleda kojim se filteri primenjuju. Sistem sa cevima i filtrima se koristi kod prevođenja programa: leksička analiza, semantička analiza i generisanje koda. Sistemi sa cevima i filtrima imaju nekoliko značajnih svojstava:

• dizajneri mogu da shvate uticaj celokupnog sistema na ulaze i izlaze kao kompoziciju filtara
  
  
• pošto se filtri mogu povezivati bez ograničenja, njihovo ponovno korišćenje u drugim sistemima je jednostavno
  
  
• razvoj sistema je jednostavan pošto se relativno lako mogu dodavati novi filteri i uklanjati stari
  
  
• pošto su filteri nezavisni, dizajneri mogu da simuliraju ponašanje sistema i analiziraju njegova svojstva kao što je propusna moć
  
  
• moguće je konkurentno izvršavanje filtara

Slika 1.

Cevi i filteri - mane

Cevi i filteri imaju nekoliko nedostataka. Podstiču paketnu obradu i nisu pogodni za interaktivne aplikacije. Pošto su filteri nezavisni, neki od njih možda ponavljaju pripremne funkcije drugih filtera što utiče na performanse i dovodi do koda višeg stepena složenosti.

Objektno orijentisani dizajn

Zahtevi mogu da se organizuju prema objektima i njihovim apstraktnim tipovima. Dizajn takođe može da gradi svoje komponente oko apstraktnih tipova podataka, tj. svaka komponenta je primerak apstraktnog tipa podataka.

Na taj način dizajn zasnovan na objektima mora da ima dve značajne karakteristike:

• objekat mora da očuva integritet predstavljanja podataka
  
  
• predstavljanje podataka mora biti sakriveno od ostalih objekata (enkapsuliranje), što olakšava promenu implementacije bez poremećaja ostatka sistema

Kombinovanje podataka i rutina koje njima manipulišu podstiče dizajnere na raščlanjivanje osnovnog problema na skup agenata koji su u međusobnoj interakciji. Da bi objekti mogli da utiču jedni na druge svaki od njih mora da zna identitet onog drugog, što se razlikuje od sistema sa cevima i filtrima gde su filtri potpuno međusobno nezavisni. Ova zavisnost znači da promena u identitetu jednog objekta zahteva da se promene sve ostale komponente koje pozivaju promenjeni objekat.

Implicitno pozivanje

Model dizajna za implicitno pozivanje pokreću događaji, a zasnovan je na pojmu difuznog emitovanja. Ideja je da umesto pozivanja procedure direktno, komponenta objavljuje jedan ili više događaja. Ostale komponente mogu tim događajima da pridružuju procedure (to se naziva registrovanjem procedure), a sistem poziva sve takve registrovane procedure. Razmena podataka u ovoj vrsti sistema mora da se obavlja pomoću zajedničkih podataka u skladištu. Ova vrsta dizajna se često koristi u mrežama sa komutiranjem paketa.

Npr. Reiss (1990) izveštava o okruženju koje se zove Field, u kojem se alatke kao što su editori registruju za događaje koji nastupaju tokom rada programa za pronalaženje grešaka.

Npr. program za pronalaženje grešaka obrađuje kod, red po red i utvrdi da nedostaje jedna promenljiva. On objavljuje događaj „nedostaje promenljiva", a sistem automatski poziva editor teksta registrovan za taj događaj. Na ovaj način editor automatski omogućava korisniku da uredi red u kojem promenljiva nedostaje.

Slojevi

Slojevi su hijerarhijski raspoređeni, svaki sloj pruža usluge sledećem sloju koji ga okružuje i igra ulogu klijenta sloju koji obuhvata, kao što se vidi na slici.  U nekim sistemima svi slojevi imaju pristup nekim ili svim ostalim slojevima, u drugim sistemima svaki sloj ima pristup samo susednim slojevima. Dizajn sadrži protokole koji regulišu način međusobnog dejstva za svaki par slojeva.

Slika 2.

Unutrašnji sloj, kriptografija, obuhvata funkcije za kriptovanje i dekriptovanje ključa koji se koristi u osnovnoj šemi kriptovanja za sistem. Drugi sloj, interfejs datoteke, kriptuje i dekriptuje datoteku. Treći sloj, rukovanje ključevima, komponenti omogućava da potpiše datoteku, proverava potpis i izračunava kod za dobijanje pristupa datoteci. Četvrti sloj proverava autentičnost, ovaj sloj upravlja datotekom lozinki koja se čuva u kriptovanom obliku i od korisnika zahteva identifikaciju (korisničko ime i lozinku).

Korisnici mogu da pristupe sistemu u različitim slojevima dizajna, zavisno od potreba izraženih u zahtevima. Npr. ako korisnici ne moraju da znaju ništa o šemi kriptovanja, oni mogu da komuniciraju sa sistemom samo u poslednjem spoljašnjem sloju da bi promenili lozinku ili dali podatke za identifikaciju. S druge strane, ako je sistem projektovan za korišćenje u različitim zemljama i okruženjima, tada neke klase korisnika mogu da imaju pristup „najunutrašnjijem" sloju i mogu da menjaju algoritam kriptovanja.

Slojevite arhitekture u velikoj meri koriste pojam apstrakcije. Svaki sloj se može smatrati sledećim stepenom apstrakcije. Dizajneri mogu da koriste slojeve za razlaganje problema u niz sve apstraktnijih koraka. Zbog ograničenja po kojima slojevi međusobno deluju, relativno je lako dodavati ili menjati sloj kada za tim pojavi potreba, takve promene obično pogađaju samo dva susedna sloja. Iz istog razloga je ponovno korišćenje sloja relativno jednostavno, a izmene su potrebne jedino u susednim slojevima. Sistem u slojevima nije uvek lako strukturirati, slojevi apstrakcije nisu uvek očigledni. Čak i kada postoji mogućnost da se napravi slojeviti dizajn, dodatno koordinisanje među slojevima može da utiče na performanse sistema.

Skladišta

Slika 3. Struktura skladišta

U skladištu postoje dve vrste komponenti:

• centralno skladište podataka i
  
• kolekcija komponenti koje se nad njim izvršavaju da bi se informacije sačuvale, pronašle i ažurirale

Pri projektovanju skladišta značajno je odlučiti na koji način će te dve vrste komponenti međusobno da deluju. Svi elementi repozitorijuma su deljeni. Obično se sastoji od tri elementa: samog zajedničkog repozitorijuma (blackboard), izvora znanja i kontrole. Izvori znanja su zasebne celine podataka, takođe zavisne od aplikacije, a međusobno deluju isključivo preko zajedničkog repozitorijuma. Izvršavanje zavisi od stanja zajedničkog repozitorijuma, kako se ono menja, izvori znanja reaguju slično kao u stilu implicitnog pozivanja. Dizajn zajedničkog repozitorijuma se koristi u mnogim sistemima, npr. kod obrade signala.

Multi-tier architecture

Višeslojne arhitekture, n-tier architecture, su klijent server arhitekture u kojima se aplikacija izvršava od strane više različitih softverskih agenata. Najrašireniji oblik multi-tier architecture je three-tier architecture, koja je prikazana na slici. Pogodna jer omogućava upgrade ili zamenu bilo kog od tri sloja ako se zahtevi ili tehnologija promeni (npr. ako se promeni operativni sistem Windows-Linux, promeniće se samo user interface). Klijentski sloj nikada ne komunicira direktno sa data slojem, svaka komunikacija mora da prođe kroz  srednji (middleware) sloj.

Slika 4. Three-tier architecture (izvor: WikiPedia)

Model-view-controller (MVC)

Arhitekturalni stil koji se koristi kod interaktivnih sistema. Na prvi pogled slično kao Three-tier arhitektura, ali sa različitim topologijama. Osnovno pravilo kod Three-tier je da korisnik nikada nije direktno u vezi sa slojem podataka. Konceptulano Three-tier arhitektura je linearna.

MVC arhitektura je triangularna - View šalje promene Controller-u, Controller ažurira Model, dok View dobija  promene direktno od Model-a.

Kada se govori o složenim aplikacijama i prikazu velikih količina informacija korisniku, razdvajaju se podaci (Model) i user interface (View), tako da promene user interface-a neće uticati na rukovanje podacima, kao što i promene organizacije podataka neće uticati na user interface. Ovo se postiže uvođenjem srednje komponente (Controller).