marina ognjanovic razvoj sopstvenog okvira za generisanje desktop aplikacija

Univerzitet u Beogradu Fakultet Organizacionih Nauka

Razvoj sopstvenog okvira za generisanje desktop aplikacija

Master rad

Mentor: dr Sinia Vlaji, Kandidat: Marina Ognjanovi

Beograd Januar, 2010. Godine


Master rad

Univerzitet u Beogradu Fakultet Organizacionih Nauka


Master rad

Kandidat: Marina Ognjanovi

lanovi komisije: dr Sinia Vlaji, doc ____________________________________

Beograd Januar, 2010. Godine2


Master rad

Razvoj sopstvenog okvira za generisanje desktop aplikacijaApstrakt: Termin okvir (eng. framework) se veoma esto koristi u softverskom inenjerstvu, naroito kada se govori o projektovanju i implementaciji objektno-orijentisanog softvera. Najoptije, okvir se moe definisati kao generator aplikacija odreenog domena, ili konkretnije okvir predstavlja skelet aplikacije, koji sadri kompletan kod osnovnih funkcija celog sistema, a koji se moe prilagoditi za potrebe konkretne aplikacije. U ovom radu e biti prikazane definicije i osobine okvira, smernice i uzori projektovanja okvira, kao i naini 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 generie skelet aplikacije tronivojske arhitekture i implementira osnovne operacije nad bazom podataka (eng. CRUD) za definisani domen problema. Trei deo rada e sadrati studijski primer: generisanje desktop aplikacije preko sopstvenog okvira. U zakljuku e biti sumirane smernice za dalji razvoj sopstvenog okvira. Kljune rei: Okvir, desktop aplikacija, c#

3


Master rad

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

4


Master rad

SadrajSadraj ..................................................................................................................... 5 1 Uvod ..................................................................................................................... 9 2 Okvir aplikacije .................................................................................................... 122.1 Defninicije okvira ......................................................................................................................... 13 2.2 Osobine okvira ............................................................................................................................. 14 2.3 Klasifikacija okvira........................................................................................................................ 17 2.4 Znaajna pitanja pri razvoju okvira ............................................................................................... 18 2.4.1 Razvoj generatora aplikacija nasuprot razvoja aplikacije ........................................................ 19 2.4.2 Pitanja kompozicije (eng. composition issues) ....................................................................... 19 2.4.3 Problemi instanciranja i dokumentacije okvira ...................................................................... 20 2.4.4 Cena i iskustvo analize domena ............................................................................................. 21 2.4.5 Uporedno evoluiranje instanci i okvira .................................................................................. 21 2.4.6 Fleksibilnost naspram sloenosti i performansi ...................................................................... 22 2.4.7 Problemi otklanjanja greaka u instancama okvira................................................................. 23 2.5 Projektovanje okvira .................................................................................................................... 23 2.5.1 Razvoj OO okvira po Markijeviu i Luceni............................................................................... 24 2.5.2 Donsonov princip razvoja okvira .......................................................................................... 25 2.5.3 Boov princip razvoja okvira .................................................................................................. 26 2.5.4 Razvoj okvira po principima kompanije Ericsson Software Technology .................................. 28 2.5.5 Principi Ksavijera Amatriaina ................................................................................................. 29 2.6 Uzori projektovanja okvira ........................................................................................................... 29 2.6.1 Tri primera ............................................................................................................................ 30 2.6.2 Okviri bele kutije ................................................................................................................... 32 2.6.3 Biblioteka komponenata ....................................................................................................... 34 2.6.4 arine take ......................................................................................................................... 36 2.6.5 Prikljuni objekti (eng. Pluggable Objects) ............................................................................. 38 2.6.6 Usitnjeni objekti (eng. Fine-grained) ...................................................................................... 39 2.6.7 Okvir crne kutije .................................................................................................................... 40 2.6.8 Vizuelni bilder ....................................................................................................................... 42 2.6.9 Jeziki alati ............................................................................................................................ 43 5


Master rad

2.7 Dokumentovanje okvira ............................................................................................................... 44

3 Znaajni koncepti za razvoj sopstvenog okvira ....................................................... 483.1 Larmanova metoda razvoja softvera ............................................................................................ 48 3.2 Tronivojska arhitektura ................................................................................................................ 49 3.3 Relacioni model ........................................................................................................................... 51 3.4 Desktop aplikacija ........................................................................................................................ 52 3.5 Automatsko programiranje .......................................................................................................... 52

4 Razvoj okvira ....................................................................................................... 544.1 Analiza domena ........................................................................................................................... 55 4.1.1 Analiza komponenata sistema ............................................................................................... 57 4.1.2 Opis zahteva pomodu modela sluaja koridenja ................................................................... 76 4.1.3 Ponaanje softverskog sistema sistemski dijagram sekvenci ............................................... 78 4.1.4 Ponaanje softverskog sistema definisanje ugovora o sistemskim operacijama................... 82 4.1.5 Struktura softverskog sistema - konceptualni model ............................................................. 83 4.2 Projektovanje .............................................................................................................................. 83 4.2.1 Arhitektura softverskog sistema ............................................................................................ 83 4.2.2 Kontroler aplikativne logike................................................................................................... 84 4.2.3 Projektovanje strukture softverskog sistema (aplikaciona logika - poslovna logika - domenske klase) ............................................................................................................................................. 85 4.2.4 Projektovanje ponaanja softverskog sistema (aplikaciona logika - poslovna logika sistemske operacije) ...................................................................................................................................... 87 4.2.5 Projektovanje aplikacione logike database broker ............................................................ 101 4.2.6 Projektovanje skladita podataka ........................................................................................ 102 4.2.7 Projektovanje ekranskih formi............................................................................................. 103 4.2.8 Zakljuak ............................................................................................................................. 106 4.3 Implementacija okvira................................................................................................................ 108 4.4 Dokumentovanje okvira ............................................................................................................. 108 4.5 Koridenje okvira........................................................................................................................ 108 4.5.1 Analiza zahteva ................................................................................................................... 109 4.5.2 Primena okvira .................................................................................................................... 128

5 Zakljuak ........................................................................................................... 142 6 Reference .......................................................................................................... 1486


Master rad

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


Master rad

Slika 41 Pocetna forma ........................................................................................................................ 135 Slika 42Kreiranje novog lana i njegovo snimanje u bazu ..................................................................... 135 Slika 43 Brisanje lana ......................................................................................................................... 136 Slika 44 Brisanje lana - uspesno obrisan lan ...................................................................................... 136 Slika 45 Izmena podataka o lanu (promena prezimena lana koji ima id 6) ......................................... 137 Slika 46 Kreiranje novog iznejmljivanja - odabir datuma ...................................................................... 137 Slika 47 Promena postojedeg iznajmljivanja - izmena CD-a................................................................... 138 Slika 48 Lista iznajmljenih CD-ova ........................................................................................................ 139 Slika 49 Izmena lana........................................................................................................................... 141 Slika 50vKonceptualni model okvira..................................................................................................... 144 Slika 51 Tronivojska arhitektura - komponente .................................................................................... 145 Slika 52 Skelet aplikacije ...................................................................................................................... 146 Slika 53 arine i zamrznute take okvira ............................................................................................. 146 Slika 54 Studijski primer - izmena lana CD kluba ................................................................................. 147

Popis tabela

Tabela 1 Uzori projektovanja ................................................................................................................. 37 Tabela 2 Metoda KreirajEnable .............................................................................................................. 91 Tabela 3 Metoda KreirajKonstruktor ...................................................................................................... 92 Tabela 4 Metoda KreirajKonstruktorPK .................................................................................................. 96 Tabela 5 Metoda KreirajPolja................................................................................................................. 98 Tabela 6 Iseak metode KreirajGetSet ................................................................................................... 99

8


Master rad

1 UvodOd poetaka softverskog inenjerstva etrdesetih godina prolog veka do danas, razvoj softvera konstantno napreduje. iri se spektar namena aplikacija, raste njihova sloenost. Stalni ciljevi su poboljanje produktivnosti softverskih inenjera, i poveanje kvaliteta aplikacija za krajnjeg korisnika. U poetku razvoja kompjutera, programi su direktno zavisili od hardvera koji je bio ugraen. Razlikovao se hardver za poslovne i naune aplikacije. Sistemski softver je bio besplatan, i dobijao se uz raunar, jer je bez tog softvera raunar bio beskoristan. Raunari su se nalazili u mainskoj sali, a programeri su rezervisali vreme za pristup raunaru ili zaduivali operatere za konkretne zadatke. Ulaz u raunar su predstavljale buene kartice, a izlaz se ekao na tampau. Bilo kakvo planiranje i upravljanje razvojem softvera su bili skoro nemogui. Interesantno je napomenuti da su sve do 1960-ih godina programeri esto bile ene. Mukarci su bili na prestinijim i bolje plaenim poslovima bavili su se hardverom. Hardver se menjao jako brzo, i svakih godinu-dve posao programera je bio prevoenje programa na novije raunare. To je podstaklo razvoj softverskih jezika vieg nivoa: FORTRAN, COBOL i ALGOL. Neke kompanije su poele da nude uslugu razvoja custom softvera, ali jo uvek niko nije prodavao softverske pakete. Ve u to doba se pojavila ideja o ponovnoj upotrebi delova softvera, modularnom programiranju i apstrakciji podataka. Kako je softver bio besplatan, mnoge kompanije su dobrovoljno davale kataloge sa komponentama za ponovnu upotrebu (npr IBM-ova grupa SHARE). Termin softversko inenjerstvo se javlja 1950-1960. Dve konferencije o softverskom inenjerstvu u Nemakoj 1968 i 1969 se smatraju zvaninim poetkom profesije softverskog inenjerstva. Takozvana softverska kriza, od 1965-1985, identifikovala je mnoge probleme u razvoju softvera. Projekti su daleko premaivali budet i rokove, uzrokovali gubitak imovine (usled loe zatite softvera, hakeri su uspevali da ukradu informacije, novac...),

9


Master rad

