Metodologija razvoja softvera Dizajn softverskih Sistema Predmetni nastavnik

Metodologija razvoja softvera Dizajn softverskih Sistema Predmetni nastavnik: Prof. dr Branko Perišić

Specifikacija dizajna - 1 PREDSTAVLJA KORAK U KOME SE ANALIZA ZAHTEVA PREVODI U ARHITEKTURU SISTEMA KOJI JE PREDMET PROJEKTOVANJA IDENTIFIKACIJA OSNOVNIH MODULA SPECIFIKACIJA FORMATA DEFINISANJE KOMUNIKACIONIH PUTEVA ZA PRENOS PODATAKA IZMEĐU MODULA DEFINISANJE UNUTRAŠNJE STRUKTURE POJEDINAČNIH MODULA DEFINICIJA STRUKTURE PODATAKA

Specifikacija dizajna - 2 SPECIFIKACIJA ZAHTEVA (SPECIFIKACIONI DOKUMENT) DEKOMPOZICIJA ILI KOMPOZICIJA SPECIFIKACIJA DIZAJNA (DESIGN SPECIFICATION) MODELING-IN_THE_LARGE IMPLEMENTACIJA (MODELING-IN-THESMALL)

Aspekti dizajna softverskih sistema - 1 • Linija razdvajanja ANALIZE i DIZAJNA softverskih sistema, u opštem slučaju, nije jasno definisana. • Termin dizajn ponekad na prvi pogled ima dvosmisleno značenje. Ako ga posmatramo kao glagol (dizajnirati) tada ga tumačimo kao kreativni proces transformacije problema u rešenje. Ako ga posmatramo kao imenicu (dizajn) tada ga tumačimo kao formalni opis rešenja. • Kada je softver u pitanju dizajn se iskazuje formalizmima implementacione hardversko/softverske platforme. implementacione hardversko/softverske

Aspekti dizajna softverskih sistema - 2 • Konceptualni (sistemski) dizajn – precizna specifikacija iz koje korisnik nedvosmisleno i jednoznačno dobija informaciju o tome šta će da radi softver • Tehnički dizajn – omogućava projektantima i programerima razumevanje stvarno potrebnog hardvera i softvera za rešavanje problema. • Arhitektonski dizajn – bavi se izborom strategije rešavanja i modularizacijom sistema. • Detaljni dizajn – bavi se formulacijom detaljnih algoritama i strukture podataka neophodne za implementaciju modula.

Arhitektonski dizajn - 1 Strategija – Distribuirana/Centralizovana arhitektura Strategija 1. Klijent/Serve arhitektura – omogućava modeliranje svojstava proizvoljne distribuirane arhitekture. (klient, server) 2. Troslojna arhitektura – (klient, aplikacioni sloj, server) (BCE-Boundary-Control-Entity) 3. Agentska arhitektura – mobilni agenti (JBeans) Agentska arhitektura

Arhitektonski dizajn - 2 Dekompozicija i modularnost Karakteristika složenih sistema je postojanje unutrašnje složenih strukture do koje se dolazi dekompozicijom. • Karakteristika rešenja je postojanje jasno definisanih celina (modula) koji kooperiraju u cilju implementacije funkcija sistema.

Arhitektonski dizajn - 3 1. Dekompozicija bazirana na modulima: • U sklopu ovog pristupa konstrukcija se bazira na alokaciju funkcija komponentama počevši od najvišeg nivoa apstrakcije pa do elemantarne (atomičke) funkcionalnosti. 2. Dekompozicija bazirana na podacima: • U sklopu ovog pristupa dizajn se rukovodi spoljašnjom strukturom podataka. Najviši nivo apstrakcije obuhvata generalnu strukturu podataka dok najniži nivoi opisuju elemente podataka.

Arhitektonski dizajn - 4 3. Dekompozicija bazirana na događajima događaje i rukovanje događajima odnosno način na koji događaju menjaju stanje sistema. U sklopu ovog pristupa akcenat se stavlja na 4. Dekompozicija bazirana na odnosu ULAZ/IZLAZ: U sklopu ovog pristupa akcenat se stavlja na ulaze i izlaze sistema (sistem se posmatra kao crna kutija). 5. Dekompozicija bazirana na objektima U sklopu ovog pristupa akcenat se stavlja na objekte sa kojima sistem radi, njihove apstrakcije (klase) i veze među njima.

