Računarska shema za dizajn

Dizajn šema () u računarskom inženjerstvu je stalno ponavljano rješenje učestalom problemu u softverskom dizajnu. U principu, ovo nije krajnje rješenje koje se može direktno pretvoriti u izvorni kod, nego je više opis ili šablon po kojem se problem može riješiti u raznim situacijama. Objektno orijentirane dizajn šeme obično pokazuju odnos između raznih klasa ili objekata, bez detaljnog opisa tih klasa ili objekata. Algoritmi se ne smatraju dizajn šemama jer oni rješavaju probleme u zadacima, a ne probleme dizajna.

 Historija 
Dizajn šeme su započele život u arhitekturi, čiji je tvorac Christopher Alexander, arhitekt i akademik. U 1987. Kent Beck i Ward Cunningham su počeli eksperimentirati sa upotrebom šema u računarstvu, te su izjasnili svoje rezultate na OOPSLA konferenciji iste godine.

Širu popularnost u računarstvu dizajn šeme dobijaju nakon izlaska knjige Design Patterns: Elements of Reusable Object-Oriented Software Pošto ova knjiga nije još prevedena na bosanski jezik, naziv ovdje je na engleskom. 1994. Iste godine se održava prva konferencija o PLoPu, te naredne godine se uspostavlja Portland Pattern Repository, koji ima cilj da dokumentira dizajn šeme. Obim ovog izraza je problematičan u narednoj deceniji.

 Upotreba 
Dizajn šeme mogu ubrzati razvoj softvera tako što daju isprobane i testirane programske paradigme. Uspješan softverski dizajn zahtijeva razmatranje problema koji se pojavljuju tek u kasnijim fazama razvoja. Ponovno korištenje postojećih šema pomaže kod izbjegavanja sitnih problema koji mogu izazvati daleko veće, te poboljšava čitkost programerima i arhitektima upoznatim za šemom.

Često softver inženjeri znaju da primijene samo neke od metoda dizajna u svom softverskom rješenju. Međutim, te metode znaju biti problematične kad se primjenjuju pri rješavanju šireg spektra problema. Dizajn šeme nude uopštena rješenja koja su dokumentirana na način koji ne zahtijeva da se prave (implementiraju) na određeni način.

Dizajn šeme se sastoje od više dijelova (pogledajte Dokumentaciju), mada od naročitog interesa su struktura, list učesnika i saradnja. Ovi dijelovi opisuju tzv. dizajn motiv, tj. (proto)tipična mikro-arhitektura koju programeri kopiraju i adaptiraju svojim potrebama da riješe stalno ponovljivi problem opisan u dizajn šemiMikro-arhitektura je skup programskih dijelova, npr. klasa, metoda itd., te njihovih međusobnih veza.. Programeri koriste dizajn šemu tako što u svojim programima koriste ovu (proto)tipičnu mikro-arhitekturu, što znači da mikro-arhitektura u njihovom dizajnu ima sličnu strukturu i organizaciju odabranom dizajn motivu.

Koristeći dizajn šeme, programeri su u stanju da komuniciraju koristeći dobro poznate, veoma razumljive pojmove za razvoj softvera. Ti uopšteni principi, tj. dizajn šeme, se mogu poboljšati s vremenom, što nije moguće sa spontanim (lat. ad-hocAd-hoc je latinska fraza koja znači "za ovo", rješenje za specifični problem ili zadatak koje nije moguće generalizirati ili upotrijebiti u druge svrhe.) dizajnom.

 Podjela 
Dizajn šeme mogu biti razvrstane u okviru raznih kriterija, međutim najčešće se dijele na osnovu problema koje rješavaju. Po ovom kriteriju, šeme su podijeljene na:
 Osnovne šeme
 Šeme stvaranja
 Šeme strukture
 Šeme ponašanja
 Istovremene šeme
 Arhitektonske šeme

 Dokumentacija 
