1. Pojam i elementi softverske arhitekture POJAM Softverska arhitektura raunarskog sistema ili programa je struktura, koja obuhvata softverske komponente, spoljanje vidljive osobine ovih komponenti i relacije izmeu njih. Termin se takoe odnosi i na dokumentaciju softverske arhitekture sistema. Dokumentovanje softverske arhitekture olakava komunikaciju izmeu svih uesnika u razvoju i omoguava ponovno korienje komponenti dizajna i ablona izmedju projekata. Disciplina softverske arhitekture se fokusira na ideji smanjenja kompleksnosti kroz apstrakciju i razdvajanja interesa. Danas jo uvek ne postoji precizna definicija softverske arhitekture. Postoji vie desetina klasinih i modernih tumaenja i definicija i vie stotina definicija od strane IT zajednice. Jednu interesantnu definiciju dao je Eoin Woods: "Softverska arhitektura je skup odluka o dizajnu koje, ako se ne donesu korektno, mogu dovesti do neuspeha projekta". ELEMENTI stilovi pogledi slojevi jezici paterni frejmovi alati standardi 2. Razlozi softverske arhiekture RAZLOZI slozenost dokumentacija diskusija ispunjenje zahteva pouzdanost skalabilnost prenosivost interoperativnost 3. Softver kao proizvod. Kvalitet softvera zahtevi---softverska arhitektura ---softverski kod

4. Softverski zahtevi: proizvodni i procesni Proizvodni i procesni proizvodni: ta treba softver da radi (da proizvede), na primer da obrauna platu da proveri da li je student ispunio uslove za upis semestra da pronae i prikae informaciju sa interneta ... procesni: kako treba softver da se razvija, na primer koji programski jezik razvojno okruenje tehnike i kriterijumi verifikacije ... Proizvodni i procesni zahtevi Postoji razlika izmeu proizvodnih i procesnih parametara softvera koji se razvija. Proizvodni parametri su zahtevi softveru, ta taj softver treba da uradi (npr. softver treba da verifikuje da je student ispunio sve uslove da izae na ispit). Procesni parametri se odnose na proces razvoja softvera (npr. softver treba da se pie u jeziku Java, ili ga treba razvijati u razvojnom okruenju otvorenog koda itd.). Procesne zahteva moe da postavi sama organizacija proizvoa softvera, ili njen kupac, ili neka trea zainteresovana strana. Procesni zahtevi mogu biti implicito generisani od nekih drugih softverskih zahteva kao, na primer, kada je re o izboru verifikacione tehnike, ili tehnike analize za smanjenje greaka koje mogu da ugroze pouzdsnost, itd.

1. Softverski zahtevi: funkcionalni i nefunkcionalni Funkcionalni i nefunkcionalni * funkcionalni (sposobnosti): preciziraju ponaanja ili funkcije, na primer i. modulacija signala ii.kreiranje izvetaja iii.provera prava pristupa iv.... b. nefunkcionalni: preciziraju kriterijume za proveru fnkcionisanja sistema i. mreni protok ii.raspoloivost iii.odravanje iv..... Funkcionlani i nefunkcionlani zahtevi Funkcionalni zahtevi** opisuju funkciju koji softver treba da izvri, odnosno definiu ta softver ili softverska komponenta treba uradi, npr : modulacija signala, formatiranje teksta, kalkulacija, manipulacija podacima itd. ). Funkcija softverskog sistema ili kompoente predstavlja skup ulaza, ponaanja prema ulazima i izlaza koji predstavljaju rezultat tog ponaanja prema ulazima. Ta ponaanja, kojima se definiu funkcionalni zahtevi, se modeluju kao sluajevi korienja (use cases) 1. Atributi kvaliteta softvera Performansa (Performance, izvravanje) Performansa kao atribut kvaliteta softvera definie metriku kojom se utvruje koliina posla koji aplikacija treba da izvri u odreenom vremenu, i/ili rok koji se ne sme prekoraiti da bi se posao smatrao korektno izvrenim. Tu metriku ine sledee mere izvrenja: Propusni opseg (Throughput). To je mera koliine posla koji apliakcija treba da obavi u jedinici vremena. Moe se meriti brojem izvrenih transakcija (transactions) po sekundi (tps), ili brojem obraenih poruka (messages) po sekundi (mps). Na primer, za bankarski sistem se moe zahtevati propusni opseg od 1000 transakcija u sekundi, a za marketinki sistem velike robne kue koja ima obimnu komunikaciju sa poslovnim partnerima - 50 poruka po sekundi. Vreme odziva (Response Time). To je mera vremena koje sme da protekne od iniciranja do zavretka transakcije, ili vremena koje je aplikaciji potrebno da odgovori na dobijeni ulaz. Na primer, na kasi u samoposluzi, posle koliko vremena nakon uitavanja bar-koda sa artikla iz kupeve korpe treba na ekranu da se pojavi cena artikla? Od toga zavisi komfor i zadooljstvo kupca i radnika na kasi. Vreme odziva se moe zadati kao: Garantovano vreme odziva, koje znai da aplikacija treba da odgovori na svaki zahtev za obradom u vremenu ne duem od zadate granice. Recimo, odgvor na upit u bazu podataka ne sme da se eka due od pola sekunde. Proseno vreme odziva, koje dozvoljava da obrada primljenog zahteva traje neto due kada je sistem veoma optereen, ali prosek ne sme da pree zadatu granicu. Ili se moe precizirati gornja granica vremena odziva na veinu zahteva, a da se za manji broj zahteva dopusti da ta granica bude vea. Recimo, 95% zahteva treba

da bude obraeno za manje od 4 sekunde, i ni za jedan zahtev se ne sme potroiti vie od 15 sekundi. Rok (Deadline). Dok vreme odziva predstavlja ogranienje vremena odgovora u odnosu na vreme kada je zahtev dobijen, rok predstavlja apsolutno vremensko ogranienje do kada neki posao treba da bude izvren. Recimo, softver Republikog fonda PIO treba da obezbedi obraun i isplatu prve rate penzija za sve penzionere svakog meseca do 10. u mesecu. Ili, zbirni pokazatelji o poslovanju kompanije treba da budu raspoloivi direktoru najkasnije u 8 sati svakog jutra za prethodni dan. Atributi kvaliteta softvera Skalabilnost (Scalability) Skalabilnost kao atribut kvaliteta softvera odgovara na pitanje: Koliko dobro e reenja za neke probleme funkcionisati ako se obim problema povea. Recimo, da li e postojati razlike u performansama ako je sistem instaliran tako da na njemu radi najvie 10 korisnika istovremeno, ili 100, ili 1000 korisnika? Ili, da li je arhitektura softverskog sistema osetljiva na obimpodataka koji treba obraditi? Recimo, da li e softverski sistzem a banku biti jednako dobrar za banke sa 10.000, 100.000 i 1.000.000 tedia? Skalabilnost se meri sledeim karakterostikama:: Obim zahteva (Requst Load). Ako se povea obim zahteva koje softver treba da obradi, to moe iziskivati potrebu da se poveaju hardverski kapaciteti, recimo vea memorija, vie servera, ili vie procesora u istom serveru. Skalabilnost u odnosu na opteenje zahtevima znai da e softverski sistem bez znaajnih modifikacija dobro raditi i na tako proirenoj platformi, bez umanjenja propusnog opsega ili uveanja vremena odziva. Simultane konekcije (Simultaneous Connections). Recimo, ako je arhitektura softverskog sistema napravljena da podri 1000 istovremenih korisnika, kako e sistem reagovati ako se broj istovremenih korisnika znaajno uvea? Skalabilnost u odnosu na broj simultanih (istovremenih) konekcija znai da se performanse sistema nee umanjiti ako se znaakjno uvea broj konekcija. To je posebno vano, na primer, kod provajdera internet-servisa (ISP Internet Sevice Provider). Ako se ISP-aplikacija ne moe bez veih intervancija i ulaganja skalirati sa, recimo, 2.000 na 100.000 istovremenih konekcija, male su joj anse da opstane na tritu. Obim podataka (Data Size). Da li e softverska arhitektura sa bazom podataka koja ima 100.000 zapisa zadrati dobre performanse ako se primeni nad bazom podataka od 1.000.000 zapisa?Ako hoe, onda je ona skalabilna u odnosu na obim podataka. Distribucija (Deployment). Skalabilnost u odnosu na distribuciju znai da se mogunost odravanja ne smanjuje sa poveanjem broja instalaija istog sistema. Idealno reenje ovog zahteva bi bilo da softverska arhitektura obezbedi automatizovane mehanizme distribucije, instaliranja, podeavanja i auriranja instaliranih aplikacija kod raznih kupaca ili korisnika istog softverskog sistema. Atributi kvaliteta softvera Izmenjivost (Modifiability) Izmenjivost kao atribut kvaliteta softvera meru mogunosti da se aplikacija modifikuje ako je to potrebno da bi se zadovoljili novi funkcionalni i nefunkcionalni zahtevi. Bezbednost (Security) Zahtevi koji se odnose na bezbednost su:. Autentinost (Authentication): Aplikacija treba da moe da verifikuje identitet korisnika koji joj pristupa ili druge aplikacije sa kojom komunicira. Autorizacija (Authorization). Korisnici i aplikacije ija autentinost je verifikovana treba da imaju definisana prava nad resursima softverskog sistema. Kriptozatita (Encrzption). Poruke koje aplikacija alje ili prima se kriptuju (ifriraju).