i ak uzrokovali smrtne sluajeve (zbog greke u proraunavanju doze zraenjem umrla su barem 3 pacijenta).

u terapiji

Za softversku krizu je decenijama traen srebrni metak1, jednostavno i neposredno reenje. Svaki novi alat, disciplina, formalna metodologija, proglaavani su za srebrni metak: Alati strukturno programiranje, OOP, CASE alati, dokumentacija, standardi, UML... Disciplina neki su smatrali da je jedini problem u nedostatku discipline kod programera Formalne metode pokuaj da se primenom formalne inenjerske metodologije u softversko inenjerstvo, ono uini jednako predvidivim kao druge grane industrije. Profesionalizam rad na etici, licencama, profesionalizmu Postalo je jasno da maginog reenja nema, ali su svi navedeni alati i tehnike doveli do inkrementalnog poboljanja produktivnosti i kvaliteta. Softversko inenjerstvo je mlada disciplina i jo uvek se razvija. Trenutne tendencije u razvoju softvera su: Aspekti (eng. aspects) obezbeuju alate za dodavanje ili uklanjanje generikog koda. Agilno programiranje koje ukljuuje brz razvoj funkcionalnih jedinica softvera, iterativnost, manje dokumentacije, timski rad, saradnju sa klijentom, i prilagoavanje aplikacije tokom ivotnog ciklusa projekta. Eksperimentalno softversko inenjerstvo grana koja se bavi pravljenjem eksperimanata na softveru, prikupljanjem podataka iz eksperimenata i postavljanjem zakona i teorema na osnovu tih podataka. To je potpuno nauna metodologija. Razvoj voen modelom (eng. model-driven development) razvoj tekstualnih i grafikih alata koji koriste transformacije modela i generisanje koda da bi1

Po narodnom predanju srebrni metak je jedina vrsta metaka kojim se mogu ubiti vukodlaci i vetice. Uglavnom se koristi kao izraz za jednostavno i neposredno reenje.

10


Master rad

generisali dobro organizovane fragmente koda koji slue kao osnova za kreiranje aplikacije. Okviri takozvane proizvodne linije softvera sistematian nain da se proizvede familija softverskih sistema, umesto jednog individualnog proizvoda. Ovaj postupak zahteva dobro planiranu i razvijenu ponovnu upotrebu koda. U sutini, to je pokuaj industrijalizacije razvoja softverskog sistema.

11


Master rad

2 Okvir aplikacijeOkvir aplikacije (eng. application framework) je apstrakcija, u kojoj generiki kod za standardne funkcionalnosti moe selektivno da se prekrije korisnikim kodom ime e se dobiti specifine funkcionalnosti[9]. Drugim reima to je skelet aplikacije, koji sadri kompletan kod osnovnih funkcija celog sistema, a koji se moe prilagoditi za potrebe konkretne aplikacije[2]. Termin okvir se veoma esto koristi u softverskom inenjerstvu, naroito kada se govori o analizi i projektovanju objektno-orijentisanog softvera. Prvi objektnoorijentisani okviri koji su zaista smatrani za okvire bili su MVC (eng. Model View Controller) za Smalltalk i MacApp za Epl (eng. Apple) aplikacije. Drugi vani okviri iz ove poetne faze su bili ET++ i Interviews. Interesantno je primetiti da je veina prvobitnih okvira bila kreirana za projektovanje korisnikog interfejsa. U istoriji okvira takoe je vano spomenuti ime kompanije Talident (eng. Taligent), zajednikog poduhvata kompanija Epl, IBM i Hjulit-Pakard (eng. Hewlett-Packard). Oni su razvili grupu alata za ubrzan razvoj aplikacija pod nazivom Zajednika taka (eng. Common Point), koji se sastoji od vie od stotinu objektno-orijentisanih okvira. Okviri su slini softverskim bibliotekama, jer i jedni i drugi predstavljaju kod koji se moe ponovo koristiti upakovan u API (eng. application programming interface). Biblioteke slue za ponovnu upotrebu koda, ali ne podrazumevaju neku konkretnu strukturu aplikacije, ve samo obezbeuju funkcionalnosti pomou kojih aplikacija radi. Sa druge strane, okviri predstavljaju apstraktnu specifikaciju nekog tipa aplikacije. Ipak neke biblioteke se pomalo ponaaju kao okviri, a sa druge strane ima okvira koji se mogu koristiti kao biblioteke klasa. To se moe posmatrati kao kontinuum sa tradicionalnim bibliotekama na jednom i sofisticiranim okvirom na drugom kraju.[9] esto postavljano pitanje je da li korienje okvira sputava kreativnost programera? Na prvi pogled deluje da je tako, jer projektovanje softvera i dalje predstavlja spoj nauke i umetnosti! Meutim, ak i svaki kolovani umetnik koristi metodologiju koja mu omoguava da usmeri svoj kreativni rad u eljenom smeru. Dobro izabrana12


Master rad

metodologija zapravo oslobaa umetnika od brige oko osnova; konkretno programer moe da se posveti dizajniranju boljeg korisnikog interfejsa (funkcionalno i vizuelno), boljim performansama, itd.

2.1 Defninicije okvira

Ne postoji jedinstvena definicija okvira, i gotovo svako ko se bavio ovom granom softverskog inenjerstva dao je svoju definiciju okvira. Raznorodnost definicija nam pokazuje da nema slaganja oko toga ta je zapravo okvir aplikacije. Razliite definicije okvira: Okvir je biblioteka klasa koja sadri uzore interakcije izmeu objekata. Sastoji se od konkretnih i apstraknih klasa, specijalno kreiranih da se koriste zajedno. [9] Okvir je logika struktura koja klasifikuje i organizuje sloene informacije. [16] Okvir je skup kolaboracionih koncepata oblikovanih za jednostavnu ponovnu upotrebu. [27] Okvir je konkretno, ali nekompletno reenje za probleme velike vanosti koji se ponavljaju. [11] Okvir je apstrakcija u kojoj generiki funkcionalnosti. [9] Okvir je skelet aplikacije, koji sadri kompletan kod osnovnih funkcija celog sistema, a koji se moe prilagoditi za potrebe konkretne aplikacije. [2] Klasa je za objekat isto ono to je okvir za aplikaciju. Klasa je prototip, skica objekta, isto kao to je okvir prototip, odnosno skica aplikacije. [5] Okviri su generatori aplikacija odreenog domena. [17] kod za standardne funkcionalnosti

moe selektivno da se prekrije korisnikim kodom kojim e se dobiti specifine

13


Master rad

Definicija okvira po Donsonu i Futu (eng. Johnson i Foote): okvir je grupa klasa koja ini apstraktan dizajn za reenja familija problema. [18] Definicija okvira po Beku i Donsonu (eng. Beck and Johnson): okvir je projekat sistema ili dela sistema koji se moe upotrebljavati iznova (eng. reusable), izraen kroz grupu apstraktnih klasa i naina na koji one sarauju; okvir je grupa ugraenih blokova za izradu softvera koje programeri mogu da iskoriste, proire, ili prilagode za odreena softverska reenja. [18]

Okviri su aplikacije na visokom nivou apstrakcije koje se odnose na jedan odreen domen, a koje mogu biti prekrojene za individualnu primenu. [30] Definicija okvira po Bou (eng. Bosch): okvir je softverska arhitektura koja se moe iznova koristiti, a koja se sastoji i od dizajna i od koda. [18]

2.2 Osobine okvirata ini jedan okvir? [12] Omota (eng. wrapper) o Pojednostavljuje interfejs ka tehnologiji. o Smanjuje/eliminie ponavljajue zadatke. o Poveava fleksibilnost aplikacije korienjem apstrakcije. o esto se mogu ponovo koristiti bez obzira na projektantske odluke visokog nivoa. Arhitektura o Arhitektura predstavlja nain na koji se implementiraju i povezuju komponente sistema. Metodologija o Usmerava projektovanje, i ini ga konzistentim. o Dekupluje zavisnosti izmeu objekata. o esto se moe ponovo koristiti bez obzira na zahteve aplikacije. Osobine okvira su: [11]14


Master rad

1. Okvir je konkretan. Drugim reima, okvir se sastoji od fizikih komponenti, koje najee ine fajlovi, biblioteke, i slino (dll, cs, zip fajlovi). Uzori projektovanja nisu okvir ve korisne ideje koje programer po svom nahoenju realizuje u toku izvoenja projekta. Za razliku od toga okvir je jedna mogua realizacija. 2. Okvir je nekompletan. To nije gotovo reenje, ve ostavlja programeru konkretna mesta koja treba da popuni odgoovarajuim kodom. to je okvir sloeniji, to manje koda programer treba da napie, ali je sa druge strane tee nauiti kako koristiti okvir. 3. Okvir diktira reenje. Okvir odreuje arhitekturu sistema, delove koda koji su predvieni za prilagoavanje potrebama konkretne aplikacije, kao i nain na koji e se to uraditi. 4. Okvir pomae u reavanju problema koji se ponavljaju. 5. Okviri reavaju vane probleme. Iako je pojam vanosti relativan, treba imati na umu da se okviri prave za reavanje problema velike vanosti. Na primer: nema smisla praviti okvir za sabiranje dva broja (taj problem moemo reiti pravljenjem metode za sabiranje brojeva), ali moemo napraviti okvir za obezbeivanje perzistencije objekata. U emu nam okvir pomae? Pojednostavljuje rad sa sloenim tehnologijama. Vezuje pojedinane komponente/objekte u korisnije celine. Primorava tim da kod implementira konzistentno, ime se obino postie fleksibilnija aplikacija sa manje greaka. Kod je jednostavniji za odravanje (ak i onima koji ga nisu implementirali).

Osobine dobro isprojektovanih okvira: Uz okvire, programeri ne moraju da poinju od nule svaki put kada piu konkretnu aplikaciju. Okviri pomau programerima da nau reenja za domene problema i da lake odravaju ta reenja. Takoe obezbeuju dobro

15


Master rad

