Univerzitet u Beogradu Fakultet Organizacionih Nauka

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

Mentor: dr Siniša Vlajić, Kandidat: Marina Ognjanović

Beograd Januar, 2010. Godine

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

Univerzitet u Beogradu Fakultet Organizacionih Nauka

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

Kandidat: Marina Ognjanović

Članovi komisije: dr Siniša Vlajić, doc _______________
_____________________

Beograd Januar, 2010. Godine
2

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

Razvoj sopstvenog okvira za generisanje desktop aplikacija
Apstrakt: Termin okvir (eng. framework) se veoma često koristi u softverskom inţenjerstvu, naročito kada se govori o projektovanju i implementaciji objektno-orijentisanog softvera. Najopštije, okvir se moţe definisati kao generator aplikacija odreĎenog domena, ili konkretnije okvir predstavlja skelet aplikacije, koji sadrţi kompletan kod osnovnih funkcija celog sistema, a koji se moţe prilagoditi za potrebe konkretne aplikacije. U ovom radu će biti prikazane definicije i osobine okvira, smernice i uzori projektovanja okvira, kao i načini njegovog dokumenovanja. U drugom delu rada će biti predstavljeno projektovanje i implementacija sopstvenog okvira za razvoj desktop aplikacija u C# programskom jeziku. Navedeni okvir na osnovu proizvoljnog domena problema, koji je predstavljen meta modelom, treba da generiše skelet aplikacije tronivojske arhitekture i implementira osnovne operacije nad bazom podataka (eng. CRUD) za definisani domen problema. Treći deo rada će sadrţati studijski primer: generisanje desktop aplikacije preko sopstvenog okvira. U zaključku će biti sumirane smernice za dalji razvoj sopstvenog okvira. Ključne reči: Okvir, desktop aplikacija, c#

3

The framework should. The second part of the paper will present design and implementation of own framework for developing desktop applications in C# programming language. Finally. a framework could be defined as an application generator for one particular domain.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Developing a desktop application generating framework Abstract: Framework as a term is very frequently used in software engineering. it represents a skeleton of an application. or more to the point. In this paper. the definitions and properties of frameworks. guidelines and patterns of framework design. especially in relation to object-oriented software design and implementation. generate application skeleton using three-tier architecture and then implement basic CRUD database operations for the defined problem domain. on the basis of an arbitrary problem domain represented by a meta model. as well as means of documenting a framework will be presented. conclusion summarizes the guidelines for further development of the implemented framework. which can be conformed to the needs of one specific application. Key words: Framework. The third part of the paper presents a case study example: generating a desktop application using the developed framework. that includes the complete code for the basic functions of a system. desktop application. c# 4 . In general.