Integritet: To je mera sigurnosti da sadraj poruka nee biti promenjen tokom prenosa. Ne-osporavanje: Poiljalac i primlac ne mogu jedan drugom da ospore uee u razmeni poruka. Poiljalac treba da ima dokaz da je poruka isporuena, a primalac da bude siguran u identitet poiljaoca. Dostupost (Availability) i opravljivost (Recoverability) Kolika je pouzdanost da e apliakcija biti dostupna korisniku kada mu zatreba?Otkazi zbog greaka mogu uiniti apliakciju nedostupnom pa je oporavljivost usko povezana sa dostupnou. Integracija (Integration) Koliko lako se jedna apikacija moe ugraditi u iri aplikativni kontekst? Recimo, kako se sistem nabavke moe ugraditi u softverski sistem prodavnice? Prenosivost (Portability) Moe li aplikacija koja je razvijena za jednu platformu da se izvrava na drugoj platformi? Da li su delovi koda koji striktno zavise od platforme izolovani i enkapsulirani tako da se pri prenosu na drugu platformu mogu zameniti bez promena u preostalom kodu? Testiranje (Testability) Koliko je lako ili teko da se aplikacija testira? Podrivost (Supportability) Ovo se odnosi na mognost dijagnostikovanja i otklanjanja problema tokom korienja razviijene i implementirane aplikacije.

1. Elementi konceptualnog okvira za opis softverske arhitekture

2. Faze razvoja softverske arhitekture Planiranje a. Definisanje zahteva za arhitekturu b. Identifikacija zahteva arhitekture c. Prioriteti Projektovanje d. Izbor okvira (frejmvorka) e. Alokacija komponenti Validacija f. Primena scenarija g. Prototipovanje 3. Gledita i pogledi u softverskoj arhitekturi

1) Logiki model koji predstavlja objekat modela koji se dizajnira i koji je prilino

upotrebljiv kada se koristi metoda objektivno orijentisanog dizajniranja; Logika arhitektura prvenstveno podrava funkcionalne zahteve tj. ta sistem treba da obezbedi od usluge do korisnika. 2) Procesni model koji obuhvata konkurentne i sinhronizacione aspekte dizajna; Procesna arhitektura obuhvata neke nefunkcionalne zahteve kao to su performanse i dostupnost. Odnosi se na pitanja konkurencije i distribucije integriteta sistema i kako se glavni izvodi iz logikog pogleda uklapaju unutar procesne arhitekture. 3) Fiziki model koji opisuje mapiranje softvera na hardver; U okviru fizike arhitekture definiu se prvenstveno nefunkcionalni zahtevi sistema kao to su: pristupanost, pouzdanost, performanse i skalabilnost. 4) Razvojni model koji opisuje statiku organizaciju softvera i njegovo razvojno okruenje. Razvojna arhitektura svoje podruije izrade softverske arhitekture usmerava ka organizaciji softverskog modula u okviru softverskog razvojnog okruenja. 11. Logiki pogled u modelu "4+1"1) Logiki model koji predstavlja objekat modela koji se dizajnira i koji je prilino

upotrebljiv kada se koristi metoda objektivno orijentisanog dizajniranja; Logika arhitektura prvenstveno podrava funkcionalne zahteve tj. ta sistem treba da obezbedi od usluge do korisnika.

U logikom delu modela 4+1 zastupljeno je korienje klasnog dijagrama. Klasni dijagram pokazuje grupu klasa i njihove logike veze: asocijativnost, korisnost, Notacija logikog pogleda

Stil koji koristimo za logiki pogled arhitekture je objektivno orijentisani stil. 12. Procesni pogled u modelu "4+1" Procesna arhitektura obuhvata neke nefunkcionalne zahteve kao to su performanse i dostupnost. Odnosi se na pitanja konkurencije i distribucije integriteta sistema i kako se glavni izvodi iz logikog pogleda uklapaju unutar procesne arhitekture. Takoe prouava na kom se stepenu kontrole u stvari izvrava operacija za neki objekat. Proces predstavlja grupisanje zadataka koji formiraju izvrnu jedinicu. Procesi predstavljaju nivo na kome se procesna arhitektura moe taktiki kontrolisati Softver je podeljen na niz nezavisnih zadataka. Zadatak je odvojeni proces koji moe biti uraen nezavisno na jednom od procesnih nodova. Notacija procesnog pogleda

Postoji nekoliko stilova koji bi odgovarali procesnom pogledu. Na primer moemo primeniti: cevi i filtere, ili client/server sa razliitim varijantama viestrukih client/single usluge ili client/multiple usluge. 13. Razvojni pogled u modelu "4+1" Razvojna arhitektura svoje podruije izrade softverske arhitekture usmerava ka organizaciji softverskog modula u okviru softverskog razvojnog okruenja. Softver je upakovan u male delove programske biblioteke ili podsisteme, koji mogu biti razvijeni od strane jednog ili manjeg broja razvojnih timova. Podsistemi su organizovani po hijerarhiji koja se sastoji od slojeva (layers). Svaki sloj obezbeuje usko definisan interfejs za svoj nadreeni sloj. Same usluge razvojnog pogleda predstavljaju osnovu koja se odnosi na: 1) Raspored zahteva; 2) Raspored poslova u okviru razvojnih timova (ak i u okviru samog tima); 3) Za planiranje i procenu trokova; 4) Nadgledanje napretka projekta; 5) Razmatranje ponovnog korienja 6) Za portabilnost i sigurnost. 7) Razvojna arhitektura je osnova za uspostavljanje proizvodne linije po kojoj e se izraditi proizvod (softver). Notacija razvojne arhitekture

Preporuuje se da se stil sloja prilagodi samom pogledu, gde e biti definisano etiri do est slojeva za svaki podsistem. Svaki sloj mora imati definisan odreen stepen odgovornosti. 14. Fiziki pogled u modelu "4+1" U okviru fizike arhitekture definiu se prvenstveno nefunkcionalni zahtevi sistema kao to su: pristupanost, pouzdanost, performanse i skalabilnost. Kreira se softver koji svoju funkcionalnost primenjuje u okviru mree izmeu raunara i izmeu procesnih nodova vodei se nefunkcionalnim zahtevima. Veliki broj elemenata se identifikuje (mree, procesi, zadaci i objekti), a da bi ta identifikacija bila pravilna svi elementi moraju biti pravilno mapirani (adresirani) na njima validne nodove. Moe se koristiti nekoliko razliitih fizikih konfiguracija: 1) Za razvoj i testiranje sistema; 2) Za prilagoavanje sistema razliitim uslugama ili za razliite klijente.

