U programiranju, frejmvork (engl. framework) je apstrakcija u kojoj omogućavanje generalnih softverskih funkcija mogu biti selektivno menjane dodatnim kodom napisanim od strane korisnika, i time omogućavajući softver koji je speficičan za aplikacije. Softverski frejmvork je univerzalano softversko okruženje koje može biti korišćeno iznova i koje omogućava određenu funkcionalnost kao deo veće softverske platforme da olakša razvoj aplikacija, proizvoda i rešenja. Softverski frejmvorci mogu uključivati podršku programa, kompajlere, biblioteke koda, skupove alatki i API koji sve ukupno donose različite komponente da omoguće razvoj projekta ili rešenja.

Frejmvorci sadrže ključno prepoznatljive mogućnosti koje ih odvajaju od normalnih biblioteka:

  • Inverzija kontrole: U frejmvorku, za razliku od biblioteka ili normalnih aplikacija korisnika, sveobuhvatno programsko upravljanje tokom nije naređivano od strane sagovornika, već od strane frejmvorka.[1]
  • podrazumevano ponašanje: Frejmvork ima podrazumevano ponašanje. Ovo podrazumevano ponašanje mora biti neko korisno ponašanje a ne skup beskorisnih potprograma.
  • rastegljivost: Frejmvork može biti proširen od strane korisnika obično selektivnim obaranjem ili specijalizovanim kodom korisnika da omogući specifične funkcionalnosti.
  • nepromenljivi kod frejmvorka: Kod frejmvorka, generalno, ne treba menjati, prihvatajući ekstenzije od strane korisnika. Drugim rečima, korisnici mogu proširiti frejmvork, ali ne treba menjati njegov kod.

Obrazloženje uredi

Dizajneri softverskih frejmvorka ciljaju da olakšaju softverski razvoj omogućavajući dizajnerima i programerima da odvoje svoje vreme na upoznavanje softverskih zahteva umesto na detalje višestandardnog nižeg nivoa koje doprinose sistem koji radi, i time smanjujući sveobuhvatno vreme razvoja.[2] Na primer, tim koji koristi frejmvork veb priloga da napravi bankarski veb sajt se može fokusirati na pisanje koda koji se posebno odnosi na bankarstvo umesto na mehaniku zahteva i upravljanja.

Frejmvorci često dodaju veličini programa, fenomen nazvan "code bloat". Zvog aplikacijskih zahteva korisnika, i takmičarski i komplementarni frejmvorci ponekad se pojave zajedno u proizvodu. Dalje, zvog kompleksnosti API-a, namenjeno smanjenje u sveovuhvatnom vremenu razvoja možda ne može biti postignuto zbog potrebe za dodatnim vremenom na učenje korišćenja frejmvorka; ova kritika je očito validna kada posebni ili novi frejmvork je prvi put susretnut od strane razvojnog tima. Ako se takav frejmvork ne iskoristi u sledećim zadacima posla, uloženo vreme u učenju frejmvorka može koštati više nego kod koji je posebno napisan, a poznat projektnom timu; mnogi programeri čuvaju kopije korisnog boilerplate-a za česte potrebe.

Kako god, kada se frejmvork konačno nauči, budući projekti mogu biti brže i lakše završeni; koncept frejmvorka je da se napravi skup jedna-veličina-koja-odgovara-svima rešenja, i sa prisnošću, proizvodnja koda bi logično trebalo da se dogodi. Ne postoje tvrdnje oko veličine koda koja je eventualno ugrađena sa izvozom proizvoda, niti oko njene efikasnosti i konciznosti. Korišćenje bilo kog bibliotekarskog rešenja neophodno povlači sa sobom dodatke i nekorišćena spoljna sredstva osim ako je program veznik kompajlera i objekta praveći tesni (mali, potpuno kontrolisani, i određeni) izvršni modul.

Problem se nastavlja, ali višedekadno industrijsko iskustvo je pokazalo da najefektivniji frejmvorci su zapravo oni koji evoluiraju iz refaktoringa čestog koda na poslovnom nivou, umesto korišćenja "jedna-veličina-koja-odgovara-svima" frejmvorka napravljenim od strane trećih lica za generalne namene. Primer toga bi bio kako korisničko sučelje u takvom paketu aplikacije kao kancelarija raste da ima čest izgled, osećaj, i atribute i metode razmene podataka, kao već što su jednom različiti skupovi aplikacije porasli objedinjeni u jedan skup koji je tešnji i manji; noviji/evoluirani skup koji može biti proizvod koji deli alatku integralnih biblioteka i korisničkih sučelja.