Arhitektonski dizajn - 5 • Bez obzira na pristup bilo koja vrsta dekompozicije razdvaja dizajn na delove koji se obično nazivaju moduli ili moduli komponente • Za sistem kažemo da je modularan ako se svaka aktivnost u sistemu odvija uz podršku samo jedne komponente sa jasno definisanim ulazima i izlazima • Za komponentu kažemo da je dobro definisana ako i samo ako su svi njeni ulazi esencijalni sa aspekta funkcionalnosti koju podržava a podržava svi njeni izlazi posledica neke od njenih (privatnih) akcija.

Karakteristike kvalitetnog dizajna 1. NEZAVISNOST KOMPONENTI (Component Independency) 2. IDENTIFIKACIJA I RUKOVANJE IZUZECIMA (exception identification and IZUZECIMA handling) 3. OTPORNOST NA GREŠKE I RUKOVANJE GREŠKAMA (Error RUKOVANJE GREŠKAMA handling) 4. SMANJENJE SLOŽENOSTI (Reduction SMANJENJE SLOŽENOSTI of complexity)

Nezavisnost komponenti - 1 1. Snaga veza među modulima (COUPLING) 1. 1. Nepovezani (uncoupled). – nizak nivo zavisnosti 1. 2. Veza preko podataka (data coupling) – parametri. 1. 3. Veza preko strukture podataka (stamp coupling). Karakteristika odjektnog dizajna 1. 4. Veza preko kontrola (control coupling) – parametri prenos kontrole. obezbeđuju NIZAK STEPEN ZAVISNOSTI MODULA. (low 1. 5. Veza preko zajedničkih elemenata (common coupling) – coupling) globalne reference i/ili globalne vrednosti. 1. 6. Veza preko sadržaja (content coupling) – jedna komponenta modifikuje drugu. – visok nivo zavisnosti

Nezavisnost komponenti - 2 2. Unutrašnja funkcionalna snaga modula (COHESION) 2. Unutrašnja funkcionalna snaga modula 1. 1. Funkcionalna (functional) – jedan modul jedna Funkcionalna funkcija 1. 2. Sekvencijalna kohezija (sequential) – jedan modul Sekvencijalna kohezija sadrži više funkcija koje se sekvencijalno koriste tako što se izlaz iz jedne prosleđuje na ulaz druge. 1. 3. Komunikaciona (communication) – modul sadrži Komunikaciona više funkcija koje su povezane preko zajedničkog repozitorijuma eksternog za modul. 1. 4. Procedurna (procedural) – modul sadrži više Procedurna funkcija koje se moraju izvršiti u utvrđenom redosledu. 1. 5. Temporalna (temporal) – modul sadrži više funkcija Temporalna čije je izvršenje vremenski povezano (t, t+dt, . . . ) 1. 6. Logička (logical) – ima smisla da budu zajedno!

Rukovanje izuzecima – exceptions 1 ·Predstavlja jedan od ključnih elemenata kvalitetnog dizajna jer stvara osnov za preventivno i korektivno delovanje u slučaju pojave ‘’iznenadnih događaja’’. ·Formiranje potpunog skupa izuzetaka predstavlja osnov za kvalitetno testiranje softverskog sistema. Jedan od načina da se to postigne je IDENTIFIKACIJA POZNATIH IZUZETAKA – situacija koje su u suprotnosti sa onim što softver treba da radi i obogaćivanje dizajna postupcima (metodama) za rukovanje izuzecima. ·Tipični primeri izuzetaka ove vrste su: oštećenje podataka (corrupted data), nemogućnost pružanja servisa, pružanje pogrešnog servisa, isporuka pogrešnih pojava strukture podataka i sl.

Rukovanje izuzecima - exceptions 2 Svaki od identifikovanih izuzetaka može da se opsluži na jedan od tri načina: ·Ponovni pokušaj (Retrying) – prvobitno stanje se restaurira i ponovi servis uz korišćenje druge strategije ·Korekcija (Correction) - prvobitno stanje se restaurira, izvrši se korekcija nekog od elemenata servisa i ponovi servis uz korišćenje iste strategije. ·Izveštavanje o neuspehu (Reporting failure) - prvobitno stanje se restaurira, izvesti se komponenta za rukovanje greškama i servis se blokira Osnovni problem: IDENTIFIKACIJA/ ’’ HVATANJE ’’ IZUZETAKA