projektovanu infrastrukturu tako da kada se kreiraju i dodaju novi delovi, mogu biti integrisani uz minimalan uticaj na druge delove okvira. [18] Koliko god elegantan ili dobro projektovan okvir bio, on nee biti upotrebljen osim ako cena razumevanja i zatim korienja njegovih apstrakcija nije nia nego procenjena cena pisanja tih funkcionalnosti od nule, tj. bez upotrebe okvira. [18] Vano je shvatiti da softver ne moe biti iznova upotrebljavan ako se niti jednom ne upotrebi.[29] Da bi uspeo, okvir mora biti kompletiran, fleksibilan, proiriv i razumljiv.[30] Okvir bi takoe trebalo da nae naine da minimizira potencijalne greke programera i da proiri meuplatformsku prenosivost. [29] Okvire bi trebalo ilustrovati primerima, koji ih ine konkretnijim i lakim za razumevanje. [29] tavie, okvir je samo uoptavanje ve postojeih primera u okviru odreenog domena aplikacija. Okviri nameu model koji zahteva od programera da se prilagode. Sa druge strane, okviri poveavaju produktivnost programera.[18] Ciljevi izrade okvira bi trebalo da budu izrada aplikacija od postojeih komponenti, upotreba malog broja tipova komponenti iznova i iznova i pisanje to je manje mogue koda. [30] Krajnji cilj u kreiranju okvira je da programer uopte ne pie kod. I konano, okvir opisuje vrste objekata koji su vani u domenu i obezbeuje renik pomou kog se govori o problemu. Ekspert za odreeni okvir vidi svet kroz taj okvir i prirodno e ga podeliti na te iste komponente. Dva iskusna korisnika istog okvira e lake razumeti aplikacije onog drugog, jer e nalaziti sline komponente i opisivae sistem koji ele da naprave na sline naine.[29]

16


Master rad

2.3 Klasifikacija okviraOpta podela okvira[9]: Okviri za optu namenu, na primer: o Rails (Ruby) o Zend, CodeIgniter (PHP) o Spring, GWT (Java) o BFC (.Net) Konkretni okviri: o MFC (Microsoft Foundation Classes) okvir, o OMG (Object Management Group) o CORBA io

DCOM i COM+ (Microsoft).

Talident je razvio razliite naine klasifikovanja okvira. Jedna od njih je[30]: Konceptualni okvir pomae nam da identifikujemo bitne koncepte iz domena aplikacije (eng. application domain). On uobliuje nau viziju budueg sistema. Okvir projektovanja ili podrke pomae nam da transformiemo model domena aplikacije u projekat softverskog sistema. Uzori projektovanja i arhitekturalni stilovi mogu da pomognu pri projektovanju, mada sami po sebi nisu okvir. Takoe, ovi okviri nude horizontalne usluge na nivou sistema, kao to su pristup datotekama (eng. file) ili podrka distribuiranom informacionom sistemu. Aplikacioni okvir Aplikacioni okviri daju podrku razvoju jedne vrste softverske aplikacije ili dela aplikacije. Primer bi mogao da bude okvir za razvoj grafikog korisnikog interfejsa. Jo jedna Talidentova podela[30]:

17


Master rad

Okviri koji se zasnivaju na arhitekturi koriste nasleivanje i mogu biti komplikovani za upotrebu, jer programer mora da pie kod (apstraktne klase se prekrivaju konkretnim klasama).

Okviri koji se zasnivaju na podacima koriste polimorfizam, laki su za korienje, ali mogu biti previe ograniavajui.

Obino dobro dizajniran okvir ima jezgro koja se zasniva na arhitekturi i slojeve koji se zasnivaju na podacima. Najire prihvaena klasifikacija je verovatna ona koju je napravio Donson, a po kojoj okviri softvera mogu biti podeljeni na okvire bele, crne i sive kutije [29]. Okviri bele kutije, koji se nazivaju i okviri bazirani na arhitekturi, dozvoljavaju instanciranje samo kroz kreiranje novih klasa. Da bi se kreirala aplikacija preko okvira, mora se razumeti implementacija okvira. Kod okvira crne kutije instance se proizvode pomou konfiguracionih skripti. Na osnovu konfiguracije, alat za automatizaciju instanciranja kreira klase i izvorni kod. Na primer, moe se koristiti grafiki arobnjak (eng. wizard) koji vodi korisnika korak po korak kroz proces instanciranja okvira. Pristup crne kutije ne zahteva od korisnika okvira da poznaju detalje funkcionisanja okvira. Stoga se ovakvi okviri nazivaju i okviri bazirani na podacima i u optem sluaju se jednostavnije koriste. Okviri koji poseduju karakteristike i jednih i drugih se nazivaju okvirima sive kutije, i oni su najbrojniji.

2.4 Znaajna pitanja pri razvoju okviraIako je razvoj pomou okvira u osnovi izuzetno efikasan, postoji vie stavki koje bi trebalo prodiskutovati. U daljim odeljcima emo razmotriti sedam taaka na koje se mora obratiti panja kada se bira model okvira. Neophodno je napomenuti da ove take same po sebi nisu ni prednosti ni mane. U svakom sluaju treba imati na umu da je razvoj pomou objektno-orijentisanih okvira relativno nov pristup. Takoe se moramo setiti da su i prakse objektno-orijentisanog projektovanja i implementacije isto tako relativno nove.

18


Master rad

Procena tehnologije okvira koja e biti predstavljena ovde se bazira na opservacijama razliitih autora po pitanju razvoja i instanciranja vie razliitih okvira.

2.4.1 Razvoj generatora aplikacija nasuprot razvoja aplikacije Neophodno je biti svestan odnosa uloenog rada i dobiti kada se bira izrada okvira umesto izrade posebnog softverskog sistema. Vano je imati na umu da e razvoj okvira kotati barem koliko i razvoj jedne pojedinane aplikacije, a verovatno i mnogo vie. S druge strane, razvoj okvira se moe sam od sebe isplatiti kroz generisanje vie aplikacija preko okvira, kada okvir postane funkcionalan. Postavlja se pitanje da li emo kreirati aplikacije ovakvog domena jo koji put. ak i ako hoemo, moe se desiti da je isplativije kreirati pojedinane aplikacije, a ne okvir za njihov razvoj. Pri izboru se mnogo ee nego to bi to eleli nalazimo u nedoumici. Uvek je dobra ideja proveriti kako su slini sistemi ostvarili zahteve klijenata. Moda se ak ispostavi da je svaki od tih slinih sistema instanca naeg okvira, ali se i dalje postavlja pitanje da li je kreiranje tog okvira vredno truda.

2.4.2 Pitanja kompozicije (eng. composition issues) Integrisanje okvira da bi se ispunili zahtevi aplikacije nije neuobiajeno. Majkl Metson (Michael Mattson) smatra da postoji bar est zajednikih problema na koje se nailazi u razvoju aplikacija i okvira kada se pokuava integracija dva ili vie okvira. Svi ovi problemi proistiu iz grupe od pet optih sluajeva: kohezivno ponaanje, pokrivenost domena, namere u projektovanju, nemogunost pristupa izvornom kodu i nedostatak standarda za okvir. Kada razvijamo okvir i oekujemo da ga neko koristi, integracija okvira je neizbena realnost. Ova pitanja kompozicije se ne smeju shvatiti olako. Okviri se esto naputaju ili se od njih odustaje jer ne postoji mogunost da se lako integriu sa drugim19


Master rad

okvirima. Integracija okvira nije jednostavan posao, pa se kompozicija mora ozbiljno razmotriti u toku razvoja. Jedan od naina na koji se razmatra kompozicija pri razvoju okvira je da se postavi skup API-ja koji uauruju servise koje okvir obezbeuje. Meutim, ako je u pitanju kompozicija mnogo okvira, ovaj pristup je dosta skup ako se ne postavi unificirano posredovanje izmeu komponenata kompozicije. U tom sluaju, posredniki sloj e funkcionisati kao "lepak" izmeu elemenata kompozicije.

2.4.3 Problemi instanciranja i dokumentacije okvira Okviri bele, crne i sive kutije imaju strmu krivu uenja. Mogunost da se korienjem okvira napravi konkretan softverski sistem zavisi od upotrebljivosti mehanizama za korienje okvira i od dokumentacije okvira. Ako je okvir loe dokumentovan, mali broj ljudi e ga koristiti ili odravati. Trebalo bi da postoji dokumentacija za korienje okvira, kao i za proirivanje okvira, ukoliko se radi o softveru sa otvorenim kodom. Mnoge smernice za pravljenje dokumentacije su predloene za okvire. Pristup koji se bazira na karticama arinih taaka (eng. Hot spots, detaljnije e biti objanjene u poglavlju 2.6.4) stavlja fokus na fleksibilne take okvira. Drugi pristup je pravljenje "kuvara" koji opisuju kako bi trebalo primeniti okvir i koji su za to neophodni koraci. Ovakvi kuvari sadre veliki broj "recepata" koji neformalno opisuju kako reiti specifine probleme u procesu instanciranja okvira. Trei pristup je preslikavanje arhitekturalnih reenja koja se koriste u projektovanju okvira. Jedan od pristupa je navoenje uzora projektovanja, koji mogu da pomognu razumevanju procesa instanciranja. Iako postoji mnogo razliitih moguih pristupa dokumentovanju okvira, ne postoji jasan standard. Najsigurniji pristup je korienje dva ili vie od pomenutih pristupa. Detaljnije o dokumentovanju okvira bie razmatrano u poglavlju 2.7.

20


Master rad