Ovaj trend u polemici donosi bitan problem oko frejmvorka. Pravljenje frejmvorka koji je elegantan, protiv onog koji se koristi isključivo za rešavanje problema, je i dalje umetnost više nego nauka. "Programska elegancija" implicira jasnoću, konciznost, i malo rasipanja (dodatne ili strane funkcionalnosti, od koje većina je definisane od strane korisnika). Za one frejmvorke koji definišu kod, na primer "elegancija" bi implicirala pravljenje koda koji je čist i čitljiv prosečnom programeru (i time je čitljivo moguće uređivati njim), protiv onog koji najviše generiše samo ispravan kod. Problem elegancije je razlog zašto su samo nekoliko softverskikh frejmvorka izdržali test vremena: najbolji frejmvorci su bili u mogućnosti da evoluiraju graciozno kao podnožna tehnologija na kojoj su napredno napravljeni. Čak i tamo, evoluirajući, mnogi takvi paketi će zadržati stare mogućnosti nadimajući konačan program kao što su drugačije zamenjene metode zadržane u paraleli sa novijim metodama.

Primeri uredi

Softverski frejmvorci obično sadrže znatna vođenja domaćinstva i kod alatke da bi pomogli u but-strepu korisničkih aplikacija, ali generalno se fokusirajući na specifične probleme domena, kao što su:

Arhitektura uredi

Prema Priju,[8] softverski frejmvorci se sastoje iz zaleđenih delova ivrućih delova. Zaleđeni delovi definišu sveobuhvatnu arhitekturu programskog sistema, misleći se na osnovne komponente i veze između njih. One ostaju nepromenjene (zamrznute) i bilo kom delu frejmvorka aplikacije. Vrući delovi predstavljaju one delove gde programeri koji koriste frejmvork da dodaju svoj kod da dodaju funkcionalnost specifičnu za svoj projekat.

U okruženju objektno-orijentisanog programiranja, frejmvork se sastoji iz apstraktnih i konkretnih klasa. Primeri takvih frejmvorka se sastoje iz komponovanja i nasleđivanja već postojećih klasa.[9]

Prilikom razvoja konkretnog programskog sistema sa softverskim frejmvorkom, programeri iskorišćavaju vruće delove u skladu sa specifičnim potrebama i neophodnosti sistema. Softverski frejmvorci se oslanjaju na Holivudski princip: "Ne zovite nas, mi ćemo vas zvati."[10] Ovo znači da korisnički definisane klase (na primer, nove potklase), dobijaju poruke iz već definisanih okvira klasa. Programeri obično rukuju sa ovim implementirajući apstraktnih metoda nasleđivanja.

Vidi još uredi

Reference uredi

  1. ^ Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology 
  2. ^ „Framework”. DocForge. Arhivirano iz originala 07. 10. 2018. g. Pristupljeno 15. 12. 2008. 
  3. ^ Vlissides, J M; Linton, M A (1990), „Unidraw: a framework for building domain-specific graphical editors”, ACM Transactions of Information Systems, 8 (3): 237—268, doi:10.1145/98188.98197 
  4. ^ Johnson, R E (1992), „Documenting frameworks using patterns”, Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, ACM Press: 63—76 
  5. ^ Birrer, A; Eggenschwiler, T (1993), „Proceedings of the European conference on object-oriented programming”, Frameworks in the financial engineering domain: an experience report, Springer-Verlag, str. 21—35 
  6. ^ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), „Architecture of the Earth System Modeling Framework (ESMF)”, Computing in Science and Engineering: 18—28 
  7. ^ Gachet, A (2003), „Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools”, Journal of Decision Systems, 12 (3): 271—281 
  8. ^ Pree, W (1994), „Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design”, Proceedings of the 8th European Conference on Object-Oriented Programming, Springer-Verlag: 150—162 
  9. ^ Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 978-0-471-95869-7 
  10. ^ Larman, C (2001), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd izd.), Prentice Hall, ISBN 978-0-13-092569-5 

Spoljašnje veze uredi