Your SlideShare is downloading. ×
Projektovanje softvera -_skripta
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Projektovanje softvera -_skripta

567
views

Published on

Sam programski jezik je uređen konačan …

Sam programski jezik je uređen konačan
skup znakova za formulisanje programa.
Njegova definicija data u ISO standardu
glasi: programski jezik je veštački jezik koji
se koristi za predstavljanje programa. Sam
program predstavlja sistem oznaka za opis
algoritama i struktura podataka pomoću
kojih ljudi komuniciraju sa računarom. Jednostavnije korišćenje mašinskog jezika dobija se uvođenjem simboličkih imena za naredbe i adreseme morijskih lokacija, a to omogućava asemblerski ili simbolički mašinski jezik. Asemblerski jezik je niskog nivoa, zbog toga što je korespodencija između asemblerskog i mašinskog jezika jedan prema jedan. Programer koristi naredbe računara na kome radi, pa stoga program nije prenosiv - ne može
se izvršiti na drugom računaru bez reprogramiranja.

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
567
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Elektrotehniči fakultet Univerziteta u Beogradu Katedra za računarsku tehniku i informatiku skripta za predmet PROJEKTOVANJE SOFTVERA Igor Tartalja Beograd, 2011. Besplatan primerak This copy is not for sale Ova skripta je objavljena u okviru projekta WUS Austria MSDP 2011 The publishing of this script is part of the project MSDP 2011 finansiranog od strane Austrijske agencije za razvoj financed by Austrian Development Agency through WUS Austria
  • 2. Predgovor 3 Projektovanje softvera Predgovor Projektovanje softvera je inženjerska disciplina i ključna faza u razvoju softvera. Ono se zasniva na principima koji se odnose prvenstveno na modeliranje strukture i ponašanja softvera, kao i na primenu projektnih uzoraka u rešavanju problema. Kao i svaki drugi inženjerski proizvod, softver u svome nastajanju prolazi kroz prepoznatljive faze, od specifikacije zahteva, pa do instalacije na ciljne mašine. Instalacijom tek počinje životni vek softvera kao tehničkog proizvoda. Život softverskog proizvoda se sastoji od njegovog korišćenja, popravki i unapređenja. Iskustva stečena u toku životnog veka softverskog proizvoda često dovode do nastanka novih proizvoda, njegovih funkcionalnih naslednika. Ako se ta iskustva formalno dokumentuju kroz model i prepoznate projektne uzorke, mogu se primeniti i mnogo šire. Praktično isti principi projektovanja softvera se primenjuju, kako na razvoj novog proizvoda, tako i na održavanje i unapređivanje postojećeg proizvoda u toku njegovog životnog veka. Predmet Projektovanje softvera, koji se drži na osnovnim i master studijama Softverskog inženjerstva i Računarske tehnike i informatike na Elektrotehničkom fakultetu, Univerziteta u Beogradu se koncentriše na dva centralna aspekta projektovanja softvera. To su modeliranje objektno-orijentisanog softvera i primena projektnih uzoraka u koncipiranju arhitekture softvera. Ova skripta sadrže materijale koji se koriste na predavanjima iz predmeta Projektovanje softvera. Skripta su nastala sa željom da se studentima koji pohađaju ovaj predmet stave na raspolaganje materijali koji se koriste na predavanjima. Predavanja se drže uz korišćenje elektronskih prezentacija sa slajdovima, te je sadržaj skripti praktično jednak sadržaju slajdova koji se koriste na predavanjima. Prvobitni tekst skripti je predstavljao samo podsetnik nastavniku za držanje predavanja. Posle višegodišnjeg iskustva u držanju nastave iz ovog predmeta, te doterivanja materijala kroz više iteracija, autor se odlučio da objavi skripta u ovom obliku i stavi ih na raspolaganje studentima koji pohađaju predmet. Zato se skreće pažnja čitaocima da su skripta namenjena praktično samo onima koji prate predavanja na predmetu. Ona ne predstavljaju samostalan udžbenik iz kojeg se predmet može valjano naučiti. Ona su praktični podsetnik na materiju koja se izlaže na predavanjima. Treba imati u vidu da se na predavanjima daju i mnoga usmena objašnjenja pojmova i principa koji su samo pomenuti u skriptama. Bez praćenja predavanja, takvi pojmovi i principi se teško mogu dobro razumeti samo na osnovu čitanja skripti. Takođe, pretpostavlja se da čitaoci ovih skripti dobro vladaju pojmovima i principima koji se prethodno izučavaju na predmetima iz proceduralnog i objektno-orijentisanog programiranja. U pripremi skripti korišćena je literatura navedena na kraju skripti. Najveći deo teksta na jezgroviti način, kroz teze, izlaže materiju iz te literature. Ujedno, navedeni izvori predstavljaju udžbenike i dopunsku literaturu predmeta Projektovanje softvera. Osim uvoda u projektovanje softvera, skripta sadrže dva dela. Prvi deo je posvećen objektno-orijentisanom modeliranju na jeziku UML (Unified Modeling Language). Drugi deo je posvećen primeni projektnih uzoraka u projektovanju softvera. Iako je materija u skriptama izložena na navedeni način, metodologija držanja predmeta je takva da se teme iz ove dve šire oblasti
  • 3. 4 Predgovor Elektrotehnički fakultet u Beogradu kombinuju, tako da se na predmetu simultano napreduje kroz obe oblasti. Na taj način se studentima omogućava da vrlo rano počnu da uvežbavaju metodologiju projektovanja na jeziku UML uz korišćenje projektnih uzoraka. Iz tog razloga su i projektni uzorci izloženi redosledom primerenim blagovremenom uvežbavanju, počeviši od onih koje je lakše razumeti i primeniti, kombinujući ih sa do tada obrađenim dijagramima jezika UML. Autor se zahvaljuje svima koji su na bilo koji način doprineli nastanku ovih skripti. Posebnu zahvalnost autor duguje kolegi mr Laslu Krausu. Dugogodišnja saradnja i plodne diskusije o problematici, kako ovog predmeta, tako i predmeta iz objektno-orijentisanog programiranja, pomogle su autoru da izgradi terminologiju i razvije metodologiju rada na predmetu. Kompletiranje završne verzije ovih skripti pomogla je Austrijska agencija za razvoj, kroz projekat Master Studies Development Program (MSDP 2011), WUS Austrija. Recenzenti izveštaja na projektu MSDP 2011, Johann Höchtl i Sylvia Purgathofer-Müller, dali su korisne savete da skripta dobiju konačni oblik. Konačno, autor se zahvaljuje studentima ranijih generacija koji su ukazali na propuste i greške u ranijim materijalima na osnovu kojih su nastala skripta u ovom obliku. U uverenju da će skripta biti od koristi studentima koji prate predmet Projektovanje softvera, autor se nada da će im izložena materija biti interesantna i podsticajna, kako za pripremu ispita, tako i za buduću inženjersku praksu. Moli ih da čitaju pažljivo, a za sve propuste i greške koje otkriju i prijave mu, biće im veoma zahvalan. Beograd, 15.06.2011. Autor
  • 4. Sadržaj 5 Projektovanje softvera Sadržaj Predgovor..........................................................................................................................................3 Sadržaj...............................................................................................................................................5 Uvod ................................................................................................................................................13 Osnovni pojmovi ..................................................................................................................................... 13 Objektno-orijentisana analiza ............................................................................................................... 13 Objektno-orijentisano projektovanje.................................................................................................... 13 Objektno-orijentisano programiranje .................................................................................................. 13 Objektno-orijentisani jezik .................................................................................................................... 14 Principi OO modela................................................................................................................................ 14 Apstrakcija i kapsulacija........................................................................................................................ 14 Modularnost i hijerarhija....................................................................................................................... 14 Tipizacija i polimorfizam ....................................................................................................................... 15 Konkurentnost i perzistencija................................................................................................................ 15 Model i modeliranje................................................................................................................................ 15 Ciljevi modeliranja ................................................................................................................................. 16 OO model i pogledi na model................................................................................................................. 16 Dijagrami................................................................................................................................................. 16 Logički i fizički aspekti modela ............................................................................................................. 16 Statički i dinamički aspekti modela....................................................................................................... 16 Notacija za opis modela.......................................................................................................................... 17 Alati za modeliranje................................................................................................................................ 17 Pregled jezika UML........................................................................................................................18 Standardni jezik za modeliranje UML ................................................................................................. 18 Korisnici UML-a..................................................................................................................................... 18 Praistorija UML-a .................................................................................................................................. 18 Istorija UML-a........................................................................................................................................ 19 Konceptualni model UML-a .................................................................................................................. 19 Stvari........................................................................................................................................................ 19 Stvari strukture – klase i interfejsi........................................................................................................ 20 Stvari strukture – slučaj korišćenja i saradnja.................................................................................... 20 Stvari strukture – komponenta i čvor................................................................................................... 21 Stvari ponašanja ..................................................................................................................................... 21 Stvari organizacije i anotacije................................................................................................................ 22 Relacije..................................................................................................................................................... 22 Dijagrami................................................................................................................................................. 23 Statički dijagrami ................................................................................................................................... 23
  • 5. 6 Sadržaj Elektrotehnički fakultet u Beogradu Dinamički dijagrami............................................................................................................................... 23 Pravila UML-a ........................................................................................................................................ 24 Opšti mehanizmi UML-a........................................................................................................................ 24 Specifikacije............................................................................................................................................. 24 Ukrasi....................................................................................................................................................... 25 Opšte podele ............................................................................................................................................ 25 Mehanizmi proširivosti........................................................................................................................... 25 Stereotipovi.............................................................................................................................................. 26 Obeležene vrednosti................................................................................................................................ 26 Ograničenja............................................................................................................................................. 26 Prvi primer...................................................................................................................................... 27 Uvod ......................................................................................................................................................... 27 Primer na Javi......................................................................................................................................... 27 Ključne apstrakcije................................................................................................................................. 27 Grupisanje............................................................................................................................................... 28 Ponašanje................................................................................................................................................. 28 Komponente ............................................................................................................................................ 28 Dijagrami klasa .............................................................................................................................. 29 Uvod ......................................................................................................................................................... 29 Klasifikator.............................................................................................................................................. 29 Klasa......................................................................................................................................................... 29 Simbol klase............................................................................................................................................. 29 Atributi i operacije.................................................................................................................................. 30 Dodatne mogućnosti ............................................................................................................................... 30 Tipovi podataka ...................................................................................................................................... 31 Osobine klasa........................................................................................................................................... 31 Sintaksa atributa..................................................................................................................................... 31 Sintaksa operacije................................................................................................................................... 31 Relacije..................................................................................................................................................... 32 Zavisnost.................................................................................................................................................. 32 Generalizacija.......................................................................................................................................... 32 Asocijacija................................................................................................................................................ 33 Realizacija................................................................................................................................................ 33 Primer osnovnih relacija........................................................................................................................ 33 Ukrasi asocijacije.................................................................................................................................... 34 Multiplikativnost..................................................................................................................................... 34 Agregacija................................................................................................................................................ 34
  • 6. 7 Projektovanje softvera Kompozicija............................................................................................................................................. 34 Primer asocijacija ................................................................................................................................... 35 Navigacija ................................................................................................................................................ 35 Pravo pristupa preko asocijacije........................................................................................................... 35 Ugnežđivanje........................................................................................................................................... 35 Dijagrami paketa ............................................................................................................................36 Uvod ......................................................................................................................................................... 36 Paket......................................................................................................................................................... 36 Imenovanje paketa i elemenata ............................................................................................................. 36 Vlasništvo i pravo pristupa .................................................................................................................... 37 Notacija.................................................................................................................................................... 37 Relacije..................................................................................................................................................... 37 Principi modeliranja............................................................................................................................... 38 Stereotipovi paketa ................................................................................................................................. 39 Dijagrami objekata .........................................................................................................................40 Uvod ......................................................................................................................................................... 40 Namena .................................................................................................................................................... 40 Objekti ..................................................................................................................................................... 40 Veze .......................................................................................................................................................... 40 Primer – uzorak Kompozicija................................................................................................................ 41 Primer - relacija “pohađa” .................................................................................................................... 41 Dijagrami interakcije......................................................................................................................42 Uvod ......................................................................................................................................................... 42 Kontekst interakcije ............................................................................................................................... 42 Poruka...................................................................................................................................................... 42 Vrste dijagrama interakcije................................................................................................................... 43 Dijagrami sekvence i komunikcije ........................................................................................................ 43 Uloge i njihove linije života.................................................................................................................... 44 Konektori................................................................................................................................................. 44 Slanje i prijem poruke............................................................................................................................ 45 Sekvenciranje poruka............................................................................................................................. 46 Sekvenciranje poruka u nitima.............................................................................................................. 47 Sintaksa poruke....................................................................................................................................... 47 Životni vek objekata i veza..................................................................................................................... 47 Događanje izvršenja (fokus kontrole)................................................................................................... 47 Primer Bankomat – dijagram sekvence................................................................................................ 48 Primer Bankomat – dijagram komunikacije ....................................................................................... 48
  • 7. 8 Sadržaj Elektrotehnički fakultet u Beogradu Iteracije i grananje.................................................................................................................................. 49 Fragment (okvir) interakcije ................................................................................................................. 49 Operatori kombinovanih fragmenata................................................................................................... 49 Primer operatora okvira interakcije..................................................................................................... 50 Dijagrami slučajeva korišćenja ..................................................................................................... 51 Uvod ......................................................................................................................................................... 51 Slučajevi korišćenja................................................................................................................................ 51 Ponašanje slučaja korišćenja ................................................................................................................. 51 Primer opisa ponašanja.......................................................................................................................... 51 Akteri ....................................................................................................................................................... 52 Relacija komunikacije ............................................................................................................................ 52 Relacija uključivanja.............................................................................................................................. 52 Primer – korisnici foruma...................................................................................................................... 53 Relacija proširivanja .............................................................................................................................. 53 Tačke proširenja slučaja korišćenja...................................................................................................... 54 Relacija generalizacije............................................................................................................................ 54 Okvir subjekta......................................................................................................................................... 55 Primer – Info sistem fakulteta ............................................................................................................... 55 Dijagrami aktivnosti....................................................................................................................... 56 Uvod ......................................................................................................................................................... 56 Odnos prema drugim dijagramima ...................................................................................................... 56 Aktivnosti i akcije ................................................................................................................................... 56 Aktivnosti................................................................................................................................................. 57 Akcije ....................................................................................................................................................... 57 Elementi dijagrama aktivnosti............................................................................................................... 58 Pseudočvorovi, tranzicije, konektori..................................................................................................... 58 Sekvencijalna grananja .......................................................................................................................... 59 Primeri grananja i iteracije.................................................................................................................... 59 Konkurentna grananja........................................................................................................................... 59 Tok objekata............................................................................................................................................ 60 Primer ...................................................................................................................................................... 60 Plivačke staze........................................................................................................................................... 60 Hijerarhijske staze i particije ................................................................................................................ 61 Primer dijagrama aktivnosti.................................................................................................................. 62 Izuzeci ...................................................................................................................................................... 62 Signali i događaji..................................................................................................................................... 63 Primer slanja i prihvatanja signala....................................................................................................... 63
  • 8. 9 Projektovanje softvera Oblast ekspanzije.................................................................................................................................... 64 Centralni bafer........................................................................................................................................ 64 Skladište podataka.................................................................................................................................. 65 Dijagrami stanja .............................................................................................................................66 Uvod ......................................................................................................................................................... 66 Kontekst primene automata stanja....................................................................................................... 66 Elementi dijagrama stanja..................................................................................................................... 66 Stanja i podautomati stanja................................................................................................................... 66 Elementi stanja........................................................................................................................................ 67 Primer stanja........................................................................................................................................... 67 Pseudostanja i specijalna stanja ............................................................................................................ 68 Prelazi ...................................................................................................................................................... 68 Primer dijagrama stanja........................................................................................................................ 69 Mealy i Moor automati........................................................................................................................... 69 Primer automata Mealy-jevog tipa ....................................................................................................... 69 Složena stanja.......................................................................................................................................... 69 Sekvencijalna podstanja......................................................................................................................... 70 Primer sekvencijalnih podstanja........................................................................................................... 70 Stanje sa istorijom .................................................................................................................................. 71 Konkurentna podstanja ......................................................................................................................... 71 Primer konkurentnih podstanja............................................................................................................ 72 Slanje signala........................................................................................................................................... 72 Dijagrami klasa – napredniji pojmovi ...........................................................................................73 Aktivne klase ........................................................................................................................................... 73 Procesi i niti............................................................................................................................................. 73 Aktivne klase - notacija .......................................................................................................................... 73 Šabloni ..................................................................................................................................................... 74 Šabloni - notacija .................................................................................................................................... 74 Izuzeci ...................................................................................................................................................... 74 Klasa asocijacije...................................................................................................................................... 74 N-arna asocijacija ................................................................................................................................... 75 Kvalifikacija ............................................................................................................................................ 75 Specifikator interfejsa (UML 1) ............................................................................................................ 76 Generalizacioni skupovi ......................................................................................................................... 76 Notacija i primer..................................................................................................................................... 76 Metaklasa................................................................................................................................................. 77 Powertype ................................................................................................................................................ 77
  • 9. 10 Sadržaj Elektrotehnički fakultet u Beogradu Konteksti relacije realizacije.................................................................................................................. 77 Parametrizovana kolaboracija .............................................................................................................. 78 Projektni uzorci....................................................................................................................................... 78 Standardni stereotipovi klasifikatora ................................................................................................... 78 Standardni stereotipovi relacije zavisnosti........................................................................................... 79 Standardni stereotipovi ostalih relacija................................................................................................ 79 Dijagrami složene strukture........................................................................................................... 80 Uvod ......................................................................................................................................................... 80 Notacija: delovi i portovi........................................................................................................................ 80 Konektori................................................................................................................................................. 80 Primer ...................................................................................................................................................... 81 Multiplikativnost..................................................................................................................................... 81 Saradnja................................................................................................................................................... 82 Događanje saradnje................................................................................................................................ 82 Dijagrami komponenata ................................................................................................................ 83 Uvod ......................................................................................................................................................... 83 Najčešće primene .................................................................................................................................... 83 Komponenta ............................................................................................................................................ 83 Grafička notacija .................................................................................................................................... 83 Artefakt.................................................................................................................................................... 84 Komponente i klase/interfejsi ................................................................................................................ 84 Port........................................................................................................................................................... 84 Port i interfejsi ........................................................................................................................................ 86 Vrste artefakata i stereotipovi ............................................................................................................... 86 Paketi i relacije zavisnosti ...................................................................................................................... 86 Primer dijagrama komponenata ........................................................................................................... 87 Dijagrami raspoređivanja .............................................................................................................. 88 Uvod ......................................................................................................................................................... 88 Najčešće primene .................................................................................................................................... 88 Čvorovi..................................................................................................................................................... 88 Organizovanje čvorova........................................................................................................................... 89 Čvorovi, komponente i artefakti............................................................................................................ 89 Uređaji i izvršna okruženja.................................................................................................................... 89 Veze .......................................................................................................................................................... 90 Primer – hardverska konfiguracija....................................................................................................... 90 Primer – čvorovi i artefakti.................................................................................................................... 90 Dijagrami interakcije - napredniji pojmovi................................................................................... 91
  • 10. 11 Projektovanje softvera Dijagrami pregleda interakcije.............................................................................................................. 91 Razlike od dijagrama aktivnosti............................................................................................................ 91 Grafička notacija .................................................................................................................................... 91 Primer – dijagram pregleda interakcije ............................................................................................... 92 Vremenski dijagrami.............................................................................................................................. 92 Grafička notacija .................................................................................................................................... 93 Primer vremenskog dijagrama.............................................................................................................. 93 Arhitektura metamodeliranja.........................................................................................................94 Uvod ......................................................................................................................................................... 94 Četvoronivoska arhitektura................................................................................................................... 94 Opis nivoa arhitekture............................................................................................................................ 94 Primer ...................................................................................................................................................... 95 Meta-metamodel ..................................................................................................................................... 95 Metamodel............................................................................................................................................... 95 Model ....................................................................................................................................................... 96 Korisnički objekti ................................................................................................................................... 96 Analogija.................................................................................................................................................. 96 Uvod ................................................................................................................................................97 Elementi uzorka..............................................................................................................................97 Naziv uzorka............................................................................................................................................ 97 Postavka problema ................................................................................................................................. 97 Opis rešenja............................................................................................................................................. 98 Posledice................................................................................................................................................... 98 Primer primene uzoraka: MVC .....................................................................................................98 Model – View komunikacija .................................................................................................................. 98 Komponovanje prikaza .......................................................................................................................... 99 Model – Controller komunikacija......................................................................................................... 99 Klasifikacija projektnih uzoraka..................................................................................................100 Kriterijum namene ............................................................................................................................... 100 Kriterijum domena............................................................................................................................... 100 Karakteristike vrsta uzoraka............................................................................................................... 100 Drugi odnosi između uzoraka.............................................................................................................. 101 Prostor projektnih uzoraka ................................................................................................................. 101 Katalog projektnih uzoraka..........................................................................................................101 UML notacija za opis uzoraka .....................................................................................................102 Unikat............................................................................................................................................103 Kompozicija...................................................................................................................................105
  • 11. 12 Sadržaj Elektrotehnički fakultet u Beogradu Prototip ......................................................................................................................................... 108 Posmatrač..................................................................................................................................... 110 Iterator.......................................................................................................................................... 113 Dekorater...................................................................................................................................... 117 Strategija....................................................................................................................................... 120 Šablonski metod ........................................................................................................................... 122 Adapter.......................................................................................................................................... 124 Stanje ............................................................................................................................................ 127 Podsetnik ...................................................................................................................................... 129 Muva ............................................................................................................................................. 131 Fabrički metod ............................................................................................................................. 133 Apstraktna fabrika ....................................................................................................................... 135 Fasada .......................................................................................................................................... 138 Posrednik...................................................................................................................................... 140 Zastupnik...................................................................................................................................... 143 Most .............................................................................................................................................. 146 Komanda....................................................................................................................................... 149 Lanac odgovornosti...................................................................................................................... 152 Graditelj........................................................................................................................................ 155 Posetilac........................................................................................................................................ 158 Interpreter..................................................................................................................................... 162 Literatura...................................................................................................................................... 166
  • 12. Uvod 13 Projektovanje softvera Uvod Osnovni pojmovi • Svaki ozbiljniji projekat prolazi kroz faze: analiza, projektovanje, implementacija, testiranje – slično je sa SW projektima, kroz faze se prolazi iterativno • Objektno-orijentisana metodologija razvoja – dominantna u proizvodnji softvera danas • Pojmovi – objektno-orijentisana analiza – OOA – objektno-orijentisano projektovanje – OOD – objektno-orijentisano programiranje – OOP – objektno-orijentisani jezik – OOL Objektno-orijentisana analiza • Tradicionalne tehnike strukturirane analize – fokus na toku podataka u sistemu • Booch (1994): Objektno-orijentisana analiza je metod analize koji ispituje zahteve iz perspektive klasa i objekata pronađenih u rečniku iz domena problema • Proizvod OOA – konceptualni model - ulaz u fazu OOD Objektno-orijentisano projektovanje • Tradicionalno strukturirano projektovanje – fokus na algoritamskim apstrakcijama • Booch (1994): Objektno-orijentisano projektovanje je metod projektovanja koji obuhvata – proces OO dekompozicije – notaciju za predstavljanje • logičkih i fizičkih • statičkih i dinamičkih aspekata modela sistema koji se projektuje • Proizvod OOD – model projektovane aplikacije ili sistema – ulaz u fazu OOP Objektno-orijentisano programiranje • Tradicionalno strukturirano programiranje – fokus na implementaciji algoritama • Booch (1994): Objektno-orijentisano programiranje je metod implementacije po kojem su: – programi organizovani kao kolekcije objekata koji sarađuju – svaki objekat predstavlja instancu neke klase i – sve klase su članovi neke hijerarhije klasa u kojoj su klase povezane relacijama nasleđivanja • Proizvod OOP – izvršna aplikacija ili sistem
  • 13. 14 Uvod Elektrotehnički fakultet u Beogradu Objektno-orijentisani jezik • Cardelli & Wegner (1985): Jezik je objektno-orijentisan ako i samo ako ispunjava: – da podržava objekte koji su apstrakcije podataka sa interfejsom preko imenovanih operacija i skrivenim lokalnim stanjem – da objekti imaju pridružen tip (klasu) – da tipovi (klase) mogu nasleđivati atribute nadtipa (natklase) • Ako jezik samo ne podržava nasleđivanje naziva se objektno-baziranim jezikom • Objektno-orijentisani jezici su: – Simula, Smalltalk, Object Pascal, Eiffel, Python, Ada95, C++, Java, C#, Visual Basic.NET, ... • Objektno-bazirani jezici – Ada83, VisualBasic v6,... Principi OO modela • Booch OOA&D (1994): Osnovni (obavezni) Dodatni (neobavezni) apstrakcija tipizacija kapsulacija konkurentnost modularnost perzistencija hijerarhija • Modifikacija: Osnovni (obavezni) Dodatni (neobavezni) apstrakcija konkurentnost kapsulacija perzistencija modularnost hijerarhija polimorfizam Apstrakcija i kapsulacija • Shaw (1984): Apstrakcija je uprošćeni opis ili specifikacija sistema koja naglašava neke od detalja ili osobina, dok potiskuje druge • Booch (1994): Apstrakcija ističe esencijalne karakteristrike objekta koje ga razlikuju od drugih vrsta objekata i tako definiše jasne konceptualne granice iz perspektive posmatrača • Kapsulacija je proces sakrivanja onih elemenata apstrakcije koji definišu strukturu i ponašanje • Kapsulacija služi da razdvoji konceptualni interfejs od implementacije apstrakcije Modularnost i hijerarhija • Modularnost je osobina sistema da se razlaže na skup kohezivnih i slabo spregnutih modula • Moduli su fizičke jedinice (nezavisno prevođenje) – predstavljaju komponete sistema – mogu se održavati nezavisno
  • 14. Uvod 15 Projektovanje softvera • Hijerarhija je rangiranje ili uređivanje apstrakcija • Nasleđivanje - “is a” hijerarhija – jednostruko/višestruko – potpuno (javno)/strukturno (privatno) • Sadržanje - “part of” hijerarhija – po vrednosti/po referenci (relevantno u C++, ali ne u Javi) – agregacija/kompozicija Tipizacija i polimorfizam • Tipizacija je osobina da se objekti različitih klasa ne mogu uopšte ili se mogu zamenjivati na ograničene načine – stroga i slaba tipizacija – statička i dinamička tipizacija (vezivanje) • Dinamička tipizacija i dinamičko vezivanje – tenički preduslov za ispoljavanje polomorfizma • Polimorfizam je osobina da se objekat kojem se pristupa kao objektu osnovne klase ponaša različito: – kao objekat osnovne klase ill kao objekat izvedene klase – ponašanje zavisi od dinamičkog tipa objekta, ne statičkog tipa reference • Polimorfizam objekta se zasniva na virtuelnim metodama Konkurentnost i perzistencija • Principi koji se dobro uklapaju u OO paradigmu • Nisu suštinski principi koji određuju da li je softver OO – OO softver ih nemora posedovati – Softver koji nije OO ih može posedovati • Konkurentnost je osobina koja razlikuje aktivne objekte od pasivnih – proces - ima vlastiti adresni prostor (tipično njime upravlja OS) – nit - deli isti adresni prostor sa drugim nitima • Perzistencija je osobina po kojoj se postojanje objekta proteže – kroz vreme (obj. nastavlja da živi nakon nestanka njegovog stvaraoca) – kroz prostor (obj. se premešta iz adresnog prostora u kojem je stvoren) Model i modeliranje • Model je pojednostavljenje realnosti • Model nekog sistema je apstrakcija tog realnog sistema iz određenog ugla posmatranja • Osnovna namena modela – da se sistem koji se razvija bolje razume • Modeliranje je važnije što je sistem kompleksniji – kompleksnost je odlika današnjih SW sistema • Savremena metodologija razvoja softvera – Model Driven Development (MDD)
  • 15. 16 Uvod Elektrotehnički fakultet u Beogradu Ciljevi modeliranja • Model pomaže da se sistem vizuelizuje • Model omogućava da se specificira – struktura sistema – ponašanje sistema • Model daje šablon koji usmerava konstrukciju sistema • Model dokumentuje projektne odluke koje se donose • Model omogućava ispitivanje projektnih odluka po relativno niskoj ceni OO model i pogledi na model • Model OO analize i projektovanja obuhvata više pogleda na sistem koji se razvija • Dve dimenzije pogleda na sistem: – logički/fizički aspekti – statički/dinamički aspekti • AiP OO sistema se obavlja u terminima klasa, objekata, njihovih relacija i interakcija • Tokom AiP koriste se različiti uglovi gledanja na model sistema u datom 2D prostoru Dijagrami • Za svaki pogled na model sistema može se definisati adekvatan dijagram • Svaki dijagram predstavlja jednu projekciju modela • Primer - aplikacija sa 100 klasa: – potrebno je više klasnih dijagrama (svaki prikazuje jedan pogled na model) • Jedno ime na svakom dijagramu označava isti entitet (sa izuzetkom operacija zbog preklapanja imena) Logički i fizički aspekti modela • Logički model sistema – opisuje ključne apstrakcije i mehanizme koji • obrazuju prostor problema ili • definišu arhitekturu sistema – definiše • strukturu i relacije između klasa • relacije i interakcije između objekata • Fizički model sistema – opisuje konkretnu softversku i hardversku kompoziciju – definiše arhitekturu modula i arhitekturu procesa Statički i dinamički aspekti modela • Statički aspekti modela se fokusiraju na strukturu sistema • Dinamički aspekti modela se fokusiraju na ponašanje sistema • Realni sistemi uvek imaju dinamičko ponašanje: – objekti se kreiraju i uništavaju – objekti šalju poruke drugim objektima nekim redosledom – spoljašnji događaji izazivaju reakcije izvesnih objekata
  • 16. Uvod 17 Projektovanje softvera Notacija za opis modela • Nekoliko notacija zaslužuju posebnu pažnju: – Booch i OMT notacija (iz istorijskih razloga) – UML notacija (standard) • Pogodnosti standardne formalne grafičke notacije: – olakšava se komunikacija između korisnika i članova razvojnog tima – projektant se rasterećuje od nebitnih detalja i koncentriše se na bitne – omogućava se upotreba automatizovanih alata za proveru konzistencije i korektnosti projekta ili izvršavanje modela • Nije neophodno koristiti celu notaciju – na primer Booch Lite, UML Basic (UML User Guide) • Potrebno je da notacija omogućava različit stepen detaljnosti (ponekad samo grube skice) • Notacija treba da bude nezavisna od programskog jezika – neki elementi notacije nemaju direktnu podršku u konkretnom jeziku Alati za modeliranje • IBM Rational: Software Architect (Rose, Rose XDE Developer, Software Modeler) http://www-01.ibm.com/software/rational/products/swarchitect/ • Borland: Together http://www.borland.com/us/products/together/index.aspx • Gentleware: Poseidon for UML http://www.gentleware.com • Open Source: StarUML http://staruml.sourceforge.net/en/ • Altova: Umodel http://www.altova.com/download/umodel/uml_tool.html • Omondo: EclipseUML http://www.omondo.com • Sparx Systems: Enterprise Architect http://www.sparxsystems.com • Visual Paradigm: Visual Paradigm for UML http://www.visual-paradigm.com/product/vpuml • Embarcadero Technologies: ER/Studio Software Architect http://www.embarcadero.com/products/er-studio-software-architect • Pregled alata: http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
  • 17. 18 UML – Pregled jezika Elektrotehnički fakultet u Beogradu Pregled jezika UML • Materijal prireman na osnovu: – Booch,G., Rumbaugh,J., Jacobson,I., The Unified Modeling Language User Guide, 2nd Edition, Addison Wesley, May 2005 – Rumbaugh,J., Jacobson,I., Booch,G., Unified Modeling Language Reference Manual, 2nd Edition, Addison-Wesley, 2004 – Fowler,M., UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition, Pearson Education, 2004 – UML 2 Infrastructure Specification, OMG – UML 2 Superstructure Specification, OMG Standardni jezik za modeliranje UML • UML (Unified Modeling Language) je grafički jezik za: – vizuelizaciju – specifikaciju – konstruisanje i – dokumentovanje • softverski-intenzivnih sistema • UML omogućava konstruisanje šema koje modeliraju sistem opisujući: – konceptualne stvari • npr. proces poslovanja i funkcije sistema – konkretne stvari • npr. klasne tipove, šeme baza podataka, softverske komponente • Sajt: http://www.uml.org/ Korisnici UML-a • Sledeće kategorije korisnika UML-a se uočavaju: – sistem-analitičari i krajnji korisnici: specificiraju zahtevanu strukturu i ponašanje sistema – arhitekti: projektuju sistem koji zadovoljava zahteve – razvojni inženjeri (developers): transformišu arhitekturu u izvršni kod – kontrolori kvaliteta (quality assurance personel): proveravaju strukturu i ponašanje sistema – bibliotekari (librarians): kreiraju i katalogiziraju komponente – rukovodioci projekata (managers): vode i usmeravaju kadrove i upravljaju resursima Praistorija UML-a • Jezici za OO modeliranje se pojavljuju još od sredine 70ih – uzrok njihove pojave je pojava nove generacije OO jezika i povećana kompleksnost softverskih sistema • U periodu 1989-1994: – broj OO metoda je porastao sa manje od 10 na više od 50 • Metode koje su ostvarile najveći uticaj na oblast OO modeliranja su: – Booch metoda – OMT (Object Modeling Technique, Rumbaugh) – OOSE (Object Oriented Software Engineering, Jacobson) – Fusion – Shlaer-Mellor – Coad-Yourdon
  • 18. UML – Pregled jezika 19 Projektovanje softvera Istorija UML-a • 1994: početak rada na UML-u - Rumbaugh se pridružio Booch-u u firmi Rational • Oktobar 1995: pojavila se verzija 0.8 drafta UM-a (Unified Method) • Jesen 1995: Jacobson se pridružio Rational-u – rad na objedinjenju UM sa OOSE • Jun 1996: pojavila se verzija 0.9 UML-a • Važniji partneri (učestvovali u definisanju verzije 1.0): – DEC, HP, IBM, Microsoft, Oracle, Rational, TI, ... • U januaru 1997: OMG-u (Object Management Group) podnet predlog std. UML 1.0 • Grupa partnera je proširena drugim podnosiocima predloga: – npr. ObjecTime, Ericsson,... • Jul 1997: podnet predlog UML 1.1 koji je prihvaćen od OMG 14.11.1997. • Jun 1998: verzija UML 1.2 • Jesen 1998: verzija UML 1.3 • Septembar 2001: verzija UML 1.4 (v. 1.4.2 => ISO std. 19501:2005) • 2002: verzija UML 1.5 (akciona semantika) • Jun 2003: v 2.0, februar 2007: v 2.1, februar 2009: v 2.2, maj 2010: v 2.3 Konceptualni model UML-a • Tri osnovna elementa UML modela su: – Osnovni gradivni blokovi – Pravila za povezivanje gradivnih blokova – Opšti mehanizmi koji se primenjuju u UML-u • Gradivni blokovi UML-a – Stvari (things) • apstrakcije koje su "građani prvog reda" u modelu – Relacije (relationships) • povezuju stvari – Dijagrami (diagrams) • grupišu interesantne skupove povezanih stvari Stvari • Stvari strukture - statički delovi modela, reprezentuju konceptualne ili fizičke elemente (imenice) • Stvari ponašanja - dinamički delovi modela, reprezentuju ponašanje kroz prostor i vreme (glagoli) • Stvari grupisanja - organizacioni delovi modela, kutije u koje model može biti dekomponovan • Stvari anotacije - objašnjavajući delovi modela, komentari koji se primenjuju na bilo koji element
  • 19. 20 UML – Pregled jezika Elektrotehnički fakultet u Beogradu Stvari strukture – klase i interfejsi • Klasa je opis skupa objekata koji dele zajedničke karakteristike (atribute i operacije), ograničenja i semantiku • Aktivna klasa je klasa čiji objekti imaju vlastitu nit kontrole i tako mogu da započnu neku upravljačku aktivnost • Ponašanje objekta aktivne klase je konkurentno sa drugim aktivnim objektima • Interfejs je kolekcija operacija koje specificiraju servis klase ili komponente • Interfejs opisuje ponašanje elementa koje je spolja vidljivo • Interfejs definiše skup specifikacija (prototipova) operacija ali ne i njihove implementacije • Klasa i komponenta mogu da implementiraju više interfejsa Stvari strukture – slučaj korišćenja i saradnja • Slučaj korišćenja (use-case) je opis skupa sekvenci aktivnosti koje obavlja sistem da bi proizveo vidljiv rezultat vredan za pojedinog aktera • Jedna sekvenca aktivnosti – instanca slučaja korišćenja (scenario) • Slučaj korišćenja reprezentuje funkcionalnost sistema (mada se neki autori ne slažu sa tim) • Koirsti se da bi se strukturirale stvari ponašanja u modelu • Realizuje se kroz saradnju (kolaboraciju) • Saradnja (collaboration) definiše zajednicu i interakciju aktera i drugih elemenata koji dejstvuju zajedno Prikaz rasporeda casova IStek Alarm postaviVreme() ukljuci() iskljuci() Tacka x y rastojanje()
  • 20. UML – Pregled jezika 21 Projektovanje softvera da ostvare kooperativno ponašanje koje je kvalitativno novo u odnosu na prostu sumu ponašanja elemenata • Saradnja ima strukturalnu, kao i dimenziju ponašanja • Projektni uzorci (design patterns) se predstavljaju kao saradnje Stvari strukture – komponenta i čvor • Komponenta je fizički i zamenjivi deo sistema koji ostvaruje realizaciju skupa interfejsa Servis.jar • Komponenta je tip koji ima ponuđene i zahtevane interfejse • U sistemu mogu postojati razne vrste izvršnih komponenata, npr. ActiveX ili Java Beans, ili fajlovi izvornog koda • Komponenta obično predstavlja fizičko pakovanje drugih logičkih elemenata kao što su klase, interfejsi i saradnje • Čvor (node) je fizički element koji postoji u vreme izvršenja i reprezentuje resurs obrade • Čvor poseduje neku memoriju i, često, mogućnost procesiranja • Skup komponenata može biti u čvoru, a može i migrirati sa čvora na čvor • Prvih pet stvari reprezentuje konceptualne ili logičke stvari, dok poslednje dve (komponenta i čvor) reprezentuju fizičke stvari • Sve navedene stvari osim saradnje predstavljaju klasifikatore: mehanizme koji opisuju strukturne i karakteristike ponašanja Stvari ponašanja • Interakcija je ponašanje koje obuhvata skup poruka koje se razmenjuju između skupa objekata unutar posebnog konteksta da se ostvari specifična svrha • Interakcija uključuje određen broj elemenata: – poruke (priložen grafički simbol) – – sekvence akcija (ponašanje izazvano porukom) – veze (komunikacione putanje između objekata) Server Posmatrac prikazi() Servis.jar <<component>>
  • 21. 22 UML – Pregled jezika Elektrotehnički fakultet u Beogradu • Automat stanja je ponašanje koje specificira sekvence stanja kroz koje prolazi jedan objekat ili jedna interakcija za vreme svog životnog veka, kao posledice događaja, zajedno sa njegovim odgovorima na te događaje • Automat stanja uključuje određen broj elemenata: – stanja (priložen grafički simbol), – tranzicije (prelaze između stanja) – događaje (stvari koje izazivaju tranziciju) – aktivnosti (odgovore na tranzicije) Stvari organizacije i anotacije • Paket je opštenamenski mehanizam za organizovanje elemenata u grupe • Stvari strukture, ponašanja, pa čak i druge stvari grupisanja mogu biti smeštene u paket • Za razliku od komponente, paket je čisto konceptualna stvar (egzistira samo u vreme razvoja) • Pored paketa postoje i sledeće stvari grupisanja: – radni okviri (frameworks), modeli • Napomena je simbol za prikazivanje komentara pridruženih jednom elementu ili kolekciji elemenata Relacije • Zavisnost je semantička relacija između dve stvari u kojoj izmena jedne (nezavisne) stvari može uticati na semantiku druge (zavisne) stvari • Asocijacija je strukturna relacija koja opisuje skup veza između objekata – sadržanje je specijalna vrsta asocijacije koja reprezentuje strukturnu relaciju između celine i njenih delova – često grafički simbol sadrži ukrase kao što su multiplikativnost i imena uloga +zaposleni+poslodavac 1..*1 FIFO awt Cekanje
  • 22. UML – Pregled jezika 23 Projektovanje softvera • Generalizacija je relacija specijalizacije/generalizacije u kojoj su objekti specijalizovanog elementa (deca) zamene za objekte generalizovanog elementa (roditelja) – dete deli strukturu i ponašanje roditelja • Realizacija je semantička relacija između klasifikatora u kojoj jedan klasifikator specificira ugovor koji drugi klasifikator ostvaruje – Sreće se: • između interfejsa i klasa ili komponenata koje ga realizuju • između slučajeva korišćenja i saradnji koje ih realizuju • Dijagrami • Dijagram je grafička reprezentacija skupa povezanih elemenata – najčešće se pojavljuje u obliku grafa temena (stvari) povezanih granama (relacijama) • Dijagrami se crtaju da bi se sistem vizualizovao iz različitih perspektiva • Vrste dijagrama u UML-u: – dijagrami za prikaz statičkih aspekata sistema – dijagrami za prikaz dinamičkih aspekata sistema Statički dijagrami • Dijagram klasa (class diagram) prikazuje logičku strukturu apstrakcija: skup klasa, interfejsa, saradnji i njihovih relacija • Dijagram objekata (object diagram) prikazuje logičku strukturu instanci: skup objekata (instanci klasa) i njihovih veza • Dijagram komponenata (component diagram) prikazuje fizičku organizaciju i zavisnosti između skupa komponenata • Dijagram raspoređivanja (deployment diagram) prikazuje konfiguraciju čvorova obrade i komponenata koje žive na njima • Dijagram paketa (package diagram) [UML 2] prikazuje statičku strukturu grupisanja elemenata modela u pakete • Dijagram složene strukture (composite structure diagram) [UML 2] prikazuje hijerarhijsko razlaganje primerka klase, komponente ili saradnje na delove Dinamički dijagrami • Dijagram slučajeva korišćenja (use case diagram) prikazuje skup slučajeva korišćenja, aktera (specijalne vrste klasa) i njihovih relacija • Dijagram interakcije (interaction diagram) prikazuje jednu interakciju koju čine skup objekata i njihovih veza sa porukama koje razmenjuju – Dijagram sekvence (sequence diagram) je dijagram interakcije koji naglašava vremenski redosled poruka – Dijagram komunikacije (communication diagram) je dijagram interakcije koji naglašava strukturnu organizaciju objekata koji šalju i primaju poruke; – Dijagram pregleda interakcije (interaction overview diagram) [UML 2] je dijagram interakcije koji definiše interakcije kroz vrstu dijagrama aktivnosti (kombinacija d. aktivnosti i d. sekvence)
  • 23. 24 UML – Pregled jezika Elektrotehnički fakultet u Beogradu – Vremenski dijagram (timing diagram) [UML 2] je dijagram interakcije koji prikazuje promenu stanja objekata u vremenu • Dijagram aktivnosti (activity diagram) prikazuje tok od jedne do druge aktivnosti u sistemu (nije specijalna vrsta dijagrama stanja u UML 2) • Dijagram stanja (statechart diagram) prikazuje konačni automat koji obuhvata stanja, tranzicije, događaje i aktivnosti Pravila UML-a • UML ima pravila koja specificiraju kako izgleda dobro formiran model • Dobro formiran model je – semantički konzistentan – u harmoniji sa korelisanim modelima • UML ima semantička pravila za: – Imena - kako se nazivaju stvari, relacije i dijagrami – Doseg - koji kontekst daje specifično značenje imenu – Vidljivost - gde se imena mogu videti i koristiti od strane drugih – Integritet - kako se stvari propisno i konzistentno korelišu prema drugim stvarima – Izvršenje - šta to znači za izvršenje ili simulaciju dinamičkog modela • Tokom razvoja se ne prave samo modeli koji su dobro formirani, već mogu biti i: – Skraćeni (elided) - izvesni elementi su sakriveni da se pojednostavi izgled – Nekompletni - izvesni elementi nedostaju – Nekonzistentni - integritet modela nije garantovan • Pravila UML-a vode kroz vreme ovakve modele prema dobro formiranim Opšti mehanizmi UML-a • Gradnja je jednostavnija i harmoničnija ako se poštuju opšti uzorci • Postoje četiri opšta mehanizma koja se primenjuju konzistentno kroz jezik: – specifikacije – ukrasi – opšte podele – mehanizmi proširivosti Specifikacije • Iza svakog dela grafičke notacije UML-a leži specifikacija koja obezbeđuje tekstualni iskaz sintakse i semantike tog gradivnog bloka • Iza grafičkog simbola (sličice, ikone) klase stoji specifikacija koja navodi: – potpun skup atributa – potpun skup operacija (uključujući kompletne potpise) – ponašanje • Grafički simbol može pokazivati samo mali deo potpune specifikacije • Može postojati i drugi izgled iste klase koji prikazuje drugi skup delova iste klase konzistentan sa specifikacijom • UML grafička notacija se koristi za vizuelizaciju • UML specifikacija se koristi da se saopšte detalji sistema • Modeli se mogu graditi:
  • 24. UML – Pregled jezika 25 Projektovanje softvera – najpre pomoću crtanja dijagrama, a zatim dodavanjem semantike u specifikaciju (tipično za direktni inženjering pri kreiranju novog sistema) – direktnim kreiranjem specifikacije pa naknadnim kreiranjem dijagrama koji su njene projekcije (tipično za reverzni inženjering postojećeg sistema) Ukrasi • Detalji specifikacije se prikazuju kao grafički ili tekstualni ukras osnovnog grafičkog elementa • Na primer: – za klasu se može naglasiti da je apstraktna tako što se ime piše italic slovima – vidljivost (pravo pristupa) atributa i operacija se može naglasiti pomoću simbola: + (javni), # (zaštićeni), – (privatni) i ~(paketni) – Agregacija se predstavlja dodatnim simbolom na simbolu asocijacije Opšte podele • Dve osnovne podele: – apstrakcije i instance – interfejsi i implementacije • Primeri prve podele: – klase/objekti (klasa je apstrakcija, a objekat instanca te apstrakcije) – slučajevi korišćenja/instance slučajeva korišćenja (scenarija) – komponente/instance komponenti • Primeri druge podele: – interfejsi/komponente – slučajevi korišćenja/saradnje – operacije/metodi • U UML-u se razlika između apstrakcije i instance pravi tako što se imena instanci podvlače • Interfejs deklariše ugovor, a implementacija reprezentuje jednu konkretnu realizaciju ugovora Mehanizmi proširivosti • UML je otvoren za proširenja jezika na kontrolisani način • Mehanizmi proširivosti uključuju: – Stereotipove – Obeležene vrednosti – Ograničenja
  • 25. 26 UML – Pregled jezika Elektrotehnički fakultet u Beogradu Stereotipovi • Stereotip proširuje rečnik UML-a dopuštajući kreiranje novih vrsta gradivnih blokova specifičnih za problem • Novi gradivni blokovi su izvedeni iz postojećih • Stereotop se prikazuje kao ime uokvireno znacima << i >> smešteno iznad imena odgovarajućeg elementa • Na primer, izuzeci su klase čiji se objekti mogu bacati i hvatati • Može se definisati i grafički simbol za određeni stereotip Obeležene vrednosti • Obeležene vrednosti proširuju osobine UML gradivnog bloka dopuštajući dodavanje nove informacije • Obeležene vrednosti se prikazuju kao string okružen zagradama { i } ispod imena odgovarajućeg elementa • String sadrži ime (tag), sepearator (simbol =) i vrednost • Na primer, verzija i autor klase nisu primitivni koncepti u UML-u, a mogu se dodati bilo kom gradivnom bloku kao što je klasa • Ograničenja • Ograničenja proširuju semantiku UML gradivnog bloka dopuštajući da se dodaju nova pravila ili promene postojeća • Ograničenja se mogu pisati: – kao slobodan tekst – na OCL (Object Constraint Language) RedCekanja {verzija=4.0 autor=...} Prekoracenje <<exception>> Merljiv <<interface>> +meri() Merljiv +meri() ⇔ RedCekanja dodaj() ukloni() isprazni() {red uredjen}
  • 26. UML – Prvi primer 27 Projektovanje softvera Prvi primer Uvod • Najbolji način učenja UML-a je kroz kreiranje modela na UML-u • Većina programera kada uči novi jezik – prvo napiše program koji ispiše "Hello, World!" • Početak učenja modeliranja na jeziku UML – model za "Hello, World!" program uz mehanizme Jave koji omogućavaju izvršenje Primer na Javi • Primer: trivijalni aplet koji ispisuje: "Hello, World!“ import java.awt.Graphics; class HelloWorld extends java.applet.Applet{ public void paint(Graphics g){ g.drawString("Hello, World!", 10, 10); } } • Iako je primer programa trivijalan, infrastruktura potrebna da bi aplet radio nije trivijalna Ključne apstrakcije • Osnovni klasni dijagram: • • Klasa HelloWorld ima jednan metod (operaciju) paint() – redefinisni metod klase Component koji "iscrtava" datu komponentu na željeni način – metod se poziva iz okruženja (ne poziva ga programer) i to inicijalno kao i pri pomeranju, otkrivanju, promeni veličine komponente • Komentar (note) kaže šta radi operacija paint() • Osnovne relacije: • Klasa HelloWorld se izvodi iz klase Applet, a koristi klasu Graphics – klasa Graphics se pojavljuje kao tip formalnog argumenta metode paint() (zavisnost) – klasa Graphics omogućava crtanje i pisanje na komponentama (grafički kontekst) – grafičke operacije menjaju bite samo unutar clipping regiona vezanog za objekat Graphics – crtanje i pisanje se obavlja korišćenjem tekućih atributa datog Graphics objekta Applet HelloWorld +paint() Graphics +drawString() HelloWorld +paint() g.drawString("Hello, World!", 10, 10);
  • 27. 28 UML – Prvi primer Elektrotehnički fakultet u Beogradu • Hijerarhija nasleđivanja • ImageObserver je interfejs preko kojeg se primaju obaveštenja o konstrukciji slike – interfejs sadrži (callback) metod imageUpdate() preko kojeg se javlja progres/status konstrukcije slike Grupisanje Ponašanje • Dijagram sekvence (originalni primer je nešto kompleksniji) Komponente HelloWorld +paint() Applet Panel Container Componenet ImageObserver Object Hello.jpg <<artifact>> Hello.htm <<artifact>> HelloWorld.class <<artifact>> Hello.java <<artifact>> : Korisnik : Browser : JVM target : HelloWorld g : Graphics otvoriHTMLStranu() run() paint() drawString() java awt applet lang
  • 28. UML – Dijagrami klasa 29 Projektovanje softvera Dijagrami klasa Uvod • Dijagram klasa prikazuje skup klasa, interfejsa, saradnji i njihovih relacija • Dijagram klasa je graf sačinjen od temena (stvari) povezanih granama (relacijama) • Specificira logičke i statičke aspekte modela • Elementi dijagrama klasa – stvari: klase, interfejsi, saradnje, paketi, objekti (izuzetno) – relacije: zavisnosti, generalizacije, asocijacije, realizacije • Dijagrami klasa su najčešći u objektnom modeliranju • Većina alata podržava generisanje skeleta koda iz dijagrama klasa Klasifikator • Klasifikator je – klasifikacija primeraka (instances) sa zajedničkim karakteristikama – mehanizam koji opisuje strukturu i ponašanje (ima atribute i operacije) – apstraktna metaklasa – prostor imena – tip koji je moguća generalizacija ili specijalizacija drugog – potencijalno ugnežden u drugi klasifikator • Ne pojavljuju se svi klasifikatori na dijagramima klasa • Konkretni klasifikatori su: klase, interfejsi, tipovi podataka, komponente, čvorovi, slučajevi korišćenja, ... • Klasifikator ima odeljke, koji se ne moraju svi prikazati – odeljci mogu imati svoje nazive, da bi se izbegla dvoznačnost kada neki odeljak nedostaje Klasa • UML 2.0 definicija: klasa je opis skupa objekata koji dele istu specifikaciju karakteristika (features), ograničenja (constraints) i semantike – karakteristike: atributi i operacije • Klasa implementira jedan ili više interfejsa • Klase opisuju apstrakcije iz domena problema kao i apstrakcije iz domena rešenja • Koriste se da reprezentuju softverske stvari, hardverske stvari i konceptualne stvari Simbol klase • Simbol klase je pravougaonik podeljen horizontalnim linijama u odeljke – odeljak može imati i naziv odeljka naveden kao stereotip GeometrijskaFigura -karakteristicnaTacka +pomeri() +promeniVelicinu() +crtaj() responsibilities -- geometrijska svojstva figura u ravni naziv atributi operacije odgovornosti
  • 29. 30 UML – Dijagrami klasa Elektrotehnički fakultet u Beogradu • Naziv klase – jednostavan: <naziv> – sa putanjom: <naziv paketa>::<jednostavan naziv> npr: java::awt::Rectangle • Odgovornosti klase – neformalna semantika – u zasebnom odeljku – slobodan tekst – svaka počinje sa -- • Svaka dobro strukturirana klasa bi trebalo da ima barem jednu i ne više od nekoliko odgovornosti Atributi i operacije • Atributi su imenovana svojstva klase koja opisuju opsege vrednosti koje instance tog svojstva mogu sadržati • Drugi nazivi: članovi podaci (C++), polja (Java) • Atributi su strukturne karakteristike (features) klase • Notacija: ime, opciono sa tipom i podrazumevanom vrednošću • Primer: izbor:Boolean=false • Operacije su servisi koji se mogu zahtevati od nekog objekta klase • Notacija: potpis koji sadrži listu argumenata sa eventualnim tipovima i podrazumevanim vrednostima, kao i tipom rezultata • Primer: pomeri(novaPozicija:Pozicija=koordinatniPocetak):Pozicija Dodatne mogućnosti • Simbol klase može sadržati prazne odeljke, a može biti i bez odeljaka Potrosac Potrosac • Prazan odeljak atributa/operacija ne znači da ih klasa nema, već da nisu relevantni za dati pogled (dijagram) • Mogu se koristiti i tri tačke (...) da naznače postojanje dodatnih atributa/operacija • Atributi/operacije se mogu grupisati, a svakoj grupi može da prethoditi opisni prefiks • Apstraktna klasa i apstraktna operacija – naziv se piše italicom ili {abstract} • Zajednički članovi (atributi i operacije) klase – pišu se podvučeno • Pravo pristupa članu (vidljivost, visibility): znak se piše ispred atributa/operacije: – javni član: + (podrazumevano) – zaštićeni član: # – paketski član: ~ – privatni član: -
  • 30. UML – Dijagrami klasa 31 Projektovanje softvera Tipovi podataka • Tipovi podataka (dataType) su tipovi čije vrednosti nemaju identitet • Vrste tipova podataka: – primitivni tipovi • postojeći prosti tipovi podataka u jeziku implementacije – nabrojivi tipovi • uzimaju vrednost iz definisanog skupa simboličkih imena Osobine klasa • Multiplikativnost je osobina klase koja ograničava broj njenih instanci • Multiplikativnost se navodi u gornjem desnom uglu • Specifične vrednosti multiplikativnosti: – 0 – uslužna klasa, sadrži samo zajedničke (statičke) atribute i operacije – 1 – unikatna (singleton) klasa • Podrazumevani slučaj je proizvoljan broj instanci • Koren hijerarhije klasa (root) je klasa koja nema roditelje • List hijerarhije klasa (leaf) je klasa koja nema potomke, tj. ona iz koje se ne može izvoditi • Osobine {root} i {leaf} se pišu u odeljku naziva klase Sintaksa atributa • Sintaksa atrubuta: [pravo_pristupa] [/] ime [:tip] [multiplikativnost] [=inicijalna_vrednost][{osobina}] • Simbol / označava da je atribut "izveden" (može se "izračunati" na osnovu drugih) • Multiplikativnost se primenjuje na atribute klase – specificira se kao interval celih brojeva, gornja granica može biti neograničena – piše se u uglastim zagradama, na primer: consolePort:Port[2..*] • Osobine atributa (neke): – readOnly – vrednost se ne može menjati, dodavati ni uklanjati nakon inicijalizovanja – ordered – vrednosti su uređene – unique – vrednosti elemenata (u jednom objektu) su jedinstvene – bag – dozvoljava ponavljanje elemenata (nije skup) – seq ili sequence – isto što i ordered bag (uređen niz elemenata sa ponavljanjem) – composite – atribut složene strukture – redefines ime – redefiniše ime – subsets ime – podskup skupa atributa ime Sintaksa operacije • Sintaksa operacije: [pravo_pristupa] ime ([lista_argumenata]) [: tip_rezultata] [{osobina}] • Sintaksa argumenta u listi: [smer] ime : tip [multiplikativnost] [ = podrazumevana_vrednost] [{osobina}]
  • 31. 32 UML – Dijagrami klasa Elektrotehnički fakultet u Beogradu • Smer može biti: – in – ulazni argument, ne sme biti modifikovan (podrazumevano) – out – izlazni argument, mora se inicijalizovati – inout – ulazno-izlazni argument, može se modifikovati • Osobine operacije: – query – izvršenje ne menja stanje objekta, operacija je čista funkcija bez bočnih efekata – exception lista – operacija može da baca izuzetke iz liste – leaf – operacija nije polimorfna i ne može se redefinisati u izvedenoj klasi – concurrency = vrednost – šta garantuje operacija pri izvršenju u konkurentnoj sredini • sequential – pozivaoci moraju obezbediti da je samo jedna nit u jednom trenutku poziva • guarded – operacija garantuje sekvencijalizaciju svih poziva svih štićenih operacija • concurrent – operacija se izvršava kao atomska Relacije • Na klasnim dijagramima se pojavljuju sve četiri (prve tri su češće) vrste relacija: – zavisnost (dependency) – asocijacija (association) – generalizacija (generalization) – realizacija (realization) Zavisnost • Povezuje stvari kod kojih izmena nezavisne stvari utiče na ponašanje zavisne stvari • Zavisna stvar koristi nezavisnu stvar • Grafička notacija: klasa A zavisi od klase B • Često se koristi kad je jedna klasa (B) tip parametra operacije druge klase (A) Generalizacija • Povezuje opštije (superklasa ili roditelj) sa specijalizovanim (subklasa ili dete) stvarima • Grafička notacija: klasa A je dete, B je roditelj A B • Drugi nazivi relacije: – vrsta (is-a-kind-of), izvođenje (A se izvodi iz B), nasleđivanje, proširivanje • Generalizacija znači da se objekti dece mogu pojaviti gde god se očekuje objekat roditelja • Deca nasleđuju osobine svojih roditelja, naročito atribute i operacije • Operacija deteta koja ima isti potpis kao operacija roditelja redefiniše operaciju roditelja • Redefinicija operacije omogućava njeno polimorfno ponašanje • Klasa koja ima samo jednog roditelja koristi jednostruko nasleđivanje • Klasa koja ima više roditelja koristi višestruko nasleđivanje A B
  • 32. UML – Dijagrami klasa 33 Projektovanje softvera Asocijacija • Specificira da li su instance jedne stvari povezane sa instancama druge stvari • Asocijacija je strukturna relacija • Asocijacija je (ako se drugačije ne kaže) bidirekcionalna veza (dvosmerna navigabilnost) • Dozvoljena je i asocijacija sa samim sobom (postoje veze između objekata iste klase) • Uobičajeno je da asocijacija povezuje dve klase (binarna asoc.) • Moguće je da asocijacija povezuje i više klasa (n-arna asocijacija) • Grafička notacija: klasa A je u asocijaciji sa klasom B A B Realizacija • Semantička relacija između klasifikatora od kojih jedan specificira ugovor a drugi garantuje njegovu implementaciju • Grafička notacija: – kanonička forma: – skraćena forma: I K • Korišćenje interfejsa (relacija zavisnosti) – kanonička forma: – skraćena forma (ball & socket): Kijent I K Primer osnovnih relacija Prozor +otvori() +zatvori() +pomeri() +prikazi() +obradiDogadjaj() Dogadjaj Konzolni prozor Dijalog Komponenta Kijent I <<interface>> K I <<interface>>K
  • 33. 34 UML – Dijagrami klasa Elektrotehnički fakultet u Beogradu Ukrasi asocijacije • Na asocijaciji se mogu pojaviti sledeći ukrasi: – Iime, smer čitanja, uloge, navigabilnost, multiplikativnost, sadržanje (agregacija ili kompozicija), pravo pristupa (vidljivost) kraju preko asocijacije Multiplikativnost • Na jednoj strani asocijacije označava se broj objekata sa te strane koji su u vezi sa tačno jednim objektom sa druge strane relacije • Može biti: – nijedan (0), – tačno jedan (1), – proizvoljno mnogo, uključujući nijedan (*), – opseg (npr. 2..*) • UML 2.0 više ne dozvoljava izraze sa diskontinuitetom – npr. 0..1,3..4,6..* - proizvoljan broj osim 2 i 5 Agregacija • Vrsta asocijacije kod koje jedna strana igra ulogu celine a druga ulogu dela (whole/part) • Celina sadrži delove ("has-a" relacija) • Agregacija ne govori ništa o uzajamnom odnosu životnih vekova celine i dela • Deo u agregaciji može biti zajednički deo više celina • Grafička notacija: Celina Deo Kompozicija • Asocijacija kod koje postoji odnos celina/deo, ali je celina odgovorna za životni vek dela • Agregacija sa strogim vlasništvom i koincidentnim životnim vekom dela u odnosu na celinu • Deo može nastati u toku života celina i može biti uništen pre uništenja celine • Deo u kompoziciji može biti deo samo jedne celine • Grafički notacija: Celina Deo Osoba Kompanija Odeljenje Radi za -poslodavac-zaposlen 11..* *1 Asocijacija Multiplikativnost Naziv Sadržanje Uloga
  • 34. UML – Dijagrami klasa 35 Projektovanje softvera Primer asocijacija Fakultet Katedra Student Predmet Nastavnik ima 1 1..* studira 1..* * pohadja ** predaje -predavac-kurs 1..** radi pri -jedinca -clan 1 * upravlja -sef1 0..1 odgovara za 1..* * Navigacija • Strelica označava navigabilnost u naznačenom pravcu • Krstić označava da nema navigabilnosti prema označenoj strani • Za asocijaciju bez ukrasa navigabilnosti se smatra da je navigabilnost neodređena • Grafička notacija: Pravo pristupa preko asocijacije • Ograničava vidljivost (visibility) objekata u asocijaciji za spoljašnji svet • Označava se sa + , #, -, ~ ispred imena uloge odgovarajuće strane relacije • + znači da objektima sa te strane mogu pristupati svi objekti preko objekta sa druge strane • - znači da objektima klase sa te strane mogu pristupati samo objekti klase sa druge strane • # znači da i objekti klasa izvedenih iz klase sa drugog kraja asocijacije imaju pristup • ~ znači da i objekti klasa iz istog paketa kao klasa sa drugog kraja asocijacije imaju pristup • Primer: GrupaKorisnika Korisnik Lozinka +korisnik * * -kljuc-vlasnik 1..*1 • Podrazumevan je javni vizibilitet uloge u asocijaciji Ugnežđivanje • Označava pojam kada je klasa B deklarisana u prostoru imena klase A • A BA B A BA B A B+
  • 35. 36 UML – Dijagrami paketa Elektrotehnički fakultet u Beogradu Dijagrami paketa Uvod • Dijagrami paketa se koriste da prikažu dekompoziciju modela u organizacione jedinice i njihove zavisnosti • Dijagrami paketa pomažu: – da se uoče zavisnosti između logičkih celina i – da se te zavisnosti drže pod kontrolom • Primer: Paket • Paket je organizaciona stvar koja se koristi za grupisanje elemenata • Paket predstavlja prostor imena i element koji se može pakovati, tako da se može sadržati u drugim paketima • Definicija uz UML RM: – paket je opšti mehanizam za organizovanje elemenata u grupe, koji uspostavlja vlasništvo nad elementima i obezbeđuje jedinstvenost imena elemenata • Paketi se koriste – uobičajeno za grupisanje logičkih apstrakcija modela (klasa) – mogu se koristiti i za grupisanje fizičkih stvari (komponenata ili čak čvorova) • Paket može da obuhvata druge pakete i proste elemente – obično postoji jedan paket u korenu hijerarhije paketa koji predstavlja ceo model • Koncept paketa odgovara – istoimenom konceptu u jeziku Java – konceptu prostora imena u jezicima C++ i C# Imenovanje paketa i elemenata • Jedno ime elementa mora biti jedinstveno u okviru paketa – ali se može koristiti za označavanje drugih elemenata iz drugih paketa • Jednoznačnost imena se odnosi na puna (kvalifikovana) imena – puna imena sadrže redom imena svih paketa u hijerarhiji od korenog paketa do datog elementa - lista u stablu, razdvojena simbolom :: • Primer: – klasa Panel koju sadrži potpaket awt paketa java nosi puno ime java::awt::Panel • Elementi kojima se unutar paketa može obraćati jednostavnim (nekvalifikovanim) imenima su: – sopstveni elementi paketa, – uvezeni elementi i – elementi iz obuhvatajućih (spoljašnjih) prostora imena (paketa) P2 PP C D P3 B P1 <<import>>
  • 36. UML – Dijagrami paketa 37 Projektovanje softvera Vlasništvo i pravo pristupa • Vlasništvo nad sopstvenim elementom implicira – ako se paket ukloni iz modela, uklanjaju se i sopstveni elementi paketa – svaki element modela mora imati kao vlasnika • neki paket ili • drugi element modela • Sopstveni i uvezeni elementi mogu imati pravo pristupa • Pravo pristupa određuje da li su elementi na raspolaganju izvan paketa • Pravo pristupa elementa u paketu može biti: – javno (+) ili – privatno (-) • Javni sadržaj paketa je uvek pristupačan izvan paketa preko punih imena • Paket "izvozi" svoj javni sadržaj • Za "uvoz" imena iz drugih paketa koriste se posebne relacije zavisnosti Notacija • Za paket se koristi simbol pravougaonika sa jezičkom Osoblje – simbol sugeriše folder koji sadrži: • fajlove (jednostavne elemente) i • druge foldere (potpakete) • Sadržani elementi paketa se mogu predstaviti na više načina: – samo tekstualno nabrojani unutar pravougaonika simbola paketa (tada se ime paketa piše unutar jezička) – nacrtani unutar pravougaonika simbola paketa (i tada se ime paketa piše unutar jezička) – povezani punom linijom sa simbolom + unutar kružića na strani paketa Relacije • Zavisnosti i stereotipovi zavisnosti: <<import>>, <<access>>, <<merge>> • Zavisnost: – označava da barem jedan element u zavisnom paketu zavisi od nekog elementa iz nezavisnog paketa – primer: ako je klasa X u paketu P1 izvedena iz klase Y iz paketa P2, paket P1 zavisi od paketa P2 • Javno uvoženje (<<import>> ): – omogućava u paketu u koji se uvozi (na strani repa strelice) korišćenje javnih imena iz uvezenog paketa (na strani glave strelice) bez kvalifikacije – uvezeni elementi se ponašaju kao javni u paketu u koji su uvezeni Tipovi Integer Float Tipovi Tipovi Integer Float + Integer Float Tipovi
  • 37. 38 UML – Dijagrami paketa Elektrotehnički fakultet u Beogradu • Privatno uvoženje (<<access>> ): – omogućava u paketu A u koji se uvozi (na strani repa strelice) korišćenje javnih imena iz uvezenog paketa B (na strani glave strelice) bez kvalifikacije, ali se uvezena imena paketa B ne mogu koristiti bez kvalifikacije u paketu C koji (javno) uvozi imena iz paketa A – uvezeni elementi paketa B imaju status privatnih elemenata u paketu A u koji su uveženi • Alternativna notacija za uvoz pojedinih imena iz drugog paketa je navođenje unutar paketa u koji se uvozi: – {import <kvalifikovano ime>} ili – {access <kvalifikovano ime>} • Uvoz imena sadržanog paketa se ne podrazumeva, a može se naznačiti na sledeći način: • Mešanje (<<merge>> ): – komplikovana relacija čije korišćenje nije potrebno u modeliranju – koristi se u metamodeliranju • Elementi paketa unutar paketa ili između paketa mogu biti povezani svim vrstama relacija – na primer, unutar paketa se može predstaviti klasni dijagram, koji može da sadrži i druge pakete Principi modeliranja • Pri projektovanju sistema se nastoji da se broj zavisnosti između paketa minimizira – u paket se smeštaju apstrakcije koje uzajamno imaju veći broj relacija i relativno mali broj relacija prema apstrakcijama izvan paketa • Nije dobro da postoje cirkularne zavisnosti između paketa – dobro je da se apstrakcije grupišu slojevito tako da jedan paket predstavlja jedan sloj (nivo) apstrakcija, pa se relacije zavisnosti između paketa orijentišu samo u jednom smeru • Pravilo zajedničkog zatvaranja (Common Closure Principle [R.C. Martin]): – preporučuje da u istom paketu budu klase koje treba menjati iz sličnih razloga • Pravilo zajedničkog ponovnog korišćenja (Comon Reuse Principle [R.C. Martin]) – preporučuje da u istom paketu budu klase koje će se zajedno ponovo koristiti • Tehnika za sužavanje javnog interfejsa paketa – svodi se na izvoženje samo malog broja operacija javnih klasa paketa – klase paketa se učine privatnim, a uvede se posebna klasa sa javnim operacijama koje pozivaju odgovarajuće javne operacije privatnih klasa paketa (uzorak Fasada) C A B <<import>> <<access>> P PP <<import>>
  • 38. UML – Dijagrami paketa 39 Projektovanje softvera Stereotipovi paketa • Iznad imena paketa može stajati naznaka stereotipa << … >> • Standardni stereotipovi paketa: – koriste se određene ključne reči da označe vrstu paketa – model: <<model>> • semantički potpun opis sistema • umesto ključne reči može da se koristi mali trougao – radni okvir: <<framework>> • generička arhitektura kao proširiv obrazac za apikacije u nekom domenu • tipično elementi predstavljaju osnovu za specijalizaciju • Podsistem <<subsystem>> nije stereotip paketa, već komponente – u UML-u 1 je smatran stereotipom paketa Bankomat Bankomat
  • 39. 40 UML – Dijagrami objekata Elektrotehnički fakultet u Beogradu Dijagrami objekata Uvod • Dijagrami objekata prikazuju primerke (objekte) apstrakcija (klasa) i njihove veze preko kojih objekti mogu da komuniciraju • Oni predstavljaju “snimak”pogleda na sistem u jednom trenutku – prikazuju se objekti sa trenutnim stanjem i trenutne veze • Dijagram objekata opisuje fizički i statički aspekt modela – fizički, jer je objekat fizička stvar, nalazi se u memoriji – statički, jer se prikazuju samo veze, a ne i interakcija preko njih • Elementi dijagrama objekata su: – stvari: objekti i paketi – relacije: veze • Dijagram ima strukturu grafa: objekti su čvorovi, a veze grane Namena • Dve osnovne namene: – prikaz složene strukture koju čini više objekata – prikaz ponašanja kroz vreme preko niza “snimaka” povezanih objekata • Dijagram objekata predstavlja samo primer, a ne specifikaciju (definiciju) modela • Ima dokumentacionu svrhu, može da pomogne razumevanju modela Objekti • Objekat je nešto (u memoriji) što ima stanje, ponašanje i identitet • Objekat je primerak apstrakcije (tipa, klase) • UML notacija: – pravougaonik sa odeljcima imena i vrednosti atributa – ime podvučeno – objekat može biti: konkretan, prototipski, anonimni objekat2 : KlasaKlasa -atribut1: tipAtributa1 -atribut2: tipAtributa2 objekat1 : Klasa atribut1 = vrednost1 atribut2 = vrednost2 : Klasa Veze • Veze su komunikacione putanje između objekata • Veze su primerci (instance) asocijacija – jedna asocijacija između dve klase predstavlja skup veza između objekata tih klasa • Na vezama se mogu naći – svi ukrasi asocijacije osim multiplikativnosti – multiplikativnost je uvek 1 Klasa1 Klasa2 *1 objekat1 : Klasa1 objekat2 : Klasa2 objekat3 : Klasa2 objekat4 : Klasa2
  • 40. UML – Dijagrami objekata 41 Projektovanje softvera Primer – uzorak Kompozicija • Opis hijerarhije objekata uzorka Kompozicija – Sklop je Element koji sadrži druge elemente – rekurzivna struktura sadržanja – hijerarhija objekata tipa stabla Element List Sklop 1 * koren : Sklop list1 : List list2 : List sklop1 : Sklop list3 : List list4 : List Dijagram klasa Dijagram objekata Primer - relacija “pohađa” • Opis relacije “pohađa” između studenata i kurseva – asocijacija označava veze koje se menjaju u vremenu – veze su različite u svakoj školskoj godini Student -brIndeksa: String Kurs +sifra: String student1 : Student brIndeksa = 06/321 student2 : Student brIndeksa = 05/123 kurs3 : Kurs sifra = IR4PS kurs4 : Kurs sifra = IR4XX pohadja ** Dijagram klasa Skolska 2009/10 student1 : Student brIndeksa = 06/321 student2 : Student brIndeksa = 05/123 kurs1 : Kurs sifra = IR2OO1 kurs2 : Kurs sifra = IR2XXX Skolska 2007/08 Dva objektna dijagrama
  • 41. 42 UML – Dijagrami interakcije Elektrotehnički fakultet u Beogradu Dijagrami interakcije Uvod • Interakcija je ponašanje koje obuhvata skup poruka koje se razmenjuju između skupa objekata u nekom kontekstu sa nekom namenom • UML 2.0: interakcija je specifikacija slanja stimulusa između objekata sa ciljem obavljanja nekog zadatka – definiše se u kontekstu neke saradnje (kolaboracije) • Interakcija se koristi za modeliranje dinamičkih aspekata modela • Objektni dijagram je reprezentacija statičkih aspekata komunikacije – prezentiraju se samo objekti i veze između objekata u jednom trenutku • Interakcija uvodi dinamički aspekat komunikacije – prezentira se i sekvenca poruka koje razmenjuju uloge Kontekst interakcije • Kontekst interakcije može biti: – sistem ili podsistem – operacija – klasa – slučaj korišćenja • Kontekst – sistem ili podsistem kao celina – interakcije su u saradnji objekata koji postoje u sistemu ili podsistemu – primer: sistem za e-trgovinu: sarađuju objekti na strani klijenta sa objektima na strani servera • Kontekst – operacija – interakcije su među objektima koji implementiraju operaciju – parametri operacije, lokalni i globalni objekti mogu interagovati da izvrše algoritam operacije • Kontekst – klasa – atributi klase mogu sarađivati međusobno kao i sa drugim objektima (globalnim, lokalnim i parametrima operacija) – interakcija se koristi da opiše semantiku klase • Kontekst – slučaj korišćenja – interakcija reprezentuje scenario za slučaj korišćenja Poruka • Poruka je specifikacija komunikacije između objekata koja prenosi informaciju, iza koje se očekuje da sledi aktivnost • Slanje poruke ulozi označava samo stimulus za aktivnost • Poruka može biti – asinhrona (slanje signala) – sinhrona (poziv operacije ) • Poruka se prikazuje kao strelica na dijagramu interakcije – razne vrste strelica odgovaraju raznim vrstama poruka – na dijagramu sekvence – poruke su linije između linija života – na dijagramu komunikacije – poruke su strelice pored konektora
  • 42. UML – Dijagrami interakcije 43 Projektovanje softvera Vrste dijagrama interakcije • Dijagrami interakcije mogu biti: – dijagrami sekvence – dijagrami komunikacije (u UML 1: dijagrami saradnje, odnosno kolaboracije) – dijagrami pregleda interakcije (UML 2) – vremenski dijagrami (UML 2) • Dijagrami sekvence naglašavaju vremensko uređenje interakcije • Dijagrami komunikacije naglašavaju strukturu veza između učesnika u interakciji • Ove dve vrste dijagrama vizuelizuju na različit način praktično iste informacije • Dijagrami pregleda interakcije kombinuju dijagram aktivnosti sa dijagramima sekvence – u okviru toka kontrole, blokovi (čvorovi) se opisuju interakcijama • Vremenski dijagrami prikazuju promenu stanja jednog objekta (ili uloge) u vremenu – promena stanja se dešava kao posledica prijema stimulusa i dešavanja događaja Dijagrami sekvence i komunikcije • Dijagram sekvence • Dijagram komunikacije a : b : : C d : Klijent 1 : m1() 2 : m2() 3 : m3() 4 : m4() 5 : r4 6 : r37 : r2 8 : r1 a : A b : B : C d : Klijent m1() m2() m3() m4() r5 r3 r2 r1
  • 43. 44 UML – Dijagrami interakcije Elektrotehnički fakultet u Beogradu Uloge i njihove linije života • Linija života (lifeline) – reprezent jednog učesnika (entiteta, objekta) u interakciji – notacija (UML 2): naziv uloge (na liniji života) se ne podvlači – alat StarUML dodaje kosu crtu ispred naziva uloge • Objekti koji učestvuju u jednoj interakciji mogu biti: – konkretne stvari – stvari iz realnog sveta • na primer, o kao primerak klase Osoba može označavati konkretnu osobu – prototipske stvari – označavaju proizvoljnu stvar nekog tipa • na primer, o kao primerak klase Osoba može predstavljati proizvoljnu osobu • U saradnjama – objekti su prototipske stvari koje igraju specifične uloge – objekti nisu konkretne stvari (primerci) iz realnog sveta • U interakciji se mogu pojaviti “primerci" apstraktnih klasa i interfejsa – ovde primerci ne označavaju konkretne stvari (nemogući su primerci apstraktnih klasa i interfejsa) – ovde primerci predstavljaju prototipske stvari (primerci potklasa) Konektori • Na d. objekata se prikazuju pojave (objekti), a na d.interakcije – uloge • Na d. objekata se prikazuju veze, a na d.komunikacije – konektori • Veza – strukturna sprega između objekata – primerak asocijacije • Konektor – komunikaciona putanja između uloga – ne mora da bude primerak asocijacije, može biti privremena veza • Ukrasi načina pristupa drugoj strani konektora – specificiraju način na koji uloga koja šalje poruku vidi drugu stranu – tekstualni ukrasi koji se pišu na udaljenom kraju veze (kod primaoca) – konkretni ukrasi: • {association} – objektu se pristupa preko instance asocijacije datih klasa • {self} – objekat sam sebi šalje poruku • {global} – objekat je u nekom okružujućem dosegu • {local} – objekat je u lokalnom dosegu • {parameter} – objekat je argument operacije /uloga:Tip StarUML uloga:Tip UML 2 objekat : Tip2 UML 1 uloga1 : Klasa1 uloga2 : Klasa2
  • 44. UML – Dijagrami interakcije 45 Projektovanje softvera Slanje i prijem poruke • Prijem jedne poruke se može smatrati pojavom jednog događaja • Kada se pošalje i primi poruka, sledi aktivnost na strani prijema – izvršenje naredbe koja predstavlja apstrakciju metoda • UML predviđa sledeće vrste poruka: – poziv (call) – pokreće operaciju uloge primaoca (može biti i poziv sebi) – povratak (return) – vraća vrednost pozivaocu – slanje (send) – asinhrono se šalje signal primaocu – kreiranje (create) – kreira se objekat (primerak uloge) – uništavanje (destroy) – uništava se objekat – pronađena poruka (found) – poznat primalac, slanje nije opisano – izgubljena poruka (lost) – poznat pošiljalac, prijem se nije dogodio – postajanje (become) – objekat menja prirodu (na obe strane je isti objekat) • Poruke su horizontalne, jer se podrazumeva atomičnost stimulusa (poruke) – ako se stimulus ne može smatrati atomičnim – poruka može biti crtana i ukoso naniže • Kod poruke vrste poziva (call) podrazumeva se "sinhronost": – pozivalac ne napreduje dok pozvani objekat ne završi obradu poziva – cela sekvenca ugneždenih poziva se završava pre nego što se spoljašnji nivo izvršenja nastavi – koristi se za: • proceduralne pozive u jednoj niti • pozive za randevu (npr. Ada) u višeprocesnom okruženju signal <<create>> <<destroy>> <<become>> operacija()
  • 45. 46 UML – Dijagrami interakcije Elektrotehnički fakultet u Beogradu • Primer raznih vrsta poruka na dijagramu sekvence: Sekvenciranje poruka • Unutar toka kontrole neke niti – poruke su uređene u vremensku sekvencu • U dijagramima sekvence – sekvenca se modelira implicitno ređanjem poruka odozgo-naniže • U dijagramima komunikacije – sekvenca se modelira rednim brojem ispred imena • Grafička notacija: – proceduralni (ugnežđeni) tok kontrole se prikazuje strelicama sa popunjenom glavom • redni brojevi poruka imaju hijerarhijsku strukturu (nivoi hijerarhije se razdvajaju tačkom) • primer: – ravni (flat) tok kontrole se prikazuje običnim strelicama (asinhrone poruke) • redni brojevi poruka nemaju hijerarhisku strukturu • primer: • Primer ravne sekvence : Lopov : Vrata : Alarm 1 : otvori 2 : aktiviraj u1 u2 : Tip2 Tip2() <<create>> o1() r1 s1 <<destroy>> stvaranje primerka uloge u2 sinhrona poruka, poziv operacije o1 vracanje rezultata r1 asinhrona poruka, slanje signala s1 uništavanje primerka uloge u2 2.1.3:op() 5: s
  • 46. UML – Dijagrami interakcije 47 Projektovanje softvera Sekvenciranje poruka u nitima • Identifikacija niti se piše iza rednog broja poruke u kojoj se vrši konkurentno grananje: – primer: • aktivnost pokrenuta 1. porukom ima konkurentno grananje, pa se posmatra 5. poruka u niti a – primer: • aktivnost pokrenuta 3. porukom se konkurentno grana, reč je o 2. poruci u okviru aktivnosti pokrenute 5. porukom u niti b Sintaksa poruke • Na poruci se osim imena mogu prikazati i – njeni argumenti – vraćena vrednost – pridruživanje vraćene vrednosti promenljivoj • vrednost se može koristiti kao argument neke naredne poruke • po pravilu (ne mora biti), promenljiva je atribut klase pošiljaoca – primer: 1.2:prosekGod=uspeh(godStud):srednjaOcena • Argumenti se mogu pisati i sa imenom – primer: 5:trazenaOsoba=trazi(ime="Petar Petrović") Životni vek objekata i veza • Po nekad se životni vek objekta ili veze ne poklapa sa trajanjem interakcije • Objekti i veze mogu nastajati i nestajati u toku interakcije • Sledeća ograničenja se mogu pripisati objektu i/ili vezi (UML 1) – {new} – objekat/veza se kreira za vreme izvršenja interakcije – {destroyed} – objekat/veza se uništava pre završetka interakcije – {transient} – objekat/veza se kreira i uništava za vreme interakcije • Promena stanja ili uloge objekta na dijagramu interakcije se naznači njegovom replikacijom (UML 1) – na dijagramu sekvence sve varijante jednog objekta se smeštaju na istu vertikalnu liniju – na dijagramu komunikacije varijante se povezuju porukom <<become>> Događanje izvršenja (fokus kontrole) • Fokus kontrole se može naznačiti samo na dijagramima sekvence – uski pravougaonik na liniji života – definiše period u kojem uloga obavlja aktivnost izazvanu porukom • Moguće je i ugnežđivanje fokusa kontrole iz sledećih razloga: – (A) zbog rekurzije ili poziva sopstvene (druge) operacije – (B) zbog povratnog poziva (call back) od pozvanog objekta 1a.5:dohvati() 3b.5.2:dohvati()
  • 47. 48 UML – Dijagrami interakcije Elektrotehnički fakultet u Beogradu • Grafička notacija: Primer Bankomat – dijagram sekvence Primer Bankomat – dijagram komunikacije : Klijent a b o1() o2() o3() r3 r2 o4() r1 povratni poziv rekurzivni poziv bankomat : Bankomat racun : Racun klijent : Klijent banka : Banka /transakcija : Transakcija kartica promptPIN unosPINa(PIN) provera(kartica, PIN) OKOK promptKomanda isplata(iznos) isplati(kartica, iznos) <<create>> racun := dohvatiRacun(kartica) isplataSaRacuna(racun, iznos) citajStanje() stanje umanjiStanje(iznos) novoStanjenovoStanje <<destroy>> {transient} novoStanjenovoStanje novac klijent : Klijent bankomat : Bankomat banka : Banka transakcija : Transakcija racun : Racun 1 : kartica 2 : promptPIN 3 : unosPINa(PIN) 6 : OK 7 : promptKomanda 8 : isplata(iznos) 20 : novoStanje 21 : novac 4 : provera(kartica, PIN) 5 : OK 9 : isplati(iznos) 19 : novoStanje 10<<create>> 11 : racun := dohvatiRacun(kartica) 12 : isplataSaRacuna(racun, iznos) 13 : citajStanje() 14 : stanje 15 : umanjiStanje(iznos)16 : novoStanje 17 : novoStanje 18 <<destroy>> {transient}
  • 48. UML – Dijagrami interakcije 49 Projektovanje softvera Iteracije i grananje • Izrazi za iteracije i grananje se pišu iza broja za sekvenciranje poruke, na bilo kom nivou ugnežđenja • Izraz za sekvencijalne iteracije: – brojač ponavljanja *[i:=1..n] ili uslov *[a>b] ili samo * – poruka se ponavlja u skladu sa izrazom • Oznaka za paralelne iteracije: – *|| • Izraz za grananje: – [x>0] – dve ili više poruka u sekvenci mogu imati isti redni broj, ali onda moraju imati disjunktne uslove Fragment (okvir) interakcije • Fragment interakcije je najopštija jedinica interakcije • Opisuje deo interakcije i konceptualno je isti kao i sama interakcija • Višestruki primerci (multiobjekti) – UML1, zastareli u UML2 Operatori kombinovanih fragmenata • Opšti – sd - dijagram sekvence ili komunikacije (uokviruje ceo dijagram) – neg - negativno – fragment prikazuje pogrešnu interakciju – ref - referenca – interakcija je definisana na drugom dijagramu • Kontrola sekvencijalnog toka – opt - opcioni fragment – izvršava se samo ako je ispunjen uslov – alt - alternativni izbor između više fragmenata – loop - petlja – fragment se izvršava više puta – break - scenario se izvršava umesto ostatka okružujućeg fragmenta • Kontrola paralelnih tokova – par - paralelno se izvršavaju fragmenti – region - kritični region – u fragmentu se ne može istovremeno izvršavati više niti RaznosnjePostesd : Postar : Posta : Posiljka : Primalac preuzimanjePosiljki() *[1..n] : dohvati() posiljke posiljka *[1..n] : isporuka
  • 49. 50 UML – Dijagrami interakcije Elektrotehnički fakultet u Beogradu Primer operatora okvira interakcije • Distribucija porudžbina – neka objekat :Porudzbina ima metod slanje procedure slanje foreach (stavka) if (vrednost<=1000) redovniDistributer.isporuci() else specijalniDistributer.isporuci() endif endfor if (potrebnaPotvrda) kurir.potvrdi() end procedure – neka akter :Prodavac pokreće slanje porudžbina signalom – neka je cela komunikacija asinhrona DistribucijaPorudzbinasd loop [foreach stavka] opt [potrebnaPotvrda] [foreach stavka] opt [potrebnaPotvrda] opt [potrebnaPotvrda][potrebnaPotvrda] alt [vrednost<=1000] [else] [vrednost<=1000] [else] : Prodavac : Porudzbina : RedovniDistributer : SpecijalniDistributer : Kurir slanje isporuci isporuci potvrdi
  • 50. UML – Dijagrami slučajeva korišćenja 51 Projektovanje softvera Dijagrami slučajeva korišćenja Uvod • Dijagram slučajeva korišćenja (use-case) prikazuje skup slučajeva korišćenja i aktera • Tipično se koristi da specificira neku funkcionalnost i ponašanje nekog subjekta (npr. projektovanog sistema) • Dijagram vizuelizuje ponašanje sistema, podsistema ili čak klase i interfejsa • Služi korisniku da razume šta sistem radi, a verifikatoru da proveri funkcionisanje • Elementi dijagrama su: – slučajevi korišćenja – akteri – relacije: asocijacije (komunikacija), zavisnosti (uključivanje i proširivanje) i generalizacija – paketi Slučajevi korišćenja • Slučaj korišćenja je opis skupa sekvenci akcija, uključujući varijante, koje subjekat (sistem) obavlja da bi proizveo vidljiv rezultat od vrednosti za pojedinog aktera • Sekvenca akcija reprezentuje interakciju aktera sa subjektom i ključnim apstrakcijama subjekta • Jedna sekvenca akcija predstavlja jedan mogući scenario slučaja korišćenja – jedan scenario je jedna pojava (događanje) slučaja korišćenja • Slučaj korišćenja specificira šta subjekat radi, a ne kako radi • Gafički simbol i alternativne notacije: imeSK1 imeSK2 imeSK3 Ponašanje slučaja korišćenja • Ponašanje slučaja korišćenja se opisuje tokom događaja: – kada slučaj korišćenja počinje i kada završava – kada slučaj korišćenja interaguje sa akterima – kada se razmenjuju poruke i objekti • Postoje primarni (osnovni) i alternativni tokovi događaja • Tok događaja se može opisati na sledeće načine: – neformalan tekst na govornom jeziku – strukturirani tekst (sa pred- i post-uslovima) – pseudokod – dijagrami interakcije • jedan za primarni i dodatni za alternativne tokove – dijagram stanja subjekta – dijagram aktivnosti – saradnja (u kojoj učestvuju i akteri) Primer opisa ponašanja • Preduslov za sve tokove događaja: platna kartica u bankomatu
  • 51. 52 UML – Dijagrami slučajeva korišćenja Elektrotehnički fakultet u Beogradu • Glavni tok događaja za proveru korisnika pri transakciji sa bankomatom: – slučaj korišćnja počinje kada sistem ispiše prompt za PIN broj – korisnik unosi PIN broj preko numeričke tastature – korisnik potvrđuje unos pritiskom na Enter taster – sistem proverava da li PIN broj odgovara karitci – provera uspela, završava se slučaj korišćenja – postuslov: omogućena promena na računu korisnika • Prvi alternativan tok događaja (poništavanje transakcije): – korisnik poništava transakciju pritiskajući Cancel taster - slučaj korišćenja se ponavlja – postuslov: nije omogućena promena na računu korisnika • Drugi alternativan tok događaja (pogrešan PIN): – korisnik unosi pogrešan PIN broj - slučaj korišćenja se ponavlja – ako se ovo ponovi tri puta za redom sistem poništava celu transakciju i sprečava korisnika da ponovo pokuša 60s – postuslov: nije omogućena promena na računu korisnika Akteri • Akter predstavlja neki koherentan skup uloga • Akter može biti čovek (korisnik) ili neki sistem sa kojim modelirani subjekat interaguje • Subjekat interaguje sa jednim ili više aktera • Akter je standardni stereotip klase sa posebnim grafičkim simbolom A1 A2 <<actor>> Relacija komunikacije • Prikazuje se punom linijom (asocijacija): • Komunikaciju može inicirati akter ili slučaj korišćenja (bidirekcionalna veza) • Relacija dozvoljena između: – aktera i slučaja korišćenja – dva slučaja korišćenja koja se ne odnose na isti subjekat • Multiplikativnost >1 na strani aktera – za događanje slučaja korišćenja potrebno više aktera (konkurentno ili sekvencijalno) Relacija uključivanja • Prikazuje se isprekidanom linijom sa strelicom i natpisom <<include>> – relacija je stereotip relacije zavisnosti SK A BA <<include>>
  • 52. UML – Dijagrami slučajeva korišćenja 53 Projektovanje softvera • Relacija uključivanja od slučaja korišćenja A prema slučaju korišćenja B ukazuje da će slučaj korišćenja A uključiti i ponašanje slučaja korišćenja B • Ponašanje opisano u B je obavezno za A • Koristi se da opiše zajedničko ponašanje između više slučajeva korišćenja – na primer: slučajevi korišćenja SK1, SK2 i SK3 uključuju ponašanje SK Primer – korisnici foruma • Dijagram opisuje najavu korisnika na forum Relacija proširivanja • Prikazuje se isprekidanom linijom sa strelicom i natpisom <<extend>> – relacija je stereotip relacije zavisnosti • Relacija proširivanja od slučaja korišćenja A prema slučaju korišćenja B ukazuje da B može obuhvatiti ponašanje specificirano u A • Praktično B može da se proširi i ispolji celokupno ponašanje opisano u A • Koristi se da se izrazi opciono ponašanje osnovnog slučaja korišćenja – ponašanje opisano u A je opciono, a ono u B osnovno • Problem sa terminom stereotipa <<extend>> – sličnost sa ključnom rečju extends jezika Java – sasvim različito značenje SK1 SK2 SK3 SK <<include>> <<include>> <<include>> Administartor Moderator Pisac Gost Adiministriranje Brisanje poruka Manipulacija temama Pisanje komentara Citanje komentara Najava <<include>> <<include>> <<include>> <<include>> A B <<extend>>
  • 53. 54 UML – Dijagrami slučajeva korišćenja Elektrotehnički fakultet u Beogradu Tačke proširenja slučaja korišćenja • Osnovni slučaj korišćenja se proširuje u određenim tačkama ponašanja – tačka se naziva tačkom proširenja (ekstenzije) • Alternativne notacije: SK1 extension points tacka1 tacka2 SK2 tacka1 tacka2 extension points SK2 tacka1 tacka2 extension points SK3 tacka1 tacka2 extension points • Tačka se navodi po sintaksi: ime [: objašnjenje] • Primer: identifikacija pozivaoca je opciona funkcija telefona Relacija generalizacije • Prikazuje se punom linijom sa trougaonom strelicom • Relacija je osnovna relacija generalizacija/specijalizacija A B • Relacija generalizacije od slučaja korišćenja A prema slučaju korišćenja B ukazuje da je slučaj korišćenja A specifičan slučaj opštijeg slučaja B • Primer: Najava Korisnicko ime i lozinka Kartica i PIN Otisak prsta Duzica oka Biometrija identifikacija pozivaoca prijem poziva prvo zvono extension points <<extend>> condition: {posle prvog zvona} extension point: prvo zvono
  • 54. UML – Dijagrami slučajeva korišćenja 55 Projektovanje softvera Okvir subjekta • Slučajevi korišćenja su “unutar”, a akteri “izvan” subjekta modeliranja • Vizuelizacija – okvir subjekta: System A B C AB AA • Subjekat nije vlasnik slučajeva korišćenja koji predstavljaju njegove funkcionalnosti • Vlasnik može biti klasa, paket ili model Primer – Info sistem fakulteta System System System Student Nastavnik Izbor predmeta Uplata Banka <<subsystem>> Evidencija <<subsystem>> Finansije Pregled primanja Odrzana nastava Obracun primanja Referent Nastavni plan Info studenti Info nastavnici Honorarni nastavnici <<extend>> Provera ID <<include>> <<include>> <<include>> <<include>> Ime-lozinka Kartica-PIN <<subsystem>> Najava <<include>> <<include>>
  • 55. 56 UML – Dijagrami aktivnosti Elektrotehnički fakultet u Beogradu Dijagrami aktivnosti Uvod • Dijagrami aktivnosti su namenjeni modeliranju dinamičkih aspekata (ponašanja) sistema • Slični konvencionalnim dijagramima – kontrole toka (flow-chart) – toka podataka (data-flow) • Prikazuju sekvencijalne i konkurentne korake u procesu obrade • Mogu se koristiti za opis: – toka poslovnog procesa – toka neke operacije • Semantika akcija – uvedena u UML1.5 – uz definisanje sintakse akcija – formalna specifikacija ponašanja – podrška za izvršive modele Odnos prema drugim dijagramima • Dijagram interakcije prikazuje – tok poruka koje se razmenjuju između objekata • Dijagram stanja prikazuje – tok promene stanja objekta • Dijagram aktivnosti prikazuje – tok aktivnosti koju izvršavaju objekti – eventualno i tok objekata između koraka aktivnosti • Dijagram aktivnosti prikazuje ponašanje koristeći modele toka kontrole i toka podataka Aktivnosti i akcije • Aktivnost je specifikacija parametrizovanog ponašanja koje se izražava kroz tok izvršenja preko sekvenciranja i konkurisanja podaktivnosti – elementarne jedinice podaktivnosti – pojedine akcije – aktivnost reprezentuje neatomsku obradu koja se dekomponuje na jedinice • Simbol aktivnosti: StarUML: aktivnost • Akcija je osnovna jedinica specifikacije ponašanja koja reprezentuje neku transformaciju ili obradu u modeliranom sistemu – akcija je osnovni izvršni element aktivnosti • osnovna jedinica izvršne funkcionalnosti – akcija predstavlja jedan korak u aktivnosti koji se obično dalje ne dekomponuje – aktivnost predstavlja kontekst akcije ime aktivnosti
  • 56. UML – Dijagrami aktivnosti 57 Projektovanje softvera • Simbol akcije: StarUML: akcija Aktivnosti • Svaka aktivnost se može predstaviti posebnim dijagramom • Aktivnost definiše parametrizovano ponašanje – može se ponavljati na više mesta u dijagramu • Akcija se dešava samo jednom na datom mestu unutar date aktivnosti Akcije • Akcije mogu biti: – pokretanje aktivnosti • pozivi operacija • slanje signala – čitanje (vraćanje vrednosti) ili upis (promena stanja) podataka • kreiranje ili uništavanje objekata (vrsta upisa) – izračunavanje • izvršenje primitivnih (npr. aritmetičkih) operacija i funkcija • Izvršenje akcije koja pokreće neku aktivnost obuhvata izvršenje te aktivnosti (njenih akcija) - takva akcija nije atomska • Akcija se može posmatrati i kao diskretan element i kao složeno ponašanje: – kao deo strukture u modelu aktivnosti • akcija je diskretan element (aktivnosti) – kao specifikacija ponašanja • akcija može pokrenuti ponašanje (aktivnost) proizvoljne složenosti • Akcija može biti inicirana iz sledećih razloga: – završeno izvršavanje prethodnih akcija – objekat je postao raspoloživ – dogodio se spoljašnji događaj (izvan modeliranog toka kontrole) • Akcija može imati skupove ulaznih i izlaznih grana aktivnosti – one specificiraju tok kontrole ili tok objekata od i prema drugim čvorovima dijagrama aktivnosti – akcija neće početi izvršenje dok: • nisu završene sve aktivnosti koje prethode po ulaznim granama • nisu svi objekti na ulaznim granama raspoloživi • nisu svi ulazni uslovi ispunjeni – završetak izvršenja akcije omogućava izvršenje skupa sledećih akcija ime akcije ime aktivnosti ime aktivnosti akcija A akcija Bulazni parametar izlazni parametar
  • 57. 58 UML – Dijagrami aktivnosti Elektrotehnički fakultet u Beogradu • UML 1: stanje akcije reprezentuje izvršenje neke atomske operacije – atomska operacija ne može biti dekomponovana – događaji se mogu dešavati za vreme izvršenja akcije ali ona se neće prekinuti – smatra se da traje beznačajno kratko vreme Elementi dijagrama aktivnosti • Dijagrami aktivnosti su grafovi koji sadrže: – čvorove: • akcije i aktivnosti • objekti • slanja signala (send signal) • prihvatanja događaja (accept event) • prihvatanja vremenskog događaja (accept time event) • kontrolni čvorovi: − sekvencijalna grananja i spajanja u toku kontrole (decision i merge) − konkurentna grananja i spajanja u toku kontrole (fork i join) • pseudočvorovi: početni, završni i kraj toka • konektori – grane: • prelazi (tranzicije) između akcija • tok objekata Pseudočvorovi, tranzicije, konektori • Grafička notacija pseudočvorova: – za početni čvor: – za završni čvor (kraj svih tokova): – za kraj jednog (konkurentnog) toka: • Prelaz (tranzicija) je legalna putanja od jednog do drugog čvora • Grafička notacija: – poslednji oblik – izvorište je objekat (ne konkretni, već prototipski - uloga), a n je broj objekata izvorišta koji se koriste u čvoru aktivnosi (akcije) – specijalne vrednosti: all, null – primer: formiranje fudbalskog tima ime {weight=n} Igrač {weight=10} Golman {weight=1} Formiranje fudbalskog tima
  • 58. UML – Dijagrami aktivnosti 59 Projektovanje softvera • Konektori sa istim imenom predstavljaju jednu tranziciju • Grafička notacija: Sekvencijalna grananja • Grananje specificira alternativne putanje kojima će se ići u zavisnosti od uslova • Isti simbol se koristi za grananje i spajanje sekvencijalnog toka kontrole: – više grana može izlaziti iz simbola sekvencijalnog grananja (decision) • uslov se piše u uglastim zagradama na grani • [else] grana – ako nije ispunjen ni jedan uslov – više grana može ulaziti u simbol sekvencijalnog spajanja (merge) • Dozvoljeno je kombinovanje grananja i spajanja u jednom kontrolnom čvoru Primeri grananja i iteracije • Iteracija se formuliše pomoću grananja • Primeri: grananje: iteracija: A B C [ uslov ] [ else ] Grananje postavi iterator [ kraj ] radi() pomeri iterator [ not kraj ] petlja sa izlazom na vrhu Konkurentna grananja • Nit kontrole se može u nekoj tački granati na više konkurentnih niti • Račvanja (fork) i udruživanja (join) niti se obavljaju u sinhronizacionim tačkama • Grafička notacija: Priprema Aktivnost 1 Aktivnost 2 Zavrsetak A A
  • 59. 60 UML – Dijagrami aktivnosti Elektrotehnički fakultet u Beogradu Tok objekata • Tok objekta se može naznačiti tako što se (prototipski) objekat povezuje simbolima prelaza sa akcijama • Akcije mogu kreirati, čitati, modifikovati ili uništavati objekat • Grafička notacija: – nožice (pinovi) koje predstavljaju objekat A1 A2 K[S] K[S] – alternativna sintaksa: – tok objekata u UML 1: • u pravougaoniku: klasa[stanje] • isprekidanim strelicama • poseban tok u odnosu na tok kontrole: paralelno sa granom prelaza između akcija • naziv objekta podvučen Primer Plivačke staze • Plivačke staze (swimlanes) specificiraju odgovornosti za delove celokupne aktivnosti • Nemaju neku duboku semantiku • Staza reprezentuje neki subjekat odgovoran za sprovođenje akcije – objekat aplikacije ili entitet realnog sveta K [S]A A K [S] A1 A2 A1 A2 [ u1 ] A3 A4 A7 [ else ] [ u2 ] A5 A6 A8 [ else ] poeetak aktivnosti akcija uslov sekvencijalno spajanje sekvencijalno grananje konkurentno grananje konkurentno spajanje kraj toka aktivnost završetak aktivnosti [O1] objekat A7
  • 60. UML – Dijagrami aktivnosti 61 Projektovanje softvera • Notacija plivačkih staza: subjekat 1 subjekat 2 subjekat 3 A B C D • Akcije pripadaju stazama • Tranzicije mogu prelaziti iz jedne staze u drugu plivačku stazu Hijerarhijske staze i particije • Hijerarhijska plivačka staza: Višedimenzione particije: Particija 1 Particija 1 Particija 2 Particija3 Particija 1 Particija4 Particija 2 Dimenzija 2 Dimenzija 1
  • 61. 62 UML – Dijagrami aktivnosti Elektrotehnički fakultet u Beogradu Primer dijagrama aktivnosti Izuzeci • Bacanje i obrada izuzetaka: • Tok aktivnosti sa bacanjem izuzetka, hvatanjem izuzetka i nastavkom aktivnosti ispitni blok bezbedan blok 2 blok obrade Izuzetak bezbedan blok 1 aktivnost koja baca izuzetak aktivnost koja hvata i obrađuje izuzetaktip izuzetka Kupa Prodava Magaci zahtevanje prihvatanje placanj Narudzbenica Narudzbenica izdavanje isporuka Narudzbenica Narudzbenica prijem naplat Racun Racun HvatanjeBacanje
  • 62. UML – Dijagrami aktivnosti 63 Projektovanje softvera Signali i događaji • Grafička notacija za signale i događaje: – slanje signala slanje signala – prihvatanje događaja prijem signala – prihvatanje vremenskog događaja • npr. čekanje zadato vreme Primer slanja i prihvatanja signala • Konkurentno izračunavanje binarne komutativne operacije – (1) sinhrona komunikacija inicijalizacija racunanje levog operanda racunanje rezultata operacije racunanje desnog operanda – (2) asinhrona komunikacija cekanje prvog operanda slanje levog operanda racunanje levog operanda racunanje desnog operanda slanje desnog operanda inicijalizacija cekanje drugog operanda racunanje rezultata operacije
  • 63. 64 UML – Dijagrami aktivnosti Elektrotehnički fakultet u Beogradu Oblast ekspanzije • Oblast strukturirane aktivnosti koja se izvršava više puta, u skladu sa elementima ulazne kolekcije (ekspanzionog čvora) – izvršava se jednom za svaki element u ulaznoj kolekciji • Grafička notacija: • Stereotipovi oblasti: <<iterative>>, <<parallel>> Centralni bafer • Vrsta čvora objekta • Namena: upravljanje tokovima objekata iz više izvora prema više odredišta • Simbol: • Primer: ulazni ekspanzioni cvor izlazni ekspanzioni cvor Proizvod Magacin 1 Proizvodjac 1 Potrosac 1 <<instantiate>> <<use>> Proizvodnja Proizvodnja Proizvod [proizveden] <<centralBuffer> Potrosnja Potrosnja Proizvod [proizveden Proizvod [proizveden Proizvod [proizveden] Proizvod [proizveden K [S] <<centralBuffer>>
  • 64. UML – Dijagrami aktivnosti 65 Projektovanje softvera Skladište podataka • Vrsta čvora objekata • Namena: opis podataka koji su permanentno na raspolaganju • Razlika u odnosu na centralni bafer – podaci c. bafera su prolazni, a podaci skladišta podataka su stalni • Simbol: • Primer: Upis studenta BazaStudenata <<datastore>> Pohadjanje predmeta Prikaz podataka o studentu <<selection>> student.indeks==xx/yyyy K [S] <<dataStore>>
  • 65. 66 UML – Dijagrami stanja Elektrotehnički fakultet u Beogradu Dijagrami stanja Uvod • Automat stanja (state machine) – ponašanje koje specificira sekvence stanja kroz koja prolazi neki objekat ili interakcija, kao odgovor na događaje, proizvodeći akcije – modelira ponašanje nekog entiteta ili protokol interakcije • Entitet reaguje na događaje promenom stanja – promena stanja izaziva nove događaje i akcije • Dijagram stanja je graf koji prikazuje automat stanja – čvorovi su stanja – grane su prelazi • Dijagrami stanja se fokusiraju na događajima vođeno ponašanje • Dijagrami aktivnosti se fokusiraju na tok aktivnosti • Dijagrami stanja se kreiraju za entitete koji pokazuju bitno dinamičko ponašanje • Dijagram stanja - formalna specifikacija ponašanja • U osnovi se koriste Harelovi dijagrami sa modifikacijama da budu OO Kontekst primene automata stanja • Može biti: – instanca klase – slučaj korišćenja – akter – podsistem/sistem – metod/operacija • Automat stanja se primenjuje da specificira ponašanje – elemenata modela koji moraju odgovarati na asinhrone događaje – elemenata modela čije tekuće ponašanje zavisi od istorije • Automat stanja se uspešno koristi za modeliranje ponašanja reaktivnih sistema – reaktivni sistem je onaj koji odgovara na signale koje daju akteri iz spoljašnjeg sveta Elementi dijagrama stanja • Dijagram stanja prikazuje: – stanja i pseudostanja (čvorovi grafa), – prelaze (tranzicije) između stanja (grane grafa) – događaje koji prouzrokuju promenu stanja i – akcije koje rezultuju iz promene stanja Stanja i podautomati stanja • Stanje je situacija u toku životnog veka entiteta u kojoj entitet može da postoji • U jednom stanju entitet – zadovoljava neki uslov, – obavlja neku aktivnost ili – čeka događaj
  • 66. UML – Dijagrami stanja 67 Projektovanje softvera • Primeri: – uslov – student je u stanju upisan ili stanju mirovanja – aktivnost – program se nalazi u stanju izvršavanja – čekanje – procesor je zaustavljen (halt) i čeka prekidni signal • Grafička notacija: Cekanje • Podautomat stanja – stanje koje reprezentuje automat stanja koji se može pojaviti na više mesta unutar dijagrama stanja – referenca na drugi automat stanja unutar nekog autmata stanja Elementi stanja • Ime – tekst koji razlikuje jedno od drugih stanja – upisuje se u odeljak imena (unutar simbola stanja) ili – u poseban pravougaoni jezičak iznad gornjeg levog ugla simbola stanja – stanje može biti i anonimno (bez imena) • Ulazni efekat (akcija) – radnja koja se obavi pri ulasku u stanje • Izlazni efekat (akcija) – radnja koja se obavi pri izlasku iz stanja • Aktivnost u stanju – radnja koja se izvršava dok je objekat u datom stanju • Odloženi događaji – lista događaja koji se ne obrađuju u datom stanju već se smeštaju u red čekanja • Unutrašnje tranzicije – tranzicije koje obrađuju događaj i zadržavaju objekat u istom stanju – različite su od samo-tranzicije: ne izazivaju izlaznu pa ulaznu akciju • Podstanja – stanja koja postoje unutar datog stanja, sekvencijalno ili konkurentno aktivna Primer stanja Cekanje ulazni efekat (akcija) Studiranje entry/upis do/ucenje exit/diplomiranje zaposlenje/defer promenaModula/priznavanje aktivnost u stanju odloženi događaj izlazni efekat (akcija) Unutrašnji prelaz s:S s:S
  • 67. 68 UML – Dijagrami stanja Elektrotehnički fakultet u Beogradu Pseudostanja i specijalna stanja Početno (initial) Završno (final) Ulazno (entry) Izlazno (exit) Sinhro (fork/join) Izbor (choice) Spoj (junction) Plitka istorija (shallow h.) H Duboka istorija (deep h.) H* • Ulazno/izlazno pseudostanje: – ulazna/izlazna tačka podautomata stanja – identifikuje odgovarajuće stanje datog podautomata • Pseudostanja izbor/spoj se koriste za grane (prelaze) Prelazi • Prelaz je relacija između dva stanja • Prelaz ukazuje da objekat napušta jedno stanje obavlja akciju i ulazi u drugo stanje kada se dogodi specificirani događaj i kada je ispunjen specificirani uslov • Grafička notacija – strelica: S1 S2 • Elementi prelaza – događaj je zbivanje koje nema trajanje i može prouzrokovati prelaz – zaštitni uslov je Bulov izraz koji čini prelaz mogućim kada je uslov ispunjen – akcija je radnja koja je pridružena prelazu i može biti • poziv operacije objekta vlasnika automata stanja ili drugog objekta koji je vidljiv datom objektu • slanje signala nekom objektu • kreiranje ili uništavanje drugog objekta A Bdogadjaj [ uslov ] / akcija
  • 68. UML – Dijagrami stanja 69 Projektovanje softvera Primer dijagrama stanja • Sistem klima-uređaja Mealy i Moor automati • Kada se modelira ponašanje objekta akcije se mogu vezivati za: – stanja ili – prelaze • Automat može biti: – Moor-ovog tipa - sve akcije vezane za stanja – Mealy-jevog tipa - sve akcije vezane za prelaze • U praksi dijagrami stanja kombinuju Moor i Mealy automate Primer automata Mealy-jevog tipa • Automat stanja za parsiranje poruka - niza znakova koji odgovaraju sintaksi: – '<' string '>' string ';' • Prvi string predstavlja oznaku (tag), a drugi telo poruke (body) • Automat radi beskonačno – nema završnog stanja Složena stanja • Jednostavno stanje – stanje koje nema unutrašnju strukturu automata stanja • Složeno (kompozitno) stanje – stanje koje ima unutrašnja stanja, tj. predstavlja automat stanja • Složena stanja se koriste da se smanji grafička kompleksnost Neaktivno Hladjenje Grejanje naTemp prehladno(zeljenaTemp) naTemp pretoplo(zeljenaTemp) pretoplo(zeljenaTemp) prehladno(zeljenaTemp) Cekanje znak( z )[ z!='<' ] / return false PrijemOznake znak( z )[ z=='<' ] PrijemTela znak( z )[ z=='>' ] znak( z )[ z!='>' ] / oznaka.dodaj(z); return false znak( z )[ z!=';' ] / telo.dodaj(z); return false znak( z )[ z==';' ] / return true
  • 69. 70 UML – Dijagrami stanja Elektrotehnički fakultet u Beogradu • Nadstanje – stanje koje obuhvata više unutrašnjih (ugnežđenih) stanja • Podstanje je unutrašnje (ugnežđeno) stanje • Kada se objekat nalazi u podstanju – istovremeno se nalazi i u nadstanju • Podstanja mogu biti: – sekvencijalna – konkurentna Sekvencijalna podstanja • Prelazi se mogu događati: – između podstanja – između podstanja ili nadstanja i stanja izvan nadstanja (spoljašnjeg stanja) • Ako je nadstanje cilj tranzicije iz spoljašnjeg stanja – nadstanje mora sadržati početno stanje • Ako je nadstanje izvor tranzicije – najpre se napušta podstanje pa nadstanje • Pri tranziciji u/iz nadstanja izvršavaju se ulazne/izlazne akcije i nadstanja i podstanja SpoljasnjeStanje1 SpoljasnjeStanje2 Nadstanje Podstanje1 Podstanje2 Podstanje1 Podstanje2 SpoljasnjeStanje1 SpoljasnjeStanje2 Nadstanje Podstanje1 Podstanje2 Podstanje1 Podstanje2 Primer sekvencijalnih podstanja • Registracija studenata za kurs InicijalizacijaKursa do/ inicijalizujKurs() PonistenKurs do/ slanjeUpozorenja() Registracija Otvorena Zatvorena exit/ spisakStudenata.kreiraj() entry/ registrujStudenta() dodajStudenta[ broj<15 ] entry/ kompletriajKurs() [ broj=15 ] dodajStudenta / broj=0 ponistiKurs
  • 70. UML – Dijagrami stanja 71 Projektovanje softvera Stanje sa istorijom • Kada se uđe u nadstanje obično se kreće od inicijalnog podstanja • Ponekad postoji potreba da se krene od podstanja iz kojeg je napušteno nadstanje • Simbol H u kružiću ukazuje da nadstanje pamti istoriju Nadstanje Podstanje1 Podstanje2 Podstanje3 H Podstanje1 Podstanje2 Podstanje3 H SpoljasnjeStanje1 • Simbol H u kružiću označava "plitku" istoriju – pamti se istorija samo neposredno ugnežđenog automata stanja • Simbol H* u kružiću označava "duboku" istoriju – pamti se istorija do najugnežđenijeg automata stanja proizvoljne dubine Konkurentna podstanja • Konkurentna podstanja – dva ili više automata stanja koja se izvršavaju u paraleli – izvršavaju se u kontekstu odgovarajućeg objekta, kao i sekvencijalna • Drugi način da se modelira konkurentnost je pomoću aktivnih objekata – umesto deljenja jednog automata stanja objekta na dva konkurentna podstanja definišu se dva aktivna objekta od kojih je svaki odgovoran za ponašanje jednog podstanja • Od više sekvencijalnih podstanja na jednom nivou – objekat može biti samo u jednom • Od više konkurentnih podstanja na jednom nivou – objekat je u svakom od njih • Prelaz u stanje sa konkurentnim podstanjima predstavlja fork prelaz • Prelaz iz stanja sa konkurentnim stanjima predstavlja join prelaz – sva konkurentna podstanja moraju biti završena da bi se izvršio prelaz join iz nadstanja – ako jedno konkurentno podstanje stigne do završnog stanja pre drugog – čeka na drugo • Sekvencijalna podstanja koja obrazuju svako od konkurentnih podstanja – mogu imati početno, završno ili pseudostanja
  • 71. 72 UML – Dijagrami stanja Elektrotehnički fakultet u Beogradu Primer konkurentnih podstanja Slanje signala • Kada se iz akcije šalje signal nekom objektu, taj objekt se može prikazati na dijagramu • Objekat je vezan sa stanjem (izvornim) stereotipom send relacije zavisnosti Neaktivno odrzavanje fork join Testiranje Komandovanje Odrzavanje Testiranje uredjaja Samo- dijagnostika Cekanje Komanda [ nastavak ] pritisnutTaster [ kraj ] Stanje1 Stanje2 dogadjaj[ uslov ] /cilj.signal(arg) cilj <<send>>
  • 72. UML – Dijagrami klasa – napredni pojmovi 73 Projektovanje softvera Dijagrami klasa – napredniji pojmovi Aktivne klase • Aktivni objekat je onaj koji poseduje vlastiti tok kontrole koji se odvija paralelno/konkurentno sa drugim tokovima kontrole • Aktivna klasa je klasa čije su instance aktivni objekti • Aktivni objekti su “koreni” pojedinih tokova kontrole – oni pozivaju svoje ili metode drugih objekata • Tok kontrole se pokreće/zaustavlja: – kada se aktivni objekat kreira/uništava – mogu postojati i posebne operacije za pokretanje i zaustavljanje • Mnogi jezici podržavaju aktivne objekte (Ada, Java, Smalltalk) • Aktivni objekti i aktivne klase se mogu pojaviti u dijagramima gde i pasivni Procesi i niti • Proces (process, task) je "teški" (heavyweight) tok kontrole – ima vlastiti adresni prostor • Nit (thread) je "laki" (lightweight) tok kontrole – deli zajednički adresni prostor sa drugim nitima • Jedan proces može sadržati više niti • Proces je jedinica konkurentnosti u operativnim sistemima: – procesi konkurišu za resurse • Primeren mehanizam za komunikaciju: – procesi - razmena poruka (message passing) – niti - deoba zajedničkih podataka (data sharing) Aktivne klase - notacija • Grafički simbol aktivne klase: UML 1: UML2: Sabirac – poseban odeljak se predviđa za signale koje klasa može primati • Nit (thread) UML 1: UML 2: • Proces (process) UML 1: UML 2: Kompresor <<process>> SabiracSabirac <<thread>> Kontroler Signals PeriferalSpreman Kompresor <<process>>
  • 73. 74 UML – Dijagrami klasa – napredni pojmovi Elektrotehnički fakultet u Beogradu Šabloni • Šablon (template) je parametrizovani element – C++, Ada, Java podržavaju šablone (generike) • Primer na C++: template <class Element, int Broj> class GenerickiBafer{ public: virtual void stavi(const Element&); virtual Element& uzmi(); ... }; typedef GenerickiBafer<Predmet,100> Bafer; // eksplicitno generisanje GenerickiBafer<Predmet,100> bafer; // implicitno generisanje Šabloni - notacija • Primer generičkog bafera: – definicija šablona i eksplicitno generisanje iz njega: implicitno generisanje: GenerickiBafer<Element->Predmet, Broj->100> Izuzeci • Izuzeci su vrste signala koji se modeliraju stereotipom klase <<exception>> • Signal šalje operacija koja izaziva izuzetak – modelira se stereotipom <<send>> relacije zavisnosti • Primer: Klasa asocijacije • Sama asocijacija može imati svoje atribute • Ti atributi pripadaju klasi koja opisuje asocijaciju (slično veznoj tabeli kod relacionih baza) GenerickiBafer +stavi(Element) +uzmi(): Element Element Broj : Integer = 10 Bafer <Element->Predmet,Broj->100><<bind>> StekPun <<exception>> Stek +stavi(Element) raises StekPun +uzmi(): Element raises StekPrazan <<send>> StekPrazan <<exception>> <<send>>
  • 74. UML – Dijagrami klasa – napredni pojmovi 75 Projektovanje softvera • Primer: N-arna asocijacija • Asocijacija može povezivati više od 2 klase – takva asocijacija se naziva n-arnom • Svaka instanca n-arne asocijacije je n-torka vrednosti odgovarajućih klasa • Primer ternarne asocijacije (sa klasom asocijacije): Kvalifikacija • Koristi se da označi ključ (kvalifikator) koji se koristi za selekciju objekta iz neke strukture • Objekat strukture za datu vrednost ključa selektuje jedan ili grupu elemenata • Učesnici u relaciji su Struktura i njen Element – element(i) strukture se izdvaja(ju) uz pomoć ključa • Kvalifikator može imati više atributa, oni su atributi asocijacije • Atributi kvalifikatora imaju istu sintaksu kao i atributi klasifikatora, sem inicijalne vrednosti • Grafička notacija: – ukras je deo asocijacije, ne klase • Primeri struktura kojima se pristupa pomoću ključa su – heš tabela, B-stablo, … • Multiplikativnost na kraju asocijacije kod klase Element: – moguće kardinalnosti skupa selektovanih objekata uparivanjem sa objektom strukture uz zadatu vrednost ključa: • 0..1 – može da bude selektovan jedinstven objekat, ali postoje i vrednosti ključa za koje se ne selektuje ni jedan objekat * Tim Igrač Sezona Statistika pobeda izgubljenih * * Firma Lice +zaposleni+poslodava c 1..** Posao +opis +datumZaposlenja +plata Struktura Element 0..1 kljuckljuc
  • 75. 76 UML – Dijagrami klasa – napredni pojmovi Elektrotehnički fakultet u Beogradu • 1 – svaka moguća vrednost kvalifikatora selektuje jedinstvenu instancu elementa • * – vrednost kvalifikatora deli skup elemenata u podskupove • Primeri: SahTabla Polje 11 red kolona red kolona Specifikator interfejsa (UML 1) • Uloge mogu implementirati samo neke od interfejsa koje realizuju klase u asocijaciji • Ime interfejsa koji zadovoljava uloga - iza dvotačke koja sledi naziv uloge • Primer 1: • Primer 2: Predmet Podsetnik -podsetnik:IPodsetnik Cuvar -podsetnik:ICuvani Generalizacioni skupovi • Relacija generalizacije/specijalizacije uspostavlja odnos između posebnog i opšteg • Ponekad se specijalizacija vrši po nekom klasifikacionom kriterijumu – kriterijum klasifikacije određuje podtipove – često objekti podtipova ne mogu biti i jedne i druge klase (ograničenje disjoint) • Generalizacioni skup definiše poseban skup relacija generalizacije koji opisuje na koji način se natklasa specijalizuje • Ograničenja generalizacionog skupa (pišu se u zagradama {}): – disjoint/overlaping • da li objekti podtipova mogu biti isključivo jednog od podtipova generalizacionog skupa – complete/incomplete • da li podtipovi predstavljaju potpuni skup mogućih podtipova Notacija i primer • Primer generalizacionog skupa pol: – potklase klase Osoba mogu biti Muskarac, Zena i Zaposleni – generalizacije prema potklasama Muskarac i Zena pripadaju generalizacionom skupu pol Osoba Muskara c Zena Zaposleni {complete, disjoint} Muskarac {incomplete} pol zaposlenje Osoba Muskarac Zena Zaposleni ---------------------------- pol Struktura Element 0..1 kljuckljuc Osoba * 1 supervizor:IUpravnik 1 radnik:IZaposleni *
  • 76. UML – Dijagrami klasa – napredni pojmovi 77 Projektovanje softvera Metaklasa • Metaklasa je klasifikator čije su instance klase • Primer: – metaklasa Class u metamodelu (metajeziku) UML-a opisuje apstrakciju klase – instance ove metaklase su klase u modelu koji kreiramo – metamodel je model kojim se specificira jezik za modeliranje Powertype • Powertype je klasifikator čije su sve instance deca (potklase) nekog roditelja • Powertype je takođe metatip (tip u metamodelu), ali korisnički – instance tog metatipa su tipovi (klase) koji su podtipovi nekog drugog tipa u modelu • Formalno: – ako je A tip, tada je Power(A) tip čije su sve instance podtipovi tipa A – ako je tip B instanca tipa Power(A), tada je B podtip A • Primer: instance Model (Yugo, Megan,...) su deca klase Automobil UML 1 UML 2 • U gronjem primeru Model je metatip za klase Yugo, Megan • UML 1: – odredište stereotipa relacije zavisnosti <<powertype>> je powertype klasifikator – stereotip zavisnosti <<instanceOf>> se koristri za veze klasa-->metaklasa Konteksti relacije realizacije • Realizacija se koristi u dva konteksta: – kontekst interfejsa (realizuje ga klasa ili komponenta) – kontekst slučajeva korišćenja (realizuje ga kolaboracija) • Klasni dijagram: FIFOred IKruzniBafer +stavi() +uzmi() • Dijagram komponenata: PosloviStampaca IBafer Automobil Model <<powertype>> Yugo Megan <<powertype>> <<instanceOf>> <<instanceOf>> Automobi Mode1* Yug Mega :Mode l 1* FIFOred IKruzniBafer <<interface>> +stavi() +uzmi()
  • 77. 78 UML – Dijagrami klasa – napredni pojmovi Elektrotehnički fakultet u Beogradu • Dijagram slučajeva korišćenja: Parametrizovana kolaboracija • Koristi se za opis projektnih uzoraka • Definicija uzoraka "posmatrač“ – parametrizovana saradnja: • Konkretna saradnja koja realizuje uzorak "posmatrač": Projektni uzorci • Drugi način za opis konkretne saradnje • Na prethodnom primeru: Standardni stereotipovi klasifikatora • Legenda: – naglašeno – stereotip specificiran kao standardni i u UML 2 (profili L2 i L3) – obično – nije naveden kao zastareo, ali nije naveden ni kao std. stereotip UML 2 – kurziv – stereotip eksplicitno naveden kao zastareo ProveraLozinke ProveraIdentiteta UzorakPosmatrac s:Subjekat p:Posmatrac Posmatrac Subjekat Posmatrac UzorakPosmatrac<SubjekatStatistika, PosmatracHistogram> naziv uzorka Ucesnik1 Ucesnik2 uloga1 uloga2 Posmatrac Model Histogram Subjekat Posmatrac
  • 78. UML – Dijagrami klasa – napredni pojmovi 79 Projektovanje softvera • utility – klasa čiji su atributi i operacije zajednički za sve instance klase • focus – klasa koja implementira glavnu (poslovnu) logiku • auxiliary – klasa koja pomaže focus klasi u implementaciji logike • stereotype – klasifikator je stereotip koji se može primeniti na druge elemente • metaclass – klasifikator čije su instance klase • powertype – klasifikator čije su instance deca datog roditelja (UML1) • thread – klasa čiji su objekti aktivni sa deljenim adresnim prostorom (UML1) • process – komponenta čiji primerci imaju vlastite procese (u UML1 process je bio stereotip klase) Standardni stereotipovi relacije zavisnosti • Između klasa i/ili objekata na klasnom dijagramu: – instantiate – izvor kreira instance odredišta – instanceOf – izvor je objekat koji je instanca odredišnog klasifikatora (UML 1) – send – izvor (operacija) šalje signal koji je odredište relacije (odredište relacije nije primalac signala) – derive – izvor se može izračunati na osnovu odredišta; relacija između dva atributa ili dve asocijacije: jedan je konkretan, a drugi konceptualan (npr: DatumRodj i Starost) – refine – izvor je finiji stepen apstrakcije od odredišta; na primer: klasa u projektu je na finijem stepenu apstrakcije od odgovarajuće klase u analizi – permit – izvoru se daju posebna prava pristupa odredištu – friend – izvoru se daju posebna prava pristupa odredištu (samo UML 1) – powertype – odredište je powertype izvora (samo UML 1) • Između paketa: – Access – izvorni paket ima pravo pristupa elementima odredišnog (privatni uvoz) – Import – javni sadržaj odredišnog paketa ulazi u prostor imena izvornog paketa (kao da su imena odredišnog paketa deklarisana u izvornom paketu) Standardni stereotipovi ostalih relacija • Standardni stereotip relacije generalizacije – implementation – dete nasleđuje implementaciju roditelja, ali je čini privatnom i ne podržava interfejs roditelja, pa ne može zamenjivati roditelja • Standardni stereotip relacije realizacije – bind – izvor je instanca ciljnog šablona sa datim stvarnim parametrima
  • 79. 80 UML – Dijagrami složene strukture Elektrotehnički fakultet u Beogradu Dijagrami složene strukture Uvod • Dijagrami složene strukture omogućavaju – hijerarhijsku dekompoziciju klasifikatora na delove njegove unutrašnje strukture – korišćenje saradnji (collaboration) u dešavanjima saradnji (collab. occurence) • Struktura – kompozicija povezanih elemenata – elementi predstavljaju pojave koje sarađuju preko komunikacionih veza da postignu zajedničke ciljeve • Unutrašnja struktura – struktura unutar pojave klasifikatora • Port – tačka interakcije klasifikatora sa okruženjem • Strukturirana klasa – klasa koja ima portove i unutrašnju strukturu • Unutrašnju strukturu imaju – klase – komponente – saradnje Notacija: delovi i portovi • Delovi klasifikatora se koriste da označe (povezane) osobine (atribute) • Portovi se povezuju sa – zahtevanim interfejsima (postolja, soketi) – realizovanim interfejsima (loptice) – unutrašnjim delovima • Delovi mogu imati naznačene: – ime – tip – multiplikativnost • Sadržanje dela: – kompozicija – pravougaonik dela se crta punom linijom – agregacija – pravougaonik dela se crta isprekidanom linijom Konektori • Konektori povezuju – delove međusobno – delove sa portovima (delegirajući konektor) A b: B[2] A b: B[2] Celina deo1 deo2 p1 p2 deo1 deo2 p1 p2 RealizovaniInterfejs ZahtevaniInterfejs
  • 80. UML – Dijagrami složene strukture 81 Projektovanje softvera • Konektor koji povezuje delove – direktna veza (označava komunikaciju između delova - asocijacija) – veza preko “lilihipa” – zahtevanog i realizovanog interfejsa • Delegirajući konektor - povezuje delove sa portovima (zavisnost) – od porta prema delu za realizovani interfejs – od dela prema portu za zahtevani interfejs Primer • Definisanje klase Automobil sa unutrašnjom strukturom – klasa Motor • realizovani interfejs (pogon) • zahtevani interfejsi (gorivo,vazduh) • portovi (prenos i karburacija) • sadrži 4 cilindra i bregastu osovinu – klasa Automobil sa unutrašnjom strukturom Multiplikativnost • Multiplikativnost se može naznačiti na svakom delu – u zagradama [] ili u gornjem desnom uglu • Na krajevima konektora se može naznačiti multiplikativnost veze – tumači se kao i multiplikativnost na stranama asocijacije: • broj objekata sa date strane konektora koji je u vezi sa tačno jednim objektom na drugoj strani veze (unutar jedne pojave okružujućeg klasifikatora) • Primer: y : Y Y a: A[2] b: B[2]a: A[2] b: B[2] 22 /a : A /a : A /b : B /b : B – pojave delova: a i b su imena uloga (oznaka /a, odnosno /b) Automobil : Motorprednji: Tocak[2] : Menjac : Motorprednji: Tocak[2] : Menjac prenos2 X a: A b: Ba: A b: B I X a: A b: Ba: A b: B Motor prenos karburacija cilindar: Cilindar[4] bregasta: Osovina prenos karburacija cilindar: Cilindar[4] bregasta: Osovina pogon gorivo vazduh
  • 81. 82 UML – Dijagrami složene strukture Elektrotehnički fakultet u Beogradu Saradnja • Saradnja opisuje strukturu elemenata koji sarađuju (uloga) od kojih svaki obavlja specijalizovanu funkciju da bi zajedno postigli neku funkcionalnost • Između uloga postoje komunikacione putanje - konektori • Notacija saradnje: – u gornjem delu elipse – ime saradnje – ispod linije – uloge u saradnji povezane konektorima – mogu biti naznačeni i tipovi uloga Događanje saradnje • Notacija događanja saradnje (collaboration occurrence): – u isprekidanoj elipsi ime_događanja_saradnje:ime_saradnje • Primer: – Trgovina je saradnja u kojoj se pojavljuju dva događanja saradnje Kupoprodaja: veleporodaja i maloprodaja – uloge u trgovini imaju proizvodjac, trgovac i potrosac • Drugi način prezentacije događanja saradnje – stereotip zavisnosti <<occurrence>> prodavac kupac Kupoprodaja prodavac:Lice kupac:Lice Kupoprodaja b c a Trgovina proizvodjac potrosac trgovac veleprodaja:Kupoprodaja maloprodaja:Kupoprodaja prodavac prodavac kupac kupac veleprodaja proizvodjac trgovac prodavac kupac Kupoprodaja <<occurence>>
  • 82. UML – Dijagrami komponenata 83 Projektovanje softvera Dijagrami komponenata Uvod • Komponenta je fizički i zamenjivi deo sistema koji realizuje skup interfejsa • Dijagram komponenata prikazuje organizaciju i zavisnosti između komponenata • Namenjen je prikazu: – fizičke organizacije softverskog sistema – statičkog pogleda na implementaciju sistema • Dijagrami sadrže: – stvari: • komponente, artefakte, portove, interfejse, klase, pakete – relacije: • zavisnosti, generalizacije, asocijacije, realizacije Najčešće primene • Modeliranje – izvornog koda – izdanja za isporuku – izvršnih izdanja i okruženja – fizičkih baza podataka Komponenta • Komponenta je modularni deo sistema – manifestacija je zamenjiva u okruženju – kapsulira neki sadržaj (koji nije vidljiv osim kroz interfejse) – definiše svoje ponašanje kroz ponuđene i zahtevane interfejse • Komponenta predstavlja tip (apstrakciju fizičke stvari) – obuhvata statičku i dinamičku semantiku • Primeri komponenata – Java Bean, EJB, CORBA, COM+, .NET assembly • Razvoj zasnovan na komponentama – razvijani sistem se gradi i strukturira od postojećih komponenata – bitna osobina – reupotreba ranije razvijenih komponenata Grafička notacija UML 1: UML 2: • Komponenta može da sadrži i odeljak klasa koje realizuje <<component>> komponentakomponentakomponenta
  • 83. 84 UML – Dijagrami komponenata Elektrotehnički fakultet u Beogradu Artefakt • Artefakt je fizička informacija koju koristi ili proizvodi – razvojni proces ili – izvršenje • Primeri: – modeli, izvorni fajlovi, skriptovi, binarni izvršni fajlovi, arhive, tabele baze podataka, dokumenti • Može da predstavlja manifestaciju komponente • Notacija: Cenovnik.jar <<artifact>> Cenovnik.jar <<artifact>> Komponente i klase/interfejsi • Komponente i klase – klasa - logička apstrakcija, a komponenta - fizička stvar "u svetu bitova" – komponenta predstavlja fizičko pakovanje logičkih apstrakcija – klase mogu imati atribute i operacije, a komponente samo operacije – servisi klase mogu biti pristupačni direktno, a servisi komponente samo kroz interfejse • Komponente i interfejsi – interfejs je skup operacija koji specificira servis klase ili komponente – komponenta realizuje jedan ili više interfejsa – standardi COM, CORBA, EJB (Enterprise Java Beans) koriste interfejse – relacija realizacije interfejsa (kanonička i skraćena forma): Port • Port reprezentuje tačku interakcije između klasifikatora i njegovog okruženja • Interfejsi pridruženi portu specificiraju prirodu interakcija koje se dešavaju preko porta: – zahtevani interfejsi karakterizuju zahteve koje može da pravi klasifikator svom okruženju – ponuđeni interfejsi karakterizuju zahteve koje okruženje može da pravi klasifikatoru • Komponenta potencijalno ispoljava interfejse preko portova • Notacija: geometrija <<realizations>> Tacka Linija Tacka Linija geometrija geometrija Tacka Linija 2 Cenovnik.jar <<artifact>>Cenovnik <<manifest>> Interfejs <<interface>> Komponenta <<component>> Interfejs Komponenta <<component>>
  • 84. UML – Dijagrami komponenata 85 Projektovanje softvera K <<component>imePorta:TipPort
  • 85. 86 UML – Dijagrami komponenata Elektrotehnički fakultet u Beogradu Port i interfejsi • Port sa interfejsima (postolje ili soket-zahtevani, loptica-ponuđeni): – Interfejs koji realizuje komponenta • izvozni (export) ili ponuđeni interfejs – Interfejs koji komponenta koristi • uvozni (import) ili zahtevani interfejs • Primer interakcije preko interfejsa: Exe <<component>> Dll <<component>> I • Konstrukcija postolja i loptice se naziva veznik sklopa (assembly connector) • Ako je port na ivici klasifikatora – vidljiv je spolja (public), inače je zaštićen (protected) • Port može imati i multiplikativnost – piše se iza imena u zagradama [] Vrste artefakata i stereotipovi • Mogu se uočiti 3 kategorije artefakata: – iz razvojnog procesa • modeli, izvorni kod, projektni fajlovi, skriptovi, resursi – za isporuku • exe, dll, jar, dokumenti, tabele – izvršni • kreirani kao posledica izvršenja, npr. COM objekat kreiran iz DLL-a • UML definiše sledeće standardne stereotipove za komponente: – executable - komponenta koja se može izvršavati na čvoru – library - statička ili dinamička objektna biblioteka – file - datoteka (proizvoljan sadržaj) – document - dokument – script - skript – source - datoteka sa izvornim kodom – table - tabela baze podataka (UML 1) Paketi i relacije zavisnosti • Paketi na dijagramima komponenata: – sadrže druge pakete i komponente – koriste se da reprezentuju fizičke podsisteme – tipično reprezentuju kataloge (foldere) u sistemu datoteka • Logički paketi iz dijagrama klasa se često preslikavaju u pakete u dijagramima komponenata • Paketi ili komponente se povezuju relacijom zavisnosti koja reprezentuje: Ponudjeni Zahtevani K <<component>> pp Ponudjeni <<interface>> Zahtevani <<interface>>
  • 86. UML – Dijagrami komponenata 87 Projektovanje softvera – zavisnost u vreme prevođenja kada se radi sa fajlovima izvornog koda – zavisnost u vreme povezivanja kada se radi sa bibliotečkim i objektnim fajlovima – zavisnost u vreme izvršenja kada se radi sa izvršnim fajlovima Primer dijagrama komponenata • Softver za administraciju nekog sistema – komponenta Administracija.exe – za sifrovanje podataka koji se razmenjuju sa administriranim sistemom • koristi se dinamička biblioteka Sifrovanje.dll – za najavu administratora na sistem • koristi se dinamička biblioteka Najava.dll Administracija.exe <<component>> Sifrovanje.dll <<component>> Najava.dll <<component>> izvrsna komponenta dinamicka biblioteka
  • 87. 88 UML – Dijagrami raspoređivanja Elektrotehnički fakultet u Beogradu Dijagrami raspoređivanja Uvod • Dijagram raspoređivanja prikazuje – statičke fizičke aspekte sistema – hardversku i softversku izvršnu arhitekturu sistema – konfiguraciju čvorova i softverskih artefakata koje žive na njima • Dijagram raspoređivanja sadrži: – stvari: • čvorove (node) • artefakte • podsisteme • pakete – relacije: • zavisnosti (između čvorova i artefakata) • asocijacije (veze između čvorova) • generalizcije Najčešće primene • Modeliranje – ugrađenih (embedded) sistema – klijent-server sistema – troslojnih sistema – potpuno distribuiranih sistema Čvorovi • Čvor je apstrakcija fizičkog objekta koji reprezentuje resurs obrade • Čvor u opštem slučaju ima barem memoriju, a često ima i mogućnost izvršavanja programa • Čvorovi mogu biti procesori, uređaji, čak i izvršna okruženja (VM) – procesor je čvor koji ima mogućnost izvršavanja programa • Grafička notacija: Server • Za višeprocesorske sisteme – multiplikativnost (u gornjem desnom uglu) • Mogu postojati odeljci: – atributa (npr. speed i memory) – operacija (npr. ukljuci(), iskljuci(), samodijagnostika()) – artefakata koji se raspoređuju na čvor • Čvor je apstrakcija (tip), pojave čvorova - podvučena imena RTI20:Server
  • 88. UML – Dijagrami raspoređivanja 89 Projektovanje softvera Organizovanje čvorova • Čvorovi se mogu organizovati u pakete • Grupisanje u paket se koristi za logički srodne čvorove • Na primer: Serveri WebServer AplikativniServer <<device>> ServerBaze Klijenti Desktop Laptop – paket serveri sadrži razne tipove servera koji se koriste u sistemu – paket klijenti sadrži razne tipove klijenata koji se koriste u sistemu • Grupisanje može biti i fizičko - podsistem – u UML 1 se koristio sterotip paketa <<subsystem>> – u UML 2 <<subsystem>> je stereotip komponente Čvorovi, komponente i artefakti • Odnosi: – artefakti mogu biti manifestacije softverskih komponenata – čvorovi su stvari koje izvršavaju artefakte – komponente reprezentuju fizičko pakovanje logičkih elemenata – čvorovi reprezentuju fizičko odredište pri raspoređivanju artefakata • Notacija dozvoljava i da se artefakti koji se isporučuju za neki čvor crtaju u njemu Cvor Artefakt <<artifact>> Uređaji i izvršna okruženja • Čvor može biti: – fizički uređaj (npr. računar), stereotip <<device>> (podrazumevan) – izvršno okruženje (npr. EJB kontejner), stereotip <<container>> Server podaci.mdb skola.exe admin.mde artifacts podaci.mdb <<deploy>> Skola.exe <<deploy>> admin.mde <<deploy>> Server
  • 89. 90 UML – Dijagrami raspoređivanja Elektrotehnički fakultet u Beogradu • Čvorovi mogu biti ugnežđeni – uređaj može sadržati izvršno okruženje – grafička notacija za ugnežđene čvorove: AplikativniServer <<device>> J2EEserver <<container>> Veze • Veza između čvorova ukazuje na komunikacioni put između njih • Koristi se relacija asocijacije • Veza može biti: – direktna, kao što je RS232 serijska veza – indirektna, kao što je komunikacija satelit-zemlja • Veze su obično bidirekcionalne • Na asocijaciji se može ukazati na prirodu komunikacionog puta – stereotip – Booch,..., “UML User Guide” – naziv – Fowler, “UML Distilled” Primer – hardverska konfiguracija Baza Konzola Server Klijent <<Ethernet>> <<RS232>> <<Internet>> Primer – čvorovi i artefakti • Raspoređivanje artefakata na čvorove u lokalnoj mreži Server Baza <<Ethernet>> Klijent <<Internet>> Konzola <<RS-232>> Klijent podaci.mdb <<artifact>> skola.exe <<artifact>> admin.mde <<artifact>> Server <<deploy>> <<deploy>> <<deploy>> <<deploy>> <<Ethernet>> 1 <<RS232>> http/Internet
  • 90. UML – Dijagrami interakcije – napredniji pojmovi 91 Projektovanje softvera Dijagrami interakcije - napredniji pojmovi Dijagrami pregleda interakcije • Dijagrami pregleda interakcije (Interaction Overview Diagrams) definišu interakcije kroz jednu varijantu dijagrama aktivnosti – na način da se dobije pregled kontrole toka • Dijagrami pregleda interakcije su specijalizacija dijagrama aktivnosti da prikazuju interakcije • Dijagrami pregleda interakcije se fokusiraju na pregled kontrole toka gde su čvorovi – interakcije ili – događanja interakcija • Interakcije i događanja interakcija predstavljaju izvršenja aktivnosti • Na dijagramima se linije života i poruke ređe pojavljuju: – u najčistijem obliku sve aktivnosti su događanja interakcije i tada na dijagramu uopšte nema poruka i linija života Razlike od dijagrama aktivnosti • Čvorovi na dijagramima pregleda interakcije mogu sadržati (ugrađenu) interakciju ili događanje interakcije – događanje interakcije se prikazuje u okviru interakcije sa ključnom rečju ref i imenom – interakcije i događanja interakcije se smatraju specijalnim oblicima izvršenja aktivnosti • Kombinovani fragmenti alternativnih (alt) tokova interakcije se prikazuju čvorom odluke (decision) i odgovarajućim čvorom spajanja (merge) • Kombinovani fragmenti paralelnih (par) tokova interakcije se prikazuju čvorom paralelnog grananja (fork) i udruživanja niti (join) • Kombinovani fragmenti petlji (loop) u interakciji se prikazuju preko jednostavnih ciklusa u toku kontrole • Dijagrami pregleda interakcije se uokviruju istim vrstama okvira koji zatvaraju druge forme dijagrama interakcije; – tekst zaglavlja može da uključuje listu sadržanih linija života (koje ne moraju da se pojavljuju grafički) Grafička notacija • Osim simbola sa dijagrama aktivnosti koriste se sledeći: – okvir interakcije (oko celog dijagrama) sa eventualnim imenom i nazivima linija života: – interakcija kao čvor (pokretanje aktivnosti) • može biti imenovana, ili anonimna nazivsd : X : Y 1 2 3 naziv lifelines :X :Ysd
  • 91. 92 UML – Dijagrami interakcije – napredniji pojmovi Elektrotehnički fakultet u Beogradu – događanje interakcije • alatima se prepušta način prikaza: − referenca − ekspandovana i ugrađena interakcija ref NazivInterakcije Primer – dijagram pregleda interakcije • Isti primer distribucije pošiljki (videti dijagrame interakcije) Vremenski dijagrami • Vremenski dijagrami se koriste da prikažu interakcije kada je primarna namena dijagrama razmatranje vremena • Vremenski dijagrami se fokusiraju na promenu uslova/stanja unutar i između linija života duž linearne vremenske ose • Vremenski dijagrami opisuju ponašanje – individualnih klasifikatora (strukturalnih elemenata) – interakcije klasifikatora • Pažnja se fokusira na vremena zbivanja događaja koji uzrokuju promene u modeliranim stanjima/uslovima linija života RedovnaIsporukasd : Porudzbina : RedovniDistributer isporuci() SpecijalnaIsporukasd : Porudzbina : SpecijalniDistributer isporuci() [vrednost<=1000] [else] [potrebna potvrda] [else] [nije poslednja stavka] ref PotvrdaKurira
  • 92. UML – Dijagrami interakcije – napredniji pojmovi 93 Projektovanje softvera Grafička notacija • Okvir interakcije (oko dijagrama) • Vremenska linija stanja/uslova • Vrednosti/stanja linije života • Linije života • Poruke (kao na dijagramima sekvence, ali su linije vertikalno orijentisane) • Vremenska ograničenja (u {}), na primer: – {<5*d}, ili {d..3*d} gde je d interval vremena – {t..t+3}, gde je t vremenski trenutak nekog događaja Primer vremenskog dijagrama Regulisanje saobracajasd :Automobil ugašen na leru u brzini {>3s} {2min} {3min}{2s} {<2s} :Semafor zeleno zuto crveno {3s} start stop stanje A stanje C stanje B t vrednost/stanje vrednost/stanje vrednost/stanje objekat1 objekat2
  • 93. 94 UML – Arhitektura metamodeliranja Elektrotehnički fakultet u Beogradu Arhitektura metamodeliranja Uvod • UML je jedan od nivoa 4-nivoske arhitekture metamodeliranja • 4-nivoska arhitektura je dokazana infrastruktura za definisanje precizne semantike koju zahtevaju kompleksni modeli • Prednosti pristupa 4-nivoske arhitekture: – rafinira semantičke konstrukcije njihovom rekurzivnom primenom na sukcesivne metanivoe – obezbeđuje arhitektonsku osnovu za: • definisanje budućih proširenja UML metamodela • nivelaciju UML metamodela sa drugim standardima zasnovanim na 4-nivoskoj arhitekturi metamodeliranja, posebno OMG Meta-Object Facility (MOF) Četvoronivoska arhitektura • Odnos između 2 susedna nivoa – niži nivo je instanca višeg nivoa • Broj meta-nivoa je teorijski neograničen, ali su za praktične primene dovoljna 4 nivoa • Opšte prihvaćeni radni okvir za metamodeliranje je zasnovan na arhitekturi sa sledeća četiri nivoa (sloja): – meta-metamodel – metamodel – model – korisnički objekti Opis nivoa arhitekture Nivo Opis Primer meta-metamodel Infrastruktura za arhitekturu metamodeliranja. Definiše jezik za specificiranje metamodela. MetaClass MetaAttribute MetaOperation metamodel Jedna instanca meta-metamodela. Definiše jezik za specificiranje modela. Class Attribute Operation Component model Jedna instanca metamodela. Definiše jezik za opis nekog informacionog domena. Dokument velicina otvaranje() korisnički objekti Jedna instanca modela. Definiše neki specifičan informacioni domen. Dokument dokument = new Dokument(“Text.rtf”); int i=100;
  • 94. UML – Arhitektura metamodeliranja 95 Projektovanje softvera Primer Meta-metamodel • Nivo meta-metamodeliranja daje temelj za arhitekturu metamodeliranja • Primarna odgovornost nivoa meta-metamodela: – da definiše jezik za specificiranje metamodela • Meta-metamodel definše model na višem stepenu apstrakcije od metamodela i tipično je kompaktniji od metamodela koji opisuje • Jedan meta-metamodel može definisati više metamodela, i može biti više meta-metamodela pridruženih svakom metamodelu • Generalno je poželjno da povezani metamodeli i meta-metamodeli dele zajedničke projektne filozofije i konstrukte – ovo nije striktno pravilo • Svaki nivo treba da održava svoj sopstveni projektni integritet • Primeri meta-metaobjekata u sloju meta-metamodeliranja su: – MetaClass, MetaAttribute i MetaOperation Metamodel • Metamodel je jedan primerak meta-metamodela • Primarna odgovornost nivoa metamodela: – da definiše jezik za specificiranje modela • Metamodeli su tipično detaljniji od meta-metamodela koji ih opisuju, specijalno kada definišu dinamičku semantiku • Primeri metaobjekata u sloju metamodeliranja su: – Class, Attribute, Operation i Component meta-metamodel (M3, MOF) metamodel (M2, UML) Atribute Class Instance Classifier Automobil -maxBrzina : Automobil Class <<instanceOf>> <<instanceOf>> <<instanceOf>> <<instanceOf>> model (M1, korisnicki model) <<instanceOf>> <<instanceOf>> objekti (M0, primerci u vreme izvršenja) auto <<instanceOf>> <<snapshot>>
  • 95. 96 UML – Arhitektura metamodeliranja Elektrotehnički fakultet u Beogradu Model • Model je jedan primerak metamodela • Primarna odgovornost nivoa modela: – da definiše jezik koji opisuje neki informacioni domen • Primeri objekata u sloju modeliranja su: – Dokument, velicina, otvaranje() Korisnički objekti • Korisnički objekti su jedan primerak modela • Primarna odgovornost nivoa korisničkih objekata – je da opišu specifičan informacioni domen • Primeri objekata u sloju korisničkih objekata su: – Dokument dokument = new Dokument(“Text.rtf”) i int i=100 Analogija • Nije samo arhitektura OO meta-modeliranja 4-nivoska – i arhitektura proceduralnog projektovanja i realizacije je 4-nivoska: • Metajezik (meta-metamodel): – stanje (podaci): primitivni tip, niz, struktura – ponašanje (kontrola toka): sekvenca, selekcija, iteracija • Jezik (metamodel): – podaci: int, [], struct – kontrola toka: {nar1; nar2;…}, if-else, for, while • Program (model): – podaci: typedef unsigned int Uint; struct S{int c; float n[2];} – kontrola toka: if (a) {b=c; while(d<100){…}} else {…} • Izvršenje programa (korisnički objekti): – podaci: Uint i=5; S s=new S(); – kontrola toka: 3. izvršenje ciklusa while
  • 96. Projektni uzorci - Uvod 97 Projektovanje softvera Uvod • Materijali pripremljeni pretežno prema knjizi: Gama, Helm, Johnson, Vlissides, “Design Patterns” • Christopher Alexander govori o uzorcima u građevinskoj arhitekturi: – “Svaki uzorak opisuje neki problem koji se ponavlja u našem okruženju i tada opisuje jezgro rešenja tog problema na takav način da se to rešenje može koristiti milion puta, a da se ne uradi ni dva puta na isti način” – definicija je primenljiva i na uzorke u objektno-orijentisanim sistemima – projektni uzorak predstavlja zabeleženo široko primenljivo iskustvo u projektovanju OO sistema – svaki projektni uzorak sistematično imenuje, objašnjava i evaluira neki važan i ponavljajući dizajn u objektno-orijentisanim sistemima – termini: projektni uzorak, obrazac, šablon (engl. Design Pattern) • Projektni uzorci su opisi komunicirajućih objekata i klasa koji su prilagođeni da reše neki opšti projektni problem u posebnom kontekstu • Projektni uzorak – identifikuje, apstrahuje i imenuje ključne aspekte neke opšte strukture – identifikuje učestvujuće klase i objekte, njihove uloge u saradnji i raspodelu odgovornosti – korisan je za kreiranje ponovo upotrebljivog OO projektnog rešenja Elementi uzorka • Svaki projektni uzorak ima 4 esencijalna elementa: – naziv uzorka – postavku problema – opis rešenja – diskusiju posledica Naziv uzorka • Koristi se da opiše projektni problem, njegova rešenja i konsekvence u par reči • Imenovanje uzorka proširuje projektni rečnik – omogućava projektovanje na višem nivou apstrakcije – pojednostavljuje komunikaciju u timu – olakšava dokumentovanje projekta • Ponekad se u literaturi sreće i više imena za isti uzorak Postavka problema • Opisuje kada da se primeni uzorak • Objašnjava problem i njegov kontekst • Može da opiše – specifičan projektni problem, npr. kako reprezentovati algoritme kao objekte – strukture klasa ili objekata koje su simptomatične za nefleksibilni dizajn – listu uslova koji se moraju ispuniti za primenu uzorka
  • 97. 98 Projektni uzorci - Uvod Elektrotehnički fakultet u Beogradu Opis rešenja • Opisuje elemente koji predstavljaju dizajn, njihove relacije, odgovornosti i saradnje • Rešenje ne opisuje konkretan dizajn ili implementaciju • Uzorak treba da posluži kao šablon koji se može primeniti u konkretnim slučajevima • Apstraktni opis – projektnog problema i – načina aranžiranja elemenata (klasa i objekata) u rešenju Posledice • Posledice su rezultati primene uzorka • Kritične su za razmatranje projektnih alternativa i razumevanje cene i dobiti primenom uzorka • Posledice se često odnose na vreme i prostor • Ponekad se odnose i na jezik i implementacione stvari • Posledice najčešće uključuju uticaj na: – fleksibilnost sistema – proširivost sistema – prenosivost (portabilnost) sistema Primer primene uzoraka: MVC • MVC je skraćeni naziv za trijadu klasa Model, View i Controller • Koristi se za realizaciju korisničkih interfejsa u Smalltalk jeziku • Model – konkretan objekat aplikacije • View – ekranska prezentacija objekta • Controller – definiše način na koji korisnički interfejs reaguje na korisnički ulaz • Komunikacije: – Model-View – Model-Controller • Primeri za 3 projektna uzorka Model – View komunikacija • Prikaz mora da obezbedi da reflektuje aktuelno stanje modela • Kad se podaci modela promene, model signalizira prikazima koji zavise od njega • Kao posledica, svaki prikaz dobija priliku da se ažurira kada se model promeni • Pristup omogućava više pogleda na model, da se dobiju različite prezentacije • Mogu se dodavati novi prikazi, a da se model ne promeni • Primer: – model sadrži neke statističke podatke – postoje tri prikaza: tabelarni, histogram, pita • Protokol između View i Model-a je tzv. subscribe-notify – prikazi se pretplaćuju kod modela, da bi ih ovaj obaveštavao kada ima promena – kada dobiju obaveštenje (signal) prikazi čitaju nove vrednosti modela • Generalizacija problema obaveštavanja "pretplatnika" – rasprezanje objekata takvo da promene jednog utiču na proizvoljan broj drugih objekata
  • 98. Projektni uzorci - Uvod 99 Projektovanje softvera – nema potrebe da menjani objekat zna za detalje drugih • Rešenje generalnog problema – opisano uzorkom Posmatrač (Observer) Komponovanje prikaza • Jedna od mogućnosti MVC koncepta – prikazi (Views) mogu biti ugneždeni • Primer: – kontrolni panel je prikaz koji sadrži ugneždene prikaze dugmadi • Klasa CompositeView izvedena iz View predstavlja – prikaz koji sadrži (ugneždava) druge – vrstu prikaza, pa se može pojaviti gde god se očekuje objekat View • Generalizacija problema složenih objekata – takvo grupisanje objekata da se grupa može tretirati i kao primerak iste vrste objekata • Rešenje generalnog problema – opisano uzorkom Kompozicija (Sastav, Sklop, engl. Composite) • Sličan je odnos klasa Container i Component u Javi Model – Controller komunikacija • MVC omogućava promenu načina na koji View reaguje na ulaz korisnika • Primer: – moguće je redefinisati odgovore na događaje sa tastature ili – zameniti komandne tastere pop-up menijem • MVC enkapsulira mehanizam odgovora u objekat tipa Controller • Postoji hijerarhija klasa kontrolera koja olakšava kreiranje novog – novi kontroler se kreira kao varijacija nekog postojećeg • View koristi objekat potklase Controller za specifičnu strategiju odgovora • Za primenu druge strategije, samo se zamenjuje objekat drugom vrstom kontrolera • Izmenu strategije je ovako moguće vršiti i u vreme izvršenja • Primer: – View može onemogućiti interakciju (disabled stanje) tako što mu se dodeli kontroler koji ignoriše ulaze • Generalizacija problema promenljivog algoritma – izmena (statička/dinamička) algoritma koji definiše ponašanje objekta • Rešenje generalnog problema – opisano uzorkom Strategija (Strategy) – Strategy je objekat koji apstrahuje i enkapsulira algoritam
  • 99. 100 Projektni uzorci - Uvod Elektrotehnički fakultet u Beogradu Klasifikacija projektnih uzoraka • Granularnost i nivo apstrakcije varira kod različitih uzoraka • Kao i svaka druga klasifikacija, ova klasifikacija – doprinosi boljem i bržem snalaženju pri traženju odgovarajućeg uzorka – usmerava napore ka otkrivanju novih uzoraka • Klasifikacija koristi dva kriterijuma za razvrstavanje uzoraka – kriterijum namene – kriterijum domena Kriterijum namene • Prvi kriterijum deli uzorke prema nameni, – odražava čime se uzorak bavi (šta opisuje) • Namena uzorka može biti da opiše – kreiranje (creational patterns) • uzorci tretiraju kreiranje objekata – strukturu (structural patterns) • uzorci tretiraju kompoziciju klasa ili objekata – ponašanje (behavioral patterns) • uzorci tretiraju načine na koje objekti ili klase interaguju Kriterijum domena • Drugi kriterijum specificira da li se uzorak primarno primenjuje na klase ili na objekte • Klasni uzorci (class patterns) se fokusiraju na relacije između klasa i potklasa – relacije se uspostavljaju kroz nasleđivanje – one su statičke – fiksirane u vreme prevođenja • Objektni uzorci (object patterns) se fokusiraju na relacije između objekata – ove relacije se mogu menjati u vreme izvršenja, pa su dinamičnije • Većina uzoraka je u objektnom domenu Karakteristike vrsta uzoraka • Klasni uzorci kreiranja – odlažu neke delove kreiranja objekata da budu implementirani u potklasama • Objektni uzorci kreiranja – delegiraju neke delove kreiranja objekata drugim objektima • Klasni uzorci strukturiranja – koriste nasleđivanje da komponuju klase • Objektni uzorci strukturiranja – opisuju načine asembliranja (sklapanja celina od nekih) objekata • Klasni uzorci ponašanja – koriste nasleđivanje da opišu algoritme i tok kontrole • Objektni uzorci ponašanja – opisuju kako grupa objekata kooperiše da obavi neki zadatak koji samostalno ne bi mogli
  • 100. Projektni uzorci - Uvod 101 Projektovanje softvera Drugi odnosi između uzoraka • Postoje i drugi načini za organizovanje uzoraka: – neki uzorci se često koriste zajedno • npr. Kompozicija (Composite) i Iterator (Iterator) ili Posetilac (Visitor) – neki uzorci su alternative jedni drugima • npr. Prototip (Prototype) i Apstraktna fabrika (Abstract Factory) – neki uzorci različitih namena rezultuju u sličnoj implementaciji • npr. Kompozicija (Composite) i Dekorater (Decorator) Prostor projektnih uzoraka • Tabela reflektuje klasifikaciju uzoraka po dva kriterijuma – kolone sadrže vrste uzoraka po nameni – vrste sadrže vrste uzoraka po domenu – Namena uzorci kreiranja uzorci strukture uzorci ponašanja klasni uzorci Fabrički metod Adapter (klasni) Interpreter Šablonski metod Domen objektni uzorci Apstraktna fabrika Graditelj Prototip Unikat Adapter (objektni) Most Sastav Dekorater Fasada Muva Zastupnik Lanac odgovornosti Komanda Iterator Posrednik Podsetnik Posmatrač Stanje Strategija Posetilac Katalog projektnih uzoraka • Katalog sadrži za svaki uzorak sledeće stavke: – ime uzorka i klasifikacija – namena – odgovori na pitanja "šta radi? čemu služi? koji problem rešava?" – drugi nazivi – isti uzorak može imati više naziva – motivacija – scenario koji ilustruje projektni problem – primenljivost – situacije u kojima se uzorak može primeniti (da se izbegne loš dizajn) – struktura – klasni/objektni i/ili dijagrami interakcije koji opisuju uzorak – učesnici – klase i objekti koji učestvuju u uzorku i njihove odgovornosti – saradnje – kako učesnici sarađuju da ispolje svoje odgovornosti – posledice – diskusija dobrih i loših strana primene uzorka – implementacija – zamke, preporuke i tehnike kojih treba biti svesan pri implementaciji – primer koda – fragment koda koji ilustruje kako se uzorak može implementirati – poznate primene – primeri primene uzorka u realnim sistemima (barem po dva) – povezani uzorci – koji uzorci su bliski sa datim, koje su razlike, sa kojima se često koristi – UML notacija – grafički simbol za saradnju koja realizuje uzorak
  • 101. 102 Projektni uzorci - Uvod Elektrotehnički fakultet u Beogradu UML notacija za opis uzoraka • UML 1: grafički simbol predstavlja parametrizovanu saradnju • Formalni parametri saradnje su uloge učesnika • Stvarni parametri su učesnici – konkretne klase • Relacija između parametrizovane kolaboracije i participanata je "binding" • UML 2: ne koristi se parametrizovana saradnja • Prvi način: uloge učesnika se crtaju u okviru saradnje • Drugi način: uloge učesnika se crtaju izvan saradnje Uzorak uloga1:Ucesnik1 uloga2:Ucesnik2 UzorakUcesnik1 Ucesnik2 uloga1 uloga2 uloga1 uloga2 uloga3 Uzorak Ucesnik1 Ucesnik2 Ucesnik3 uloga 1 uloga2 uloga3
  • 102. Projektni uzorci - Unikat 103 Projektovanje softvera Unikat • Ime i klasifikacija: – Unikat (Singleton) – objektni uzorak kreiranja • Namena: – obezbeđuje da klasa ima samo jedan objekat i daje globalni pristup tom objektu • Motivacija: – za neke klase je važno obezbediti da imaju samo po jedan objekat – na primer, u sistemu treba da postoji samo jedan dispečer štampe (spooler) – globalna promenljiva obezbeđuje da je objekat pristupačan, ali ne brani više objekta – bolje rešenje je da klasa sama bude odgovorna za jedinstvenost njenog objekta • Primenljivost: – Unikat uzorak treba koristiti kada: • mora postojati tačno jedan objekat klase i ona mora biti pristupačna klijentima preko svima poznate tačke pristupa • klasa treba da bude proširiva izvođenjem, a da klijenti mogu da koriste objekat izvedene klase bez potrebe da modifikuju svoj kod • Struktura: • Učesnici: – Unikat • definiše operaciju primerak() kao operaciju klase (statički metod) koja daje klijentima pristup do jedinstvenog objekta • može biti odgovorna za kreiranje vlastitog jedinstvenog objekta • Saradnja: – klijenti pristupaju objektu klase Unikat isključivo kroz njenu operaciju primerak() • Posledice: dobre strane – kontrolisani pristup do jedinog objekta • pošto klasa kapsulira jedini objekat, ona može imati striktnu kontrolu nad tim kako i kada klijenti pristupaju objektu – rasterećenje prostora imena • uzorak Unikat je bolji koncept od globalne promenljive, jer izbegava opterećivanje prostora imena globalnom promenljivom koja čuva jedini objekat – dozvoljeno doterivanje operacija i reprezentacije • iz klase Unikat se može izvoditi • aplikaciju je lako konfigurisati objektom izvedene klase, čak i u vreme izvršenja – dozvoljava kontrolisano povećanje broja objekata • uzorak omogućava projektantu da se po maloj ceni predomisli i poveća broj dozvoljenih objekata – fleksibilnost u odnosu na operacije klase • drugi način za realizaciju funkcionalnosti Unikata je uslužna (utility) klasa • sa uslužnom klasom je komplikovano promeniti broj objekata Unikat -jediniPrimerak: Unikat -podaci <<create>>#Unikat() +primerak(): Unikat +dohvatiPodatke() +operacija() primerak():Unikat{ if (jediniPrimerak==null) jediniPrimerak=<<create>>Unikat(); return jediniPrimerak; }
  • 103. 104 Projektni uzorci - Unikat Elektrotehnički fakultet u Beogradu • statičke funkcije na C++ nisu virtuelne, pa potklase ne mogu da ih polimorfno redefinišu • Implementacija C++: class Unikat { public: static Unikat* primerak(); virtual void operacija(); protected: Unikat(); private: static Unikat* jediniPrimerak; } // implementacija: Unikat* Unikat::jediniPrimerak=0; Unikat* Unikat::primerak(){ if (jediniPrimerak == 0) jediniPrimerak = new Unikat; return jediniPrimerak; } // koriscenje: Unikat::primerak()->operacija(); • Implementacija Java: class Unikat{ public static Unikat primerak(){ if (jediniPrimerak == null) jediniPrimerak = new Unikat(); return jediniPrimerak; } public void operacija(){/*...*/}; protected Unikat(){} private static Unikat jediniPrimerak=null; }; // koriscenje: Unikat.primerak().operacija(); • Poznate primene: – u aplikacijama sa jednim dokumentom (single-document) klasa Dokument je unikat – u Smalltalk jeziku svaka metaklasa (klasa čiji su primerci klase) ima samo jedan objekat • Povezani uzorci: – mnogi uzorci koriste Unikat (Apstraktna fabrika, Graditelj, Prototip, Fasada) • Notacija – UML 1 – UML 2 unikat Unikat Dokument unikat Uzorak Unikat unikat: Dokument Uzorak Unikat Dokument unikat ili
  • 104. Projektni uzorci - Kompozicija 105 Projektovanje softvera Kompozicija • Ime i klasifikacija: – Kompozicija (Sklop, Sastav, engl. Composite) – objektni uzorak strukture • Namena: – komponuje objekte u strukturu stabla (hijerarhija celina-deo) – omogućava klijentima da uniformno tretiraju • individualne objekte • njihove kompozicije • Motivacija: – grafičke aplikacije kao što su editori crteža i sistemi za unos šema: • omogućavaju crtanje kompleksnih slika (dijagrama) sastavljenih od jednostavnih grafičkih elemenata (komponenata) • elementi se mogu grupisati da se formiraju složeni elementi (kompozicije) • složeni element je potrebno tretirati i kao vrstu grafičkog elementa • ključno: apstraktna klasa koja predstavlja i proste i složene elemente – klasni dijagram – objektni dijagram – struktura rekurzivno komponovanih grafičkih objekata: s1 : Slika l1 : Linija l2 : Linija s2 : Slika p1 : Pravougaonik l3 : Linija • Primenljivost: uzorak treba koristiti kada se želi da – postoje hijerarhije objekata celina-deo takve da su celina i deo iste vrste – klijenti mogu da ignorišu razlike između kompozicija i pojedinih objekata Editor Grafik +crtaj() +dodaj(g: Grafik) +ukloni(g: Grafik) +dohvatiElement(i: int) Linija +crtaj() Pravougaonik +crtaj() Slika +crtaj() +dodaj(g: Grafik) +ukloni(g: Grafik) +dohvatiElement(i: int) -elementi* konkretne metode imaju prazna tela crtaj(){ foreach g in elementi g.crtaj(); }
  • 105. 106 Projektni uzorci - Kompozicija Elektrotehnički fakultet u Beogradu • Struktura: • Učesnici: – Element (klasa Grafik) • deklariše zajednički interfejs za sve objekte u kompoziciji • implementira podrazumevano ponašanje zajedničko za sve klase • deklariše interfejs za pristupanje i upravljanje decom • implementira prazne metode za pristup i upravljanje decom (zbog listova) • opciono deklariše i implementira interfejs za pristup roditelju – List (klase Linija, Pravougaonik) • reprezentuje individualne objekte – listove u stablu • definiše ponašanje za primitivne objekte u kompoziciji – Kompozicija (klasa Slika) • definiše ponašanje za objekte koji imaju decu • sadrži komponente decu • implementira operacije za pristup i upravljanje decom – Klijent (klasa Editor) • manipuliše objektima u kompoziciji kroz interfejs klase Element • Saradnja: – klijenti koriste interfejs apstraktne klase Element da interaguju sa objektima složene strukture • ako je primalac zahteva List, zahtev se neposredno izvršava • ako je primalac zahteva Kompozicija obično se zahtev prosleđuje komponentama deci • UML notacija: – na primeru grafičkog editora Klijent Element +operacija() +dodaj(e: Element) +ukloni(e: Element) +dohvati(i: int) List +operacija() Kompozicija +operacija() +dodaj(e: Element) +ukloni(e: Element) +dohvato(i: int) -deca * konkretne metode imaju prazna tela operacija(){ foreach d in deca d.operacija(); } Grafik Linija Pravougaonik SlikaEditor Kompozicija Klijent Element List List Kompozicija
  • 106. Projektni uzorci - Kompozicija 107 Projektovanje softvera • Posledice: – čini jedostavnim klijente • oni tretiraju na jedinstven način sve objekte u hijerarhiji – čini jednostavnim dodavanje nove vrste elemenata – nije jednostavno ograničiti vrste elemenata koje neke kompozicije sadrže • Povezani uzorci: – Često se veza element-roditelj koristi za uzorak Lanac odgovornosti • ako element ne može da odgovori na zahtev – prosleđuje ga roditeljskom objektu – Dekorater (Dopuna) ima sličnu strukturu klasa i često se koristi sa Kompozicijom • kada se koriste zajedno obično imaju zajedničku natklasu – Muva dozvoljava deljenje elemenata, ali oni ne mogu da pristupaju svojim roditeljima – Iterator se koristi često za obilazak strukture Kompozicije – Posetilac lokalizuje operacije i ponašanje koje bi inače bilo distribuirano između klasa Kompozicija i List
  • 107. 108 Projektni uzorci - Prototip Elektrotehnički fakultet u Beogradu Prototip • Ime i klasifikacija: – Prototip (polimorfna kopija, engl. Prototype) – objektni uzorak kreiranja • Namena: – specificira vrste objekata koje se kreiraju korišćenjem prototipske instance – kreira nove objekte kopiranjem prototipa • Motivacija: – editor za muzičke partiture bi se mogao realizovati: • prilagođenjem opšteg radnog okvira za grafičke editore • dodavanjem novih objekata koji predstavljaju note, pauze i druge muzičke simbole – radni okvir editora može imati paletu alata za dodavanje muzičkih objekata partituri • paleta bi takođe uključila i alate za selektovanje, pomeranje i druge radnje nad objektima • korisnik bi kliknuo na alat "četvrtinka" i dodao ovu u partituru • korisnik bi mogao da koristi alat za pomeranje da premesti notu na drugu notnu liniju – radni okvir nudi • apstraktnu klasu Simbol za grafičke komponente (npr. note, linije) • apstraktnu klasu Alat za definisanje alata kakvi su u paleti • klasu AlatZaSimbole, potklasu klase Alat, za kreiranje i dodavanje objekata u dokument – problem za projektanta radnog okvira je klasa AlatZaSimbole • klase za note i notne linije su specifične za aplikaciju, nepoznate radnom okviru • mogla bi se praviti potklasa AlatZaSimbole za svaki muzički objekat, ali ima ih mnogo • potklase bi se razlikovale samo po vrsti muzičkog objekta koje stvaraju – kompozicija objekata je česta fleksibilna alternativa izvođenju i nasleđivanju – radni okvir parametrizuje primerke AlatZaSimbole objektima klase Simbol – rešenje: • AlatZaSimbole kreira novi Simbol kopiranjem objekta potklase Simbol • dotični objekat (primerak potklase Simbol) se naziva prototipom • objekat AlatZaSimble je parametrizovan prototipom koji klonira i dodaje u dokument – potrebno da sve potklase Simbol imaju operaciju kopija() – u muzičkom editoru, alati za kreiranje muzičkih obj. su objekti AlatZaSimbole • dotičan objekat AlatZaSimbole se inicijalizuje različitim prototipom • svaki objekat AlatZaSimbole proizvodi muzički objekat kloniranjem njegovog prototipa • Primenljivost: uzorak treba koristiti Alat +primeni() AlatZaRotaciju +primeni() AlatZaSimbole +primeni() Simbol +crtaj() +kopija() Nota NotnaLinija +crtaj() +kopija() CelaNota +crtaj() +kopija() Polovina +crtaj() +kopija() -prototip primeni(){ p=prototip.kopija(); while (korisnik pomera p) { crtaj p na tekucoj poziciji } umetni p u sliku; } kopija() { return kopija CelaNota; }
  • 108. Projektni uzorci - Prototip 109 Projektovanje softvera – kada sistem treba da bude nezavisan od toga kako se njegovi proizvodi kreiraju i predstavljaju – kada se klase specificiraju u vreme izvršenja, npr. dinamičkim učitavanjem – kada treba izbeći izgradnju hijerarhije fabrika paralelno sa hijerarhijom proizvoda • Struktura: • Učesnici: – Prototip (klasa Simbol) • deklariše interfejs za sopstveno kloniranje – KonkretanProtorip (klase CelaNota, Polovina, NotnaLinija) • implementira operaciju za sopstveno kloniranje – Klijent (klasa AlatZaSimbole) • kreira novi objekat zahtevom prototipu da se klonira • Saradnja: – klijent zahteva od prototipa da se klonira • UML notacija: • Posledice: – Prototip ima sledeće dobre strane: • redukuje broj imena koje klijent treba da poznaje • dodavanje i uklanjanje proizvoda u vreme izvršenja (registracija prototipske instance) • smanjivanje potrebe izvođenja • dinamičko konfigurisanje aplikacije klasama – loša strana uzorka Prototip: • svaka potklasa mora implementirati operaciju kopija() • to je komplikovano ako klasa već postoji ili ako sadrži objekte koji ne podržavaju kopiranje • Povezani uzorci: – Apstraktna Fabrika je alternativan uzorak, ali se može i dopuniti sa Prototipom: • fabrika može sadržati skup prototipova na osnovu kojih klonira i vraća proizvode – projekti koji intenzivno koriste uzorci Kompozicija (Sklop) i Dekorater (Dopuna) mogu imati koristi i od uzorka Prototip Prototip +kopija() KonkretanPrototip1 +kopija() KonkretanPrototip2 +kopija() Klijent +operacija() -prototip kopija(){ vraca kopiju KonkretanPrototip1; } operacija(){ ... prototip.kopija(); ... } kopija(){ vraca kopiju KonkretanPrototip2; } ide izaAlatZaSimbole Simbol CelaNota Klijent Uzorak Prototip Prototip KonkretanPrototip
  • 109. 110 Projektni uzorci - Posmatrač Elektrotehnički fakultet u Beogradu Posmatrač • Ime i klasifikacija: – Posmatrač (engl. Observer) – objektni uzorak ponašanja • Namena: – definiše 1:n zavisnost između objekata takvu da kada jedan objekat promeni stanje svi zavisni se obaveste i modifikuju automatski • Druga imena: – Zavisni objekti, Objavljivanje-Pretplata (Dependents, Publish-Subscribe) • Motivacija: – nije dobro da su klase sistema čvrsto-spregnute (smanjuje se reupotrebljivost) • na primer, GUI toolkits razdvajaju prezentacione aspekte od aplikativnih podataka • klase aplikativnih podataka i one za prezentaciju se mogu reupotrebiti nezavisno – objekat za tabelarni prikaz i objekat za histogram mogu prikazati iste podatke • objekat za tabelarni prikaz i objekat za histogram ne znaju jedan za drugog • zbog toga dopuštaju nezavisnu reupotrebu, a ponašaju se kao da su spregnuti • kada se podaci promene kroz tabelu – promeni se i histogram tabela histogram model 1 : promeniStanje() 3 : osvezi() 2 : obavesti() 4 : citajStanje() subjekat posmatraci pita 5 : osvezi() 6 : citajStanje() – tabela i histogram su zavisni od modela: treba ih obavestiti kad model promeni stanje – nema ograničenja u broju zavisnih objekata koje treba obaveštavati – ključni objekti u uzorku su subjekat (subject) i posmatrač (observer) – posmatrač zavisi od subjekta • subjekat obaveštava posmatrača kad promeni stanje • posmatrač zatim šalje upit subjektu o njegovom stanju da bi ažurirao svoje stanje – uzorak se naziva i Publish-Subscribe • posmatrači se "pretplaćuju" kod subjekta za obaveštenja (notifikaciju) • subjekat šalje signal posmatraču (notifikacija) • siganali se šalju svim posmatračima i ne znajući ko su sve posmatrači • Primenljivost: uzorak treba koristiti u sledećim situacijama: – kada jedna apstrakcija ima barem dva međusobno zavisna apsekta takva da promena bilo kog utiče na promenu drugih – kada izmena jednog objekta zahteva izmenu nepoznatog broja drugih objekata – kada jedan objekat treba da signalizira promenu drugim objektima ne znajući ko su ti objekti
  • 110. Projektni uzorci - Posmatrač 111 Projektovanje softvera • Struktura: • Učesnici: – Subjekat (klasa Model) • zna svoje posmatrače; proizvoljan broj posmatrača može da nadgleda subjekat • obezbeđuje interfejs za pridruživanje i razdruživanje posmatrača – Posmatrac (klasa Komponenta) • definiše interfejs za signaliziranje promena subjekta – KonkretanSubjekat (klasa Statistika) • čuva stanje od interesa za konkretne posmatrače • omogućava čitanje stanja • šalje signal posmatračima kada se promeni stanje – KonkretanPosmatrac (klase Tabela, Histogram, Pita) • poseduje referencu na konkretan subjekat (subjekat može da bude i parametar) • čuva stanje koje treba da bude u konzistenciji sa stanjem konkretnog subjekta • implementira operaciju za signaliziranje promene subjekta • čita stanje konkretnog subjekta da bi ažurirao sopstveno stanje • Saradnja: – konkretan subjekat signalizira svojim posmatračima svaku promenu svog stanja – nakon poziva osvezi, konkretan posmatrač traži od subjekta informaciju o stanju – posmatrač koristi informaciju o stanju subjekta da ažurira svoje stanje • UML notacija Subjekat +pridruzi() +razdruzi() +obavesti() Posmatrac +osvezi() KonkretanSubjekat -stanjeSubjekta +citajStanje() +menjajStanje() KonkretanPosmatrac -stanjePosmatraca +osvezi() osvezi(){ stanjePosmatraca:=subjekat.citajStanje() } obavesti(){ for all p in posmatraci p.osvezi() } -posmatraci *1 -subjekat 1 * uzorak Posmatracsd s : KonkretanSubjekat p1 : KonkretanPosmatrac p2 : KonkretanPosmatrac 1 : menjajStanje() 2 : obavesti() 3 : osvezi() 4 : citajStanje() 5 : osvezi() 6 : citajStanje()
  • 111. 112 Projektni uzorci - Posmatrač Elektrotehnički fakultet u Beogradu • Posledice: – dobre strane • apstraktno vezivanje između subjekata i posmatrača; tako se omogućava da subjekat i posmatrač budu u različitim slojevima aplikacije • podrška sa broadcast komunikaciju; subjekat ne zna identitet posmatrača kojem šalje signal – nedostatak: • nepoznata cena promene: pošto posmatrači ne znaju ko će sve dobiti signal, oni nisu svesni cene promene subjekta • Povezani uzorci: – za kapsuliranje kompleksne semantike ažuriranja Mediator može da posreduje između subjekata i posmatrača Model Prikaz Tabela Histogram PitaStatistika Uzorak Posmatrac Subjekat KonkretanSubjekat KonkretanPosmatrac Posmatrac
  • 112. Projektni uzorci - Iterator 113 Projektovanje softvera Iterator • Ime i klasifikacija: – Iterator (engl. Iterator) – objektni uzorak ponašanja • Namena: – obezbeđuje pristup elementima zbirke (agregata) redom, bez eksponiranja interne strukture te zbirke • Drugo ime: – Kurzor (engl. Cursor), za specifičnu vrstu iteratora • Motivacija: – lista (agregat) treba da omogući pristup njenim elementima – interna struktura liste ne treba da bude eksponirana klijentima – može postojati više načina za obilazak liste • klasu liste ne treba opteretiti operacijama za razne načine obilazaka • ni klijenta ne treba opteretiti specifičnostima načina obilaska liste – potrebno je da više klijenata simultano obilazi listu – ključna ideja uzorka Iterator: • prenošenje odgovornosti za obilazak liste na poseban objekat - iterator – klasa iteratora definiše interfejs za pristup elementima liste – objekat iteratora zna način obilaska liste i to: • od kog elementa početi obilazak • koji su elementi liste već posećeni, odnosno koji je naredni na redu • kada je obilazak završen (nema neobiđenih elemenata) – objekat iteratora čuva informaciju o tekućem elementu obilaska – relacija između klasa Lista i IteratorListe: Lista +brojElemenata() +dodajElement() +ukloniElement() IteratorListe -indeks +prviElement() +sledeciElement() +kraj() +tekuciElement() -lista *1 – prviElement()- inicijalizuje pokazivač tekućeg elementa postavljanjem na prvi element – sledeciElement()- proglašava naredni element tekućim – kraj() - testira da li je obilazak završen – tekuciElement()- vraća tekući element liste – razdvajanje mehanizma obilaska od objekta liste omogućava definisanje posebnih iteratora za različite politike obilaska • na primer: IteratorFiltriraneListe može pružiti pristup samo onim elementima koji zadovoljavaju uslove filtra • interfejs klase Lista nije opterećen raznim politikama obilaska – nedostatak: • klijent mora biti svesan da se obilazi baš lista, a ne neka druga struktura • ukoliko bi se menjala struktura koja se obilazi – morao bi se menjati kod klijenta – generalizacija koncepta iteratora: polimorfni iterator – primer: • klijent treba da radi sa klasom Lista ali i sa klasom FIFOLista
  • 113. 114 Projektni uzorci - Iterator Elektrotehnički fakultet u Beogradu – definiše se interfejs ApstraktnaLista • za manipulisanje proizvoljnom listom – definiše se interfejs Iterator • za objekte iteratora svih vrsta lista – potklase koje implementiraju interfejs Iterator biće iteratori za odgovarajuće liste – mehanizam iteratora je postao nezavisan od konkretnih klasa lista • klijent ne mora da vodi računa o vrsti liste, odnosno iteratora – da bi se klijent učinio nezavisnim od konkretne liste/iteratora: • definiše se operacija liste kreirajIterator() kojom ova treba da kreira svoj iterator • klijenti koriste apstraktnu operaciju i tako su nezavisni od konkretnih klasa liste • operacija kreirajIterator() je primer Fabirčkog metoda • Primenljivost: uzorak treba koristiti – da se podrže višestruki simultani obilasci agregata – da se obezbedi uniformni interfejs za obilazak različitih agregata – da se ni klijent ni agregat ne opterete politikom obilaska • Struktura: • Učesnici: – Agregat (klasa ApstraktnaLista) • definiše interfejs za kreiranje objekta iteratora – Iterator (klasa Iterator) • definiše interfejs za obilazak elemenata agregata i pristup elementu – KonkretanAgregat (klase Lista, FIFOLista ) • implementira interfejs za kreiranje iteratora tako što vraća odgovarajući konkretan iterator – KonkretanIterator (klase IteratorListe, IteratorFIFOListe) ApstraktnaLista +kreirajIterator() +brojElemenata() +dodajElement() +ukloniElement() Klijent Iterator +prviElement() +sledeciElement() +kraj() +tekuciElement() Lista FIFOLista IteratorFIFOListe IteratorListe -struktura *1 -iterator 11 <<instantiate>> *1 <<instantiate>> *1 Agregat +dodajElement() +izbaciElement() +napraviIterator() Iterator +prviElement() +sledeciElement() +kraj() +tekuciElement() KonkretanAgregat +napraviIterator() KonkretanIterator 1 * Klijent1 * 11 <<instantiate>> napraviIterator(){ return <<create>> KonkretanIterator(this); }
  • 114. Projektni uzorci - Iterator 115 Projektovanje softvera • implementira interfejs Iterator • čuva informaciju o tekućoj poziciji pri obilasku agregata • Saradnja: – konkretan iterator vodi računa o tekućem objektu u agregatu i može da odredi sledeći objekat u obilasku agregata • UML notacija: • Posledice: – Iterator ima sledeće dobre strane: • pojednostavljuje interfejs agregata: − interfejs za obilazak je u klasi iteratora • više od jednog obilaska se može simultano sprovoditi nad agregatom • podržava varijacije u obilasku agregata: − lako se kreira nova klasa konkretnog iteratora za novi način obilaska • Implementacija: – ko upravlja iterativnim procesom? • Spoljašnji (external) iterator – klijent kontroliše iteraciju − na klijentu je odgovornost za progres obilaska − eksplicitno zahteva od iteratora sledeći element • Unutrašnji (internal) iterator – iterator kontroliše iteraciju − klijent samo zahteva od iteratora da izvrši neku operaciju − sam iterator primenjuje operaciju na svaki element agregata • spoljašnji iterator je fleksibilniji od unutrašnjeg – ko definiše algoritam obilaska? • po pravilu – iterator, ali ne i obavezno • agregat može definisati algoritam obilaska − iterator se koristi samo da čuva stanje iteracije - samo ukazuje na tekuću poziciju u agregatu − ovakav iterator se naziva Kurzor (Cursor) − agregat ima operacije za obilazak i dohvatanje: prviElement(),… − klijent poziva operaciju sledeciElement() sa kurzorom kao argumentom − operacija sledeciElement() promeni stanje kurzor-objekta • ako se algoritam obilasaka definiše u klasi agregata gube se povoljnosti: − lakog variranja iterativnih algoritama nad istim agregatom − reupotrebe algoritma za obilazak sličnih agregata – koliko je robustan iterator? • opasno je modifikovati agregat dok se on obilazi − moguće je ukloniti tekući element (iterator postaje “viseći”) − moguće je umetnuti ili ukloniti naredni element (problem ako je iterator već zapamtio adresu narednog) • robusno implementiran uzorak iteratora obezbeđuje da umetanje/uklanjanje elemenata agregata ne interferira sa obilaskom • sprečavanje interferencije − ne treba raditi kopiranjem agregata − agregat treba da registruje iteratore koje je kreirao − pri umetanju i uklanjanju elementa agregat prilagođava stanje registrovanih iteratora – Dodatne operacije iteratora za uređene/indeksirane agregate • prethodniElement() pozicionira iterator na prethodni element ApstraktnaLista IteratorLista IteratorListe Agregat KonkretanAgregat Iterator KonkretanIterator Klijent Klijent Uzorak Iterator
  • 115. 116 Projektni uzorci - Iterator Elektrotehnički fakultet u Beogradu • skociNa() pozicionira iterator na objekat koji odgovara specifičnim kriterijumima – Polimorfni iteratori u C++ • polimorfni iteraratori imaju svoju cenu – objekat iteratora se alocira dinamički • drugi nedostatak je što je klijent odgovoran za dealokaciju objekta iteratora – Iteratori mogu imati privilegovani pristup • iteratori se mogu posmatrati kao ekstenzije agregata sa kojima su čvrsto spregnuti • na C++ se čvrsta sprega može iskazati tako što su iteratori prijatelji agregata • ako su iteratori prijatelji, agregat ne mora da implementira operacije za efikasni pristup • loša strana rešenja je što pri definisanju novih iteratora mora da se menja agregat (da bi se proglasio novi prijatelj) • klasa Iterator može da uključi neke zaštićene operacije za direktan pristup agregatu − date operacije koriste samo izvedene klase iz klase Iterator – Iteratori za objekte Sastava • objekti sastava (u hijerarhiji stabla) se često obilaze na razne načine: − prefiksnim/infiksnim/postfiksnim redosledom, po širini/dubini stabla • nije jednostavno spolja pamtiti poziciju – ona treba da uključi putanju od korena • zato su spoljašnji iteratori komplikovaniji za agregate tipa sastava • unutrašnji iteratori implicitno čuvaju putanju na steku − rekurzivno se izvršava zadata operacija – NullIterator • degenerisani iterator pogodan za obradu graničnih uslova • po definiciji, njegova operacija kraj() uvek vraća true • pogodan je za obilazak agregata tipa stabla (kao što je Sastav) − u svakom koraku obilaska od čvora se traži iterator za obilazak njegove dece − svi čvorovi osim listova vraćaju konkretni iterator, a list vraća NullIterator − ovim se dobija uniformnost u obilasku strukture stabla • Povezani uzorci: – Iterator se često primenjuje na rekurzivne strukture kao što je Sastav – Polimorfni iteratori se zasnivaju na Fabričkom metodu • apstraktna operacija agregata (fabrike) za kreiranje iteratora • konkretizuje se u potklasi konkretnog agregata • objekat konkretnog agregata stvara objekat konkretne potklase iteratora – Iterator interno može da koristi Podsetnik za čuvanje stanja iteracije
  • 116. Projektni uzorci - Dekorater 117 Projektovanje softvera Dekorater • Ime i klasifikacija: – Dekorater (engl. Decorator) – objektni uzorak strukture • Namena: – dinamički dodaje odgovornosti (mogućnosti) nekom objektu – predstavlja fleksibilnu alternativu izvođenju za proširivanje funkcionalnosti • Druga imena: – Dopuna, Omotač (engl. Wrapper) • Motivacija: – alati za GUI podržavaju dodavanje “ukrasa” na razne komponente • klizači, okviri sa raznim efektima,… – jedan način za dodavanje mogućnosti – nasleđivanje sa proširivanjem • nasleđivanje je nefleksibilno, jer bi se ukrasi birali statički − klijent ne može da bira kada da se iscrtava okvir, na primer • opasnost od eksplozije broja izvedenih klasa kada se kombinuju ukrasi – fleksibilniji pristup je da se komponenta obuhvati drugom komponentom • komponenta koja obuhvata osnovnu dodaje ukras (okvir, klizače) • proširenja mogu biti specifična stanja ili ponašanja • odgovornosti se dodaju pojedinom objektu, a ne celoj klasi – komponenta koja obuhvata osnovnu se naziva • dekoraterom, omotačem ili dopunom – dekorater prosleđuje zahteve klijenta obuhvaćenoj komponenti i može da obavi dodatne akcije • kao što je crtanje okvira ili dodavanje klizača za pomeranje – dekorater nasleđuje interfejs komponente koju ukrašava – prisustvo dekoratera je transparentno za klijente komponente • transparentnost omogućava neograničen broj dodataka uvedenih posebnim dekoraterima – primer: • TekstKomponenta prikazuje tekst u prozoru i nema klizače za H/V pomeranje sadržaja, ni okvir • ako su potrebni klizači − dodajemo objekat klase DopunaKlizacem koji ih dodaje • ako se želi i okvir − dodajemo i objekat klase DopunaOkvirom koji crta okvir • sledeći dijagram prikazuje objektnu kompoziciju i interakciju: dK : DopunaKlizacemdI : DopunaOkvirom tK : TekstKomponenta 1 : crtaj() 2 : crtaj()
  • 117. 118 Projektni uzorci - Dekorater Elektrotehnički fakultet u Beogradu – sledeći dijagram prikazuje opisanu klasnu strukturu: • Primenljivost: – kada je potrebno dinamički dodavati odgovornosti objektima na transparentan način – kada proširenje izvođenjem nije praktično (kada je moguć veliki broj nezavisnih proširenja, pri čemu se ona mogu kombinovati, što vodi eksploziji broja klasa) • Struktura: Komponenta +operacija() Dopuna +operacija() Subjekat +operacija() -komponenta 1 KonkretnaDopuna2 +operacija() +dodatnoPonasanje() KonkretnaDopuna1 -dodatnoStanje +operacija() • Učesnici: – Komponenta (klasa VizuelnaKomponenta) • definiše interfejs za objekte kojima se mogu dinamički dodavati odgovornosti – Subjekat (klasa TekstKomponenta) • definiše objekat kojem se dodaju odgovornosti – Dopuna (klasa Dopuna) • održava referencu na objekat klase Komponenta i nasleđuje interfejs klase Komponenta – KonkretnaDopunaX (klase DopunaKlizacem, DopunaOkvirom ) • dodaje odgovornost objektu klase Komponenta VizuelnaKomponenta +crtaj() TekstKomponenta +crtaj() Dopuna +crtaj() DopunaKlizacem -pozicijaKlizaca +crtaj() +crtajKlizac() +pomeriKlizac() DopunaOkvirom -debljinaOkvira +crtaj() +crtajOkvir() -komponenta 1 1 crtaj(){komponenta->crtaj();} crtaj(){ Dopuna::crtaj(); crtajOkvir(); }
  • 118. Projektni uzorci - Dekorater 119 Projektovanje softvera • Saradnja: – objekat KonkretnaDopunaX • prosleđuje zahteve obuhvaćenom objektu (klase Komponenta) • izvršava dodatne operacije pre i/ili posle prosleđivanja zahteva • Posledice – prednosti • veća fleksibilnost od statičkog nasleđivanja − dinamičko dodavanje odgovornosti • izbegavanje bogato parametrizovanih klasa visoko u hijerarhiji • izbegavanje eksplozije potklasa koje kombinuju ukrase – mane • identitet dekoratera i dekorisanog objekta su različiti • objekti se ne razlikuju po klasi već po načinu povezivanja − potencijalan problem kod razumevanja i održavanja sistema • nasleđeni atributi komponente, ako postoje (duplikat) − dobro je da apstraktna komponenta nema atribute • UML notacija: • Povezani uzorci: – Dekorater zadržava interfejs, a Adapter menja interfejs – Kompozicija ima sličnu strukturu • Dekorater je po strukturi degenerisana Kompozicija (Sastav, Sklop) − objekat Dopuna sadrži samo jednu komponentu, a objekat Kompozicija više • po nameni je Dekorater sasvim različit, jer dodaje odgovornosti i nije namenjen grupisanju – Dekorater i Strategija su alternative za promenu ponašanja objekta • Dekorater menja spoljašnjost objekta, a Strategija unutrašnjost VizuelnaKomponenta TekstKomponenta Dopuna DopunaKlizacem DopunaOkvirom Komponenta Subjekat KonkretnaDopuna Dopuna Uzorak Dekorater
  • 119. 120 Projektni uzorci - Strategija Elektrotehnički fakultet u Beogradu Strategija • Ime i klasifikacija: – Strategija (engl. Strategy) – objektni uzorak ponašanja • Namena: – definiše familiju algoritama, kapsulirajući svaki, i čini ih međusobno zamenjivim – omogućava jednostavnu promenu algoritma u vreme izvršenja • Drugo ime: – Politika (Policy) • Motivacija: – postoji više algoritama za prelom teksta u linije – ugrađivanje tih algoritama u klase koje ih zahtevaju nije dobro iz više razloga: • klijenti kojima je potreban prelom postaju kompleksniji i teži za održavanje • različiti algoritmi su odgovarajući u različitim trenucima, a teško ih je menjati • teško je dodati novi algoritam i varirati postojeći – kapsulirani algoritam u klasu se naziva strategija (strategy) – klasa Tekst je odgovorna za održavanje i ažuriranje preloma prikazanog teksta – strategije preloma nisu implementirane u klasi Tekst, već u potklasama Prelom – klasa Tekst sadrži referencu na objekat tipa Prelom – kada Tekst reformatira tekst – on prosleđuje tu odgovornost objektu klase Prelom – klijent klase Tekst specificira objekat Prelom instalirajući ga u Tekst • Primenljivost: – kada se više srodnih klasa razlikuju samo po ponašanju • uzorak omogućava konfigurisanje klase jednim od više ponašanja – kada su potrebne različite varijante nekog algoritma – kada algoritam koristi podatke o kojima klijenti ne treba ništa da znaju • izbegava se eksponiranje kompleksnih struktura podataka specifičnih za algoritam – potrebno kapsuliranje algoritma i podataka – kada klasa konteksta definiše više ponašanja koja se pojavljuju kao grane uslovne naredbe u raznim operacijama • grane uslovne naredbe treba kapsulirati u njima odgovarajuće klase strategije Tekst +popravi() +prikazi() Prelom +prelomi() JednostavanPrelom +prelomi() TeXPrelom +prelomi() -prelamac prikazi(){ prelamac->prelomi(); }
  • 120. Projektni uzorci - Strategija 121 Projektovanje softvera • Struktura: Kontekst Strategija +operacija() -strategija KonkretnaStartegija1 +operacija() KonkretnaStrategija2 +operacija() • Učesnici: – Strategija (klasa Prelom) • deklariše zajednički interfejs za sve podržane algoritme – KonkretnaStrategijaX (klase JednostavanPrelom, TeXPrelom) • implementira konkretan algoritam tako da odgovara interfejsu klase Strategija – Konktekst (klasa Tekst) • konfigurisan je objektom KonkretnaStrategijaX • poseduje referencu na objekat tipa Strategija • može da pruži interfejs koji omogućava objektu strategije da pristupi njegovim podacima • Saradnja: – KonkretnaStrategijaX i Kontekst interaguju da implementiraju izabrani algoritam • Kontekst može da pošalje sve podatke koje zahteva algoritam pri pozivu objekta Strategija, ili da pošalje referencu na sebe i tako omogući povratni poziv (callback) – Kontekst prosleđuje zahteve svojih klijenata svom objektu Strategija • klijenti obično kreiraju i prosleđuju objekte KonkretnaStrategijaX objektu Kontekst • kasnije klijenti interaguju samo sa objektom Kontekst • UML notacija: • Posledice: – Familije srodnih algoritama – hijerarhija Strategija klasa definiše familiju algoritama – Alternativa izvođenju iz klase Kontekst (kad bi Kontekst implementirao algoritam) – Strategije eliminišu potrebu za uslovnim naredbama u klijentskom kodu – Izbor implementacija – klijent bira da postigne performanse u vremenu/prostoru – Klijenti moraju biti svesni različitih strategija - nedostatak – Kontekst kreira nepotrebne parametre za neke objekte KonkretnaStrategijaX – Povećava se broj objekata u aplikaciji zbog objekata KonkretnaStrategijaX • Povezani uzorci: – Objekti Strategije često predstavljaju dobre objekte Muve Tekst Prelom JednostavanPrelom TeXPrelom Kontekst Strategija KonkretnaStrategija Uzorak Strategija
  • 121. 122 Projektni uzorci – Šablonski metod Elektrotehnički fakultet u Beogradu Šablonski metod • Ime i klasifikacija: – Šablonski metod (engl. Template Method) - klasni uzorak ponašanja • Namena: – definiše skelet nekog algoritma operacije, delegirajući pojedine korake potklasama – omogućava potklasama da redefinišu neke korake algoritma bez izmene njegove strukture • Motivacija: – razmatra se radni okvir za razvoj aplikacije koji obezbeđuje klase Aplikacija i Dokument – klasa Aplikacija je odgovorna za otvaranje postojećih dokumenata – dokumenti se čuvaju u nekom eksternom formatu (fajlu) – objekt klase Dokument reprezentuje informaciju u dokumentu nakon što je učitana iz fajla – aplikacije koje se grade iz radnog okvira mogu da naslede klase Aplikacija i Dokument • npr. aplikacija za crtanje definiše potklase Editor i Crtež – apstraktna klasa Aplikacija definiše algoritam za otvaranje dokumenta • algoritam je implementiran u otvoriDokument() operaciji void Aplikacija::otvoriDokument(const char* ime){ if (!postojiLiDokument(ime))return; Dokument * dokument=napraviDokument(); if (dokument){ dodajDokument(dokument); preOtvaranja(dokument); dokument->otvori(); dokument->citaj(); } } – otvoriDokument() definiše korake za otvaranje dokumenta – metod otvoriDokument() se naziva Šablonski metod – šablonski metod definiše algoritam sastavljen od apstraktnih operacija – potklase definišu operacije da obezbede konkretno ponašanje – definisanjem koraka algoritma šablonski metod fiksira njihov redosled – potklase prilagođavaju korake algoritma svojim potrebama • Primenljivost: uzorak treba koristiti – da se implementiraju invarijantni delovi algoritma jednom, a da se ostave potklasama za implementaciju delovi koji mogu varirati RadniOkvir Dokument +sacuvaj() +otvori() +zatvori() +citaj() Aplikacija +dodajDokument() +otvoriDokument() +postojiLiDokument() +napraviDokument() +preOtvaranja() Crtez +citaj() Editor +napraviDokument() +preOtvaranja() -dokumenti 1* <<instantiate>> napraviDokument(){ return new Crtez(); }
  • 122. Projektni uzorci – Šablonski metod 123 Projektovanje softvera – kada zajedničko ponašanje među potklasama treba lokalizovati da se izbegne dupliranje • Struktura: • Učesnici: – ApstraktnaKlasa (klasa Aplikacija) • implementira šablon (skelet) algoritma koji poziva primitivne operacije • deklariše apstraktne primitivne operacije za korake algoritma koje će potklase definisati – KonkretnaKlasa (klasa Editor) • implementira primitivne operacije koje obavljaju delove algoritma specifične za potklase • Saradnja: – KonkretnaKlasa implementira varijantne korake algoritma za klasu ApstraktnaKlasa • UML notacija: • Posledice: – fundamentalna tehnika za reupotrebu koda (zajedničko ponašanje u klasama radnog okvira) – vodi invertovanoj kontrolnoj strukturi (holivudski princip: "Ne zovite nas, mi ćemo zvati Vas" – roditeljska klasa zove operacije dece) – izbegava se rizik da izvedena klasa iz redefinisane operacije ne pozove potrebnu operaciju roditeljske klase – mogu se neke primitivne operacije realizovati u apstraktnoj klasi kao rudimentarne hook operacije koje obezbeđuju podrazumevano ponašanje • Povezani uzorci: – Fabrički Metod (npr. napraviDokument) se često poziva iz Šablonskog Metoda – Šablonski Metod statički varira deo algoritma, a Strategija dinamički varira ceo algoritam ApstraktnaKlasa +operacija1() +operacija2() +operacija3() +sablonskiMetod() KonkretnaKlasa +operacija1() +operacija2() +operacija3() sablonskiMetod(){ ... operacija1(); ... operacija2(); ... operacija3(); ... } Aplikacija EditorUzorak Sablonski Metod ApstraktnaKlasa KonkretnaKlasa
  • 123. 124 Projektni uzorci – Adapter Elektrotehnički fakultet u Beogradu Adapter • Ime i klasifikacija: – Adapter – klasni i objektni uzorak strukture (različite realizacije) • Namena: – konvertuje interfejs klase u drugi interfejs koji klijenti očekuju – omogućava da rade zajedno klase koje inače to ne bi mogle, zbog različitog interfejsa • Drugo ime: – Omotač (engl. Wrapper) – dvoznačno, koristi se i za Dekorater • Motivacija: – ponekad neka korisna klasa iz biblioteke nije upotrebljiva • razlog: njen interfejs ne odgovara domenski specifičnom interfejsu kakav očekuje aplikacija – razmatra se primer grafičkog editora • editor omogućava crtanje i aranžiranje grafičkih elemenata • grafički elementi su linije, poligoni, tekst − oni se nalaze na slikama i dijagramima • ključna apstrakcija grafičkog editora je grafički objekat • grafički objekat ima editabilan oblik i može sam da se nacrta • interfejs za grafičke objekte je definisan apstraktnom klasom (Grafik) • editor definiše potklase klase Grafik za svaki tip grafičkog objekta: Linija, Poligon, Tekst, ... • klasu Tekst je značajno kompleksnije implementirati od drugih klasa • postojeća klasna biblioteka nudi klasu TextView − za prikaz i editovanje teksta • problem: − klasna biblioteka nije imala u vidu klasu Grafik kada je definisan TextView − ne mogu se koristiti naslednici Grafik i TextView polimorfno (različiti interfejsi) • rešenje: − definisati Tekst na način da adaptira interfejs TextView prema Grafik − implementirati Tekst pomoću TextView • ovo se može uraditi na jedan od dva načina: − implementacijom interfejsa Grafik i nasleđivanjem TextView ili − agregacijom TextView u Tekst • ova dva pristupa odgovaraju klasnoj i objektnoj verziji uzorka Adapter Editor Grafik <<interface>> +dimenzije() TextView +width() +height() Tekst +dimenzije() Linija +dimenzije() Poligon +dimenzije() dimenzije(){ return new Dimenzije(width(), height()); }
  • 124. Projektni uzorci – Adapter 125 Projektovanje softvera • Primenljivost: – generalno, uzorak treba koristiti kada: • želimo da koristimo neku raspoloživu klasu koja nema interfejs kakav nam odgovara • želimo da kreiramo reupotrebljivu klasu koja sarađuje sa nepovezanim i nepredviđenim klasama, t.j. klasama čiji interfejsi nisu neophodno kompatibilni – objektni adapter treba koristiti kada: • treba koristiti nekoliko postojećih potklasa, ali je nepraktično adaptirati njihove interfejse višestrukim izvođenjem iz svake od tih klasa • Struktura: – klasni adapter: – objektni adapter: • Učesnici: – Cilj (klasa Grafik) • definiše domenski-specifičan interfejs koji koristi klijent – Klijent (klasa Editor) • sarađuje sa objektima koji poštuju interfejs Cilj – Adaptirani (klasa TextView) • definiše neki postojeći interfejs koji zahteva adaptiranje – Adapter (klasa Tekst) Editor Grafik <<interface>> +dimenzije() TextView +width() +height() Tekst +dimenzije() Linija +dimenzije() Poligon +dimenzije() dimenzije(){ return new Dimenzije(t->width(),t->height()); } -t Adapter +opearacija() Adaptirani +specificnaOperacija() Cilj +operacija() operacija(){ ... specificnaOperacija(); ... } Klijent Adapter +opearacija() Klijent Cilj +operacija() Adaptirani +specificnaOperacija() -adaptirani1 operacija(){ ... adaptirani->specificnaOperacija(); ... }
  • 125. 126 Projektni uzorci – Adapter Elektrotehnički fakultet u Beogradu • adaptira interfejs Adaptirani na interfejs Cilj • Saradnja: – klijenti pozivaju operacije objekta adaptera, a adapter poziva operacije adaptiranog podobjekta (nasleđivanjem ili agragacijom) da izvrše zahtev • UML notacija: • Posledice: – klasni Adapter ima sledeće karakteristike: • ne odgovara kada se želi adaptiranje neke klase i svih njenih potklasa • dopušta adapteru kao potklasi da redefiniše metode adaptirane natklase, • uvodi samo jedan objekat i nema potrebe za dodatnom indirekcijom (pokazivačem) da se stigne do adaptiranog objekta – objektni Adapter ima sledeće karakteristike: • dopušta jednom adapteru da radi sa hijerarhijom adaptiranih klasa (adapter može da doda funkcionalnost za sve adaptirane klase odjednom) • identitet ciljnog objekta i adaptiranog objekta se razlikuje – dvosmerni Adapter – zadržava i interfejs Adaptirani • objekat se može koristiti i kao Cilj i kao Adaptirani • postiže se transparentnost za različite klijente • Implementacija: – u C++ se klasni uzorak reallizuje javnim izvođenjem iz Cilj i privatnim iz Adaptirani • ukoliko se ne želi dvosmerni adapter • Povezani uzorci: – I Dekorater i objektni Adapter prave omotače nekog objekta – Dekorater dopunjuje drugi objekat ne menjajući mu interfejs, a Adapter upravo menja interfejs adaptiranog objekta • posledica: Dekorater podržava rekurzivne kompozicije, koje nisu moguće sa adapterima – Most ima sličnu strukturu objektnom adapteru • namena je drugačija Grafik <<interface>>Editor TextViewTekst Klijent Cilj Adapter Adaptirani Uzorak Adapter
  • 126. Projektni uzorci – Stanje 127 Projektovanje softvera Stanje • Ime i klasifikacija: – Stanje (engl. State) – objektni uzorak ponašanja • Namena: – omogućava objektu da pouzdano menja svoje ponašanje kada se menja njegovo unutrašnje stanje – izgleda kao da objekat menja svoju klasu • Drugo ime: – Objekti za stanja (engl. Objects for States) • Motivacija - primer vezan za mrežni TCP protokol TCPConnection +open() +close() +acknowledge() TCPState +open() +close() +acknowledge() TCPEstablished +open() +close() +acknowledge() TCPListen +open() +close() +acknowledge() TCPClosed +open() +close() +acknowledge() -state – vezu opisuje TCPConnection klasa – moguća stanja veze: Established, Listening, Closed – TCPConnection objekat odgovara na zahteve u zavisnosti od stanja • npr. efekat open() zahteva se razlikuje u stanju Closed i Established – uzorak Stanje opisuje kako ponašanje TCPConnection objekta zavisi od stanja – ključna ideja: uvođenje apstraktne klase TCPState • klasa predstavlja stanja veze – klasa TCPState deklariše zajednički interfejs za klase stanja – potklase TCPState realizuju specifično ponašanje pojedinih stanja – klasa TCPConnection održava objekat stanja (objekat potklase TCPState) koji reprezentuje tekuće stanje veze – klasa TCPConnection prosleđuje objektu stanja zahteve koji su zavisni od tekućeg stanja – kada konekcija menja stanje TCPConnection objekat zamenjuje objekat stanja koji koristi • Primenljivost: – kada ponašanje objekta zavisi od stanja i mora se menjati u vreme izvršavanja – kada operacije imaju velike uslovne naredbe sa više grana, čije izvršenje zavisi od stanja objekta • često više operacija sadrži istu uslovnu naredbu • uzorak Stanje pravi od svake grane posebnu klasu koja određuje ponašanje operacije u datom stanju
  • 127. 128 Projektni uzorci – Stanje Elektrotehnički fakultet u Beogradu • Struktura: Kontekst +zahtev() Stanje -stanje +obradi() KonkretnoStanjeA +obradi() KonkretnoStanjeB +obradi() -stanje • Učesnici: – Kontekst (klasa TCPConnection) • definiše interfejs od interesa za klijente • održava primerak KonkretnoStanjeX – Stanje (klasa TCPState) • definiše interfejs za pojedina stanja • kapsulacija ponašanja pridruženog stanju objekta klase Kontekst – KonkretnoStanjeX (klase TCPEstablished, TCPListen, TCPClosed) • implementira interfejs stanja • Posledice: – lokalizacija ponašanja specifičnog za stanje i razdvajanje ponašanja u različitim stanjima – nova stanja se lako dodaju definisanjem novih potklasa stanja • nefleksibilna alternativa su uslovni iskazi rasuti svuda po kodu konteksta − veliki uslovni iskazi komplikuju održavanje koda i treba ih izbegavati – prelazi između stanja su eksplicitni • kada objekat konteksta definiše samostalno svoje stanje vrednostima atributa, onda prelazi između stanja nemaju eksplicitnu reprezentaciju: − predstavljaju se dodelama vrednosti atributima • objekti stanja štite objekat konteksta od nekonzistentnih stanja − prelazi su atomski iz perspektive konteksta − prelaz se svodi na prevezivanje jednog pokazivača – objekti stanja mogu biti deljeni • ako objekti stanja nemaju atribute, već je stanje koje reprezentuju kodirano u njegovom tipu − konteksti mogu da dele isti objekat stanja • tada su objekti stanja “muve” bez unutrašnjeg stanja, poseduju samo ponašanje • UML notacija: • Povezani uzorci: – Muva – objašnjava kada se objekti stanja mogu deliti – Objekti stanja se često realizuju kao Unikati TCPConnection TCPState TCPEstablished TCPListen TCPClosed Uzorak Stanje KonkretnaStanja Kontekst Stanje
  • 128. Projektni uzorci – Podsetnik 129 Projektovanje softvera Podsetnik • Ime i klasifikacija: – Podsetnik (engl. Memento) – objektni uzorak ponašanja • Namena: – bez narušavanja kapsulacije, snima i eksternalizuje unutrašnje stanje nekog objekta – omogućava da se objekat kasnije može vratiti u dato stanje • Drugo ime: – Oznaka (engl. Token) • Motivacija: – podrška za poništavanje operacija (undo) – potrebno je sačuvati unutrašnje stanje objekta, kako bi ga kasnije vratili u to stanje – problem: objekat kapsulira svoje stanje i nije dobro da ga eksponira • zato menjani objekat treba sam da snimi svoje stanje – “podsetnik” • objekat podsetnika ne mora da čuva objekat koji ga je snimio – primer: crtanje olovkom u editoru ikona • editor obezbeđuje da se nakon iscrtavanja traga isti može restaurirati – klasa Editor • pokreće operacije klase Olovka i poseduje operaciju ponisti() – klasa Olovka poseduje operacije: • spusti() – otpočinje crtanje − pamti se prethodna bitmapa ikone • pomeri() – pomera olovku − ako je olovka spuštena, pikseli na tragu se menjaju − pamte se min/max X i Y koordinata • podigni() – završava crtanje − odseca se deo bitmape izvan min/max X i Y koordinata − preostali deo bitmape (podsetnik) se daje editoru na čuvanje – operacija ponisti() • olovci se dostavlja podsetnik da restaurira sliku • Primenljivost: uzorak treba koristiti kada – treba napraviti snimak stanja nekog objekta da bi se stanje kasnije restauriralo stanje – direktan interfejs za dobijanje stanja bi eksponirao implementacione detalje EditorOlovka Bitmapa -podsetnik
  • 129. 130 Projektni uzorci –Podsetnik Elektrotehnički fakultet u Beogradu • Struktura: • Učesnici: – Podsetnik (klasa Bitmapa) • čuva unutrašnje stanje Subjekat objekta • ne dozvoljava pristup stanju drugim objektima osim objektu Subjekat • ima dva interfejsa: Cuvar vidi uski, Subjekat vidi široki – Subjekat (klasa Olovka) • kreira Podsetnik objekat koji sadrži snimak njegovog tekućeg stanja • ima diskreciono pravo da odluči koji deo stanja se čuva • koristi Podsetnik objekat da restaurira stanje – Cuvar (klasa Editor) • odgovoran za bezbedno čuvanje Podsetnik objekta • ne ispituje i ne koristi stanje Podsetnik objekta • Saradnja: objekti podsetnika su pasivni • UML notacija: • Povezani uzorci: – u uzorku Komanda - Podsetnik se može koristiti za čuvanje stanja poništivih operacija – u uzorku Iterator- Podsetnik se može koristiti za čuvanje podatka o tekućem elementu : Cuvar : Podsetnik : Subjekat napraviPodsetnik() Podsetnik() <<create>> postaviStanje() restaurirajStanje() dohvatiStanje() Subjekat -stanje +napraviPodsetnik() +restaurirajStanje(p: Podsetnik) Podsetnik -stanje +dohvatiStanje() +postaviStanje() CuvarnapraviPodsetnik(){ return new Podsetnik(stanje); } restaurirajStanje(p:Podsetnik){ stanje=p.dohvatiStanje(); } -podsetnik Subjekat Podsetnik Cuvar EditorOlovka Bitmapa Uzorak Podsetnik
  • 130. Projektni uzorci – Muva 131 Projektovanje softvera Muva • Ime i klasifikacija: – Flyweight – objektni uzorak strukture • Namena: – deljenje “lakih” objekata sa ciljem da se izbegne hiperprodukcija objekata – laki objekti su objekti bez stanja ili objekti čije unutrašnje stanje ne zavisi od stanja konteksta − stanje konteksta definiše “spoljašnje” stanje lakog objekta • Motivacija: – editor teksta organizuje dokument kao hijerarhiju kolona, redova, znakova : Kolona : Red : Red : Red : Znak : Znak: Znak : Znak: Znak : Znak: Znak – problem: hiperprodukcija objekata znakova – rešenje: svaki objekat znaka reprezentuje pojedini znak, a red u kojem se znak nalazi određuje kontekst pojave znaka • red izračunava poziciju pojave znaka u dokumentu • znak pamti samo svoj specifični kod : Kolona : Red : Red : Red : Znak : Znak : Znak: Znak Alfabetski skup • Primenljivost: ako su ispunjeni svi uslovi – aplikacija koristi veliki broj objekata koji troše značajan memorijski prostor – veći deo stanja objekta može da se prebaci u “spoljašnje” stanje – kada se ukloni spoljašnje stanje mnoge grupe objekata mogu da se zamene deljenim objektima sa unutrašnjim stanjem – identitet objekta nije bitan - testovi identiteta vraćaju true za sve njegove pojave u kontekstu • Struktura: • Učesnici: – Muva (klasa GrafičkiElement) • deklariše interfejs kroz koji muva prima spoljašnje stanje Muva +operacija(spoljasnjeStanje) FabrikaMuva +dohvatiMuvu(kljuc) KonkretnaMuva -unutrasnjeStanje +operacija(spoljasnjeStanje) NedeljenaKonkretnaMuva -stanjeZavisnoOdKonteksta +operacija(spoljasnjeStanje) Klijent dohvatiMuvu(kljuc){ if (muva=muve[kljuc]){ return muva; } else { muva=new KonkretnaMuva(); muve.dodaj(muva); return muva; } } -muve
  • 131. 132 Projektni uzorci – Muva Elektrotehnički fakultet u Beogradu – KonkretnaMuva (klasa Znak) • implementira interfejs muve i dodaje atribute unutrašnjeg stanja • objekti moraju biti deljivi, ne smeju da zavise od stanja konteksta – NedeljenaKonkretnaMuva (klase Kolona, Red) • interfejs muve dozvoljava deljenje, ali ga ne zahteva • u hijerarhiji objekata muva neki objekti mogu biti nedeljivi − oni čuvaju i atribute spoljašnjeg stanja (zavisnog od konteksta) − oni nisu listovi u objektnoj hijerarhiji (deljive muve su listovi) – FabrikaMuva (klasa FabrikaZnakova) • kreira i upravlja muvama • obezbeđuje propisno deljenje muva − kada klijent zahteva muvu, fabrika dohvata postojeću ili kreira novu, ako data ne postoji – Klijent (klasa Editor) • održava reference na dodeljene muve • smešta ili izračunava spoljašnje stanje objekata muva • Saradnja: – klijenti pri pozivu operacija prenose spoljašnje stanje muvi – klijenti ne smeju da prave objekte muve direktno, već preko fabrike muva • UML notacija: • Posledice: – potencijalni troškovi pronaženja i izračunavanja spoljašnjeg stanja – ušteda u prostoru zavisi od: • smanjenja broja objekata • odnosa unutrašnjeg i spoljašnjeg stanja po objektu • da li se spoljašnje stanje čuva ili izračunava • Povezani uzorci: – često se kombinuje sa uzorkom Kompozicija (Sastav, Sklop) za formiranje acikličnog grafa sa deljenim čvorovima u listovima – često se objekti uzoraka Stanje i Strategija prave kao muve Kolona Red Znak GrafickiElementFabrikaZnakova Klijent FabrikaMuva Muva NedeljeneKonkretneMuve KonkretnaMuva Editor Uzorak Muva
  • 132. Projektni uzorci – Fabrički metod 133 Projektovanje softvera Fabrički metod • Ime i klasifikacija: – Fabrički (proizvodni) Metod (Factory Method) – klasni uzorak kreiranja • Namena: – uzorak dopušta klasi da delegira stvaranje objekata potklasi – definiše interfejs za kreiranje objekata, ali ostavlja potklasama da odluče čije objekte kreiraju • Drugo ime: – Virtuelni Konstruktor (Virtual Constructor) • Motivacija: – razmatra se radni okvir (framework) za aplikacije koje mogu da rade sa više dokumenata – ključne apstrakcije su Aplikacija i Dokument – obe klase su apstraktne i klijenti treba da naprave potklase da ostvare specifične realizacije – klasa aplikacije je odgovorna za upravljanje dokumentima • ona kreira dokumente kada korisnik zahteva Otvori ili Novi iz menija • ona zna samo kada će kreirati dokument • ona ne zna konkretan tip dokumenta koji treba kreirati – radni okvir (framework) • skup opštih klijentskih klasa • korisnik projektuje serverske (klijentske pozivaju serverske) • radni okvir mora da stvara objekat klase dokumenta • on poznaje samo apstraktnu klasu dokumenta – konkretna potklasa aplikacije • redefiniše apstraktni metod klase aplikacije iz radnog okvira za kreiranje specifičnih dokumenta za datu aplikaciju • metod za kreiranje dokumenata je fabrički metod (odgovoran je za proizvodnju objekata konkretnog dokumenata) • Primenljivost: uzorak treba koristiti kada: – klasa ne može da anticipira klasu objekata koje mora da kreira – klasa želi da njene potklase odrede objekte koje će ona kreirati Dokument +otvori() +sacuvaj() +zatvori() MojDokument Aplikacija +noviDokument() +otvoriDokument() +napraviDokument() MojaAplikacija +npraviDokument() <<instantiate>> -dokumenti 1* noviDokument(){ Dokument dokument=napraviDokument; dokumenti.dodaj(dokument); dokument.otvori(); } napraviDokument(){ return new MojDokument(); }
  • 133. 134 Projektni uzorci – Fabrički metod Elektrotehnički fakultet u Beogradu • Struktura: • Učesnici: – Proizvod (klasa Dokument) • definiše interfejs objekata koje fabrickiMetod() kreira – KonkretanProizvod (klasa MojDokument) • implemetira interfejs Proizvod – Fabrika (klasa Aplikacija) • deklariše fabrickiMetod() koji vraća objekat tipa Proizvod • može da definiše podrazumevanu implementaciju za fabrickiMetod(), koji vraća podrazumevani objekat tipa KonkretniProizvod • iz neke operacije poziva fabrickiMetod() da kreira objekat Proizvod – KonkretnaFabrika (klasa MojaAplikacija) • redefiniše fabrickiMetod() tako da vrati objekat KonkretanProizvod • Saradnja: – Fabrika zavisi od svojih potklasa koje definišu fabrickiMetod() tako da on vraća odgovarajući objekat KonkretanProizvod • UML notacija: • Posledice: – uzorak eliminiše potrebu da se klijentski kod vezuje za aplikativno-specifične klase • klijent radi preko interfejsa Proizvod, pa može da radi sa bilo kakvim klasama KonkretanProizvod – Fabrički metod daje potklasama mogućnost da obezbede proširenu verziju nekog objekta • Povezani uzorci: – Fabrički Metod se obično poziva iz Šablonskog Metoda – Prototip ne zahteva izvođenje potklase iz klase Fabrika • on zahteva klon() operaciju u klasi Proizvod (Prototip), koju poziva Fabrika • Fabrički Metod ne zahteva takvu operaciju – Apstraktna Fabrika se često implementira pomoću Fabričkog metoda Dokument MojDokument Aplikacija MojaAplikacija Proizvod KonkretanProizvod Fabrika KonkretnaFabrika Uzorak Fabricki Metod Fabrika +operacija() +fabrickiMetod() KonkretnaFabrika +fabrickiMetod() Proizvod KonkretniProizvod <<instantiate>> operacija(){ ... fabrickiMetod(); ... } fabrickiMetod(){ return new KonkretniProizvod(); }
  • 134. Projektni uzorci – Apstraktna fabrika 135 Projektovanje softvera Apstraktna fabrika • Ime i klasifikacija: – Apstraktna fabrika (eng. Abstract Factory) – objektni uzorak kreiranja • Namena: – obezbeđuje interfejs za kreiranje familija povezanih ili zavisnih objekata (proizvoda) bez specificiranja konkretnih klasa te familije • Drugo ime: – Kit • Motivacija: – razmatra se klasna biblioteka za realizaciju korisničkog interfejsa • biblioteka podržava više standarda izgleda-i-osećaja (look-and-feel) • primeri su Motif i Presentation Manager (PM) – različit izgled i osećaj definiše različite pojave komponenata (widget) • primeri su prozori (windows), klizači (scroll bars) i dugmad (buttons) – aplikacija treba da bude portabilna između standarda izgleda i osećaja • ne smeju se fiksno kodirati stvari izgleda i osećaja • ne treba kreirati objekte specifičnog izgleda svuda po aplikaciji – rešenje problema - definiše se apstraktna klasa FabrikaKomponenata • klasa predstavlja apstrakciju fabrike familije komponenata • klasa definiše interfejs za kreiranje svih vrsta komponenata od interesa • za svaku vrstu komponente postoji apstraktan metod za kreiranje – potrebna je po jedna izvedena klasa stvarne fabrike za svaki standard izgleda i osećaja • one implementiraju operacije kreiranja koje je propisala apstraktna fabrika • operacije kreiranja poštuju specifičan standard izgleda i osećaja – potrebna je po jedna apstraktna klasa za svaku vrstu komponenata • konkretne potklase implementiraju komponentu za jedan standard izgleda FabrikaKomponenata +napraviProzor() +napraviDugme() MotifFabrika +napraviProzor() +napraviDugme() PMFabrika +napraviProzor() +napraviDugme() Prozor Dugme MotifProzor PMProzor GUIKlijent MotifDugme PMDugme <<instantiate>> <<instantiate>> <<instantiate>> <<instantiate>> -fabrika 1 *
  • 135. 136 Projektni uzorci – Apstraktna fabrika Elektrotehnički fakultet u Beogradu – klijenti metodima apstraktne fabrike proizvode objekte komponenata • klijenti nisu svesni konkretne fabrike koju koriste za proizvodnju komponenata – ostaju nezavisni od izgleda i osećaja • klijenti moraju da poštuju interfejs koji definiše apstraktna fabrika • samo pri kreiranju objekta konkretne fabrike klijent je svesan njegovog tipa – osim apstraktne fabrike klijenti vide i apstraktne komponente (neopterećene specifičnostima izgleda i osećaja) • Primenljivost: uzorak treba koristiti kada – sistem treba da bude konfigurisan jednom od više familija proizvoda – sistem treba da bude nezavisan od načina • kreiranja proizvoda • predstavljanja proizvoda – potrebno je forsirati da proizvodi iz familije budu korišćeni zajedno – potrebno je ponuditi klasnu biblioteku proizvoda otkrivajući samo interfejse, ne implementacije • Struktura: • Učesnici: – ApstraktnaFabrika (klasa FabrikaKomponenata) • deklariše interfejs za operacije koje kreiraju objekte apstraktnih proizvoda – KonkretnaFabrika (klase PMFabrika i MotifFabrika) • implementira operacije koje kreiraju objekte konkretnih proizvoda – ApstraktniProizvodX (klase Prozor i Dugme) • deklariše interfejs za određeni tip objekta proizvoda – KonkretanProizvod (klase PMProzor, PMDugme, MotifProzor, MotifDugme) • implementira interfejs apstraktnog proizvoda • definiše objekat proizvoda koji će biti kreiran pomoću odgovarajuće konkretne fabrike – Klijent (klasa GUIKlijent) • koristi samo interfejse deklarisane pomoću apstraktne fabrike i apstraktnog proizvoda • Saradnja: – apstraktna fabrika odlaže kreiranje proizvoda do njenih potklasa – konkretnih fabrika – normalno treba kreirati samo po jednu instancu konkretne fabrike ApstraktnaFabrika +napraviProizvodA() +napraviProizvodB() KonkretnaFabrika1 +napravi ProizvodA() +napraviProizvodB() KonkretnaFabrika2 +napraviProizvodA() +napraviProizvodB() ApstraktniProizvodA ApstraktniProizvodB KonkretniProizvodA1 KonkretniiProizvodA2 <<instantiate>> KonkretniProizvodB1 KonkretniProizvodB2 <<instantiate>> <<instantiate>> <<instantiate>> Klijent 1
  • 136. Projektni uzorci – Apstraktna fabrika 137 Projektovanje softvera • UML notacija: • Posledice: – Izolacija konkretnih klasa proizvoda • klijent manipuliše proizvodima kroz njihove apstraktne interfejse • klijent ne koristi imena konkretnih klasa proizvoda (čak ni za njihovo stvaranje) – Olakšava izmenu familije proizvoda • klasa konkretne fabrike se pojavljuje samo jednom u aplikaciji – tamo gde se pravi njen objekat • aplikacija može koristiti različite konfiguracije proizvoda menjanjem konkretne fabrike • pošto apstraktna fabrika kreira kompletnu familiju, cela familija se menja odjednom – Unapređuje konzistenciju među proizvodima • aplikacija koristi objekte proizvoda samo iz jedne familije u jednom trenutku – Problem: podrška novoj vrsti proizvoda nije jednostavna • razlog je taj što apstraktna fabrika fiksira skup proizvoda koji se mogu kreirati • podrška novog proizvoda zahteva proširenje apstraktne fabrike i svih potklasa • Povezani uzorci: – Apstraktna fabrika se često implementira sa Proizvodnim metodom ili koristeći Prototip • konkretne fabrike mogu realizovati proizvodne metode (uobičajeno), ali mogu se i paramerizovati prototipskim objektima proizvoda i praviti njihove kolonove – konkretna fabrika je često Unikat – konkretna fabrika predstavlja konkretnu Strategiju kreiranja familije proizvoda FabrikaKomponenata MotifFabrika PMFabrika Prozor Dugme MotifProzor PMProzor GUIKlijent MotifDugme PMDugme Uzorak Apstraktna Fabrika Proizvod ApstraktnaFabrika KonkretnaFabrika KonkretanProizvod Klijent
  • 137. 138 Projektni uzorci – Fasada Elektrotehnički fakultet u Beogradu Fasada • Ime i klasifikacija: – Fasada (engl. Facade) – objektni uzorak strukture • Namena: – pružanje jednistvenog interfejsa podsistema – definisanje interfejsa višeg nivoa da bi se podsistem lakše koristio • Motivacija: – strukturiranje sistema u podsisteme • pojednostavljuje proces projektvanja (i održavanja) – cilj je da se međuzavisnosti podsistema svedu na minimum – uvođenje objekta “fasada” ide u pravcu ovog cilja • fasada nudi uprošćeni interfejs za opšte upotrebe podsistema – fasada ne brani direktan pristup klasama unutar podsistema – primer: podsistem prevodioca: • klase: Scanner, Parser, ProgramNode, BytecodeStream, … • klasa Compiler ostvaruje opštenamenski interfejs podsistemu − ona predstavlja fasadu podsistema prevodioca − ona većini klijenata pruža dovoljan servis (kompletno prevođenje) - olakšava se posao većini programera − ona ne skriva ostale klase koje pružaju servise nižeg nivoa ne sprečava se pristup pojedinim klasama unutar podsistema pristup drugim klasama potreban je samo specijalnim aplikacijama • Primenljivost: uzorak treba koristiti kada – potrebno je dati jednostavan interfejs složenom podsistemu • složenost podsistema raste tokom razvoja • primena uzoraka pospešuje porast broja manjih klasa • podsistem postaje teži za upotrebu klijentima • većini klijenata je dovoljan interfejs podsistemu preko fasade – postoje brojne zavisnosti između klijenata i klasa podsistema • fasada razdvaja podsistem od klijenata i drugih podsistema – postoji potreba da se rasloje podsistemi • fasada se može koristiti za ulaznu tačku svakog nivoa podsistema Stream Scanner Token Parser Symbol ProgramNodeBuilder ProgramNode StatementNode ExpressionNode VariableNode Prevodilac +compile() BytecodeStream CodeGenerator StackMachineCodeGenerator RISCCodeGenerator klase podsistema prevodioca <<instantiate>> <<instantiate>> <<instantiate>> <<instantiate>> <<instantiate>> <<instantiate>>
  • 138. Projektni uzorci – Fasada 139 Projektovanje softvera • Struktura: Podsistem Fasada • Učesnici: – Fasada (klasa Compiler) • zna koje klase podsistema su odgovorne za koji zahtev • delegira zahteve klijenata odgovarajućim objektima podsistema – klase podsistema • implementiraju funkcionalnosti izvršavaju zahteve fasade • ne znaju ništa o fasadi • Saradnja: – klijenti šalju zahteve fasadi – fasada prosleđuje zahteve objektima podistema • Posledice: – smanjivanje broja objekata od kojih klijenti zavise • olakšava korišćenje podsistema – slabo vezivanje između podistema i klijenata • variranje komponenata podsistema bez uticaja na klijenta • smanjivanje potrebe ponovnog prevođenja klijenta kada se promeni nešto u podsistemu • povećavanje portabilnosti (pod)sistema − izmene u podsistemu zbog prenosa ne utiču na druge podsisteme – uzorak ne sprečava korišćenje ostalih klasa podsistema • UML notacija: • Povezani uzorci: – Apstraktna fabrika se koristi uz Fasadu kao interfejs za kreiranje objekata podsistema – potreban je samo jedan objekat Fasade, pa se relizuje kao Singleton – Posrednik je sličan Fasadi samo što on apstrahuje proizvoljne komunikacije između objekata (podsistema), a Fasada apstrahuje interfejs podsistema • objekat Posrednik može da dodaje funkcionalnost • objekti podsistema znaju za objekat Posrednik • objekti podsistema ne znaju za objekat Fasada ImplementacijaPrevodiocaFasada Podsistem Prevodilac Uzorak Fasada
  • 139. 140 Projektni uzorci – Posrednik Elektrotehnički fakultet u Beogradu Posrednik • Ime i klasifikacija: – Posrednik (engl. Mediator) – objektni uzorak ponašanja • Namena: – definiše objekat koji kapsulira interakciju skupa objekata – omogućava slabo sprezanje skupa objekata • uklanja potrebu uzajamnog referisanja • omogućava da im se interakcija menja nezavisno • Motivacija: – OO projektovanje podstiče distribuciju odgovornosti među objektima • posledica je da raste broj objekata koji se lakše održavaju • međutim, raste i broj veza među objektima – što otežava održavanje • ako postoji mnogo zavisnosti među objektima – sistem deluje kao monolitan − da bi se promenilo ponašanje sistema mora da se menja više klasa – primer: implementacija dijaloga u GUI (dugmad, polja za unos, liste,...) • međuzavisnost komponenti (npr. onemogućeno dugme dok je polje prazno) – rešenje: posrednik (medijator) • kapsulira ponašanje skupa objekata • odgovoran za kontrolu i koordinaciju interakcije između objekata • objekti se ne poznaju uzajamno – poznaju samo objekat posrednika • smanjuje se broj veza • Motivacija (nastavak): • kada se selektuje stavka u listi potrebno je upisati je u tekst-polje • brigu preuzima sam dijalog na kojem su lista i tekst-polje klijent upravljacFontDijaloga lista dugme tekstPolje • klasni dijagram upravljacFontDijalogaklijent lista tekstPolje prikaziDijalog() promenjena() dohvatiSelekciju() postaviTekst()
  • 140. Projektni uzorci – Posrednik 141 Projektovanje softvera • Primenljivost: – kada skup objekata komunicira na dobro definisan ali složen način; • međuzavisnosti nisu strukturirane i teško se shvataju – kada je reupotreba objekata teška zato što referišu i komuniciraju sa mnogim drugim objektima – kada treba omogućiti prilagođavanje ponašanja distribuiranog na više klasa, a da se izbegne mnogo potklasa • Struktura: Posrednik Kolega KonkretanPosrednik KonkretanKolega1 KonkretanKolega2 +posrednik 1 * 1 1 • Učesnici: – Posrednik (klasa UpravljacDijaloga) • definiše interfejs za komunikaciju sa objektima kolega – KonkretanPosrednik (klasa UpravljacFontDijalog) • implementira spregnuto ponašanje koordiniranjem objekata kolega • poznaje i održava kolege – Kolega (klasa Komponenta) • interfejs za konkretne kolege • poznaje samo klasu Posrednik – KonkretanKolegaX (klase Lista i TekstPolje) • nasleđuje poznavanje klase Posrednik • Saradnja: – kolege šalju i primaju zahteve od objekta posrednika – Posrednik implementira kooperativno ponašanje rutirajući zahteve između odgovarajućih kolega UpravljacDijaloga +prikaziDijalog() +kreirajKomponente() +promenjenaKomponenta(: Komponenta) Komponenta +promenjena() upravljac->promenjenaKomponenta(this) UpravljacFontDijaloga +kreirajKomponente() +promenjenaKomponenta() Lista TekstPolje -upravljac 1 * -lista 1 -tekstPolje 1
  • 141. 142 Projektni uzorci – Posrednik Elektrotehnički fakultet u Beogradu • UML notacija: • Povezani uzorci: – Fasada ima sličnosti sa Posrednikom (jedna klasa prema podsistemu) ali se razlikuje od uzorka Posrednik, jer ona: • apstrahuje podsistem objekata da obezbedi pogodniji interfejs • pri tome koristi jednosmeran protokol − samo se objekat fasade obraća objektima podsistema • posrednik koristi dvosmerni protokol u komunikaciji sa kolegama – Kolege mogu da komuniciraju sa posrednikom korišćenjem Posmatrača UpravljacDijaloga Komponenta Lista UpravljacFontDijaloga Uzorak PosrednikPosrednik KonkretanPosrednik Kolega KonkretanKolega
  • 142. Projektni uzorci – Zastupnik 143 Projektovanje softvera Zastupnik • Ime i klasifikacija: – Zastupnik (engl. Proxy) - objektni uzorak strukture • Namena: – realizuje zamenu (surogat) drugog objekta koji: • kontroliše pristup originalnom objektu • odlaže punu cene kreiranja i inicijalizacije originala do trenutka kada je ovaj zaista potreban • Drugo ime: – Predstavnik, Zamena, Surogat (engl. Surogate) • Motivacija: – problem: editor dokumenata koji mogu da sadrže grafičke objekte u sebi • neki grafički objekti kakve su velike rasterske slike su skupi za kreiranje • sa druge strane, otvaranje dokumenta treba da bude brzo • pri otvaranju dokumenta treba izbeći kreiranje svih slika koje dokument sadrži • sliku treba otvarati tek kad postaje vidljiva (stvarno potrebna), na zahtev • činjenicu da se slika kreira tek na zahtev sakrivamo, da se ne bi komplikovao editor • ova optimizacija ne treba da utiče npr. na kod za prikazivanje ili formatiranje dokumenta – rešenje: • u dokument stavljamo umesto realne slike poseban proksi-objekat koji je zamenjuje • proksi se ponaša kao slika i vodi brigu o stvaranju objekta slike kad je baš on potreban • u slučaju da su slike u posebnim fajlovima, proksi čuva ime fajla kao referencu na sliku • proksi slike takođe čuva dimenzije slike • svest o dimenzijama čini da proksi daje taj podatak formateru i bez učitavanja slike • proksi slike stvara objekat slike tek kada editor od njega zahteva da se slika prikaže • naredne zahteve proksi prosleđuje slici, t.j. proksi čuva referencu na objekat slike – EditorDokumenata pristupa ugrađenim slikama kroz interfejs apstraktne klase GrafickiObjekat – ZastupnikSlike je klasa za slike koje se kreiraju na zahtev • ona održava ime fajla kao referencu na sliku koja je na disku • ime fajla se prosleđuje kao argument konstruktora • ona čuva i dimenzije slike i referencu na objekat stvarne slike • referenca na objekat stvarne slike nije valjana dok se objekat slike ne kreira • operacija crtaj() proverava da li je objekat slike kreiran pre nego što mu prosledi zahtev EditorDokumenata GrafickiObjekat +crtaj() +dimenzije() +ucitaj() +sacuvaj() Slika -implementacijaSlike -visina -sirina +crtaj() +dimenzije() +ucitaj() +sacuvaj() ZastupnikSlike -imeFajla -visina -sirina +crtaj() +dimenzije() +ucitaj() +sacuvaj() 1 * -slika 11 <<instantiate>> crtaj(){ if (slika==null) slika=ucitaj(imeFajla); slika.crtaj(); } dimenzije(){ if (slika==null) return Dimenzije(visina, sirina); else return slika.dimenzije(); }
  • 143. 144 Projektni uzorci – Zastupnik Elektrotehnički fakultet u Beogradu • operacija dimenzije() prosleđuje zahtev objektu slike, ako je ovaj postoji • ako slika nije kreirana dimenzije() vraća sačuvane dimenzije slike • Primenljivost: – uzorak je primenljiv kada postoji potreba za sofističnom referencom na objekat • Vrste zastupnika prema primeni: – udaljeni zastupnik (remote proxy) • obezbeđuje lokalnog predstavnika objekta koji se nalazi u drugom adresnom prostoru • Colpien ovu vrstu zastupnika naziva "ambasadorom" – virtuelni zastupnik (virtual proxy) • kreira relativno skup objekat na zahtev (ZastupnikSlike je primer) – zaštitni zastupnik (protection proxy) • kontroliše pravo pristupa originalnom objektu – pametni pokazivač (smart reference) • zamena za obični pokazivač, obavlja dodatne akcije prilikom pristupa • tipične primene: − brojanje referenci na objekat, da bi se ovaj dealocirao automatski kad je broj 0 − punjenje perzistentnog objekta u memoriju pri prvom referisanju − provera da li je objekat zaključan, t.j. da ga neko drugi tada ne menja • Struktura: • Učesnici: – Subjekat (klasa GrafickiObjekat) • zajednički interfejs za Original i Zastupnik, da se Zastupnik može koristiti kao Original – Zastupnik (klasa ZastupnikSlike) • čuva referencu za pristup originalu • realizuje interfejs subjekta tako da može predstavljati zamenu za original • kontroliše pristup originalu, može biti odgovoran za njegovo kreiranje/uništavanje • u zavisnosti od tipa zastupnika: − Udaljeni je odgovoran za slanje zahteva i argumenata u drugi adresni prostor − Virtuelni može keširati dodatne informacije o originalu da odloži pristup − Zaštitni proverava da li pozivalac ima pristupnu dozvolu za dati zahtev – Original (klasa Slika) • realni subjekat koji je reprezentovan zastupnikom Klijent Subjekat +zahtev() Original +zahtev() Zastupnik +zahtev()-original 1 1 -sub zahtev(){ if (! potrebanOriginal) {... } else{ if (original == null) original=new Original(); original.zahtev() } }
  • 144. Projektni uzorci – Zastupnik 145 Projektovanje softvera • Posledice: – uzorak Zastupnik uvodi jedan nivo indirekcije u pristupu objektu – optimizacija koju zastupnik može da sakrije od klijenta je copy-on-write • kopiranje velikih i komplikovanih objekata može biti skupa operacija • ako se kopija nikad ne modifikuje, nije neophodno platiti cenu • korišćenjem zastupnika da odloži kopiranje, cena se plaća samo ako se objekat modifikuje • zahtev za kopiranje rezultuje samo u inkrementiranju broja referenci na subjekat • kada klijent zahteva operaciju koja modifikuje original, tada zastupnik − stvarno kopira original − dekrementira broj referenci na original • kada broj referenci padne na 0 – original se uništava • UML notacija: • Povezani uzorci: – Adapter obezbeđuje različit interfejs objektu koji adaptira, dok Zastupnik obezbeđuje isti interfejs, kao i Dekorater – Dekorater – može imati sličnu implementaciju kao Zastupnik, ali ima različitu namenu: • Dekorater dodaje jednu ili više odgovornosti objektu, a Zastupnik kontroliše pristup objektu • Zaštitni zastupnik može biti implementiran baš kao Dekorater EditorDokumenata GrafickiObjekat Slika ZastupnikSlikeUzorak Zastupnik Klijent Zastupnik OriginalSubjekat
  • 145. 146 Projektni uzorci – Most Elektrotehnički fakultet u Beogradu Most • Ime i klasifikacija: – Most (eng. Bridge) – objektni uzorak strukture • Namena: – razdvaja apstrakciju od njene implementacije da bi se mogle nezavisno menjati • Drugo ime: – Ručka/Telo (Handle/Body) • Motivacija: – problem: postoji više implementacija za jednu apstrakciju – tradicionalno OO rešenje: apstraktna klasa i izvedene klase • rešenje nije dovoljno fleksibilno – nasleđivanje čvrsto vezuje implementaciju za apstrakciju • teško se nezavisno menjaju, proširuju i ponovo koriste – primer: apstrakcija Prozor u alatima za GUI • potrebno pisati aplikacije za razne prozorske sisteme − npr. X Window System i IBM Presentation Manager • tradicionalno rešenje: Prozor XWProzor PMProzor – problem (1): uvodi se nova apstrakcija - prozor za dijalog Dijalog • da bi se apstrakcija implementirala na obe platforme dobija se: Prozor XWProzor PMProzor Dijalog XWDijalog PMDijalog • za svaku novu vrstu prozora – moraju se definisati po dve klase • podrška za novu platformu – po jedna klasa za svaku vrstu prozora – problem (2): klijentski kod postaje zavisan od platforme • kad god klijent pravi prozor – pravi primerak konkretne klase sa specifičnom implementacijom za datu platformu • otežano prenošenje klijentskog koda na druge platforme • klijenti ne bi trebalo da se vezuju za konkretne implementacije − oni treba da vode računa samo o različitim apstrakcijama prozora − samo bi implementacija prozora smela da zavisi od platforme – rešenje problema: uzorak Most • apstrakcija prozora i njegova implementacija su dva odvojena korena odgovarajućih hijerarhija klasa • uspostavlja se most između apstrakcije i implementacije tako da se one mogu nezavisno menjati
  • 146. Projektni uzorci – Most 147 Projektovanje softvera – sve operacije klase Prozor se implementiraju primenom apstraktnih operacija klase ProzorImp • Primenljivost: uzorak treba koristiti kada – treba izbeći trajno vezivanje apstrakcije i njene implementacije • npr., ako je potrebno implementaciju menjati u vreme izvršenja – i apstrakciji i implementaciji je potrebno proširivanje kroz potklase • most omogućava kombinovanje različitih apstrakcija i implementacija – promena u implementaciji apstrakcije ne sme da utiče na klijente – u jeziku C++: potpuno sakrivanje implementacije klase od klijenta • definicije klasa su u h fajlovima – delimično se otkriva implementacija – postoji opasnost od prevelikog broja klasa • npr. u primeru se vidi kvadratni rast (broj sistema x broj tipova prozora) – kada se želi da istu implementaciju deli više objekata a da to bude sakriveno od klijenta (eventualno uz brojanje referenci) • Struktura: Apstrakcija +operacija() imp.operacijaImp(); Implementacija +operacijaImp() -imp 1 1 FinijaApstrakcija KonkretnaImpA +operacijaImp() KonkretnaImpB +operacijaImp() Klijent Prozor +crtajTekst() +crtajPrvougaonik() ProzorImp +crtajTekst() +crtajLiniju() Dijalog +crtajOkvir() GlavniProzor +crtajTrakuMenija() XWProzorImp +crtajTekst() +crtajLiniju() PMProzorImp +crtajTekst() +crtajLiniju() crtajPravougaonik(){ imp.crtajLiniju(); imp.crtajLiniju(); imp.crtajLiniju(); imp.ctajLiniju(); } crtajPravougaonik(); crtajPravougaonik(); crtajTekst(){ xCrtajTekst(); } crtajLiniju(){ xCrtajLiniju(); } crtajTekst(){ imp.crtajTekst(); } most -imp 1 1
  • 147. 148 Projektni uzorci – Most Elektrotehnički fakultet u Beogradu • Učesnici: – Apstrakcija (klasa Prozor) • definiše interfejs apstrakcije • održava referencu na objekat implementacije – FinijaApstrakcija (klasa Dijalog) • proširuje interfejs apstrakcije – Implementacija (klasa ProzorImp) • definiše interfejs klasa implement. − interfejs ne mora da liči na interfejs apstrakcije – KonkretnaImpX (klase XWProzorImp, PMProzorImp) • implementira interfejs implement. • definiše konkretnu implementaciju • Saradnja: – Apstrakcija prosleđuje klijentske zahteve objektu Implementacija • Posledice: – razdvajanje interfejsa od implementacije • implementacija nije trajno vezana za apstrakciju, može da se konfiguriše dinamički • eliminisane su zavisnosti apstrakcije od implementacije u vreme prevođenja − prevođenje klasa implementacije ne zahteva prevođenje klasa apstrakcije − bitno kada se mora obezbediti kompatibilnost verzija biblioteke klasa – bolje mogućnosti proširivanja • hijerarhije apstrakcija i implementacija se mogu nezavisno proširivati – skrivanje detalja implementacije od klijenta • klijent ne vidi niša od implementacije, vidi samo apstrakciju • UML notacija: • Povezani uzorci: – Apstraktna fabrika može da kreira i konfiguriše Most – Adapter i Most prilagođavaju klijentu interfejs neke implementacije • Adapter se obično projektuje retroaktivno • Most se obično projektuje unapred Prozor XWProzorDijalog ProzorImpMost Apstrakcija FinijaApstrakcija KonkretnaImp Implementacija
  • 148. Projektni uzorci – Komanda 149 Projektovanje softvera Komanda • Ime i klasifikacija: – Komanda (engl. Command) – objektni uzorak ponašanja • Namena: – kapsulira zahtev u jedan objekat, omogućavajući: • da se klijenti parametrizuju različitim zahtevima, • da se zahtevi isporučuju kroz red čekanja, • da se pravi dnevnik (log) zahteva i • da se efekti izvršenog zahteva ponište (undo) • Drugo ime: – Akcija, Transakcija (engl. Action, Transaction) • Motivacija: – nekad je potrebno izdati zahtev da se izvrši neka operacija bez znanja o samoj zahtevanoj operaciji i izvršiocu (primaocu zahteva) – npr. GUI biblioteke sadrže objekte kao što su dugmad ili meniji • ovi objekti izvršavaju zahteve koji su posledica akcije korisnika • biblioteka klasa ne može da realizuje adekvatne operacije u ovim objektima • samo ciljna aplikacija zna šta je specifična operacija za neko dugme • projektant biblioteke ne zna ništa o operaciji ni o primaocu zahteva – uzorak Komanda: • dopušta objektima biblioteke da zahtevaju da nepoznate operacije budu izvršene od nepoznatih objekata aplikacije • to postiže smeštajući zahteve za operacijama u posebne objekte – objekat sa zahtevom se može zapamtiti ili proslediti drugom objektu – ključna apstrakcija uzorka je klasa Komanda • deklariše interfejs za izvršenje operacija • u najjednostavnijoj formi, interfejs se sastoji od apstraktne operacije izvrsi() – potklase klase Komanda specificiraju par (primalac komande, operacija) • primalac zna kako da izvrši akcije koje su potrebne za ispunjenje zahteva – meniji se lako mogu implementirati koristeći objekte potklasa klase Komanda Aplikacija +dodajDok() +tekuciDok() MeniStavka +aktivacija() Dokument +otvori() +zatvori() +kopiraj() Komanda +izvrsi() KomandaOtvori +izvrsi() +pitajIme() KomandaKopiraj +izvrsi() -komanda 1 1 Meni 1 * -dokumenti * izvrsi(){ ime=pitajIme(); dok=new Dokument(ime); aplikacija.dodajDok(dok); dok.otvori(); } -aplikacija izvrsi(){ dok=aplikacija.tekuciDok(); dok.kopiraj(); } -aplikacija
  • 149. 150 Projektni uzorci – Komanda Elektrotehnički fakultet u Beogradu – uzorak raspreže objekat pozivaoca operacije od onog ko zna kako da je izvrši • objekat koji izdaje komandu treba da zna samo kako se ona izdaje • on ne treba da zna ništa o tome kako se izvršava i ko je izvršava – komande se mogu menjati dinamički • u konkretnom primeru menija, ovo omogućava kontekstno zavisne menije – jednostavna je implementacija skriptova (složenih komandi - sekvenci operacija) • Primenljivost: – kada treba parametrizovati objekte akcijom koju treba da obave • zamena za funkciju povratnog poziva (callback) u tradicionalnim jezicima – kada treba specificirati, stavljaiti u red čekanja i izvršavati zahteve u različitim trenucima • objekat komande može imati različit životni vek od onog ko izdaje zahtev • objekat komande se može prepustiti drugom procesu (promena adresnog prostora), ako se primalac može adresirati univerzalno – kada treba podržati undo • izvrsi() operacija može sačuvati u samom objektu stanje za rastauraciju • interfejs treba da sadrži i ponisti() operaciju koja restaurira stanje • neograničen nivo undo i redo se postiže smeštanjem objekata izvršenih komandi u listu, odnosno prolaskom kroz listu unazad i unapred – kada treba podržati recovery • potrebno je snimati promene da bi se one mogle ponovo uraditi • u interfejs klase Komanda se dodaju operacije za perzistenciju dnevnika promena • oporavak se postiže učitavanjem dnevnika sa diska i ponovnim izvršavanjem izvrsi() – kada treba podržati transakcije • transakcije su složene operacije sastavljene od primitivnih • transakcije kapsuliraju skup promena podataka • Struktura: Klijent Komanda +izvrsi() Primalac +akcija() Pokretac KonkretnaKomanda -stanje +izvrsi() -komanda <<instantiate>> -izvrsilac -komanda izvrsi(){ izvrsilac.akcija(); }
  • 150. Projektni uzorci – Komanda 151 Projektovanje softvera • Učesnici: – Komanda (klasa Komanda) • deklariše interfejs za izvršenje neke operacije – KonkretnaKomanda (klase KomandaOtvori, KomandaKopiraj) • definiše vezu između jednog objekta Primalac i akcije – Kijent (klasa Aplikacija) • kreira objekat KonkretnaKomanda i postavlja njen objekat Primalac – Pokretac (klasa MeniStavka) • traži od komande da izvrši zahtev – Primalac (klasa Dokument) • zna kako da izvrši operacije pridružene ispunjavanju zahteva • Saradnja: • UML notacija: • Posledice: – raspreže objekat koji pokreće operaciju od onog koji zna kako da je izvrši – komande su objekti kao i svi drugi i njima se može manipulisati – komande se mogu asemblirati u kompozitne komande (makrokomande) – jednostavno je dodavanje novih komandi, ne treba menjati postojeće klase • Povezani uzorci: – Kompozicija se koristi za kreiranje makrokomandi (skriptova) – Podsetnik može da čuva stanje pre izvršenja komande potrebno za Undo – komanda čija se kopija stavlja u listu istorije se ponaša kao Prototip : Primalac: Pokretac : Klijent : KonkretnaKomanda <<create>> sacuvaj() izvrsi() akcija() Aplikacija MeniStavka Dokument Komanda KomandaOtvori KomandaKopiraj Klijent Pokretac Primalac Komanda KonkretnaKomanda Uzorak Komanda
  • 151. 152 Projektni uzorci – Lanac odgovornosti Elektrotehnički fakultet u Beogradu Lanac odgovornosti • Ime i klasifikacija: – Lanac odgovornosti (engl. Chain of Responsibility) - objektni uzorak ponašanja • Namena: – povezuje objekte primaoce zahteva u lanac i prosleđuje zahtev niz lanac, dok ga neki objekat ne obradi – izbegava neposredno vezivanje pošiljaoca zahteva sa primaocem, dajući šansu većem broju objekata da obrade zahtev • Motivacija: – sistem pomoći zavisne od konteksta u grafičkom korisničkom interfejsu • svaka komponenta treba da pruža pomoć na komandu preko miša • ako za konkretnu komponentu ne postoji pomoć, treba da se prikaže pomoć za dijalog koji sadrži komponentu • ako ni za dijalog ne postoji pomoć – treba da se prikaže pomoć za program – informacije pomoći se organizuju prema opštosti • od specifičnijih (u komponentama) prema opštijim (dijalog, aplikacija) – zahtev za pomoć treba da obrađuje nekoliko objekata • od specifičnijih ka opštijim, dok neko ne obradi u celini – problem: • objekat koji pruža pomoć nije unapred poznat onome ko zahteva pomoć • potrebno je razdvojiti onoga ko inicira zahtev za pomoć (dugme) od objekta koji će na kraju da prikaže pomoć – rešenje: • lanac odgovornosti: zahtev se predaje duž lanca dok ga neko ne obradi dugmeOdustajem dugmeStampaj dijalogStampaj dijalogSacuvaj aplikacija – da bi se obezbedilo prosleđivanje kroz lanac a da primaoci ostanu implicitni, svi objekti u lancu moraju imati isti interfejs dugmeStampaj : Dugme dijalogStampaj : Dijalog aplikacija : Aplikacija pruziPomoc() pruziPomoc() prikaziPomoc()
  • 152. Projektni uzorci – Lanac odgovornosti 153 Projektovanje softvera • Primenljivost: – kada više objekata može da obradi zahtev, ali se ne zna unapred koji će obraditi – kad se hoće izdati zahtev jednom od nekoliko objekata, a da se ne odredi eksplicitno primalac – kada skup objekata koji obrađuju zahtev treba da se odredi dinamički • Struktura: klijent obradjivac1 obradjivac2-obradjivac -sledeci • Učesnici: – Obradjivac (klasa DavalacPomoci) • definiše interfejs obrade zahteva • implementira vezu prema sledećem u lancu − opciono, svi osim poslednjeg – KonkretanObradjivacX (klase Dugme, Dijalog) • obrađuje zahteve koje ume • može da pristupi naslednicima u lancu • ako može da obradi zahtev – to i čini, u suprotnom ga prosleđuje nasledniku Klijent Obradjivac +obradaZahteva() KonkretanObradjivac1 +obradaZahteva() KonkretanObradjivac2 +obradaZahteva() -obradjivac obradaZahteva(){ sledeci->obradaZahteva() } -sledeci DavalacPomoci +pruziPomoc() KomponentaAplikacija DijalogDugme +pruziPomoc() -prikaziPomoc() -roditelj pruziPomoc(){ roditelj->pruziPomoc() } pruziPomoc(){ if (moze) { prikaziPomoc() } else roditelj -> Pomoc::pruziPomoc() }
  • 153. 154 Projektni uzorci – Lanac odgovornosti Elektrotehnički fakultet u Beogradu • Saradnja: – kada klijent izda zahtev on putuje po lancu odgovornosti dok konkretni obrađivač ne preuzme odgovornost za obradu • Posledice: – rasprezanje pošiljaoca i primaoca • pošiljalac i primalac ne treba da znaju ništa jedan o drugom • objekat u lancu ne treba da poznaje strukturu lanca • smanjuje se broj veza među objektima − objekat ne mora pristupati svima, dovoljno je sledbeniku – dodatna fleksibilnost u pridruživanju odgovornosti objektima • odgovornosti za obradu zahteva se mogu dodavati i menjati u vreme izvršenja – prijem nije garantovan • moguća je situacija da zahtev stigne do kraja lanca, a da nije obrađen • UML notacija: • Povezani uzorci: – često se primenjuje sa uzorkom Kompozicija; roditelj komponente može da igra ulogu “sledećeg” u lancu Dugme DavalacPomoci Obradjivac KonkretanObradjivac1 Aplikacija KonkretanObradjivac2 KlijentLanac odgovornosti Klijent
  • 154. Projektni uzorci – Graditelj 155 Projektovanje softvera Graditelj • Ime i klasifikacija: – Graditelj (engl. Builder) – objektni uzorak kreiranja • Namena: – razdvaja proces konstrukcije kompleksnog objekta od njegove reprezentacije – posledica je da isti proces konstrukcije može da kreira različite reprezentacije • Motivacija: – posmatra se aplikacja za čitanje RTF dokumenata (čitač) – potrebno je da učitane dokumente može da konvertuje u: • čisti ASCII tekst • TeX dokument • tekstualnu komponentu koja može da se interaktivno edituje • ... (broj mogućih konverzija je neograničen) – potrebno je da se lako dodaje nova konverzija, bez izmene čitača – rešenje je primena uzorka Graditelj: • konfigurisanje RTFCitac klase objektom TekstKonvertor • RTFCitac čita RTF tekst i parsira ga • TekstKonvertor konvertuje RTF u drugu tekstualnu reprezentaciju • kad RTFCitac prepozna RTF element − on izdaje zahtev TekstKonvertor objektu • TekstKonvertor konvertuje i reprezentuje element u ciljnom formatu • potklase TekstKonvertor specijalizuju korake u konverziji – svaka vrsta konvertora, iza apstraktnog interfejsa, ima mehanizam za kreiranje i sastavljanje složenog objekta – konvertor je razdvojen od čitača • čitač je odgovoran samo za parsiranje ulaznog RTF dokumenta – svaka klasa konvertora u uzorku se naziva graditeljem (builder) – klasa čitača se naziva upravljačem (director) – u ovom primeru uzorak graditelja je razdvojio • algoritam interpretacije tekstualnog formata (parser za RTF dokumente) • način kako se konvertovani format stvara i reprezentuje – posledica je reupotreba algoritma parsiranja pri kreiranju različitih tekstualnih reprezentacija od RTF dokumenata parsirajRTF(){ while (t=sledeciToken()){ switch t.tip { ZNAK: graditelj.konvertujZnak(t); FONT: graditelj.konvertujPromenuFonta(t); PARAGRAF: graditelj.konvertujParagraf(t); } } } Podrazumevane (prazne) implementacije TekstKonvertor +konvertujZnak() +konvertujPromenuFonta() +konvertujParagraf() ASCIIKonvertor +konvertujZnak() +dohvatiASCIITekst() TeXKonvertor +konvertujZnak() +konvertujPromenuFonta() +konvertujParagraf() +dohvatiTeXTekst() KonvertorKomponente +konvertujZnak() +konvertujPromenuFonta() +konvertujParagraf() +dohvatiTekstKomponente() RTFCitac +parsirajRTF() TekstKomponenta <<instantiate>> ASCIITekst TeXTekst <<instantiate>> <<instantiate>> -graditelj
  • 155. 156 Projektni uzorci – Graditelj Elektrotehnički fakultet u Beogradu • RTFCitac se samo konfiguriše objektom neke od potklasa TekstKonvertor • Primenljivost: uzorak treba koristiti kada – algoritam za kreiranje složenog objekta treba da bude nezavisan • od delova koji čine objekat • od načina na koji se delovi sklapaju u celinu – proces konstrukcije mora da dopusti različite reprezentacije za objekat koji se konstruiše • Struktura: • Učesnici: – Graditelj (klasa TekstKonvertor) • specificira apstraktan interfejs za kreiranje delova objekta Proizvod – KonkretanGraditelj (klase ASCIIKonvertor, TeXKonvertor) • konstruiše i sastavlja delove proizvoda implementiranjem interfejsa Graditelj • definiše i čuva proizvod koji kreira • obezbeđuje interfejs za dohvatanje proizvoda – Upravljac (klasa RTFCitac) • konstruiše objekat koristeći interfejs Graditelj – Proizvod (klase ASCIITekst, TeXTekst) • predstavlja složeni objekat koji se konstruiše • uključuje klase koje definišu sastavne delove − uključujući interfejse za sastavljanje delova u finalan rezultat Upravljac +konstruisi() Graditelj +izgradiDeoA() +izgradiDeoB() +izgradiDeoC() KonkretanGraditelj +izgradiDeoA() +izgradiDeoB() +izgradiDeoC() +dajRezultat() -graditelj Proizvod <<instantiate>> graditelj->izgradiDeoA(); graditelj->izgradiDeoB(); graditelj->izgradiDeoC();
  • 156. Projektni uzorci – Graditelj 157 Projektovanje softvera • Saradnja: • Posledice: – dopušta izmene interne reprezentacije i načina sklapanja složenog proizvoda • graditelj pruža upravljaču apstraktan interfejs za konstrukciju proizvoda • reprezentacija i interna struktura, kao i način sklapanja su sakriveni • za promenu interne reprezentacije potrebna je samo nova vrsta graditelja – izolovanje koda za konstrukciju i reprezentaciju • bolja modularnost kroz kapsuliranje načina konstrukcije složenog objekta • klijenti ne treba da znaju ništa o klasama koje definišu unutrašnju strukturu proizvoda − te klase se ne pojavljuju u interfejsu graditelja – daje finiju kontrolu nad procesom konstrukcije od drugih fabrika • drugi uzorci kreiranja konstruišu proizvod u jednom potezu • graditelj konstruiše proizvod korak-po-korak, pod kontrolom upravljača • UML notacija: • Povezani uzorci: – Druge fabrike (npr. Apstraktna fabrika) takođe mogu da konstruiše kompleksne objekte • Graditelj vrši konstrukciju kompleksnog objekta korak-po-korak, druge fabrike u jednom koraku • Graditelj vraća proizvod kao finalni korak, druge fabrike vraćaju proizvod odmah – Graditelj često gradi objekat Kompozicije – Upravljac uzorka Graditelja se parametrizuje objektom klase Graditelj, kao što se Kontekst parametrizuje objektom Strategija u odgovarajućem uzorku • osim u nameni, razlika je što se Strategija najčešće implementira u jednoj metodi dok su kod Graditelja implementirani pojedini koraci gradnje kao posebne metode – Šablonska metoda poziva apstraktne metode sopstvene klase, dok kod uzorka Graditelj, Upravljac sadrži konkretnu metodu koja poziva apstraktne metode klase Graditelj klijent upravljac konkretanGraditelj <<create>> <<create>> konstruisi() izgradiDeoA() izgradiDeoB() izgradiDeoC() dajRezultat() Upravljac Graditelj KonkretanGraditelj RTFCitac TekstKonvertor TeXKonvertor TeXTekstUzorak Graditelj Proizvod
  • 157. 158 Projektni uzorci – Posetilac Elektrotehnički fakultet u Beogradu Posetilac • Ime i klasifikacija: – Posetilac (engl. Visitor) – objektni uzorak ponašanja • Namena: – skup različitih operacija koje treba primenjivati na elemente jedne objektne strukture – omogućava definisanje nove operacije bez izmene klasa elemenata nad kojima se izvršava • Motivacija: – razmatra se prevodilac koji reprezentuje programe kao stabla apstraktne sintakse (SAS) – potrebno je obezbediti operacije nad SAS za: • statičku proveru tipova • generisanje koda • … – većina operacija će na različit način tretirati čvorove SAS za: • naredbu dodele vrednosti • referisanje promenljive • … – hijerarhija čvorova SAS zavisi od jezika, ali je za dati jezik stabilna – nefleksibilan dizajn: OperacijaZaCvor +proveraTipa() +generisanjeKoda() OpZaCvorReference +proveraTipa() +generisanjeKoda() OpZaCvorDodele +proveraTipa() +generisanjeKoda() – problem: prisustvo svih operacija u različitim klasama čvorova vodi do sistema koji je teško razumeti, održavati i menjati • mešanje koda za proveru tipova i koda za generisanje koda kvari razumljivost • dodavanje nove operacije zahteva ponovno prevođenje svih klasa čvorova – cilj: razdvajanje hijerarhije čvorova od operacija koje se vrše nad njima – rešenje: pakovanje operacija u objekte posetilaca koji se prosleđuju čvorovima SAS kada se struktura obilazi – posetilac kapsulira jednu operaciju za različite čvorove SAS – kada čvor primi posetioca – on šalje zahtev posetiocu koji odgovara klasi čvora i kao parametar dostavlja referencu na sebe – posetilac tada izvršava operaciju za dotični čvor (koja je ranije bila u okviru samog čvora)
  • 158. Projektni uzorci – Posetilac 159 Projektovanje softvera – u uzorku Posetilac se definišu dve hijerarhije klasa • za elemente nad kojima se vrše operacije (h. čvorova) • za posetioce koji definišu operacije nad elementima (h. posetilaca) – nova operacija se dodaje kao nova potklasa u h. posetilaca • ako bi aplikacija trebalo da računa metriku programa samo bi se definisala nova potklasa klase PosetilacCvora a ne bi se dodavao aplikativno zavisan kod u klase čvorova SAS • Primenljivost: uzorak treba koristiti kada – jedna objektna struktura sadrži objekte raznih klasa, a potrebno je nad tim objektima izvršiti operacije koje zavise od njihovih konkretnih klasa – više nepovezanih operacija se izvršava nad objektima strukture, a ne želimo da “zagadimo” njihove klase tim operacijama • posetilac omogućava grupisanje povezanih operacija (koje odgovaraju jednoj primeni) u jednoj klasi – klase koje definišu strukturu objekata se retko menjaju, a često se definišu nove operacije nad elementima strukture • promena klasa objektne strukture zahteva promenu svih posetilaca • može mnogo da košta, pa ako je ovo često, bolje je definisati operacije u tim klasama • Struktura: • Učesnici: – Posetilac (klasa PosetilacCvora) • po jedna operacija poseti() za svaku potklasu Element • potpis operacije identifikuje odgovarajući potklasu Element Posetilac +posetiElementA(ElementA) +posetiElementB(ElementB) ObjektnaStruktura Klijent KonkretanPosetilac1 +posetiElementA(ElementA) +posetiElementB(ElementB) KonretanPosetilac2 +visitElementA(ElementA) +visitElementB(ElementB) Element +prihvati(Posetilac) ElementA +prihvati(Posetilac p) +operacijaA() ElementB +pihvati(Posetilac p) +operacijaB() p->posetiElementA(this) p->posetiElementB(this) * p.posetiDodelu(this) p.posetiReferencu(this) PosetilacCvora +posetiDodelu(CvorDodele) +posetiReferencu(CvorReference) PosetilacProveraTipa +posetiDodelu(CvorDodele) +posetiReferencu(CvorReference) PosetilacGeneratorKoda +posetiDodelu(CvorDodele) +posetiReferencu(CvorReference) Program CvorDodele +prihvati(PosetilacCvora p) CvorReference +prihvati(PosetilacCvora p) Cvor +prihvati(PosetilacCvora) *
  • 159. 160 Projektni uzorci – Posetilac Elektrotehnički fakultet u Beogradu – KonkretanPosetilacX (klase PosetilacProveraTipa,...) • implementira sve operacije koje deklariše Posetilac • predstavlja kontekst algoritma i čuva njegovo stanje koje često akumulira rezultate obilaska strukture objekata • svaka operacija implementira deo algoritma za odgovarajuću klasu objekata u strukturi – Element (klasa Cvor) • deklariše operaciju prihvati() - posetilac je argument – ElementX (klase CvorDodele, CvorReference) • implementira operaciju prihvati() – ObjektnaStruktura (klasa Program) • pruža interfejs visokog nivoa koji omogućava klijentu da obiđe elemente dostavljajući im posetioca • može da bude objekat Sastav (stablo) ili kolekcija (lista) • Saradnja: – Klijent: • stvara objekat konkretnog posetioca • obilazi objektnu strukturu posećujući svaki njen element • svakom elementu prosledi posetioca – Element • poziva operaciju posetioca kojom mu traži da ga poseti : ObjektnaStruktura : ElementA : ElementB p : KonkretanPosetilac1 : Klijent <<create>> sledeciElement() prihvati() posetiElementA() operacijaA() sledeciElement() pihvati() posetiElementB() operacijaB()
  • 160. Projektni uzorci – Posetilac 161 Projektovanje softvera • Posledice: – olakšava dodavanje novih operacija – dodavanje novih klasa konkretnih elemenata nije lako – grupiše srodne i razdvaja različite operacije – mogućnost obilaska objekata iz različitih hijerarhija klasa – mogućnost akumuliranja stanja za vreme posećivanja elemenata • bez posetioca, stanje bi se predavalo operacijama kao dodatni argument – probijanje kapsuliranja elemenata • često su potrebne javne operacije za pristup unutrašnjem stanju elemenata strukture • UML notacija: • Povezani uzorci: – Kompozicija – posetilac može da se koristi da bi se neka operacija primenila na strukturu objekata definisanu kao kompozicija – Iterator se često koristi zajedno sa Posetiocem, • služi za sistematičan obilazak objekata strukture kojima se šalju posetioci – Interpreter – posetilac se može koristiti da obavi interpretaciju Posetilac KonkretanPosetilac ElementX Element ObjektnaStruktura PosetilacCvora PosetilacProveraTipa CvorCvorReference ProgramPosetilac
  • 161. 162 Projektni uzorci - Interpreter Elektrotehnički fakultet u Beogradu Interpreter • Ime i klasifikacija: – Interpreter – klasni uzorak ponašanja • Namena: – za dati jezik, definiše: • reprezentaciju njegove gramatike • interpreter koji koristi tu reprezentaciju da interpretira iskaze jezika • Motivacija: – u nekim aplikacijama: • pojedini zahtevi se mogu predstaviti iskazima jednostavnog jezika • može se napraviti interpreter koji rešava probleme interpretirajući iskaze – primer: problem (zahtev) - traženje stringova koji odgovaraju uzorku • regularni izrazi su standardan jezik za specificiranje uzoraka stringova • algoritam pretrage može da interpretira regularan izraz koji specificira skup stringova za uparivanje – uzorak Interpreter opisuje: • kako definisati gramatiku za jednostavne jezike, • kako predstaviti iskaze u jeziku i • kako interpretirati te iskaze – sledeća gramatika definiše regularne izraze: izraz ::= literal | redjanje | izbor | ponavljanje | '(' izraz ')' redjanje ::= izraz '&' izraz izbor ::= izraz '|' izraz ponavljanje ::= izraz '*' literal ::= 'a' | 'b' | 'c' | ... { 'a' | 'b' | 'c' | ... }* – na primer - zadavanje uzorka za pretragu: projektni & uzorci & (kreiranja | strukture | ponašanja) – uzorak Interpreter koristi po klasu da reprezentuje gramatičko pravilo – simboli na levoj strani pravila određuju klase interpretera – data gramatika se opisuje sa 5 klasa: RegularniIzraz +interpretiraj() Literal -literal +interpretiraj() Redjanje +interpretiraj() Izbor +interpretiraj()Ponavljanje +interpretiraj() -izraz -izraz2 -izraz1 -izraz2 -izraz1 – desna strana pravila određuje sastavljanje objektne strukture – svaki regularan izraz definisan na datoj gramatici se predstavlja pomoću jednog stabla apstraktne sintakse (SAS) sastavljenog od objekata datih klasa – primer:
  • 162. Projektni uzorci – Interpreter 163 Projektovanje softvera • regularni izraz: pada & (kisa | sneg)* • odgovarajuće SAS: redjanje literal 'pada' -izraz1 ponavljanje izbor literal 'kisa' -izraz1 literal 'sneg' -izraz2 -izraz2 – može se napraviti interpreter za ovakve regularne izraze – definiše se interpretiraj()operacija za svaku potklasu RegularniIzraz • interpretiraj() dobija kao argument kontekst u kojem interpretira izraz • kontekst sadrži ulazni tekst i informaciju o tome koji njegov deo je već obrađen • svaka potklasa RegularniIzraz implementira interpretiraj() da upari sledeći deo ulaznog teksta u datom kontekstu • na primer: − Literal proverava da li ulaz odgovara literalu koji definiše − Redjanje proverava da li ulaz odgovara sledu njegovih izraza − Izbor proverava da li ulaz odgovara jednom od njegovih izraza − Ponavljanje proverava da li ulaz ima ponavljanja njegovog izraza • Primenljivost: – uzorak treba primeniti kada • postoji jezik koji treba interpretirati i • iskazi jezika se mogu predstaviti kao stabla apstraktne sintakse – najbolji rezultati se dobijaju pod sledećim uslovima • gramatika je jednostavna − za kompleksne gramatike broj klasa u hijerarhiji postaje preveliki za održavanje • efikasnost nije kritična − najefikasniji interpreteri se obično ne implementiraju interpretiranjem stabala parsiranja direktno, već se najpre ona transformišu u neku drugu formu − na primer – regularni izrazi se često transformišu u automate stanja, ali i tada se translator može implementirati pomoću uzorka Interpreter
  • 163. 164 Projektni uzorci - Interpreter Elektrotehnički fakultet u Beogradu • Struktura: • Učesnici: – ApstraktniIzraz (klasa RegularniIzraz) • deklariše apstraktnu operaciju interpretiraj() koja je zajednička za sve čvorove u SAS – TerminalniIzraz (klasa Literal) • implementira interpretiraj() operaciju za terminalne simbole u gramatici • po primerak se zahteva za svaki terminalni simbol u iskazu – NeterminalniIzraz (klase Redjanje, Izbor, Ponavljanje ) • zahteva se po jedna klasa za svako gramatičko pravilo R::=R1 R2 ... Rn • sadrži objekte tipa ApstraktniIzraz za svaki od simbola R1...Rn • implementira op. interpretiraj() za neterminalne simbole tako što se ova poziva rekurzivno za objekte simbola R1...Rn – Kontekst (klasa Tekst) • sadrži informaciju koja je globalna za interpreter – Klijent • gradi (ili je već dato) SAS koje predstavlja pojedini iskaz na jeziku koji definiše gramatika − SAS je sastavljeno od objekata klasa NeterminalniIzraz i TerminalniIzraz • poziva interpretiraj() operaciju korena SAS • Saradnja: – klijent gradi (ili je već dat) iskaz kao SAS od objekata terminalnih i neterminalnih izraza – zatim klijent inicijalizuje kontekst i pokreće operaciju interpretiraj() – svaki čvor neterminalnog izraza definiše operaciju interpretiraj() tako što poziva operaciju interpretiraj() svojih podizraza – operacija interpretiraj() svakog terminalnog izraza definiše krajnju tačku u rekurziji – operacija interpretiraj() u svakom čvoru koristi kontekst da smesti stanje i pristupi stanju interpretacije • Posledice: – lako je menjati i proširivati gramatiku • klase reprezentuju pravila • ova se mogu menjati i dodavati nova kroz izvođenje – lako je implementirati gramatiku • klase koje definišu čvorove SAS imaju slične implementacije • generisanje ovih klasa može čak da bude automatizovano – kompleksne gramatike je teško održavati • za svako gramatičko pravilo se defiiše barem jedna klasa • gramatike sa mnogo pravila rezultuju u velikom broju klasa Kontekst ApstraktniIzraz +interpretiraj(Kontekst) TerminalniIzraz +interpretiraj(Kontekst) NeterminalniIzraz +interpretiraj(Kontekst) Klijent *
  • 164. Projektni uzorci – Interpreter 165 Projektovanje softvera • treba primenjivati druge tehnike (generatori parsera/prevodioca) – dodavanje novih načina za interpretaciju izraza • dodavanje novog načina za interpretaciju izraza (npr. proveraTipa()) zahteva dodavanje nove operacije u sve klase izraza • ako se ovo radi više puta, treba razmotriti uzorak Posetilac • UML notacija: • Povezani uzorci: – SAS je primerak projektnog uzorka Kompozicija – Muva omogućava da se efikasno dele terminalni simboli u SAS – Interpreter može da koristi Iterator za obilazak SAS – ako se operacija interpretiraj() realizuje u posebnoj klasi, onda je moguće lako dodavati druge načine interpretacije - Posetilac RegularniIzraz Literal Redjanje Tekst ApstraktniIzraz TerminalniIzraz NeterminalniIzraz Kontekst Klijent Klijent Uzorak Interpreter
  • 165. 166 Literatura Elektrotehnički fakultet u Beogradu Literatura Booch, G., Rumbaugh, J., Jacobson., I., The Unified Modeling Language User Guide, 2nd edition, Addison-Wesley, 2005. Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference Manual, 2nd edition, Addison-Wesley, 2005 Fowler, M., UML distilled, 3rd ed., Addison-Wesley Professional, 2003., prevod na srpski jezik: UML ukratko, Mikro knjiga, 2004. Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns, Addison-Wesley, 1998., prevod na srpski jezik: Gotova Rešenja, CET, 2002. Kraus, L., Tartalja, I., Zbirka zadataka iz projektovanja softvera, Akademska misao, 2009.