Rukovanje greškama – errors - 1 ·U fazi dizajna neophodno je anticipirati greške i rukovati njima u cilju minimizacije vremena u kome softverski sistem nije funkcionalan odnosna maksimiziranja sigurnosti. Greška (fault) je uzrok – otkaz (failure) je obično njena posledica. ·Važno je shvatiti da svaka greška ne mora nužno biti vezana za otkaz budući da se deo koda koji sadrži grešku možda neće nikada izvršiti. ·Sa druge strane je moguće zamisliti situaciju u kojoj dolazi do otkaza nakon koga je nemoguće ponoviti okolnosti u kojima se on desio.

Rukovanje greškama – errors - 2 • Prevencija grešaka (fault prevention) – dizajn uparen sa testiranjem i verifikacijom • Izbegavanje otkaza (failure avoidance) – nadzor i sprečavanje pojave otkaza • Detekcija grešaka (fault detection) – otkrivanje greške na osnovu manifestacije otkaza • Ispravka grešaka (fault correction) – uklanjanje grešaka, oporavak od posledica otkaza, testiranje, verifikacija i ponovno aktiviranje. • Otpornost na greške (fault tolerance) – uklanjanje grešaka je nekada skupo i rizično. Otpornost na greške podrazumeva dizajniranje softvera tako da izoluje štetu uzrokovanu otkazom, dinamički reorganizuje servise, obezbedi oporavak ili redundantni servis i nastavi podršku korisnicima.

Smanjenje složenosti SMANJENJE SLOŽENOSTI – pojednostavljivanje strukture softverskog sistema i strukture podataka do nivoa potpune funkcionalnosti uz minimalnu složenost. Predstavlja izuzetan izazov za fazu konstrukcije softvera u kojoj često dolazi do ‘’infiltriranja’’ infiltriranja i kumuliranja neracionalnosti i neefikasnosti kao posljedica ad-hok intervencija

Objektni model softverskog sistema

Opšti ciljevi dizajna softverskih sistema - 1 1. 2. Svaki dizajner želi kreirati interaktivni sistem visokog kvaliteta kome se ‘’dive’’ njegove kolege, koga korisnici ‘’glorifikuju’’, koji se nezadrživo širi i biva često imitiran od strane drugih dizajnera. Zahvalnost korisnika nije posledica velikih obećanja ili dobre reklame već isključivo nastaje kao produkt iskustva u radu sa implementiranim rešenjem.

Opšti ciljevi dizajna softverskih sistema - 2 3. Kada je interaktivni sistem kvalitetno dizajniran korisnički interfejs, kao posrednik između čoveka i programa, nestaje omogućavajući korisniku da se skoncentriše na posao koji radi.

Esencijalni zahtevi prema softverskom sistemu 1. ISPRAVNO FUNKCIONISANJE Ako sistem ne funkcioniše ispravno ostali elementi nisu bitni! 2. POUZDANOST, RASPOLOŽIVOST, BEZBEDNOST i INTEGRITET Ako sistem ne poseduje gornje osobine ostali elementi nisu bitni! 3. 4. STANDARDIZACIJA, INTEGRACIJA, KONZISTENTNOST i PRENOSIVOST Ako sistem ne poseduje gornje osobine ostali elementi nisu bitni! VREME ISPORUKE i TROŠKOVI Ako sistem nije isporučen na vreme i u skladu sa procenjenim troškovima ostali elementi nisu bitni!

Principi izrade GUI aplikacija- 1 Izrada GUI aplikacija predstavlja multidisciplinarnu aktivnost i podrazumeva timski rad. Dobar GUI dizajn zahteva kombinaciju veština koje posedije: umetnikgrafički dizajner, sistem analitičar (analiza zahteva), sistem dizajner (dizajn proizvoda kao celine), programer, ekspert iz domena informacionih tehnologija (uređaji i sredstva), sociolog, psiholog i ekspert za domen primene (tehnolog procesa rada).