3) Mapiranje softvera na nodove mora biti veoma fleksibilno i da ima minimalan uticaj na izvorni kod. Notacija fizikog planiranja

15. Scenariji u modelu "4+1" Scenarije moemo definisati kao proces izdvajanja najbitnijih zahteva u okviru sva etiri pogleda. Izdvajanje i dizajn sistema u okviru scenarija se moe prikazati preko dijagrama scenarija i dijagrama interakcije izmeu objekata. Dijagram scenarija predstavlja uzorak (template) koji se upotrebljava za bru izradu sistema ukoliko interakcija izmeu pogleda to dozvoljava. Dijagram interakcije se upotebljava kada se izrada sistema ne moe realizovati preko uzora jer sama interakcija izmeu pogleda to ne dozvoljava. Scenarijo je povezan sa sva etiri pogleda (kao to naziv kae on predstavlja +1), ali se moe koristiti kao: 1) Ureaj za otkrivanje elemenata arhitekture tokom dizajniranja sistema; 2) Kao validacioni i ilustracioni softver nakon dizajniranja arhitekture; 3) Poetna taka za testiranje prototipa sistema. Notacija scenarija Notacija scenarija to se tie komponenata umnogome slina notaciji logikog pogleda, ali koristi konektore procesnog pogleda za interakciju izmeu objekata. 17. Troslojna softverska arhitektura Sam naziv troslojna arhitektura softvera, govori nam da se susreemo sa organizacionom strukturom koja je podeljena u 3 celine (sloja). Ta tri sloja su sloj podataka, srednji sloj(poslovna logika) i prezentacioni sloj (korisniki interfejs). Svaki od ova tri sloja ima razliitu ulogu, a pritom, povezani u celinu ine veoma koristan i primenljiv sistem. Detaljnije o svakom sloju, bie u narednom poglavlju. Troslojni model znai da ne morate da pravite, instalirate ili podeavate klijentski sloj. Svaki posetilac koji ima ita veba moe da koristi veb aplikaciju koja ita podatke iz baze, obino bez potrebe da instalira dodatni softver, da koristi specifian operativni sistem

ili odreenu hardversku platformu. To znai da aplikacija moe da opslui bilo koji broj razliitih, geografski rasejanih korisnika. 18. Prezentacioni sloj Klijentski sloj u modelu troslojne arhitekture obino je ita veba. ita veba obrauje i prikazuje HTML resurse, alje HTTP zahteve za resursima i obrauje HTTP odgovore. itai veba su vrlo lagani klijenti, to podrazumeva da je vrlo mali deo logike srednjeg sloja optereen klijentskim slojem. ita samo alje HTTP zahteve za resursima i prikazuje odgovore, koji mahom sadre HTML dokumente. Meutim, ta je alternativa laganom klijentu? Namenski napisan Java aplet primer je teeg klijenta koji se ipak moe uklopiti u troslojni model. Korisnik preuzima aplet i izvrava vie aplikacione logike na svojoj platformi nego u sluaju laganog klijenta. Aplet i dalje komunicira sa srednjim slojem koji ipak predstavlja interfejs ka sloju baze podataka. U ovom sluaju prednost je prilagoenost odreenoj nameni. Umesto da se koristi generiki ita, koristi se namensko reenje koje eliminie mnoge probleme oko uvanja stanja, bezbednosti i manjkanja fleksibilnosti veba. Aplet uopte ne mora da koristi HTTP protokol za komuniciranje sa logikom aplikacije u srednjem sloju. 19. Srednji sloj U veini troslojnih sistema na vebu, najvei deo logike aplikacije nalazi se u srednjem sloju. Klijentski sloj prikazuje podatke korisniku i prihvata podatke koje on unosi. Sloj podataka skladiti i uitava podatke. Srednji sloj obavlja veinu preostalih zadataka pomou kojih se objedinjuju ostali slojevi: upravlja strukturom i sadrajem podataka koji se prikazuju korisniku obrauje podatke dobijene od korisnika alje upite ka bazi podataka (za upis , itanje ili auriranje) Takoe, ovaj sloj omoguava upravljanje stanjem uz upotrebu HTTP protokola. Logika aplikacije ugraena u srednji sloj integrie veb sa sistemom za upravljanje bazom podataka. U okviru ove teme, predstavljamo aplikacioni model u kome su komponente srednjeg sloja veb server, programski jezik za pisanje veb skriptova i maina za izvravanje skriptova. Veb server obrauje HTTP zahteve i formulie odgovore. U sluaju veb aplikacija, ti zahtevi su obino upueni programima koji komuniciraju sa osnovnim sistemom za upravljanje bazom podataka. Najee korien je Apache HTTP server, proizvod organizacije Apache Software Foundation. To je veb server otvorenog koda i koristi se na vie od 75% raunara koji su stalno povezani na Internet. 20. Sloj podataka Sloj podataka je osnova troslojne arhitekture. Razumevanje sistemskih zahteva, odabir softvera za sloj baze podataka, projektovanje baza podataka i izrada sloja prvi su koraci uspenog projektovanja aplikacija.

Sloj baze podataka zaduen je za upravljanje podacima. Upravljanje podacima obino podrazumeva skladitenje i uitavanje podataka, kao i upravljanje postupkom auriranja, pri emu vie procesa iz srednjeg sloja moe simultano da pristupa. Zatim, zatitu podataka, ouvanje njihovog integriteta i obezbeivanje usluga za podrku, poput izrade rezervnih kopija.

Da biste efikasno koristili DBMS, potrebno je da znate da projektujete bazu podataka i da formuliete komande i upite za DBMS. U veini DBMS-ova jezik za upite je SQL. Veini korisnika nije potrebno da razumeju unutranju arhitekturu DBMS-a. 21. Pojam i funkcije sistema sa klijent/server-arhitekturom Klijent/server model je baziran na distribuciji funkcija izmeu dva tipa nezavisnih i autonomnih procesa: servera i klijenta. Klijent je bilo koji proces koji zahteva specifine usluge od server procesa. Server je proces koji obezbeuje usluge za klijenta. Klijent i server mogu biti smeteni u istom raunaru ili u razliitim raunarima povezanim preko mree.U sluaju da su klijent i server procesi smeteni u dva ili vie nezavisnih i umreenih raunara, serverski proces moe da obezbedi usluge za vie od jednog klijenta. Pored toga, klijent moe zahtevati usluge i od vie servera iz okruenja bez obzira na njihove lokacije ili fizike karakteristike raunara na kojima se nalaze server procesi. Mrea slui da povee servere i klijente zajedno obezbeujui medijum kroz koji klijenti i serveri komuniciraju. Tipian (ali ne i obavezan) scenario po kome radi klijent/server arhitektura je sledei:

Serverski proces se startuje na nekom raunaru (na kome je smeten), inicijalizuje se, a zatim prelazi u sleep mod i eka da ga neki klijentski proces kontaktira i zatrai neki servis od njega. Klijentski proces se startuje na istom ili nekom drugom raunaru koji je preko mree povezan sa raunarom na kome se nalazi server. Klijentski procesi se esto inicijalizuju od strane interaktivnih korisnika koji zahtevaju izvrenje odreenih komandi. Klijentski proces alje zahtev putem mree do servera traei odreenu uslugu od njega. Kada serverski proces zavri posao (servis) koji je od njega zahtevan od strane klijenta, prelazi ponovo u sleep mod i eka sledei zahtev za nekom uslugom. Klijent je bilo koji raunarski proces koji zahteva usluge od servera. Klijent, poznat jo i kao eona aplikacija, odraava injenicu da je krajnji korisnik obino u interakciji sa klijent procesom. Server je bilo koji raunarski proces koji eka na zahteve od klijenata i obezbeuje potrebne usluge za klijente shodno pristiglim zahtevima. Poznat je i kao pozadinska aplikacija. Komunikacioni posrednik je bilo koji raunarski proces ijim posredstvom komuniciraju klijent i server. Sastavljen je od nekoliko softverskih nivoa koji pomau pri prenosu podataka i upravljakih informacija izmeu klijenta i servera. Komunikacioni posrednik je obino povezan sa mreom. Klijent