.................................................................................. 40 2...................3 Problemi instanciranja i dokumentacije okvira ......................................................... 42 2.......................................................... 36 2.............................. Fine-grained) ....................... 24 2........7 Okvir crne kutije .........................................................................................1 Tri primera .................................................................... 22 2.5...........................6 Uzori projektovanja okvira ................2 Džonsonov princip razvoja okvira ...................................................................................4 Razvoj okvira po principima kompanije Ericsson Software Technology .4 Cena i iskustvo analize domena . composition issues) ................................................................................................................................ 28 2................................................. 5 1 Uvod ....... 29 2.......................... 34 2..............................................................................................................................1 Razvoj OO okvira po Markijeviču i Luceni.....................................................6...................... Pluggable Objects) ................................5........................9 Jezički alati ...................................3 Biblioteka komponenata ..... 19 2............................................................................................................ 19 2.................7 Problemi otklanjanja grešaka u instancama okvira............................ 32 2...................... 23 2.....................................................2 Pitanja kompozicije (eng............6 Fleksibilnost naspram složenosti i performansi ......................................................... 26 2....................6.......................................................... 9 2 Okvir aplikacije ...................... 18 2........................................3 Klasifikacija okvira..............................4........................................................................ 23 2......................................................... 17 2...5.....4....................6................3 Bošov princip razvoja okvira ................................ 25 2........................... 12 2.....................6..6........ 20 2.......1 Razvoj generatora aplikacija nasuprot razvoja aplikacije ...........................................5 Principi Ksavijera Amatriaina ........2 Okviri bele kutije ..................................................................................................................................................................4...........4 Značajna pitanja pri razvoju okvira ....................................... 14 2.................................................................................................................................................................................4.5 Uporedno evoluiranje instanci i okvira ....................................................................Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sadrţaj Sadrţaj .........4.............................................................................. 21 2..............................................6..6 Usitnjeni objekti (eng..........................................................6............ 29 2........6..................... 21 2..............6.........5.............................4....................5 Priključni objekti (eng............ 13 2...............4 Žarišne tačke ..................................................5 Projektovanje okvira ......................5...........................4..........2 Osobine okvira .. 39 2................................ 43 5 ..................................................................................... 30 2.........1 Defninicije okvira ........................................8 Vizuelni bilder ................................. 38 2.

......1.........................................5........................................................................ 85 4... 84 4........3 Projektovanje strukture softverskog sistema (aplikaciona logika .........................................................5 Automatsko programiranje ................................................................................ 76 4....................................................................................................................................................................................7 Dokumentovanje okvira .......................................7 Projektovanje ekranskih formi..2..3 Ponašanje softverskog sistema – sistemski dijagram sekvenci ..........................................1........................... 142 6 Reference ........ 52 4 Razvoj okvira ......................................................................... 83 4............................................................................................................6 Projektovanje skladišta podataka ...................2................................ 82 4......1................2 Projektovanje .................................................................................. 57 4......2... 108 4.......................................................................................5 Struktura softverskog sistema ........................... 101 4........... 109 4........ 87 4.............8 Zaključak ..... 148 6 .................................................................................................5 Korišdenje okvira... 83 4.2 Kontroler aplikativne logike........................................1...............................................................................................................................2......................... 78 4......poslovna logika ...... 54 4....... 106 4.......................... 52 3.........1 Analiza komponenata sistema ...................................................4 Dokumentovanje okvira ......................................................4 Desktop aplikacija .........................2................................................................................1 Analiza domena .. 48 3..............2.................................................................1 Larmanova metoda razvoja softvera ................................................................................................2 Primena okvira ................................3 Relacioni model ................................................5 Projektovanje aplikacione logike – database broker .....5............................4 Ponašanje softverskog sistema – definisanje ugovora o sistemskim operacijama...........................1 Analiza zahteva ............................................ 102 4....................................................................................... 48 3.......2 Tronivojska arhitektura ........................................................................................2 Opis zahteva pomodu modela slučaja korišdenja .......poslovna logika – sistemske operacije) .............................domenske klase) ............................................ 44 3 Značajni koncepti za razvoj sopstvenog okvira ..........konceptualni model ....1 Arhitektura softverskog sistema .............................. 55 4........................................................................................................................................3 Implementacija okvira..................................................2........2.......................................4 Projektovanje ponašanja softverskog sistema (aplikaciona logika .................................................................................. 128 5 Zaključak .................................................................................................................................................................................................................. 108 4......... 51 3............................ 49 3................... 83 4......................................................................Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2.............. 108 4.........................1......................................... 103 4.....

................................skladište podataka........... 131 Slika 39 Konkretne klase aplikacije..solution .......................................................................................................................................................................................................... 67 Slika 16 Sistemske operacije ............................................................................................................................................................................................................................................ 62 Slika 12 KKIOpsti ..................................................................................................................................................................................... 51 Slika 4 Konceptualni model okvira ........... 102 Slika 32 Kreiranje brokera ..................................................................sloution ................................................... 60 Slika 10 FOpsta .........................Kandidat ................................komponente ................................................. 94 Slika 31 Arhitektura softverskog sistema – broker.......................................................................Magacin ................ 102 Slika 33 Arhitektura softverskog sistema ..............................................................Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Popis slika Slika 1 Razvoj okvira nasuprot razvoju aplikacije .................................................................... 58 Slika 8 Forma "Prijemni ispit" ............... 68 Slika 17 Materijalizacija i dematerijalizacija objekata ...cela aplikacija sa konkretnim klasama........................................................................... 83 Slika 23 Arhitektura softverskog sistema.. 25 Slika 2 Tronivojska arhitektura ........... 103 Slika 34 konceptualni model ....... 90 Slika 30 Sistemska operacija .......................................... 129 Slika 37 Korisnički interfejs ...................................................... 89 Slika 29 Sistemska operacija ....................................................... 86 Slika 26 Dijagram softverskih klasa strukture ..............................................................konkretan slučaj .................. 54 Slika 5 Konceptualni model okvira ............................................................................struktura foldera ................ 64 Slika 13 Aplikativna logika........................ 128 Slika 36 Skelet aplikacije ........................................................................................... 87 Slika 27 Skelet aplikacije .......................................................................................................................................... 56 Slika 7 Korisnički interfejs ............................................................................................................................relacioni model ... 76 Slika 22 Konceptualni model ................................... 61 Slika 11 FOpsta ................................................................softverske klase strukture.......................................................................................... 72 Slika 19 Bridge uzor ............................................. 133 7 .............................................................................................................................................................................. 130 Slika 38 Visual Studio .................................................................. 69 Slika 18 Bridge uzor – opšti slučaj ..............................................................................................kreiranje forme .............. 66 Slika 15 Template method uzor .......................................... 85 Slika 25 Softverske klase strukture....apstraktna klasa kontrolera korisničkog interfejsa......C# projekti ................................................. 84 Slika 24 Arhitektura softverskog sistema ........................................................ 107 Slika 35 Pocetna forma okvira............... 65 Slika 14 Kontroler aplikativne logike ...................................................... 72 Slika 20 Arhitektura skeleta sistema .................................................................................................................................................................... 88 Slika 28 Sistemska operacija ..............kreiranje dizejnera forme ................................................................................................................opšta realizacija forme ...........................kreiranje kontrolera korisničkog interfejsa ............................................................................................................................................................................ 50 Slika 3 Tronivojska arhitektura ............................................................... 59 Slika 9 Forma "Cipelarnik" .......................................................................... 75 Slika 21 Žarišne i zamrznute tačke okvira ................................................................................................................................................................. 132 Slika 40 Visual Studio ....................................................................................................................................fajlovi ................................................................................................................................................. 55 Slika 6 Opšti uzor .......................

izmena CD-a........ 37 Tabela 2 Metoda KreirajEnable ................................. 147 Popis tabela Tabela 1 Uzori projektovanja ........ 98 Tabela 6 Isečak metode KreirajGetSet ......................... 139 Slika 49 Izmena člana..... 136 Slika 44 Brisanje člana .......................................................................................... 91 Tabela 3 Metoda KreirajKonstruktor ................izmena člana CD kluba .................................................................................................................................................................................................................... 92 Tabela 4 Metoda KreirajKonstruktorPK ...................................................................................Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 41 Pocetna forma ..................................................................... 135 Slika 42Kreiranje novog člana i njegovo snimanje u bazu .................................................................................................... 96 Tabela 5 Metoda KreirajPolja.......................... 136 Slika 45 Izmena podataka o članu (promena prezimena člana koji ima id 6) . 135 Slika 43 Brisanje člana ................................................................................. 141 Slika 50vKonceptualni model okvira......................................................................................................................................................................................................... 138 Slika 48 Lista iznajmljenih CD-ova ....................................................................................................................................................................................................uspesno obrisan član .................................odabir datuma .................................................................................................................................... 99 8 .................... 137 Slika 47 Promena postojedeg iznajmljivanja ................................................................... 144 Slika 51 Tronivojska arhitektura ...........komponente ........................................................................................................................................................... 146 Slika 53 Žarišne i zamrznute tačke okvira .......................................................................................................................................... 145 Slika 52 Skelet aplikacije ................................................................................... 146 Slika 54 Studijski primer ...................................................................................................... 137 Slika 46 Kreiranje novog iznejmljivanja ........................

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 1 Uvod Od početaka softverskog inţenjerstva četrdesetih godina prošlog veka do danas. raste njihova sloţenost. Neke kompanije su počele da nude uslugu razvoja “custom” softvera.. modularnom programiranju i apstrakciji podataka. uzrokovali gubitak imovine (usled loše zaštite softvera. a programeri su rezervisali vreme za pristup računaru ili zaduţivali operatere za konkretne zadatke.. mnoge kompanije su dobrovoljno davale kataloge sa komponentama za ponovnu upotrebu (npr IBM-ova grupa SHARE). Projekti su daleko premašivali budţet i rokove. od 1965-1985. Ulaz u računar su predstavljale bušene kartice. To je podstaklo razvoj softverskih jezika višeg nivoa: FORTRAN. novac. ali još uvek niko nije prodavao softverske pakete. i dobijao se uz računar. i svakih godinu-dve posao programera je bio prevoĎenje programa na novije računare. jer je bez tog softvera računar bio beskoristan. Kako je softver bio besplatan. Bilo kakvo planiranje i upravljanje razvojem softvera su bili skoro nemogući.). Već u to doba se pojavila ideja o ponovnoj upotrebi delova softvera. Interesantno je napomenuti da su sve do 1960-ih godina programeri često bile ţene. Razlikovao se hardver za poslovne i naučne aplikacije. identifikovala je mnoge probleme u razvoju softvera. programi su direktno zavisili od hardvera koji je bio ugraĎen. Takozvana softverska kriza. Hardver se menjao jako brzo. Termin softversko inţenjerstvo se javlja 1950-1960. Stalni ciljevi su poboljšanje produktivnosti softverskih inţenjera. U početku razvoja kompjutera. Dve konferencije o softverskom inţenjerstvu u Nemačkoj 1968 i 1969 se smatraju zvaničnim početkom profesije softverskog inţenjerstva. hakeri su uspevali da ukradu informacije. Širi se spektar namena aplikacija. Sistemski softver je bio besplatan. razvoj softvera konstantno napreduje. Računari su se nalazili u „mašinskoj sali”. 9 . a izlaz se čekao na štampaču. COBOL i ALGOL. i povećanje kvaliteta aplikacija za krajnjeg korisnika. Muškarci su bili na prestiţnijim i bolje plaćenim poslovima – bavili su se hardverom.

OOP. Disciplina – neki su smatrali da je jedini problem u nedostatku discipline kod programera Formalne metode – pokušaj da se primenom formalne inţenjerske metodologije u softversko inţenjerstvo. disciplina. model-driven development) – razvoj tekstualnih i grafičkih alata koji koriste transformacije modela i generisanje koda da bi 1 Po narodnom predanju srebrni metak je jedina vrsta metaka kojim se mogu ubiti vukodlaci i veštice. CASE alati. u terapiji Za softversku krizu je decenijama traţen “srebrni metak1”. ono učini jednako predvidivim kao druge grane industrije. timski rad. Trenutne tendencije u razvoju softvera su:   Aspekti (eng.. proglašavani su za “srebrni metak”:    Alati – strukturno programiranje. UML. profesionalizmu Postalo je jasno da magičnog rešenja nema. To je potpuno naučna metodologija.  Razvoj voĎen modelom (eng. 10 . ali su svi navedeni alati i tehnike doveli do inkrementalnog poboljšanja produktivnosti i kvaliteta. standardi.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad i čak uzrokovali smrtne slučajeve (zbog greške u proračunavanju doze zračenjem umrla su barem 3 pacijenta). saradnju sa klijentom. i prilagoĎavanje aplikacije tokom ţivotnog ciklusa projekta. Uglavnom se koristi kao izraz za jednostavno i neposredno rešenje. aspects) – obezbeĎuju alate za dodavanje ili uklanjanje generičkog koda. manje dokumentacije. Svaki novi alat. jednostavno i neposredno rešenje.  Eksperimentalno softversko inţenjerstvo – grana koja se bavi pravljenjem eksperimanata na softveru. Agilno programiranje – koje uključuje brz razvoj funkcionalnih jedinica softvera..  Profesionalizam – rad na etici. prikupljanjem podataka iz eksperimenata i postavljanjem zakona i teorema na osnovu tih podataka. dokumentacija. iterativnost. Softversko inţenjerstvo je mlada disciplina i još uvek se razvija. formalna metodologija. licencama.

to je pokušaj industrijalizacije razvoja softverskog sistema.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad generisali dobro organizovane fragmente koda koji sluţe kao osnova za kreiranje aplikacije.  Okviri – takozvane proizvodne linije softvera – sistematičan način da se proizvede familija softverskih sistema. umesto jednog individualnog proizvoda. Ovaj postupak zahteva dobro planiranu i razvijenu ponovnu upotrebu koda. 11 . U suštini.

okviri predstavljaju apstraktnu specifikaciju nekog tipa aplikacije. već samo obezbeĎuju funkcionalnosti pomoću kojih aplikacija radi. Prvi objektnoorijentisani okviri koji su zaista smatrani za okvire bili su MVC (eng. a sa druge strane ima okvira koji se mogu koristiti kao biblioteke klasa. naročito kada se govori o analizi i projektovanju objektno-orijentisanog softvera. Interesantno je primetiti da je većina prvobitnih okvira bila kreirana za projektovanje korisničkog interfejsa. zajedničkog poduhvata kompanija Epl. To se moţe posmatrati kao kontinuum sa tradicionalnim bibliotekama na jednom i sofisticiranim okvirom na drugom kraju. Okviri su slični softverskim bibliotekama. Termin okvir se veoma često koristi u softverskom inţenjerstvu. Drugim rečima to je skelet aplikacije. U istoriji okvira takoĎe je vaţno spomenuti ime kompanije Talidţent (eng. Apple) aplikacije. Taligent). čak i svaki školovani umetnik koristi metodologiju koja mu omogućava da usmeri svoj kreativni rad u ţeljenom smeru. „Common Point“). Drugi vaţni okviri iz ove početne faze su bili ET++ i Interviews. Sa druge strane. koji sadrţi kompletan kod osnovnih funkcija celog sistema. ali ne podrazumevaju neku konkretnu strukturu aplikacije. jer i jedni i drugi predstavljaju kod koji se moţe ponovo koristiti upakovan u API (eng. Hewlett-Packard). Ipak neke biblioteke se pomalo ponašaju kao okviri. Model View Controller) za Smalltalk i MacApp za Epl (eng. application framework) je apstrakcija. Oni su razvili grupu alata za ubrzan razvoj aplikacija pod nazivom „Zajednička tačka“ (eng. IBM i Hjulit-Pakard (eng. Dobro izabrana 12 . jer projektovanje softvera i dalje predstavlja spoj nauke i umetnosti! MeĎutim. application programming interface).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2 Okvir aplikacije Okvir aplikacije (eng. u kojoj generički kod za standardne funkcionalnosti moţe selektivno da se prekrije korisničkim kodom čime će se dobiti specifične funkcionalnosti[9]. Biblioteke sluţe za ponovnu upotrebu koda. koji se sastoji od više od stotinu objektno-orijentisanih okvira.[9] Često postavljano pitanje je da li korišćenje okvira sputava kreativnost programera? Na prvi pogled deluje da je tako. a koji se moţe prilagoditi za potrebe konkretne aplikacije[2].

itd. [27]  Okvir je konkretno. [17] kod za standardne funkcionalnosti moţe selektivno da se prekrije korisničkim kodom kojim će se dobiti specifične 13 . Sastoji se od konkretnih i apstraknih klasa. [9]  Okvir je skelet aplikacije.1 Defninicije okvira Ne postoji jedinstvena definicija okvira. Različite definicije okvira:  Okvir je biblioteka klasa koja sadrţi uzore interakcije izmeĎu objekata. odnosno skica aplikacije. Raznorodnost definicija nam pokazuje da nema slaganja oko toga šta je zapravo okvir aplikacije. specijalno kreiranih da se koriste zajedno. Klasa je prototip. [2]   Klasa je za objekat isto ono što je okvir za aplikaciju. isto kao što je okvir prototip. a koji se moţe prilagoditi za potrebe konkretne aplikacije. [5] Okviri su generatori aplikacija odreĎenog domena. ali nekompletno rešenje za probleme velike vaţnosti koji se ponavljaju. konkretno programer moţe da se posveti dizajniranju boljeg korisničkog interfejsa (funkcionalno i vizuelno). [11]  Okvir je apstrakcija u kojoj generički funkcionalnosti. 2. koji sadrţi kompletan kod osnovnih funkcija celog sistema.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad metodologija zapravo oslobaĎa umetnika od brige oko osnova. skica objekta. boljim performansama. i gotovo svako ko se bavio ovom granom softverskog inţenjerstva dao je svoju definiciju okvira. [16]  Okvir je skup kolaboracionih koncepata oblikovanih za jednostavnu ponovnu upotrebu. [9]  Okvir je logička struktura koja klasifikuje i organizuje sloţene informacije.

o Dekupluje zavisnosti izmeĎu objekata. o Često se mogu ponovo koristiti bez obzira na projektantske odluke visokog nivoa.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad   Definicija okvira po Dţonsonu i Futu (eng. okvir je grupa ugraĎenih „blokova“ za izradu softvera koje programeri mogu da iskoriste.  Metodologija o Usmerava projektovanje. izraţen kroz grupu apstraktnih klasa i načina na koji one saraĎuju. Beck and Johnson): okvir je projekat sistema ili dela sistema koji se moţe upotrebljavati iznova (eng. prošire. o Povećava fleksibilnost aplikacije korišćenjem apstrakcije. a koje mogu biti „prekrojene“ za individualnu primenu.2 Osobine okvira Šta čini jedan okvir? [12]  Omotač (eng. [30] Definicija okvira po Bošu (eng.  Arhitektura o Arhitektura predstavlja način na koji se implementiraju i povezuju komponente sistema. o Često se moţe ponovo koristiti bez obzira na zahteve aplikacije. wrapper) o Pojednostavljuje interfejs ka tehnologiji. ili prilagode za odreĎena softverska rešenja. [18] Definicija okvira po Beku i Dţonsonu (eng. reusable). [18]   Okviri su aplikacije na visokom nivou apstrakcije koje se odnose na jedan odreĎen domen. a koja se sastoji i od dizajna i od koda. [18] 2. Osobine okvira su: [11] 14 . Bosch): okvir je softverska arhitektura koja se moţe iznova koristiti. i čini ga konzistentim. o Smanjuje/eliminiše ponavljajuće zadatke. Johnson i Foote): okvir je grupa klasa koja čini apstraktan dizajn za rešenja familija problema.

Kod je jednostavniji za odrţavanje (čak i onima koji ga nisu implementirali). ali moţemo napraviti okvir za obezbeĎivanje perzistencije objekata. programeri ne moraju da počinju od nule svaki put kada pišu konkretnu aplikaciju. 2. okvir se sastoji od fizičkih komponenti. delove koda koji su predviĎeni za prilagoĎavanje potrebama konkretne aplikacije. već ostavlja programeru konkretna mesta koja treba da popuni odgoovarajućim kodom. Okviri pomaţu programerima da naĎu rešenja za domene problema i da lakše odrţavaju ta rešenja. Što je okvir sloţeniji. 3. Na primer: nema smisla praviti okvir za sabiranje dva broja (taj problem moţemo rešiti pravljenjem metode za sabiranje brojeva). Okvir je konkretan. Osobine dobro isprojektovanih okvira:  Uz okvire. zip fajlovi). Okvir diktira rešenje. čime se obično postiţe fleksibilnija aplikacija sa manje grešaka. kao i način na koji će se to uraditi. koje najčešće čine fajlovi. Primorava tim da kod implementira konzistentno. TakoĎe obezbeĎuju dobro 15 . i slično (dll. U čemu nam okvir pomaţe?     Pojednostavljuje rad sa sloţenim tehnologijama. Okvir pomaţe u rešavanju problema koji se ponavljaju. Vezuje pojedinačne komponente/objekte u korisnije celine. biblioteke. Drugim rečima. 4. Okvir odreĎuje arhitekturu sistema. Za razliku od toga okvir je jedna moguća realizacija. Okviri rešavaju vaţne probleme. ali je sa druge strane teţe naučiti kako koristiti okvir. to manje koda programer treba da napiše.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 1. Iako je pojam vaţnosti relativan. 5. To nije gotovo rešenje. Uzori projektovanja nisu okvir već korisne ideje koje programer po svom nahoĎenju realizuje u toku izvoĎenja projekta. Okvir je nekompletan. treba imati na umu da se okviri prave za rešavanje problema velike vaţnosti. cs.

okvir mora biti kompletiran. jer će nalaziti slične komponente i opisivaće sistem koji ţele da naprave na slične načine. [18]     Vaţno je shvatiti da softver ne moţe biti iznova upotrebljavan ako se niti jednom ne upotrebi. proširiv i razumljiv. bez upotrebe okvira. [30] Krajnji cilj u kreiranju okvira je da programer uopšte ne piše kod. tj.[30] Okvir bi takoĎe trebalo da naĎe načine da minimizira potencijalne greške programera i da proširi meĎuplatformsku prenosivost. okvir opisuje vrste objekata koji su vaţni u domenu i obezbeĎuje rečnik pomoću kog se govori o problemu. [29] Štaviše. [18]  Koliko god elegantan ili dobro projektovan okvir bio. okviri povećavaju produktivnost programera. okvir je samo uopštavanje već postojećih primera u okviru odreĎenog domena aplikacija. upotreba malog broja tipova komponenti iznova i iznova i pisanje što je manje moguće koda. fleksibilan. Dva iskusna korisnika istog okvira će lakše razumeti aplikacije onog drugog.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad projektovanu infrastrukturu tako da kada se kreiraju i dodaju novi delovi. koji ih čine konkretnijim i lakšim za razumevanje. mogu biti integrisani uz minimalan uticaj na druge delove okvira. Ekspert za odreĎeni okvir vidi svet kroz taj okvir i prirodno će ga podeliti na te iste komponente.[18] Ciljevi izrade okvira bi trebalo da budu izrada aplikacija od postojećih komponenti.[29] Da bi uspeo.[29] 16 . [29] Okvire bi trebalo ilustrovati primerima.   Okviri nameću model koji zahteva od programera da se prilagode.  I konačno. Sa druge strane. on neće biti upotrebljen osim ako cena razumevanja i zatim korišćenja njegovih apstrakcija nije niţa nego procenjena cena pisanja tih funkcionalnosti od nule.

 Aplikacioni okvir – Aplikacioni okviri daju podršku razvoju jedne vrste softverske aplikacije ili dela aplikacije.3 Klasifikacija okvira Opšta podela okvira[9]:  Okviri za opštu namenu. file) ili podrška distribuiranom informacionom sistemu. kao što su pristup datotekama (eng.Net)  Konkretni okviri: o MFC (Microsoft Foundation Classes) okvir. Još jedna Talidţentova podela[30]: 17 . On uobličuje našu viziju budućeg sistema. na primer: o Rails (Ruby) o Zend. application domain). Talidţent je razvio različite načine klasifikovanja okvira. Jedna od njih je[30]:   Konceptualni okvir – pomaţe nam da identifikujemo bitne koncepte iz domena aplikacije (eng. CodeIgniter (PHP) o Spring. Okvir projektovanja ili podrške – pomaţe nam da transformišemo model domena aplikacije u projekat softverskog sistema. GWT (Java) o BFC (. Uzori projektovanja i arhitekturalni stilovi mogu da pomognu pri projektovanju. mada sami po sebi nisu okvir. Primer bi mogao da bude okvir za razvoj grafičkog korisničkog interfejsa. o OMG (Object Management Group) o CORBA i o DCOM i COM+ (Microsoft). TakoĎe.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2. ovi okviri nude horizontalne usluge na nivou sistema.

18 .  Okviri koji se zasnivaju na podacima koriste polimorfizam. U svakom slučaju treba imati na umu da je razvoj pomoću objektno-orijentisanih okvira relativno nov pristup. Na primer. alat za automatizaciju instanciranja kreira klase i izvorni kod. TakoĎe se moramo setiti da su i prakse objektno-orijentisanog projektovanja i implementacije isto tako relativno nove. Neophodno je napomenuti da ove tačke same po sebi nisu ni prednosti ni mane. Najšire prihvaćena klasifikacija je verovatna ona koju je napravio Dţonson. a po kojoj okviri softvera mogu biti podeljeni na okvire bele. Da bi se kreirala aplikacija preko okvira. mora se razumeti implementacija okvira. jer programer mora da piše kod (apstraktne klase se prekrivaju konkretnim klasama). Pristup crne kutije ne zahteva od korisnika okvira da poznaju detalje funkcionisanja okvira. Kod okvira crne kutije instance se proizvode pomoću konfiguracionih skripti.4 Značajna pitanja pri razvoju okvira Iako je razvoj pomoću okvira u osnovi izuzetno efikasan. U daljim odeljcima ćemo razmotriti sedam tačaka na koje se mora obratiti paţnja kada se bira model okvira. Na osnovu konfiguracije. postoji više stavki koje bi trebalo prodiskutovati. moţe se koristiti grafički čarobnjak (eng. crne i sive kutije [29].Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad  Okviri koji se zasnivaju na arhitekturi koriste nasleĎivanje i mogu biti komplikovani za upotrebu. ali mogu biti previše ograničavajući. Okviri koji poseduju karakteristike i jednih i drugih se nazivaju okvirima sive kutije. Obično dobro dizajniran okvir ima jezgro koja se zasniva na arhitekturi i slojeve koji se zasnivaju na podacima. koji se nazivaju i „okviri bazirani na arhitekturi“. i oni su najbrojniji. wizard) koji vodi korisnika korak po korak kroz proces instanciranja okvira. lakši su za korišćenje. Okviri bele kutije. dozvoljavaju instanciranje samo kroz kreiranje novih klasa. Stoga se ovakvi okviri nazivaju i “okviri bazirani na podacima” i u opštem slučaju se jednostavnije koriste. 2.

pokrivenost domena. composition issues) Integrisanje okvira da bi se ispunili zahtevi aplikacije nije neuobičajeno. 2. integracija okvira je neizbeţna realnost.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Procena tehnologije okvira koja će biti predstavljena ovde se bazira na opservacijama različitih autora po pitanju razvoja i instanciranja više različitih okvira. ali se i dalje postavlja pitanje da li je kreiranje tog okvira vredno truda. moţe se desiti da je isplativije kreirati pojedinačne aplikacije. kada okvir postane funkcionalan. nemogućnost pristupa izvornom kodu i nedostatak standarda za okvir. Kada razvijamo okvir i očekujemo da ga neko koristi.1 Razvoj generatora aplikacija nasuprot razvoja aplikacije Neophodno je biti svestan odnosa uloţenog rada i dobiti kada se bira izrada okvira umesto izrade posebnog softverskog sistema. S druge strane. Pri izboru se mnogo češće nego što bi to ţeleli nalazimo u nedoumici. razvoj okvira se moţe sam od sebe isplatiti kroz generisanje više aplikacija preko okvira.4. Čak i ako hoćemo. 2. Postavlja se pitanje da li ćemo kreirati aplikacije ovakvog domena još koji put. Ova pitanja kompozicije se ne smeju shvatiti olako. Majkl Metson (Michael Mattson) smatra da postoji bar šest zajedničkih problema na koje se nailazi u razvoju aplikacija i okvira kada se pokušava integracija dva ili više okvira. Vaţno je imati na umu da će razvoj okvira koštati barem koliko i razvoj jedne pojedinačne aplikacije.2 Pitanja kompozicije (eng. namere u projektovanju. a verovatno i mnogo više. Okviri se često napuštaju ili se od njih odustaje jer ne postoji mogućnost da se lako integrišu sa drugim 19 . Uvek je dobra ideja proveriti kako su slični sistemi ostvarili zahteve klijenata. Svi ovi problemi proističu iz grupe od pet opštih slučajeva: kohezivno ponašanje. a ne okvir za njihov razvoj. Moţda se čak ispostavi da je svaki od tih sličnih sistema instanca našeg okvira.4.

6.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad okvirima. Jedan od načina na koji se razmatra kompozicija pri razvoju okvira je da se postavi skup API-ja koji učauruju servise koje okvir obezbeĎuje.3 Problemi instanciranja i dokumentacije okvira Okviri bele. kao i za proširivanje okvira. Mogućnost da se korišćenjem okvira napravi konkretan softverski sistem zavisi od upotrebljivosti mehanizama za korišćenje okvira i od dokumentacije okvira. detaljnije će biti objašnjene u poglavlju 2. Drugi pristup je pravljenje "kuvara" koji opisuju kako bi trebalo primeniti okvir i koji su za to neophodni koraci.4) stavlja fokus na fleksibilne tačke okvira. 20 . Mnoge smernice za pravljenje dokumentacije su predloţene za okvire.7. Treći pristup je preslikavanje arhitekturalnih rešenja koja se koriste u projektovanju okvira. U tom slučaju. ukoliko se radi o softveru sa otvorenim kodom. ne postoji jasan standard. Jedan od pristupa je navoĎenje uzora projektovanja. MeĎutim. ako je u pitanju kompozicija mnogo okvira.4. crne i sive kutije imaju strmu krivu učenja. Integracija okvira nije jednostavan posao. ovaj pristup je dosta skup ako se ne postavi unificirano posredovanje izmeĎu komponenata kompozicije. Hot spots. Najsigurniji pristup je korišćenje dva ili više od pomenutih pristupa. mali broj ljudi će ga koristiti ili odrţavati. Detaljnije o dokumentovanju okvira biće razmatrano u poglavlju 2. Ako je okvir loše dokumentovan. pa se kompozicija mora ozbiljno razmotriti u toku razvoja. Trebalo bi da postoji dokumentacija za korišćenje okvira. Ovakvi kuvari sadrţe veliki broj "recepata" koji neformalno opisuju kako rešiti specifične probleme u procesu instanciranja okvira. posrednički sloj će funkcionisati kao "lepak" izmeĎu elemenata kompozicije. Iako postoji mnogo različitih mogućih pristupa dokumentovanju okvira. Pristup koji se bazira na karticama ţarišnih tačaka (eng. 2. koji mogu da pomognu razumevanju procesa instanciranja.

Ovaj proces mogu predstavljati izmene u arhitekturi. rešavanje novih zahteva i mnogi drugi izvori promene. ako je odabrani domen previše suţen. a koje će biti nepotrebne ili suvišne. Vaţno je imati na umu koje ţarišne tačke će biti potrebne ili neophodne s obzirom na zahteve. analiza domena pokriva celu jednu klasu problema. Sa druge strane.5 Uporedno evoluiranje instanci i okvira Kako vreme prolazi i okvir sazreva. primenjivost okvira je umanjena. praviti prototipove ili analizirati slične softverske sisteme. jedna od faza razvoja je analiza domena. Povrh toga. širokom domenu je 21 . aplikacije kreirane korišćenjem tog okvira će takoĎe evoluirati i menjati se. a kreirane aplikacije će biti suviše slične da opravdaju trud uloţen u izradu okvira. gubljenje je vremena da se prikupe i ocene informacije i resursi.4. biće neophodno uposliti osobe upoznate sa domenom. okviri se koriste da generišu aplikacije za jedan unapred odreĎen domen. Za razliku od faze izrade liste zahteva za softverski sistem. 2. vreme razvoja i cena izrade okvira će biti preveliki. U tu svrhu. Nema jasnog rešenja. menja se i evoluira u skladu sa zahtevima. dobro projektovan i implementiran okvir neće biti tako nestabilan kao loš okvir. Kako se izboriti sa evolucijom i aplikacije i okvira? Aplikacije zasnovane na okviru bi mogle da postanu neupotrebljive ako se okvir promeni ili se obustavi rad na njemu. Ako je domen prevelik.4 Cena i iskustvo analize domena Kako je već ranije navedeno.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2. odbijajući da koriste bilo koji okvir koji nisu sami pravili.4. Zadatak analize domena je da sagleda veličinu i sloţenost izabranog domena. Pronalaţenje izvora iskustva u tako komplikovano. Jedini moguć savet u takvoj situaciji je da se paţljivo razmotri okvir koji će biti korišćen. i većina ljudi će verovatno patiti od "nije naše" sindroma. U meĎuvremenu. U tom slučaju.

jer dinamičko povezivanje uvodi redundansu (eng. i način na koji će se vršiti aţuriranja okvira.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Pod "dobro dizajniran" podrazumeva se da bi okvir trebalo da ima dobru dokumentaciju i pri tome odgovara potrebama domena problema. ovaj pristup vodi ka povećanju sloţenosti i problemima sa performansama. sloţenost procesa instanciranja. zajedničkih osobina objektno-orijentisanih jezika. Okvir koji odrţava koncept objektno-orijentisanog učaurenja i ima dobro definisan javni interfejs će verovatno ostati kompatibilan sa budućim verzijama na nivou interfejsa kroz sve nadgradnje i revizije. Iz tog razloga. Iako je 22 .6 Fleksibilnost naspram sloţenosti i performansi Kako je već navedeno. koji su zahtevi ispunjeni a koji ne. Proširivost se postiţe korišćenjem nasleĎivanja i dinamičkog povezivanja. Procena dizajna i/ili implementabilnosti okvira nije uvek jednostavna. Korišćenje ţarišnih tačaka povećava sloţenost okvira. a zarad fleksibilnosti. Ovaj pristup proizvodi generator aplikacije koji je sloţeniji i proširiviji od klasičnih softverskih sistema. MeĎutim. i ponekad ta dodatna funkcionalnost moţe biti nezgodan dodatak. overhead) čije će korišćenje u sistemu umanjiti performanse. okviri se prave da budu fleksibilni i opšti. Ako ne postoje zahtevi za "dodatnim" ţarišnim tačkama. bilo sloţenog redizajna kod svake nove verzije ili laganog aţuriranja kompatibilnog sa starim verzijama 2. Način aţuriranja okvira sadrţi planove za aţuriranje okvira. kako je gore prikazano.4. u pokušaju da se pokriju širi domen umesto konkretnih problema. gde kreator okvira ne sme ni previše konkretizovati ni previše generalizovati okvir. mora se razmotriti iskustvo dizajnera. Ovakav kompromis čini neophodnim paţljiv izbor ţarišnih tačaka. postoje kompromisi na uštrb performansi. Vaţno je primetiti da je uobičajeno da programeri uvode neodgovarajuće ţarišne tačke misleći da će time okvir biti "moćniji". veća sloţenost neće pomoći u smislu funkcionalnosti.

2.4. Okviri su generatori aplikacija koji su direktno vezani za specifičan domen problema. Cena odrţavanja ovako konfuznog koda je neizbeţno visoka. Preplitanje ţarišnih i zamrznutih tačaka učiniće korišćenje okvira teţim. ovo rešenje ne obuhvata sloţenost koju uvodi mešavina koda ţarišnih i zamrznutih tačaka. Jedno od mogućih rešenja koje olakšava otklanjanje grešaka je odvajanje zamrznutih i ţarišnih tačaka okvira i upotreba preduslova i postuslova u svakoj metodi koda zamrznutih tačaka.5 Projektovanje okvira Objektno-orjentisani okviri su kamen temeljac modernog softverskog inţenjerstva. da ne bi greškom promenili kod zamrznutih tačaka. Posledica toga je da se pri otklanjanju grešaka aplikacije doĎe do koda samog okvira. inače se moţe desiti da bude kreiran gigantski okvir za jednu upotrebu. Shodno tome. moraju postojati tačke fleksibilnosti okvira koje mogu biti prilagoĎene za potrebe konkretne aplikacije. Tačke fleksibilnosti okvira se nazivaju ţarišne tačke. familiju srodnih problema. koji će se koristiti kao potvrda da su pozivi tim metodama validni. Okviri su nekompletni. 2.7 Problemi otklanjanja grešaka u instancama okvira Kada se aplikacija generiše preko okvira uobičajeno je da se kod okvira izmeša sa konkretnim kodom vezanim za aplikaciju. MeĎutim. potvrde izvršenja će obavestiti o bilo kom pogrešnom ulazu ili povratnoj informaciji prosleĎenim kôdu zamrznutih tačaka. jer korisnici okvira (programeri) moraju paţljivo da menjaju postojeći i uvode novi kod. Ţarišne tačke su apstraktne klase ili metode koje moraju biti implementirane [17]. trebalo bi da postoji samo tamo gde je neophodna. tj. i kao takvi 23 . koji ne sme biti promenjen. TakoĎe. pa će praćenje i otklanjanje grešaka biti mnogo lakše.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad fleksibilnost vaţna i korisna. Razvoj okvira ubrzano biva prihvatan svuda zahvaljujući mogućnosti ponovne upotrebe izvornog koda.

u ovom stadijumu se koriste paterni projektovanja. Jezgro je uvek konstantan i sveprisutan deo svake instance okvira. definiše se jedan deo ţarišnih i zamrznutih tačaka. čime se generiše softverski sistem. application specific) za svaku od ţarišnih tačaka. a takoĎe se uokviruje proširivost i fleksibilnost predloţena u analizi domena. Modeliraju se ţarišta i zamrznute tačke (recimo korišćenjem UML dijagrama). Na slici 1 stadijumi procesa razvoja okvira se porede sa fazama klasičnog objektno-orijentisanog programiranja.5. Zamrznute tačke. Kako je već napomenuto. Da bi obuhvatili ove zahteve. Vaţno je napomenuti da će svaka od ovih aplikacija imati zajedničke zamrznute tačke okvira. Analizom domena se pokušavaju otkriti zahtevi u pogledu domena i potencijalni zahtevi u budućnosti. su delovi koda koji su već implementirani unutar okvira i koje pozivaju jednu ili više ţarišnih tačaka koje je implementator kreirao. Tokom analize domena. uzimaju se u obzir prethodno objavljena iskustva. za razliku od ţarišnih tačaka. zapravo konkretna aplikacija.[17] 2. Tačke na kojima nije moguće vršiti izmene čine jezgro okvira. Neke osobine okvira se ne mogu isključiti po potrebi i ne mogu se jednostavno izmeniti. 24 . U finalnom. stadijumu instanciranja.1 Razvoj OO okvira po Markijeviču i Luceni Tri glavna stadijuma razvoja svakog okvira su[17]:    analiza domena. mora se implementirati kod vezan za aplikaciju (eng. lična iskustva i standardi. frozen spots). Da bi se generisao izvršni kod. Stadijum razvoja okvira definiše apstrakcije okvira. postojeći softverski sistemi slične namene. koje se često naziva zamrznute tačke okvira (eng.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad ne mogu se izvršavati. projektovanje okvira instanciranje (korišćenje) okvira. implementiraju se ţarišta.

klasičan razvoj objektno-orijentisanog softvera se razlikuje od razvoja okvira. Kod objektno-orijentisanog programiranja. Kao konačan rezultat klasičnog objektnoorijentisanog razvoja dobija se izvršna aplikacija. faza analize problema sluţi za proučavanje zahteva samo jednog problema.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Analiza domena Projektovanje rešenja Implementacija Aplikacija Tradicionalni razvoj objektno-orijentisanog softvera Analiza domena Projektovanje okvira Razvoj okvira Aplikacija 1 Aplikacija 2 Aplikacija n Korišćenje okvira Slika 1 Razvoj okvira nasuprot razvoju aplikacije [17] Kako vidimo sa slike 1. analiza domena okvira obuhvata zahteve za čitav domen problema. Sa druge strane. dok se primenom okvira dobija više izvršnih aplikacija. 2.5. [29] 25 .2 Dţonsonov princip razvoja okvira Dţonson objašnjava razliku izmeĎu "idealnog" i "dobrog" načina za razvoj okvira i softvera uopšte.

definišući apstrakcije i prikupljajući primere programa koji bi trebalo da budu izraĎeni. Prvo razdvaja dve različite aktivnosti u razvoju okvira:   razvoj jezgra okvira interne dopune okvira. analizira kako će druge aplikacije moći da upotrebe okvir i pravi dokumentaciju i sistem obuke dve grupe za razvoj aplikacija koje pokušavaju da upotrebe okvir i stavljaju primedbe po pitanju toga koliko ga je teško ponovno upotrebiti. analizirajući sve moguće postojeće primere. stare aplikacije rade dobro. podeliti projekat u tri grupe   grupu za razvoj okvira koja kreira okvir.5. 2. uveriti se da postoji bar nekoliko programera u timu koji su već razvijali aplikacije za taj domen. 26 . Tako da je iako-ne-idealan-ali-dobar način razvoja okvira da se prvo izaberu dve aplikacije u domenu koje bi trebalo da budu kreirane preko okvira. pa ne postoji finansijski povod da se konvertuju da koriste novi softver. Zatim se projektuju apstrakcije koje mogu biti specijalizovane tako da pokriju sve primere i izvedu teoriju kako bi objasnili ove primene. Ovaj idealni put je nemoguće ispratiti detaljno iz dva razloga   veoma je komplikovano i gubljenje je vremena izvršiti detaljnu analizu domena.3 Bošov princip razvoja okvira Boš [18] daje malo drugačiji pregled procesa razvoja okvira.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Idealan način se sastoji od tri osnovne faze razvoja. Prvo se analizira domen problema. Na kraju se okvir testira tako što se koristi da reši konkretne probleme.

Sa druge strane. testiranje okvira 2. dok je namena apstraktnih klasa ili da budu nevidljive ili da budu upotrebljene kroz podklase. internih dopuna okvira i "dopuna vezanih za aplikaciju". faza razvoja okvira. Namena konkretnih klasa je da budu nevidljive i transparentne krajnjem korisniku (npr. U fazi razvoja okvira. Pošto se okvir zasniva na delovima koje implementira korisnik. Konačna aplikacija kreirana iz okvira sastoji se od elemenata jezgra okvira. 3. biće potrebno mnogo stručnjaka u timu i proces bi mogao da postane dug i skup. Ako se pojavi greška u okviru u toku razvoja aplikacije: ko će ispraviti grešku u okviru i da li bi aplikacije koje rade i na koje ne utiče ta greška trebalo da se nadograde na poslednju verziju okvira? 27 . interne dopune okvira prave dodatne klase koje formiraju odreĎeni broj biblioteka klasa. glavne faze razvoja su: 1. U fazi upotrebe okvira dolazi se do vaţnog pitanja. često nepredviĎenih načina. osnovni alat za skladištenje). jednostavno nije izvodljivo testirati sve aspekte okvira. ako je okvir suviše uzak verovatno će morati da se prilagodi svakoj novoj primeni koja iskrsne. analiza domena. S obzirom da se okvir moţe upotrebiti na mnogo. koja je uobičajeno ona koja zahteva najviše truda i čiji je cilj pravljenje dizajna koji se moţe ponovo upotrebiti u okviru odreĎenog domena a. d. projektovanje arhitekture. faza upotrebe ili instanciranja gde se razvijaju aplikacije.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Razvoj jezgra okvira se sastoji i od apstraktnih i od konkretnih klasa u domenu. implementacija okvira. pri odreĎivanju širine domena. postoji problem izbora valjane veličine: ako je okvir preširok. c. b. faza evoluiranja i odrţavanja okvira. e. praktično je nemoguće testirati ga u potpunosti pre puštanja u upotrebu. U ovom modelu. projektovanje okvira. Oni obuhvataju uobičajene implementacije jezgra okvira i mogu biti ili podklase koje predstavljaju uobičajene upotrebe koncepata obuhvaćenih nadklasama ili kolekcija klasa koja predstavlja specifikaciju za kompletno instanciranje okvira u konkretnom kontekstu.

use cases) bi trebalo da budu podeljeni na one vezane za okvir i one vezane za aplikaciju i takoĎe bi trebalo da budu podeljeni na funkcionalne i nefunkcionalne. kao i lista zahteva za okvir. Isto tako bi trebalo razviti statični model za svaku od aplikacija. Informacije bi trebalo prikupiti iz što je moguće više izvora.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2. U skladu sa prethodno pomenutm Talidţentom. uvodeći apstrakcije zajedničke za više aplikacija u okvir. Trebalo bi ispitati postojeća rešenja. trebalo bi istraţiti postojeće okvire u pokušaju da se iskoristi što je više dizajna moguće. na kraju. TakoĎe bi trebalo predvideti listu budućih zahteva za okvir. MeĎutim. proces razvoja okvira mora pratiti četiri vaţne smernice koje bi mogle da budu shvaćene kao sumiranje prethodne liste[30]:     Praviti okvire iz postojećih problema i rešenja Razvijati male. kao priprema za identifikovanje okvira. 28 .5. uz učešće klijenta i korišćenje prototipova. samo apstrakcije koje pripadaju domenu okvira bi trebalo uvesti u okvir. Tim projektanata bi trebalo da ima članove koji poseduju znanje vezano za svaki domen problema svake od pojedinih aplikacija i člana koji poznaje koncepte projektovanja okvira. Pri projektovanju okvira trebalo bi obezbediti listu zahteva za bar dve aplikacije. Koristeći grafičku prezentaciju. fokusirane okvire. Podsistemi bi trebalo da imaju jaku koheziju i slabo kuplovanje. Zahtevi i slučajevi korišćenja (eng. Tretirati okvire kao kompletne proizvode time što će biti obezbeĎena potpuna dokumentacija i podrška. Apstrakcije visokog nivoa bi takoĎe trebalo da budu identifikovane. Razvijati okvire iterativnim putem. trebalo bi projekat jasno prezentovati svim učesnicima projekta. i time što će biti planirana distribucija i odrţavanje. a ostale zanemariti. a velike okvire struktuirati kroz pod-okvire. I.4 Razvoj okvira po principima kompanije Ericsson Software Technology TakoĎe je interesantno baciti pogled na to kako kompanija kao što je Swiss Ericsson modelira proces razvoja okvira.

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

2.5.5 Principi Ksavijera Amatriaina

Ksavijer Amatrianin[18] veruje da je klasični "prvo analiza" pogled na projektovanje modela retko adekvatan za projektovanje okvira (neki autori tvrde da ovaj pristup nije adekvatan ni za jedan tip projektovanja softvera). Pri projektovanju okvira očigledno je da mora biti izvršena neka početna analiza domena, kako bi se shvatili osnovni zahtevi i različite tačke gledišta koje prezentuju različite interesne strane. MeĎutim, cilj ne moţe biti razumevanje i modeliranje celog domena od početka, već je vaţno upamtiti da pri izradi okvira mi ne samo da implementiramo infrastrukturu za postojeće aplikacije, već mislimo i na budući razvoj domena. Amatrianin veruje u pristup izrade okvira voĎen aplikacijom kakav je prezentovao Dţonson i u kom je proces razvoja okvira iterativan i gde je povratna informacija od korisnika neophodna na konstantnoj osnovi. Ne samo da nije neophodno prethodno uraditi model analize domena pre započinjanja projektovanja okvira, nego je okvir taj koji na kraju generiše odgovarajući metamodel domena.

2.6 Uzori projektovanja okvira
Softverski uzori predstavljaju opšta rešenja koja se mogu iznova koristiti za uobičajene probleme u razvoju softvera. To nisu gotova rešenja koja se mogu direktno prevesti u kod, već opisi ili šeme koji pomaţu za rešavanje problema u različitim kontekstima problema [9]. Uzori se takoĎe definišu kao trodelna pravila koja uspostavljaju relaciju izmeĎu nekog problema, njegovog rešenja i njihovog konteksta [2]. U ovom poglavlju će biti dat pregled uzora koji su identifikovani kao značajni pri razvoju okvira, uglavnom u fazama analize domena i projektovanja okvira [18][19].

29

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

2.6.1 Tri primera Kontekst Odlučeno je da se pravi okvir za odreĎen domen problema Problem Kako započeti projektovanje okvira? Sile (Forces) Apstrakcije nastaju generalizacijom konkretnih primera. Gotovo svaki pokušaj odreĎivanja ispravne apstrakcije „na papiru“, bez praktične primene, je osuĎen na neuspeh. Niko nije toliko pametan. S obzirom da je okvir projekat koji moţe da bude upotrebljen više puta, logično je razvijati ga iz stvari čiji bi projekat trebalo da bude. Što se više primera uzme u obzir, to će okvir biti generičkiji, meĎutim:   Analiziranje aplikacija je komplikovano. Ne sme biti previše primera ili okvir nikada neće biti završen. Upotreba okvira olakšava razvoj aplikacija, čak i kada je okvir komplikovan za upotrebu. Kada se jednom završi prva verzija okvira, pravljenje još primera će biti lakše.  Projekti za koje treba mnogo vremena da se doĎe do nečeg konkretnog imaju tendenciju da budu otkazani. Obično postoji samo kratka trţišna prilika koja se mora ispoštovati. Ako projekat ne počne da generiše prilive u nekom trenutku, organizacija će naići na probleme sa protokom novca. Klima u kompaniji se menja, i sistem mora biti izgraĎen pre nego što se njegovi nosioci prebace na druge projekte ili u druge kompanije. Rešenje Razviti tri aplikacije za koje verujete da će vam okvir pomoći da ih napravite. Ove aplikacije bi trebalo da same isplate razvoj okvira.

30

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

Argumentacija Okvir koji moţe biti više puta upotrebljen ne moţe se razviti površnom analizom domena problema. Vrlo je teško postaviti ispravne apstrakcije. Eksperti u domenu neće razumeti kako treba postaviti apstrakcije koje intuitivno razumeju, dok programeri neće razumeti domen dovoljno dobro da izvedu apstrakcije. Štaviše, često postoje apstrakcije koje se ne pokazuju sve dok ne doĎe do korišćenja okvira. Često ove "skrivene" apstrakcije nemaju fizičke analoge (npr. objekti strategije). Mogućnost generalizacije za odreĎenu vrstu aplikacije moţe doći jedino iz projektovanja više aplikacija i odreĎivanja koje od apstrakcija se koriste kroz te aplikacije. Generalizacija na osnovu jedne aplikacije je retkost. Mnogo je jednostavnije generalizovati na osnovu dve aplikacije, ali je i to teško. Opšte pravilo bi glasilo: napraviti aplikaciju, zatim napraviti drugu aplikaciju koja se malo razlikuje od prve, i na kraju napraviti treću aplikaciju koja se još više razlikuje od prve dve. S obzirom da sve tri aplikacije potpadaju pod domen problema, zajedničke apstrakcije će postati očite. Okvir neće biti gotov posle ove tri aplikacije. Očekivano je da on nastavi da evoluira. Mogao bi čak da bude koristan i za prikupljanje još više primera. MeĎutim, ne treba imati previše primera u startu, jer će se okvir sigurno menjati! Postoje dva pristupa u razvoju ovih aplikacija. Po prvom, aplikacije se razvijaju jedna za drugom od strane istog tima. To omogućava timu da počne da koristi uočene apstrakcije odmah, čak i po cenu suţavanja domena. Po drugom pristupu, aplikacije se razvijaju paralelnom od strane odvojenih timova. Ovaj pristup omogućava diverzifikaciju i različita gledišta na uštrb vremena koje će biti potrebno da se ove aplikacije unificiraju u budućnosti. U slučajevima kada je programer izradio odreĎeni tip aplikacije mnogo puta, postoji mogućnost da se isprojektuje okvir bez prethodne izrade primera. Ovo nije kontraprimer svemu navedenom, nego se zasniva na činjenici da je programer napravio svoje primere pre nego što je odlučio da započne okvir.

31

Početna verzija okvira će verovatno biti okvir bele kutije. i odjednom se shvati da bi trebalo da se isprojektuje okvir. često je moguće napraviti dobar okvir. ponekada se prave serije aplikacija bez pokušaja da se iskoristi bilo šta od koda iz prethodnih. drugi na polimorfnoj kompoziciji.6. a ne kompletna prava vlasništva aplikacije. Iako će aplikacija iziskivati izmene okvira. trudeći se da kreirani sistem bude fleksibilan i proširiv. često je teško dobiti prava da se iskoristi kod pisan za jednu aplikaciju u drugoj aplikaciji. prava vlasništva će ostati na programeru. Kod će verovatno morati da se refaktoriše kada se bude upotrebljavao.2 Okviri bele kutije Kontekst Započeto je projektovanje druge aplikacije Problem Neki okviri se jako mnogo zasnivaju na nasleĎivanju. ali će na ovaj način okvir biti mnogo bliţe finalnom nego da je razvijana samo jedna aplikacija. MeĎutim. Pošto su već razvijene te prve tri aplikacije. Šta treba koristiti? 32 . Kada se pravi više aplikacija.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Implementacija Najočigledniji način primene ovog paterna je jednostavno pravljenje tri aplikacije u nizu. Treba obratiti paţnju na činjenicu da nema potrebe za nekim specijalnim tehnikama objektno orijentisanog projektovanja kada se kreiraju ove aplikacije. Treba koristiti samo uobičajene tehnike. Drugi način primene ovog paterna je pravljenje prototipova za više aplikacija bez kreiranja konačnih verzija aplikacija. Slični paterni Ovo je specijalan primer "Pravila trojke". Jedna od prednosti ovog pristupa je da se moţe reći klijentima da kupuju smo pravo na korišćenje okvira. 2.

mada će ih verovatno imati.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sile  NasleĎivanje ima za rezultat jako kuplovanje izmeĎu komponenata. Kasnije. Kada se doĎe do funkcionalnog okvira. Kompozicija se moţe izmeniti pri izvršenju programa. Odatle će se pokazati šta će se verovatno izmeniti. Argumentacija NasleĎivanje je najbrţi način omogućavanja korisniku da menja kod u objektoorijentisanom okruţenju jer ga podrţavaju skoro svi objektno orijentisani jezici. Napraviti okvir bele kutije generalizacijom klasa individualnih aplikacija. ali ju je teško razumeti analiziranjem teksta statičnog programa. Koristiti paterne kao što su Template Method i Factory Method da bi se povećala količina upotrebljenog koda u nadklasama iz kojih se nasleĎuje. U ovom trenutku ne bi trebalo brinuti o semantici nasleĎivanja. MeĎutim. tako da se mogu promeniti stvari za koje prvobitni projektant nije ni pomislio da bi mogle biti promenjene. moţe se početi sa njegovom upotrebom. Polimorfna kompozicija zahteva znanje o tome šta će se promeniti. nepromenljivi kod okvira moţe biti učauren i parametrizovan konverzijom okvira u okvir crne kutije. NasleĎivanje je statično i ne moţe se lako izmeniti pri izvršenju. već samo o mogućnosti upotrebe koda. Kompozicija je moćna tehnika ponovne upotrebe. a šta ne.      Rešenje Koristiti nasleĎivanje. Ne treba brinuti ako aplikacije nemaju nijednu zajedničku konkretnu klasu. Ovo omogućava kreiranje klasa prostim nasleĎivanjem najpoţeljnijeg ponašanja iz postojeće klase i prekrivanje samo metoda koje su različite u podlasama. u ovoj tački ţivotnog ciklusa verovatno neće biti dovoljno informacija da se doĎe do Pravljenje nove klase zahteva programiranje. 33 . ali dozvoljava modifikacija komponenata koje se ponovno koriste.

počeće da se izdvajaju delovi koji konstanto bivaju prekrivani. Kako izbeći pisanje sličnih objekata za svako korišćenje okvira? Sile  Ogoljen okvir zahteva puno uloţenog truda da bi se mogao koristiti. trebalo bi izdvojiti delove koji se menjaju u novu metodu. Slični paterni Uporedno sa razbojem novih aplikacija. gde god se pojavi potreba za klasom koja je slična klasi isprojektovanoj u nekoj od prethodnih aplikacija. Implementacija Tokom razvoja budućih aplikacija. out-of-the-box) se koriste 34 . Problem Slični objekti moraju biti implementirani za svaku od aplikacija koje se kreiraju preko okvira. Stvari koje rade bez prethodnog podešavanja (eng. Ovaj metod je poznat pod nazivom "programiranje po razlikama" (eng. Okviri crne kutije se bave istim problemom. a koji će ostati nepromenljivi. i svi sledeći primeri na bazi okvira bele kutije. verovatno će se pokazati da su odreĎene metode skoro iste u svim podklasama. treba kreirati podklasu i prekriti metode koje se razlikuju. TakoĎe.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad informisane odluke o tome koji delovi okvira će biti stalno menjani kroz aplikacije. Ovo moţe dovesti do toga da početne metode postanu identične i kao takve mogu se izmestiti u apstraktnu klasu. Ponovo. U tom trenutku programer će biti u mogućnosti da kreira apstraktnu klasu koja sadrţi najčešće elemente. u procesu prekrivanja metoda.3 Biblioteka komponenata Kontekst Razvija se drugi primer. Pošto se napravi nekoliko podklasa. trebalo bi početi sa izradom biblioteke komponenata. kao i oni koji su relativno stabilni. programming-by-difference).6. 2. ali u drugom kontekstu.

Iz njih će moći da se izvedu glavne apstrakcije u okviru domena problema koje bi trebalo da budu predstavljene kao komponente okvira. Apstraktne klase se obično nalaze u okviru. Neke komponente se odnose na konkretan problem dok se druge pojavljuju u većini rešenja. klasa bi trebalo da bude uključena u bibilioteku komponenata samo ako je koristi više aplikacija. dok se konkretne klase obično nalaze u aplikaciji. Rešenje Započeti sa jednostavnom bibliotekom najočiglednijih klasa i dodavati klase kako se javlja potreba za njima. 35 . ali u početku sve konkretne klase mogu da uĎu u biblioteku.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad mnogo jednostavnije.  Isprva je teško reći koje komponente će biti potrebne korisnicima okvira. trebalo bi da ostane u biblioteci. Implementacija Klase biblioteke komponenata su konkretne podklase apstraktnih klasa koje sačinjavaju okvir. te klase će obezbediti vredan pogled na vrstu koda koji korisnik okvira mora da napiše. Biblioteka komponenata moţe biti kreirana prikupljanjem svih konkretnih klasa koje su stvorene za različite aplikacije potekle iz okvira. Ovakve klaseće na kraju biti uklonjeni iz biblioteke. Argumentacija Kako se dodaju klase u biblioteku. Ako se nikad ne koristi. Mnoge komponente će biti refaktorisane u manje podkomponente kasnije navedenim uzorima. Ako se neka komponenta mnogo koristi. neke će se odnositi na konkretan problem i nikada više se neće koristiti. Na duge staze. izbacuje se. MeĎutim. Okvir sa dobrom bibliotekom konkretnih komponenata se jednostavnije koristi nego onaj sa malom bibliotekom. Ostali klase će biti zajednički za više aplikacija.

Idealno. Okupljanjem koda koji varira u pojedine objekte pojednostaviće se proces upotrebe i pokazaće se korisnicima gde projektanti okvira očekuju da se vrše promene na okviru. Trebalo bi pratiti ţarišne tačke okvira u kojima se kod menja od aplikacije do aplikacije. promenljivi kod treba učauriti u objekte kad god je to moguće. Volfgang Pre (Wolfgang Pree) naziva ova mesta u okviru ţarišnim tačkama. Ako je promenljivi kod na nekoj zajedničkoj lokaciji. pojaviće se sličan. odreĎeni delovi će često varirati. jer je objekte lakše koristiti nego odvojene metode.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slični paterni Kako se komponente dodaju u biblioteku. ali dovoljno različit kod koji će morati da bude pisan iznova i iznova u svakoj novoj aplikaciji. Rešenje Treba odvojiti kod koji se menja od onog koji se ne menja. varijacije se postiţu kreiranjem ţeljenog objekta češće nego kreiranjem podklasa ili pisanjem metoda. Argumentacija Ako se okvir intenzivno koristi (čemu i sluţi). počeće se uviĎati kod koji se ponavlja jer ga dele grupe komponenata.4 Ţarišne tačke Kontekst Dodavanje komponenata u biblioteku komponenata Problem Pri razvoju aplikacije bazirane na okviru.6. tok programa moţe biti zamaskiran jer će pozivi uvek biti ka objektu koji sadrţi promenljivi kod. Kako eliminisati ponavljajući kod? Sile   Ako je promenljivi kod razbacan po aplikaciji. teško je pratiti ga i menjati. Kada se kod učauri. 2. 36 .

Abstract Factory. Visitor Command Bridge Observer Mediator Factory Prototype Method. Sledeća tabela pokazuje koje je paterne moguće upotrebiti kada se okvir menja od aplikacije do aplikacije: Šta se menja Algoritmi Akcije Implementacija Stanje nadreĎenog objekta Interakcije izmeĎu objekata Kreiranje objekata Patern projektovanja Strategy.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Dobro imenovanje ovih objekata će učiniti kontrolu toka manje bitnom za razumevanje okvira. Implementacija Mnogi uzori iz grupe „Gang of Four“ uzora projektovanja učauruju različite tipove promena. State 37 . Kreiranje strukture Sekvencijalni pristup agregiranom objektu Interfejs objekta Ponašanje objekta Tabela 1 Uzori projektovanja Builder Iterator Adapter Decorator.

blokove za procenu i šta god je još potrebno da se razlikuje jedna trivijalna podklasa od druge. Kako izbeći kreiranje trivijalnih podklasa svaki put kada se ţeli upotrebiti okvir? Sile   Nove klase. koliko god trivijalne. simbolu ili referenci klase. povećavaju sloţenost sistema. kreirati promenljivu koja će 38 .5 Priključni objekti (eng. često se moraju kreirati usitnjeniji (finer-grained) objekti. 2. Ovakvi objekti će učiniti da se okvir pribliţi okviru crne kutije.6. indekse za pristup. Dodavanje parametara u procesu kreiranja konkretne aplikacije omogućava upotrebu originalne klase bez neophodnosti da se koristi programiranje. Pluggable Objects) Kontekst Dodavanje komponenata u biblioteku komponenata. kreiranja novih podklasa da bi se učaurila mala promena je definitivno preterivanje. Problem Većina podklasa koje je potrebno napisati se razlikuju na trivijalne načine (npr. Rešenje Projektovati prilagodljive podklase koje mogu biti parametrizovane u smislu toga da imaju poruke za slanje. samo jedna metoda se prekrije). Argumentacija Ako je razlika izmeĎu podklasa trivijalna.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slični paterni Da bi se učaurile ţarišne tačke. Implementacija Odrediti koje promene se javljaju u svakoj od podklasa koje je neophodno napisati. Sloţene grupe parametara čine parametrizovane klase teţim za razumevanje i upotrebu. Ako je razlika u konstanti.

Parametri mogu biti automatski prosleĎivani pomoću vizuelnog bildera (eng. Programiranje 39 . visual builder).6 Usitnjeni objekti (eng. to je teţe razumeti sistem. to jest. proslediti blok koji predstavlja kod metodi za kreiranje objekta.6. i sačuvati ga u promenljivoj. potrebno je obezbediti alate da se kompozicija automatski kreira. Rešenje Treba razbijati objekte na sitnije i sitnije sve dok više nema smisla to činiti dalje. Argumentacija Pošto će okvire na kraju koristiti eksperti u domenu (odnosno ljudi koji nisu programeri). 2. do trenutka kada bi dalja podela objekta rezultovala objektima koji nemaju individualno značenje u domenu problema. Stoga je mogu biti ţeljene kreirane jednostavnim izborom objekata koji nije implementiraju funkcionalnosti aplikacije. Aplikacije neophodno. Fine-grained) Kontekst Refaktorisanje biblioteke komponenata da bi je učinili upotrebljivijom. Ako je varijacija u malom delu koda.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad sadrţati referencu i proslediti je objektu u metodi za kreiranje obekta. Problem Koliko daleko treba ići u deljenju objekata na manje objekte? Sile   Što je više objekata u sistemu. Slični paterni Kreiranje priključnih objekata je jedan od načina za učaurenje ţarišnih tačaka u okvir.

okvir postaje više nalik okviru crne kutije.7 Okvir crne kutije Kontekst Razvoj priključnih objekata učauravanjem ţarišnih tačaka i kreiranjem usitnjenijih objekata. 40 . ali dozvoljava izmenu komponenata koje se upotrebljavaju. treba je zameniti pozivom kompozicije prethodno kreiranih klasa koje implementiraju ţeljeno ponašanje. Polimorfna kompozicija zahteva shvatanje toga šta će se promeniti. drugi na polimorfnoj kompoziciji. Treba kreirati razdvojene klase koje učauruju svako od ponašanja. Šta koristiti? Sile  NasleĎivanje rezultuje jakim kuplovanjem izmeĎu komponenata. 2. Ovo će umanjiti dupliranje koda. Gde god se koristi izvorna klasa. Alati mogu biti tako dizajnirani da obezbede proširivanje objekata.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad vaţno izbeći programiranje. Implementacija Bilo gde u bibilioteci komponenata naići će se na klase koje učauruju višestruka ponašanja koja bi mogla nezavisno da variraju. tako da se mogu izmeniti stvari za koje prvobitnom projektantu ne bi ni palo na pamet da će neko menjati.   Pravljenje nove klase zahteva programiranje. Problem Neki okviri se zasnivaju na nasleĎivanju. kao i potrebu za kreiranjem novih podklasa za svaku novu aplikaciju. Slični paterni Kako objekat postaje usitnjeniji.6.

Implementacija Konvertovati odnose nasleĎivanja u odnose komponenata. koje predstavlja "je" (eng. Kompozicija moţe biti izmenjena u vreme izvršenja. Korišćenjem kompozicije da se napravi aplikacija. Koristiti nasleĎivanje da se organizuje biblioteka komponenata. is) odnos. Ove hijerarhije nam omogućavaju da klasifikujemo stvari i brzo shvatimo u kakvom odnosu su različite klasifikacije. nasleĎivanje će obezbediti sistematiku delova da bi se olakšao pregled koda.  Rešenje NasleĎivanje je statično i ne moţe se jednostavno izmeniti u vreme izvršenja. Kada nije u potpunosti jasno koja je bolja tehnika za neku komponentu. U osnovi. a kompozicija će omogućiti maksimalnu fleksibilnost u razvoju aplikacija. izbegava se programiranje i omogućava se variranje kompozicije u vreme izvršenja. za organizaciju naše biblioteke komponenata. okviri bele kutije zahtevaju razumevanje načina na koji klase funkcionišu tako da se mogu razviti odgovarajuće podklase. Korišćenjem nasleĎivanja. ali ju je teško razumeti analizom teksta statičnog programa. Argumentacija Okvir crne kutije je onaj kod kog se komponente mogu upotrebiti priključivanjem i bez razmišljana o tome kako izvršavaju svoje individualne zadatke. a polimorfnu kompoziciju da se komponente iskombinuju u aplikaciju. Suprotno tome. Ljudi vole da hijerarhijski organizuju stvari. trebalo bi favorizovati kompoziciju. moţemo brzo uvideti na koji način je mnoštvo komponenata u meĎusobnim relacijama. Mnogi od prethodno pomenutih uzora će obezbediti tehnike za pronalaţenje i kreiranje novih klasa sa komponentama. Izvući zajednički kod u nepovezane (po nasleĎivanju) klase i učauriti ga u nove komponente. 41 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad  Kompozicija je moćna tehnika upotrebe.

Uobičajeno je da se aplikacija sastoji iz dva dela: prvi deo je konfiguracija koja povezuje objekte okvira u celinu i "uključuje ih". Kako pojednostaviti kreiranje ovih konfiguracija? Sile    Rešenje Napraviti grafički program koji omogućava specificiranje objekata koji će biti u aplikaciji i način na koji su oni povezani. a drugi deo predstavlja ponašanje individualnih objekata. Kompozicije koje predstavljaju aplikacije okvira konvoluiraju. podrţavamo kreiranje vizuelnog bildera koji omogućava da se biblioteka pretraţuje i da se kompozicije kreiraju grafički. Okvir obezbeĎuje najveći deo ponašanja objekata. cela aplikacija se moţe kreirati prostim povezivanjem objekata postojećih klasa.8 Vizuelni bilder Kontekst Kada se jednom kreira okvir crne kutije. ali programer aplikacije mora da napravi konfiguraciju. Alati za izradu su skupi. Eksperti u domenu su retko programeri.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slični paterni Organizovanjem biblioteke komponenata u ovom maniru. 2. Problem Konfiguracija aplikacije je najčešće veoma slična od aplikacije do aplikacije. Ponašanje te aplikacije je sada u potpunosti odreĎeno time na koji su način ovi objekti meĎusobno povezani. Taj grafički program bi trebalo da generiše kod za aplikaciju na osnovu specifikacija. odnosno samo se specifični objekti razlikuju. teško se razumeju i generišu. 42 .6.

i moţe biti smatran za suvišan. . Dialog box).6. Slični paterni Razvijen je vizuelni programski jezik. Problem Vizuelni bilder kreira sloţene kompozitne objekte.9 Jezički alati Kontekst Upravo je kreiran bilder. Alat će takoĎe učiniti da okvir bude lakši za korišćenje time što će obezbediti grafički interfejs koji bi trebalo da koristi standardne notacije koje inače postoje u domenu problema. 43 Postojeći alati su obično neadekvatni za bavljenje specijalizovanim kompozitnim odnosima koji postoje u okviru. što znači da će biti neophodni jezički alati. Izrada dobrih alata je skup zadataka. Samo u retkim slučajevima bi trebalo da bude neophodno dodavanje novih klasa u okvir. U ovom trenutku eksperti za domen mogu kreirati aplikacije jednostavnim manipulisanjem slika na ekranu. debug)? Sile   Rešenje Kreirati specijalizovane alate za analiziranje objekata i uklanjanje grešaka. alat ga moţe generisati automatski. Ali. kao i u svakom drugom jeziku. najčešće je neophodno crtanje grafika da bi se predstavili sloţeni odnosi u komplikovanim domenima.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Argumentacija Pošto se specifičan kod aplikacije svodi praktično samo na konfiguraciju. Kako jednostavno analizirati te kompozicije i otkloniti nastale greške (eng. 2. Implementacija Ponekad se komponente i odnosi u aplikaciji mogu u potpunosti odrediti kroz neke vrste pretraţivača sadrţaja ili dijaloge (eng.

takozvane uzore projektovanja. Example Application) . 2. Ovi alati bi trebalo da omoguće korisniku da zaobiĎe delove kompozicije koji nisu interesantni. Stvar komplikuje činjenica da različitim ciljnim grupama trebaju različite informacije:   običan korisnik koji ţeli da iskoristi okvir na predviĎeni način. a od dokumentacije očekuje da ga uputi na očekivano podešavanje okvira. (wrappers) i strategije. Napraviti specijalizovane alate za navigaciju i ispitivanje kompozicija. Oni se najčešće nalaze tamo gde se objekti intenzivno komponuju pomoću stvari kao što su omotači eng. biće neophodni jezički alati kao pomoć u razumevanju i otklanjanju grešaka. jer će okvir biti pun malih objekata koji svi liče jedan na drugi. i načina na koji one funkcionišu zajedno. Implementacija Pronaći delove okvira koji su komplikovani za ispitavanje i otklanjanje grešaka.  projektant drugog okvira ţeli da nauči principe na kojima se zasniva fleksibilnost okvira uzetog kao primer.7 Dokumentovanje okvira Strma kriva učenja i razumevanja okvira oteţava njihovu upotrebu i efikasnost te upotrebe. Alati koji dolaze uz programski jezik kojim je izraĎen okvir verovatno neće biti dovoljno dobri. od čega će polovina biti potpuno neinteresantna nekome ko pokušava da jednostavno napravi aplikaciju. Napredni korisnik koji ţeli da iskoristi okvir na nepredviĎen način kombinovanjem različitih ţarišnih tačaka na neispitan način: ovaj tip korisnika mora razumeti principe i ograničenja ţarišnih tačaka. Ovo je slično standardnom razvoju softvera u kombinaciji sa problemima pri razvoju okvira.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Argumentacija Pošto je kreirani sistem u osnovi grafički programski jezik vezan za odreĎeni domen. Različiti načini dokumentovanja okvira[28]:  Primeri aplikacija (eng.Izvršni kod primera aplikacija koje su konstruisane upotrebom okvira je često prva i jedina 44 .

Dokumentacija zahteva gradiranu grupu primera za veţbu. sve do potpune pokrivenosti. Većina kuvara se vrte oko malog broja jednostavnijih primera aplikacija. a ugovori obezbeĎuju rigorozniji opis saradnji bitne za motiv. ukrštanja sa drugim receptima i primere izvornog koda. Pattern Language) . moţda uz poneku sliku.Recept opisuje kako izvesti uobičajen primer upotrebe tokom razvoja aplikacije.Kuvar je kolekcija recepata. Mnogi sistemi koriste kuvare kao metod prezentovanja dokumentacije. Iako neformalan. paternima projektovanja i ugovorima (eng.  Recept (eng. opis situacije korišćenja. Informacije bi trebalo da budu prezentovane neformalnim jezikom. 45 . Organizacija prati spiralni pristup gde recepti za najčešće oblike upotrebe bivaju predstavljeni pri početku i gde se koncepti i detalji spominju što je kasnije moguće. Recipe) . Svoj pristup je primenio na HotDraw. korake recepta. sekcije.Dţonson je uveo neformalni jezik paterna koji moţe da se koristi za dokumentovanje okvira prirodnim jezikom. Prvi recept je pregled koncepata okvira i drugih recepata. korake koje treba poduzeti pri podešavanju i ukrštanja sa drugim motivima. Paterni projektovanja obezbeĎuju informacije o internoj arhitekturi.  Kuvar (eng. kao npr.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad dokumentacija koju imaju programeri aplikacija.  Motiv (eng. Najčešće postoji vodič kroz sadrţaj recepata. Motif) . Ovi paterni sadrţe format svakog recepta i način organizacije kuvara.Laţoj i Keler (eng. Svaki bi trebalo da ilustruje po jednu novu ţarišnu tačku. recept najčešće prati strukturu. contracts). bilo kao sadrţaj kuvara ili kroz prvi recept koji je koncipiran kao pregled kuvara. i najčešće uz primer izvornog koda.  Jezik uzora (eng. Lajoie i Keller) su uveli termin "motiv" za Dţonsonove paterne da bi se izbeglo mešanje sa uzorima projektovanja. počevši od najjednostavnijeg i najčešćeg oblika upotrebe za tu ţarišnu tačku. Cookbook) . Oni koriste šablon za opis motiva koji sadrţi naziv i nameru. okvir za programe za izmenu slika.

kao i šta je fiksirano a šta fleksibilno. njene pred i post uslove i indikaciju na koje članove podataka utiče 46 . ulogu svakog člana podataka (eng. kao i raspravu posledica prihvatanja rešenja. Dijagram saradnje moţe biti upotrebljen da predstavi te iste informacije. Uobičajeno je da opis klase sadrţi svrhu ili odgovornost klase. Pregled okvira definiše ţargon domena i razgraničava opseg dejstva okvira: šta je pokriveno okvirom.Ugovor interakcije se bavi kooperativnim ponašanjem više učesnika koji interaguju kako bi postigli zajednički cilj. Interaction Contract) . Uzori projektovanja pomaţu u razmevanju arhitekture  Pregled okvira (eng.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad  Ugovor interfejsa (eng.Ugovor obuhvata spisak obaveza.  Ugovor interakcije (eng. sistema. Pregled okvira je najčešće prvi recept u kuvaru.  Priručnik (eng. Ugovor interfejsa obezbeĎuje specifikaciju interfejsa klase i izolovanih invarijanti klase. Opis metoda prezentuje funkcionalnost metode. Interface Contract) . semantike interfejsa metode i ograničenja ponašanja koja obuhvataju zavisnosti ponašanja izmeĎu objekata  Uzori projektovanja (eng. Framework Overview) . Analiza koristi i ustupaka primene uzora je vaţan deo opisa uzora projektovanja. Moguće je da će postojati primer jednostavne aplikacije. Reference Manual) . Design Pattern) .Priručnik objektno orijentisanog sistema se sastoji od opisa svih klasa.Postavljanje konteksta okvira je prvi korak ka omogućavanju programeru aplikacije da upotrebi okvir. a šta ne.Uzor projektovanja je rešenje problema koji bi mogao nastati u datom kontekstu. Problem moţe biti ilustrovan konkretnim primerom. kao i pregled dokumentacije. Rešenje opisuje objekte i klase koji učestvuju u rešenju. TakoĎe mogu biti prikazani primeri rešenja u konkretnim situacijama. data member). i neke informacije o svakoj od metoda. Opis uzora projektovanja objašnjava problem i rešenje u njegovom kontekstu. Ugovor specificira grupu učesnika koji meĎusobno komuniciraju i njihove ugovorne obaveze: tipove ograničenja zadate od strane potpisa metode. kao i njihova zaduţenja i saradnje.

Za dokumentovanje okvira. Iako postoji mnogo različitih mogućih pristupa dokumentovanju okvira. opisi mogu sadrţati dodatne materijale po pitanju uloge klase ili metode u obezbeĎivanju fleksibilnosti ţarišne tačke. Najsigurniji pristup je korišćenje više načina dokumentovanja okvira. naročito po pitanju toga da li je klasa zamišljena da sadrţi podklase ili metoda da bude prekrivena.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad ili ih koristi. ne postoji jasan standard. 47 .

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 3 Značajni koncepti za razvoj sopstvenog okvira U ovom poglavlju biće definisani i opisani značajni koncepti koji će biti korišćeni za razvoj sopstvenog okvira: Larmanova metoda razvoja softvera. relacioni model. u kome se zahtevi i rešenja razvijaju kroz saradnju tima koji razvija softver i naručioca softvera. Slučajevi korišćenja definišu interakciju korisnika sa sistemom.1 Larmanova metoda razvoja softvera Agilne metode razvoja softvera su nastale kao odgovor na preteranu birokratiju „teških“ metoda. definišu šta sistemska operacija treba da radi bez 48 .  Analiza – opisuje logičku strukturu i ponašanje sistema: o Ponašanje softverskog sistema – opisuje se preko:  Sekvencnog dijagrama . tronivojska arhitektura. koje opisuje skup od jednog osnovnog i više alternativnih scenarija. Glavni aspekt agilnih metoda su jednostavnost. Osnovne faze Larmanove metode razvoja softvera su [7][2]:  Zahtevi – predstavljaju uslove i svojstva koje sistem mora da zadovolji. dogaĎaje u odreĎenom redosledu koji uspostavljaju interakciju izmeĎu korisnika i softverskog sistema. Scenario predstavlja skup ţeljenih korišćenja sistema od strane korisnika. DogaĎaje pravi korisnik.  Ugovora o sistemskim operacijama . desktop aplikacija i automatsko programiranje (kod generator). i traţe kompromis izmeĎu previše i premalo planiranja kod razvoja softvera. Podvlačenjem imenica u slučaju korišćenja definišemo koncepte domena problema.prikazuje. 3. za svaki scenario slučaja korišćenja.opisuju ponašanje sistemskih operacija. brzina i iterativan razvoj. a prikazuju se preko modela slučajeva korišćenja. Larmanova metoda razvoja softvera spada u jednu od agilnih metoda razvoja softvera. a sistem odgovara na njih u vidu poziva sistemske operacije.

o Projektovanje ponašanja softverskog sistema – sistemskih operacija. o Struktura softverskog sistema:  Konceptualni (domenski) model sistema . da bi joj se moglo pristupiti iz okruţenja softverskog sistema.  Projektovanje – opisuje fizičku strukturu i ponašanje softverskog sistema. obrada podataka i skladište podataka logički odvojeni. što znači da opisuju njegovu strukturu.na osnovu konceptualnog modela moţe se napraviti relacioni model kao osnov za projektovanje relacione baze podataka. Konceptualne klase predstavljaju atribute softverskog sistema.  Relacioni model sistema .opisuje konceptualne klase domena problema i asocijacije meĎu njima. o Projektovanje strukture softverskog sistema – domenskih klasa. o Projektovanje skladišta podataka.   Implementacija. o Projektovanje kontrolera korisničkog interfejsa. koja se smatra istovremeno i arhitekturom sistema i uzorom projektovanja. o Projektovanje ekranskih formi. Ona je javna. odnosno arhitekturu sistema: o Definisanje arhitekture softverskog sistema. 3. o Projektovanje aplikacione logike – database brokera.[9] 49 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad ulaţenja u to kako će to da radi. Sistemska operacija opisuje ponašanje softverskog sistema. o Projektovanje aplikacione logike – kontrolera.2 Tronivojska arhitektura Višenivojska arhitektura (često označena kao n-nivojska) je arhitektura u kojoj su prezentacioni sloj. Testiranje. Najrasprostranjeniji oblik višenivojske arhitekture je tronivojska arhitektura (Slika 3).

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad I nivo II nivo III nivo SOFTVERSKI SISTEM KORSNIČKI INTERFEJS APLIKATIVNA LOGIKA SKLADIŠTE PODATAKA Slika 2 Tronivojska arhitektura Kod tronivojske arhitekture korisnički interfejs. Pored standardnih prednosti koje imaju svi modularni softveri. Na primer.opisuje strukturu i ponašanje sistema o Kontroler . često na različitim platformama. Aplikativna logika . poslovna logika i skladište podataka su razvijeni i odrţavani u nezavisnim modulima. Klasičnu tronivojsku arhitekturu čine (slika 3) :   Korisnički interfejs . TakoĎe čuva domenske klase o Broker . tronivojska arhitektura teţi da dozvoli da se slojevi aplikacije odvojeno menjaju. Projektovanje softverskog sistema opisuje njegovu fizičku strukturu i ponašanje.prima zahteve za izvršenje sistemskih operacija od korisnika i prosleĎuje ga poslovnoj logici o Poslovna logika .odgovorna je za izvršenje sistemskih operacija.ulazno-izlazna jedinica softverskog sistema. promena operativnog sistema na serveru na kom se nalazi prezentacioni sloj uslovljava samo promenu koda na korisničkom interfejsu.odgovoran je za komunikaciju poslovne logike sa skladištem podataka  Skladište podataka .čuva stanja atributa sistema 50 .

[9] Model ili šema baze podataka predstavlja strukturu baze podataka. 51 . Kolone predstavljaju atribute objekata.3 Relacioni model Model podataka je apstraktan model koji opisuje način na koji su podaci predstavljeni i način na koji im se pristupa. Drugačije rečeno. Vrste predstavljaju pojavljivanja objekata. Vrste modela baze podataka:       Hijerarhijski model Mreţni model Relacioni model Model objekti-veze Objektno-relacioni model Objektni model Relacioni model se predstavlja preko skupa tabela (relacija). Osnovni koncepti relacionog modela:    Tabele predstavljaju tipove objekata. opisanu kroz formalni jezik koji podrţava sistem za upravljanje bazom podataka. ali takoĎe i neke veze u modelu. Model podataka formalno opisuje elemente i veze izmeĎu elemenata za odreĎeni domen.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad SOFTVERSKI SISTEM APLIKACIONA LOGIKA KORSNIČKI INTERFEJS KONTROLER POSLOVNA LOGIKA BROKER SKLADIŠTE PODATAKA Slika 3 Tronivojska arhitektura . to je model podataka primenjen na sistem za upravljanje bazom podataka.komponente 3.

Uobičajeno je da ima sloţeniji korisnički interfejs od veb (eng. Desktop aplikacije su efikasnije od veb aplikacija kada:      Korisnici nemaju pristup internetu. Četrdesetih godina prošlog veka bilo je opisano kao automatizacija 52 .4 Desktop aplikacija Aplikacija koja se pokreće na desktop (korisničkom. Relacioni model je vrednosno orijentisan. Potrebno je da se obrada podataka vrši na klijentskom računaru. Desktop aplikacije mogu biti kreirane tako da se koriste potpuno samostalno. Korisnički interfejs je toliko sloţen da su mu potrebne kontrole koje nisu dostupne preko Internet čitača (eng. klijentskom) računaru se naziva desktop aplikacija. browser). programer. Veliki broj konkurentnih korisnika koristi aplikaciju. Većina savremenih baza podataka izgraĎena je preko sistema za upravljanje bazom podataka zasnovanom na relacionom modelu.5 Automatsko programiranje Automatsko programiranje predstavlja kompjutersko programiranje u kome neki mehanizam generiše program umesto da čovek.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad  Primarni ključ relacije predstavlja jedan ili više atributa tabele koji jedinstveno odreĎuju jednu vrstu tabele. Evolucijom kompjutera i nauke o njima menjala se i definicija automatskog programiranja. Potrebne su visoke performanse. piše kod [9]. mada ga mogu koristiti. ili mogu da prenose informacije u lokalnoj mreţi i uglavnom ne zahtevaju pristup internetu. [35] 3. web) aplikacija. najčešće de bi se smanjili zahtevi za veličinu opsega mreţe. 3. što znači da su veze izmeĎu objekata uspostavljene preko vrednosti njihovih atributa.

Dialog box) vodi korisnika kroz niz koraka kojima odabira ţeljenu akciju. Generisanje programskog koda (eng. IDE) transformiše u programski kod. skica. njegove čitljivosti. Jedan od prvih prevodioca (kompajlera) nazvan je Autokod (eng. Neki IDE-i sadrţe razne forme generisanja programskog koda:  Čarobnjaci (eng. Postoje čarobnjaci za interaktivno generisanje GUI-a. ponovljivi parčići koda koji se „umeću“ u veće programske module i time olakšavaju Refaktorizacija – promena unutrašnje strukture programa. prototipa. koji u pozadini generišu izvorni kod. Parnas je zaključio da je automatsko programiranje uvek predstavljalo eufemizam za programiranje u jeziku višeg nivoa od onog koji je bio dostupan programerima u tom trenutku. 53 . source code) je bazirano na ontološkom modelu (npr. performansi. jednostavnosti odrţavanja i proširivanja. itd. šemi) koji se preko nekog programerskog alata ili integrisanog razvojnog okruţenja (eng. Generativno programiranje (proizvodno) je programiranje koje koristi automatizovano kreiranje programskog koda preko generičkih frejmova. kao i promena koda u svrhu uklapanja u ţeljenu programsku paradigmu.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad ručnog procesa bušenja kartica. Autocode).   Snipeti (eng. pojednostavljivanja strukture. klasa. wizard) – niz dijaloga (eng. snippets) – relativno mali. Zatim je predstavljalo prelazak na jezike višeg nivoa kao što su Fortran i Algol. bez promene njegove spoljašnje funkcionalnosti u cilju poboljšanja kvaliteta softvera.

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

4 Razvoj okvira

Na bazi predstavljene teorije biće razvijen sopstveni okvir za generisanje desktop aplikacija u C# programskom jeziku. Konkretan okvir bi trebalo da generiše skelet tronivojske aplikacije i da implementira osnovne operacije (eng. CRUD - create, read, update, delete) nad bazom podataka, za proizvoljan domen problema. Kako implementacija CRUD operacija zavisi od modela podataka aplikacije, ulaz u sistem će predstavljati meta model podataka aplikacije, a izlaz, kako je već navedeno, konkretna aplikacija tronivojske arhitekture (Slika 4).

META MODEL PODATAKA

OKVIR

DESKTOP APLIKACIJA

Slika 4 Konceptualni model okvira

Primarni cilj je odrediti arhitekturu desktop aplikacije koju okvir treba da generiše. Neophodno je doći do komponenti arhitekture koje ne zavise od meta podataka i koje će kao takve činiti nepromenljivi deo okvira, odnosno jezgro okvira. Pored toga, potrebno je uočiti komponente arhitekture koje zavise od meta podataka i odrediti transformacije koje su potrebne da bi okvir generisao te komponente. Ovako izgenerisane komponente činiće promenljivi deo okvira, odnosno interne dopune

okvira.
Za razvoj Oz 
2

okvira koristićemo modifikovanu Bošovu metodu razvoja okvira:

Razvoj okvira: o Analiza domena – u okviru analize domena korišćenjem uzora tri primera biće analizirane tri aplikacije sa ciljem da se doĎe do arhitekture desktop aplikacije. Kao rezultat ove faze dobiće se

2

Sopstveni okvir je nazvan Oz. S obzirom da je razvijan Objektno-Orijentisan Okvir, od akronima tih reči je dobijen logičan naziv OOO, odnosno O3, što možemo pročitati kao dirilično Oз i latinično napisati kao O z.

54

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

komponente koje čine jezgro okvira i komponente koje čine promenljivi deo okvira. o Projektovanje okvira - biće uraĎeno po Larmanovoj metodologiji, koja spada u jednu od agilnih metodologija razvoja softvera. Pored projektovanja arhitekture samog okvira, kao rezultat ove faze dobiće se sve transformacije neophodne za generisanje komponenti koje čine promenljivi deo okvira. o Implementacija okvira – okvir će biti implementiran u C# programskom jeziku. o Testiranje okvira – neće biti posebno razmatrano, biće uključeno u fazu implementacije okvira. o Dokumentovanje okvira – ovo je faza koju Boš ne razmatra posebno, ali prateći ostale smernice za razvoj okvira moţe se zaključiti da je veoma značajna za korišćenje okvira.   Korišćenje okvira – biće realizovano kroz studijski primer u poglavlju 4.5 Evolucija i odrţavanje okvira – dalja evolucija okvira prevazilazi granice ovog rada, ali moţe biti tema nekog narednog istraţivanja.

4.1 Analiza domena

Domen problema će biti opisan preko modela podataka, konkretno preko relacionog modela podataka, koji se u praksi pokazao kao najčešće korišćen (slika 5), i on će predstavljati ulaz u Oz okvir.
RELACIONI MODEL PODATAKA OKVIR DESKTOP APLIKACIJA

Slika 5 Konceptualni model okvira - relacioni model

Prvo pitanje koje se nameće je: kako započeti analizu domena? Rešenje koje predlaţe uzor tri primera je definisanje domena na osnovu analize tri aplikacije iz datog domena. Kako ţelimo da kreiramo okvir za razvoj desktop aplikacija orijentisanih na
55

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

bazu podataka, prateći uzor tri primera, analiziraćemo tri takve aplikacije, uočiti njihove sličnosti i razlike, i pokušati da izvedemo neke apstrakcije. Softverski sistemi koji će biti analizirani su:   Aplikacija „Cipelarnik“ za magacinsko poslovanje, izraĎena za potrebe kompanije Mastaco, Aplikacija „Prijemni ispit“ za pomoć u organizovanju prijemnog ispita, izraĎena kroz seminarski rad iz predmeta „Projektovanje informacionih sistema“,  Aplikacija „Restoran“, za naručivanje u restoranu.

Cilj analize domena je da se doĎe do generalne arhitekture poslovne desktop aplikacije koju bi okvir trebalo da generiše. Kako bismo došli do komponenti koje čine jezgro i promenljivi deo okvira koristićemo uzore u najopštijem smislu. Problem koji dovodi do korišćenja uzora u opštem smislu je visoka zavisnost izmeĎu klijenta i konkretnih servera, koji mu pruţaju odreĎene servise. Rešenje ovog problema dobija se povezivanjem klijenta sa apstraktnim serverom u vreme kompajliranja, što omogućava klijentu da se u vreme izvršavanja poveţe sa konkretnim serverom (slika 6).

PROBLEM

Konkretan server 1

Klijent

Apstraktan server

REŠENJE

Klijent

Konkretan server 2

T

Konkretan server n

Konkretan server 1

Konkretan server 2

Konkretan server n

UZOR

Slika 6 Opšti uzor

56

i biće kreirane komponente generalizacijom klasa individualnih aplikacija. Analizom sistemskih operacija dobiće se opšta klasa za realizaciju sistemske operacije. Zatim će biti izvršena analiza kontrolera korisničkog interfejsa. koju će naslediti svaki konkretan kontroler. odnosno promenljivi deo okvira. kao što je navedeno u opštem uzoru. Cilj analize kontrolera aplikativne logike je da se doĎe do generalnih metoda koje postoje u svakoj od navedenih aplikacija. Pored ovoga cilj je da se izvrši uopštavanje nekih zajedničkih 57 . čime će se postići jednostavnije korišćenje okvira. Cilj analize svake pojedinačne komponente je da se dobije interfejs. biće analizirana aplikativna logika sa ciljem kreiranja opšte klase za aplikativnu logiku. Biće izvršena analiza kontrola forme i metoda koje se izvršavaju u pozadini sa ciljem da se doĎe do interfejsa i opšte klase koju će naslediti sve konkretne forme. kao što je predloţeno u uzoru biblioteke klasa. u cilju dobijanja apstraktne klase za kontroler korisničkog interfejsa. Prvo će biti izvršena analiza ekranskih formi. Uočene konkretne klase koje se pojavljuju u većini rešenja biće dodate u biblioteku komponenata. Pretpostavka je da aplikacija koju generiše okvir treba da omogući samo CRUD operacije. U okviru analize primarni cilj je odrediti zakonitosti koje se koriste u procesu kreiranja domenskih klasa i njihovu vezu sa relacionim modelom.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Iz ovoga se moţe zaključiti da apstraktni serveri u najopštijem smislu predstavljaju jezgro okvira. sve tri navedene aplikacije.1 Analiza komponenata sistema U daljem tekstu će biti analizirani svi navedeni elementi tronivojske arhitekture. dok konkretni serveri predstavljaju interne dopune okvira i dopune vezane za aplikaciju. Pored toga potrebno je da se uoči veza izmeĎu meta podataka relacionog modela i koda formi. Sledeći zadatak biće analiza domenskih klasa. apstraktna klasa ili konkretna (opšta) klasa za datu komponentu.1. 4. Nakon toga.

ta forma se moţe pozvati samo preko forme njenog jakog objekta. moţe se zaključiti da se većina ekranskih formi sastoji od:  Kontrola za unos novog ili izmenu postojećeg objekta. odnosno da se doĎe do interfejsa brokera.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad osobina svih domenskih klasa koje dovodi do kreiranje apstraktne klase koji će one naslediti. U poslednjoj fazi analize domena biće izvršena analiza brokera. Na osnovu analize grafičkog interfejsa iz navedenih projekata (slike 8 i 9). Tipovi grafičkih kontrola koje okvir generiše: 58 . Jedan od ciljeva analize je da se uoči skup zajedničkih metoda koje se koriste u svakoj od navedenih konkretnih aplikacija. Za svaki atribut tabele kreira se po jedna grafička kontrola. U slučaju slabih objekata. Korisnički interfejs Korisnički interfejs (slika 7) predstavlja ulazno-izlaznu komponentu sistema. Sastoji se od:   Ekranskih formi Kontrolera korisničkog interfejsa [2] Korisnički interfejs Ekranska forma Kontroler KI Softverski sistem Slika 7 Korisnički interfejs Na osnovu analize navedenih projekata moţe se zaključiti da se za svaku tabelu iz relacionog modela kreira ekranska forma. Drugi cilj je da se doĎe do konkretnih relalizacija brokera vezanih za odreĎene sisteme za upravljanje bazama podataka.

ili je integrisana u formu jakog objekta. kreira se ComboBox kontrola o Ako je atribut datumskog tipa. Magacina.) Dugmića za akcije nad objektom prikazanim na formi: o Nov o Snimi o Obriši o Izlaz  Formi sa istom takvom strukturom za svaki slab objekat datog objekta koja se ili poziva kao modalni dijalog. Jedinica mere.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad o U najvećem broju slučajeva kreirana kontrola je tipa TextBox. odnosno tekstualno polje o U slučaju da je atribut spoljni ključ.. Slika 8 Forma "Prijemni ispit" .Kandidat 59 . kreira se DateTimePicker kontrola   ListView-a ili DataGridView-a sa spiskom svih objekata iz baze (npr. Kandidata..

„izlaz“. Korišćenjem opšteg uzora kreirana je interfejs klasa za formu: 60 . Potrebno je znati polja tabele na osnovu kojih se kreiraju polja forme.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 9 Forma "Cipelarnik" . dobija se sledeći skup metoda:  Metode koje se odigravaju pri učitavanju forme: o Popunjavanje ComboBox-ova o Popunjavanje ListView-a    DogaĎaji koji se dešavaju klikom na dugme („nov“. kao i relacije nad tabelom.Magacin Analizom metoda forme koje se izvršavaju u pozadini. „obriši“) Popunjavanje/brisanje polja forme Metode nad ListView-om ili DataGridView-om. neophodno je poznavanje meta podataka tabele za koju se generiše forma. scroll) objekata iz kontrole  Slične metode za svaki slab objekat datog objekta Da bi ovakve ekranske forme bile kreirane. „snimi“. i tipove polja u bazi podataka. o Izbor ţeljenog objekta iz kontrole o Brisanje ţeljenog objekta iz kontrole o Pregledanje (eng.

biće kreirana i klasa za opštu realizaciju forme Fopsta (slike 10 i 11) Slika 10 FOpsta .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad interface InterfaceForm { void FOpsta_Load(object sender.opšta realizacija forme 61 . void gridOdo_DoubleClick(object sender. EventArgs e). void btnNov_Click(object sender. EventArgs e). EventArgs e). KeyEventArgs e). void btnIzlaz_Click(object sender. System. EventArgs e). EventArgs e). } TakoĎe. EventArgs e). void OdaberiStavku(object sender.Forms. void text_EnterTab(object sender.KeyEventArgs e). void gridOdo_KeyUp(object sender. void EnablujPolja(). void PrvoPoljeFokus(). void btnSnimi_Click(object sender.Windows.

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 11 FOpsta Da bi se kreirala konkretna forma koja prekriva metode opšte klase za formu neophodno je poznavanje meta podataka tabele za koju je forma kreirana. U projektovanju okvira biće odreĎena transformacija koja će da generiše konkretne forme na osnovu relacionog modela. Ovo znači da konkretna forma predstavlja promenljivi deo okvira. dok su opšte klase i interfejs forme deo jezgra okvira. Kontroler korisničkog interfejsa Kontroler korisničkog interfejsa je odgovoran da:    Prihvati podatke koje šalje ekranska forma Konvertuje podatke iz grafičkih elemenata u objekte domenske klase Šalje zahtev za izvršenje sistemskih operacija do softverskog sistema 62 .

primarnih i spoljnih ključeva. koji je veoma sličan metodama ekranskih formi:  Dogadjaji koje inicira korisnik sistema: o Učitavanje forme o Kreiranje novog objekta o Snimanje izabranog objekta o Brisanje izabranog objekta   Popunjavanje/brisanje polja forme Metode nad ListView-om ili DataGridView-om o Izbor ţeljenog objekta iz kontrole o Brisanje ţeljenog objekta iz kontrole o Pregledanje objekata iz kontrole Kako svaka forma ima referencu na konkretan kontroler korisničkog interfejsa. Kontroler korisničkog interfejsa će biti realizovan kroz apstraktnu klasu prikazanu na slici 12. tipova polja. dobija se sledeći skup metoda.[2] Analizom kontrolera korisničkog interfejsa. jasno je da kontroler zavisi od meta podataka tabele za koju je generisana forma: polja tabele.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad   Prihvata objekte koji nastaju kao rezultat izvršenja sistemskih operacija Konvertuje prethodno pomenute objekte u podatke grafičkog interfejsa. 63 .

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 12 KKIOpsti . 64 .apstraktna klasa kontrolera korisničkog interfejsa Kako je za kreiranje konkretne klase kontrolera korisničkog interfejsa neophodno poznavanje meta podataka tabele za koju se kreira. U fazi projektovanja okvira biće odreĎena transformcija koja će na osnovu relacionog modela da generiše konkretne kontrolere korisničkog interfejsa. dok su apstraktne klase kontrolera korisničkog interfejsa deo jezgra okvira. to znači da ovaj segment okvira zavisi od podataka. što znači da spada u promenljivi deo okvira.

Aplikacioni serveri su odgovorni da obezbede servise koji će omogućiti realizaciju aplikacione logike softverskog sistema.KAL). Broker je odgovoran za komunikaciju izmeĎu poslovne logike i skladišta podataka. Treba napomenuti da su konkretne klase predstavljene na slici tu samo u svrhu ilustracije.SO) Šematski prikaz delova aplikacionog servera je dat na slici 13.DAC). Svaki aplikacioni server se sastoji iz tri dela:[2]  Deo za komunikaciju sa klijentom (kontroler .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Aplikaciona logika Aplikaciona logika opisuje strukturu i ponašanje softverskog sistema.   Deo za komunikaciju sa skladištem podataka (broker . SOFTVERSKI SISTEM APLIKACIONA LOGIKA SKLADIŠTE PODATAKA KONTROLER POSLOVNA LOGIKA KORSNIČKI INTERFEJS Slika 13 Aplikativna logika 65 . Kontroler je odgovoran da prihvati zahteve za izvršenje sistemske operacije od klijenta i da ga prosledi do poslovne logike koja je odgovorna za izvršenje sistemske operacije. Poslovna logika je opisana strukturom (domenskim klasama .DK) i ponašanjem (sistemskim operacijama . Deo koji sadrţi poslovnu logiku.

dok je u drugim primerima pozivao sistemske operacije da izvrše poslovnu logiku.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Analizom navedenih projekata je utvrĎeno da je u nekim slučajevima kontroler aplikativne logike potpuno preuzeo ulogu sistemskih operacija. što znači da čini deo jezgra okvira. Pored toga. to jest definisaće interfejs ka njima da bi se podsistem ponašanja sistema lakše koristio. Slika 14 Kontroler aplikativne logike Primećujemo da ovako definisan kontroler aplikativne logike ne zavisi od podataka. 66 . Kontroler aplikativne logike će pozivati konkretnu sistemsku operaciju (Slika 14). kontroler aplikativne logike će se ponašati kao Facade uzor za sistemske operacije. Sistemske operacije Sistemske operacije definišu ponašanje sistema.

sem za nekoliko objekata čije izmene povlače veoma sloţene operacije nad bazom podataka.. VratiCombo. DataGridView i ComboBox kontrola. a u „Cipelarniku“ i „Restoranu“ su opšte. programer. Biće definisane kao klasa sa virtuelnim metodama koje programer moţe da prekrije konkretnim metodama. ProveriPredusloveInsert() ProveriPostusloveInsert() OsoKonkretna ProveriPredusloveInsert() ProveriPostusloveInsert() . Oso Insert() ProveriPredusloveInsert() ProveriPostusloveInsert() . 67 . Virtuelne metode će implementirati osnovno ponašanje sistema (Slika 16). Kao potencijalno veoma korisne metode ističe se još nekoliko opštih metoda u „Cipelarniku“: VratiTabelu. Ove konkretne klase predstavljaće ţarišne tačke.. Ukoliko je potrebno da se promeni ponašanje neke od metoda opšte sistemske operacije neophodno je kreirati konkretnu klasu u kojoj će biti prekrivena ţeljena metoda... Slika 15 Template method uzor Ovako definisana klasa opšte sistemske operacije ne zavisi od podataka i predstavljaju jezgro okvira. Za opštu sistemsku operaciju biće iskorišćen Template method uzor (slika 15) koji definiše skelet algoritma neke operacije. one metode koje se ponavljaju u sve tri aplikacije su metode za manipulaciju bazom podataka: CRUD operacije.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Pored raznih specifičnih metoda. koje vraćaju tabelarne podatke za popunjavanje ListView. U „Prijemnom ispitu“ su te metode konkretne za svaki pojedini objekat. prenoseći odgovornost izvršenja pojedinih koraka algoritma do podklasa [2]. VratiTabeluLike. i izvršavaće ţeljenu akciju nad bazom podataka. koje korisnik. moţe da implementira. Sistemske operacije će pozivati konkretan broker.

Jedno od zaduţenja domenske klase je da vrši 68 . sledi zaključak da se za svaku tabelu relacionog modela kreira domenska klasa.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 16 Sistemske operacije Domenske klase Domenske klase predstavljaju softverske klase strukture. [2] Na osnovu analize navedenih aplikacija. Domenska klasa sadrţi sve atribute koje sadrţi tabela za koju je kreirana.

string DajSelectAll(). string DajInsertKolone(). public abstract OpstiDomenskiObjekat KreirajObjekat(DataRow vrsta).} string DajSelect().} public abstract string SifraPolje { get.} string NazivPolje { get. string DajId().Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad objektno-relaciono preslikavanje.} public abstract void KreirajObjekat(DataRow vrsta.} Odo KreirajObjekat(DataRow vrsta). “Prijemni ispit” sadrţi metode: domObj). Materijalizacija predstavlja proces transformacije slogova iz baze podataka u objekte programa.} public abstract string NazivPolje { get. string NazivTabele { get. kao i enum: enum Status 69 . string DajUpdate().} string IdPolje { get. IDomenskiObjekat Metode “Cipelarnika” su: abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract abstract ArrayList SlabiObjekti { get. a dematerijalizacija obrnut proces (slika 17). koju nasleĎuju svi ostali domenski objekti. public abstract string NazivTabele { get. OpstiDomenskiObjekat odo). [2] SOFTVERSKI SISTEM Program – operativna memorija Materijalizacija Objekti Slogovi Baza podataka Dematerijalizacija Slika 17 Materijalizacija i dematerijalizacija objekata Treba primetiti da u sve tri aplikacije već postoji apstraktna klasa OpstiDomenskiObjekat. public abstract DataRow NapuniVrstuSaPodacima(DataRow novaVrsta. string DajInsert().

Ubaci(OpstiDomenskiObjekat odo).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad { inserted. PotvrdiTransakciju(). Konkretni domenski objekat. ima još i regione:     Konstruktori – za kreiranje objekta (iako nije konstruktor. deleted. Sve tri aplikacije sadrţe interfejs brokera. Konkretan domenski objekat zavisi od meta podataka tabele za koju se kreira. U „Prijemnom ispitu” je interfejs implementiran za rad sa MSSql bazom. dok apstraktna klasa OpstiDomenskiObjekat predstavlja deo jezgro okvira. pored toga što implementira apstraktnu klasu OpstiDomenskiObjekat. none } Metode „Restorana” su veoma slične metodama „Cipelarnika”. DajNoviID(). U fazi projektovanja okvira biće neophodno odrediti transformaciju koja će generisati konkretne domenske klase n osnovu meta podataka relacionog modela. updated. OtvoriKonekciju(). a u „Restoranu” za rad sa PostgreSql bazom podataka. tu postoji i metoda za popunjavanje objekta novim vrednostima atributa) Polja – atributi objekta (privatni) Get-Set – metode za izmenu vrednosti atributa Polja konstante – naziv polja iz baze (za prebacivanje iz objektnog u relacioni model i obrnuto). ZatvoriKonekciju(). 70 . u „Cipelarniku” za rad sa MySql bazom. te predstavlja promenljivi deo okvira. kao i naziv tabele u bazi u kojoj se čuva objekta. ZapocniTransakciju(). sa sličnim metodama za pristup bazi. Metode interfejsa brokera “Prijemnog ispita” su: bool bool bool void void void long void KreirajKonekciju(). PonistiTransakciju(). Broker Broker je odgovoran za komunikaciju poslovne logike sa skladištem podataka.

U konkretnom slučaju Bridge uzor ima strukturu koja je prikazana na slici 19. DataTable IzvrsiUpit(string upit). void PonistiTransakciju(). bool pocni. Metode interfejsa brokera “Cipelarnika” su: bool KreirajKonekciju(). Odo SelectOne(Odo odo). string param. DataTable SelectAll(Odo odo). DataTable SelectAll(Odo odo). } Kako se pokazalo u 3 posmatrane aplikacije. int NoviIdFakture(UlaznaFaktura ulaznaFaktura). void PonistiTransakciju(). bool Insert(Odo odo. void ZapocniTransakciju(). bool zavrsi). DataTable SelectAllLike(Odo odo. string deoNaziva). bool zavrsi). void Izbaci(OpstiDomenskiObjekat odo).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad void Promeni(OpstiDomenskiObjekat odo). DataTable DajSifreINazive(OpstiDomenskiObjekat odo). bool zavrsi). bool Update(Odo odo. Zato će biti iskorišćen Brigde uzor (slika 18) koji odvaja (dekupluje) apstrakciju od njene implementacije. bool pocni. string[] DajSveSifre(OpstiDomenskiObjekat odo). void ZapocniTransakciju(). 71 . bool pocni. void PotvrdiTransakciju(). bool zavrsi). void PotvrdiTransakciju(). bool Delete(Odo odo. bool zavrsi). bool Update(Odo odo. string param. DataTable IzvrsiUpit(string upit). DataTable SelectAllLike(Odo odo. bool pocni. DataTable SelectCombo(Odo odo). bool Insert(Odo odo. bool ZatvoriKonekciju(). bool pocni. bool pocni. Moţda će za sledeću implementaciju biti potreban MSSql ili Access ili nešto treće. Novodefinisani interfejs za broker: public interface IDAC { bool KreirajKonekciju(). bool OtvoriKonekciju(). bool zavrsi). bool Delete(Odo odo. Odo SelectOne(Odo odo). DataTable SelectCombo(Odo odo). string deoNaziva). velike su šanse da se relaciona baza razlikuje. bool OtvoriKonekciju(). bool ZatvoriKonekciju(). int NoviIdMagacina(MagacinskiDokument magacinskiDokument).

MSSQL i PostgreSQL bazu. Broker predstavlja deo jezgra okvira. ConcreteImplementor A RefinedAbstraction OperationImp() ConcreteImplementor B OperationImp() Slika 18 Bridge uzor – opšti slučaj KAL OSO IDAC DacOpstiPostgreSql DacOpstiMySql DacOpstiMSSql Slika 19 Bridge uzor . 72 .config). Izbor brokera će biti u konfiguracionom fajlu (app.konkretan slučaj Veoma je verovatno da će korisnicima okvira biti potrebna neka konkretna implementacija brokera.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Client Abstraction Operation() Implementor OperationImp() Imp->OperationImp(). Zato ću okviru pridruţiti 3 konkretne klase za njegovu implementaciju za MySQL.

Klasa za validaciju se bavi najčešćim validacijama (integer i decimal tipa. Skelet aplikacije čine nepromenljive klase okvira (slika 20):  Korisnički interfejs o Forme   FormaInterface . koja će biti podešena da loguje greške koje se dogaĎaju pri komunikaciji sa bazom podataka. enable/disable). Zaključak Na osnovu izvršene analize dolazimo do arhitekture sistema. koje obezbeĎuju različite servise:    Klasa za logovanje grešaka. i veoma slična klasa za realizaciju forme slabog objekta o Kontroler korisničkog interfejsa  KKIOpšti. kao i datuma). odnosno klasa koje zavise od relacionog modela podataka. kao i menjanje podešavanja da li je u polja dozvoljeno pisanje ili nije (eng.jezgra okvira i Promenljivog dela okvira – internih dopuna okvira.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Pomoćne klase U aplikacijama je uočeno nekoliko značajnih klasa. koja se sastoji od:   Skeleta aplikacije .interfejs FOpsta. Klasa takoĎe sadrţi metode koje omogućavaju da se u polja ekranskih formi dozvoli samo upis numeričkih ili integer vrednosti. KKIOpštiSlab – apstraktne klase za opštu realizaciju brokera   KKIHelper – konkretna klasa koja vrši servise formi i kontroleru korisničkog interfejsa Aplikativna logika 73 . a programer je po ţelji moţe proširiti Klasa KKIHelper obezbeĎuje brisanje vrednosti polja forme. FOpstaSlab – opšte klase za realizaciju forme.

DacOpstiMSSql. DacHelperMSSql. DacOpstiPostgreSql – konkretne klase za realizaciju brokera ka različitim sistemima za upravljanje bazom podataka  DacHelperMySql.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad o Kontroler  Kal – konkretna klasa Sistemske operacije  o Poslovna logika  Oso – Klasa za opštu realizaciju sistemske operacije Odo – Apstraktna klasa za opštu realizaciju domenskog objekta  Domenske klase  o Broker   IDAC – interfejs za broker DacOpstiMySql. DacHelperPostgreSql – konkretne pomoćne klase za realizaciju brokera o Pomoćne klase   Log – konkretna klasa za pomoć pri logovanju dogaĎaja Validacija – konkretna klasa za validaciju podataka 74 .

a zelenom promenljive klase okvira. 75 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad KORISNIČKI INTERFEJS SOFTVERSKI SISTEM Korisnički interfejs FOpsta KKIOpsti Kontroler aplikativne logike KAL Oso Sistemske operacije Broker Kontroler korisničkog interfejsa KKIOpstiSlab DacOpstiMySql DacHelperMySql «interface» InterfaceForm KKIHelper Odo «interface» IDAC DacOpstiMSSql DacHelperMSSql FOpstaSlab Domenske klase DacOpstiPostqreSql DacHelperPostgreSql SKLADIŠTE PODATAKA Slika 20 Arhitektura jezgra okvira Na osnovu izvršene analize dolazimo i do šeme koja prikazuje odnos jezgra i internih dopuna okvira. odnosno nepromenljivih i promenljivih klasa okvira (Slika 21). Na slici su narandţastom bojom predstavljene nepromenljive klase. odnosno one koje zavise od meta podataka.

preduslova.2 Opis zahteva pomoću modela slučaja korišćenja Slučaj korišćenja se opisuje preko njegovog naziva. aktora.1. Scenario je opisan preko sekvence akcija: 76 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad SKLADIŠTE PODATAKA «interface» InterfaceForm Korisnički interfejs SOFTVERSKI SISTEM FOpstaSlab FOpsta Broker DacOpstiMySql DacHelperMySql FKonkretna1 FKonkretnaN «interface» IDAC DacOpstiMSSql DacHelperMSSql DacOpstiPostqreSql KKIKonkretan1 KKIKonkretanN DacHelperPostgreSql KKIOpsti Kontroler aplikativne logike KAL OsoKonkretna1 OsoKonkretnaN Oso KKIHelper Kontroler korisničkog interfejsa KKIOpstiSlab Sistemske operacije OdoKonkretna1 OdoKonkretnaN Odo Domenske klase Slika 21 Promenljive i nepromenljive klase okvira 4. opisa. kao i osnovnog i alternativnih scenarija.

Aktor priprema ulazne argumente za sistemsku operaciju o APSO .Aktor poziva sistem da izvrši sistemsku operaciju o ANSO . Programer poziva sistem da kreira novu aplikaciju (APSO) 2.Sistem izvršava sistemsku operaciju o IA .Kreiranje nove aplikacije Naziv: Kreiranje nove aplikacije Aktori: Programer Opis: Programer kreira novu aplikaciju iz datog domena Preduslovi: Programer je kreirao bazu podataka za datu aplikaciju Osnovni scenario: 1. Programer poziva sistem da kreira aplikaciju (APSO) 5. Programer unosi podatke (APUSO) 4.Aktor izvršava nesistemsku operaciju  Sistem izvodi 2 akcije u kontinuitetu: o SO . Sistem prikazuje formu za unos konekcionog stringa ka bazi podataka. moguće je specificirati zahteve sistema preko modela slučajeva korišćenja. Sistem snima aplikaciju i prikazuje poruku (IA) 77 .Sistem prosleĎuje izlazne argumente do aktora Nakon sagledavanja tri aplikacije iz konkretnog domena. naziv aplikacije i lokaciju na koju će biti snimljena (IA) 3. SK1 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad  Aktor izvodi jednu od 3 vrste akcije: o APUSO . Sistem kreira aplikaciju:  Sistem kreira skelet aplikacije (SO)  Sistem kreira forme (SO)  Sistem kreira dizajner (SO)  Sistem kreira kontroler korisničkog interfejsa (SO)  Sistem kreira domenske klase (SO) 6.

SD1 . Programer poziva sistem da kreira aplikaciju (APSO) 4. Kod generator se ne poziva. Sistem prikazuje formu za unos konekcionog stringa ka bazi podataka. naziv aplikacije i lokaciju na koju će biti snimljena (IA) 3.1. Sistem snima aplikaciju (IA) 78 .Kreiranje nove aplikacije 1. 4.3 Ponašanje softverskog sistema – sistemski dijagram sekvenci Za svaki scenario slučaja korišćenja pravi se sekvencni dijagram.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Alternativna scenarija:  Alternativni scenario 1: 4. koji prikazuje u odreĎenom redosledu akcije korisnika i odgovore sistema na te akcije.(SO) 6. Prikazuje poruku (IA) i prekida se izvršenje scenarija.1 Lokacija za snimanje ne postoji ili je samo za čitanje.1 Programer odustaje od kreiranja aplikacije(APSO) 5. Sistem kreira skelet aplikacije. Programer poziva sistem da započne kreiranje nove aplikacije (APSO) 2. Stoga se u sekvencnom dijagramu predstavljaju samo APSO i IA akcije scenarija.1 Baza je nedostupna.1 Sistem snima aplikaciju (IA)  Alternativni scenario 3: 6.1 Sistem prikazuje početnu formu (IA)  Alternativni scenario 2: 5.

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Programer Programer poziva sistem da započne kreiranje nove aplikacije Forma Programer poziva sistem da kreira aplikaciju Snimljena aplikacija Alternativna scenarija:  Alternativni scenario 1: 4.1 Sistem prikazuje početnu formu (IA) 79 .1 Programer odustaje od kreiranja ispitivanja(APSO) 5.

1 Baza je nedostupna.1 Sistem snima aplikaciju (IA) 80 . Kod generator se ne poziva.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Programer Programer poziva sistem da započne kreiranje nove aplikacije Forma Odustani Početna forma  Alternativni scenario 2: 5. Sistem kreira skelet aplikacije.(SO) 6.

Sistem Programer Programer poziva sistem da započne kreiranje nove aplikacije Forma Programer poziva sistem da kreira aplikaciju Poruka o grešci 81 .1 Lokacija za snimanje ne postoji ili je samo za čitanje.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Programer Programer poziva sistem da započne kreiranje nove aplikacije Forma Programer poziva sistem da kreira aplikaciju Snimljen skelet aplikacije  Alternativni scenario 3: 6. Prikazuje poruku (IA) i prekida se izvršenje scenarija.

Ugovor: KreirajSkeletAplikacije Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajSkeletAplikacije (Aplikacija app) SK1 Kreiran je skelet aplikacije Ugovor: KreirajDizajnerForme Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajDizajnerForme (Fajl FormaDesigner) SK1 Sistem je ostvario konekciju sa bazom podataka Kreirane su parcijalne klase dizajner forme Ugovor: KreirajForme Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajForme(Fajl Forma) SK1 Sistem je ostvario konekciju sa bazom podataka Kreirane su parcijalne klase forme (pozadinski kod forme) Ugovor: KreirajKKI Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajKKI(Fajl KKI) SK1 Sistem je ostvario konekciju sa bazom podataka Kreirane su klase kontrolera korisničkog interfejsa aplikacije Ugovor: KreirajDK Operacija: Veza sa SK: Preduslovi: KreirajDK (Fajl DomenskaKlasa) SK1 Sistem je ostvario konekciju sa bazom podataka 82 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 4.1.4 Ponašanje softverskog sistema – definisanje ugovora o sistemskim operacijama Za svaku sistemsku operaciju definiše se ugovor koji opisuje šta ona treba da radi bez ulaţenje u to kako će to da radi.

1 Arhitektura softverskog sistema U fazama prikupljanja zahteva i analize data je specifikacija strukture i ponašanja softverskog sistema. što čini poslovnu logiku sistema (slika 23).2. 83 .konceptualni model Na osnovu analize slučajeva korišćenja dobijen je konceptualni model sistema (slika 22). aplikacione logike i skladišta podataka. Na opštem modelu tronivojske arhitekture moţe biti prikazana konkretna poslovna logika. Slika 22 Konceptualni model 4.5 Struktura softverskog sistema . a obuhvata projektovanje korisničkog interfejsa. 4. A do kraja izrade dokumentacije i ostali opšti objekti biće zamenjeni konkretnim objektima.2 Projektovanje Faza projektovanja opisuje strukturu i ponašanje softverskog sistema (arhitekturu softverskog sistema).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Postuslovi: Kreirane su domenske klase aplikacije 4.1.

2 Kontroler aplikativne logike Preko kontrolera aplikativne logike prosleĎuju se zahtevi klijenta do odgovarajućih sistemskih operacija (slika 24).2.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad SOFTVERSKI SISTEM APLIKACIONA LOGIKA KORSNIČKI INTERFEJS KONTROLER BROKER SKLADIŠTE PODATAKA POSLOVNA LOGIKA STRUKTURA SISTEMA PONAŠANJE SISTEMA Slika 23 Arhitektura softverskog sistema 4. 84 .

2.softverske klase strukture 4.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad SOFTVERSKI SISTEM APLIKACIONA LOGIKA BROKER KONTROLER POSLOVNA LOGIKA SKLADIŠTE PODATAKA KORSNIČKI INTERFEJS Slika 24 Arhitektura softverskog sistema .3 Projektovanje strukture softverskog sistema (aplikaciona logika poslovna logika .domenske klase) Na osnovu konceptualnih klasa prave se softverske klase strukture (slika 25). 85 .

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 25 Softverske klase strukture Dijagram softverskih klasa strukture je predstavljen na slici 26. 86 .

Ova sistemska operacija kopira skelet aplikacije na novu lokaciju. odnosno jezgro okvira. Kada se sistemska operacija izvrši. onu koju je programer zadao.2. Te klase će biti identične za svaku aplikaciju koja se kreira preko okvira. na novoj lokaciji će biti kreirana 87 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad SOFTVERSKI SISTEM APLIKACIONA LOGIKA SKLADIŠTE PODATAKA BROKER KONTROLER POSLOVNA LOGIKA KORSNIČKI INTERFEJS Slika 26 Dijagram softverskih klasa strukture 4. Ugovor: KreirajSkeletAplikacije Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajSkeletAplikacije (Aplikacija App) SK1 Kreiran je skelet aplikacije Analizom je utvrĎeno da postoje klase aplikacije koje ne zavise od meta podataka. kontroler interfejsa i domenske klase.4 Projektovanje ponašanja softverskog sistema (aplikaciona logika poslovna logika – sistemske operacije) Ovde će biti detaljnije opisano kako će izgledati konkretne klase za formu. One zajedno čine skelet aplikacije.

Slika 27 Skelet aplikacije .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad odreĎena struktura foldera (detaljnije opisana u projektovanju skladišta podataka) i C# projekti sa meĎusobnim referencama (Slika 27).C# projekti Ugovor: KreirajDizajnerForme Operacija: KreirajDizajnerForme(Fajl FormaDesigner) 88 .

Regioni od kojih se sastoji su:   Zaglavlje KreirajLabelInput – kreira parove kontrola “Label” i “TextBox”. FArtikal). cbxJedinicaMere) Od programera se očekuje da elemente rasporedi na ţeljeni način na formi. Dobija naziv FPascalCaseImeTabele 3 (npr. itd. kao i da po potrebi promeni kontrole.kreiranje dizejnera forme Ugovor: KreirajForme Operacija: 3 KreirajForme(Fajl Forma) PascalCase – način pisanja više reči po kome se reči pišu bez razmaka. počinje od neke predefinisane visine. Tipovi kontrola: o TextBox o ComboBox – za atribute koji su spoljni ključevi o DateTimePicker – za atribute tipa DateTime Imenovanje: o Za labele:   Naziv labele .lblPascalCaseImePolja (npr.Designer. Slika 28 Sistemska operacija . npr: RečiBezRazmaka 89 . Naziv artikla) o Za tekst polja – txtPascalCaseImePolja (npr. txtNazivArtikla) o Za ComboBox – cbxPascalCaseImePolja(npr.cs) se kreira za svaku tabelu iz baze podataka. redosled operacija. svaka sa velikim početnim slovom. lblNazivArtikla) Text labele – Pascal case ime polja (npr. a svaki sledeći par pozicionira još 30px niţe.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Veza sa SK: SK1 Preduslovi: Sistem je ostvario konekciju sa bazom podataka Postuslovi: Kreirane su parcijalne klase dizajner forme Klasa dizajner forme (Form.

Dobija isti naziv kao i klasa dizajnera forme. foreach (DataRow dr in tblShema. sb.EnablujPolja(true. inicijalizuju komponente i kreiraju objekat klase kontroler korisničkog inetrfejsa za konkretnu formu. Pomoćne metode – metode za omogućavanje (tabela 2) i onemogućavanje upisa u polja forme.AppendLine().KKIHelper.AppendLine(). new Control[] { "). sb. sb. sb. osim tabela slabih objekata. I dodatno je kreiran konstruktor forme koji će se referencirati na kontroler korisničkog interfejsa date forme.Append("{"). Slika 29 Sistemska operacija . Regioni od kojih se sastoji su:    Zaglavlje Konstruktori – izvršavaju se pri kreiranju forme. NasleĎuje klasu Fopsta. Prekrivene su samo metode za otvaranje i zatvaranje polja za upis. sb.AppendLine(). sb.Append("public override void EnablujPolja()").Rows) { 90 . DataTable tblShema) { StringBuilder sb = new StringBuilder().Append("KKI.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Veza sa SK: Preduslovi: Postuslovi: SK1 Sistem je ostvario konekciju sa bazom podataka Kreirane su parcijalne klase forme (pozadinski kod forme) Klasa forme se kreira za svaku tabelu iz baze podataka. Klasa je predstavljana na slici 29.kreiranje forme Transformacija private static string KreirajEnable(string imeTabele.

sb.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad if (dr["ordinal_position"]. } if (dr["ordinal_position"].Append("}). tj za svaku tabelu iz baze podataka.Append(".ToString() == "") { sb. NasleĎuje klasu KKIOpsti.2. sb.ToString() == "1") { sb. txtTelefon}). } Tabela 2 Metoda KreirajEnable Generisani kod (primer) Ugovor: KreirajKKI Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajKKI(Fajl KKI) SK1 Sistem je ostvario konekciju sa bazom podataka Kreirane su klase kontrolera korisničkog interfejsa aplikacije Klasa kontrolera korisničkog interfejsa se kreira za svaku formu. return sb. txtImeIPrezime. ").").ToString(). npr: Artikal artikal.AppendLine().Append(". sb. txtAdresa. Transformacija public static string KreirajKonstruktor(string imeTabele.Append(PomocnaKlasa.KKIHelper.Append(PomocnaKlasa. DataTable tblShema) 91 . } public override void EnablujPolja() { KKI. 2).AppendLine().Length .Remove(sb. new Control[] { txtId. Regioni od kojih se sastoji su:    Zaglavlje Polja – referenca na objekat domenske klase na koju se forma. Dobija naziv KKIPascalCaseImeTabele (npr. "). sb.ToTxtName(dr["COLUMN_NAME"])). sb.Append("}").EnablujPolja(true.ToCbxName(dr["REFERENCED_table_NAME"])). Konstruktori – konstruktor kreira samo nove objekte tipa “kal” i konkretne domenske klase (tabela 3). KKIArtikal). sb. } } sb.

Append("(). enable) o SnimiObjekat – upisivanje novog ili promena postojećeg objekta u zavisnosti da li je parametar operacijaNov true ili false. sb. polje.Append(" = new ").AppendLine().ToString().Append("#endregion"). i fokusira se na 1. sb. sb.Append("form = f.Append("kal = new Kal().TocamelCase(imeTabele)). sb.Append("(Form f)"). sb. popunjavaju se sve ComboBox kontrole. sb. o NovObjekat – kreira nov objekat. sb.ToPascalCase(imeTabele)). sb. prazni polja forme i dozvoljava upis u njih (eng. form = f. Kao ulazni 92 . sb. return sb. clan = new Clan().AppendLine().Append( PomocnaKlasa.").Append("{").Append("}"). sb.Append("#region Konstruktori").Append( PomocnaKlasa.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad { StringBuilder sb = new StringBuilder(). } #endregion Tabela 3 Metoda KreirajKonstruktor  DogaĎaji – odnose se na dogaĎaje na formi: o FormLoad – pri učitavanju forme poziva se ova metoda koja popunjava DataGridView sa svim podacima iz ţeljene tabele baze podataka."). sb.AppendLine()."). sb.AppendLine().AppendLine(). sb.AppendLine().ToKKIName(imeTabele)). } Generisani kod #region Konstruktori (primer) public KKIClan(Form f) { kal = new Kal().Append(PomocnaKlasa. sb. sb. sb. sb. sb. sb.AppendLine().AppendLine().AppendLine(). sb. sb.AppendLine().Append("public "). onemogućava promenu teksta u poljima za kreiranje i izmenu objekta. sb. sb.

Pri kliku na taster DEL na selektovanom redu poziva se brisanje ţeljenog objekta. onemogućava upis u tekstualna polja (eng. a kao izlazni parametar ima tekst da li je operacija uspela ili ne. 93 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad parametar ima formu iz koje uzima podatke za atribute objekta. disable) i fokusira se na dugme za kreiranje novog objekta. o PopuniGrid – popunjava DataGridView sa svim podacima iz baze o PopuniCombo – postoji za svaku ComboBox kontrolu na formi i popunjava je podacima iz baze  Data grid view metode – odnose se na kretanje kroz DataGridView (strelice gore i dole). pri čemi se popunjavaju polja za izmenu sa selektovanom vrednošću. osveţava DataGridView kontrolu sa forme. TakoĎe. o NadjiObjekat – vraća objekat po primarnom ključu i upisuje ga u polja forme.

Artikal). U analizi domena je zaključeno da se domenske klase sastoje od regiona: 94 .kreiranje kontrolera korisničkog interfejsa Ugovor: KreirajDK Operacija: Veza sa SK: Preduslovi: Postuslovi: KreirajDK (Fajl DomenskaKlasa) SK1 Sistem je ostvario konekciju sa bazom podataka Kreirane su domenske klase aplikacije Za svaku tabelu iz relacionog modela kreira se posebna domenska klasa. Domenska klasa se naziva PascalCase imenom tabele (npr.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 30 Sistemska operacija .

").Length . 2).Append(PomocnaKlasa. sb.Append(PomocnaKlasa.Append(PomocnaKlasa. sb. DataTable tblShema) { StringBuilder sb = new StringBuilder(). } } sb.").2.Rows) { if (dr["column_key"]. foreach (DataRow dr in tblShema.Append(PomocnaKlasa.TocamelCase( dr["COLUMN_NAME"])). sb.Append(PomocnaKlasa.ToString()=="") { sb.Append("(")."). sb. sb. foreach (DataRow dr in tblShema. } if (dr["ordinal_position"]. a u ovoj metodi se od njih kreira objekat domenske klase (tabela 4). sb. public static string KreirajKonstruktorPK(string imeTabele.Append("="). sb. Postoji više različitih konstruktora. sb.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad   Zaglavlje klase – sadrţi reference ka spoljnim klasama koje će biti korišćene. sb. sb. sb. sb.ToPascalCase(imeTabele)).Rows) { if (dr["column_key"].AppendLine().ToString() == "PRI") { sb.Append(".ToString() == "PRI") { if (dr["ordinal_position"]. sb.TypeConversion( dr["DATA_TYPE"])). sb. koji se razlikuju po ulaznim parametrima: o Samo primarni ključ. kao i početak imenovanog prostora i klase Konstruktori klase.Append(" ").Append("this.Append(")").TocamelCase( dr["COLUMN_NAME"])).AppendLine().AppendLine().Append(".ToString() == Transformacija 95 . sb.Append("public "). sb.AppendLine().Append("{"). gde se spoljni ključevi prosleĎuju po tipu iz relacionog modela.TocamelCase( dr["COLUMN_NAME"])).Remove(sb.

Append("}"). this. this. 2 metode. Jedinicamere jedinicamere) { this. U jednoj se spoljni ključevi prosleĎuju kao objekti domenskih klase (1.a u drugoj po tipu iz relacionog modela (2.dr)). string naziv. return sb.ToString(). } Generisani kod public Artikal(int id) (primer) { this. string naziv.jedinicamere = } new Jedinicamere(jedinicaMereId). } Tabela 4 Metoda KreirajKonstruktorPK o Svi parametri sem primarnog ključa (spoljni ključevi se prosleĎuju po tipu iz relacionog modela.jedinicamere=jedinicamere. string naziv. } public Artikal(int id. primer): public Artikal(int id. string idVdljiv.naziv=naziv. o Svi parametri.naziv=naziv.AppendLine().id=id.AppendFormat( VratiKreirajObjekatKonstruktor( imeTabele.id=id. sb. Primer izgenerisanog koda: public Artikal(string idVdljiv. this.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad "1") { sb. this. primer).idVdljiv=idVdljiv.tblShema.idVdljiv=idVdljiv. a u ovoj metodi se od njih kreira objekat domenske klase). } } } sb. this. int jedinicaMereId) { this. string idVdljiv. int jedinicaMereId) 96 .

id=id.jedinicamere = } new Jedinicamere(jedinicaMereId).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad { this. string naziv. a namena joj je popunjavanje već kreiranog objekta novim vrednostima (spoljni ključevi se prosleĎuju po tipu iz relacionog modela. Ukoliko polje pripada spoljnom ključu. this.AppendLine(). this. Primer izgenerisanog koda: public { this. this. osim prve reči koja počinje malim slovom.naziv=naziv. njegov naziv je isti kao naziv polja u tabeli (camelCase 4).jedinicamere = } new Jedinicamere(jedinicaMereId). Artikal Upisi(string idVdljiv. this.naziv=naziv. Ukoliko polje ne pripada spoljnom ključu. ulazni parametri su svi parametri sem primarnog ključa. foreach (DataRow dr in tblShema. string slab. Transformacija public static string KreirajPolja(DataTable tblShema.Rows) 44 camelCase – način pisanja više reči po kome se reči pišu bez razmaka. this.AppendLine(). logički pripada ovom regionu). sb. sb. „varchar“ se konvertuje u „string“). ArrayList alSlabi) { StringBuilder sb = new StringBuilder(). Treba obratiti paţnju da ukoliko je spoljni ključ sloţen.idVdljiv=idVdljiv. o Metoda Upiši (iako nije konstruktor klase. Sva polja su privatna. int jedinicaMereId)  Polja – Svako polje iz tabele se konvertuje u atribut domenske klase. ne sme se kreirati više atributa u domenskoj klasi za taj spoljni ključ! Primer je dat u tabeli 5.idVdljiv=idVdljiv. a tip polja se konvertuje u tip koji odgovara tipu podatka specifičnom za C# programski jezik (npr. svaka sa velikim početnim slovom. njegov naziv ( camelCase) i tip (PascalCase) su isti kao naziv tabele kojoj pripada spoljni ključ.Append("#region Polja"). sb. npr: rečiBezRazmaka 97 . a u ovoj metodi se od njih kreira objekat domenske klase).

sb. sb.ToString() == "" ? PomocnaKlasa.TocamelCase(dr["COLUMN_NAME"]) : PomocnaKlasa.ToSlabObj(s)).").Append(" = new ArrayList().AppendLine().AppendLine(). } } if (alSlabi!=null) { foreach (string s in alSlabi) { sb. string camelIme = dr["REFERENCED_COLUMN_NAME"]. samo su public (tabela 6).ToString() == "1" || dr["ordinal_position"]. string pascalIme = dr["REFERENCED_COLUMN_NAME"].Append( PomocnaKlasa. } } sb. sb.Append(camelIme).AppendLine(). sb.").ToPascalCase(dr["COLUMN_NAME"]) : PomocnaKlasa.ToString(). return sb. i očekuje se da će programer izbrisati nepotrebne.ToString() == "" ? PomocnaKlasa. sb.ToString() == "" || dr["ordinal_position"]. #endregion Tabela 5 Metoda KreirajPolja  Get-set (tj property za polja) – formiraju se po sličnim pravilima kao i atributi iz regiona “Polja”. sb. Formiraju se za sva polja. private Jedinicamere jedinicamere. sb. 98 .ToPascalCase(dr["REFERENCED_TABLE_NAME"] ).ToString()==null) { string tip = dr["REFERENCED_COLUMN_NAME"].Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad { if (dr["ordinal_position"].Append("private ArrayList "). sb.Append(tip).ToString() == "" ? PomocnaKlasa.ToPascalCase(dr["REFERENCED_TABLE_NAME"] ). sb.TypeConversion(dr["DATA_TYPE"]) : PomocnaKlasa.Append(" "). sb.Append("#endregion").Append("private ").Append(". } Dobijeni (primer) kod #region Polja private string naziv.TocamelCase(dr["REFERENCED_TABLE_NAME"]) .

sb.Append("}").Append(pascalIme). sb. sb.} } Tabela 6 Isečak metode KreirajGetSet Dobijeni (primer) kod 99 .ToString() == "" ? PomocnaKlasa.AppendLine().TocamelCase(dr["COLUMN_NAME"]) : PomocnaKlasa.Append(camelIme).}").ToString() == "" ? PomocnaKlasa.AppendLine().Append("public ").ToString() == "1" || dr["ordinal_position"].Append(camelIme).Append(" "). polja if (dr["ordinal_position"].}"). string pascalIme = dr["REFERENCED_COLUMN_NAME"]. sb.} set { jedinicamere = value.AppendLine(). sb.ToString() == "" ? PomocnaKlasa. sb.Append("{").ToPascalCase(dr["COLUMN_NAME"]) : PomocnaKlasa. sb.} set { naziv = value.TypeConversion(dr["DATA_TYPE"]) : PomocnaKlasa. sb. sb.Append(tip).ToString() == null) { string tip = dr["REFERENCED_COLUMN_NAME"]. sb.AppendLine().Append(" = value. sb.TocamelCase(dr["REFERENCED_TABLE_NAME"]) . sb. sb.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Transformacija //kreiranje 1. } public string Naziv { get { return naziv. sb. string camelIme = dr["REFERENCED_COLUMN_NAME"].ToPascalCase(dr["REFERENCED_TABLE_NAME"] ).AppendLine(). sb.ToString() == "" || dr["ordinal_position"]. sb.Append("get { return ").Append("set { ").} } public Jedinicamere Jedinicamere { get { return jedinicamere.Append(". sb.ToPascalCase(dr["REFERENCED_TABLE_NAME"] ).

public override string NazivTabele { get { return NAZIV_TABELE. Konstante imaju naziv P_IMEPOLJA. Primer generisanog koda: public const string P_NAZIV = "naziv".naziv = Convert. }  CRUD – region za osnovne operacije nad bazom podataka.ToString(vrsta[P_NAZIV]).id = Convert. što se u brokeru interpretira kao “select *”. builder. artikal.jedinicamere = new Jedinicamere( Convert.ToString(vrsta[P_IDVDLJIV]).ToInt32(vrsta[P_ID]).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad   Slabi objekti Konstante – sadrţe nazive polja u bazi. return artikal.Append("insert into "). Primer generisanog koda: public override string DajInsert() { StringBuilder builder = new StringBuilder(). public const string P_JEDINICAMEREID = "jedinicaMereId". o Metode Select i SelectAll vraćaju prazne stringove. artikal.idVdljiv = Convert. Primer generisanog koda: public override Odo KreirajObjekat(DataRow vrsta) { Artikal artikal = new Artikal(). Nazivi i tipovi atributa objekta se odreĎuju kao što je objašnjeno kod polja. Kao nazivi atributa u bazi koriste se definisane konstante. artikal. } }  Kreiraj objekat iz baze – sadrţi metodu KreirajObjekat u kojoj se kreira nov objekat tipa konkretne domenske klase. a povezuju se sa odgovarajućim poljuma iz DataRow objekta na osnovu konstanti.ToInt32( vrsta[ P_JEDINICAMEREID ] )). id i naziv. i taj objekat se popunjava vrednostima iz reda tabele (ulazni parametar tipa DataRow). a programer ih po ţelji moţe promeniti o Metoda Insert kreira insert naredbu kojom će se insertovati svi atributi konkretnog objekta. artikal. 100 . kao i get propertije za atribute naziv tabele.

Append(". builder.Append("'"+naziv+"'")."). builder. sem primarnog ključa.").2.Append("values").Append(P_ID).Append("(").ToString(). builder. builder. builder. builder. builder. za zadat primarni ključ. ali ne radi izvršavanja CRUD operacija. builder. builder.Append(")").Append(".").Append(")").Append(id).").Append(". o Metoda DajDeleteUslov – vraća uslov za brisanje – podrazumevano vraća prazan string o Metoda DajId – vraća primarni ključ 4.Append(". nego radi čitanja meta podataka iz baze. Osnovne metode brokera su: 101 .Append(".Append(jedinicamere.Append(P_JEDINICAMEREID). builder. builder. } o Metoda Update – menja sve atribute objekta. builder. builder. builder. builder.5 Projektovanje aplikacione logike – database broker Broker će komunicirati sa bazom podataka.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad builder. builder. na osnovu kojih će biti kreirane klase aplikacije koje zavise od relacionog modela podataka. builder.").Id).Append(". builder. builder.Append(P_IDVDLJIV).Append(P_NAZIV). return builder.Append(NAZIV_TABELE).Append("(").Append("'"+idVdljiv+"'").").

proširenu za kolone koje prikazuju podatke o tome da li je polje spoljni ključ. što je skladište podataka.vraća tabelu u kojoj svaki red sadrţi podatke o jednom polju tabele: naziv polja.6 Projektovanje skladišta podataka Skladište podataka je sistem fajlova (slika 33).2. itd. VratiShemuTabele . i ukoliko jeste naziv tabele i kolone na koju se polje referencira. komentar tabele. VratiForeignKeyTabele – vraća tabelu kao VratiShemuTabele. itd.vraća tabelu u kojoj svaki red sadrţi podatke o jednoj tabeli izabrane baze podataka: naziv tabele.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad    VratiShemu . broker će imati metodu za upis podataka na fajl sistem. SOFTVERSKI SISTEM APLIKACIONA LOGIKA SKLADIŠTE PODATAKA KONTROLER POSLOVNA LOGIKA KORSNIČKI INTERFEJS Slika 31 Arhitektura softverskog sistema – broker Slika 32 Kreiranje brokera 4. Struktura po kojoj će folderi biti kreirani je sledeća:  Osnovni folder sa nazivom aplikacije (kreiran na putanji koju je korisnik zadao) 102 . TakoĎe. tip polja. tip tabele. tip ključa.

u njega se snimaju svi fajlovi sistemskih operacija o Folder KAL .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad o Folder KI – u njega se snimaju svi fajlovi za korisnički inerfejs o Folder KKI .u njega se snimaju svi fajlovi za kontroler korisničkog inerfejsa o Folder DK .u njega se snimaju svi fajlovi za broker SOFTVERSKI SISTEM APLIKACIONA LOGIKA SKLADIŠTE PODATAKA Sistem fajlova KONTROLER POSLOVNA LOGIKA KORSNIČKI INTERFEJS Slika 33 Arhitektura softverskog sistema .u njega se snimaju svi fajlovi za kontroler aplikativne logike o Folder DAC .2.skladište podataka 4.7 Projektovanje ekranskih formi 1. Programer poziva sistem da kreira novu aplikaciju (APSO) Opis akcije: Programer pokrene aplikaciju 2.u njega se snimaju svi fajlovi domenskih klasa o Folder SO . naziv aplikacije i lokaciju na koju će biti snimljena (IA) 103 . Sistem prikazuje formu za unos konekcionog stringa ka bazi podataka.

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

3. Programer unosi podatke (APUSO)

4. Programer poziva sistem da kreira aplikaciju (APSO)

Opis akcije: Programer klikne mišem na dugme »Snimi« 5. Sistem kreira aplikaciju:  Sistem kreira skelet aplikacije (SO)  Sistem kreira forme (SO)  Sistem kreira dizajner (SO)
104

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

 Sistem kreira kontroler korisničkog interfejsa (SO)  Sistem kreira domenske klase (SO) 6. Sistem snima aplikaciju (IA)

Alternativna scenarija:   4.1 Programer odustaje od kreiranja ispitivanja(APSO) 5.1 Sistem prikazuje početnu formu (IA) 5.1 Baza je nedostupna. Sistem kreira skelet aplikacije. Kod generator se ne poziva.(SO) 6.1 Sistem snima aplikaciju (IA)

6.1 Lokacija za snimanje ne postoji ili je dostupna samo za čitanje, ili se dogodila neka druga greška. Prikazuje poruku (IA) i prekida se izvršenje scenarija.

105

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

4.2.8 Zaključak Kao što je već navedeno, desktop aplikacija koju bi Oz okvir trebalo da generiše se sastoji od:    Skeleta aplikacije – jezgra, odnosno nepromenljivog dela okvira, koji se kao takav nalazi u svakoj aplikaciji kreiranaoj korišćenjem okvira, Promenljivog dela okvira – klasa koje okvir generiše na osnovu relacionog modela, Ostalih dopuna vezanih za aplikaciju – koje izvršava korisnik okvira, i nisu deo samog okvira. U fazi projektovanja okvira za sve komponente koje čine promenljivi deo okvira izvedene su transformacije koje se koriste za generisanje tih komponenti na osnovu relacionog modela podatak. Pored toga naznačene su i ţarišne tačke u kojima korisnik okvira moţe proširivati funkcionalnosti generisane aplikacije. Time smo dobili detaljniju šemu načina na koji se relacioni model transformiše u konkretnu desktop aplikaciju, što je prikazano na slici 34.

106

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Relacioni model Tabela 2 Tabela 3 Tabela 1 Tabela 4 Tabela 5 OKVIR KONKRETNA DESKTOP APLIKACIJA Slika 34 Konceptualni model okvira 107 .

1-4.1 i 4. za proizvoljan domen problema. Kroz ovo poglavlje biće predstavljeno instanciranje okvira (kreiranje aplikacije preko okvira). Implementacija je izvršena u Microsoft Visual Studio 2005 okruţenju. 108 . za . do prepravki dobijene aplikacije do potpune ţeljene funkcionalnosti. što će pomoći u razumevanju okvira.    Recept – u poglavlju 4. 4.3 iznet je razvoj okvira. i biće opisano kako primeniti okvir na kreiranju konkretne aplikacije.4 biće predstavljen studijski primer. koje su posebno predstavljene na slici 17.5 Korišćenje okvira Okvir je sada u potpunosti razvijen i spreman za upotrebu. postoji mnogo načina dokumentovanja okvira.3 Implementacija okvira Nakon završenog projektovanja okvira izvršena je implementacija zadatih funkcionalnosti u C# programskom jeziku i otklanjanje grešaka nastalih u implementaciji. Kroz poglavlja 4.NET Framework 2. 4.2 predstavljena je kreirana arhitekutra sistema. i definisane su ţarišne i zamrznute tačke okvira.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 4. preko detaljnog uputstva za korišćenje okvira. i korišćeni uzori projektovanja. Primer aplikacije – uz okvir će postojati i kompletan izvršni kod studijskog primera Uzori projektovanja – u poglavljima 4.7 navedeno.4 Dokumentovanje okvira Kao što je u poglavlju 2. a najsigurnije je opredeliti se za nekoliko načina:  Pregled okvira – kontekst okvira: konkretan okvir generiše skelet tronivojske aplikacije i implementira CRUD operacije nad bazom podataka. počev od analize zahteva.0.

Osnovni scenario : 1.(APUSO) 2.(SO) 4. evidenciju članova.5. sistem prikazuje formu za pretraţivanje CD-ova. Ucesnici: Korisnik i sistem.Ukoliko CD sa zadatim brojem ne postoji sistem prikazuje na ekranu poruku da CD ne postoji i prekida se izvršenje scenarija. koja je izvršena po njegovom rednom broju.5.(IA) Alternativna scenarija: 1. Preduslov: Sistem je uključen.1. Aktori: Korisnik Ucesnici: Korisnik i sistem. 4.1. Korisnik poziva sistem da izvrši pretragu. Aktori: Korisnik.(APSO) 109 . Sistem prikazuje korisniku podatke o CD-u. Pretraţi CD Naziv: Pretraţi CD-ove.(APSO) 3. i praćenje iznajmljivanja CD-ova. Korisnik unosi podatke o CD-u potrebne za pretragu. Aplikacija će omogućiti evidenciju CD-ova. Osnovni scenario: 1. Kreiraj novog CD-a Naziv: Kreiranje novog CD-a.Korisnik odustaje od pretrage CD-ova. sistem prikazuje formu za pretraţivanje CD-ova.1 Opis zahteva pomoću modela slučaja korišćenja 1. 3. 2.1 Analiza zahteva 4. Korisnik poziva sistem da kreira novi CD.1. Sistem vrši pretragu i priprema podatke za prikaz.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Studijski primer predstavlja aplikaciju za pomoć u radu u CD klubu. Preduslov: Sistem je uključen.

(SO) 4. Ukoliko sistem ne moţe da kreira nov CD prikazuje se odgovarajuća poruka.(APUSO) 2. i scenario se prekida. Aktori: Korisnik.1. i scenario se prekida. 8. Sistem kreira novog CD-a. Korisnik unosi podatke. Aktori: Korisnik. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA). 3. Sistem prikazuje korisniku polja u koja moţe uneti podatke o novom CD-u.1. uspešno izvršeno pretraţivanje CD-a(Sistem prikazuje postojeći CD). Osnovni scenario: 1. i scenario se prekida. Ukoliko sistem ne moţe da snimi podatke o CD-u prikazuje se odgovarajuća poruka. Korisnik poziva sistem da snimi unete podatke o CD-u(APSO) 3.(APUSO) 6. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA). Korisnik unosi potrebne izmene. Alternativna scenarija 3.1. Sistem snima naznačene izmene(SO) 4. Sistem vrši snimanje podataka(SO). Obriši CD Naziv: Brisanje CD-a. Alternativna scenarija: 2. 7. 4. Korisnik poziva sistem da sačuva podatke o CD-u(APSO) 7. 110 .(IA) 5.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2. Ucesnici : Korisnik i sistem. Preduslov: Sistem je uključen.Aţuriraj CD Naziv: Aţuriranje CD-a. Ukoliko sistem ne moţe da snimi podatke o CD-u prikazuje se odgovarajuća poruka.

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Ucesnici: Korisnik i sistem. Ucesnici: Korisnik i sistem. Korisnik poziva sistem da izbrise taj CD.1.(APSO) 3. Osnovni scenario 1. Osnovni scenario: 1. Ukoliko sistem ne moţe da izbriše CD prikazuje se odgovarajuća poruka. i scenario se prekida. Kreiranje nove članske karte Naziv:Kreiranje nove članske karte. Sistem vrši pretragu i priprema podatke za prikaz. Korisnik unosi podatke o članu potrebne za pretragu. 111 . 2.(APUSO) 2. 5. Korisnik poziva sistem da izvrši pretragu.Ukoliko član sa zadatim rednim brojem ne postoji sistem prikazuje na ekranu poruku da taj član ne psotoji i prekida se izvršenje scenarija. Pretraţi članske karte Naziv: Pretraţi člana.(SO) 4.sistem prikazuje formu za pretraţivanje člana. Aktori: Korisnik Ucesnici: Korisnik i sistem.(APSO) 2.(IA) Alternativna scenarija 2. uspešno izvršeno pretraţivanje CD-a(Sistem prikazuje postojeći CD).(IA) Alternativna scenarija 3. Preduslov: Sistem je uključen. Sistem prikazuje poruku o uspešnosti izvršenja operacije. Preduslov: Sistem je uključen.(SO) 3. Sistem prikazuje korisniku podatke o članu dobijene pretragom koja je izvršena po njegovom rednom broju. Aktori: Korisnik.1. Sistem briše CD tog rednog broja.

(IA) 4. i scenario se prekida. Osnovni scenario : 1. Alternativna scenarijo: 3. Osnovni scenario: 1. Aktori: Korisnik.Aţuriranje članske karte Naziv: Aţuriranje članske karte. Korisnik poziva sistem da snimi unete podatke o članu(APSO) 3.(APSO) 6. 4.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Preduslov: Sistem je izvršio ptretragu ćlanskih karti.1. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA). Ukoliko sistem ne moţe da snimi podatke o članu prikazuje se odgovarajuća poruka. Sistem kreira novog člana. Ukoliko sistem ne moţe da kreira novou člansku kartu prikazuje se odgovarajuća poruka. i iznajmljenim CD-ovima.(APSO) 2. 5. Korisnik poziva sistem da kreiranovu člansku kartu.(APUSO) 2. Brisanje članske karte Naziv:Brisanje člana. Sistem snima naznačene izmene(SO) 4. Sistem prikazuje korisniku polja gde moţe uneti podatke o novom članu. Alternativna scenarija: 2.1.(APUSO) 5. Korisnik unosi potrebne izmene. 3. Ukoliko sistem ne moţe da snimi podatke o članu prikazuje se odgovarajuća poruka.(SO) 3.1. Preduslov: Sistem je prethodno izvršio ptretragu članske karte. Korisnik unosi podatke o članu. 112 . Ucesnici: Korisnik i sistem. Korisnik poziva sistem da snimi podatke. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA). i scenario se prekida. i scenario se prekida.