Osnovni postulati kvalitetnog GUI-dizajna - 1 1. KORISNIČKA ORIJENTISANOST (user is in control). Bitno je napomenuti da koncept korisničke orijentisanosti ne podrazumeva da aplikacija u celosti radi posao za korisnika (''mama će sve da uradi samo ti sedi. . . ''), već da ''podržava'' korisnika u obavljanju njegovog posla kroz interaktivni mehanizam: korisnička akcija (izbor stavke menia, klik miša, pomeranje kursora i sl. )- preuzimanje kontrole od strane aplikacije (otvaranje GUI prozora ili dijaloga, poziv servisnog programa(storredprocedure, 4 GL skript i sl. ))- povratna informacija animacija i sl. ). (set podataka, poruka, slika,

Osnovni postulati kvalitetnog GUI-dizajna - 2 2. 1. KONZISTENTNOST(consistency). Pod konzistentnošću u ovom slučaju podrazumevamo poštovanje standarda i uobičajenog načina na koji korisnik obavlja ''posao''. Važno je da GUI dizajner nije previše inventivan kada je korisnički interfejs u pitanju i da striktno poštuje dva osnovna aspekta konzistentnosti GUI aplikacija: • usklađenost sa GUI standardima isporučioca (npr. Microsoft Windows 'look-and-feel' , Apple Macintosh menu-standard i sl. ) · usklađenost sa konvencijama imenovanja, označavanja i drugim GUI-elementima i standardima interno razvijenim u sklopu organizacionog sistema korisnika.

Osnovni postulati kvalitetnog GUI-dizajna - 3 3. PERSONALIZACIJA i PODEŠAVANJE (personalization and customization). Pod personalizacijom se podrazumeva podešavanje (customization) u skladu sa ličnim afinitetima korisnika, dok se podešavanjem u opštem smislu podrazumeva administrativna procedura ua prilagođavanje softvera različitim grupama korisnika. Personalizacija – reorganizacija kolona u sklopu browser-a i sačuvavanje podešavanja u personalnom profilu. Podešavanje – ''lagani (light)'' režim rada za početnike i ''full (potpuni)'' režim rada za iskusne korisnike.

Osnovni postulati kvalitetnog GUI-dizajna - 4 PODRŠKA EKSPERIMENTISANJU i OPORAVKU (forgivenes principle). Kvalitetna GUI aplikacija treba da omogući korisniku eksperimentisanje, eksperimentisanje pravljenje grešaka i oporavak od grešaka restauriranjem ''početne pozicije'‘ (rollback and recovery). Ova osobina podrazumeva implementaciju višenivovske undo-funkcije (multilevel undo) kao standardnog svojstva elementa softverskog sistema. Zavisno od generičke oblasti primene ova osobina nekada nije poželjna (npr. undo akcije uzimanja novca iz bankomata nakon što je novac već preuzet ali bez vraćanja novca u automat!).

Osnovni postulati kvalitetnog GUI-dizajna - 5 POVRATNA INDIKACIJA (feedback). Da bi moga ostati u upravljačkoj ulozi neophodno je da korisnik tačno zna šta se dešava od trenutka kada se kontrola privremeno prenese na pozvani servis (program). Projektant mora u sastav aplikacije ugraditi vizualne i/ili auditivne efekte koji jednoznačno ilustruju aktivnost pozvanog servisa (pešćani sat, indikator progresa i sl. ). Nije preporučljivo pretpostaviti da je vreme odgovora pozvanog servisa toliko kratko da je povratna indikacija nepotrebna.

Osnovni postulati kvalitetnog GUI-dizajna - 6 ESTETSKI ASPEKTI i MOGUĆNOST KORIŠĆENJA (aesthetics and usability). Pod estetskim aspektom softverskog sistema podrazumeva se vizualna pojava GUI aplikacije podložna skupu ocenskih kriterijuma. Pod mogućnošću korišćenja (usability) podrazumeva se: lakoća, jednostavnost, efikasnost, pouzdanost i produktivnost pri korišćenju softverskog sistema (Lepota je u jednostavnosti!) (Lepota je u oku onoga koji posmatra!).

Specifikacija dizajna - 3 Elementi specifikacije dizajna: • Segregacija – razlaganje funkcionalne specifikacije Segregacija na MODULE/KOMPONENTE • Hijerarhijsko organizovanje modula • Definisanje tokova podataka između modula Definisanje tokova podataka • Definisanje strukture spoljašnjih skladišta podataka • Definisanje pristupnih puteva spoljašnjim Definisanje pristupnih puteva skladištima podataka • Definisanje struktura podataka koje se razmenjuju među modulima posredstvom definisanih tokova (puteva) • Izrada ključnih algoritama • Definisanje unutrađnje strukture svakog modula

UML Specifikacija dizajna – (1) Slučajevi korišćenja ne definišu način na koji će sistem biti izgrađen, već samo način na koji učesnici mogu koristiti funkcije projektovanog sistema. STATIČKA STRUKTURA SISTEMA – • definiše način implementacije slučajeva korišćenja. • KLASE • OBJEKTI • VEZE

UML Specifikacija dizajna – (2) DINAMIČKO PONAŠANJE SISTEMA • – definiše način komunikacije između objekata i efekte te komunikacije, komunikacije odnosno načine na koji OBJEKTI sarađuju i kako se unutar sistema menjaju u toku vlastitog životnog ciklusa. menjaju DIJAGRAMI STANJA • DIJAGRAMI SEKVENCE • DIJAGRAMI SARADNJE • DIJAGRAMI AKTIVNOSTI •

UML Specifikacija dizajna – (3) UML Specifikacija dizajna definiše način realizacije (implementacije) slučajeva korišćenja! • <<realizuje>> Use Case Saradnja klasa <<implementira>> Opis slučaja koriščenja Klasa A Klasa |B Klasa C Atributi Operacije

Dobro strukturirana klasa! �Dobro strukturirana klasa ima sledeće osobine: ◦ Predstavlja JASNU APSTRAKCIJU nečega što je sastavni deo problema (sistema) sistema ili realizacije (implementacije) (rešenja). rešenja ◦ Sadrži mali broj dobro definisanih odgovornosti i ispravno ih realizuje. ◦ Omogućava jasno razdvajanje SPECIFIKACIJE i IMPLEMENTACIJE SPECIFIKACIJE IMPLEMENTACIJE apstrakcije koju predstavlja. ◦ Razumljiva je i jednostavna, ali otvorena (dozvoljava modifikacije, proilagođavanja. . . )

Odeljci klase �Klasa se sastoji od četiri sekcije Ime pripada domenu problema Treba da ◦ Prva sekcija sadrži naziv klase bude IMENICA bez prefiksa ili sufiksa. ◦ Druga sekcija sadrži svojstva (attribute) Imenovane osobine Uobičajeno je opisuju da je klase koje klase ◦ Treća sekcija sadrži ponašanje prvo slovo svake reči slovo opseg vrednosti koje (operations) koja čini složeno ime Operacija primerci je konkretni VELIKO apstrakcija osobine mogu onoga da ◦ Četvrta opis odnosa atributa i operacija. Naziv klase Atributi Metode Odgovornosti Profesor Ime Identifikator create( ) save( ) delete( ) change( ) što se može izvršiti sadrže. nad objektom i što je zajedničko za sve Tekst objekte. u slobodnoj formi koji pobliže opisuje vezu između atributa i operacija.

UML predstava atributa �Odeljak atributa (Attribute Compartment) [vidljivost] ime [višestrukost] [: tip] [= početna vrednost] [{lista vrednosti}] [{promenljivost}] changable – default Kardinalitet – konstatna 1. primitivni frozen (Boolean, String, Integer) 2. složeni add. Only – samo pri dodavanju 1. public (+) Svaki spoljnji klasifikator može koristiti tu karkteristiku 2. protected (#) Svaki naslednik može koristiti karakteristiku 3. private (-) Samo klasifikator može koristiti karakteristiku default – public ili undefined

UML pretstava operacija �Odeljak operacija (Operation Compartment) [vidljivost] ime ([lista parametara]) [: tip rezultata] [{osobina}] is. Quiery Čista funkcija bez sporednih efekata. parametar [, lista parametara] sequential U datom objektu u jednom trenutku parametar = [smer] ime: tip [=podrazumevana postoji samo jedan upravljački tok. vrednost] Oni koji pozivaju metodu moreju se eksterno sinhronizovati. 1. public {in, out, inout} guarded Jedna operacija u jednom trenutku (+) Svaki spoljnji klasifikator može koristiti operaciju. na svakoj instanci (objektu). 2. protected Sekvencijalnost je zagarantovana (#) Svaki naslednik može koristiti operaciju. 3. private (-) Samo klasifikator može koristiti operaciju. concurent Operacije su atomičke prirode. default = public unutar objekta! Dozvoljeni su konkurentni pozivi iz paralelnih upravljačkih tokova ka jednoj instanci klase.

UML predstava operacija-(2) Toolbar #current. Selection: Tool #tool. Count: Integer Primer +pozicija: Possition=“Up” specifikacije operacija +draw(p: Possition) +pick. Item(i: Integer) +add. Tool(t: Tool) +remove. Tool(t: Tool) +get. Tool(): Tool #chack. Orphans)=: Boolean -compact() +restart() {guarded}

Veze između Klasa i Objekata �Asocija ◦ Agregacija ◦ Kompozicija �Zavisnost �Generalizacija �Realizacija

Veze između Klasa i Objekata –(2) � Asocija opisuje grupu veza sa zajedničkom strukturom i semantikom (Osoba radi za Preduzeće) kod strukturom koje su svi učesnici “SVESNI POSTOJANJA ONIH DRUGIH” DRUGIH tj. međusobno se referenciraju. Asocija je obično skup obično dvosmerna veza između klasa koja opisuje dvosmerna mogućih veza na isti način na koji klasa opisuje skup potencijalnih instanci (objekata). UML simbolika: <<naziv asocijacije K 1 -K 2>> Klasa K 2 Klasa K 1 <<Uloga K 1>> <<Uloga K 2>> <<kvalifikator>> <<kardinalitet K 1>> <<kardinalitet K 2>> <<naziv asocijacije K 2 -K 1>>

Veze između Klasa i Objekata –(2) Koliko pojava date klase može biti vezano za jednu pojavu druge. 1, 0. . 1, * , 1. . *, n. . m, k, r Imenovanje asocijacije (glagol ili imenica) UML simbolika: Uloga klase u asocijaciji (opciono) <<naziv asocijacije K 1 -K 2>> Klasa K 1 Klasa K 2 Predstavlja jedan atribut <<Uloga K 2>> <<Uloga K 1>> ili skup atributa <<kvalifikator>> referencirane klase pomoću kojih se iz skupa <<kardinalitet K 1>> <<kardinalitet K 2>> instanci klase izdvaja podskup koji ima <<naziv asocijacije K 2 -K 1>> vrednost kvalifikatora!

Asocijacije –(1) � Obične (normalne) � Rekurzivne - (povezuju različite instance iste klase) � Refleksivne – (povezuju iste instance) � Kvalifikovane – (ako je definisan kvalifikator) � Uređene – (ako postoji eksplicitno uređenje - sortiranje) � Agregacija modeluje vezu čije je značenje “deo- celina” celina ili “deo-od” od preko koje su objekti koji predstavljaju delove celine povezane sa objektom koji predstavlja celinu. Delovi ne dele sudbinu celine! � Kompozicija modeluje vezu čije je značenje “deo- celina” celina ili “deo-od” od preko koje su objekti koji predstavljaju delove celine povezane sa objektom koji predstavlja celinu. Delovi moraju da dele sudbinu celine!

Agregacija i Kompozicija Agregacija: Klasa K 1 Klasa K 2 Kompozicija: Klasa K 1 Klasa K 2

Primer: Kardinalitet Student 1 Navigacija 0. . * Raspored

Kompozicija

Agregacija

Asocijativna klasa

Veze između Klasa i Objekata-(3) �Zavisnost je slabija verzija veze koja odražava odnos klijenta (potrošača) potrošača i servera (proizvođača). proizvođača Podrazumeva vezu koja opisuje međuzavisnost elemenata modela kod koje promena u sklopu jednog (nezavisnog) nezavisnog elementa uzrokuje promenu u sklopu drugog (zavisnog) elementa. zavisnog �Može se uspostaviti između različitim elemenata modela (klase, komponente, paketi) ali jedino na istom nivou apstrakcije! apstrakcije

Veze između Klasa i Objekata-(3) � Primeri zavisnosti: 1. Jedna klasa preuzima objekat druge klase kao objekat parametar! parametar 2. Jedna klasa pristupa globalnom objektu druge klase! 3. Jedna klasa poziva operaciju definisanu u drugoj klasi! UML simbolika: (zavisnost) Klasa K 2 Klasa K 1 labela <<stereotip>>

Primeri veza zavisnosti Klasa Klijent Server Klijent Paket Veza zavisnost i Klijent. Paket Server. Pakete Komponent a Server Veza zavisnos ti

Veze između Klasa i Objekata-(4) �Rafinacija (refinments) predstavlja vezu između JEDNE TE ISTE STVARI na različitim nivoima APSTRAKCIJE! APSTRAKCIJE UML simbolika: (rafinacija) Klasa K 2 Klasa K 1 (specifikacija zahteva) labela <<stereotip>> (specifikacija dizajna)

Relacije: Realizacija �Jedan klasifikator služi kao “ugovor” koji ugovor drugi klasifikator prihvata da poštuje �Postoji između: ◦ Interfejsa i klasifikatora koji ih realizuju ◦ Slučajeva korišćenja i saradnje klasa koja ih realizuje. Klasa Komponenta Podsistem Interfejs Vodeća forma Kanonski oblik Use Case Use-Case Realization

Realizacija - implementira Interfejs pretstavlja skup operacija koje služe za specificiranje servisa klase ili komponente (Booch, 1999). Interfejsi formalizuju polimorfizam, dopuštaju definisanje polimorfizma na deklarativni način nezavisno od implementacije.

Veze između Klasa i Objekata-(5) �Generalizacija predstavlja vezu između klasa u kojoj jedna od njih ima opšta svojstva dok je druga njena specijalizacija. Podređeni element je u specijalizacija potpunoj saglasnosti sa nadređenim i saglasnosti poseduje sve osobine nad-klase (roditeljska klasa – predak), predak ali može posedovati i dodatne osobine koje definiše pod-klasa (potomak). potomak Veza generalizacije je jedino moguća između KLASA! KLASA

Generalizacija �Veza između klasa kod koje jedna klasa deli strukturu i/ili ponašanje jedne ili više deli klasa. �Definiše hijerarhiju apstrakcija kod koje hijerarhiju apstrakcija PODKLASE nasleđuju svojstva ili nasleđuju ponašanje od jedne ili više SUPERKLASA. ◦ Jednostruko nasleđivanje (Single inheritance) ◦ Višestruko nasleđivanje (Multiple inheritance) �Generalizacija je veza tipa “je-pripadnik-

Generalizacija - primer

Primer: Jednostruko nasleđivanje �Jedna klasa nasleđuje od druge Predak Superklasa (roditelj) Podklase Account balance name number Withdraw() Create. Statement() Veza generelizacije Checking Savings Withdraw() Get. Interest() Withdraw() Potomci

Šta se nasleđuje? �Klasa potomak nasleđuje atribute klase pretka, metode i metode veze sa drugim klasama �Klasa potomak može: ◦ Dodati nove atribute, metode i veze ◦ Redefinisati nasleđene metode. �Zajednički atributi, metode i/ili veze se prikazuju na što je moguće višem nivou hijerarhije. Nasleđivanje “niveliše” niveliše sličnosti među klasama!

Primer: Šta se nasleđuje Zemaljsko. Vozilo Superklasa (Roditelj) weight license. Number vlasnik 0. . * Osoba 1 register( ) generalizacija Podklase (Potomci) Auto size Kamion tonnage get. Tax( ) Prikolica

Primer-1: Dijagram klasa Canvas Figure {abstract} sadrži * * pozicija: Pos draw(): {abstract} Linija {abstract} Grupa draw(): sadrži Element * draw(): {abstract} Luk draw(): Duz draw():

Primer-2: Dijagram klasa Invertor IKolo +Iscrtavanje() : void +Pomeranje() : void +Iscrtavanje() : void +Selektovanje() : 1 void +Pomeranje() : void Poseduje ulaze/izlaze 1. . * +Selektovanje() : void Logičko kolo +Selektovanje() : void Grafički objekat #Tačka 1 : TPoint #Tačka 2 : TPoint Ili. Kolo +Iscrtavanje() : void Ulaz/izlaz Linijski objekat #Selektovan? : bool #Pomera se? : bool +Iscrtavanje() : void +Pomeranje() : void +Selektovanje() : void 1 +Iscrtavanje() : void +Pomeranje() : void +Selektovanje() : void Početni objekat 1 +Selektovanje() : Veza void 0. . * Krajnji objekat 0. . 1 +Iscrtavanje() : void +Pomeranje() : void

UML notacije veza

Metodologija razvoja softvera Dizajn softverskih sistema ?