2.4.4 Cena i iskustvo analize domena Kako je ve ranije navedeno, okviri se koriste da generiu aplikacije za jedan unapred odreen domen. U tu svrhu, jedna od faza razvoja je analiza domena. Za razliku od faze izrade liste zahteva za softverski sistem, analiza domena pokriva celu jednu klasu problema. Zadatak analize domena je da sagleda veliinu i sloenost izabranog domena. Ako je domen prevelik, gubljenje je vremena da se prikupe i ocene informacije i resursi. U tom sluaju, vreme razvoja i cena izrade okvira e biti preveliki. Povrh toga, bie neophodno uposliti osobe upoznate sa domenom, praviti prototipove ili analizirati sline softverske sisteme. Pronalaenje izvora iskustva u tako komplikovano. Sa druge strane, ako je odabrani domen previe suen, primenjivost okvira je umanjena, a kreirane aplikacije e biti suvie sline da opravdaju trud uloen u izradu okvira. Vano je imati na umu koje arine take e biti potrebne ili neophodne s obzirom na zahteve, a koje e biti nepotrebne ili suvine. 2.4.5 Uporedno evoluiranje instanci i okvira Kako vreme prolazi i okvir sazreva, menja se i evoluira u skladu sa zahtevima. Ovaj proces mogu predstavljati izmene u arhitekturi, reavanje novih zahteva i mnogi drugi izvori promene. U meuvremenu, aplikacije kreirane korienjem tog okvira e takoe evoluirati i menjati se. 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. Nema jasnog reenja, i veina ljudi e verovatno patiti od "nije nae" sindroma, odbijajui da koriste bilo koji okvir koji nisu sami pravili. Jedini mogu savet u takvoj situaciji je da se paljivo razmotri okvir koji e biti korien; dobro projektovan i implementiran okvir nee biti tako nestabilan kao lo okvir. irokom domenu je

21


Master rad

Pod "dobro dizajniran" podrazumeva se da bi okvir trebalo da ima dobru dokumentaciju i pri tome odgovara potrebama domena problema. Okvir koji odrava koncept objektno-orijentisanog uaurenja i ima dobro definisan javni interfejs e verovatno ostati kompatibilan sa buduim verzijama na nivou interfejsa kroz sve nadgradnje i revizije. Procena dizajna i/ili implementabilnosti okvira nije uvek jednostavna; mora se razmotriti iskustvo dizajnera, sloenost procesa instanciranja, koji su zahtevi ispunjeni a koji ne, i nain na koji e se vriti auriranja okvira. Nain auriranja okvira sadri planove za auriranje okvira, bilo sloenog redizajna kod svake nove verzije ili laganog auriranja kompatibilnog sa starim verzijama

2.4.6 Fleksibilnost naspram sloenosti i performansi Kako je ve navedeno, okviri se prave da budu fleksibilni i opti, u pokuaju da se pokriju iri domen umesto konkretnih problema. Ovaj pristup proizvodi generator aplikacije koji je sloeniji i proiriviji od klasinih softverskih sistema. Proirivost se postie korienjem nasleivanja i dinamikog povezivanja, zajednikih osobina objektno-orijentisanih jezika. Iz tog razloga, postoje kompromisi na utrb performansi, a zarad fleksibilnosti, jer dinamiko povezivanje uvodi redundansu (eng. overhead) ije e korienje u sistemu umanjiti performanse. Korienje arinih taaka poveava sloenost okvira. Ako ne postoje zahtevi za "dodatnim" arinim takama, vea sloenost nee pomoi u smislu funkcionalnosti. Vano je primetiti da je uobiajeno da programeri uvode neodgovarajue arine take mislei da e time okvir biti "moniji". Meutim, ovaj pristup vodi ka poveanju sloenosti i problemima sa performansama, kako je gore prikazano, i ponekad ta dodatna funkcionalnost moe biti nezgodan dodatak. Ovakav kompromis ini neophodnim paljiv izbor arinih taaka, gde kreator okvira ne sme ni previe konkretizovati ni previe generalizovati okvir. Iako je

22


Master rad

fleksibilnost vana i korisna, trebalo bi da postoji samo tamo gde je neophodna, inae se moe desiti da bude kreiran gigantski okvir za jednu upotrebu.

2.4.7 Problemi otklanjanja greaka u instancama okvira Kada se aplikacija generie preko okvira uobiajeno je da se kod okvira izmea sa konkretnim kodom vezanim za aplikaciju. Posledica toga je da se pri otklanjanju greaka aplikacije doe do koda samog okvira. Jedno od moguih reenja koje olakava otklanjanje greaka je odvajanje zamrznutih i arinih taaka okvira i upotreba preduslova i postuslova u svakoj metodi koda zamrznutih taaka, koji e se koristiti kao potvrda da su pozivi tim metodama validni. Takoe, potvrde izvrenja e obavestiti o bilo kom pogrenom ulazu ili povratnoj informaciji prosleenim kdu zamrznutih taaka, pa e praenje i otklanjanje greaka biti mnogo lake. Meutim, ovo reenje ne obuhvata sloenost koju uvodi meavina koda arinih i zamrznutih taaka. Preplitanje arinih i zamrznutih taaka uinie korienje okvira teim, jer korisnici okvira (programeri) moraju paljivo da menjaju postojei i uvode novi kod, da ne bi grekom promenili kod zamrznutih taaka, koji ne sme biti promenjen. Cena odravanja ovako konfuznog koda je neizbeno visoka.

2.5 Projektovanje okviraObjektno-orjentisani okviri su kamen temeljac modernog softverskog

inenjerstva. Razvoj okvira ubrzano biva prihvatan svuda zahvaljujui mogunosti ponovne upotrebe izvornog koda. Okviri su generatori aplikacija koji su direktno vezani za specifian domen problema, tj. familiju srodnih problema. Shodno tome, moraju postojati take fleksibilnosti okvira koje mogu biti prilagoene za potrebe konkretne aplikacije. Take fleksibilnosti okvira se nazivaju arine take. arine take su apstraktne klase ili metode koje moraju biti implementirane [17]. Okviri su nekompletni, i kao takvi23


Master rad

ne mogu se izvravati. Da bi se generisao izvrni kod, zapravo konkretna aplikacija, mora se implementirati kod vezan za aplikaciju (eng. application specific) za svaku od arinih taaka. Neke osobine okvira se ne mogu iskljuiti po potrebi i ne mogu se jednostavno izmeniti. Take na kojima nije mogue vriti izmene ine jezgro okvira, koje se esto naziva zamrznute take okvira (eng. frozen spots). Zamrznute take, za razliku od arinih taaka, su delovi koda koji su ve implementirani unutar okvira i koje pozivaju jednu ili vie arinih taaka koje je implementator kreirao. Jezgro je uvek konstantan i sveprisutan deo svake instance okvira.[17]

2.5.1 Razvoj OO okvira po Markijeviu i Luceni Tri glavna stadijuma razvoja svakog okvira su[17]: analiza domena, projektovanje okvira instanciranje (korienje) okvira.

Analizom domena se pokuavaju otkriti zahtevi u pogledu domena i potencijalni zahtevi u budunosti. Da bi obuhvatili ove zahteve, uzimaju se u obzir prethodno objavljena iskustva, postojei softverski sistemi sline namene, lina iskustva i standardi. Tokom analize domena, definie se jedan deo arinih i zamrznutih taaka. Stadijum razvoja okvira definie apstrakcije okvira. Modeliraju se arita i zamrznute take (recimo korienjem UML dijagrama), a takoe se uokviruje proirivost i fleksibilnost predloena u analizi domena. Kako je ve napomenuto, u ovom stadijumu se koriste paterni projektovanja. U finalnom, stadijumu instanciranja, implementiraju se arita, ime se generie softverski sistem. Vano je napomenuti da e svaka od ovih aplikacija imati zajednike zamrznute take okvira. Na slici 1 stadijumi procesa razvoja okvira se porede sa fazama klasinog objektno-orijentisanog programiranja.24


Master rad

Analiza domena

Projektovanje reenja

Implementacija

Aplikacija

Tradicionalni razvoj objektno-orijentisanog softvera

Analiza domena

Projektovanje okvira

Razvoj okvira

Aplikacija 1

Aplikacija 2

Aplikacija n

Korienje okvira

Slika 1 Razvoj okvira nasuprot razvoju aplikacije [17]

Kako vidimo sa slike 1, klasian razvoj objektno-orijentisanog softvera se razlikuje od razvoja okvira. Kod objektno-orijentisanog programiranja, faza analize problema slui za prouavanje zahteva samo jednog problema. Sa druge strane, analiza domena okvira obuhvata zahteve za itav domen problema. Kao konaan rezultat klasinog objektnoorijentisanog razvoja dobija se izvrna aplikacija, dok se primenom okvira dobija vie izvrnih aplikacija.

2.5.2 Donsonov princip razvoja okvira

Donson objanjava razliku izmeu "idealnog" i "dobrog" naina za razvoj okvira i softvera uopte. [29]

25


Master rad

Idealan nain se sastoji od tri osnovne faze razvoja. Prvo se analizira domen problema, definiui apstrakcije i prikupljajui primere programa koji bi trebalo da budu izraeni. Zatim se projektuju apstrakcije koje mogu biti specijalizovane tako da pokriju sve primere i izvedu teoriju kako bi objasnili ove primene. Na kraju se okvir testira tako to se koristi da rei konkretne probleme. Ovaj idealni put je nemogue ispratiti detaljno iz dva razloga veoma je komplikovano i gubljenje je vremena izvriti detaljnu analizu domena, analizirajui sve mogue postojee primere; stare aplikacije rade dobro, pa ne postoji finansijski povod da se konvertuju da koriste novi softver. Tako da je iako-ne-idealan-ali-dobar nain razvoja okvira da se prvo izaberu dve aplikacije u domenu koje bi trebalo da budu kreirane preko okvira; uveriti se da postoji bar nekoliko programera u timu koji su ve razvijali aplikacije za taj domen; podeliti projekat u tri grupe grupu za razvoj okvira koja kreira okvir, analizira kako e druge aplikacije moi da upotrebe okvir i pravi dokumentaciju i sistem obuke dve grupe za razvoj aplikacija koje pokuavaju da upotrebe okvir i stavljaju primedbe po pitanju toga koliko ga je teko ponovno upotrebiti.

2.5.3 Boov princip razvoja okvira

Bo [18] daje malo drugaiji pregled procesa razvoja okvira. Prvo razdvaja dve razliite aktivnosti u razvoju okvira: razvoj jezgra okvira interne dopune okvira.

26


Master rad