22. Komponente sistema sa klijent/server-arhitekturom

23. Raspodela funkcija i zadataka u klijent/server-arhitekturi Klijent je bilo koji proces koji zahteva usluge od serverovog procesa. Klijent zapoinje konverzaciju sa serverom. Klijent sadri hardverske i softverske komponente i poeljno je da one poseduju sledee karakteristike:

Ne toliko snaan hardver , Operativni sistem koji je sposoban da podri multitasking , Grafiki korisniki interfejs (GUI Graphic User Interface) , Komunikacione sposobnosti.

Klijent aplikacija se startuje pod nekim operativnim sistemom i povezuje se sa komunikacionim posrednikom radi pristupa slobodnim servisima na mrei i ove aplikacije su uglavnom zasnovane na grafikom korisnikom interfejsu sa namerom da se sakrije kompleksnost od krajnjeg korisnika. Klijent aplikacija interaguje sa operativnim sistemom radi korienja multitaskinga i grafikog korisnikog interfejsa koje on obezbeuje. Server Server je bilo koji proces koji obezbeuje servise za klijente. On je reaktivan jer uvek eka na zahteve klijenta. Posmatrano sa strane usluga koje pruaju klijentima tipini su sledei servisi: Server, takoe poseduje softversku i hardversku komponentu. Raunar koji radi kao server mora biti mnogo snaniji od uobiajenih klijent raunara zato to server procesi moraju da zadovolje konkurentne zahteve vie klijenata. Ovi raunari obino imaju veu procesorsku snagu (ne retko i vie snanijih procesora), vei kapacitet operativne memorije i vei kapacitet diskova nego raunari klijenata. Komunikacioni posrednik (meusloj) Softver komunikacionog posrednika obezbeuje sredinu kroz koju klijent i server komuniciraju radi izvoenja specifinih akcija. On je logiki smeten izmeu klijenta i servera i obezbeuje specijalne servise za izolovanje klijenta od detalja mrenih protokola i detalja u protokolima server procesa. Takoe, on izoluje aplikacionog programera od internih poslova u serveru i od mrenih protokola. Opti zahtevi: Hardverska nezavisnost, Softverska nezavisnost, Otvoreni pristup servisima, Funkcionalna distributivnost i Standardizacija 24. Referentni model servisno orijentisane arhitekture Servisno orijentisana arhitektura se zasniva na 4 kljune apstrakcije: aplikacija (application frontend), servis, repozitorijum servisa i magistralu servisa Servis predstavlja primarni element SOA arhitekture - enkapsulaciju poslovnog koncepta niskog nivoa. Njega karakteriu implementacija kojom je realizovana poslovna logika i podaci, servisni ugovor (Service Contract) koji definie funkcionalnost, uslove korienja i ogranienja za klijente servisa, i interfejs kojim se fiziki eksponira funkcionalnost servisa. Magistrala servisa je kluna komponenta za oslobaanje servisno orijentisane infrastructure za IT okretnost i podeavanje posla prema potrebama.Magistrala servisa treba da primi bilo koju sinhronizaciju ili nesinhronizovanu poruku u bilo kojem protokolu na putu do odredita prema konfigurisanim pravilima Repozitorijum servisa se koristi za skladitenje servisnih ugovora individualnih servisa. On obezbeuje alate za otkrivanje potrebnih servisa i pristup informacijama o uslovima njihovog korienja. Iako se veliki broj informacija o servisima skladiti u okviru servisnog ugovora, repozitorijumi servisa se mogu iskoristiti za skladitenje dodatnih korisnih informacija, kao

to su fizika lokacija servisa, informacije o vlasniku, odnosno provajderu servisa, informacije o trokovima korienja, tehnikim ogranienjima, pitanjima bezbednosti, itd. 25. Smernice za razvoj i aktivnosti razvoja servisno orijentisane arhitekture Osnovne smernice za projektovanje, razvoj, odravanje i korienje SOA arhitekture su viestruko korienje, granularnost, modularnost i interoperabilnost servisa, kao i okruenje za njihovu identifikaciju, kategorizaciju, isporuku, monitoring i praenje. Pritom, veoma je vano istai i ulogu upravljanja ivotnim vekom servisa, efikasno korienje resursa i praenje njegovih performansi i zrelosti. Osnovni principi za projektovanje servisno orijentisane arhitekture su[7]: 1. Enkapsulacija servisa. Servis se predstavlja svojom definicijom, odnosno, interfejsom prema okruenju, koji otkriva njegovu funkciju i odgovarajuom, enkapsuliranom logikom za njeno izvravanje. 2. Slaba meusobna povezanost. Iako izmeu servisa postoje relacije, oni ne smeju biti meusobno uslovljeni. Jedina vrsta veze koja se izmeu njih uspostavlja je znanje o meusobnom postojanju. 3. Ekspozicija funkcionalnosti servisa putem servisnog ugovora (Service Contract). Funkcija i opis servisa se predstavlja servisnim ugovorom (Service Contract). 4. Apstrakcija servisa. Okruenju su dostupne samo informacije o servisu koje su predstavljene u njegovom ugovoru. Logika funkcionisanja je sakrivena. 5. Viestruko korienje servisa. Logika se distribuira po servisima sa ciljem da se omogui njihovo viestruko korienje u razliitim kontekstima. 6. Sposobnost kompozicije servisa. Raznovrsne grupe servisa se mogu orkestrirati i koordinisati sa ciljem formiranja kompozitnih servisa. 7. Autonomija servisa. Iskljuivu kontrolu nad logikom koja je enkapsulirana u okviru odreenog servisa ima samo taj servis. 8. Neperzistentnost servisa. Servisi se staraju o ouvanju minimalnog skupa informacija o aktivnostima koje se sprovode. 9. Eksponiranost servisa. Servisi se projektuju tako da se mogu lako pronai i analizirati od strane odgovarajuih mehanizama za njihovo otkrivanje. 26. Primena referentnog modela na projektovanje servisno orijentisanih aplikacija Referentna arhitektura omoguava projektovanje, razvoj i uvoenje SOA aplikacija na nain da se dobiju to bolji rezultati i bri povraaj investicija (Return on investment, ROI). Referentna arhitektura se takoe odnosi na SOA stek reenja, koji definie slojeve, gradivne blokove arhitekture, odluke projektovanja i arhitekture, paterne i druge opcije koje pomau preduzeu da bolje realizuje vrednost SOA arhitekture. Na sl. 7. se prikazuju slojevi SOA referentne arhitekture.

Provajderi servisa se bave niim slojevima (servisi, komponente servisa i operativni sloj), dok su vii slojevi (servisi, poslovni procesi i konzumeri) briga konzumera servisa. Postoji pet horizontalnih slojeva koji se odnose na sveukupnu funkcionalnost SOA reenja. Vertikalni slojevi su nefunkcionalni po prirodi i podravaju razliite aspekte koji prolaze kroz funkcionalne slojeve: Operativni sloj, Sloj komponenata servisa, Sloj servisa, Sloj poslovnih procesa, Sloj konzumera, Sloj integracije, Sloj QoS, Arhitektura informacija i sloj poslovne inteligencije, Sloj upravljivosti 27. Planiranje softverske arhitekture kao deo softverskog procesa Plan projekta definie kako e se projekat razvijati da bi zadovoljio zahteve definisane od strane korisnika. Prvo se pravi grub raspored projekta da bi se isplanirao vremenski period. Ovaj raspored se bazira na pretpostavkama ,a ne na detaljima projekta Projekat arhitekture koji je razvijen nekom OO metodologijom slui kao osnova za razvoj aplikacije. Kada budu zavreni neki delovi programa poinje postupak kontrole. Kontrola moe da obuhvati proveru programskih linija, ispitivanje programskih celina, ispitivanje njihove integrisanosti i ispitivanje sistema. Cilj kontrole je pronalaenje greaka u programu to ranije u procesu razvoja. Gotova aplikacija zahteva odravanje koje moe ukljuiti ispravljanje greaka, proirivanje programa, promene pravila poslovanja itd. [2] Broj osoba koje rade na razvoju sotfvera zavisi od veliine i sloenosti projekta, ali uloge se jasno razlikuju. Uloge se mogu podeliti na