1.(SO) 3.2 Ponašanje softverskog sistema – sistemski dijagram sekvenci DSK1 Dijagram sekvenci slučaja korišćenja –Pretraţi CD Osnovni scenario: 1.1.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Aktori: Korisnik.(IA) Alternativna scenarija: 2. 4.5. Ucesnici: Korisnik i sistem. Ukoliko sistem ne moţe da izbriše člana prikazuje se odgovarajuća poruka. Preduslov: Sistem je prethodno izvršio ptretragu članske karte.(APSO) 2. Preduslov: Sistem je prethodno izvršio ptretragu članske karte.Poruka o neuspelom snimanju podataka. Aktori: Korisnik. Korisnik poziva sistem da izvrši pretragu. Sistem prikazuje poruku o uspešnosti izvršenja operacije. 4. 9.Sistem pamti unete podatke(SO) 5. Osnovni scenario: 1.1.Korisnik poziva sistem da zapamti iznajmljivanja CD-a.(APSO) 113 .(IA) Alternativna scenarija 2.1. Osnovni scenario: 1. Korisnik poziva sistem da izbrise tog člana.Greska u sistemu.Sistem prikazuje sve podatke o iznajmljenom CD-u. Sistem briše člana tog rednog broja. i scenario se prekida. Iznajmljivanje CD-a Naziv: Iznajmljivanje CD-ova.(APSO) 4. Ucesnici: Korisnik i sistem.