Razvoj jezgra okvira se sastoji i od apstraktnih i od konkretnih klasa u domenu. Namena konkretnih klasa je da budu nevidljive i transparentne krajnjem korisniku (npr. osnovni alat za skladitenje), dok je namena apstraktnih klasa ili da budu nevidljive ili da budu upotrebljene kroz podklase. Sa druge strane, interne dopune okvira prave dodatne klase koje formiraju odreeni broj biblioteka klasa. Oni obuhvataju uobiajene implementacije jezgra okvira i mogu biti ili podklase koje predstavljaju uobiajene upotrebe koncepata obuhvaenih nadklasama ili kolekcija klasa koja predstavlja specifikaciju za kompletno instanciranje okvira u konkretnom kontekstu. Konana aplikacija kreirana iz okvira sastoji se od elemenata jezgra okvira, internih dopuna okvira i "dopuna vezanih za aplikaciju". U ovom modelu, glavne faze razvoja su: 1. faza razvoja okvira, koja je uobiajeno ona koja zahteva najvie truda i iji je cilj pravljenje dizajna koji se moe ponovo upotrebiti u okviru odreenog domena a. analiza domena, b. projektovanje arhitekture, c. projektovanje okvira, d. implementacija okvira, e. testiranje okvira 2. faza upotrebe ili instanciranja gde se razvijaju aplikacije; 3. faza evoluiranja i odravanja okvira. U fazi razvoja okvira, pri odreivanju irine domena, postoji problem izbora valjane veliine: ako je okvir preirok, bie potrebno mnogo strunjaka u timu i proces bi mogao da postane dug i skup; ako je okvir suvie uzak verovatno e morati da se prilagodi svakoj novoj primeni koja iskrsne. S obzirom da se okvir moe upotrebiti na mnogo, esto nepredvienih naina, jednostavno nije izvodljivo testirati sve aspekte okvira. Poto se okvir zasniva na delovima koje implementira korisnik, praktino je nemogue testirati ga u potpunosti pre putanja u upotrebu. U fazi upotrebe okvira dolazi se do vanog pitanja. Ako se pojavi greka u okviru u toku razvoja aplikacije: ko e ispraviti greku u okviru i da li bi aplikacije koje rade i na koje ne utie ta greka trebalo da se nadograde na poslednju verziju okvira?27


Master rad

2.5.4 Razvoj okvira po principima kompanije Ericsson Software Technology Takoe je interesantno baciti pogled na to kako kompanija kao to je Swiss Ericsson modelira proces razvoja okvira. Pri projektovanju okvira trebalo bi obezbediti listu zahteva za bar dve aplikacije, kao i lista zahteva za okvir. Takoe bi trebalo predvideti listu buduih zahteva za 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. Informacije bi trebalo prikupiti iz to je mogue vie izvora. Zahtevi i sluajevi korienja (eng. use cases) bi trebalo da budu podeljeni na one vezane za okvir i one vezane za aplikaciju i takoe bi trebalo da budu podeljeni na funkcionalne i nefunkcionalne. Apstrakcije visokog nivoa bi takoe trebalo da budu identifikovane, kao priprema za identifikovanje okvira. Meutim, samo apstrakcije koje pripadaju domenu okvira bi trebalo uvesti u okvir, a ostale zanemariti. Trebalo bi ispitati postojea reenja, a velike okvire struktuirati kroz pod-okvire. Isto tako bi trebalo razviti statini model za svaku od aplikacija, uvodei apstrakcije zajednike za vie aplikacija u okvir. Koristei grafiku prezentaciju, trebalo bi projekat jasno prezentovati svim uesnicima projekta. Podsistemi bi trebalo da imaju jaku koheziju i slabo kuplovanje. I, na kraju, trebalo bi istraiti postojee okvire u pokuaju da se iskoristi to je vie dizajna mogue. U skladu sa prethodno pomenutm Talidentom, proces razvoja okvira mora pratiti etiri vane smernice koje bi mogle da budu shvaene kao sumiranje prethodne liste[30]: Praviti okvire iz postojeih problema i reenja Razvijati male, fokusirane okvire. Razvijati okvire iterativnim putem, uz uee klijenta i korienje prototipova. Tretirati okvire kao kompletne proizvode time to e biti obezbeena potpuna dokumentacija i podrka, i time to e biti planirana distribucija i odravanje.

28


Master rad

2.5.5 Principi Ksavijera Amatriaina

Ksavijer Amatrianin[18] veruje da je klasini "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 oigledno je da mora biti izvrena neka poetna analiza domena, kako bi se shvatili osnovni zahtevi i razliite take gledita koje prezentuju razliite interesne strane. Meutim, cilj ne moe biti razumevanje i modeliranje celog domena od poetka, ve je vano upamtiti da pri izradi okvira mi ne samo da implementiramo infrastrukturu za postojee aplikacije, ve mislimo i na budui razvoj domena. Amatrianin veruje u pristup izrade okvira voen aplikacijom kakav je prezentovao Donson 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 zapoinjanja projektovanja okvira, nego je okvir taj koji na kraju generie odgovarajui metamodel domena.

2.6 Uzori projektovanja okviraSoftverski uzori predstavljaju opta reenja koja se mogu iznova koristiti za uobiajene probleme u razvoju softvera. To nisu gotova reenja koja se mogu direktno prevesti u kod, ve opisi ili eme koji pomau za reavanje problema u razliitim kontekstima problema [9]. Uzori se takoe definiu kao trodelna pravila koja uspostavljaju relaciju izmeu nekog problema, njegovog reenja i njihovog konteksta [2]. U ovom poglavlju e biti dat pregled uzora koji su identifikovani kao znaajni pri razvoju okvira, uglavnom u fazama analize domena i projektovanja okvira [18][19].

29


Master rad

2.6.1 Tri primera Kontekst Odlueno je da se pravi okvir za odreen domen problema Problem Kako zapoeti projektovanje okvira? Sile (Forces) Apstrakcije nastaju generalizacijom konkretnih primera. Gotovo svaki pokuaj odreivanja ispravne apstrakcije na papiru, bez praktine primene, je osuen na neuspeh. Niko nije toliko pametan. S obzirom da je okvir projekat koji moe da bude upotrebljen vie puta, logino je razvijati ga iz stvari iji bi projekat trebalo da bude. to se vie primera uzme u obzir, to e okvir biti generikiji, meutim: Analiziranje aplikacija je komplikovano. Ne sme biti previe primera ili okvir nikada nee biti zavren. Upotreba okvira olakava razvoj aplikacija, ak i kada je okvir komplikovan za upotrebu. Kada se jednom zavri prva verzija okvira, pravljenje jo primera e biti lake. Projekti za koje treba mnogo vremena da se doe do neeg konkretnog imaju tendenciju da budu otkazani. Obino postoji samo kratka trina prilika koja se mora ispotovati. Ako projekat ne pone da generie prilive u nekom trenutku, organizacija e naii na probleme sa protokom novca. Klima u kompaniji se menja, i sistem mora biti izgraen pre nego to se njegovi nosioci prebace na druge projekte ili u druge kompanije. Reenje Razviti tri aplikacije za koje verujete da e vam okvir pomoi da ih napravite. Ove aplikacije bi trebalo da same isplate razvoj okvira.

30


Master rad

Argumentacija Okvir koji moe biti vie puta upotrebljen ne moe se razviti povrnom analizom domena problema. Vrlo je teko postaviti ispravne apstrakcije. Eksperti u domenu nee razumeti kako treba postaviti apstrakcije koje intuitivno razumeju, dok programeri nee razumeti domen dovoljno dobro da izvedu apstrakcije. tavie, esto postoje apstrakcije koje se ne pokazuju sve dok ne doe do korienja okvira. esto ove "skrivene" apstrakcije nemaju fizike analoge (npr. objekti strategije). Mogunost generalizacije za odreenu vrstu aplikacije moe doi jedino iz projektovanja vie aplikacija i odreivanja 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 teko. Opte pravilo bi glasilo: napraviti aplikaciju, zatim napraviti drugu aplikaciju koja se malo razlikuje od prve, i na kraju napraviti treu aplikaciju koja se jo vie razlikuje od prve dve. S obzirom da sve tri aplikacije potpadaju pod domen problema, zajednike apstrakcije e postati oite. Okvir nee biti gotov posle ove tri aplikacije. Oekivano je da on nastavi da evoluira. Mogao bi ak da bude koristan i za prikupljanje jo vie primera. Meutim, ne treba imati previe 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 omoguava timu da pone da koristi uoene apstrakcije odmah, ak i po cenu suavanja domena. Po drugom pristupu, aplikacije se razvijaju paralelnom od strane odvojenih timova. Ovaj pristup omoguava diverzifikaciju i razliita gledita na utrb vremena koje e biti potrebno da se ove aplikacije unificiraju u budunosti. U sluajevima kada je programer izradio odreeni tip aplikacije mnogo puta, postoji mogunost 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 odluio da zapone okvir.

31


Master rad

Implementacija Najoigledniji nain primene ovog paterna je jednostavno pravljenje tri aplikacije u nizu. Meutim, ponekada se prave serije aplikacija bez pokuaja da se iskoristi bilo ta od koda iz prethodnih, i odjednom se shvati da bi trebalo da se isprojektuje okvir. Poto su ve razvijene te prve tri aplikacije, esto je mogue napraviti dobar okvir. Drugi nain primene ovog paterna je pravljenje prototipova za vie aplikacija bez kreiranja konanih verzija aplikacija. Kod e verovatno morati da se refaktorie kada se bude upotrebljavao, ali e na ovaj nain okvir biti mnogo blie finalnom nego da je razvijana samo jedna aplikacija. Jedna od prednosti ovog pristupa je da se moe rei klijentima da kupuju smo pravo na korienje okvira, a ne kompletna prava vlasnitva aplikacije. Iako e aplikacija iziskivati izmene okvira, prava vlasnitva e ostati na programeru. Kada se pravi vie aplikacija, esto je teko dobiti prava da se iskoristi kod pisan za jednu aplikaciju u drugoj aplikaciji. Treba obratiti panju na injenicu da nema potrebe za nekim specijalnim tehnikama objektno orijentisanog projektovanja kada se kreiraju ove aplikacije. Treba koristiti samo uobiajene tehnike, trudei se da kreirani sistem bude fleksibilan i proiriv. Slini paterni Ovo je specijalan primer "Pravila trojke". Poetna verzija okvira e verovatno biti okvir bele kutije. 2.6.2 Okviri bele kutije Kontekst Zapoeto je projektovanje druge aplikacije Problem Neki okviri se jako mnogo zasnivaju na nasleivanju, drugi na polimorfnoj kompoziciji. ta treba koristiti?