Kupac kompanija koja plaa za softverski sistem koji se razvija Korisnik stvarno radi na sistemu Razvojni tim - pravi softverski sistem za kupca tj. naruioca sastoji se od softverskih inenjera, ali svaki od njih moe da se specijalizuje za poseban aspekt razvojnog procesa 28. Dizajniranje softverske arhitekture Dizajn je definisan kao proces definisanja arhitekture, komponenti, interfejsa i ostalih karakteristika sistema ili komponenti. Softverski dizajn je aktivnost ivotnog ciklusa softverskog inenjeringa u kome se softverski zahtevi analiziraju u cilju proizvodnje opisa interne strukture softvera koja e sluiti kao osnova za konstrukciju. Jo preciznije, softverski dizajn mora opisati softversku arhitekturu, tj. kako je softver razloen i organizovan u komponente i kakav je interfejs izmeu ovih komponenti. Mora da opie komponente na nivou detalja koji omoguavaju njihovu konstrukciju 29. Validacija softvereske arhitekture Za vreme arhitekturalnog procesa cilj faze validacije je da povea pouzdanje u timu dizajnera i da uveri dizajnerski tim da arhitektura slui svrsi. Validacija treba biti postignuta u okviru vremena i budeta koje je bilo planirano za projekat, jer detaljan dizajn i implementacija ne mogu u potpunosti da se izvre dok se ne odobri arhitektura. Validacija mora biti to rigoroznija i to efikasnija. Validacija arhitekturalnog dizajna sadri izazove. Nebitno da li je re o arhitekturi za novu aplikaciju ili ocenjivanje ve postojeeg sistema, predloeni dizajn je, bas to, dizajn. Ne moe se pokrenuti ili testirati da bi se videlo da li ispunjava sve zahteve. Najverovatnije e se sastojati od novih komponenata, koji moraju biti napravljeni i ve postojeih specijalizovanih biblioteka i aplikacija. Svi ovi delovi moraju biti sjedinjeni i raditi zajedno. Dakle, ta logino treba uraditi? Postoje dve glavne tehnike koje su se pokazale korisne. Prva u sutini ukljuije runo testiranje arhitekture koristei test scenarija. Drugo ukljuuje konstrukciju protopita koji kreira prostu arhitekturu dizajnirane aplikacije, tako da njegova sposobnost da zadovolji potrebe moe biti povezana u dublje i detaljnije testiranje prototipa. Cilj obe tehnike je da prepozna potencijalne greke i slabosti u dizajnu, koje mogu da se poprave pre nego to implementacija pone. Ovi pristupe bi trebalo koristiti za identifikaciju potencijalnih rizika za praanje i posmatranje tokom procesa pravljena 30. Pojam i znaaj dokumentacije softverske arhitekture , (, , )

. . [1]. : . , . . . , , . : . . . . . . . . 31. Znaaj UML za razvoj na polju modelovanja i dokumentovanja softverske arhitekture , UML . . , , . UML 2.0 . . . , , . , UML , UML . , UML- . :

(Class diagrams), (Component diagrams),

(Package diagrams), (Deployment diagrams), (Object diagrams), (Composite Structure diagrams). . :

(Activity diagrams), (Communication diagrams), (Sequence diagrams), (State Machine diagrams), (Interaction Overview diagrams), (Timing diagrams), (Use Case diagrams).

32. Odabir pogleda za dokumentovanje . . / , . 3 :1. .

. 1. . . , . . 2. . . . , , . . 3. . . . , . ,

, . 33. Dokumentovanje pogleda , [2] , , . .1.

2.

3.

4.

5.

. . , . . , . , . . . . , . , , . , , , . [2]. , , . , , , . . , . , : a. . . , , . b. . , , . . , . :

a. ,

.b. ,

.c. , . 6. . 7. .

. , , . , , . 34. Pojam, struktura i znaaj ablona (template) dokumentacije softverske arhitekture . : , . 35. Ciljevi i principi UML-modelovanja Ciljevi UML modelovanja UML modelovanjem se postiu sledei ciljevi: - model slui da se sistem vizuelno prikae kakav jeste ili kakav elimo da bude (vizuelizacija); - modelom se definie struktura i ponaanje sistema (specifikacija); - model predstavlja uzor koji pokazuje kako sistem treba konstruisati (konstrukcija); - model predstavlja dokumentaciju projektnih odluka (dokumentacija). Principi UML modelovanja - Izbor modela koji se prave ima kljuan uticaj na to kako se problem reava i kako se oblikuje reenje. - Svaki model moe imati razliite nivoe detalja. - Najbolji modeli su povezani sa realnim svetom. Nijedan model nije dovoljan sam za sebe; svaki netrivijalni sistem najbolje se opisuje malim skupom skoro nezavisnih modela. Tri osnovna elementa UML modela su: - Osnovni gradivni blokovi - Pravila za povezivanje gradivnih blokova - Opti mehanizmi koji se primenjuju u UML-u 36. Primena UML na dokumentovanje funkcionalnosti i granica sistema

Ponaanje sistema (funkcionalnost koju sistem treba da obezbedi) koji se razvija treba da se dokumentuje modelom sluajeva korienja koji prikazuje predviene funkcije sistema (sluajeva korienja), njegovu okolinu (aktere) i relacije izmeu sluajeva korienja i aktera (dijagrame sluajeva korienja). Model sluajeva korienja zapoinje u poetnoj fazi (inception phase) identifikacijom aktera i glavnih sluajeva korienja za sistem. Model se dorauje u fazi razrade (elaboration phase) gde se dodaju detaljnije informacije o identifikovanim korisnikim funkcijama. Akteri (actors), nisu deo sistema ve predstavljaju bilo koga ili bilo ta to mora da usposatvlja interakciju sa sistemom. - Akter moe: Samo da unosi informacije u sistem Samo da prima informacije od sistema Unosi informacije u sistem i prima ih od njega Sluajevi korienja (use case) modeluju dijalog izmeu aktera i sistema. Predstavljaju funkcionalnost koju obezbeuje sistem; tj. mogunosti koje e sistem obezbediti akteru. Sluaj korienja se moe definisati kao niz transakcija koje izvodi sistem, koji daje merljive rezultate, od vrednosti za pojedinanog aktera. Pitanja koja mogu pomoi u identifikaciji sluajeva korienja sistema: Koji su zadaci svakog aktera? Da li e neki akter kreirati, uvati, menjati, brisati ili itati informacije u sistemu? Koji e sluaj korienja kreirati, uvati, menjati, brisati ili itati ove informacije? Da li e neki akter morati da informie sistem o iznenadnim spoljanjim promenama?

37. Primena UML na modelovanje ponaanja sistema Model koji posmatra sistem iz ove perspektive je model ponaanja. Model ponaanja se koristi da opie ponaanje sistema. On pokazuje kako sistem reaguje na dogaaje. Sistemi za rad u realnom vremenu su esto voeni dogaajima i za njih je ovaj model pogodan jer prikazuje reakciju sistema na razliite dogaaje. Iz perspektive ponaanja promatraju se transformacije podataka i reagovanje sistema na dogaaje. Za prikazivanje ovog modela koristimo dijagram aktivnosti. UML dijagram aktivnosti Ovi dijagrami predstavljaju dinamiku sistema. Aktivnost predstavlja izvoenje nekog ponaanja u procesu rada. To su dijagrami toka koje koristimo da bi prikazali proces rada u sistemu, tj. oni pokazuju tok kontrole od aktivnosti do aktivnosti u sistemu, koje aktivnosti se mogu obavljati paralelno, kao i bilo koji altrentativni put kroz tok. Mogu predstaviti tok preko svih use case-ova

