UML Informacione tehnologije UML PROGRAM I CILJEVI KURSA

UML Informacione tehnologije

UML PROGRAM I CILJEVI KURSA

SADRŽAJ KURSA 1. 2. 3. 4. 5. 6. UVOD U MODELIRANJE FAZE RAZVOJA SOFTVERA UML – SINTAKSA I SEMANTIKA KREIRANJE UML MODELA UML I J 2 EE RUP I DRUGE METODOLOGIJE PROJEKTOVANJA SOFTVERA

CILJEVI KURSA Naučiti osnove projektovanja softvera 2. Naučiti osnovna pravila i primenu UMLa 3. Naučiti osnovne veze UML i J 2 EE 1.

Šta je UML? Unified Modeling Language je jezik za specifikaciju, konstrukciju, vizuelizaciju i dokumentovanje softverskih proizvoda l uključuje principe Booch, OMT i OSE l korišćenjem UML autori nastoje da obezbede primenu modeliranja u oblastima simultanih i distribuiranih sistema l UML se ne zasniva ni na jednom programskom jeziku za razvoj objektno orijentisanih sistema, već u sebi sadrži opšti model dizajna l

Šta se postiže modeliranjem? l modeli pomažu da se sistem vizuelizuje onakav kakav je ili kakav bi trebalo da bude l modeli omogućuju da se odredi struktura ili ponašanje sistema l modeli daju uzorke koji nas vode prilikom konstrukcije sistema l modeli dokumentuju odluke koje smo donosili

Dva osnovna načina izrade modela l konvencionalni pristup l objektno orijentisan pristup

Nedostaci konvencionalnog pristupa l mala modularnost sistema l statički koncept modela podataka l nesaglasnost jezika baze podataka i programskih jezika l razvoj sistema u jednom prolazu

Prednosti objektno orijentisanog pristupa l objekti se mogu koristiti više puta l nezavisno testiranje objekata l lakši timski rad l razvoj objekata koji su nezavisni od mašine na kojoj rade l velika prilagodljivost na promene

Proces razvoja softvera l use case driven proces l orijentisan ka arhitekturi l iterativan i inkrementalan l usmeren na postizanje kvaliteta (quality assurance) i eliminaciju rizika

Iterativni razvojni proces l kontinuirana integracija l frekventno izvršenje realizacije l smanjenje rizika kroz stalno testiranje

4 FAZE U ŽIVOTNOM CIKLUSU SOFTVERA l početak l elaboracija l konstrukcija l tranzicija

OBJEKTNO ORIJENTISAN RAZVOJ INFORMACIONOG SISTEMA SE IZVODI KROZ ČETIRI PROCESA: l definisanje zahteva l objektno orijentisana analiza l objektno orijentisano projektovanje l implementacija

DEFINISANJE ZAHTEVA l izrada logičkog modela funkcija (definišu se granice posmatranog sistema) l izrada fizičkog modela poslovnih procesa (definiše se dinamika, odnosno način odvijanja posla, gde se poslovni procesi dekomponuju do nivoa primitivnih procesa)

Izgled use case dijagrama (1) Use-Case Model of the Order System Manage Order The use-case model specifies the behavior and surroundings of the system in terms of use cases and actors. The description of an actor or use case is found in its specification, which is displayed when double-clicking on the actor or use case. The documentation field on the General tab, is displayed in the application window when you select and actor or use case. (If not, click Documentation on the View menu. ) Order Administrator Manage Customer Register Manage Articles Store Administrator Execute Order Instead of describing the flow of events of a use case in the documentation field of its specification, an external document with the description can be connected to the use case. That can be done on the Files tab in the Use-Case Specification or by dragging the file from the Windows Explorer and dropping it on the use case in the Browser. The use cases constitute the functional requirements on the system. They also define how the requirements are distributed among the design objects of the system, i. , e. how the objects interact to perform each use case. In the Browser you can see that the Manage Order use case is described in two interaction diagrams of the type sequence diagram.

Izgled use case dijagrama (2)

OBJEKTNO ORIJENTISANA ANALIZA l razmatra objekte sadržane u realnom sistemu, kao i načine njihove međusobne saradnje l najkritičnija faza u kojoj treba odrediti koji se sve objekti pojavljuju u realnom sistemu l proces ispitivanja korisničkih zahteva radi njihovog definisanja na osnovu čega se pristupa OOP