32


Master rad

Sile Nasleivanje ima za rezultat jako kuplovanje izmeu komponenata, ali dozvoljava modifikacija komponenata koje se ponovno koriste, tako da se mogu promeniti stvari za koje prvobitni projektant nije ni pomislio da bi mogle biti promenjene. Reenje Koristiti nasleivanje. Napraviti okvir bele kutije generalizacijom klasa individualnih aplikacija. Koristiti paterne kao to su Template Method i Factory Method da bi se poveala koliina upotrebljenog koda u nadklasama iz kojih se nasleuje. Ne treba brinuti ako aplikacije nemaju nijednu zajedniku konkretnu klasu, mada e ih verovatno imati. Argumentacija Nasleivanje je najbri nain omoguavanja korisniku da menja kod u objektoorijentisanom okruenju jer ga podravaju skoro svi objektno orijentisani jezici. Ovo omoguava kreiranje klasa prostim nasleivanjem najpoeljnijeg ponaanja iz postojee klase i prekrivanje samo metoda koje su razliite u podlasama. U ovom trenutku ne bi trebalo brinuti o semantici nasleivanja, ve samo o mogunosti upotrebe koda. Kada se doe do funkcionalnog okvira, moe se poeti sa njegovom upotrebom. Odatle e se pokazati ta e se verovatno izmeniti, a ta ne. Kasnije, nepromenljivi kod okvira moe biti uauren i parametrizovan konverzijom okvira u okvir crne kutije. Meutim, u ovoj taki ivotnog ciklusa verovatno nee biti dovoljno informacija da se doe do Pravljenje nove klase zahteva programiranje. Polimorfna kompozicija zahteva znanje o tome ta e se promeniti. Kompozicija je mona tehnika ponovne upotrebe, ali ju je teko razumeti analiziranjem teksta statinog programa. Kompozicija se moe izmeniti pri izvrenju programa. Nasleivanje je statino i ne moe se lako izmeniti pri izvrenju.

33


Master rad

informisane odluke o tome koji delovi okvira e biti stalno menjani kroz aplikacije, a koji e ostati nepromenljivi. Implementacija Tokom razvoja buduih aplikacija, gde god se pojavi potreba za klasom koja je slina klasi isprojektovanoj u nekoj od prethodnih aplikacija, treba kreirati podklasu i prekriti metode koje se razlikuju. Ovaj metod je poznat pod nazivom "programiranje po razlikama" (eng. programming-by-difference). Poto se napravi nekoliko podklasa, poee da se izdvajaju delovi koji konstanto bivaju prekrivani, kao i oni koji su relativno stabilni. U tom trenutku programer e biti u mogunosti da kreira apstraktnu klasu koja sadri najee elemente. Takoe, u procesu prekrivanja metoda, verovatno e se pokazati da su odreene metode skoro iste u svim podklasama. Ponovo, trebalo bi izdvojiti delove koji se menjaju u novu metodu. Ovo moe dovesti do toga da poetne metode postanu identine i kao takve mogu se izmestiti u apstraktnu klasu. Slini paterni Uporedno sa razbojem novih aplikacija, trebalo bi poeti sa izradom biblioteke komponenata. Okviri crne kutije se bave istim problemom, ali u drugom kontekstu. 2.6.3 Biblioteka komponenata Kontekst Razvija se drugi primer, i svi sledei primeri na bazi okvira bele kutije. Problem Slini objekti moraju biti implementirani za svaku od aplikacija koje se kreiraju preko okvira. Kako izbei pisanje slinih objekata za svako korienje okvira? Sile Ogoljen okvir zahteva puno uloenog truda da bi se mogao koristiti. Stvari koje rade bez prethodnog podeavanja (eng. out-of-the-box) se koriste

34


Master rad

mnogo jednostavnije. Okvir sa dobrom bibliotekom konkretnih komponenata se jednostavnije koristi nego onaj sa malom bibliotekom. Isprva je teko rei koje komponente e biti potrebne korisnicima okvira. Neke komponente se odnose na konkretan problem dok se druge pojavljuju u veini reenja. Reenje Zapoeti sa jednostavnom bibliotekom najoiglednijih klasa i dodavati klase kako se javlja potreba za njima. Argumentacija Kako se dodaju klase u biblioteku, neke e se odnositi na konkretan problem i nikada vie se nee koristiti. Ovakve klasee na kraju biti uklonjeni iz biblioteke. Meutim, te klase e obezbediti vredan pogled na vrstu koda koji korisnik okvira mora da napie. Ostali klase e biti zajedniki za vie aplikacija. Iz njih e moi da se izvedu glavne apstrakcije u okviru domena problema koje bi trebalo da budu predstavljene kao komponente okvira. Implementacija Klase biblioteke komponenata su konkretne podklase apstraktnih klasa koje sainjavaju okvir. Apstraktne klase se obino nalaze u okviru, dok se konkretne klase obino nalaze u aplikaciji. Biblioteka komponenata moe biti kreirana prikupljanjem svih konkretnih klasa koje su stvorene za razliite aplikacije potekle iz okvira. Na duge staze, klasa bi trebalo da bude ukljuena u bibilioteku komponenata samo ako je koristi vie aplikacija, ali u poetku sve konkretne klase mogu da uu u biblioteku. Ako se neka komponenta mnogo koristi, trebalo bi da ostane u biblioteci. Ako se nikad ne koristi, izbacuje se. Mnoge komponente e biti refaktorisane u manje podkomponente kasnije navedenim uzorima.

35


Master rad

Slini paterni Kako se komponente dodaju u biblioteku, poee se uviati kod koji se ponavlja jer ga dele grupe komponenata. Trebalo bi pratiti arine take okvira u kojima se kod menja od aplikacije do aplikacije.

2.6.4 arine take Kontekst Dodavanje komponenata u biblioteku komponenata Problem Pri razvoju aplikacije bazirane na okviru, pojavie se slian, ali dovoljno razliit kod koji e morati da bude pisan iznova i iznova u svakoj novoj aplikaciji. Volfgang Pre (Wolfgang Pree) naziva ova mesta u okviru arinim takama. Kako eliminisati ponavljajui kod? Sile Ako je promenljivi kod razbacan po aplikaciji, teko je pratiti ga i menjati. Ako je promenljivi kod na nekoj zajednikoj lokaciji, tok programa moe biti zamaskiran jer e pozivi uvek biti ka objektu koji sadri promenljivi kod. Reenje Treba odvojiti kod koji se menja od onog koji se ne menja. Idealno, promenljivi kod treba uauriti u objekte kad god je to mogue, jer je objekte lake koristiti nego odvojene metode. Kada se kod uauri, varijacije se postiu kreiranjem eljenog objekta ee nego kreiranjem podklasa ili pisanjem metoda. Argumentacija Ako se okvir intenzivno koristi (emu i slui), odreeni delovi e esto varirati. Okupljanjem koda koji varira u pojedine objekte pojednostavie se proces upotrebe i pokazae se korisnicima gde projektanti okvira oekuju da se vre promene na okviru.36


Master rad

Dobro imenovanje ovih objekata e uiniti kontrolu toka manje bitnom za razumevanje okvira. Implementacija Mnogi uzori iz grupe Gang of Four uzora projektovanja uauruju razliite tipove promena. Sledea tabela pokazuje koje je paterne mogue upotrebiti kada se okvir menja od aplikacije do aplikacije:

ta se menja Algoritmi Akcije Implementacija Stanje nadreenog objekta Interakcije izmeu objekata Kreiranje objekata

Patern projektovanja Strategy, Visitor Command Bridge Observer Mediator Factory Prototype Method, Abstract Factory,

Kreiranje strukture Sekvencijalni pristup agregiranom objektu Interfejs objekta Ponaanje objektaTabela 1 Uzori projektovanja

Builder Iterator

Adapter Decorator, State

37


Master rad

Slini paterni Da bi se uaurile arine take, esto se moraju kreirati usitnjeniji (finer-grained) objekti. Ovakvi objekti e uiniti da se okvir priblii okviru crne kutije. 2.6.5 Prikljuni objekti (eng. Pluggable Objects) Kontekst Dodavanje komponenata u biblioteku komponenata. Problem Veina podklasa koje je potrebno napisati se razlikuju na trivijalne naine (npr. samo jedna metoda se prekrije). Kako izbei kreiranje trivijalnih podklasa svaki put kada se eli upotrebiti okvir? Sile Nove klase, koliko god trivijalne, poveavaju sloenost sistema. Sloene grupe parametara ine parametrizovane klase teim za razumevanje i upotrebu. Reenje Projektovati prilagodljive podklase koje mogu biti parametrizovane u smislu toga da imaju poruke za slanje, indekse za pristup, blokove za procenu i ta god je jo potrebno da se razlikuje jedna trivijalna podklasa od druge. Argumentacija Ako je razlika izmeu podklasa trivijalna, kreiranja novih podklasa da bi se uaurila mala promena je definitivno preterivanje. Dodavanje parametara u procesu kreiranja konkretne aplikacije omoguava upotrebu originalne klase bez neophodnosti da se koristi programiranje. Implementacija Odrediti koje promene se javljaju u svakoj od podklasa koje je neophodno napisati. Ako je razlika u konstanti, simbolu ili referenci klase, kreirati promenljivu koja e38


Master rad