Dokumentacija dizajn šeme treba da sadrži dovoljno podataka o problemu koji treba riješiti, kontekst (okvir) upotrebe, te predloženo rješenje. Mada autori obično koriste svoj format dokumenata, njihov format sadrži napomenute podatke. Često se uključe dodatni podaci koji daju detaljniji opis i organiziraju elemente šeme u različitim dijelovima, obično sa različitim imenima.

Uobičajeni format je opisan u gore spomenutoj knjizi Četvorice Otpisanih () i sadrži sljedeće dijelove:

 Ime i podjelu šeme - svaka šema treba da ima jedinstveno i opisivo ime, pomoću kojeg se ona može prepoznati. Povrh toga, treba se klasificirati po podjeli, poput gore spomenute podjele, pošto ta podjela olakšava prepoznavanje kada se ta šema treba koristiti.
 Namjeru - ovaj dio treba da opiše cilj šeme i razloge za upotrebu, tj. ovo je opis problema šeme.
 Također poznata kao - ako je šema poznata pod drugim nazivima, onda se ti nazivi navode u ovom dijelu.
 Razlog - ovaj dio sadrži scenario napravljen od opisa problema i konteksta unutar kojeg se šema može koristiti. Pošto povezuje problem i kontekst, ovaj dio dokumenta također razjašnjava kad treba koristiti šemu.
 Primjena - u ovom dijelu se opisuju situacije u kojima treba primijeniti šemu, tj. opisuje kontekst šeme.
 Struktura - grafička slika šeme, obično nacrtana koristeći UML-ov dijagram klasa ili dijagram redoslijeda.
 Lista učesnika - je lista klasa i objekata korištenih u šemi i njihove uloge.
 Saradnja - opisuje kako klase i objekti surađuju u šemi.
 Konsekvence - ovaj dio opisuje rezultate, nepoželjne efekte i čega se mora odreći pri primjeni šeme.
 Implementacija - ovaj dio opisuje rješenje i način primjene šeme. Tehnički detalji i prijedlozi oko implementacije se također navode u ovom dijelu.
 Primjer izvornog koda - ilustracija kako se ova šema može napisati u nekom od programskih jezika.
 Poznate upotrebe - u ovom dijelu se navode upotrebe ove šeme u stvarnom životu.
 Vezane šeme - dio sadrži listu šema koje su vezane za šemu, koje se mogu koristiti zajedno sa ovom šemom ili umjesto ove šeme. Također se navode razlike između šeme i vezanih šema.

 Kritika 
Koncept dizajn šeme je pod udarom kritike od strane nekih u polju računarstva, najviše iz sljedećih razloga:

 Nezadovoljavajuća apstrakcija dizajn šema 
Neki od kritičara misle da je potreba za šemama rezultat korištenja programskih jezika ili metoda sa nezadovoljavajućim nivoom apstrakcije. Idealna faktorizacija zahtijeva da se koncept ne kopira, nego da se samo referencira. Međutim, ako je nešto referencirano a ne kopirano, onda tu nema šeme koja sa može označiti i katalogiziratiPaul Graham (May 2002). Revenge of the Nerds. Napomena prebačena sa Engleske interwiki 15. maja 2006.

Čak i gore navedena knjiga, Design Patterns: Elements of Reusable Object-Oriented SoftwareGama et. al. (1995) Design Patterns: Elements of Reusable Object-Oriented Software, , je često pod udarom kritike poput izjave da od navedenih 23 šema (opisanih u C++-u) čak 16 je eliminisano ili pojednostavljeno u jezicima poput Lispa ili Dylan-aPeter Norvig (1998-03-17). Design Patterns in Dynamic Programming. Napomena prebačena sa Engleske interwiki 15. maja 2006.

 Teorijska potpora dizajn šema 
Neki teoretičari tvrde da su studiji dizajn šema previše spontani (ad-hoc), te da je njihovom konceptu neophodna formalizacija.

 Reference 

Kategorija:Programiranje