OBJEKTNO ORIJENTISANA ANALIZA Ovaj proces se definiše kao: l izrada konceptualnog modela l izrada dijagrama sekvenci l definisanje ugovora o izvršenju operacije

l Izrada konceptualnog modela treba da definiše dijagram klasa bez definisanih operacija za ciljne koncepte u domenu posmatranja. Definišu se koncepti, odgovarajući atributi i potrebne asocijacije između koncepata. Odgovara klasičnom modeluobjekti veze. Definiše se lista kandidata korišćenjem liste kategorije koncepta i identifikacijom imenica iz fraza, potom se kreira konceptualni model, dodaju atributi i odgovarajuće asocijacije. Identifikuju se uloge ljudi i bitnih stvari angažovanih u procesima.

l Izrada dijagrama sekvenci pokazuje za svaki slučaj upotrebe događaje koje generiše spoljni učesnik i njihov redosled. Prikazuje dinamičku saradnju između objekata u vremenu. Ovom aktivnošću se opisuje šta sistem radi, a ne kako radi l Definisanje ugovora o izvršenju operacije daje opis logike

Izgled dijagrama sekvenci (1) Order Administrator 1: dlg_Order : dlg_Order Active Order : Order Active Customer : Customer 2: 3: Fetch (Integer) Restores the customer from the customer database. 4: Purchaser (customer) 5: Steps 5 -8 are repeated as multiple order rows are added to the active order. 6: Create () 7: Add. Order. Row (Order. Row) 8: Sum () 9: Register the order and store the order in the order database. 10: Register () The subsequent flow is described in the Create Order Row sequence diagram. New Row : Order. Row

Izgled dijagrama sekvenci (2)

OBJEKTNO ORIJENTISANO PROJEKTOVANJE treba da omogući definisanje logike softverskih objekata (koji imaju atribute i operacije) koji će se u sledećoj fazi implementirati pomoću objektno orijentisanih jezika l treba odrediti kako se procesi izvršavaju tj. treba dati odgovor na pitanje ko šta radi i kakva je saradnja (što zahteva dodeljivanje poslova i odgovornosti različitim softverskim objektima za izradu buduće aplikacije) l

l dodaju se nove klase koje ne predstavljaju ključne apstrakcije već su deo implementacije mehanizama l dodaju se novi atributi i operacije potrebne za realizaciju mehanizama i ključnih apstrakcija l dodaju se relacije između klasa potrebne za implementaciju

U objektno orijentisanom projektovanju se precizno specifiraju: l klase koje postoje u sistemu i definišu njihovi međusobni odnosi l identifikuju svi mehanizmi koji se koriste u interakciji objekata l definiše gde se u programima deklarišu pojedine klase i objekti

Ovaj proces se definiše preko sledećih aktivnosti: l izrada dijagrama saradnje l kreiranje potpunih dijagrama klasa l izrada dijagrama stanja l definisanje paketa, saradnje mustri (pattern design) i aplikativnih kostura

Izrada dijagrama saradnje koristi se za detaljnu specifikaiju svake operacije sistema l objektno orijentisano projektovanje daje specifikacije logike softvera koji će ispuniti funkcionalne zahteve bazirane na dekompoziciji po klasama ili objektima l korišćenjem ovih dijagrama treba locirati odgovornosti na objekte i odrediti kako oni deluju preko poruka i to prikazati u grafičkom ili mrežnom formatu l

Izgled dijagrama saradnje

Kreiranje potpunih dijagrama klasa definiše potpun dijagram klasa sa detaljno specificiranim atributima, asocijama i dodatim operacijama i njihovim opisom l najvažniji i najviše korišćeni UML dijagram i predstavlja tatičku strukturu sistema l dijagram klasa u obliku konceptualnog modela se koristi u OOA, gde se definiše šta sistem treba da radi, i u OOP, gde se definiše kako sistem radi l