sadrati referencu i proslediti je objektu u metodi za kreiranje obekta. Ako je varijacija u malom delu koda, proslediti blok koji predstavlja kod metodi za kreiranje objekta, i sauvati ga u promenljivoj. Slini paterni Kreiranje prikljunih objekata je jedan od naina za uaurenje arinih taaka u okvir. Parametri mogu biti automatski prosleivani pomou vizuelnog bildera (eng. visual builder).

2.6.6 Usitnjeni objekti (eng. Fine-grained) Kontekst Refaktorisanje biblioteke komponenata da bi je uinili upotrebljivijom. Problem Koliko daleko treba ii u deljenju objekata na manje objekte? Sile to je vie objekata u sistemu, to je tee razumeti sistem. Aplikacije neophodno. Reenje Treba razbijati objekte na sitnije i sitnije sve dok vie nema smisla to initi dalje, to jest, do trenutka kada bi dalja podela objekta rezultovala objektima koji nemaju individualno znaenje u domenu problema. Argumentacija Poto e okvire na kraju koristiti eksperti u domenu (odnosno ljudi koji nisu programeri), potrebno je obezbediti alate da se kompozicija automatski kreira. Stoga je mogu biti eljene kreirane jednostavnim izborom objekata koji nije implementiraju funkcionalnosti aplikacije. Programiranje

39


Master rad

vano izbei programiranje. Alati mogu biti tako dizajnirani da obezbede proirivanje objekata. Implementacija Bilo gde u bibilioteci komponenata naii e se na klase koje uauruju viestruka ponaanja koja bi mogla nezavisno da variraju. Treba kreirati razdvojene klase koje uauruju svako od ponaanja. Gde god se koristi izvorna klasa, treba je zameniti pozivom kompozicije prethodno kreiranih klasa koje implementiraju eljeno ponaanje. Ovo e umanjiti dupliranje koda, kao i potrebu za kreiranjem novih podklasa za svaku novu aplikaciju. Slini paterni Kako objekat postaje usitnjeniji, okvir postaje vie nalik okviru crne kutije. 2.6.7 Okvir crne kutije Kontekst Razvoj prikljunih objekata uauravanjem arinih taaka i kreiranjem usitnjenijih objekata. Problem Neki okviri se zasnivaju na nasleivanju, drugi na polimorfnoj kompoziciji. ta koristiti? Sile Nasleivanje rezultuje jakim kuplovanjem izmeu komponenata, ali

dozvoljava izmenu komponenata koje se upotrebljavaju, 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. Polimorfna kompozicija zahteva shvatanje toga ta e se promeniti.

40


Master rad

Kompozicija je mona tehnika upotrebe, ali ju je teko razumeti analizom teksta statinog programa. Kompozicija moe biti izmenjena u vreme izvrenja.

Reenje

Nasleivanje je statino i ne moe se jednostavno izmeniti u vreme izvrenja.

Koristiti nasleivanje da se organizuje biblioteka komponenata, a polimorfnu kompoziciju da se komponente iskombinuju u aplikaciju. U osnovi, nasleivanje e obezbediti sistematiku delova da bi se olakao pregled koda, a kompozicija e omoguiti maksimalnu fleksibilnost u razvoju aplikacija. Kada nije u potpunosti jasno koja je bolja tehnika za neku komponentu, trebalo bi favorizovati kompoziciju. Argumentacija Okvir crne kutije je onaj kod kog se komponente mogu upotrebiti prikljuivanjem i bez razmiljana o tome kako izvravaju svoje individualne zadatke. Suprotno tome, okviri bele kutije zahtevaju razumevanje naina na koji klase funkcioniu tako da se mogu razviti odgovarajue podklase. Ljudi vole da hijerarhijski organizuju stvari. Ove hijerarhije nam omoguavaju da klasifikujemo stvari i brzo shvatimo u kakvom odnosu su razliite klasifikacije. Korienjem nasleivanja, koje predstavlja "je" (eng. is) odnos, za organizaciju nae biblioteke komponenata, moemo brzo uvideti na koji nain je mnotvo komponenata u meusobnim relacijama. Korienjem kompozicije da se napravi aplikacija, izbegava se programiranje i omoguava se variranje kompozicije u vreme izvrenja. Implementacija Konvertovati odnose nasleivanja u odnose komponenata. Izvui zajedniki kod u nepovezane (po nasleivanju) klase i uauriti ga u nove komponente. Mnogi od prethodno pomenutih uzora e obezbediti tehnike za pronalaenje i kreiranje novih klasa sa komponentama.

41


Master rad

Slini paterni Organizovanjem biblioteke komponenata u ovom maniru, podravamo kreiranje vizuelnog bildera koji omoguava da se biblioteka pretrauje i da se kompozicije kreiraju grafiki. 2.6.8 Vizuelni bilder Kontekst Kada se jednom kreira okvir crne kutije, cela aplikacija se moe kreirati prostim povezivanjem objekata postojeih klasa. Ponaanje te aplikacije je sada u potpunosti odreeno time na koji su nain ovi objekti meusobno povezani. Uobiajeno je da se aplikacija sastoji iz dva dela: prvi deo je konfiguracija koja povezuje objekte okvira u celinu i "ukljuuje ih", a drugi deo predstavlja ponaanje individualnih objekata. Okvir obezbeuje najvei deo ponaanja objekata, ali programer aplikacije mora da napravi konfiguraciju. Problem Konfiguracija aplikacije je najee veoma slina od aplikacije do aplikacije, odnosno samo se specifini objekti razlikuju. Kako pojednostaviti kreiranje ovih konfiguracija? Sile Reenje Napraviti grafiki program koji omoguava specificiranje objekata koji e biti u aplikaciji i nain na koji su oni povezani. Taj grafiki program bi trebalo da generie kod za aplikaciju na osnovu specifikacija. Kompozicije koje predstavljaju aplikacije okvira konvoluiraju, teko se razumeju i generiu. Alati za izradu su skupi. Eksperti u domenu su retko programeri.

42


Master rad

Argumentacija Poto se specifian kod aplikacije svodi praktino samo na konfiguraciju, alat ga moe generisati automatski. Alat e takoe uiniti da okvir bude laki za korienje time to e obezbediti grafiki interfejs koji bi trebalo da koristi standardne notacije koje inae postoje u domenu problema. U ovom trenutku eksperti za domen mogu kreirati aplikacije jednostavnim manipulisanjem slika na ekranu. Samo u retkim sluajevima bi trebalo da bude neophodno dodavanje novih klasa u okvir. Implementacija Ponekad se komponente i odnosi u aplikaciji mogu u potpunosti odrediti kroz neke vrste pretraivaa sadraja ili dijaloge (eng. Dialog box). Ali, najee je neophodno crtanje grafika da bi se predstavili sloeni odnosi u komplikovanim domenima. Slini paterni Razvijen je vizuelni programski jezik, to znai da e biti neophodni jeziki alati, kao i u svakom drugom jeziku. 2.6.9 Jeziki alati Kontekst Upravo je kreiran bilder. Problem Vizuelni bilder kreira sloene kompozitne objekte. Kako jednostavno analizirati te kompozicije i otkloniti nastale greke (eng. debug)? Sile Reenje Kreirati specijalizovane alate za analiziranje objekata i uklanjanje greaka.43

Postojei

alati

su

obino

neadekvatni

za

bavljenje

specijalizovanim

kompozitnim odnosima koji postoje u okviru. Izrada dobrih alata je skup zadataka, i moe biti smatran za suvian.


Master rad

Argumentacija Poto je kreirani sistem u osnovi grafiki programski jezik vezan za odreeni domen, bie neophodni jeziki alati kao pomo u razumevanju i otklanjanju greaka. Alati koji dolaze uz programski jezik kojim je izraen okvir verovatno nee biti dovoljno dobri, jer e okvir biti pun malih objekata koji svi lie jedan na drugi, od ega e polovina biti potpuno neinteresantna nekome ko pokuava da jednostavno napravi aplikaciju. Implementacija Pronai delove okvira koji su komplikovani za ispitavanje i otklanjanje greaka. Oni se najee nalaze tamo gde se objekti intenzivno komponuju pomou stvari kao to su omotai eng. (wrappers) i strategije. Napraviti specijalizovane alate za navigaciju i ispitivanje kompozicija. Ovi alati bi trebalo da omogue korisniku da zaobie delove kompozicije koji nisu interesantni.

2.7 Dokumentovanje okviraStrma kriva uenja i razumevanja okvira oteava njihovu upotrebu i efikasnost te upotrebe. Stvar komplikuje injenica da razliitim ciljnim grupama trebaju razliite informacije: obian korisnik koji eli da iskoristi okvir na predvieni nain, a od dokumentacije oekuje da ga uputi na oekivano podeavanje okvira. Napredni korisnik koji eli da iskoristi okvir na nepredvien nain kombinovanjem razliitih arinih taaka na neispitan nain: ovaj tip korisnika mora razumeti principe i ogranienja arinih taaka, i naina na koji one funkcioniu zajedno. Ovo je slino standardnom razvoju softvera u kombinaciji sa problemima pri razvoju okvira. projektant drugog okvira eli da naui principe na kojima se zasniva fleksibilnost okvira uzetog kao primer, takozvane uzore projektovanja. Razliiti naini dokumentovanja okvira[28]: Primeri aplikacija (eng. Example Application) - Izvrni kod primera aplikacija koje su konstruisane upotrebom okvira je esto prva i jedina44


Master rad

