Oblikovanje programske potpore Modeliranje (objektno usmjerene) arhitekture programske potpore

Oblikovanje programske potpore

• Modeliranje (objektno usmjerene) arhitekture programske potpore

• (UML jezik za modeliranje)

Kreiranje UML-a

Sudjelovanje u kreiranju UML-a

Modeli i dijagrami

Modeli i dijagrami

• Modeliranje s razredima

• (UML dijagrami razreda i objekata)

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.

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]): returnType
• vidljivost je private ako nema oznake
• Razred se može prikazati s različitom razinom detalja, kao na slici:

Pridruživanje i brojnost (višestrukost)

• Pridruživanje ili asocijacija 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).

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.

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.

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.

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.

Analiza i validacija pridruživanja

• Izbjegavaj nepotrebno jedan – jedan pridruživanje.

• Izbjegavaj ovo Učini ovo

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)

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::

Refleksivno pridruživanje

• Moguće je da se pridruživanje spaja na isti razred.

Smjer pridruživanja

• Pridruživanja su u osnovici bidirekcijska (dvosmjerna).

• Moguće je ograničiti smjer pridruživanja dodavanjem strelice na jednom kraju.

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.

Izbjegavanje nepotrebne generalizacije (1/2)

Izbjegavanje nepotrebne generalizacije (2/2)

Rukovanje višestrukim diskriminatorima

• Kreiranje generalizacije više razine.

Rukovanje višestrukim diskriminatorima (višestruko nasljeđivanje)

Izbjegavanje da instance moraju mijenjati razred

• Instanca nikad ne treba mijenjati razred.

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):

Razlika između pridruživanja i generalizacije

• Pridruživanje (asocijacija) 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.

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. isPartOf ).

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.

Kompozicija

• Kompozicija je jaki tip agregacije.
• Ako se agregat uništi, tada se uništavaju i njegovi dijelovi.
• Alternativni načini modeliranja adresa:

Agregacija

