Projektovanje IS Dinamika u UML-u Zaključak Vozač Isporuka Službenik Prodaja Mušterija Službenik zadužen za refundiranje Menadžer Određivanje cijena Pisanje zahtjeva za refundiranje Refundacija Refundacija Na dijagramu vidimo use case dijagram dok je dijagram aktivnosti za korisničku funkciju refundiranje prikazan desno. Napominjem da većina sistema se sastoji od više use case dijagrama. :RefundReq uest [New] :RefundReq uest [Denied] :Refund Request [Approved] Review request Create rejection letter [Missing documentation] [Valid request with documentation] File request Notify customer Create refund check 1
Događaji akcije aktivnosti - Definicije Događaj nema trajanje za njega koristimo kao sinonime termine operacija i poruka. Događaj je zbivanje koje pokreće prelaz stanja. Prelaz ili tranzicija (transition) jeste veza između dva stanja i ukazuje na to da će objekt koji se nalazi u jednom stanju preduzeti neke akcije kada se označeni događaj zbije. Aktivnosti (activity) znači tekuće neatomsko izvršavanje unutar dijagrama stanja. Akcija (action) znači izvršenu atomsku jedinicu koja dovodi do promjena stanja modela ili do vraćanja vrijednosti. Grafički predstavljeno stanje je pravougaonik sa zaobljenim ivicama (gornji dio je naziv a u donjem se navode interne tranzicije, akcije i aktivnosti). Stanja mogu biti anonimna a svako stanje ima jedinstven naziv. Prelaz (tranzicija) crta se kao puna usmjerena linija. Dijagram stanja obuhvata: definisanje stanja sistema; definisanje prelaza (tranzicija) i definisanje složenih stanja. Stanje je period vremena tokom kojeg objekt posmatranja zadovoljava neke uslove, izvršava aktivnosti ili čeka da se desi neki događaj. Primjer aktivnosti Primjer primarnog toka podataka u sistemu za rezervaciju aviokarata bi mogao da ima sljedeće korake: 1. Slučaj upotrebe počinje kada mušterija odabere opciju da vidi informacije o letu; 2. Sistem traži informacije o destinaciji; eventualnoj povratnoj karti i datumima; 3. Korisnik unosi tražene podatke; 4. Sistem pokazuje listu raspoloživih letova sa cijenama (A1: Nema raspoloživih letova ovo je zapravo početak alternativnog toka podataka koji se posebno prikazuje i počinje od ove tačke); 5. Korisnik bira let koji želi da rezerviše; 6. Sistem prikazuje opcije plaćanja za let; 7. Korisnik bira način plaćanja; 8. Sistem pokazuje sumu koju će korisnik platiti; 9. Korisnik potvrđuje iznos; 10. Sistem se raspituje o vrsti kreditne kartice, broju, imenu i datumu isteka; 11. Korisnik unosi tražene podatke vezane za kreditnu karticu; 12. Sistem podnosi zahtjev za kupovinu (A6: Račun nije pronađen; A7: Nedovoljno novčanih sredstava; E1: Sistem obrade kreditne kartice nije dostupan); 13. Sistem rezerviše mjesto za putnika u avionu; 14. Sistem generiše i prikazuje kod za potvrđivanje korisniku; 15. Korisnik potvrđuje prijem koda; 16. Završetak slučaja upotrebe. U ovom slučaju upotrebe identifikovane su neke neregularnosti. One koje su uvedene od strane korisnika su šifrirane sa A i brojem detektovane neregularnosti dok su one unesene od strane sistema označene sa E i rednim brojem (ovo je interna notacija koja ne mora biti poštovana u opštem slučaju). Svaku grešku kreiranu od strane korisnika prati odgovarajući alternativni tok podataka dok svaku grešku indukovanu od strane sistema prati tok greške. 2
Alternativni i tok greške: primjeri A1: Nema dostupnih letova; 1. Sistem ispisuje da nema dostupnog leta sa traženim parametrima; 2. Korisnik potvrđuje da je primio poruku; 3. Tok se vraća u primarni tok korak 2. Tok greške E1: Sistem za obradu kartica nije dostupan; 1. Sistem ispisuje odgovarajuću poruku o grešci; 2. Povratak na korak 2 primarnog toka. Očigledno da u ovakvom relativno složenom sistemu postoji veoma veliki broj alternativnih i tokova greške. Sami protumačite dijagram aktivnost na narednom slajdu!!!! Open Add/Remove passenger Tranzicija može da bude refleksivna (povratna) kada počinje i završava u istom stanju. Scheduled Tentative Reject flight schedule Add/Remove passenger entry/post flight schedule on internet do/check current date [Current day is less than 60 days before flight] Add passanger [Last seat was sold] Open Open Remove passanger [10 minutes before scheduled take off] [10 minutes before scheduled take off] [Plane arrived] Delayed Close Takeoff In Flight 4 hrs after scheduled takeoff time Scheduled takeoff time [Plane not yet arrived] [Fewer than 50 people on flight] Landed Land Canceled do/arrange alternate flight for customers 3
Superstanje Scheduled [Current date is less than 60 days before flight]/set number of passengers to 0 Add passenger[last seat was sold] Open Open Remove passenger(passengername) [10 minutes before scheduled takeoff] Closed U najvećem broju slučajeva superstanje se uvodi samo radi smanjivanja broja linija koje se pojavljuju na dijagramu i ne predstavlja fizički odvojiv dio sistema već samo dio logike sistema koja se može prikazati kao jedna cjelina. Dijagrami aktivnosti else [nagib=l.nagib] x=(l.delta-delta)/(nagin-l.nagib) y=(nagib*x)+delta return Tačka(x,y) return Tačka(0,0) Dijagram aktivnosti iskorišćen za prikaz modelovanja operacije (u ovom slučaju igra ulogu flow chart dijagrama) Događaji i signali Signal, protok vremena i promjena stanja su asinhroni događaji koji se mogu dogoditi u proizvoljnom trenutku. Pozivi su sinhroni događaji koji predstavljaju pozive operacija. Signali se najčešće prikazuju preko stereotipa 4
Događaji i signali SpuštenaSlušalica Slobodan SpuštenaSlušalica/raskini Vezu() Zauzet događaj koji dovodi do promjene iz jednog u drugo stanje Događaji mogu biti spoljašnji (odvijaju se između sistema i izvođača) i unutrašnji (između objekata unutar sistema). Mogu se modelovati četiri vrste događaja: signali, pozivi, protok vremena i promjena stanja. Signal se prikazuje kao objekat kojeg odašilje neki objekat (asinhrono) i prima ga drugi objekat. Događaji i signali Signali su slični klasama (mogu imati atribute i operacije pa i konkretne primjerke ali rijetko), mogu biti uključeni u relacije generalizacije (za modelovanje hijerarhije događaja). Stoga se modeluju kao klase unutar stereotipa. Ako operacija šalje signal treba koristiti stereotip <<send>>. Signal i pozivi - primjeri Sudar forsiraj:uspravno <<send>> KontrolorKretanja položaj brzina pređina() ilustracija slanje signala Ručno pokreniautopilot(normal) Automatski Ključna rjieč after se koristi da naglasi relativan odnos kada se događaj pojavljuje dok ključna riječ when naglašava momenat pojave događaja. 5
Slobodan when(11:49pm)/samiispitaj() after(2 seconds)/raskinivezu() RobotovSignal Zauzet After i when ilustracija Sudar senzor:integer HardverskiKvar KvarBaterije MehaničkiKvar VideoKvar KvarOcjeneRastojanja SlabljenjeMotora ilustracija hijerarhije signala Signali koje jedna klasa može da pošalje se često objedinjuju u okviru aktivne klase. Ilustracija aktivne klase KontrolerNumeričkeTastature Signali pritisnitaster(t:taster) napajanjeuključeno napajanjeisključeno Jedna od primjena signala je prilikom modelovanja izuzetaka. <<exception>> Exception sethandler() firsthandler() lasthandler() Set Item <<exception>> Duplicate <<exception>> Owerflow <<exception>> Underflow add() remove() <<send>> <<send>> <<send>> 6
Konačni automati događaj bez parametra isključi Isključen događaj sa parametrom suvišehladno(željenatemp) natemp natemp suvišetoplo(željenatemp) Hlađenje suvišehladno(željenatemp) Grejanje Pokretanje spreman/uključi() Aktivan Crni kružić početak Zaobljeni pravougaonici stanja Crni koncentrični kružić kraj Stanje sa konačnim automatom unutar ugnježdeno stanje Stanja i tranzicije Stanje može da ima: Ime, Ulazne/izlazne akcije (akcije koje se izvršavaju prilikom ulaska ili izlaska iz stanja), Unutrašnje tranzicije (tranzicije koje ne dovode do primjene stanja), Stanja i tranzicije Stanje dalje imaju Podstanja (ugnježdena struktura stanja koja se mogu obavljati razdvojeno sekvencijalno ili istovremeno paralelno), Odgođeni događaji (spisak događaja koji se ne obavljaju u datom stanju već se obavljaju odgođeno u nekom drugom stanju objekta). Tranzicija se može tretirati kao odnos između dva stanja gdje objekat u prvom stanju izvršava određene akcije i zatim prelazi u neko drugo stanje kada se za to steknu uslovi (npr. nakon nekog događaja). Tranzicija se sastoji od: Izvorišnog stanja, Pobudnog događaja, Zaštitnog uslova (tranzicija se može obaviti samo ako je ovaj zaštitni uslov logički tačan), Akcija (neko izračunavanje koje nije djeljivo - odnosno lokalizovano je npr. u jednom objektu koje može djelovati direktno na taj objekat ali i indirektno na druge objekte koji vide dati objekat) primjer akcije je t.dodajcilj(p) na sljedećem slajdu, Odredišno stanje (stanje koje je aktivno nakon završetka tranzicije). 7
Modelovanje tranzicija after(2 seconds)/ send c.budan šum Neaktivan Pretražuje Angažovanje ciljna(p) [jepretnja]/ t.dodajcilj(p) Praćenje kontakt Angažovanje Napredno modelovanje stanja i tranzicija Praćenje entry/zadajstatus(upraćenje) exit/zadajstatus(vanpraćenja) novicilj/pratilac.preuzmi() do/slijedicilj samokontrola/defer naziv stanja ulazna akcija izlazna akcija unutrašnja tranzicija aktivnost odgođeni događaj Primjer složenog stanja Display Available Flights Primjeri tranzicija entry/find all flights for second cities/dates entry/determine flights with available seats do/display list of flights with available seats do/highlight flight with lowest fare event/user requests fare information/display fare information Reserve seat Reserve seat Generate confirmation number Cancel Generate confirmation number Refund credit purchase Cancel reservatio n [Invalid account, insufficient funds, credit system not available] Reserve seat Display fare Edit credit information Generate confirmation number [Approved] Generate and e-mail receipt Reserve seat [New reservation] Generate information number Generalizacija Zaposleni aktera Display confirmation number Honorarno zaposleni Stalno zaposleni Privremeno zaposleni 8
Napredne opcije stanja i tranzicija Ključne riječi entry, exit i do označavaju redom ulaznu i izlaznu akciju i aktivnost. Za napredno modelovanje stanja koriste se podstanja. Postoje tri tipa podstanja: sekvencijalna (izvršavaju se redom), istorijska (pamte prethodna stanja) i istovremena (izvršavaju se paralelno). Sekvencijalna podstanja održavaj Slobodan Održavanje umetnuta kartica odustani Aktivan Provjera [nastavi] Obrada Izbor entry/čitajkarticu exit/izbacikarticu [ne nastavi] Štampanje Istorijska podstanja Komandovanje upit Pravljenje rezerve H Sakupljanje H predstavlja plitko istorijsko podstanje (pamti jedan korak unazad) Kopiranje Čišćenje H * predstavlja duboko istorijsko podstanje (pamti više koraka unazad) održavaj Održavanje Istovremena podstanja Održavanje Ispitivanje Komandovanje Ispitni uređaji Čekanje pritisaktastera [nastavi] Autodijagnostika Komandno [ne nastavi] 9
Primjeri stanja za vježbu Za vježbu definišite primjere konkretnih stanja koja bi se mogla uklopiti u navedene dijagrame: Stanje 1 Interna tranzicija tranzicija Stanje 2 Interna tranzicija Stanje 1 intrerna tranzicija DOGAĐAJ (argument 1) [uslov 1]/akcija 1 Stanje 2 intrerna tranzicija Stanje 1 do/izraz aktivnosti entry/izraz akcije exit/izraz akcije Pocetak Kraj Stanje 1 do/izraz aktivnosti entry/izraz akcije exit/izraz akcije DOGADJAJ 1 [argument 1] [uslov 1]/akcija 1 DOGADJAJ 2 [argument 2] [uslov 2]/akcija 2 Stanje 2 do/aktivnost 2 Stanje 3 do/aktivnost 3 Stanje A Poruka/Operacija Poruka/Operacija Stanje B1 entry/ akcije do/ aktivnost Stanje B Poruka Poruka Stanje B2 Stanje B3 Nastavak vježbe sa prethodnog slajda Superstanje Konkurentsko stanje Stanje 1 Stanje 2 A Stanje 3 Konkurentsko stanje B 10
Aktivne klase UML modeluje svako nezavisno odvijanje upravljanja kao aktivan objekat. Aktivni objekti su primjerci aktivnih klasa i mogu da započnu upravljačku aktivnost. Međusobno komuniciraju preko poruka ali te poruke ovdje moraju biti proširene semantikom istovremenosti. UML posjeduje koncept aktivne klase kao i većina OO jezika a u okviru ovakve klase navode se i svi signali koje klasa može da generiše. KontrolerTable aktivna klasa sa tekućiizvorznanja signalima koje generiše Signali tablajerješena postojiuputstvo Procesi i niti Započinjanje upravljačke aktivnosti se generiše preko procesa i niti. Procesi i niti se mogu izvršavati istovremeno sa ostalim procesima u sistemu. Prikazuju se kao stereotipi aktivnih klasa. Ovdje može da postoji više tokova upravljanja. Procesi i niti se označavaju sa stereotipima: process i thread. Proces je tok teške kategorije koji je poznat samo operativnom sistemu i izvršava se u nezavisnom adresnom prostoru. Niti su laka kategorija koja se izvršava unutar procesa u njihovom adresnom prostoru. Sve niti unutar adresnog prostora (i na istom procesor) konkurišu za iste resurse. Procesi i niti Interakcije među objektima Objekti međusobno razmjenjuju poruke. Tipovi poruka: Od jednog ka drugom pasivnom objektu (poziv neke operacije). Između dva aktivna objekta (komunikacija). Stilovi komunikacije su: Objekat pošalje poruku i sačeka rezultat (u pitanju je sinhroni poziv koji se naziva i randevuom). Tokom randevua objekti ne mogu da rade ništa drugo (lock-step). Aktivni objekat pozove drugi i nastavi da radi do momenta kada drugi završi operaciju i kada ga obavjesti o rezultatu (u pitanju je asinhroni poziv i tip komunikacije preko mail-boxova). 11
Interakcije među objektima Sinhroni pozivi se prikazuju pomoću strelice a asinhroni preko polustrelica. Tipične primjene procesa i niti su za modelovanje više istovremenih tokova upravljanja i za modelovanje međuprocesorske komunikacije. Komunikacija među aktivnim objektima Primjer k1:aktiviraj t: Tabla k:kontrolertable 1:postojiUputstvo(z) 2:prikažiMeđuRješenje() k2:počnitraženje() k3:saopšti() :IzvorZnanja :IzvorZnanja Redosljed identifikacije klasa Važan elemenat kojega treba razmotriti je redosljed koraka u proceduri kreiranja IS i/ili softverske realizacije. Postoje dva pristupa u redosljedu kreiranja softverske realizacije. Jedan je da se krene od korisničkih funkcija i slučajeva korišćenja, preko dijagrama interakcije, dijagrama aktivnosti i da se kroz te korake identifikuju klase koje su potrebne u sistemu. Druga skupina polazi od klasa pa zatim kada kreira klase prolazi kroz ostale djelove sistema. Oba pristupa imaju prednosti i mane. Kod prvog lakše se identifikuju koraci u nekoj realizaciji i postoji mogućnost da ti koraci daju veoma kvalitetnu osnovu za buduće klase. Druga metodologija je bliža programerima i dobra je sa stanovišta rane implementacije komunikacije između pojedinih djelova sistema. Sa našeg stanovišta prva metodologija je znatno bolja jer daje odličnu teorijsku osnovu za realizaciju sistema. Postoji opasnost da se odlično izanaliziran sistem ne može realizovati jer su neki programerski problemi zanemareni. Dijagram klasa ove probleme veoma brzo identifikuje. 12
Modelovanje vremena i prostora Tokom rada neki elementi u sistemu se mogu pomjerati čak i fizički. Prikazuje se u obliku čvora ili pomoću naznačene vrijednosti za stereotipom location. <<processor>> KioskServer Obuhvata vision.exe log.exe samokontrola.exe :NadzorOpterećenosti {location=router} Primjer modelovanja Modelovanje sistema sa osvježavanjem sa prijemom video signala. {a.periodičnozapočinjanje svake 1ms} s:agentisistema s:serverstanice k:kamere a:osvježi() b:dajsliku() {dajsliku.vrijemeizvršavanja srazmjerno veličini slike} {a.vrijemeizvršavanja<100ns} Modelovanje vremena i prostora - Primjer n:narudžbine {location=radnastanica} p:prodaja {location=radnastanica} Modelovanje raspodjele objekata a:nadzorniagent {location=server} Dijagram stanja čekanje p:proizvod {location=server} t:tabelaproizvoda {location=centralnostovarištepodataka} unesi(k)[k=='<'] unesi(k)[k==';'] /return true unesi(k)[k/='<'] /return false PrijemNaznake unesi(k)[k/='>'] /naznaka.append(k); return false unesi(k)[k=='>'] PrijemTijela unesi(k)[k/=';'] /tijelo.append(k); return false 13
Društva saradnika Do sada smo se upoznali samo sa činjenicom da unutar društva saradnika se nalaze klase koje rade na istim problemima. Jasno je da ove klase mogu biti u složenim odnosima koji se mogu vizuelizovati na različite načine. Po pravilu se prikazuju barem dva dijagrama: jedan statički i jedan dinamički. Od statičkih se obično prikazuje dijagram klasa. Kod dinamičkih prikaz postoji više mogućnosti. Modelovanje jednog društva saradnika je prikazano u skripti kroz nekoliko dijagrama. Šabloni i strukturni okviri Prilikom modelovanja nekog sistema često se ponavljaju slična rješenja koja se mogu primjeniti na različite probleme. Ponavljanje rješenja sugeriše da je sistem dobro dizajniran. Ova dobra rješenja se pogodno prikazuju preko šablona i strukturnih okvira. Šabloni i strukturni okviri Šablonska rješenja koja se mogu realizovati društvom saradnika se nazivaju šablonima dok se šablonizovani djelovi arhitekture sistema nazivaju strukturni okviri. Grafička predstava oba tipa je ista i predstavlja vizuelnu modifikaciju paketa. <<framework>> Prihodi Naplata Poravnanja Prikazi šablona i strukturnih okvira Na najvišem nivou apstrakcije šablona i strukturnih okvira oni se prikazuju šematski. Projektni i arhitektonski šabloni se po pravilu vizuelizuju na različite načine. Na nižim nivoima apstrakcije potrebno je naglasiti pojedine aspekte korišćenja šablona: Strukturni aspekti se naglašavaju preko dijagrama klasa; Dinamički aspekti se modeluju preko dijagrama interakcija ili na neki drugi pogodan način. 14
Prikaz modela sistema i veza sa podsistemima <<sistem>> Sistem Maloprodajnog preduzeća <<podsistem>> Podsistem za Zahtjeve Kupaca <<podsistem>> Podsistem za Upravljanje Zalihama <<podsistem>> Podsistem za Upravljanje Robnim Kućama Vođenje Trgovine Vizija Smjernica Grafički prikaz razvoja modela <<trace>> Vođenje Trgovine {version=7.1} <<trace>> Vođenje Trgovine {version=7.2} Umjesto zaključka Vidjeli smo dio kompleksnosti koja postoji kod rada sa informacionim sistemom. Vidjeli smo da za mnoga rješenja ne postoji čarobni štapić. Vidjeli smo da se mnoge stvari mogu uraditi na više načina i da postoji pitanje optimalnosti. Vidjeli smo da je najvažnije pitanje napraviti dobar IS i to tako da su njegova proširenja jednostavna. Ostalo je da komentarišemo nekoliko dodatnih pitanja. Što je starije klasa ili podsistem? Mi smo rekli da treba prvo globalno izdijeliti sistem na podsisteme i rasporediti resurse a zatim preći na automatizaciju pojedinih djelova. Međutim, već na tom nivou treba se dogovoriti kako će izgledati baze podataka a to teško da možemo uraditi bez poznavanja klasa. Zaključak treba prvo odrediti klase. Došli smo do suprotnosti od onoga što smo pretpostavili na početku i mogli bi i dalje da se vrtimo u starom dobrom pitanju tipa što je starije kokoška ili jaje. 15
UML i veze sa drugim tehnologijama UML ima mnogo dodirnih tačaka sa BSP metodologijom. I u objektno orjentisanim metodologijama poslovni procesi odnosno model poslovnih procesa su osnova za kreiranje ISa. Modelovanje poslovnih procesa se može shvatiti kao modelovanje same organizacije kroz koje se može izučiti kako unutrašnja struktura organizacije tako i način na koji organizacija intereaguje sa okolinom. Podsjetimo se da smo smatrali da je sistem koji je modelovan na osnovu poslovnih procesa veoma stabilan odnosno da poslovni procesi ostaju relativno malo promijenjeni tokom životnog vijeka organizacije. Sistem modelovan na osnovu poslovnih procesa ima šanse da bez velikih revizija preživi nekoliko nadogradnji ISa. Pored ovoga postoje i drugi razlozi za modelovanje sistema preko modelovanja poslovnih procesa: razumijevanje vizije organizacije (da omogući svim djelovima tima da shvate važne detalje organizacije; ponekad je ovo važno čak i za korisnike sistema koji koriste samo djelove); reinžinjering poslovnih procesa (dijagram toka podataka koji su od ključne važnosti može se relativno lako generisati iz opisanih modela); vježbanje (ovi dijagrami mogu da posluže za uvježbavanje djelova projektanskog tima); UML i modelovanje poslovnih procesa dodatak softverskom rješenju (jednostavnije je ponekad shvatiti predloženo rješenje na osnovu dijagrama nego na osnovu koda programa pa čak i kada se ne vrši modelovanje prije kodiranja nije loše napraviti nakon završenog posla model). Poslovne procese: moraju modelovati početnici, zatim se uvijek moraju modelovati ako je organizacija modifikovala neke od poslovnih procesa ili to planira da učini, ako se radi softver od značaja za veći dio kompanije, ako u organizaciji postoje veliki i kompleksni poslovni procesi koji nijesu dobro dokumentovani, ako organizacija vrši konsultantske usluge u formi sa kojom prethodno nije imala kontakt. Modelovanje poslovnih procesa se ne mora vršiti u sljedećim situacijama: ako se struktura, ciljevi, poslovna vizija i nosioci određenih procesa dobro poznaju; ako se vrši izrada softvera za potrebe manjeg dijela organizacije koji nema uticaj na poslovanje ostatka firme; ako su tokovi poslovnih procesa jasni i dobro dokumentovani, ako za potrebnu analizu nema dovoljno vremena (nedostatak vremena ne treba da bude opravdanje uvijek je bolje pokušati dobiti malo više vremena za ovu analizu nego unaprijed od nje odustati). 16
Klase i podsistemi Ako sistem već postoji i ako su podsistemim već definisani i ako ne pravimo prevelike promjene problem je riješen jer imamo podsisteme i treba da odredimo nove ili modifikujemo stare klase u pojedinim podsistemima uz manji ili veći problem u komunikaciji sa djelovima tima koji rade na implementaciji pojedinih podsistema. Veći je problem kod pisanja novog programskog projekta, kreiranju novog ISa od početka i u slučaju kada se prave velike prepravke sistema. Jedino ispravno je ipak dizajnirati na početku klase na osnovu BSP ili neke slične metodologije (na osnovu poslovnih procesa i poslovnih entiteta). Nakon početnog dizajna klasa vrši se reorganizacija polaznog sistema klasa uz recimo metodologiju koja izbacuje sinonime i provjerava odgovornosti pojedinih klasa. Ostale klase u sistemu jedino možemo identifikovati kroz scenarije i analizu korišćenja sistema. Zatim se eventualno opredjeljujemo za rooted ili non-rooted arhitekturu kod nasljeđivanja i vrši nasljeđivanje. Zatim bi se prešlo na određivanje prijatelja i društava saradnika. Klase i podsistemi Sadržaj dobijenog sistema klasa možemo prikazati recimo preko klasnog dijagrama a ponašanja preko dijagrama stanja, interakcija i aktivnosti. Zatim treba odrediti i podsisteme recimo na osnovu metodologije koja povezuje klase podataka i poslovne podsisteme. Postoji veliki problem u ovoj metodologiji a to je da se otegne vrijeme dizajna klasa i da u trenutku kontrole realizacije vašeg sistema nemate gotovo ništa od sistema realizovano već ste samo u analizi. Iako dobro napravljena analiza se brzo isplati u smislu brzog pisanja koda i implementacije sistema može da se dogodi da izgubite posao kada poslodavcima nemate što da pokažete od vašeg sistema osim nacrta i dijagrama. Kako je tržište jedino mjerilo rada tu treba biti oprezan. Ako ste izbjegli ovaj problem možete izvršiti dizajn softverskih komponenti koje su potrebne kao i hardvera koji je potreban i izvršiti vizuelizaciju ovih djelova preko dijagrama komponenti i dijagrama raspoređenosti. Pored UML postoje novi razvojni alati koji se mogu koristiti za dizajn hardverskih a posebno mrežnih komponenti do dizajna servera i prava pristupa. Ovi alati su danas vlasništvo manjih firmi i tek su u razvoju. 17
Rad u podsistemima Hardverske i softverske komponente sistema mogu da dovedu do određenih ograničenja u implementaciji. Rad u podsistemu će otkriti određene probleme u inicijalnom dizajnu i po potrebi zahtjevati modifikaciju postojećih ili uvođenje novih klasa. Modifikacija inicijalnih klasa u smislu promjena u podacima članovima znači promjenu ili provjeru svih operacija u toj klasi kao i u prijateljskim klasama. Dodavanje nove operacije u klasi je veoma jednostavno. Veći problem je ako se ispostavi da trebaju drugačije veze te klase i drugih u sistemu. Dodavanje nove klase koja će se koristiti u podsistemu je mali problem. Sve promjene koje jedna grupa izvrši u klasama važnim za čitav sistem trebaju biti dokumentovane i dogovorene sa ostalim grupama. Danas često se odvojeno projektuju: korisnički interfejs, dio za obradu podataka i baze podataka (neki kažu da je ovakva strategija loša). Dobro je ako se ovi djelovi mogu relativno nezavisno projektovati jer se za njihov dizajn mogu angažovati različiti timovi koji će raditi paralelno. Takođe, ovo podrazumjeva da će ekipe moći da primjene neka od već razvijenih standardnih rješenja. OO razvoj IS - razlike u odnosu na klasični OO metodologija i UML dovode do određenih promjena u proceduri projektovanja IS. Te promjene se najviše odnose na redosljed određenih koraka. Prvo se provodi logičko i fizičko modeliranje. Kod logičkog modeliranja nema izmjena već i dalje treba da dođemo do primitivnih funkcija (procesa), tokova podataka i skladišta podataka. Kod fizičkog modeliranja postoje izmjene koje zavise od nivoa poznavanja sistema koji se obrađuje i od toga što se koriste OO metodologije. Ako se polazi od manje poznatog sistema onda se sistem analizira polazivši od dinamike a to znači da treba prvo definisati: Slučajeve upotrebe (a prije toga aktere) Dijagrame aktivnosti (a prije toga učesnike kojima će biti dodijeljene odgovornosti u dijagramima) Dijagrame stanja i tranzicije Sama OO analiza sistema ponovo se relativno malo razlikuje u odnosu na klasičnu se relativno malo razlikuje osim mnogo više mogućnosti u definisanju nasljeđivanja. Druga bitna stvar je definisanje odgovornosti i kros-validacija dizajna kroz provjeru da li je skup odgovornosti/klasa odgovarajući. Dakle, statika OO sistema u dizajnu se ne razlikuje puno od klasičnog u slučaju statike dok su krupne promjene vezane za dinamiku. Prosto imamo mnogo više alata na raspolaganju: aktivnosti, interakcije (moramo definisati poruke koje se razmjenjuju i tipove sinhronizacije među objektima, kao i korespodenciju metoda sa operacijama koje sistem vrši i reflektovanja toga na same objekte). 18
OO razvoj - razlike u dizajnu Faza dizajna se u OO metodologiji bitno razlikuje od faze dizajna u klasičnim metodologijama jer postoji znatno više alata i mogućnosti za opis dinamike sistema te za povezivanje dinamike sa statikom. Četiri su osnovna elementa u dizajnu koja možemo (ili moramo implementirati): Kolaboracije; Detaljne klase i klasni dijagrami; Dijagrami stanja i analize scenarija; Definisanje paketa i eventualno definisanje projektnih mustri i šablona. Jasno je da se OO metodologija ona koja može da ispuni navedene zahtjeve a da UML posjeduje sve navedene koncepte i niz drugih. Kupovima komponenti ili pisanje novih Brzina pisanja koda i cijena kupljenog softvera su elementi koji određuju ovu odluku. Takođe, programeri koji su na raspolaganju i njihov kvalitet su faktori za odluku. U pojedinim sistemima želite da imate source code svih djelova softvera i ne želite da prepravke zavise od drugih. To je onda dominanti faktor za odluku. Prilikom odlučivanja ne treba odbaciti nijednu mogućnost. Z A K LJ U Č A K Dobra analiza prethodi implementaciji i pisanju koda!!! Dobra analiza se brzo isplati u smislu brze implementacije sistema!!! 19