dokumentacija koju imaju programeri aplikacija. Dokumentacija zahteva gradiranu grupu primera za vebu. Svaki bi trebalo da ilustruje po jednu novu arinu taku, poevi od najjednostavnijeg i najeeg oblika upotrebe za tu arinu taku, sve do potpune pokrivenosti. Veina kuvara se vrte oko malog broja jednostavnijih primera aplikacija. Recept (eng. Recipe) - Recept opisuje kako izvesti uobiajen primer upotrebe tokom razvoja aplikacije. Informacije bi trebalo da budu prezentovane neformalnim jezikom, moda uz poneku sliku, i najee uz primer izvornog koda. Iako neformalan, recept najee prati strukturu, kao npr. sekcije, korake recepta, ukrtanja sa drugim receptima i primere izvornog koda. Kuvar (eng. Cookbook) - Kuvar je kolekcija recepata. Najee postoji vodi kroz sadraj recepata, bilo kao sadraj kuvara ili kroz prvi recept koji je koncipiran kao pregled kuvara. Mnogi sistemi koriste kuvare kao metod prezentovanja dokumentacije. Jezik uzora (eng. Pattern Language) - Donson je uveo neformalni jezik paterna koji moe da se koristi za dokumentovanje okvira prirodnim jezikom. Svoj pristup je primenio na HotDraw, okvir za programe za izmenu slika. Ovi paterni sadre format svakog recepta i nain organizacije kuvara. Organizacija prati spiralni pristup gde recepti za najee oblike upotrebe bivaju predstavljeni pri poetku i gde se koncepti i detalji spominju to je kasnije mogue. Prvi recept je pregled koncepata okvira i drugih recepata. Motiv (eng. Motif) - Laoj i Keler (eng. Lajoie i Keller) su uveli termin "motiv" za Donsonove paterne da bi se izbeglo meanje sa uzorima projektovanja. Oni koriste ablon za opis motiva koji sadri naziv i nameru, opis situacije korienja, korake koje treba poduzeti pri podeavanju i ukrtanja sa drugim motivima, paternima projektovanja i ugovorima (eng. contracts). Paterni projektovanja obezbeuju informacije o internoj arhitekturi, a ugovori obezbeuju rigorozniji opis saradnji bitne za motiv.

45


Master rad

Ugovor interfejsa (eng. Interface Contract) - Ugovor obuhvata spisak obaveza. Ugovor interfejsa obezbeuje specifikaciju interfejsa klase i izolovanih invarijanti klase.

Ugovor interakcije (eng. Interaction Contract) - Ugovor interakcije se bavi kooperativnim ponaanjem vie uesnika koji interaguju kako bi postigli zajedniki cilj. Ugovor specificira grupu uesnika koji meusobno komuniciraju i njihove ugovorne obaveze: tipove ogranienja zadate od strane potpisa metode, semantike interfejsa metode i ogranienja ponaanja koja obuhvataju zavisnosti ponaanja izmeu objekata

Uzori projektovanja (eng. Design Pattern) - Uzor projektovanja je reenje problema koji bi mogao nastati u datom kontekstu. Opis uzora projektovanja objanjava problem i reenje u njegovom kontekstu, kao i raspravu posledica prihvatanja reenja. Problem moe biti ilustrovan konkretnim primerom. Reenje opisuje objekte i klase koji uestvuju u reenju, kao i njihova zaduenja i saradnje. Dijagram saradnje moe biti upotrebljen da predstavi te iste informacije. Takoe mogu biti prikazani primeri reenja u konkretnim situacijama. Analiza koristi i ustupaka primene uzora je vaan deo opisa uzora projektovanja. sistema. Uzori projektovanja pomau u razmevanju arhitekture

Pregled okvira (eng. Framework Overview) - Postavljanje konteksta okvira je prvi korak ka omoguavanju programeru aplikacije da upotrebi okvir. Pregled okvira definie argon domena i razgraniava opseg dejstva okvira: ta je pokriveno okvirom, a ta ne, kao i ta je fiksirano a ta fleksibilno. Mogue je da e postojati primer jednostavne aplikacije, kao i pregled dokumentacije. Pregled okvira je najee prvi recept u kuvaru.

Prirunik (eng. Reference Manual) - Prirunik objektno orijentisanog sistema se sastoji od opisa svih klasa. Uobiajeno je da opis klase sadri svrhu ili odgovornost klase, ulogu svakog lana podataka (eng. data member), i neke informacije o svakoj od metoda. Opis metoda prezentuje funkcionalnost metode, njene pred i post uslove i indikaciju na koje lanove podataka utie46


Master rad

ili ih koristi. Za dokumentovanje okvira, opisi mogu sadrati dodatne materijale po pitanju uloge klase ili metode u obezbeivanju fleksibilnosti arine take, naroito po pitanju toga da li je klasa zamiljena da sadri podklase ili metoda da bude prekrivena. Iako postoji mnogo razliitih moguih pristupa dokumentovanju okvira, ne postoji jasan standard. Najsigurniji pristup je korienje vie naina dokumentovanja okvira.

47


Master rad

3 Znaajni koncepti za razvoj sopstvenog okviraU ovom poglavlju bie definisani i opisani znaajni koncepti koji e biti korieni za razvoj sopstvenog okvira: Larmanova metoda razvoja softvera, tronivojska arhitektura, relacioni model, desktop aplikacija i automatsko programiranje (kod generator).

3.1 Larmanova metoda razvoja softvera

Agilne metode razvoja softvera su nastale kao odgovor na preteranu birokratiju tekih metoda, i trae kompromis izmeu previe i premalo planiranja kod razvoja softvera. Glavni aspekt agilnih metoda su jednostavnost, brzina i iterativan razvoj, u kome se zahtevi i reenja razvijaju kroz saradnju tima koji razvija softver i naruioca softvera. Larmanova metoda razvoja softvera spada u jednu od agilnih metoda razvoja softvera. Osnovne faze Larmanove metode razvoja softvera su [7][2]: Zahtevi predstavljaju uslove i svojstva koje sistem mora da zadovolji, a prikazuju se preko modela sluajeva korienja. Sluajevi korienja definiu interakciju korisnika sa sistemom, koje opisuje skup od jednog osnovnog i vie alternativnih scenarija. Scenario predstavlja skup eljenih korienja sistema od strane korisnika. Podvlaenjem imenica u sluaju korienja definiemo koncepte domena problema. Analiza opisuje logiku strukturu i ponaanje sistema: o Ponaanje softverskog sistema opisuje se preko: Sekvencnog dijagrama - prikazuje, za svaki scenario sluaja korienja, dogaaje u odreenom redosledu koji uspostavljaju interakciju izmeu korisnika i softverskog sistema. Dogaaje pravi korisnik, a sistem odgovara na njih u vidu poziva sistemske operacije. Ugovora o sistemskim operacijama - opisuju ponaanje sistemskih operacija, definiu ta sistemska operacija treba da radi bez48


Master rad

ulaenja u to kako e to da radi. Sistemska operacija opisuje ponaanje softverskog sistema. Ona je javna, da bi joj se moglo pristupiti iz okruenja softverskog sistema. o Struktura softverskog sistema: Konceptualni (domenski) model sistema - opisuje konceptualne klase domena problema i asocijacije meu njima. Konceptualne klase predstavljaju atribute softverskog sistema, to znai da opisuju njegovu strukturu. Relacioni model sistema - na osnovu konceptualnog modela moe se napraviti relacioni model kao osnov za projektovanje relacione baze podataka. Projektovanje opisuje fiziku strukturu i ponaanje softverskog sistema, odnosno arhitekturu sistema: o Definisanje arhitekture softverskog sistema, o Projektovanje aplikacione logike kontrolera, o Projektovanje strukture softverskog sistema domenskih klasa, o Projektovanje ponaanja softverskog sistema sistemskih operacija, o Projektovanje aplikacione logike database brokera, o Projektovanje skladita podataka. o Projektovanje ekranskih formi. o Projektovanje kontrolera korisnikog interfejsa. Implementacija, Testiranje.

3.2 Tronivojska arhitekturaVienivojska arhitektura (esto oznaena kao n-nivojska) je arhitektura u kojoj su prezentacioni sloj, obrada podataka i skladite podataka logiki odvojeni. Najrasprostranjeniji oblik vienivojske arhitekture je tronivojska arhitektura (Slika 3), koja se smatra istovremeno i arhitekturom sistema i uzorom projektovanja.[9]49


Master rad

I nivo

II nivo

III nivo

SOFTVERSKI SISTEM

KORSNIKI INTERFEJS

APLIKATIVNA LOGIKA

SKLADITE PODATAKA

Slika 2 Tronivojska arhitektura

Kod tronivojske arhitekture korisniki interfejs, poslovna logika i skladite podataka su razvijeni i odravani u nezavisnim modulima, esto na razliitim platformama. Pored standardnih prednosti koje imaju svi modularni softveri, tronivojska arhitektura tei da dozvoli da se slojevi aplikacije odvojeno menjaju. Na primer, promena operativnog sistema na serveru na kom se nalazi prezentacioni sloj uslovljava samo promenu koda na korisnikom interfejsu. Projektovanje softverskog sistema opisuje njegovu fiziku strukturu i ponaanje. Klasinu tronivojsku arhitekturu ine (slika 3) : Korisniki interfejs - ulazno-izlazna jedinica softverskog sistema. Aplikativna logika - opisuje strukturu i ponaanje sistema o Kontroler - prima zahteve za izvrenje sistemskih operacija od korisnika i prosleuje ga poslovnoj logici o Poslovna logika - odgovorna je za izvrenje sistemskih operacija. Takoe uva domenske klase o Broker - odgovoran je za komunikaciju poslovne logike sa skladitem podataka Skladite podataka - uva stanja atributa sistema

50


Master rad

SOFTVERSKI SISTEM

APLIKACIONA LOGIKA

KORSNIKI INTERFEJS

KONTROLER

POSLOVNA LOGIKA

BROKER

SKLADITE PODATAKA

Slika 3 Tronivojska arhitektura - komponente

3.3 Relacioni modelModel podataka je apstraktan model koji opisuje nain na koji su podaci predstavljeni i nain na koji im se pristupa. Model podataka formalno opisuje elemente i veze izmeu elemenata za odreeni domen. [9] Model ili ema baze podataka predstavlja strukturu baze podataka, opisanu kroz formalni jezik koji podrava sistem za upravljanje bazom podataka. Drugaije reeno, to je model podataka primenjen na sistem za upravljanje bazom podataka. Vrste modela baze podataka: Hijerarhijski model Mreni

marina ognjanovic razvoj sopstvenog okvira za generisanje desktop aplikacija

Documents