1. koja je izvršena po njegovom rednom broju. Sistem Korisnik Pretrazi CD() Odustajanje od pretrage 2. Sistem prikazuje korisniku podatke o CD-u. 114 .Ukoliko CD sa zadatim brojem ne postoji sistem prikazuje na ekranu poruku da CD ne psotoji i prekida se izvršenje scenarija.(IA) Sistem Korisnik Pretrazi CD() PronadjenCD Alternativna scenarija: 1.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 2.1.Korisnik odustaje od pretrage CD-a.

Korisnik poziva sistem da sačuva podatke o CD-u(APSO) 4. 115 . Korisnik poziva sistem da kreira novog CD-a. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA).(IA) 3.(APSO) 2. Sistem prikazuje korisniku polja gde moţe uneti podatke o novom CD-u.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik Pretrazi CD() Poruka da cd ne postoji DSK2 Dijagram sekvenci slučaja korišćenja –Kreiraj nov CD Osnovni scenario : 1.

1. Ukoliko sistem ne moţe da kreira CD prikazuje se odgovarajuća poruka. Sistem Korisnik Kreiraj novi CD() Poruka da CD ne moze biti kreiran 116 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik Kreiraj novi CD() NoviCD Snimi CD() Poruka o uspesnom snimanju Alternativna scenarija: 1. i scenario se prekida.