ili tok unutar use case-a. Dijagrami aktivnosti sadre aktivnosti, tranzicije izmeu aktivnosti, take odluke i sinhonizacione sabirnice (synchronization bars). UMLu aktivnosti se predstavljaju kao zaobljeni pravougaonici, tranzicije se crtaju kao usmerene strelice, take odluke kao rombovi, a sinhronizacioni barovi kao debele horizontalne ili vertikalne pruge Struktura dijagrama aktivnosti sadri: - Poetak: akcija poetnog vora (initial node) - Izvravanje akcije - Grananje (fork): ima jedan ulazni tok i nekoliko paralelnih izlaznih tokova - Spajanje (join): ima vie ulaznih tokova i jedan izlazni tok koji zapoinje tek kada svi ulazni tokovi stignu do take spajanja - Kraj: zavrni vor 38. Pojam i poslovni modeli elektronskog poslovanja E-poslovanje (e-business) predstavlja upotrebu Internet tehnologija i drugih informacionokomunikacionih dostignua za poboljanje poslovnih procesa Elektronsko poslovanje je skup poslovnih aktivnosti koje se odvijaju posredstvom informaciono-komunikacionih tehnologija, a posebno Interneta, i koje podrazumevaju: optimizaciju poslovnih procesa (proizvodnja, marketing, veleprodaja, distribucija, prodaja, naplata, isporuka, dopuna zaliha); unapreenje odnosa sa ciljnim javnostima (klijentima, zaposlenima, dobavljaima, distributerima); unapreenje ostalih poslovnih servisa podrke (banke, advokatske agencije, raunovodstvene agencije, zakonodavstvo i vladine agencije). Postoje tri osnovna modela E-poslovanja: B2B (elektronsko poslovanje meu kompanijama) B2C(elektronsko poslovanje izmeu kompanija i pojedinaca) C2C(elektronsko poslovanje meu pojedincima) 39. Arhitektura elektronskog poslovanja

Glavne inioice arhitekture elektronskog poslovanja ine: Web sajt Baza podataka IS kompanije Skladitenje podataka Priprema i analiza podataka

40. Pojam i struktura softverske arhitekture P2P U aplikacijama tipa P2P za razmenu fajlova program na korisnikom krajnjem sistemu ponaa se kao klijent kada od drugog raunara zahteva neki fajl, a kao server kada fajlove alje drugom raunaru. Na Internetu, strane koje komuniciraju meusobno su ravnopravnekomunikacija je simetrina, pri emu obe strane i alju i primaju podatke. Izraz peertopeer se moe definisati kao mrea ravnopravnih vorova na aplikacijskom sloju, u kojoj svaki vor istovremeno ima funkciju klijenta i servera, mrea u kojoj korisnici doprinose svojim vlastitim dokumentima ili ostalim resursima. 41. Vrste softverske arhitekture P2P Mree tipa P2P se mogu prema strukturi podeliti na: centralizovane decentraliziovane strukturirane nestrukturirane Centralni sistemi (sl. 3.) tipa P2P zasnivaju se na centralnom serverskom sistemu koji usmerava promet izmeu pojedinih registrovanih korisnika.

Decentralizovane mree tipa P2P (sl. 4.) su druga generacija ovih mrea, a njihova je glavna karakteristika da izbegavaju strukturu sredinjeg sistema servera. Takvi sistemi dalje se mogu podeliti na strukturirane i nestrukturirane sisteme Kada govorimo o strukturiranim sistemima tipa P2P, govorimo o sistemima sa definsanom mrenom topologijom. Oni funkcioniu tako da svaki vor ima svoj jedinstveni identifikator p (npr. ime) koji je mogue sa raspodeljenim algoritmom jednoznano povezati sa kljuem k. Implementira se metoda lookup (k) koja vraa identifikator vora koji je odgovoran za klju k. Kod nestrukturiranih, za razliku od strukturiranih sistema, mrena topologija nema definisanu strukturu, ve mrea vorova ini sluajan graf. Podaci su smeteni na vorovima koji ih kreiraju, a pretraivanje sistema izvodi se preplavljivanjem ili sluajnim izborom (random walk). 42. Primena modela pogleda "4+1" na arhitekturu P2P Arhitekturu tia P2P je moguce korienjem UML dijagrama predstaviti kroz svi pet pgleda, odnosno kroz model 4+1. Sledeih pet slika predstavljaju prikaz arhitekture P2P kroz poglede modela 4+1. Na sl. 8. i 9. predstavljen je logicki pogled arhitekture tipa P2P korienjem UML dijagrama sekvenci i dijagrama saradnje.

Kao to je ve reeno peti, dodatni, pogled modela 4+1 se pradstavlja UML dijagramom sluajeva korienja. Na sl. 12. videmo kako na primeru arhitekture tipa P2P izgleda ovaj pogled.

43. Pojam i primena softverskih okvira Softverski okvir je skup kodova ili biblioteka koje obezbeuju funkcionalnost zajedniku za celu aplikaciju. Softverski okvir u kompjuterskom programiranju predstavlja apstrakciju kojom se programiraju generike funkcionalnosti. Programski kod softverskog okvira je uopten. U njegovoj primeni na konkretan problem, opti kod se zamenjuje korisnikim kodom tako da generika funkcionalnost okvira dobija svoje konkretno znaenje, specifino za taj problem. Okvir je specijalni sluaj softverske biblioteke u kojoj se koristi viekratna apstrakcija koda uvijenog u dobro definisan API (Application programming interface Aplikacioni programski interfejs). API je raunarski interfejs koji definie naine na koje aplikacioni program moe da zahteva servise od biblioteka i/ili operativnih sistema. On odreuje renik i konvencije pozivanja koje programer treba da primeni kako bi koristio servise. To moe da ukljuuje specifikacije za rutine, strukture podataka, objektne klase i protokole koji se koriste za komunikaciju izmeu softvera koji trai uslugu i biblioteke [3]. Meutim, okviri sadre neke kljune specifinosti koje se razlikuju od normalne biblioteke. 44. Slojevi i domeni u referentnom modelu arhitekture poslovnog sistema

Domen arhitekture U kontekstu stvaranja arhitekture poslovnog sistema uobiajeno je, prema Peter Bernus (2005), da se prepoznaju tri ili etiri tipa arhitekture, od kojih svaki odgovara odreenom arhitekturnom domenu. Primeri takvih domena su: Poslovna arhitektura: opisuje strukturu i ponaanje poslovnog sistema (ne nuno vezano za raunare). Pokriva poslovne ciljeve, poslovne funkcije ili mogunosti, poslovne procese i uloge itd. Poslovne funkcije i poslovni procesi esto podrazumevaju ispravke u aplikacijama i podacima koje su im potrebne. Arhitektura informacionih sistema, esto podeljena na o Arhitekturu podataka: opisuje strukturu podataka koje koristi posao i/ili aplikacija. Obuhvata opis skladitenih podataka i prenos podataka u pokretu. Opisuje skladite, grupe podataka i stavke podatka. Mapiranje tih podataka rezultuje proizvodnjom kvaliteta podataka, aplikacija, lokacija i slino. o Aplikacionu arhitekturu: opisuje strukturu i ponaanje aplikacija koji se koriste u poslovanju, fokusirana je na nain interakcije jednih sa drugima i sa korisnicima. Takoe, fokusirana je na podatke koji se koriste i proizvode od strane aplikacija, a ne na njihovu unutranju strukture. U aplikacijama za upravljanje mapama, aplikacije su obino mapirane poslovne funkcije i tehnologije primene platforme. Tehnika arhitektura ili arhitektura infrastrukture: opisuje strukturu i ponaanje tehnologije infrastrukture. Pokriva klijent i server vorove hardverske konfiguracije, infrastrukturu aplikacije koje rade na njima, infrastrukturu usluge koje nude aplikacije, protokole i mree koje povezuju aplikacije i vorova. [10] Arhitektonski domeni su kriterijumi za skup arhitektonskih proizvoda. Ne bi ih trebalo meati sa aplikacionim domenima okvira. Slojevi arhitekture poslovnog sistema Slojevi arhitekture poslovnog sistema su (sl. 2): Poslovni procesi i aktivnosti Podaci koji moraju da se prikupljaju, organizuju, uvaju i distribuiraju Aplikacije, kao to su kombinacije ili gotovi softverski alati Tehnologija, kao to su kompjuterski sistemi i telefonske mree