• public class Person  {  // person has a name
• private Name my_name;  // Name je razred
•   public void setName(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.

Kompozicija

• public class Person  {  // person has a name
• private Name my_name;  
• public Person (String fName, String lName)  
•    {  
•         my_name = new Name(fName, lName);  
•     }  
•     //...  }  
• 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.

Primjeri agregacije i kompozicije

Agregacijska hijerarhija

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.

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.

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.

Sučelja (engl. Interfaces)

• Primjer sučelja Ownable kao skupine apstraktnih metoda:

• public interface Ownable {

• public abstract String getOwner(); // apstrakt operacije

• public abstract void setOwner(String name); }

• Neki razred implementira sučelje Ownable:

• public class BankAccount implements Ownable {

• …

• public String getOwner(){return accountHolder;}

• public void setOwner(String name){accountHolder = name;}

• … }

• Poziv neke "interface" metode (var b je tipa razreda koji implementira sučelje):

• BankAccount b = new BankAccount();

• (može i preko tipa sučelja: Ownable b = new BankAcccount();)

• b.getOwner();

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.

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)

Modeli i razine detalja

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

Preporučena sekvenca aktivnosti pri izradi dijagrama razreda

• 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.

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.

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.

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.

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

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..

Akcije nisu pridruživanja

• Česta pogreška je predstaviti akcije kao pridruživanja.

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.

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.

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

Primjer: Sustav rezervacije avio-leta

• Flight – (određen let) središnji razred oko kojega se gradi sustav (sadrži atribute/podatke: date, time, flightNumber).

• Znamo da letovi koji polijeću u određene dane (obično u tjednu) u isto vrijeme imaju isti broj leta (flightNumber). Zato je logično da se podijeli Flight u RegularFlight (sadrži time and flight number) i SpecificFlight (odlazi na određen dan - date).

• Pridruživanje između ova dva razreda je jedan – mnogo (jedan RegularFlight u određenim danima).

• Svaki definiran dan ima samo jedan

• regularan let.

Primjer: Sustav rezervacije avio-leta

• Putnici i rezervacije leta:

• Passenger ima atribut/podatak ime putnika ali i neki ID broj.

• Između Passenger i SpecificFlight općenito postoji odnos mnogo-mnogo. Ranije pokazano da je između Passenger i SpecificFlight, potrebno ubaciti pridruženi razred Booking sa seatNumber 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 SpecificFlight.

• Svaki SpecificFlight može imati veći koji broj Bookinga (od 0 do kapaciteta aviona).

Primjer: Sustav rezervacije avio-leta

• Razred zaposlenik (Employee):

• Atributi: name, employeeID, jobFunction (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 SpecificFlight uz brojnost mnogo-mnogo.

Primjer: Sustav rezervacije avio-leta – sve spojeno (atributi i pridruživnja)

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 PersonRole i pridružen razredu Person.

• Svaka instancija (objekt) od Person može imati nula do dvije uloge.

• PersonRole se specijalizira u PassengerRole i EmployeeRole.

• Instance od PassengerRole i EmployeeRole nasljeđuju uloge i povezuju se (asocijacija) s objektom iz razreda Person.

• Mogući dio dijagrama objekata (UML objekte označuje podcrtano):

• Person1 sam (nema nikakvu ulogu, brojnost 0); Person2 povezan s PassengerRole1; (brojnost 1) Person3 povezan s EmployeeRole1; (brojnost 1) Person4 povezan s PassengerRole2 i EmployeeRole2.(broj. 2)

Primjer: Sustav rezervacije avio-leta (generalizacije)

Alociranje odgovornosti (engl. responsibility)

• Odgovornosti su nešto š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.

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.

Primjer: Sustav rezervacije avio-leta (odgovornosti)

• Kreiranje novog regularnog leta

• Pronalaženje leta

• Modificiranje atributa leta

• Kreiranje novog specifičnog leta

• Rezervacija leta

• Otkazivanje rezervacije

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).

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.

Primjer realizacija jednostavnih odgovornosti

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 SpecificFlight i postojeće instance od Airplane (na ranijoj slici to su operacije označene s “a1” i “a2”.

•  

• a1 - (public) Instanca od SpecificFlight

• izgradi jednosmjernu vezu prema instanci od Airplane.
• zatim zove operaciju a2.

• a2 - (non - public) Instanca od Airplane

• izgradi jednosmjernu vezu natrag do instance od SpecificFlight.

Odgovornost a), povezivanje dva postojeća objekta

• Asocijacija se implementira kao veza (engl. link) kroz varijablu instanci.

• Dvosmjerna asocijacija (veza) se rastavlja na dvije jednosmjerne asocijacije (veze).

• Implementacija jednosmjerne veze gdje je brojnost na drugom kraju 0..1:

• SpecificFlight će imati deklaracije varijabli (Java):
• private Airplane airplane;
• Također i veza (link) prema FlightLog
• private FlightLog 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 specificFlights;

• A na primjer PassengerRole ima:

• private List bookings;

Odgovornost b), kreiranje objekta i povezivanje s nekim postojećim objektom

• Kreiranje objekta FlightLog i povezivanje sa SpecificFlight:

• b1 – (public), instanca od SpecificFlight poziva konstruktor iz FlightLog i nakon konstrukcije ostvaruje jednosmjernu vezu prema tom novom objektu iz FlightLog.

• b2 – (non-public), konstruktor razreda FlightLog, pored drugih akcija, ostvaruje jednosmjernu vezu na SpecificFlight.

• Na slajdu 59 , postoji analogno:

• RegularFlight kreira više objekata (više specifičnih letova) i povezuje se sa SpecificFlight.

• Na sljedećoj slici je kostur koda (Java) 

RegularFlight kreira objekt SpecificFlight

• class RegularFlight {

• private List specificFlights; // tu stavljamo spec letove

• ...

• // metoda zove konstruktor u SpecificFlight i upisuje let

• public void addSpecificFlight(Calendar aDate); {

• SpecificFlight newSpecificFlight; // var za jedan spec let

• newSpecificFlight = new SpecificFlight(aDate, this);

• specificFlights.add(newSpecificFlight); // dodaj u listu

• ...}...}

• class SpecificFlight {

• private Calendar date;

• private RegularFlight regularFlight; // za vezu s

• ... // RegularFlight

• SpecificFlight(Calendar aDate, RegularFlight aRegularFlight) { date = aDate; // na određen dan

• regularFlight = aRegularFlight;} ... } // ostvari vezu

Odgovornost c), kreiranje pridruženog razreda

• Kreiranje instance Booking koja povezuje PassengerRole i SpecificFlight

• c1 – (public), instanca od PassengerRole zove konstruktor od Booking .

• c2 – (non-public), konstruktor Booking(), uz druge akcije stvara:

• - jednosmjernu vezu natrag na PassengerRole.

• - jednosmjernu vezu prema SpecificFlight

• - zove operacije c3 i c4

• c3 – (non_public), instanca od SpecificFlight stvara jednosmjernu vezu s instancom od Booking

• c4 – (non-public), instanca od PassengerRole stvara jednosmjernu vezu prema instanci od Booking (jer čeka da se sve stvori).

Odgovornost d), promjena destinacije veze

• Promjena postojećih aviona (objekata) airplane1 u airplane2 kao instanci iz razreda Airplane

• d1- (public), instanca od SpecificFlight

• briše vezu na airplane1
• ostvaruje jednosmjernu vezu na airplane2
• zove operaciju d2, a zatim operaciju d3.

• d2. - (non-public), airplane1

• briše jednosmjernu vezu do instance do SpecificFlight.

• d3 - (non-public) airplane2

• ostvaruje jednosmjernu vezu prema instanci od SpecificFlight.

Odgovornost e), pretraživanje skupa objekata

• Pretraživanje i pronalaženje po imenima članova posade za određeni objekt iz razreda SpecificFlight  

• e1 - (public), instanca od SpecificFlight

• kreira sekvencijski upit (tipa Iterator u Javi) koji iterira preko svih svojih veza tipa crewMember.
• za svaku od tih veza zove operaciju e2, dok se ne pronađe podudarnost.

• e2 - (može biti public), instanca od EmployeeRole vraća ime člana posade.

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.

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.