Oblikovanje programske potpore Modeliranje objektno usmjerene arhitekture programske
Oblikovanje programske potpore Modeliranje (objektno usmjerene) arhitekture programske potpore (UML jezik za modeliranje) 1
Kreiranje UML-a UML 1. 3 OMG Acceptance, Nov 1997 UML 1. 1 Final submission to OMG, Sep ‘ 97 public feedback First submission to OMG, Jan ´ 97 UML 1. 0 UML partners UML 0. 9 Web - June ´ 96 OOPSLA ´ 95 Other methods Unified Method 0. 8 Booch method OMT OOSE
Sudjelovanje u kreiranju UML-a Harel Meyer Before and after conditions Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions and message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Object lifecycles Odell Classification
Modeli i dijagrami Model je pojednostavljeni opis sustava iz određene perspektive. Dokumentira se dijagramima. Obilježja dijagrama: • Dijagram je pogled u model predstavljen s aspekta određenog dionika. • Dijagram je djelomičan opis sustava. • Dijagram mora biti semantički konzistentan s ostalim pogledima. U okviru UML standarda (v. 1. 3) postoji devet standardnih dijagrama: • Statički pogledi (5 dijagrama): dijagram obrazaca uporabe, dijagram razreda, dijagram objekata, dijagram komponenata, dijagram razmještaja • Dinamički pogledi (4 dijagrama): sekvencijski dijagram, komunikacijski (kolaboracijski) dijagram, dijagram stanja (“statechart”), dijagram aktivnosti
Modeli i dijagrami Dijagrami specifični za objektno usmjerenu programsku potporu Dijagrami razmatrani u sklopu analize i dokumentiranja zahtjeva Use Case Diagrams Sekvencijski Diagrams dijagrami Use Case Dijagrami Diagrams obrazaca uporabe (use case) Scenario Diagrams Komunikacijski Diagrams dijagrami Scenario “Statechart” Diagrams Dijagrami stanja State Diagrams Dijagrami Diagrams razreda Modeli State Diagrams Dijagrami Diagrams objekata State Diagrams Dijagrami Diagrams komponenata Component Diagrams Dijagrami aktivnosti razmještaja
Modeliranje s razredima (UML dijagrami razreda i objekata) Izvor: T. C. Lethbridge, R. Laganiere, 2005 6
Temelji UML dijagrama razreda Dijagram razreda predstavlja apstraktan pogled na sustav. Osnovni simboli prikazani na dijagramima razreda su: • Razredi - apstraktna reprezentacija objekata određenog razreda (svih objekata toga razreda koji uopće mogu postojati). - predstavljanju tip podataka (podatkovne apstrakcije koje sadrže procedure). • Pridruživanja (engl. Associations) - apstraktna reprezentacija svih mogućih veza između instanci dvaju razreda koje uopće mogu postojati. • Atributi (obilježja, stanje) - podaci sadržani u razredima i njihovim instancama. • Operacije - predstavljaju funkcionalnosti koje izvode instance razreda (objekti). • Generalizacije - grupiranje razreda u hijerarhiju nasljeđivanja. 7
Razredi Razred je predstavljen pravokutnikom s imenom. • Grafički simbol razreda može prikazati atribute i operacije. • Cjeloviti potpis operacije je: : [vidljivost] name([parameter-list]): return. Type — vidljivost je private ako nema oznake • Razred se može prikazati s različitom razinom detalja, kao na slici: Oznake za vidljivost + public (dostupni svima) - private (dostupni unutar razreda) # protected (dostupni od podrazreda) 8
Pridruživanje i brojnost (višestrukost) Pridruživanje ili asocija pokazuje sve moguće veze između objekata dvaju razreda. Označuje se crtom između razreda. Brojnost pokazuje koliko objekata (instanci) promatranog razreda (na toj strani veze) može biti povezano s nekim objektom drugog razreda. Primjer: 0 ili 1 objekt razreda Office (promatrani kraj asocijacije) može se povezati s 0 ili više objekata razreda Employee (na drugom kraju asocijacije). 0 ili više 1 ili više 0 ili između 3 i 8 5 dijagrama razreda 9
Označavanje pridruživanja • Svako pridruživanje može se dodatno označiti kako bi se ekspliciralo njegovo značenje. Na svakom kraju pridruživanja može se opisati uloga (engl. role) koju ima instanca toga razreda. 10
Analiza i validacija pridruživanja • Više (mnogo) - jedan —Samo jednu kompaniju je moguće povezati s jednim zaposlenikom. - Ta kompanija nema podataka o radu “u fušu” (engl. moonlighting). —Jedna kompanija može imati ima više zaposlenika. —Kompanija može biti bez zaposlenika. - Npr. početna registracija, ili krovna kompanija. —Nije moguće biti zaposlenik ako ne radiš za neku kompaniju. Employee * works. For 1 Company zaposlenik 11
Analiza i validacija pridruživanja • Više - više —Jedan asistent može raditi za više menadžera. —Jedan menadžer može imati više asistenata. —Asistenti mogu biti organizirani u skupove (engl. pool). —Menadžeri mogu imati grupu asistenata. —Neki menadžeri nemaju asistente. (0. . * i * je ekvivalentno) Assistant * (najmanje 1) 1. . ** supervisor Manager 12
Analiza i validacija pridruživanja • Jedan - jedan —U svakoj kompaniji postoji točno jedan odbor direktora. —Odbor direktora je odbor samo jednoj kompaniji. — Kompanija mora uvijek imati odbor direktora. —Odbor direktora je uvijek odbor u nekoj kompaniji. 1 1 13
Analiza i validacija pridruživanja Izbjegavaj nepotrebno jedan – jedan pridruživanje. Izbjegavaj ovo Učini ovo 14
Složeniji primjer pridruživanja (rezervacija leta) • Rezervacija (engl. booking) je uvijek samo za jednog putnika. —Nema rezervacije za nula putnika. —Rezervacija nikada ne uključuje više od jednog putnika. . • Putnik može imati bilo koji broj rezervacija. —Putnik uopće ne mora imati neku rezervaciju. —Putnik može imati više od jednu rezervaciju. • Rezervacije se odnose na specifičan let. • Ukupno se može identificirati tri razreda. • Okvir oko ovoga dijagrama je opcija koju predviđa UML 2. 0. (nebitno za ova predavanja) 15
Pridruženi razredi • Ponekad se atribut (podatak) koji se tiče više razreda ne može smjestiti niti u jedan od navedenih razreda. • Postoje dva ekvivalentna označavanja pridruženih razreda: : Ako je grade ovdje, tada ga nije moguće imati za više predmeta (već samo za jedan po studentu) Pridruženi razred, može imati podrazrede Ako je grade ovdje, tada ga nije moguće imati za više studenata (već samo za jednog po grupi predmeta) Semantički jasnije Jednostavnije se čita 16
Refleksivno pridruživanje • Moguće je da se pridruživanje spaja na isti razred. vrlo slični predmeti ne mogu se upisivati predmet može imati druge predmete kao preduvjete 17
Smjer pridruživanja Pridruživanja su u osnovici bidirekcijska (dvosmjerna). Moguće je ograničiti smjer pridruživanja dodavanjem strelice na jednom kraju. (za odabrani dan pogledaj bilješku, ali ne i obratno) 18
Generalizacija Specijalizacija superrazreda u jedan ili više podrazreda. • Generalizacijski skup je označena grupa generalizacija sa zajedničkim superrazredom. • Oznaka riječima (katkad nazvana diskriminator) opisuje kriterije za specijalizaciju. 19
Izbjegavanje nepotrebne generalizacije (1/2) Nepogodna hijerarhija razreda, Podrazredi bi trebali biti instance (objekti). Vidi slijedeću sliku. 20
Izbjegavanje nepotrebne generalizacije (2/2) Vrste zapisa Dijagram razreda Dijagrami objekata U dijagramu objekata nema oznaka brojnosti Slika pokazuje poboljšani dijagram razreda uz pridružena dva dijagrama objekata (instanci). Razredi iz prethodnog dijagrama su ovdje objekti (instance) jednog razreda Recording. Category 21
Rukovanje višestrukim diskriminatorima • Kreiranje generalizacije više razine. Dvije generalizacije koje dijele isti superrazred. (ovo je bolje rješenje nego dvije odvojene hijerarhije) 22
Rukovanje višestrukim diskriminatorima (višestruko nasljeđivanje) 23
Izbjegavanje da instance moraju mijenjati razred • Instanca nikad ne treba mijenjati razred. Studentov status se može promijeniti, pa taj objekt (instanca) mora promijeniti razred (traži destrukciju – kreaciju novog objekta). Jedno rješenje: uključi atribut attendance. Status u razred Student te ne koristiti podrazrede (ali tako se gubi mogućnost polimorfizma - specifičnih metoda u različitim podrazredima). 24
Dijagrami objekata generiraju se iz dijagrama razreda: Primjer: Iz ovih dijagrama razreda generiraju se (nastaju) dijagrami objekata (vidi sljedeću sliku): 25
Dijagram objekata (instanci) Prikazuje instance (objekte) i veze između njih u jednom trenutku izvođenja sustava (nije više apstrakcija svih mogućih objekata i veza). Poveznica (engl. link) između objekata je instanca pridruživanja (asocijacije) između razreda (slično kako je objekt instanca jednog razreda). — Na vezama nema oznake brojnosti (radi se o individualnim objektima u jednom trenutku izvođenja programa). • Iz jednog dijagrama razreda mogu se generirati beskonačno mnogo dijagrama objekata. Iz ranijih dvaju dijagrama razreda generiraju se dijagrami objekata (poveznice su konzistentne s definiranom brojnosti): 26
Razlika između pridruživanja i generalizacije • Pridruživanje (asocija) razreda opisuje odnos između instanci koji će nastupiti za vrijeme izvođenja programa. —Kada se dijagram objekata generira iz dijagrama razreda, u dijagramu objekata postojat će instance oba razreda spojene vezama (instancama pridruživanja). • Generalizacija opisuje odnos isključivo između razreda u dijagramu razreda. —Generalizacija se ne pojavljuje u dijagramu objekata. —Jedna instanca nekog razreda ujedno je i instanca svakog njegovog superrazreda. 27
Napredne značajke u dijagramu razreda: Agregacija • Agregacije su posebna vrsta pridruživanja koja predstavlja odnos “cjelina-dio”. —“Cijeli” dio se često naziva agregat (zbor, skup). —UML simbol označuje pridruživanje “je_dio_od” (engl. is. Part. Of ). vozilo dio vozila država oznake brojnosti ! 28
Kada koristiti agregaciju Kao opće pravilo, agregacija se u pridruživanju koristi kada: • • Može se tvrditi: — Dijelovi su dio agregata. — ili agregat je sastavljen od dijelova. Kada je netko ili nešto vlasnik agregata (ili upravlja njime) tada je ujedno i vlasnik (upravlja) njegovim dijelovima. 29
Kompozicija • Kompozicija je jaki tip agregacije. —Ako se agregat uništi, tada se uništavaju i njegovi dijelovi. • Alternativni načini modeliranja adresa: 30
Agregacija public class Person { // person has a name private Name my_name; // Name je razred public void set. Name(Name a_name) { my_name = a_name ; } //. . . } • • Objekt razreda Person sadrži objekt razreda Name. Kod agregacije stvaranje objekta razreda Name je izvan razreda Person. Nije poznat njegov životni vijek. 31
Kompozicija public class Person { // person has a name private Name my_name; public Person (String f. Name, String l. Name) { my_name = new Name(f. Name, l. Name); } //. . . } • • Objekt razreda Person sadrži objekt razreda Name. Kako se objekt razreda Name stvara u konstruktoru razreda Person, to će objekt razreda Name nestati kada nestane objekt razreda Person. To je kompozicija. 32
Primjeri agregacije i kompozicije 33
Agregacijska hijerarhija 34
Propagacija u agregaciji • Propagacija je mehanizam kojim se implementira operacija u agregatu tako da djeluje na njegove dijelove. • U isto vrijeme, značajke dijelova propagiraju natrag prema agregatu. • Propagacija u agregaciji predstavlja isto što i nasljeđivanje u generalizaciji. —Temeljna razlika: - Nasljeđivanje je implicitan mehanizam. - Propagacija se mora programirati kada je potrebna. agregat dijelovi 35
Sučelja (engl. Interfaces) Sučelje opisuje dio vidljivog ponašanja skupa objekata. • Jedno sučelje slično je razredu, osim što mu nedostaju varijable instanci i implementacija metoda. Sučelje je lista apstraktnih operacija. Sučelje pokazuje vidljivo ponašanje objekta. Sučelje nije moguće instancirati. «interface» je UML oznaka “stereotip”. Označuje “nešto posebno” Apstraktne operacije koje implementira neki konkretan razred. Ovdje je sučelje kao pridruženi razred Označavanje sučelja u UML-u moguće je na dva načina. 36
Sučelja (engl. Interfaces) Prethodnu sliku možemo čitati: — Employee "se može vidjeti kao" Blagajnik (engl. cashier). — ATM "se može vidjeti kao" Blagajnik (engl. cashier). (gdje je "se može vidjeti" = "can-be-seen-as"). Vrijednost sučelja je u specifikaciji operacija koje polimorfno implementiraju različiti razredi. Ti razredi (koji implementiraju operacije) ne moraju biti ni u kakvom međusobnom odnosu. Neki razred može implementirati više sučelja. Sučelje može biti tip neke varijable. Takva varijabla referencira objekt (instancu) bilo kojega razreda koji implementira sučelje. Sučelje ne može stvoriti objekt (jer opisuje apstrakna ponašanja). Objekt tipa sučelja može nastati konstruktorom razreda koji implementira to sučelje. Pozivanje ispravne metode osigurano je dinamičkim povezivanjem kao kod nasljeđivanja. Uporabom te varijable može se izvesti bilo koja operacija koja je podržana sučeljem. 37
Sučelja (engl. Interfaces) Primjer sučelja Ownable kao skupine apstraktnih metoda: public interface Ownable { public abstract String get. Owner(); // apstrakt operacije public abstract void set. Owner(String name); } Neki razred implementira sučelje Ownable: public class Bank. Account implements Ownable { … public String get. Owner(){return account. Holder; } public void set. Owner(String name){account. Holder = name; } … } Poziv neke "interface" metode (var b je tipa razreda koji implementira sučelje): Bank. Account b = new Bank. Account(); (može i preko tipa sučelja: Ownable b = new Bank. Acccount(); ) b. get. Owner(); Samo ovaj razred može stvoriti objekt 38
Bilješke i opisni tekst • Opisni tekst i drugi dijagrami —Uključi dijagrame u veći dokument (vidi projekt u okviru predmeta Oblikovanje programske potpore). —Tekst može objasniti bilo koji aspekt sustava uporabom sasvim slobodne (nestandardizirane) notacije. —Ističe i proširuje opis važnih značajki sustava, te navodi argumente u donošenju odluka oblikovanja. • Bilješke (engl. Notes): —Bilješka je mali blok teksta uključen u UML dijagram. —Ima istu ulogu kao i komentar u programskom jeziku. 39
Proces razvoja dijagrama razreda UML modeli mogu se kreirati u različitim fazama oblikovanja programske potpore s različitim ciljem (svrhom) i s različitom razinom detalja. • Istraživački (engl exploratory) model domene primjene: (malo detalja) —Razvija se tijekom analize domene s ciljem razumijevanja te domene. • Sistemski model domene: (više detalja) —Modelira aspekt domene koji će biti predstavljen programskim sustavom. • Model sustava: (najviše detalja) —Uključuje razrede objekata potrebnih u izgradnji arhitekture sustava i korisničkog sučelja. fokus u ovom kolegiju (vidi dokumentaciju projekta) 40
Modeli i razine detalja Elementi (ne domenski) potrebni za izgradnju Elementi koji predstavljaju domene koji će potpunog sustava stvarno biti domenu implementirani 41
Sistemski model domene i model sustava • Sistemski model domene može izostaviti mnoge razrede potrebne u izgradnji cjelovitog programskog sustava. —Može sadržavati manje od polovice od ukupnog broje razreda u sustavu. —Izgrađuje se i koristi neovisno o skupu - razreda koji modeliraju korisničko sučelje - razreda koji modeliraju arhitekturu sustava • Cjeloviti model sustava sadrži —Sistemski model domene —Razrede koji modeliraju korisničko sučelje —Razrede koji modeliraju arhitekturu sustava —Pomoćne razrede 42
Preporučena sekvenca aktivnosti pri izradi dijagrama razreda 1. 2. 3. 4. 5. 6. Identificiraj početni skup kandidata za razrede. Dodaj pridruživanja (engl. associations), brojnost i atribute (podatke). Pronađi generalizacije (hijerarhiju razreda). Izlistaj temeljne odgovornosti (engl. resposibilities) svakog razreda. Odluči se za specifične operacije. Iteriraj proces dok ne dobiješ zadovoljavajući model — Dodaj ili izbriši razrede, pridruživanja, atribute, generalizacije, odgovornosti ili operacije. — Identificiraj razrede sučelja. Odgovornost je nešto sustav i njegovi razredi moraju obaviti. To je viša razina apstrakcije ponašanja od operacije. Hijerarhija ponašanja: odgovornost operacija metoda. 43
Identificiraj razrede • Tijekom razvoja modela domene otkrij (engl. discover) razrede. • Kada si usredotočen na korisničko sučelje ili na arhitekturu sustava razredi se osmišljavaju (engl. invent) kako bi se riješio određen problem u oblikovanju. —Osmišljavanje je dopustivo i tijekom razvoja modela domene. • Obrati pažnju na mogućnost ponovne uporabe (engl. reuse) razreda. 44
Jednostavna tehnika otkrivanja razreda u domeni primjene • Pogledaj u izvorne dokumente opisa zahtjeva. • Izdvoji imenice i imeničke izraze. • Eliminiraj imenice koje: —su redundantne —predstavljaju instance —nejasne su i vrlo općenite —nepotrebne u primjeni • Obrati pažnju na razrede u domeni koji predstavljaju tipove korisnika ili druge aktore. U pravilu se i njih predočuje kao razred u sustavu. 45
Primjer otkrivanja razreda: dobri, loši i razredi za koje nismo sigurni. • Sustav osigurava temeljne usluge za rukovanje bankovnom računima u banci koja se zove OOBank. Ta banka ima više poslovnica, koje imaju svoje adrese i oznaku poslovnice. Pojedini klijent otvara račun u poslovnici banke. Sustav – previše općenit razred OOBank – očito instanca oznaka poslovnice – očito atribut 46
Identificiranje atributa • Započni s razredima koji su središnji i najvažniji. • Odluči o jasnim i očiglednim podacima koje ti razredi moraju sadržavati, te o njihovim odnosima s drugim razredima. • Potraži informacije koje svaki razred mora podržavati. • Neke imenice koje su odbačene kao razredi, sada mogu biti atributi. • Atribut bi općenito trebao sadržavati jednostavnu vrijednost —Npr. string, broj 47
Savjeti o identificiranju i specificiranju valjanih pridruživanja između razreda • Pogledaj u sekvencijski dijagram koji razredi (tj. njihovi objekti) komuniciraju. • Pridruživanje postoji ako razred: - posjeduje (ili ovladava) - upravlja - spojen je s - odnosi se prema (engl. is related to) - dio je od - ima dijelove - član je - ima članove . . . neke druge razrede u modelu. • Specificiraj brojnost na oba kraja pridruživanja. • Označi pridruživanje dodatnom informacijom. . 48
Akcije nisu pridruživanja • Česta pogreška je predstaviti akcije kao pridruživanja. Posudba knjiga, CD, . . . Loše, akcije su predstavljene kao pridruživanja Bolje, operacija borrow kreira poseban objekt iz razreda Loan. Operacija return postavlja returned. Date atribut. Obrati pažnju da su borrow i return operacije a ne pridruživanja. 49
Savjeti o identificiranju i specificiranju valjanih atributa • Nije dobro imati mnogo kopija atributa. • Ako neki podskup atributa u pojedinom razredu čini koherentnu grupu kreiraj poseban razred koji sadrži te atribute. nula ili više Loše, atribut u množini. Loše, previše atributa. Dobro rješenje. type označuje da li je to adresa stanovanja ili posla. 50
Identificiranje generalizacija i sučelja (engl. Interfaces) • • Postoje dva načina identificiranja generalizacija: — Odozdo prema gore - Grupiraj slične razrede i kreiraj novi superrazred — Odozgo prema dolje - Najprije potraži općenitije razrede pa ih specijaliziraj ako je potrebno. Kreiraj sučelje (engl. Interface) umjesto superrazreda: — Postoji potreba za varijablom koja bi morala referencirati instance nekoliko razreda, a pri tome: - Razredi su vrlo različiti osim nekoliko zajedničkih operacija. Jedan ili više razreda već imaju svoj superrazred (npr. u Javi je nespretno izvesti višestruko nasljeđivanje) Želi se ograničiti operacije s varijablom samo na operacije dostupne u sučelju. 51
Primjer: Sustav rezervacije avio-leta The reservation system keeps track of passengers who will be flying in specific seats on various flights, as well as people who will form the crew. For the crew the system needs to track what everyone does and who supervises whom. ********************** Sustav za rezervaciju vodi računa i pohranjuje podatke o putnicima koji će letjeti na odabranom sjedištu na raznim letovima, te podatke o ljudima koji će činiti posadu. Što se posade tiče, sustav treba voditi računa tko što radi te tko nadgleda koga. *********************** Postupak identificiranja razreda: Imenice na početnoj listi razreda: Flight, Passenger, Employee Ostale imenice: “reservation system” – previše općenit razred “seat” – atribut razreda Flight “crew” – Employee je mnogo fleksibilnije (uključuje i ostale). “people” – preopćenito, tu se radi ustvari o Employee 52
Primjer: Sustav rezervacije avio-leta Flight – (određen let) središnji razred oko kojega se gradi sustav (sadrži atribute/podatke: date, time, flight. Number). Znamo da letovi koji polijeću u određene dane (obično u tjednu) u isto vrijeme imaju isti broj leta (flight. Number). Zato je logično da se podijeli Flight u Regular. Flight (sadrži time and flight number) i Specific. Flight (odlazi na određen dan - date). Pridruživanje između ova dva razreda je jedan – mnogo (jedan Regular. Flight u određenim danima). Svaki definiran dan ima samo jedan regularan let. 53
Primjer: Sustav rezervacije avio-leta Putnici i rezervacije leta: Passenger ima atribut/podatak ime putnika ali i neki ID broj. Između Passenger i Specific. Flight općenito postoji odnos mnogo-mnogo. Ranije pokazano da je između Passenger i Specific. Flight, potrebno ubaciti pridruženi razred Booking sa seat. Number kao atributom. Instanca Passenger se kreira prije ili istovremeno s Bookingom. Booking je uvijek za jednog Passangera. Passenger može imati više Bookinga (može i 0 Bookinga). Za svaki Booking postoji samo jedan Specific. Flight. Svaki Specific. Flight može imati veći koji broj Bookinga (od 0 do kapaciteta aviona). 54
Primjer: Sustav rezervacije avio-leta Razred zaposlenik (Employee): Atributi: name, employee. ID, job. Function (tko što radi). Employee može biti supervisor drugim Employee. Potrebno je uvesti refleksivno pridruživanje s oznakom uloge (engl. role) na jednom kraju (i naravno brojnost, npr 0. . 1 prema *). Razred Employee je pridružen razredu Specific. Flight uz brojnost mnogo-mnogo. 55
Primjer: Sustav rezervacije avio-leta – sve spojeno (atributi i pridruživnja) u slučaju istih imena “who supervises whom” tko nadgleda koga implicira refleksivno pridruživanje u nekom danu isto vrijeme, isti broj leta. “what everyone does” tko što radi implicira atribut job. Function različiti dani Generalizacije ? 56
Primjer: Sustav rezervacije avio-leta Identificiranje generalizacija Razredi Passenger i Employee očito dijele neke zajedničke informacije. Moguće je uvesti superrazred Person. Definiranje superrazreda Person nije dovoljno dobro jer jedna osoba (Person) može biti oboje: putnik (Passenger) i zaposlenik (Employee). Budući da: Instanca može nastati i postojati samo od jednog razreda ! uveden je razred Person. Role i pridružen razredu Person. Svaka instancija (objekt) od Person može imati nula do dvije uloge. Person. Role se specijalizira u Passenger. Role i Employee. Role. Instance od Passenger. Role i Employee. Role nasljeđuju uloge i povezuju se (asocija) s objektom iz razreda Person. Mogući dio dijagrama objekata (UML objekte označuje podcrtano): Person 1 sam (nema nikakvu ulogu, brojnost 0); Person 2 povezan s Passenger. Role 1; (brojnost 1) Person 3 povezan s Employee. Role 1; (brojnost 1) Person 4 povezan s Passenger. Role 2 i Employee. Role 2. (broj. 2) 57
Primjer: Sustav rezervacije avio-leta (generalizacije) novi superrazred bolji nazivi razreda 58
Alociranje odgovornosti (engl. responsibility) Odgovornosti su nešto razredi u sustavu moraju obaviti. • Svaki funkcionalni zahtjev mora se pripisati nekom razredu. —Sve odgovornosti jednog razreda moraju biti jasno povezane. —Ako jedan razred ima previše odgovornosti, razmotri podjelu toga razreda u različite razrede. —Ako razred nema odgovornosti, tada je vjerojatno beskoristan. —Ako se neka odgovornost ne može pripisati niti jednom od postojećih razreda, mora se kreirati novi razred. • Kako bi se odredile odgovornosti: —Analiziraj obrasce uporabe (engl. use case). —U opisu sustava potraži glagole i imenice koje opisuju akcije. 59
Kategorije odgovornosti • Postavljanje i dohvaćanje vrijednosti atributa. • Kreiranje i inicijalizacija novih instanci (objekata). • Upis i čitanje iz trajne pohrane podataka. • Dokidanje (uništavanje) instanci (objekata). • Dodavanje i brisanje veza između instanci. • Kopiranje, konverzija, preslikavanje, prijenos, izlaz podataka. • Izračunavanje numeričkih vrijednosti. • Navigacija i pretraživanje (npr. pronaći sve instance koje odgovaraju nekom kriteriju). • Drugi specijalizirani poslovi. 60
Primjer: Sustav rezervacije avio-leta (odgovornosti) Neke primjerene odgovornosti: Pripiši odgovornost novom razredu Novi razred (kompanija) Kreiranje novog regularnog leta Pronalaženje leta Modificiranje atributa leta Kreiranje novog specifičnog leta Rezervacija leta Otkazivanje rezervacije Može se pripisati u Booking, ali Booking još nije kreiran u trenutku kad se ova odgovornost inicijalizira 61
Objašnjenja alociranja odgovornosti: • Dinamičko kreiranje Regular. Flight prepušta se objektu. Stoga se uvodi novi razred Airline čiji objekt će kreirati instancu od Regular. Flight. Vjerojatno će postojati samo jedan objekt od razreda Airline. • U pronalaženju određenog Regular. Flight, odgovornost za održavanje kolekcije objekata Regular. Flight prepušta se također razredu Airline, jer je objekt od Airline kreirao objekt od Regular. Flight. • Modificiranje atributa u Regular. Flight je odgovornost te iste Regular. Flight klase. • Kreiranje Specific. Flight može biti odgovornost razreda Regular. Flight, jer Regular. Flight postoji kada se ta odgovornost inicira. • Otkazivanje leta Specific. Flight može biti odgovornost tog istog razreda. • Odgovornost za rezervaciju (engl. Booking a passenger) je objašnjena na prethodnoj slici. • Otkazivanje rezervacije je prirodna odgovornost klase Booking. 62
Identificiranje operacija za realizaciju odgovornosti Hijerarhija ponašanja: odgovornost operacije metode. Operacije realiziraju odgovornosti pojedinog razreda a implementiraju se metodama. • Može postojati nekoliko operacija i metoda koje realiziraju jednu odgovornost. • Uvijek je jedna operacija glavna za realizaciju odgovornosti. • Ta glavna operacija (metoda) koja realizira odgovornost normalno se deklarira kao public. • Druge operacije (metode) koje surađuju u realizaciji odgovornosti trebaju biti što je moguće više deklarirane kao private. Inače, ako bi sve operacije mogle biti izravno pozivane (public), sustav bi se mogao naći u nestabilnom stanju (u sredini neke odgovornosti). 63
Tipične jednostavne odgovornosti Odgovornosti je katkada bolje prikazati skupom manjih (jednostavnijih) odgovornosti iako na kraju svaka odgovornost (složena ili jednostavna) mora rezultirati definiranim skupom operacija. Realizacija neke odgovornosti najčešće traži kolaboraciju nekoliko razreda. Tipične jednostavne odgovornosti su: a) Povezati dva postojeća objekta (kako bi jedan znao za drugoga). b) Kreirati objekt i povezati ga s nekim postojećim objektom. c) Kreirati pridružen razred (engl. association class). d) Promijeniti destinaciju veze (engl. link) između objekata. e) Pretražiti skup pridruženih objekata. 64
Primjer realizacija jednostavnih odgovornosti Promatramo nešto izmijenjeni raniji primjer i operacije koje realiziraju odgovornosti razreda Specific. Flight Dodani su i novi razredi Airplane i Flight. Log) Ako bez oznake može se dohvatiti unutar paketa U UML notaciji uvijek se mogu dodati oznake. Ovdje slova a do e znače pojedinu odgovornost 65
Odgovornost a), povezivanje dva postojeća objekta To je u objektnom dijagramu kreiranje veze (engl. link), a u implementaciji definiranje varijable instanci u kojoj će biti referenciran (“upisan”) objekt. Tako da jedan objekt zna za drugoga. Dvosmjerna veza razbija se na dvije jednosmjerne. Npr. : dodavanje bidirekcijske veze između postojeće instance od Specific. Flight i postojeće instance od Airplane (na ranijoj slici to su operacije označene s “a 1” i “a 2”. Specific. Flight * 0. . 1 Airplane a 1 - (public) Instanca od Specific. Flight — izgradi jednosmjernu vezu prema instanci od Airplane. — zatim zove operaciju a 2 - (non - public) Instanca od Airplane — izgradi jednosmjernu vezu natrag do instance od Specific. Flight. 66
Odgovornost a), povezivanje dva postojeća objekta Asocija se implementira kao veza (engl. link) kroz varijablu instanci. Dvosmjerna asocija (veza) se rastavlja na dvije jednosmjerne asocijacije (veze). Implementacija jednosmjerne veze gdje je brojnost na drugom kraju 0. . 1: — Specific. Flight će imati deklaracije varijabli (Java): - private Airplane airplane; — Također i veza (link) prema Flight. Log - private Flight. Log flightlog; Ako je brojnost “mnogo” upotrebljava se za tip varijable razred za kolekciju kao što je List. U razredu Airplane će stoga postojati deklaracija (za vezu) natrag: - private List specific. Flights; A na primjer Passenger. Role ima: private List bookings; 67
Odgovornost b), kreiranje objekta i povezivanje s nekim postojećim objektom Kreiranje objekta Flight. Log i povezivanje sa Specific. Flight: b 1 – (public), instanca od Specific. Flight poziva konstruktor iz Flight. Log i nakon konstrukcije ostvaruje jednosmjernu vezu prema tom novom objektu iz Flight. Log. b 2 – (non-public), konstruktor razreda Flight. Log, pored drugih akcija, ostvaruje jednosmjernu vezu na Specific. Flight. Na slajdu 59 , postoji analogno: Regular. Flight kreira više objekata (više specifičnih letova) i povezuje se sa Specific. Flight. Na sljedećoj slici je kostur koda (Java) 68
Regular. Flight kreira objekt Specific. Flight class Regular. Flight { private List specific. Flights; // tu stavljamo spec letove. . . // metoda zove konstruktor u Specific. Flight i upisuje let public void add. Specific. Flight(Calendar a. Date); { Specific. Flight new. Specific. Flight; // var za jedan spec let new. Specific. Flight = new Specific. Flight(a. Date, this); specific. Flights. add(new. Specific. Flight); // dodaj u listu. . . } this = trenutni objekt iz Regular. Flight. class Specific. Flight { Konstruirani objekt iz Specific. Flight te private Calendar date; ostvaruje povratnu vezu. private Regular. Flight regular. Flight; // za vezu s . . . // Regular. Flight Specific. Flight(Calendar a. Date, Regular. Flight a. Regular. Flight) { date = a. Date; // na određen dan regular. Flight = a. Regular. Flight; }. . . } // ostvari vezu 69
Odgovornost c), kreiranje pridruženog razreda Kreiranje instance Booking koja povezuje Passenger. Role i Specific. Flight c 1 – (public), instanca od Passenger. Role zove konstruktor od Booking. c 2 – (non-public), konstruktor Booking(), uz druge akcije stvara: - jednosmjernu vezu natrag na Passenger. Role. - jednosmjernu vezu prema Specific. Flight - zove operacije c 3 i c 4 c 3 – (non_public), instanca od Specific. Flight stvara jednosmjernu vezu s instancom od Booking c 4 – (non-public), instanca od Passenger. Role stvara jednosmjernu vezu prema instanci od Booking (jer čeka da se sve stvori). 70
Odgovornost d), promjena destinacije veze Promjena postojećih aviona (objekata) airplane 1 u airplane 2 kao instanci iz razreda Airplane d 1 - (public), instanca od Specific. Flight — briše vezu na airplane 1 — ostvaruje jednosmjernu vezu na airplane 2 Podcrtano je uobičajena UML oznaka za objekt. — zove operaciju d 2, a zatim operaciju d 3. d 2. - (non-public), airplane 1 — briše jednosmjernu vezu do instance do Specific. Flight. d 3 - (non-public) airplane 2 — ostvaruje jednosmjernu vezu prema instanci od Specific. Flight. 71
Odgovornost e), pretraživanje skupa objekata Pretraživanje i pronalaženje po imenima članova posade za određeni objekt iz razreda Specific. Flight e 1 - (public), instanca od Specific. Flight — kreira sekvencijski upit (tipa Iterator u Javi) koji iterira preko svih svojih veza tipa crew. Member. — za svaku od tih veza zove operaciju e 2, dok se ne pronađe podudarnost. e 2 - (može biti public), instanca od Employee. Role vraća ime člana posade. 72
Tradicijska metoda oblikovanje dijagrama razreda na papiru • Nakon identifikacije razreda, svakom razredu se dodijeli mali komad papira (karticu) s nazivom razreda. • Te se kartice nazivaju CRC (engl. Class-Responsibility. Collaboration) kartice. • Nakon što se identificiraju atributi i odgovornosti, popišu se na papir (CRC kartici) određenog razreda. • Ako se sve odgovornosti ne mogu ispisati na jednoj CRC kartici: - to sugerira da se razred treba podijeliti u dva međusobno povezana razreda. . • Premještajući i pomičući kartice oblikuje se dijagram razreda. • Povlačenje linija između kartica predstavlja asocijacije i generalizacije. 73
Poteškoće i rizici u kreiranju dijagrama razreda • Modeliranje je posebno teška vještina. —Čak i izvrsni programeri imaju poteškoća razmišljati na odgovarajućoj razini apstrakcije. —Obrazovanje se tradicijski više fokusira na programiranje nego na modeliranje. • Rješenje: —Osiguraj da članovi tima imaju adekvatno obrazovanje. —Imaj u timu jednu ili više iskusnih osoba za modeliranje. —Tijekom oblikovanja temeljito recenziraj sve modele. 74
- Slides: 74