l dijagram klasa treba da odgovori na pitanje kako su objekti povezani i šta su to operacije klase odgovor na ovo pitanje daje dijagram saradnje, koji sugeriše neophodne veze između objekata i operacija koje svaka klasa mora da ima l treba naglasiti da nasuprot konceptualnom modelu, dijagram klasa ne ilustruje koncept realnog sveta, već opisuje buduće softverske komponente

Izrada dijagrama stanja l vezana je samo za jedan objekat i operaciju unutar njega za određenu klasu l način za opisivanje složene operacije klase l prikazuje se sekvenca stanja kroz koje objekat prolazi tokom vremena, a kao reakcija na spoljašnje i unutrašnje pobude l dijagrami stanja se koriste i za opis logike jednog slučaja upotrebe

Definisanje paketa, saradnje mustri i aplikativnih kostura definišu se paketi koji se koriste da bi se elementi za modeliranje organizovali u veće celine kojima će se manipulisati kao sa nekom grupom l saradnja prestvlja konceptualni skup elemenata i njihove interakcije a mustra neko opšte rešenje za opšti problem l aplikativni kostur ocrtava celokupnu arhitekturu zasnovanu na složenim mustrama kojima se definiše neka opšta aplikacija u posmatranoj oblasti l

IMPLEMENTACIJA l koristi objektno orijentisano programiranje tj. jezike tipa C++, Java, VB i dr. za projektovanje komponenata l u ovoj fazi se pristupa izradi baze podataka, izradi aplikacije, kao i prevođenju i testiranju l podrazumeva kodiranje u ciljnom programskom jeziku

Osnovne aktivnosti u implementaciji su: l izrada aplikacije l definisanje tehnologije, aplikativne i mrežne arhitekture l testiranje l uvođenje l održavanje

l Aktivnost Izrada aplikacije sadrži sledeće podaktivnosti: l 1. Izrada baze podataka podrazumeva tri podaktivnosti: dizajna baze podataka, kreiranje fizičkog modela baze podataka i generisanje baze podataka Dizajn baze podataka je postupak prevođenja logičkog modela podataka u fizički dizajn za implementaciju. Uzima u obzir veličine podataka, bezbednost, zahteve za arhiviranje i backup-recovery

Kreiranje fizičkog modela baze podataka koristi se za analizu fizičke baze podataka, kao i za dizajn i razumevanje kompleksnosti relacione baze podataka. Ovaj model prevodi persistentni logički (objektni) model u fizički model koji je orijentisan relacionim bazama podataka. Fizički model baze podataka koristi se za kreiranje šeme baze podataka Generisanje baze podataka se izvodi korišćenjem jezika za definisanje podataka – Data Definition Language (DDL) za relacione baze podataka ili Program Specification Block (PSB) i Database Definition (DBD) za IMS, generisanje izvršivih baza podataka

l 2. Izrada korisničkog interfejsa treba da obezbedi konzistentan, fleksibilan interfejs koji ispunjava korisničke zahteve i organizacione standarde. Kako je korisnički interfejs “aplikacija” za krajnjeg korisnika, veoma je važno da interfejs bude lak za korišćenje, da bude fleksibilan i da reflektuje stil rada korisnika l 3. Mapiranje, programiranje i prevođenje je proces razvoja specifičnih logičkih izraza unutar modula koji će omogućiti kreiranje programa spremnih za kompajliranje generatorom ili ručno

Definisanje tehnologije, aplikativne i mrežne arhitekture podrazumeva, primenu kompozitnih i generativnih tehnologija sa jedne strane i primenu višeslojne arhitekture i, u vezi sa tim, primenu implementacionih dijagrama razvoja i dijagrama razmeštaja sa druge strane l Testiranje podrazumeva izolovano i integralno testiranje realizovanih funkcionalnih tačaka i njihovih delova. Potrebno je omogućiti ocenjivanje valjanosti programa, tj. testiraju se performanse programa i obavljaju korekcije programa da bi se njegove performanse prilagodile korisniku l

l Uvođenje se izvodi počev od instaliranja preko vrednovanja softvera do izrade korisničkih uputstava i plana obuke l Održavanje je proces pravljenja zahteva za promene na aplikaciji kada je ona već implementirana. Sadrži praćenje rada softvera, ispravljanje grešaka, poboljšanje sistema i dodavanje novih funkcija i izmenu hardvera i softvera