45. Pojam i principi semantikog veba Ideja je da se sve informacije, koje se na web-u pojavljuju, oznae posebnim tagovima tako da raunari mogu automatski povezati podatke iz jednoga tipa informacija (primer fotografija s oznaenim mestom, datumom i vremenom nastanka) s nekim drugim tipom informacija (primer meteoroloki izvetaj za period kada je nastala fotografija) semantiki veb kao koncept predstavlja i omoguava da vebu dostupni izvori informacija mogu biti organizovani i korieni semantikim, a ne sintaktikim ili strukturnim metodama. Semantiki veb predstavlja sinergiju programa koji prikupljaju sadraj sa weba iz razlicitih izvora, zatim vri obradu informacija i razmenjuje rezultate sa drugim programima, na globalnom nivou. Sve moe biti identifikovano URI-ovima Ljudi, mesta i stvari u fizikom svetu mogu biti u semantikom veb-u koristei niz identifikatora. Onaj ko ima kontrolu na delu prostora imena na veb-u (Web Namespace) moe kreirati URI i rei da on identifikuje neto u fizikom svetu Resursi i linkovi mogu imati tipove Semantiki Veb se takoe sastoji od resursa i linkova (slika 1). Meutim, kod njega resursi i linkovi mogu imati tipove koji definiu koncept koji daje vie informacija maini (raunaru na primer). Tolerancija parcijalnih informacija semantiki veb neogranien, bilo ko moe rei bilo ta o bilo emu i stvarati razliite tipove ili linkove izmeu resursa. Uvek e postojati neto vie za otkrivanje. Neki od povezanih resursa mogu prestati postojati ili adrese mogu biti ponovno iskoriene za neto drugo. Alati na semantikom veb-u trebaju da toleriu taj raspad podataka (data decay) i da budu u mogunosti da funkcioniu upkos tom raspadu. Nema potrebe za apsolutnom istinom Sve to je pronaeno na veb-u nije apsolutno istinito i semantiki veb ne menja to na bilo koji nain.

Podrka evoluciji Semantiki veb koristi opisne konvencije koje se mogu iriti kao to se i ljudsko razumevanje iri. Konvencije doputaju efektivne kombinacije nezavisnih poslova raznih zajednica ak i kad koriste razliite renike. 46. Vieslojna arhitektura semantikog veba Principi Semantikog Web-a su primenjeni na slojeve Web tehnologija i standarda. Slojevi su prikazani na slici 2. Unicode i URI slojevi slue da nam omogue korienje internacionalnog skupa znakova (character set) i prue nain za identifikovanje objekata na semantikom veb-u. XML sloj sa prostorom imena i emom definicija osigurava integraciju definicije semantikog veb-a sa ostalim standardima baziranim na XML-u. Sa RDF-om i RDF emom mogue je napraviti izvetaje o objektima sa URI-ovima i definisati renike kojima se moe upravljati preko URI-ova. Ovo je sloj u kojem moemo dati tipove resursima i linkovima. Ontoloki sloj podrava evoluciju renika, takoe moe definisati relacije izmeu razliitih koncepata. Navedeni slojevi, zajedno sa slojem za detekciju promena kod dokumenata (Digital Signature layer), trenutno se standardizuju od strane radne grupe W3C. Slojevi na vrhu: Logic, Proof, Trust se trenutno razvijaju i grade se jednostavni demonstrativni primeri. Logiki sloj omoguava pisanje pravila, dok Proof sloj izvrava (executes) ta pravila i evoluira, zajedno sa Trust slojem (da li da se veruje datom dokazu (proof) ili ne) 47. Okvir za opis resursa semantikog veba XML XML je osmiljen za opis podataka. Elementi u XML nisu predefinisani ve se moraju definisati vlastiti elementi. RDF Resource Description Framework (RDF) je jednostavan model, dizajniran za prikazivanje meta podataka (podatke o podacima) o resursima na veb-u. RDF ima grafiku sintaksu i XML baziranu serijsku sintaksu. Interpretacija trojke je da ima svojstvo ija je vrijednost . U RDF-u je uvek resurs identifikovan sa URI-om. je vlasnitvo resursa dok je vrednost vlasnitva resursa. Ontologije ontologija znaci formalno definisani sistem od pojmova i/ili koncepata i relacija izmedu tih pojmova. Web konstruktori se slue ontologijama za registrovanje odnosa, relacija i karakteristika objekata. OIL OIL (Ontology Inference Layer) predstavlja jezik za opis ontologija na web-u. U velikoj mjeri OIL se zasniva na, i uzima kao polaznu taku RDF eme.

DAML (DARPA Agent Markup Language) je jezik zasnovan na ontologijama, razvijen je kao proirenje XML-a i RDF-a. DAML u odnosu na RDF ema ide jo jedan korak dalje, pruajuci dodatnu dubinu kod properties-a i klasa, omogucavajui time iri spektar izraavanja nego od RDF Schema. 48. Zainteresovane strane elektronskog dnevnika Zainteresovane strane sistema "Elektronski dnevnik" su: -dizajner sistema- on predstavlja zainteresovanu stranu zato to ima novanu korist od izrade arhitekture i kasnijeg odravanja sistema; -administrator- predstavlja zainteresovanu stranu jer neko treba da odrava sistem, bilo da je to neko od profesora informatike iz kole ili neki drugi administrator koji e biti zaposlen; -kola- zbog toga to je olakava celokupan kolski sistem ili program te kole, kao i administracija kako uenika tako i zaposlenih u koli; -direktor- zbog toga to ima uvid u administraciju i u svakom trenutku ima uvid u detaljnu analizu rada u toku kolske godine kako profesora i uenika, tako i svog ostalog osoblja zaposlenog u administraciji te kole; -profesori (nastavnici)- predstavljaju zainteresovanu stranu koja predstavlja kljuni element u funkcionisanju ovog sistema. Oni vode kompletnu evidenciju dogaaja na jednom asu, bilo da se tie upisa ocena, izostanaka ili asa. Elektronski dnevnik im takoe omoguava laku komunikaciju sa roditeljima. U delu administracije nastavnik ima mogunost videti popis svih razreda u koli, uspeh i prosek svog odeljenja i detaljnu analizu izostanaka koja mu olakava prikupljanje podataka za nastavne sednice. -roditelji- roditelji su u mogunosti da putem interneta u Elektronskom dnevniku pogledaju uspeh,vladanje,rezultate sa takmienja i naravno izostanke svoje dece. Prema tome ne moraju da dolaze u kolu,a ima i onih koji nemaju tu mogunost, pa moraju doi i interesovati se za uenje i vladanje svoje dece. Otvorena je i mogunost da roditelj unese podatke,miljenja,predloge,sugestije,koje se onda razmatraju i nalaze se reenja. -uenici- uenici takoe predstavljaju zainteresovanu stranu jer im elektronski dnevnik omoguuje uvid u svoje ocene i izostanke. To im pokazuje trenutno stanje, u sluaju da su zaboravili i olakava jer ne moraju voditi evidenciju o ocenama.Automatski im je pokazan prosek ocena iz nekog predmeta i ve znaju koja je to ocena i imaju predstavu ta bi trebala biti sledea ocena u sluaju da ele bolje rezultate. I na kraju, Miniastarstvo prosvete predstavlja zainteresovanu stranu iz razloga to ima uvid u sve kole koje pripadaju tom sistemu, i moe pratiti uspeh kole, moe ih rangirati i raditi na poboljanju neuspeha blagovremeno, a ne kada se desi problem. 49. Proizvodni zahtevi elektronskog dnevnika Mogunost identifikacije i prijavljivanja Softver mora podravati prijavljivaje pomou korisnickiog imena i lozinke, koja imaju razlicita prava pristupa. Tako bi se spreila potencijalna zloupotreba i omoguilo praenje pristupa. Trebalo bi da postoji glavni administratorski nalog koji regullise pristup ostalih naloga, uenici i roditelji bi imali samo pravo pregledanja (nalozi im ne bi bili potrebni, ali sve zavisi da li se ocene smatraju privatim ili javnim tj. da li ih mogu pregledati samo uenici i roditelji ili bilo koja osoba koja pristupi dnevniku). Upisivanje ocena