Ukoliko sistem ne moţe da snimi podatke o CD-u prikazuje se odgovarajuća poruka.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 3. 117 . i scenario se prekida. Sistem Korisnik Kreiraj novi CD() NoviCD Snimi CD() Poruka o neuspelom snimanju DSK3 Dijagram sekvenci slučaja korišćenja –Aţuriranje CD-a Osnovni scenario: 1. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA). Korisnik poziva sistem da snimi unete podatke o CD-u(APSO) 2.1.

(IA) 118 . Sistem Korisnik SacuvajCD() Poruka o nemogucnosti snimanja DSK4 Dijagram sekvenci slučaja korišćenja –Brisanje CD-a Osnovni scenario: 1. i scenario se prekida. Sistem prikazuje poruku o uspešnosti izvršenja operacije.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik Sacuvaj CD() Poruka o uspesnom snimanju Alternativna scenarija Ukoliko sistem ne moţe da snimi podatke o CD-u prikazuje se odgovarajuća poruka.(APSO) 2. Korisnik poziva sistem da izbrise CD.

(APSO) 2.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik Obrisi CD() Poruka o uspesnom brisanju Alternativna scenarija Ukoliko sistem ne moţe da izbriše CD prikazuje se odgovarajuća poruka. Korisnik poziva sistem da izvrši pretragu. Sistem prikazuje korisniku podatke o članu dobijene pretragom koja je izvršena po njegovom rednom broju.(IA) 119 . i scenario se prekida. Sistem Korisnik ObrisiCD() Poruka o nemogucnosti brisanja DSK5 Dijagram sekvenci slučaja korišćenja –Pretaţivanje člana Osnovni scenario: 1.

Sistem prikazuje korisniku polja gde moţe uneti podatke o novom članu.1. Sistem Korisnik PretraziClana() Trazeni clan ne postoji DSK6 Dijagram sekvenci slučaja korišćenja –Kreiranje nove članske karte Osnovni scenario: 1. Korisnik poziva sistem da snimi podatke.(APSO) 4.(APSO) 2.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik PretraziClana() Pronadjen clan Alternativna scenarija: 1.Ukoliko član sa zadatim rednim brojem ne postoji sistem prikazuje na ekranu poruku da taj član ne psotoji i prekida se izvršenje scenarija. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA). 120 .(IA) 3. Korisnik poziva sistem da kreira novu člansku kartu.

121 . Ukoliko sistem ne moţe da kreira novou člansku kartu prikazuje se odgovarajuća poruka.1.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Korisnik KreirajClana() NoviClan SnimiClana() Poruka o uspesnom snimanju Alternativna scenarija: 1. i scenario se prekida.

i scenario se prekida. Sistem Korisnik KreirajClana() Poruka o uspesnom snimanju SnimiClana() Poruka o neuspesnom snimanju DSK7 Dijagram sekvenci slučaja korišćenja –Aţuriranje članske karte Osnovni scenario: 122 .1. Ukoliko sistem ne moţe da snimi podatke o članu prikazuje se odgovarajuća poruka.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik KreirajClana() Poruka o neuspelom kreiranju 3.