Profesori i nastavnici bi imali mogunost upisa ocena uenicima, kao i zakljuivanje kranje ocene, ali samo iz svog predmeta. Softver bi trebalo da moe da rauna prosek ocena iz svakog predmeta pojedinano, da rauna ukupan prosek svih ocena i da na kraju kolske godine odredi uspeh svih uenika, i ukupan prosek ocena svih ucenika iz jednog predmeta ili ukupan uspeh ucenika iz razreda (ako bi softver postao obavezan, onda i prosek cele kole,svih kola u gradu,dravi itd). Dodavanje uenika i profesora Na poetku kolske godine moraju se ubaciti svi profesori i uenici. Mogunost dodavanja i brisanja treba da postoji i u toku kolske godine u sluaju zamene profesora ili dolaska i odlaska uenika. Dodavanje predmeta Dnevnik treba da sadri spisak predmeta,i mogunost dodavanja novih predmeta pre poetka kolske godine(u sluaju da doe do izmena u programu smerova). U softver bi trebalo uneti templejt-e (template) za razliite smerove i razrede koji sadre predmete za taj smer treba dodati i mogunost izmene dodavanja novih i brisanja templejt-a (u sluaju dodavanja,izmene ili ukidanja smerova). Skladitenje podataka Softver bi trebalo da ima bazu podataka u kojoj se skladite imena uenika,imena nastavnika i profesora, ocene, vreme pristupa razlicitih korisnika,vreme dobijanja ocena itd. Dnevnik mora imati i funkciju arhiviranja kada se kolska godina zavri. Svi podaci moraju biti zatieni od neautorizovanog pristupa i izmene. Prikaz podataka Softver mora imati funkcije prikaza podataka (ocene, datum dobijanja ocene,prosek ocena, ime nastavnika, itd.) . Moe postojati nekoliko naina prikaza (kao tabela, lista itd.), mogu se dodati i mogunosti prikaza funkcija razliitih podataka koristei grafike (npr. uspeh uenika jednog razreda u toku vremena, prosek ocena iz nekog predmeta u toku vremena, ili koorelacija ocena iz slinih predmeta ). 50. Procesni zahtevi elektronskog dnevnika Procesni zahtevi se odnose na sam razvoj softvera i definisu: kojim programskim jezikom treba da se izradi softver, njegov interfejs, tehniku koja ce omoguciti smanjenje gresaka u fazi razvoja kao i upotrebu softvera. Procesni zahtevi mogu biti uslovljeni od zaintresovanih strana. 51. Atributi kvaliteta softvera elektronskog dnrvnika Skalabilnost - sistem treba da obavlja svoju funkciju bez obzira na to da li sistemu pristupa jedan ili vie korisnika.

Distribucija - sistem treba biti lak za odravanje. Vreme odziva - vreme za koje korisnik dobija povratnu informaciju. Obim podataka - utie na vreme odziva ukoliko je baza podataka manja, odziv je bri. Rok - podaci moraju biti aurirani pre sledeeg asa Bezbednost - dnevniku mogu pristupiti samo nastavnici kao administratori Prenosivost - dostupan na raznim platformam Dostupnost - dostupan u svakom trenutku sa minimalnom mogunou pada sistema. 52. Prezentacioni sloj elektronskog dnevnika Troslojnu arhitekturu ine: prezentacioni sloj, komunikacioni sloj i sloj podataka. Prezentacioni sloj ima ulogu da omogui interakciju korisnika sa veb prezentacijom, predstavi korisnicki interfejs E-dnevnika... Obuhvata: forma za registraciju forma za prijavljivanje korisnika forma za dodavanje i brisanje uenika i profesora forma za upis ocena forma za dodavanje predmeta forma za evidentiranje izostanaka e-mail usluga za komunikaciju nastavnika i roditelja forma za upis komentara... Prezentacioni sloj sadri objekte korisnikog interfejsa (forme za pregled, unos, izmenu, brisanje podataka). ELEKTRONSKI DNEVNIK - forma za registraciju i prijavljivanje korisnika - forma za dodavanje i brisanje uenika i profesora - forma za upis ocena - forma za dodavanje i brisanje predmeta - forma za evidenciju izostanaka - SMS servis - e-mail usluga - forma u vidu oglasne table (sadri obavetenja) Komunikacioni sloj ima ulogu da povee prezentacioni sloj sa slojem podataka, upravlja strukturom i sadrajem podataka koji se prikazuju korisniku, obradjuje podatke dobijene od korisnika, alje upite ka bazi podataka u E-dnevniku. Korisnicima olakava upotrebu sistema. Obuhvata: zahtevi za registraciju zahtevi za prijavljivanje korisnika zahtevi za unos ocena zahtev za evidentiranje uenika... Sloj podataka ima ulogu da upravlja podacima iz E-dnevnika. Obuhvata: Baza podataka Interfejs za aplikacije Interpretator SQL koda Analizator upita

Modul za pristup podacima 53. Sloj poslovne logike elektronskog dnevnika Srednji sloj povezuje sloj podataka sa prezentacijskim slojem. On u ovom sluaju obradjuje prispele zahteve iz prezentacijskog sloja, a to su: zahtevi za registraciju zahtevi za logovanje u Elektronski dnevnik zahtevi za unos ocena i evidencija uenika korisnik putem prezentacijskog sloja alje zahtev za unos ocena srednji sloj taj zahtev obrauje i povezuje sa odreenim delom BP on preuzima podatke iz baze i njih prosleuje prezentacijskom sloju, koji ih predstavlja u vidu formulara nakon unosa ocene od strane korisnika, ocena se prenosi i skladiti u bazu podataka zahtevi za pregled podataka od strane svih korisnika sistema (ocene, izostanci, napomene) zahtevi za unos novih profila u bazu podataka zahtevi za pregled liste svih profesora i predmeta u koli zahtev za pretragu uenika i predmeta Poseduje kalendar koji podatke iitava iz posebne baze podataka gde su smeteni tekui i predstojei dogaaji (sednice, roditeljski sastanci, neradni dani, ekskurzije itd.), koristei odgovarajui skript. 54. Sloj podataka elektronskog dnevnika Sloj podataka je zaduen za upravljanje podacima, to podrazumeva: -skladitenje -uitavanje -auriranje -zatita podataka -integritet podataka -podrka viem sloju -izrada rezervnih kopija Svi podaci koji su potrebni za funkcionisanje sistema Elektronskog dnevnika moraju biti skladiteni u nekoj bazi podataka, koja e biti izraena u najprikladnijem DBMS-u. A verovatno je za to najprikladniji My-Sql. Preko interfejsa za aplikacije vri se uitavanje i auriranje podataka koji se nalaze u bazi podataka. U bazu podataka je potrebno unositi podtke o uenicima, ocene uenika, izostanke, asove, komentare u vezi asova...Takoe, baza bi trebalo da sadri podatke o roditeljskim sastancima, interesovanja roditelja, kao i mnoge druge podatke... Podaci bi trebalo biti dobro zatieni korienjem odgovarajuih algoritama enkripcije i sistemskim backup-ovanjem. U zavisnosti od dinamike unoenja podataka u bazu, zavisi i vremenski period izmeu vrenja backup-a. Poto se u sistemu elektronskog dnevnika podaci unose svakodnevno, vrenje backup-a bi trebalo biti makar na nedeljnom nivou. To bi trebalo da osigura integritet podataka kao i kontrolu pristupa podacima.