Sistem Korisnik SnimanjeIzmenjenogClana() Poruka o neuspesnom snimanju izmena 123 . Sistem Korisnik SnimanjeIzmenjenogClana() Poruka o uspesnoj izmeni Alternativna scenario: Ukoliko sistem ne moţe da snimi podatke o članu prikazuje se odgovarajuća poruka. Korisnik poziva sistem da snimi unete podatke o članu(APSO) 2. i scenario se prekida. Sistem prikazuje poruku o uspešnosti izvršenja operacije(IA).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 1.

(APSO) 2. Korisnik poziva sistem da izbrise tog člana.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad DSK8 Dijagram sekvenci slučaja korišćenja –Brisanje članske karte Osnovni scenario: 1. i scenario se prekida. Sistem Korisnik BrisanjeClana() Poruka o nemogucnosti brisanja 124 . Sistem prikazuje poruku o uspešnosti izvršenja operacije.(IA) Sistem Korisnik BrisanjeClana() Poruka o uspesnom brisanju Alternativna scenarija Ukoliko sistem ne moţe da izbriše člana prikazuje se odgovarajuća poruka.

Greska u sistemu.Korisnik poziva sistem da zapamti podatke o iznajmljivanju. 125 .1.Sistem prikazuje sve podatke o iznajmljenom CD-u.(IA) Sistem Korisnik SnimiIznajmljivanje() Poruka o uspesnom snimanju Alternativna scenarija: 2.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad DSK9 Dijagram sekvenci slučaja korišćenja –Iznajmljivanje CD-a Osnovni scenario: 1.(APSO) 2.

Veza sa SK: DSK2. UGOVOR UG2 : kreiraj CD Operacija : Kreiraj(CD):bool. Preduslovi: U slučaju da podaci nisu dobro unešeni sistem će prijaviti grešku .3 Ponašanje softverskog sistema – definisanje ugovora o sistemskim operacijama UGOVOR UG1 :pretraţi CD Operacija : Pretraţi(CD):bool. Veza sa SK: DSK1. Preduslovi: U slučaju da CD tog rednog broja ne postoji.5. Postuslovi: Nadjen CD.1. Preduslovi: U slučaju da podaci nisu dobro unešeni sistem će prijaviti grešku. Veza sa SK: DSK3. Postuslovi: Novi CD.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Sistem Korisnik SnimiIznajmljivanje() Poruka o gresci 4. UGOVOR UG3 : aţuriraj CD Operacija :Aţuriraj (CD):bool. Postuslovi: Promenjeni CD. 126 .sistem ga ne moţe naći .

Veza sa SK: DSK5. UGOVOR UG8 : obriši člana Operacija :Obriši (Član):bool. Preduslovi: U slučaju da podaci nisu dobro unešeni sistem će prijaviti grešku . Veza sa SK: DSK4. UGOVOR UG6 : kreiraj novog člana Operacija : Kreiraj(Član):bool. 127 . Preduslovi: U slučaju da podaci nisu dobro unešeni sistem će prijaviti grešku. UGOVOR UG5 :pretraţi člana Operacija : Pretraţi(Član):bool.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad UGOVOR UG4 : obriši CD Operacija :Obriši (CD):bool. Postuslovi: Novi clan.sistem ga ne moţe naći . Veza sa SK: DSK7. Veza sa SK: DSK6. Postuslovi: Promenjeni clan. Preduslovi: U slučaju da podaci nisu dobro unešeni sistem će prijaviti grešku. Preduslovi: U slučaju da clan tog rednog broja ne postoji. Postuslovi:Član uspešno izbrisan. Postuslovi: Nadjen clan. Veza sa SK: DSK8. Postuslovi:CD uspešno izbrisan. UGOVOR UG7 : aţuriraj člana Operacija :Aţuriraj (Član):bool. Preduslovi: U slučaju da podaci nisu dobro unešeni sistem će prijaviti grešku.

2.2 Struktura softverskog sistema – relacioni model Dolazimo do relacionog modela: clan (id. iznajmljivanje (id. ovde ćemo se zaustaviti sa projektovanjem rešenja i primenićemo okvir na dati relacioni model.1. Veza sa SK: DSK9. 4.5. S obzirom da okvir diktira arhitekturu sistema. Preduslovi: Postuslovi:CD uspešno iznajmljen. telefon). datumOd. idClan.datumDo).5. idCd. Slika 35 Pocetna forma okvira 128 .5. zanr).2. adresa.7 pri pokretanju okvira otvoriće se forma za kreiranje nove aplikacije koju ćemo popuniti konkretnim podacima.2 Primena okvira 4. i pritisnuti dugme „Snimi“ (slika 35). CD (id. naziv.1 Generisanje aplikacije preko okvira Kao što je opisano u poglavlju 4.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad UGOVOR UG9 : iznajmi CD Operacija :Iznajmi (CD):bool. 4. imeIPrezime.

Fiznajmljivanje). 129 .struktura foldera Ulaskom u folder KI (slika 37) vidimo da se u njemu nalaze klase skeleta korisničkog interfejsa. Slika 36 Skelet aplikacije . kao i nekoliko konkretnih klasa formi ( Fclan. FCD.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Na zadatoj lokaciji se formirala struktura foldera (slika 36) i prikazuje poruka o uspešnom izvršenju.

koji predstavlja Visual Studio Solution fajl.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 37 Korisnički interfejs .sln fajl.fajlovi Kada otvorimo OsnovaOkvira. otvara se Visual Studio. 130 . i svi projekti kreiranog rešenja (slika 38).

i da se u rešenju ne nalaze konkretne klase vezane za domenske klase i korisnički interfejs. Iako konkretne klase postoje u pomenutim folerima. Klikom na ikonicu „Show All Files“ pojavljuju se ikonice konkretnih klasa (slika 39). one nisu uključene u rešenje. i moguće ih je uključiti u projekat (opcija „Include In Project“). 131 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 38 Visual Studio .sloution Primećuje se da je kreiran samo skelet aplikacije.

132 . dobijamo celokupno rešenje koje je okvir generisao (slika 40).Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 39 Konkretne klase aplikacije Kada taj postupak ponovimo na projektima KKI i DK.

2.Run(new FPocetna()). putanju ka bazi podataka i putanju ka log fajlu u App. kojih u primeru nema). niti neki drugi način pristupa svim formama (osim za forme slabih objekata.cela aplikacija sa konkretnim klasama 4.5. Stoga je korisno kreirati formu preko koje ćemo pozivati ostale forme i podesiti je da se otvara pri startovanju aplikacije.2 Neophodne izmene aplikacije pre startovanja Treba napomenuti da okvir ne generiše meni.cs: Application. 133 .config fajlu.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 40 Visual Studio . promenom koda u fajlu Program. Zatim je neophodno podesiti tip brokera.solution .

2.txt" /> <!--moguci tipovi brokera: Access. bazaMySql --> <add name="bazaMySql" connectionString="DRIVER={MySQL ODBC 3.5. EventArgs e) { kki. pre pokretanja aplikacije. potrebno je skinuti komentar sa te linije koda: public virtual void FOpsta_Load(object sender. Kada se završi sa izmenama forme. Na narednim slikama (41-47) biće ilustrovana upotreba aplikacije.port=3306.FormLoad(this). i primena osnovnih operacija nad bazom podataka. 134 .3 Ilustracija dobijenih formi i crud operacije Startovaćemo aplikaciju.FormLoad(this). 4. i otvara se forma koju smo kreirali. MySql --> <add key="tip_brokera" value="MySql" /> </appSettings> <connectionStrings> <!--Nazivi konekcionog stringa: bazaSql. MsSql.database=CDklub." /> </connectionStrings> </configuration> Zbog problema sa nasleĎivanjem formi u Visual Stuio-u nije moguće videti formu u dizajn modu ukoliko sledeća linija koda u klasi Fopsta nije zakomentarisana: public virtual void FOpsta_Load(object sender. .51 Driver}. EventArgs e) { //kki. bazaOleDb..server=MMO..uid=proba.0" encoding="utf-8" ?> <configuration> <appSettings> <!--putanja do log fajla--> <add key="txt" value="C:\Log\log.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad <?xml version="1.

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 41 Pocetna forma Slika 42Kreiranje novog člana i njegovo snimanje u bazu 135 .

uspesno obrisan član 136 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 43 Brisanje člana Slika 44 Brisanje člana .

odabir datuma 137 .Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 45 Izmena podataka o članu (promena prezimena člana koji ima id 6) Slika 46 Kreiranje novog iznejmljivanja .

} Prekrivene metode: 138 . nije nam od posebnog značaja da vidimo spisak samo sa id-jevima clana i iznajmljenog CD-a. 1.2.5.Empty. ili moţemo kreirati nove klase/metode i integrisati ih u postojeći sistem. Daću 2 primera prekrivanja metode. ili izmeniti postojeće konkretne metode. Treba voditi računa da izmena generičkih klasa ili metoda povlači za sobom velike izmene celog sistema.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad Slika 47 Promena postojedeg iznajmljivanja .izmena CD-a 4. Primer Primećujemo da je lista iznajmljivanja dosta neintuitivna. Da bismo to izmenili potrebno je prekriti metodu DajSelectAll() iz klase DK.Iznajmlivanje.4 Izmene aplikacije Da bismo izmenili funkcionalnosti aplikacije moţemo prekriti generičke meode konkretnim metodama. Originalna metoda: public override string DajSelectAll() { return string.

Insert(odo). izn. } . return sb. koja nasleĎuje klasu Oso. izn..Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad public override string DajSelectAll() { StringBuilder sb = new StringBuilder()..datumDo from ").idCd=CD. sb. } . public bool Insert(Odo odo) { return oso.Append(" as izn inner join CD on izn. Primer – implementacija ţarišne tačke Zahtev: „Ukoliko je ime člana nije uneto.Append("select izn.izn.datumOd... izn.Append(NAZIV_TABELE). sb.naziv.. public Kal() { oso = new Oso().ToString().idCd.. Slika 48 Lista iznajmljenih CD-ova 2. clan.id").id inner join clan on izn. i prikazana je na slici 48..oso = oso. U klasi OsoClan ćemo prekriti metode za preduslove kod snimanja objekta u bazu. Originalne metode: public class Kal { Oso oso. CD.idClan=clan. } Lista iznajmljivanja je sada mnogo jasnija.idClan... Najpre je potrebno da kreiramo klasu OsoClan. } public Kal(Oso oso) { this.imeIPrezime. sb.id. ne treba dozvoliti upis člana u bazu“. } public class Oso 139 ..

.. što ćemo uraditi promenom konstruktora za Kal u klasi KKIClan: public KKIClan(Form f) { 140 .. } return true. } return true..ImeIPrezime == string. public virtual bool Insert(Odo odo) { if (ProveriPredusloveInsert(odo)) { bool rezultat = dac. if (c. true. } protected override bool ProveriPredusloveUpdate(Odo odo) { Clan c = (Clan)odo.ImeIPrezime==string.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad { . } else return false.. } } Sada je potrebno da pozovemo konkretnu klasu sistemske operacije.Empty) { return false.Insert(odo.. kada upisujemo člana.....Empty) { return false. protected virtual bool ProveriPredusloveInsert(Odo odo) { return true. if (!ProveriPostusloveInsert(rezultat)) { return false. } . } return rezultat. } protected virtual bool ProveriPredusloveUpdate(Odo odo) { return true. true). } Prekrivene metode: public class OsoClan:Oso { protected override bool ProveriPredusloveInsert(Odo odo) { Clan c = (Clan)odo. if (c.

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad kal = new Kal(new OsoClan()). } Na slici 49 je prikazana poruka koju aplikacija javlja u slučaju da korisnik pokuša da snimi člana bez imena i prezimena. 141 . form = f. clan = new Clan().2. kao što je u poglavlju i bilo projektovano.5. Što znači.5 Zaključak Kada je primer aplikacije kreiran preko okvira moţemo videti da su njegove sistemske operacije zaista realizovane. primenom okvira dobili smo projektovanu funkcionalnost aplikacije. Slika 49 Izmena člana 4.

2 i 2.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 5 Zaključak Pitanje na koje se rad fokusira je šta je okvir aplikacije i kako ga razviti. a koji se moţe prilagoditi za potrebe konkretne aplikacije.4 dat je pregled osobina okvira. odnosno skica aplikacije. do veoma konkretnih: “Okvir je skelet aplikacije. preko opisnih: „Klasa je za objekat isto ono što je okvir za aplikaciju. Osnovne osobine okvira su: [11]  Okvir je konkretan.“[5]. koji sadrţi kompletan kod osnovnih funkcija celog sistema. na početku istraţivanja. Ove osobine pomaţu boljem razumevanju okvira i njihovom logičkom razdvajanju od standardnih aplikacija. isto kao što je okvir prototip. Klasa je prototip. skica objekta.“ [2] U poglavljima 2. 142 . Na osnovu definisanog predmeta istraţivanja. čime je ustanovljeno da shvatanje okvira aplikacije nije jedinstveno. Definicije variraju od veoma uopštenih: „Okviri su generatori aplikacija odreĎenog domena“[17]. identifikovani su sledeći ciljevi istraţivanja:  Okvir aplikacije o Pregled različitih definicija okvira o Osobine okvira o Klasifikacija okvira o Pregled principa razvoja okvira o Prikaz uzora projektovanja okvira o Prikaz različitih načina dokumentovanja okvira  Razvoj okvira o Analiza domena o Projektovanje okvira o Implementacija okvira o Dokumentovanje okvira o Primena okvira na studijskom primeru U sklopu poglavlja „Okvir aplikacije“ dat je pregled različitih definicija okvira.

Različiti uzori projektovanja okvira i njihove osobine su dati u poglavlju 2. Okviri rešavaju vaţne probleme. ali pregled smernica za razvoj okvira po različitim autorima je dat u poglavlju 2."okviri bazirani na arhitekturi" Okvir crne kutije . fleksibilan. Okvir pomaţe u rešavanju problema koji se ponavljaju. proširiv i razumljiv. Okvir diktira rešenje.5.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad          Okvir je nekompletan. Različite klasifikacije okvira su opisane u poglavlju 2. Okvir vezuje pojedinačne komponente/objekte u korisnije celine.3. upotreba malog broja tipova komponenti iznova i iznova i pisanje što je manje moguće koda."okviri bazirani na podacima" Okvir sive kutije – okviri koju poseduju karakteristike i okvira bele i okvira crne kutije Ne postoji jedinstvena metodologije projektovanja okvira. Okviri pomaţu programerima da naĎu rešenja za domene problema i da lakše odrţavaju ta rešenja. okvir mora biti kompletiran. [30] Krajnji cilj u kreiranju okvira je da programer uopšte ne piše kod.6:         Uzor 3 primera Bela kutija Biblioteka komponenata Ţarišne tačke Prilagodljivi objekti Usitnjeni objekti Crna kutija Vizuelni bilder 143 .[30] Ciljevi izrade okvira bi trebalo da budu: izrada aplikacija od postojećih komponenti. Da bi uspeo. Okvir pojednostavljuje rad sa sloţenim tehnologijama. Jedna od najzastupljenijih klasifikacija je ona koja okvire deli na[29]:    Okvir bele kutije .

Korišćenjem uzora biblioteka klasa kreirana je biblioteka konkretnih komponenata okvira. i kao zaključak se navodi da ne postoji najbolji način dokumentovanja okvira.7. Konkretan okvir generiše skelet tronivojske aplikacije i da implementira CRUD operacije nad bazom podataka. Kako implementacija CRUD operacija zavisi od modela podataka aplikacije. Na bazi predstavljene teorije razvijen je sopstveni okvir za generisanje desktop aplikacija u C# programskom jeziku. Analizirane su komponenata tri aplikacije iz posmatranog domena. konkretna aplikacija tronivojske arhitekture (slika 50). kreirani su interfejsi i apstraktne klase aplikacije. za proizvoljan domen problema. već je najkorisnije primeniti nekoliko različitih modela dokumentovanja. Korišćenjem opšteg uzora. kako je već navedeno. a izlaz. ulaz u sistem će predstavljati meta model podataka aplikacije. RELACIONI MODEL PODATAKA OKVIR DESKTOP APLIKACIJA Slika 50 Konceptualni model okvira Za razvoj Oz okvira koristišćena je modifikovana Bošova metoda razvoja okvira:  Razvoj okvira: o Analiza domena o Projektovanje okvira o Implementacija okvira o Dokumentovanje okvira   Korišćenje okvira Evolucija i odrţavanje okvira U analizi domena je korišćen uzor tri primera za definisanje domena problema.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad  Alat programskog jezika Načini dokumentovanja okvira su predstavljeni u poglavlju 2. 144 .

Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad SOFTVERSKI SISTEM APLIKACIONA LOGIKA KORSNIČKI INTERFEJS KONTROLER POSLOVNA LOGIKA BROKER SKLADIŠTE PODATAKA Slika 51 Tronivojska arhitektura . a koje programer po ţelji moţe dalje da doraĎuje. dok druge ne zavise. a okvir koji je generiše zaista sadrţi skelet aplikacije. Promenljivi deo okvira predstavlja delove aplikacije koja zavise od specifične aplikacije i njenih podataka. odnosno od relacionog modela aplikacije. 145 . i kompletan kod osnovnih funkcija celog sistema. odnosno identifikovani su jezgro okvira i promenljivi delovi okvira (slika 53). Na osnovu relacionog modela kreiraju se konkretne komponente vezane za aplikaciju.komponente Na osnovu analize komponenata sistema (slika 51) utvrĎeno je da neke komponente sistema zavise od podataka. Jezgro okvira. Time se dobija desktop aplikacija kreirana na osnovu meta modela podataka koja podrţava osnovne operacije nad bazom podata. što predstavlja jednu od definicija okvira. koje prekrivaju kod pojedinih metoda opštih klasa. odnosno skelet aplikacije je pretstavljen na slici 52. koji se moţe prilagoditi za potrebe konkretne aplikacije [2].

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

KORISNIČKI INTERFEJS

SOFTVERSKI SISTEM

Korisnički interfejs
FOpsta KKIOpsti

Kontroler aplikativne logike
KAL

Oso

Sistemske operacije

Broker Kontroler korisničkog interfejsa
KKIOpstiSlab

DacOpstiMySql

DacHelperMySql

«interface» InterfaceForm

KKIHelper

Odo

«interface» IDAC

DacOpstiMSSql

DacHelperMSSql

FOpstaSlab

Domenske klase

DacOpstiPostqreSql

DacHelperPostgreSql

SKLADIŠTE PODATAKA

Slika 52 Skelet aplikacije
SKLADIŠTE PODATAKA
«interface» InterfaceForm

Korisnički interfejs

SOFTVERSKI SISTEM

FOpstaSlab

FOpsta

Broker

DacOpstiMySql

DacHelperMySql

FKonkretna1

FKonkretnaN

«interface» IDAC

DacOpstiMSSql

DacHelperMSSql

DacOpstiPostqreSql KKIKonkretan1 KKIKonkretanN

DacHelperPostgreSql

KKIOpsti

Kontroler aplikativne logike
KAL

OsoKonkretna1

OsoKonkretnaN

Oso KKIHelper

Kontroler korisničkog interfejsa
KKIOpstiSlab

Sistemske operacije

OdoKonkretna1

OdoKonkretnaN

Odo

Domenske klase

Slika 53 Promenljive i nepromenljive tačke okvira

146

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

U poglavlju 4.5 prikazano je instanciranje okvira, odnosno primena okvira na studijskom primeru. Detaljno je objašnjeno kreiranje aplikacije preko okvira, korišćenje aplikacije (slika 54) i prilagoĎavanje koda konkretnim potrebama aplikacije.

Slika 54 Studijski primer - izmena člana CD kluba

Dalji pravci istraţivanja odnosili bi se na doradu okvira:      Povećanje broja funkcionalnosti okvira – dodavanje novih šablona klasa u okvir Dodavanje konkretnih klasa u biblioteku klasa Kreiranje boljeg korisničkog interfejsa primenovm većeg broja kontrola (na primer CheckBox, RichTextBox...) Kreiranje web interfejsa Druge dorade u skladu sa zahtevima korisnika, nastale na osnovu iskustva sa radom sa prvom iteracijom razvijenog okvira.

147

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

6 Reference
1. Terry Quatrani: Vizuelno modelovanje Rational Rose 2002 i UML , CET, Beograd 2003 2. Dr Siniša Vlajić: Projektovanje programa (skripta) , FON, Beograd 2004 3. Gregory M. Kapfhammer, Mary Lou Soffa: A FAMILY OF TEST ADEQUACY CRITERIA
FOR

DATABASE-DRIVEN APPLICATIONS

http://www.cs.virginia.edu/~soffa/research/SE/p98-kapfhammer.pdf 4. Luca Cardelli: BAD ENGINEERING PROPERTIES OF OBJECT-ORIENTED LANGUAGES http://doc.cat-v.org/programming/bad_properties_of_OO 5. JONATHAN CROSSLAND' S TALKWARE: http://www.jonathancrossland.com/page/what-is-a-framework.aspx 6. Frank Budinsky, Marilyn Finnie, Patsy Yu, John Vlissides: AUTOMATIC CODE

GENERATION FROM DESIGN PATTERNS:
http://www.research.ibm.com/designpatterns/pubs/codegen.pdf 7. Craig Larman: http://www.craiglarman.com/ 8. Objects by Design: http://www.objectsbydesign.com 9. Enciklopedija: http://en.wikipedia.org/wiki/Object-oriented_design 10. Martin Fowler: http://www.martinfowler.com 11. Chetan Panchal: What is framework?, http://blog.newtonicaonline.com/2008/12/06/what-is-framework/ 12. Marc Clifton: What is a framework,
HTTP://WWW.CODEPROJECT.COM/KB/ARCHITECTURE/WHATISAF RAMEWORK.ASPX

13. Frank Budinsky, Marilyn Finnie, Patsy Yu, John Vlissides: AUTOMATIC CODE

GENERATION FROM DESIGN PATTERNS,
http://www.research.ibm.com/designpatterns/pubs/codegen.pdf 14. Debasish Ghosh: Gode Generation, Boilerplates and OO, http://debasishg.blogspot.com/2006/04/code-generation-boilerplates-andoo.html

148

VERSION.MDD. http://st-www.es/miembros/jmvara/pubs/ICMT2009.Schemas.org/crossroads/xrds7-4/frameworks.pdf High-Level Framework Reuse Interfaces using Aspects.ichnet.html 18.html 20. http://www.com/tt/articles/article. Vara.acm.htm 17. http://www.alunos.agiledata. Belen Vela.amatriain. http://portal.de/ObjectArchitects/orpatterns/ 24. Ralph Johnson: Evolving Frameworks. Carlos J. Andre L.ul. http://www.kybele. Marcus Eduardo Markiewicz.pt/~i26503/data/Publications_attach/Santos_EuroP 21.pdf 23.etsii. Santos. Leksikon pojmova.org/glossary.edu/users/droberts/evolve. Esperanza Marcos: Model transformation for object-relational database development. http://xavier.P. Juan M.PRELIMINARY. Belen Vela.OR DB.fc. Inc.objectarchitects. Vara.net/Thesis/html/node23. http://www. Objectmatter. 149 .html#BasicConcepts 25.org/citation. Patrik Nordwall: Improving Developer Productivity with Lightweight Domain Specific Modeling http://www.di.acm.theserverside.tss?l=LightweightModeling 16. Wolfgang Keller i drugi: Patterns for Object / Relational Mapping and Access Layers. Kai Koskimies: Modular Hot Spots: A Pattern Language for Developing LoP08.cs. Don Roberts.org/essays/mappingObjects. A Pattern Language for Developing Object-Oriented Frameworks. Scott Ambler: Mapping Objects to Relational Databases: O/R Mapping In Detail http://www. Juan M.urjc. Lucena: Object Oriented Framework Development. Xavier Amatriain: Framework.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad 15. http://www.cfm?id=1244222 22.html 19. Jose Maria Cavero.: Object Relational Mapping Strategies . Jose Maria Cavero.of.illinois. Esperanza Marcos: Supporting Model-Driven Development of Object-Relational Database Schemas: a Case Study.

com/vbsf/docs/maptool/ormapping. Douglas C.cs.html 33.Band.de/LNI/Proceedings/Proceedings48/GI. Fayad: Framework Integration: Problems. Nenad Aničić. SlaĎan Babarogić: Baze podataka. Causes.1. Mattsson.psu.psu.Net Framework.com/stuart_kent/archive/2004/06/14/155132. http://www. 150 .objectmatter. http://citeseerx.1.emis.19.msdn. Greg Butler. http://citeseerx.edu/viewdoc/summary?doi=10.35.tss?l=PragmaticGen 35. Vlad Romanenko: Object-Relational Mapping Techniques for . Stuart Kent: On Code Generation from models. E: How to Design Frameworks 30.wustl.html 26.com/tt/articles/article. http://subs. Johnson. Branislav Lazarević.theserverside.ist. Heinz Zullighoven: Frameworking. M. Stefan Roock. Pierre Denommee: Documenting framework. Henning Wolf.1. J. R.pdf 27.1.edu/viewdoc/summary?doi=10. Solutions 32. http://www. Anatoliy Doroshenko.8939 29.Razvoj sopstvenog okvira za generisanje desktop aplikacija Master rad http://www. Schmidt: Object-Oriented Application Frameworks. Beograd 2003. Swen Efftinge: The Pragmatic Code Generator Programmer . Zoran Marjanović.ist. Mohamed Fayad. http://blogs. M.48-6.aspx 34.edu/~schmidt/CACM-frameworks. FON. Taligent: Building Object-Oriented Frameworks 31.3972 28. Bosch.

Sign up to vote on this title
UsefulNot useful