Opće karakteristike UML jezika. Vrste UML dijagrama Vrste uml dijagrama

Napomena: Predmet ovog tečaja je UML - Unified Modeling Language. U prethodnom predavanju govorilo se o tome što je UML, njegovoj povijesti, namjeni, načinima korištenja jezika, strukturi njegove definicije, terminologiji i notaciji. Uočeno je da je UML model skup dijagrama. U ovom predavanju razmotrit ćemo sljedeća pitanja: zašto je potrebno više vrsta dijagrama; vrste dijagrama; OOP i slijed dijagramiranja

Prije nego što prijeđemo na raspravu o glavnom materijalu ovog predavanja, razgovarajmo o tome zašto uopće trebamo graditi bilo kakve dijagrame. Razvoj modela bilo kojeg sustava (ne samo softvera) uvijek prethodi njegovoj izradi ili ažuriranju. To je potrebno barem kako bismo jasnije zamislili problem koji se rješava. Dobro osmišljeni modeli vrlo su važni kako za interakciju unutar razvojnog tima tako i za međusobno razumijevanje s kupcem. U konačnici, ovo osigurava da je dizajn "arhitektonski dosljedan" prije nego što se implementira u kod.

Gradimo modele složenih sustava jer ih ne možemo u potpunosti opisati, “baciti pogled na njih”. Stoga ističemo samo svojstva sustava koja su bitna za specifičan zadatak i gradimo njegov model koji prikazuje ta svojstva. Metoda objektno orijentirane analize omogućuje nam da na najadekvatniji način opišemo stvarne složene sustave. Ali kako se kompleksnost sustava povećava, javlja se potreba za dobrom tehnologijom modeliranja. Kao što smo već rekli u prethodnom predavanju, unificirani jezik modeliranja(Unified Modeling Language, UML), koji je grafički jezik za specifikaciju, vizualizaciju, projektiranje i dokumentiranje sustava. Pomoću UML-a možete razviti detaljan model sustava koji se stvara, odražavajući ne samo njegov koncept, već i specifične značajke njegove implementacije. Unutar UML modela sve ideje o sustavu bilježe se u obliku posebnih grafičkih struktura koje nazivamo dijagramima.

Bilješka. Razmotrit ćemo ne sve, već samo neke vrste dijagrama. Na primjer, komponentni dijagram nije obuhvaćen ovim predavanjem, koje je samo kratak pregled vrsta dijagrama. Broj tipova dijagrama za određeni model aplikacije nije ni na koji način ograničen. Za jednostavne aplikacije nema potrebe za izgradnjom dijagrama svih vrsta bez iznimke. Neki od njih mogu jednostavno nedostajati, a ta se činjenica neće smatrati pogreškom. Važno je razumjeti da dostupnost određenih vrsta dijagrama ovisi o specifičnostima pojedinog projekta. Informacije o drugim vrstama dijagrama (o kojima se ovdje ne govori) mogu se pronaći u UML standardu.

Zašto vam je potrebno nekoliko vrsta dijagrama

Prvo, definirajmo terminologiju. U uvodu ovog predavanja više puta smo koristili pojmove sustava, modela i dijagrama. Autor je uvjeren da svatko od nas intuitivno razumije značenje ovih pojmova, no da bi nam bilo potpuno jasno, pogledajmo ponovno rječnik i pročitajmo sljedeće:

Sustav- skup međusobno povezanih kontroliranih podsustava ujedinjenih zajedničkom svrhom rada.

Da, nije baš informativno. Što je onda podsustav? Da razjasnimo situaciju, okrenimo se klasicima:

Sustav odnosi se na skup podsustava organiziranih za postizanje određenog cilja i opisanih korištenjem skupa modela, po mogućnosti s različitih gledišta.

Pa, ne možete ništa učiniti, morat ćete potražiti definiciju podsustava. Tamo također piše da podsustav je skup elemenata od kojih neki određuju ponašanje drugih elemenata. Ian Sommerville objašnjava ovaj koncept na sljedeći način:

Podsustav je sustav čije funkcioniranje ne ovisi o uslugama drugih podsustava. Softverski sustav strukturiran je kao skup relativno neovisnih podsustava. Također su definirane interakcije između podsustava.

Također nije baš jasno, ali je bolje. Govoreći “ljudskim” jezikom, sustav se predstavlja kao skup jednostavnijih entiteta koji su relativno samodostatni. To se može usporediti s time kako u procesu razvoja programa gradimo grafičko sučelje od standardnih “kockica” - vizualnih komponenti ili kako je sam programski tekst također podijeljen na module koji sadrže potprograme, objedinjene funkcionalnošću, a oni mogu se ponovno koristiti u sljedećim programima.

Razumijemo koncept sustava. Tijekom procesa projektiranja, sustav se razmatra s različitih gledišta uz pomoć modela, čiji se različiti prikazi pojavljuju u obliku dijagrama. Opet, čitatelj može imati pitanja o značenju pojmova modeli I dijagrami. Mislimo da je to lijepa, ali ne baš jasna definicija modeli kao semantički zatvorena apstrakcija sustava Malo je vjerojatno da će razjasniti situaciju, pa ćemo pokušati objasniti "svojim riječima".

Model- ovo je određeni (materijalni ili ne) objekt koji prikazuje samo najznačajnije karakteristike sustava za dani zadatak. Makete su različite - materijalne i nematerijalne, umjetne i prirodne, dekorativne i matematičke...

Navedimo nekoliko primjera. Svima nama poznati plastični automobili s kojima smo se s takvim uzbuđenjem igrali u djetinjstvu nisu ništa drugo nego materijal umjetni ukrasni model pravog automobila. Naravno, takav “auto” nema motor, ne punimo mu rezervoar benzinom, mjenjač ne radi (dapače, mjenjača uopće nema), ali kao model ova igračka u potpunosti ispunjava svoje funkcije : daje djetetu predodžbu o automobilu, budući da prikazuje njegove karakteristične značajke kao što su prisutnost četiri kotača, karoserija, vrata, prozori, sposobnost vožnje itd.

U medicinskim istraživanjima, ispitivanja na životinjama često prethode kliničkim ispitivanjima na ljudima. U ovom slučaju, životinja djeluje kao materijal prirodan ljudski modeli.

Gore prikazana jednadžba također je model, ali je matematički model i opisuje kretanje materijalne točke pod utjecajem gravitacije.

Ostaje samo reći što je dijagram. Dijagram je grafički prikaz mnogih elemenata. Obično se prikazuje kao graf s vrhovima (entitetima) i rubovima (odnosima). Postoji mnogo primjera dijagrama. Ovo je blok dijagram koji nam je svima poznat iz školskih godina, dijagrami instalacije razne opreme koje možemo vidjeti u korisničkim uputama, te stablo datoteka i direktorija na disku koje možemo vidjeti pokretanjem naredbe stabla u Windows konzola, i još mnogo, mnogo drugog. U svakodnevnom životu dijagrami nas okružuju sa svih strana, jer lakše percipiramo crteže nego tekst...

Ali vratimo se dizajnu softvera (i više od toga). U ovoj industriji sa Dijagrami se mogu koristiti za vizualizaciju sustava iz različitih perspektiva. Jedan od dijagrama, na primjer, može opisati interakciju korisnika sa sustavom, drugi može opisati promjenu stanja sustava tijekom njegovog rada, treći može opisati interakciju elemenata sustava međusobno itd. Složeni sustav može i treba prikazati kao skup malih i gotovo neovisnih modela – dijagrama, a niti jedan od njih nije dovoljan da opiše sustav i dobije cjelovitu sliku o njemu, jer se svaki od njih fokusira na određeni aspekt funkcioniranja sustava i izražava različit razina apstrakcije. Drugim riječima, svaki model odgovara određenom, određenom gledištu na projektirani sustav.

Unatoč činjenici da smo u prethodnom paragrafu vrlo slobodno tretirali pojam modela, treba imati na umu da u kontekstu gornjih definicija nijedan pojedinačni dijagram nije model. Dijagrami su samo sredstvo za vizualizaciju modela, a ta se dva pojma moraju razlikovati. Samo skup dijagrama čini model sustava i opisuje ga najpotpunije, ali ne samo jedan dijagram izvučen iz konteksta.

Vrste grafikona

UML 1.5 definiran dvanaest vrsta grafikona, podijeljen u tri grupe:

• četiri vrste dijagrama predstavljaju statičku strukturu aplikacije;
• pet predstavlja bihevioralne aspekte sustava;
• tri predstavljaju fizičke aspekte rada sustava (implementacijski dijagrami).

Trenutna verzija UML-a 2.1 nije napravila previše promjena. Dijagrami su malo promijenjeni u izgledu (pojavili su se okviri i druga vizualna poboljšanja), notacija je malo poboljšana, a neki dijagrami su dobili nova imena.

Međutim, točan broj kanonski dijagrami za nas je to apsolutno nevažno, jer nećemo razmotriti sve, već samo neke - iz razloga što broj tipova dijagrama za određeni model određene aplikacije nije strogo fiksan. Za jednostavne primjene nema potrebe za izgradnjom svakog pojedinačnog dijagrama. Na primjer, za lokalnu aplikaciju nije potrebno izraditi dijagram postavljanja. Važno je razumjeti da popis dijagrama ovisi o specifičnostima projekta koji se razvija i određuje ga sam programer. Ako znatiželjni čitatelj još uvijek želi znati o svim UML dijagramima, uputit ćemo ga na UML standard (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Podsjetimo, svrha ovog tečaja nije opisati apsolutno sve mogućnosti UML-a, već samo predstaviti ovaj jezik i dati početnu ideju o ovoj tehnologiji.

Dakle, ukratko ćemo pogledati takve vrste dijagrama kao što su:

• dijagram slučaja uporabe;
• dijagram klasa;
• dijagram objekta;
• sekvencijski dijagram;
• dijagram interakcije;
• dijagram stanja;
• dijagram aktivnosti;
• dijagram postavljanja.

O nekima od ovih dijagrama ćemo detaljnije govoriti u narednim predavanjima. Za sada se nećemo usredotočiti na detalje, već ćemo si postaviti cilj naučiti čitatelja da barem vizualno razlikuje vrste dijagrama i da da početnu ideju o svrsi glavnih vrsta dijagrama. Dakle, počnimo.

Dijagram slučajeva uporabe

Svi (uključujući softverski) sustavi dizajnirani su uzimajući u obzir činjenicu da će ih tijekom rada koristiti ljudi i/ili komunicirati s drugim sustavima. Entiteti s kojima sustav komunicira tijekom svog rada nazivaju se glumci, a svaki akter očekuje da se sustav ponaša na strogo definiran, predvidljiv način. Pokušajmo dati strožu definiciju ektora. Da bismo to učinili, koristit ćemo prekrasan vizualni rječnik za UML Zicom Mentor:

Ector (glumac)- ovo je skup logički povezanih uloga koje se izvode u interakciji s prethodnicima ili entitetima (sustav, podsustav ili klasa). Glumac može biti osoba ili drugi sustav, podsustav ili klasa koji predstavlja nešto izvan entiteta.

Grafički, ektor je prikazan ili " čovječuljak“, slične onima koje smo crtali kao djeca, a prikazuju članove naše obitelji ili klasni simbol s odgovarajućim stereotipom, kao što je prikazano na slici. Oba oblika predstavljanja imaju isto značenje i mogu se koristiti u dijagramima. “Stereotipni” oblik se češće koristi za predstavljanje aktera sustava ili u slučajevima kada akter ima svojstva i ona se trebaju prikazati (slika 2.1).

Pažljivi čitatelj može se odmah upitati: zašto glumac a ne glumac? Slažemo se, riječ "ektor" malo je oštra za uši Rusa. Razlog zašto to kažemo je jednostavan - riječ ector izvedena je iz riječi akcijski, što prevedeno znači akcijski. Doslovni prijevod riječi “ector” je glumac- predugo i nezgodno za korištenje. Stoga ćemo i dalje ovako govoriti.

Riža. 2.1.

Isti je pažljivi čitatelj mogao primijetiti riječ "presedan" koja treperi kroz ektorovu definiciju. Što je? Ovo će nas pitanje još više zanimati ako se sjetimo o čemu sada govorimo dijagram slučaja uporabe. Tako,

Slučaj upotrebe- opis zasebnog aspekta ponašanja sustava sa stajališta korisnika (Butch).

Definicija je prilično jasna i sveobuhvatna, ali se njome može dodatno pojasniti Zicom Mentor"om:

Slučaj upotrebe- opis skupa sekvencijalnih događaja (uključujući opcije) koje izvodi sustav koji dovode do rezultata koje promatra akter. Slučaj upotrebe predstavlja ponašanje entiteta, opisujući interakciju između aktera i sustava. Slučaj upotrebe ne pokazuje "kako" se postiže određeni rezultat, samo "što" se postiže.

Presedani su označeni na vrlo jednostavan način - u obliku elipse, unutar koje je naznačeno njegovo ime. Slučajevi korištenja i akteri povezani su linijama. Često je figura nacrtana na jednom kraju linije. 2.3

formiranje općih zahtjeva za ponašanje projektiranog sustava;

razvoj konceptualnog modela sustava za njegovu naknadnu detaljizaciju;

priprema dokumentacije za interakciju s kupcima i korisnicima sustava.

Trenutno je UML standardna notacija za vizualno modeliranje softverskih sustava, usvojena od strane konzorcija Object Managing Group (OMG) u jesen 1997., a koju podržavaju mnogi objektno orijentirani CASE proizvodi.

UML standard nudi sljedeći skup dijagrama za modeliranje:

· dijagram slučaja uporabe – za modeliranje poslovnih procesa organizacije ili poduzeća i određivanje zahtjeva za informacijski sustav koji se kreira;

· dijagram klasa – za modeliranje statičke strukture klasa sustava i veza među njima;

· dijagrami ponašanja sustava;

· dijagrami interakcije;

· dijagrami sekvenci – za modeliranje procesa razmjene poruka između objekata unutar jednog slučaja uporabe;

· dijagram suradnje – za modeliranje procesa razmjene poruka između objekata unutar jednog slučaja uporabe;

· dijagram stanja – za modeliranje ponašanja objekata sustava tijekom prijelaza iz jednog stanja u drugo;

· dijagram aktivnosti – za modeliranje ponašanja sustava u okviru različitih slučajeva korištenja, odnosno aktivnosti modeliranja;

dijagrami implementacije:

· komponentni dijagrami – za modeliranje hijerarhije komponenti (podsustava) informacijskog sustava;

· dijagram postavljanja – za modeliranje fizičke arhitekture projektiranog informacijskog sustava.

Na sl. 1.1 predstavlja integrirani model informacijskog sustava, uključujući glavne dijagrame koji bi se trebali razviti u ovom kolegiju.

Riža. 1. Integrirani model informacijskog sustava u UML notaciji

4.2. Dijagram slučajeva uporabe

Slučaj upotrebe je niz radnji koje izvodi sustav kao odgovor na događaj koji je pokrenuo neki vanjski objekt (akter). Slučaj upotrebe opisuje tipičnu interakciju između korisnika i sustava. U najjednostavnijem slučaju, use case se određuje u procesu razgovora s korisnikom o funkcijama koje bi želio implementirati u ovaj informacijski sustav. U UML-u je slučaj upotrebe prikazan na sljedeći način:

sl.2. Slučaj upotrebe

Glumac je uloga koju korisnik ima u odnosu na sustav. Glumci predstavljaju uloge, a ne određene ljude ili nazive poslova. Iako su prikazani kao stilizirane ljudske figure u dijagramima slučajeva upotrebe, akter može biti i vanjski informacijski sustav koji treba neke informacije iz tog sustava. Glumci bi trebali biti prikazani na dijagramu samo ako stvarno trebaju neke slučajeve upotrebe. U UML-u, akteri su predstavljeni kao oblici:

sl.3. lik (glumac)

Glumci su podijeljeni u tri glavne vrste:

· korisnici;

· sustavi;

· drugi sustavi u interakciji s ovim;

Vrijeme postaje akter ako o njemu ovisi pokretanje bilo kakvih događaja u sustavu.

4.2.1. Odnosi između slučajeva uporabe i aktera

U UML-u, dijagrami slučajeva korištenja podržavaju nekoliko vrsta odnosa između elemenata dijagrama:

· komunikacija

uključivanje (uključiti),

· proširenje (proširiti),

· generalizacija.

komunikacijska veza je odnos između slučaja upotrebe i aktera. U UML-u, komunikacijski odnosi prikazani su pomoću jednosmjerne asocijacije (puna linija).

sl.4. Primjer komunikacijske veze

Omogući vezu koristi se u situacijama u kojima postoji neki dio ponašanja sustava koji se ponavlja u više od jednog slučaja upotrebe. Ove se veze obično koriste za modeliranje funkcije za višekratnu upotrebu.

Komunikacija proširenja koristi se za opisivanje promjena u normalnom ponašanju sustava. Omogućuje jednom slučaju upotrebe da koristi funkcionalnost drugog slučaja upotrebe kada je to potrebno.

sl.5. Primjer odnosa uključivanja i proširenja

Veza generalizacije pokazuje da nekoliko aktera ili klasa imaju zajednička svojstva.

sl.6. Primjer veze generalizacije

4.3.

Dijagrami interakcija opisati ponašanje skupina objekata u interakciji. Tipično, dijagram interakcije pokriva ponašanje objekata unutar samo jednog slučaja upotrebe. Takav dijagram prikazuje brojne objekte i poruke koje oni međusobno razmjenjuju.

Poruka je način na koji objekt pošiljatelj traži od objekta primatelja da izvede jednu od svojih operacija.

Informativna poruka je poruka koja pruža objektu primatelju neke informacije za ažuriranje njegovog stanja.

Poruka zahtjeva (upitna) je poruka koja zahtijeva izdavanje nekih informacija o objektu primatelja.

Imperativna poruka je poruka koja od objekta primatelja traži da izvrši neku radnju.

Postoje dvije vrste dijagrama interakcije: dijagrami sekvenci i dijagrami suradnje.

4.3.1. Dijagrami sekvenci

Dijagram slijeda odražava tok događaja koji se odvijaju unutar jednog slučaja upotrebe.

Svi akteri (akteri, klase ili objekti) uključeni u određeni scenarij (slučaj upotrebe) prikazani su na vrhu dijagrama. Strelice odgovaraju porukama koje se prenose između aktera i objekta ili između objekata za izvođenje potrebnih funkcija.

U dijagramu sekvenci, objekt je prikazan kao pravokutnik s isprekidanom okomitom linijom povučenom od njega. Ova linija se zove linija života objekta . Predstavlja fragment životnog ciklusa objekta u procesu interakcije.

Svaka poruka predstavljena je kao strelica između životnih linija dva objekta. Poruke se pojavljuju redoslijedom kojim se pojavljuju na stranici od vrha prema dolje. Svaka poruka je označena barem nazivom poruke. Ako želite, također možete dodati argumente i neke kontrolne informacije. Možete prikazati samodelegiranje - poruku koju objekt šalje sam sebi, sa strelicom poruke koja pokazuje na istu liniju života.

Riža. 7. Primjer sekvencijskog dijagrama

4.3.2. Dijagram suradnje

Dijagrami suradnje prikazati tijek događaja unutar određenog scenarija (upotreba). Poruke su poredane prema vremenu, iako se dijagrami suradnje više fokusiraju na veze između objekata. Dijagram suradnje predstavlja sve informacije koje su prisutne u dijagramu sekvenci, ali dijagram suradnje drugačije opisuje tok događaja. Olakšava razumijevanje veza koje postoje između objekata.

U dijagramu suradnje, baš kao i u dijagramu sekvenci, strelice predstavljaju poruke koje se razmjenjuju unutar određenog slučaja upotrebe. Njihov vremenski slijed označen je numeriranjem poruka.

Riža. 8. Primjer dijagrama suradnje

4.4. Dijagram klasa

4.4.1. Opće informacije

Dijagram klasa definira tipove klasa sustava i razne vrste statičkih veza koje postoje između njih. Dijagrami klasa također prikazuju atribute klasa, operacije klasa i ograničenja koja su nametnuta odnosima između klasa.

Dijagram klasa u jeziku UML je graf čiji su čvorovi elementi statičke strukture projekta (klase, sučelja), a lukovi su odnosi između čvorova (asocijacije, nasljeđivanje, ovisnosti).

Dijagram klasa prikazuje sljedeće elemente:

· Paket - skup elemenata modela koji su međusobno logički povezani;

· Klasa (klasa) - opis zajedničkih svojstava grupe sličnih objekata;

· Sučelje - apstraktna klasa koja specificira skup operacija koje objekt proizvoljne klase povezan s danim sučeljem pruža drugim objektima.

4.4.2. Klasa

Klasa je skupina entiteta (objekata) koji imaju slična svojstva, naime podatke i ponašanje. Pojedinačni predstavnik klase naziva se objekt klase ili jednostavno objekt.

Ponašanje objekta u UML-u odnosi se na bilo koja pravila za interakciju objekta s vanjskim svijetom i podacima samog objekta.

Na dijagramima je klasa prikazana kao pravokutnik s čvrstim rubom, podijeljen vodoravnim linijama u 3 dijela:

Gornji odjeljak (odjeljak naziva) sadrži naziv klase i druga opća svojstva (osobito stereotip).

Srednji dio sadrži popis atributa

Na dnu je popis operacija klase koje odražavaju njezino ponašanje (radnje koje izvodi klasa).

Nijedan odjeljak atributa i operacije možda neće biti prikazan (ili oboje odjednom). Za odjeljak koji nedostaje, ne morate nacrtati liniju razdvajanja ili na bilo koji način naznačiti prisutnost ili odsutnost elemenata u njemu.

Dodatni odjeljci, poput iznimaka, mogu se uvesti prema nahođenju specifične implementacije.

Riža. 9. Primjer dijagrama klasa

4.4.2.1.Klasni stereotipi

Klasni stereotipi su mehanizam za podjelu razreda u kategorije.

UML definira tri glavna klasna stereotipa:

Granica (granica);

Entitet (entitet);

Kontrolirati.

4.4.2.2.Granične klase

Granične klase su one klase koje se nalaze na granici sustava i cjelokupne okoline. To uključuje zaslone, izvješća, sučelja s hardverom (kao što su pisači ili skeneri) i sučelja s drugim sustavima.

Da biste pronašli granične klase, morate ispitati dijagrame slučajeva upotrebe. Svaka interakcija između aktera i slučaja upotrebe mora biti povezana s najmanje jednom graničnom klasom. Upravo ova klasa omogućuje akteru interakciju sa sustavom.

4.4.2.3.Klase entiteta

Klase entiteta sadrže pohranjene informacije. Imaju najveće značenje za korisnika, pa se u njihovim nazivima često koriste pojmovi iz predmetnog područja. Tipično, tablica se stvara u bazi podataka za svaku klasu entiteta.

4.4.2.4.Kontrolni razredi

Kontrolne klase odgovorne su za koordinaciju akcija drugih klasa. Tipično, svaki slučaj upotrebe ima jednu kontrolnu klasu koja kontrolira slijed događaja za taj slučaj upotrebe. Klasa upravitelja odgovorna je za koordinaciju, ali sama ne pruža nikakvu funkcionalnost budući da joj druge klase ne šalju mnogo poruka. Umjesto toga, on sam šalje mnoge poruke. Klasa menadžera jednostavno delegira odgovornost na druge klase, zbog čega se često naziva klasa menadžera.

Mogu postojati druge kontrolne klase u sustavu koje su zajedničke za višestruke slučajeve upotrebe. Na primjer, može postojati klasa SecurityManager (upravitelj sigurnosti) odgovorna za praćenje događaja povezanih sa sigurnošću. Klasa TransactionManager odgovorna je za koordinaciju poruka povezanih s transakcijama baze podataka. Mogu postojati drugi upravitelji koji će upravljati drugim elementima rada sustava, kao što je dijeljenje resursa, distribuirana obrada podataka ili rukovanje pogreškama.

Osim gore spomenutih stereotipa, možete stvoriti vlastiti.

4.4.2.5.Atributi

Atribut je element informacija povezan s klasom. Atributi pohranjuju enkapsulirane podatke klase.

Budući da su atributi sadržani unutar klase, skriveni su od drugih klasa. Zbog toga ćete možda morati navesti koje klase imaju pravo čitati i mijenjati atribute. Ovo se svojstvo naziva vidljivost atributa.

Atribut može imati četiri moguće vrijednosti za ovaj parametar:

Javno (opće, otvoreno). Ova vrijednost vidljivosti pretpostavlja da će atribut biti vidljiv svim drugim klasama. Svaka klasa može vidjeti ili promijeniti vrijednost atributa. Prema UML notaciji, zajedničkom atributu prethodi znak "+".

Privatno (zatvoreno, tajno). Odgovarajući atribut nije vidljiv niti jednoj drugoj klasi. Privatni atribut je prema UML notaciji označen znakom “–”.

Zaštićen (zaštićen). Ovaj je atribut dostupan samo samoj klasi i njezinim potomcima. UML oznaka za zaštićeni atribut je znak "#".

Paket ili Implementacija (paket). Pretpostavlja da se atribut dijeli, ali samo unutar opsega njegovog paketa. Ova vrsta vidljivosti nije označena nikakvom posebnom ikonom.

Uz pomoć zatvorenosti ili sigurnosti moguće je izbjeći situaciju u kojoj vrijednost atributa mijenjaju sve klase sustava. Umjesto toga, logika za promjenu atributa bit će sadržana u istoj klasi kao i sam atribut. Postavke vidljivosti koje postavite utjecat će na generirani kod.

4.4.2.6.Operacije

Operacije implementiraju ponašanje povezano s klasom. Operacija ima tri dijela: ime, parametre i vrstu povrata.

Parametri su argumenti koje operacija prima kao ulaz. Tip povrata odnosi se na rezultat operacije.

Dijagram klasa može prikazati i nazive operacija i nazive operacija zajedno s njihovim parametrima i tipom povrata. Kako bi se smanjilo opterećenje dijagrama, korisno je na nekima od njih prikazati samo nazive operacija, a na drugima njihov puni potpis.

U UML-u operacije imaju sljedeću notaciju:

Naziv operacije (argument: argument tip podataka, argument2:argument2 tip podataka,...): tip povrata

Postoje četiri različite vrste operacija koje treba razmotriti:

Operacije provedbe;

Upravljačke operacije;

Operacije pristupa;

Pomoćne operacije.

Operacije provedbe

Operacije implementatora implementiraju neke poslovne funkcije. Takve se operacije mogu pronaći ispitivanjem dijagrama interakcije. Ova vrsta dijagrama usredotočuje se na poslovne funkcije, a svaka se poruka u dijagramu vjerojatno može preslikati na aktivnost implementacije.

Svaka operacija implementacije mora biti lako sljediva do odgovarajućeg zahtjeva. To se postiže u različitim fazama simulacije. Aktivnost je izvedena iz poruke u dijagramu interakcije, poruke proizlaze iz detaljnog opisa tijeka događaja koji se kreira na temelju slučaja korištenja, a potonji se kreira na temelju zahtjeva. Mogućnost praćenja cijelog ovog lanca omogućuje vam da osigurate da je svaki zahtjev implementiran u kodu i da svaki dio koda implementira neki zahtjev.

Kontrolne operacije

Operacije upravitelja kontroliraju stvaranje i uništavanje objekata. Konstruktori i destruktori klasa spadaju u ovu kategoriju.

Operacije pristupa

Atributi su obično privatni ili zaštićeni. Međutim, druge klase ponekad moraju pregledati ili promijeniti svoje vrijednosti. U tu svrhu postoje operacije pristupa. Ovaj pristup omogućuje sigurnu kapsulaciju atributa unutar klase, štiteći ih od drugih klasa, ali i dalje dopuštajući kontrolirani pristup njima. Standardno je kreirati operacije Get i Set za svaki atribut klase.

Pomoćne operacije

Pomoćne operacije su one operacije klase koje su joj potrebne za obavljanje svojih odgovornosti, ali o kojima druge klase ne bi trebale ništa znati. Ovo su operacije privatne i zaštićene klase.

Da biste identificirali transakcije, slijedite ove korake:

1. Naučite sekvencijske dijagrame i kooperativne dijagrame. Većina poruka u ovim dijagramima su operacije implementacije. Reflektirajuće poruke bit će pomoćne operacije.

2. Razmotrite kontrolne operacije. Možda ćete morati dodati konstruktore i destruktore.

3. Razmotrite operacije pristupa. Za svaki atribut klase s kojim će druge klase morati raditi, trebate stvoriti operacije Get i Set.

4.4.2.7.Veze

Odnos predstavlja semantički odnos između klasa. Daje klasi mogućnost učenja o atributima, operacijama i odnosima druge klase. Drugim riječima, da bi jedna klasa poslala poruku drugoj u dijagramu sekvenci ili kooperativnom dijagramu, mora postojati odnos između njih.

Postoje četiri vrste odnosa koji se mogu uspostaviti između klasa: asocijacije, ovisnosti, agregacije i generalizacije.

Udruga Komunikacija

Asocijacija je semantička veza između klasa. Oni se crtaju na dijagramu klasa kao obična linija.

Riža. 10. Udruga komunikacija

Asocijacije mogu biti dvosmjerne, kao u primjeru, ili jednosmjerne. U UML-u, dvosmjerne asocijacije crtaju se kao jednostavna linija bez strelica ili sa strelicama na obje strane. Jednosmjerna asocijacija ima samo jednu strelicu koja pokazuje njen smjer.

Smjer asocijacije može se odrediti ispitivanjem dijagrama sekvenci i kooperativnih dijagrama. Ako sve poruke na njima šalje samo jedna klasa, a prima samo druga klasa, ali ne i obrnuto, postoji jednosmjerna komunikacija između tih klasa. Ako je barem jedna poruka poslana u suprotnom smjeru, povezivanje mora biti dvosmjerno.

Asocijacije mogu biti refleksne. Refleksivna asocijacija uključuje jednu instancu klase u interakciji s drugim instancama iste klase.

Ovisnost o komunikaciji

Odnosi ovisnosti također odražavaju odnose između klasa, ali uvijek su jednosmjerni i pokazuju da jedna klasa ovisi o definicijama napravljenim u drugoj. Na primjer, klasa A koristi metode klase B. Onda kada se klasa B promijeni, potrebno je izvršiti odgovarajuće promjene u klasi A.

Zavisnost je predstavljena točkastom linijom povučenom između dva elementa dijagrama, a za element usidren na kraju strelice kaže se da ovisi o elementu usidren na početku te strelice.

Riža. 11. Ovisnost o komunikaciji

Prilikom generiranja koda za te klase, neće im se dodavati novi atributi. Međutim, za podršku komunikaciji stvorit će se operatori specifični za jezik.

Komunikacijska agregacija

Agregacije su čvršći oblik udruživanja. Agregacija je veza između cjeline i njezinog dijela. Na primjer, možete imati klasu pod nazivom Auto, kao i klase kao što su Motor, Gume i klase za druge dijelove automobila. Kao rezultat toga, objekt klase Car sastojat će se od objekta klase Engine, četiri objekta Tire, itd. Agregacije se vizualiziraju kao linija s dijamantom u blizini klase, što je cijeli broj:

Riža. 11. Komunikacijska agregacija

Uz jednostavnu agregaciju, UML uvodi jaču vrstu agregacije koja se naziva kompozicija. Prema sastavu, predmet-dio može pripadati samo jednoj cjelini, a osim toga, u pravilu, životni ciklus dijelova podudara se s ciklusom cjeline: oni žive i umiru s njom. Svako brisanje cjeline odnosi se na njezine dijelove.

Ovo kaskadno brisanje često se smatra dijelom definicije agregacije, ali se uvijek podrazumijeva kada je višestrukost uloga 1..1; na primjer, ako je potrebno izbrisati Kupca, tada se ovo brisanje također mora primijeniti na Narudžbe (i, zauzvrat, na Linije narudžbi).

UML je jezik za grafičko modeliranje opće namjene za specifikaciju, vizualizaciju, projektiranje i dokumentiranje svih artefakata stvorenih tijekom razvoja softverskih sustava.

Postoji mnogo dobrih knjiga koje detaljno opisuju UML (ponekad čak vrlo detaljno), želio bih na jednom mjestu prikupiti osnovne pojmove o dijagramima, entitetima i vezama između njih za brzo prisjećanje, nešto poput lista za varanje.

Ovaj članak koristi materijale iz knjiga: Ivanov D. Yu., Novikov F. A. Jedinstveni jezik za modeliranje UML I Leonenkov. UML vodič.

Prvo odlučimo o uredniku. Pod Linuxom sam isprobao različite UML editore, najviše mi se svidio UMLet, iako je napisan u Javi, vrlo brzo se kreće i sadrži većinu predložaka entiteta. Tu je i ArgoUML, višeplatformski UML editor, također napisan u Javi, koji je funkcionalno bogat, ali dodatno usporava.

Zaustavio sam se na UMLet, instalirajte ga pod Arch Linux I Ubuntu:

# na Arch Linux yaourt -S umlet # na Ubuntu sudo apt-get install umlet

U UML-u se svi entiteti mogu podijeliti u sljedeće vrste:

• strukturalni;
• ponašanje;
• grupiranje;
• anotativni;

Postoje četiri glavne vrste odnosa koji se koriste u UML-u:

Ovisnost- označava da promjena u nezavisnom entitetu na neki način utječe na zavisni entitet. Grafički je odnos ovisnosti prikazan točkastom linijom sa strelicom usmjerenom od ovisnog entiteta prema nezavisnom.

Udruga- javlja se ako je jedan entitet izravno povezan s drugim (ili s drugima - asocijacija ne može biti samo binarna). Grafički, asocijacija je prikazana kao puna linija s raznim dodacima koji povezuju povezane entitete.

Generalizacija je odnos između dva entiteta, od kojih je jedan poseban (specijalizirani) slučaj drugog. Grafički se generalizacija prikazuje kao crta s trokutastom, neispunjenom strelicom na kraju, usmjerenom od posebnog (podrazreda) prema općem (nadrazredu).

Implementacije- Implementacijski odnos ukazuje da je jedan entitet implementacija drugog. Grafički, implementacija je prikazana kao isprekidana linija s trokutastom, neispunjenom strelicom na kraju, usmjerenom od entiteta koji provodi implementaciju prema entitetu koji se implementira.

U UML 2 definiran 13 vrste dijagrama. Prema standardima, svaki dijagram mora imati okvir s pravokutnikom (zakošeni donji desni kut) u gornjem lijevom kutu koji označava identifikator dijagrama (tag) i naslov.

Dijagrami za prikaz strukture sustava:

• Dijagram komponenti (oznaka komponenta);
• Dijagram postavljanja, oznaka raspoređivanje);
• Dijagram klasa (dijagram klasa, oznaka razreda);
• Dijagram objekta (oznaka objekt);
• Dijagram kompozitne strukture, oznaka razreda);

Dijagrami za prikaz ponašanja sustava:

• Dijagram sinkronizacije (dijagram interakcije, oznaka vrijeme);
• Dijagram aktivnosti (tag aktivnost);
• Dijagram sekvence, oznaka SD);
• Dijagram komunikacije (tag komunikacija);
• Dijagram stroja stanja, oznaka državni stroj);
• dijagram pregleda interakcije, oznaka interakcija);

Ističu se dijagrami:

• Dijagram slučaja upotrebe (dijagram slučaja upotrebe, oznaka slučaja upotrebe);
• Dijagram paketa (dijagram paketa, oznaka paket);

Dijagram korištenja

Dijagram korištenja(dijagram slučaja korištenja) je najopćenitiji prikaz funkcionalne namjene sustava.

Kada dijagram slučaja upotrebe smatrate modelom sustava, možete ga povezati s modelom crne kutije. Svaki slučaj upotrebe definira slijed radnji koje mora izvesti dizajnirani sustav kada komunicira s odgovarajućim akterom.

Dijagram upotrebe koristi dvije vrste osnovnih entiteta: slučajeve upotrebe i aktere, između kojih se uspostavljaju sljedeće osnovne vrste odnosa.

Odnos asocijacije- Ovaj odnos specificira koju specifičnu ulogu akter igra u interakciji s instancom slučaja upotrebe. Odnos asocijacije označen je punom crtom između aktera i slučaja upotrebe. Ovaj redak može imati dodatne simbole, kao što su naziv i višestrukost.

Relacija proširenja- definira odnos između instanci određenog slučaja upotrebe i općenitijeg slučaja upotrebe, čija se svojstva određuju na temelju načina na koji se te instance međusobno kombiniraju. Dakle, ako postoji relacija proširenja od slučaja upotrebe A do slučaja upotrebe B, to znači da se svojstva instance slučaja upotrebe B mogu proširiti zbog prisutnosti svojstava u proširenom slučaju upotrebe A.

Odnos proširenja između slučajeva upotrebe označen je isprekidanom linijom sa strelicom (opcija odnosa ovisnosti) usmjerenom od slučaja upotrebe koji je proširenje izvornog slučaja upotrebe.

Odnos generalizacije služi za označavanje činjenice da se neki slučaj upotrebe A može generalizirati na slučaj upotrebe B. U ovom slučaju, opcija A će biti specijalizacija opcije B. U ovom slučaju, B se naziva predak ili roditelj A, a opcija A je dijete opcije korištenja V.

Grafički je ovaj odnos predstavljen punom linijom sa strelicom u obliku otvorenog trokuta, što označava roditeljski slučaj upotrebe.

Odnos generalizacije između slučajeva upotrebe koristi se kada je potrebno primijetiti da podređeni slučajevi upotrebe imaju sve atribute i ponašanje nadređenih slučajeva upotrebe.

Odnos uključivanja između dva slučaja upotrebe označava da je određeno ponašanje za jedan slučaj upotrebe uključeno kao sastavna komponenta u nizu ponašanja drugog slučaja upotrebe.

Odnos uključivanja usmjeren od slučaja upotrebe A do slučaja upotrebe B ukazuje da svaka instanca slučaja upotrebe A uključuje funkcionalna svojstva navedena za slučaj upotrebe B.

Grafički je ovaj odnos označen isprekidanom linijom sa strelicom (varijanta odnosa ovisnosti) usmjerenom od osnovnog slučaja upotrebe prema uključenom.

Dijagram klasa

Dijagram klasa(dijagram klasa) je glavni način za opisivanje statičke strukture sustava.

Dijagram klasa koristi jednu glavnu vrstu entiteta: klase (uključujući brojne posebne slučajeve klasa: sučelja, primitivne tipove, klase asocijacija, itd.), između kojih su uspostavljene sljedeće glavne vrste odnosa: ovisnosti, asocijacije, generalizacije, implementacije.

Odnos ovisnosti općenito, označava neki semantički odnos između dva elementa modela ili dva skupa takvih elemenata, koji nije odnos asocijacije, generalizacije ili implementacije. Odnos ovisnosti koristi se u situaciji kada neka promjena jednog elementa modela može zahtijevati promjenu drugog elementa modela koji ovisi o njemu.

Odnos ovisnosti je grafički predstavljen točkastom linijom između odgovarajućih elemenata sa strelicom na jednom kraju, pri čemu strelica pokazuje od klase klijenta ovisnosti prema nezavisnoj ili izvornoj klasi.

Mogu postojati posebne ključne riječi (stereotipi) iznad strelice:

• "pristup" - služi za označavanje dostupnosti javnih atributa i operacija izvorne klase za klijentske klase;
• "bind" - klasa klijenta može koristiti neki predložak za svoju naknadnu parametrizaciju;
• "derive" - ​​atributi klase klijenta mogu se izračunati iz atributa izvorne klase;
• "uvoz" - javni atributi i operacije izvorne klase postaju dio klijentske klase, kao da su deklarirani izravno u njoj;
• "refine" - označava da klasa klijenta služi kao dorada izvorne klase iz povijesnih razloga kada se pojave dodatne informacije tijekom rada na projektu.

Odnos asocijacije odgovara prisutnosti nekog odnosa između klasa. Taj je odnos označen punom linijom s dodatnim posebnim simbolima koji karakteriziraju pojedinačna svojstva određene asocijacije. Dodatni posebni znakovi mogu biti naziv asocijacije, kao i nazivi i mnoštvo klasa uloga asocijacije. Naziv udruge je neobavezan element njezine oznake.

Odnos agregacije javlja između nekoliko klasa ako jedna od klasa predstavlja entitet koji uključuje druge entitete kao komponente. Koristi se za predstavljanje odnosa sustava tipa "dio-cjelina".

Omjer sastava je poseban slučaj agregacijske relacije. Ovaj odnos služi za isticanje posebnog oblika odnosa “dio-cjelina”, u kojem se sastavni dijelovi na neki način nalaze unutar cjeline. Specifičnost odnosa među njima leži u tome što dijelovi ne mogu djelovati izolirano od cjeline, tj. razaranjem cjeline uništavaju se svi njezini sastavni dijelovi.

Odnos generalizacije je odnos između općenitijeg elementa (roditelja ili pretka) i specifičnijeg ili specijaliziranog elementa (dijete ili potomak). Kada se primijeni na dijagram klasa, ovaj odnos opisuje hijerarhijsku strukturu klasa i nasljeđivanje njihovih svojstava i ponašanja. Ovo pretpostavlja da klasa potomak ima sva svojstva i ponašanje klase pretka, a također ima vlastita svojstva i ponašanje koje klasa pretka nema.

Dijagram stroja

Dijagram stroja(dijagram stanja stroja) ili dijagram stanja u UML-u 1 (dijagram grafikona stanja) je jedan od načina da se detaljno opiše ponašanje u UML-u. U biti, strojni dijagrami, kao što ime sugerira, su grafovi stanja i prijelaza konačnog stroja napunjenog mnogim dodatnim detaljima i detaljima.

Dijagram stanja opisuje proces promjene stanja samo jedne klase, točnije jedne instance određene klase, odnosno modelira sve moguće promjene stanja određenog objekta. U ovom slučaju, promjena stanja objekta može biti uzrokovana vanjskim utjecajima drugih objekata ili izvana. Dijagrami stanja koriste se za opisivanje reakcije objekta na takve vanjske utjecaje.

U automatskom dijagramu koristi se jedan glavni tip entiteta - stanja, i jedan tip odnosa - prijelazi, ali za oba su definirane mnoge varijante, posebni slučajevi i dodatne oznake. Automat predstavlja dinamičke aspekte modeliranog sustava u obliku usmjerenog grafa, čiji vrhovi odgovaraju stanjima, a lukovi prijelazima.

Početno stanje je poseban slučaj stanja koje ne sadrži nikakve unutarnje radnje (pseudostanje). Objekt je u ovom stanju prema zadanim postavkama u početno vrijeme. Služi za označavanje grafičkog područja na dijagramu stanja od kojeg počinje proces promjene stanja.

Konačna (konačna) stanje je poseban slučaj stanja koje također ne sadrži nikakva unutarnja djelovanja (pseudostanja). Objekt će biti u ovom stanju prema zadanim postavkama nakon što stroj završi svoju operaciju u konačnoj točki u vremenu.

Dijagram aktivnosti

Prilikom modeliranja ponašanja sustava koji se projektira ili analizira, postaje potrebno ne samo predstaviti proces mijenjanja njegovih stanja, već i detaljno opisati značajke algoritamske i logičke implementacije operacija koje izvodi sustav.

Dijagram aktivnosti(dijagram aktivnosti) je još jedan način opisivanja ponašanja koji vizualno nalikuje dobrom starom dijagramu toka algoritma. Koristi se za modeliranje procesa izvođenja operacija.

Glavna upotreba dijagrama aktivnosti je vizualizacija značajki implementacije klasnih operacija, kada je potrebno predstaviti algoritme za njihovu implementaciju.

Dijagram aktivnosti koristi jednu glavnu vrstu entiteta - radnju i jednu vrstu odnosa - prijelaze (prijenose kontrole). Također se koriste konstrukcije kao što su račvanja, spajanja, veze i grane. Preporuča se koristiti glagol s riječima objašnjenja kao naziv jednostavne radnje.

Dijagram slijeda

Dijagram slijeda(dijagram slijeda) je način opisivanja ponašanja sustava "koristeći primjere".

Zapravo, sekvencijski dijagram je zapis protokola određene sesije sustava (ili fragment takvog protokola). U objektno orijentiranom programiranju, najvažnija stvar u vremenu izvođenja je prijenos poruka između objekata koji komuniciraju. To je redoslijed slanja poruka koji je prikazan na ovom dijagramu, otuda i naziv.

Dijagram sekvenci koristi jednu osnovnu vrstu entiteta - instance klasifikatora koji međusobno djeluju (uglavnom klase, komponente i akteri) i jednu vrstu odnosa - veze duž kojih se razmjenjuju poruke.

Moguće vrste poruka (slika preuzeta sa larin.in):

Dijagram komunikacije

Dijagram komunikacije(komunikacijski dijagram) - način opisivanja ponašanja koji je semantički ekvivalentan dijagramu sekvenci. Zapravo, ovo je isti opis slijeda razmjene poruka međudjelujućih instanci klasifikatora, samo izražen drugim grafičkim sredstvima.

Dakle, u komunikacijskom dijagramu, kao iu dijagramu sekvenci, koristi se jedan glavni tip entiteta - instance međudjelovanja klasifikatora i jedan tip odnosa - veze. No, ovdje nije naglasak na vremenu, već na strukturi veza između pojedinih instanci.

Dijagram komponenti

Dijagram komponenti(komponentni dijagram) - prikazuje odnose između modula (logičkih ili fizičkih) koji čine modelirani sustav.

Glavna vrsta entiteta u dijagramu komponenti su same komponente, kao i sučelja kroz koja se specificiraju odnosi između komponenti. U dijagramu komponenti primjenjuju se sljedeći odnosi:

• implementacije između komponenti i sučelja (komponenta implementira sučelje);
• ovisnosti između komponenti i sučelja (komponenta koristi sučelje);

Dijagram postavljanja

Dijagram postavljanja(dijagram postavljanja), uz prikaz sastava i povezanosti elemenata sustava, pokazuje kako su oni fizički smješteni na računalnim resursima tijekom izvođenja.

Dijagram izgleda, u usporedbi s dijagramom komponenti, dodaje dvije vrste entiteta: artefakt, koji je implementacija komponente i čvora (može biti ili klasifikator koji opisuje vrstu čvora ili specifičnu instancu), i odnos asocijacije između čvorova, što pokazuje da su čvorovi fizički povezani tijekom izvođenja.

Dijagram objekta

Dijagram objekta(objektni dijagram) - je instanca dijagrama klasa.

Objektni dijagram koristi jednu glavnu vrstu entiteta: objekte (instance klasa), između kojih su naznačene specifične veze (najčešće instance asocijacija). Objektni dijagrami su pomoćne prirode - zapravo, to su primjeri (reklo bi se ispisi memorije) koji pokazuju koji su objekti dostupni i veze između njih u nekom određenom trenutku rada sustava.

Dijagram unutarnje strukture(kompozitni strukturni dijagram) služi za detaljniji prikaz strukturnih klasifikatora, prvenstveno klasa i komponenti.

Strukturni klasifikator prikazan je kao pravokutnik s imenom klasifikatora na vrhu. Ima dijelova unutra. Može biti nekoliko dijelova. Dijelovi mogu međusobno djelovati. To se pokazuje korištenjem konektora raznih vrsta. Mjesto na vanjskoj granici dijela na koji se spaja konektor naziva se ulaz. Priključci se također nalaze na vanjskoj granici strukturnog klasifikatora.

Dijagram pregleda interakcije Dijagram pregleda interakcije vrsta je dijagrama aktivnosti s proširenom sintaksom: elementi dijagrama pregleda interakcije mogu biti poveznice na interakcijske upotrebe definirane dijagramima sekvenci.

Vremenski dijagram

Vremenski dijagram Vremenski dijagram poseban je oblik sekvencijskog dijagrama koji se fokusira na promjenjiva stanja različitih instanci klasifikatora i njihovu vremensku sinkronizaciju.

Dijagram paketa

Dijagram paketa(dijagram paketa) jedini je alat koji vam omogućuje upravljanje složenošću samog modela.

Glavni elementi notacije su paketi i zavisnosti s različitim stereotipima.

Model entitet-odnos (ER model)

Analogno dijagrami klasa(UML) možda ER model, koji se koristi pri projektiranju baza podataka (relacijski model).

Model entiteta i odnosa (ER-model) je podatkovni model koji vam omogućuje opisivanje konceptualnih dijagrama predmetnog područja. ER model se koristi u (konceptualnom) dizajnu baze podataka visoke razine. Uz njegovu pomoć možete identificirati ključne entitete i identificirati veze koje se mogu uspostaviti između tih entiteta. wikipedija

Bilo koji fragment predmetnog područja može se prikazati kao skup entiteta, između kojih postoji niz veza.

Osnovni koncepti:

Esencija(entitet) je objekt koji se može identificirati na neki način koji ga razlikuje od drugih objekata, na primjer, KLIJENT 777. Entitet je zapravo skup atributa.

Skup entiteta(entity set) - skup entiteta iste vrste (imaju ista svojstva).

Veza(odnos) je asocijacija uspostavljena između nekoliko entiteta.

Domena(domena) - skup vrijednosti (domena definicije) atributa.

Postoje tri vrste binarnih veza:

• jedan na jedan- jedna instanca entiteta jedne klase povezana je s jednom instancom entiteta druge klase, npr. VODITELJ - ODJEL;
• 1 do N ili jedan prema mnogima- jedna instanca entiteta jedne klase povezana je s mnogo instanci entiteta druge klase, na primjer, ODJEL - ZAPOSLENI;
• N do M ili mnogi mnogima- mnoge instance entiteta jedne klase pridružene su mnogim instancama entiteta druge klase, na primjer, ZAPOSLENIK - PROJEKT;
Rječnik osnovnih pojmova u UML-u

Objekt- entitet koji je jedinstven i sažima stanje i ponašanje.

Klasa- opis skupa objekata sa zajedničkim atributima koji definiraju stanje i operacije koje definiraju ponašanje.

Sučelje- imenovani skup operacija koji definira skup usluga koje potrošač može zatražiti, a pružiti pružatelj usluga.

Suradnja- skup objekata koji međusobno djeluju kako bi postigli neki cilj.

Glumac- entitet koji se nalazi izvan modeliranog sustava iu izravnoj je interakciji s njim.

komponenta- modularni dio sustava s jasno definiranim skupom potrebnih i predviđenih sučelja.

Artefakt- element informacija koji se koristi ili generira tijekom procesa razvoja softvera. Drugim riječima, artefakt je fizička jedinica implementacije izvedena iz elementa modela (kao što je klasa ili komponenta).

Čvor- računalni resurs na kojem se artefakti nalaze i, ako je potrebno, izvršavaju.

Entiteti ponašanja namijenjeni su opisivanju ponašanja. Postoje samo dva glavna entiteta ponašanja: stanje i djelovanje.

država- razdoblje u životnom ciklusu objekta, tijekom kojeg objekt zadovoljava određeni uvjet i obavlja vlastite aktivnosti ili čeka nastanak nekog događaja.

Akcijski- primitivni atomski proračun.

Mašina je paket koji definira mnoge koncepte potrebne za predstavljanje ponašanja modeliranog entiteta u obliku diskretnog prostora s konačnim brojem stanja i prijelaza.

Klasifikator je deskriptor skupa objekata istog tipa.

Dodatna literatura

• Fowler M. UML. Osnove, 3. izdanje
• Buch G., Rambo D., Jacobson I. UML jezik. Korisnički vodič

UML je akronim koji označava Unified Modeling Language. Zapravo, to je jedna od najpopularnijih tehnika modeliranja poslovnih procesa i međunarodna je standardna oznaka za specifikaciju, vizualizaciju i dokumentiranje razvoja softvera. Definiran od strane Object Management Group, nastao je kao izdanak nekoliko dodatnih UML notacijskih sustava i sada je postao de facto standard za vizualno modeliranje. Temeljno načelo svakog objektno orijentiranog programiranja počinje izgradnjom modela.

UML je nastao kao rezultat kaosa oko razvoja softvera i dokumentacije. U 1990-ima postojalo je nekoliko različitih načina razmišljanja o softverskim sustavima. Postojala je potreba za jedinstvenijim vizualnim UML načinom predstavljanja ovih sustava, i kao rezultat toga, između 1994. i 1996. razvila su ga tri softverska inženjera koja su radila u Rational Software-u. Kasnije je usvojen kao standard 1997. godine i takav je ostao i danas, uz samo nekoliko ažuriranja.

U osnovi, UML je jezik za modeliranje opće namjene u području razvoja softvera. Međutim, sada je pronašao svoj put u dokumentaciju nekoliko poslovnih procesa ili radnih procesa, kao što su dijagrami aktivnosti. Vrsta UML dijagrama može se koristiti kao zamjena za dijagrame toka. Oni pružaju i standardiziraniji način modeliranja radnih procesa i širok raspon značajki za poboljšanje čitljivosti i učinkovitosti.

Arhitektura se temelji na meta-objektu, koji definira osnovu za stvaranje UML jezika. Dovoljno je precizan za izradu cijele aplikacije. Potpuno izvršni UML može se implementirati na više platformi koristeći različite tehnologije sa svim procesima tijekom ciklusa razvoja softvera.

UML je namijenjen da bude jezik za vizualno modeliranje koji razvijaju korisnici. Podržava razvojne koncepte visoke razine kao što su strukture, obrasci i suradnja. UML je skup elemenata kao što su:

1. Izjave programskog jezika.
2. Glumci - opisuju ulogu korisnika ili bilo kojeg drugog sustava u interakciji s objektom.
3. Radnje koje je potrebno izvršiti za ispunjenje ugovora o radu prikazane su dijagramima.
4. Poslovni proces koji uključuje skup zadataka koji stvaraju određenu uslugu za klijente, vizualiziran dijagramom toka uzastopnih radnji.
5. Logičke softverske komponente koje se mogu ponovno koristiti.

UML dijagrami spadaju u dvije kategorije. Prvi tip uključuje sedam tipova dijagrama koji predstavljaju strukturne informacije, drugi - preostalih sedam, koji predstavljaju opće tipove ponašanja. Ovi se dijagrami koriste za dokumentiranje arhitekture sustava i izravno su uključeni u UML modeliranje sustava.

UML dijagrami se prikazuju kao statički i dinamički prikazi modela sustava. Statički prikaz uključuje dijagrame klasa i sastava koji ističu statičku strukturu. Dinamički pogled predstavlja interakciju između objekata i promjene u unutarnjim stanjima objekata pomoću dijagrama slijeda, aktivnosti i stanja.

Dostupan je širok izbor UML alata za modeliranje koji pojednostavljuju modeliranje, uključujući IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner i Dia.

Upotreba UML-a ima različite vrste u dokumentaciji razvoja softvera iu poslovnim procesima:

1. Skica. U ovom slučaju, UML dijagrami se koriste za prenošenje različitih aspekata i karakteristika sustava. Međutim, ovo je samo pogled na najvišu razinu sustava i najvjerojatnije neće sadržavati sve potrebne detalje da se projekt dovrši do samog kraja.
2. Forward Design - Dizajn skice se radi prije nego što se aplikacija kodira. Ovo se radi kako bi se dobio bolji pregled sustava ili tijeka rada koji korisnik pokušava stvoriti. Mogu se identificirati mnogi projektni problemi ili nedostaci, što će poboljšati cjelokupno zdravlje i dobrobit projekta.
3. Obrnuti dizajn. Nakon što je kôd napisan, UML dijagrami se prikazuju kao oblik dokumentacije za različite aktivnosti, uloge, sudionike i tijekove rada.
4. Plan. U ovom slučaju dijagram služi kao cjeloviti dizajn koji zahtijeva samo stvarnu implementaciju sustava ili softvera. To se često radi pomoću alata CASE (Computer Aided Software Engineering Tools). Glavni nedostatak korištenja CASE alata je što zahtijevaju određenu razinu znanja, obuku korisnika, kao i menadžmenta i osoblja.

UML nije samostalni programski jezik poput Jave, C++ ili Pythona, ali s pravim alatima može postati pseudoprogramski jezik UML. Da bi se postigao ovaj cilj, cijeli sustav mora biti dokumentiran u različitim dijagramima, a pomoću odgovarajućeg softvera dijagrami se mogu izravno prevesti u kod. Ova metoda može biti korisna samo ako će vrijeme utrošeno na crtanje dijagrama trajati manje od pisanja stvarnog koda. Iako je UML stvoren za modeliranje sustava, našao je nekoliko primjena u poslovnim područjima.

Ispod je primjer UML dijagrama za poslovno modeliranje.

Jedno praktično rješenje bilo bi vizualno prikazati tijek procesa za teleprodaju kroz dijagram aktivnosti. Od trenutka kada je nalog uzet kao ulaz do trenutka kada je nalog dovršen i dan je određeni izlaz.

Postoji nekoliko vrsta UML dijagrama, a svaki od njih obavlja drugačiji zadatak, bilo da je razvijen prije implementacije ili nakon, kao dio dokumentacije. Dvije najšire kategorije, koje pokrivaju sve ostale vrste, su dijagram ponašanja i dijagram strukture. Kao što naziv sugerira, neki UML dijagrami pokušavaju analizirati i prikazati strukturu sustava ili procesa, dok drugi opisuju ponašanje sustava, njegovih sudionika i komponenti.

Različite vrste raščlanjene su na sljedeći način:

1. Ne koriste se svi od 14 različitih tipova UML dijagrama redovito pri dokumentiranju sustava i arhitektura.
2. Paretov princip također se primjenjuje na korištenje UML dijagrama.
3. Programeri koriste 20% grafikona 80% vremena.

Elementi koji se najčešće koriste u razvoju softvera su:

• dijagrami korištenja;
• dijagrami klasa;
• sekvence.

Dijagrami aktivnosti su najvažniji UML dijagrami za izradu modela poslovnih procesa. U razvoju softvera koriste se za opisivanje tijeka različitih aktivnosti. Mogu biti serijski ili paralelni. Oni opisuju predmete koji se koriste, konzumiraju ili proizvode u nekoj aktivnosti i odnose između različitih aktivnosti.

Sve navedeno važno je za modeliranje poslovnih procesa koji vode od jednog do drugog, jer su međusobno povezani s jasnim početkom i krajem. U poslovnom okruženju to se naziva i mapiranje poslovnih procesa. Glavni likovi su autor, urednik i izdavač. Primjer UML-a je sljedeći. Kada recenzent pogleda nacrt i odluči da je potrebno napraviti neke izmjene. Autor zatim revidira nacrt i ponovno ga vraća kako bi analizirao recenziju.

Dijagram korištenja

Kamen temeljac sustava - koristi se za analizu zahtjeva na razini sustava. Ovi zahtjevi su izraženi u različitim slučajevima upotrebe. Tri glavne komponente UML dijagrama su:

1. Funkcionalni - prikazani kao slučajevi upotrebe.
2. Glagol koji opisuje radnju.
3. Glumci - za interakciju sa sustavom. Uloga aktera može biti korisnik, organizacija ili vanjska aplikacija. Odnosi između sudionika prikazani su ravnim strelicama.

Na primjer, za grafikon upravljanja zalihama. U ovom slučaju postoji vlasnik, dobavljač, upravitelj, stručnjak za zalihe i inspektor zaliha. Okrugli spremnici predstavljaju akcije koje izvode glumci. Moguće radnje: kupnja i uplata dionica, provjera kvalitete zaliha, povrat zaliha ili distribucija.

Ova vrsta dijagrama je prikladna za prikazivanje dinamičkog ponašanja između sudionika u sustavu, pojednostavljujući njegovu prezentaciju bez odražavanja detalja implementacije.

Privremeni

UML vremenski dijagrami koriste se za predstavljanje odnosa objekata gdje je fokus ovisan o vremenu. Nije zanimljivo kako objekti međusobno djeluju ili se međusobno mijenjaju, ali korisnik želi zamisliti kako objekti i subjekti djeluju duž linearne vremenske osi.

Svaki pojedinačni sudionik predstavljen je kroz liniju života, koja je u biti linija koja oblikuje stupnjeve kako se pojedinačni sudionik pomiče s jednog stupnja na drugi. Fokus je na vremenskom trajanju događaja i promjenama koje se o njemu događaju.

Glavne komponente vremenskog dijagrama su:

1. Lifeline je pojedinačni član.
2. Vremenska crta stanja - jedan životni put može proći kroz različita stanja unutar procesa.
3. Ograničenje trajanja je ograničenje vremenskog intervala koje predstavlja trajanje potrebno za zadovoljenje ograničenja.
4. Vremensko ograničenje - ograničava vremenski interval tijekom kojeg sudionik nešto mora dovršiti.
5. Destruction Emergence - Pojava poruke koja uništava pojedinog sudionika i predstavlja kraj životnog ciklusa tog sudionika.

Horizontalni dijagrami, koji se nazivaju i dijagrami stanja, koriste se za opisivanje različitih stanja komponente unutar sustava. Prihvaća konačni format imena jer je dijagram u biti stroj koji opisuje višestruka stanja objekta i kako se on mijenja na temelju unutarnjih i vanjskih događaja.

Vrlo jednostavan dijagram stanja stroja bio bi poput partije šaha. Tipična šahovska partija sastoji se od poteza bijelih i poteza crnih. Bijeli ima prvi potez, čime započinje igru. Kraj partije može se dogoditi bez obzira pobijedi li bijeli ili crni. Igra može završiti utakmicom, prekidom ili remijem (različita stanja stroja). Grafikoni stanja koriste se uglavnom u unaprijednom i obrnutom UML dizajnu raznih sustava.

Uzastopno

Ova vrsta dijagrama je najvažniji UML dijagram ne samo u informatičkoj zajednici, već i kao model na razini dizajna za razvoj poslovnih aplikacija. Popularni su pri opisivanju poslovnih procesa zbog svoje vizualno samoočigledne prirode. Kao što naziv sugerira, dijagrami opisuju slijed poruka i interakcija koje se događaju između subjekata i objekata. Akteri ili objekti mogu biti aktivni samo kada je to potrebno ili kada drugi objekt želi komunicirati s njima. Sve komunikacije prikazane su kronološkim redom.

Za potpunije informacije, možete razmotriti primjer UML sekvencijskog dijagrama u nastavku.

Kao što primjer sugerira, strukturni dijagrami koriste se za prikaz strukture sustava. Točnije, jezik se koristi u razvoju softvera za predstavljanje arhitekture sustava i načina na koji su različite komponente međusobno povezane.

UML dijagram klasa najčešći je tip dijagrama za softversku dokumentaciju. Budući da se većina programa stvorenih danas još uvijek temelji na paradigmi objektno orijentiranog programiranja, korištenje dijagrama klasa za dokumentiranje softvera pokazalo se zdravim razumom. To je zato što se OOP temelji na UML klasama i odnosima između njih. Ukratko, dijagrami sadrže klase, zajedno s njihovim atributima, koji se također nazivaju podatkovnim poljima, i njihovim ponašanjem, koje se naziva funkcijama članicama.

Točnije, svaka klasa ima 3 polja: ime na vrhu, atribute odmah ispod imena, operacije/ponašanja na dnu. Odnos između različitih klasa (predstavljen spojnom linijom) čini dijagram klasa. Gornji primjer prikazuje osnovni dijagram klasa.

Predmeti

Kada se raspravlja o strukturnim dijagramima UML-a, potrebno je zadubiti se u koncepte računalne znanosti. U softverskom inženjeringu, klase se tretiraju kao apstraktni tipovi podataka, dok su objekti instance. Na primjer, ako postoji "Automobil", koji je opći apstraktni tip, tada će instanca klase "Automobil" biti "Audi".

UML objektni dijagrami pomažu programerima softvera provjeriti predstavlja li generirana apstraktna struktura održivu strukturu kada se implementira u praksi, to jest kada se objekti instanciraju. Neki programeri ovo smatraju sekundarnom razinom provjere točnosti. Prikazuje instance klasa. Točnije, generička klasa "Klijent" sada ima stvarnog klijenta, na primjer, pod nazivom "James". James je instanca općenitije klase i ima iste atribute, međutim, sa zadanim vrijednostima. Isto je učinjeno i s računom Računi i štednja. Oba su objekti svojih klasa.

Raspoređivanja

Dijagrami postavljanja koriste se za vizualizaciju odnosa između softvera i hardvera. Da budemo precizniji, pomoću dijagrama postavljanja možete izgraditi fizički model kako se softverske komponente (artefakti) postavljaju na hardverske komponente poznate kao čvorovi.

Tipična pojednostavljena shema postavljanja web aplikacije uključivala bi:

1. Čvorovi (aplikacijski poslužitelj i poslužitelj baze podataka).
2. Shema artefakata klijentske aplikacije i baze podataka.

Dijagram paketa sličan je kolekciji makronaredbi za UML dijagrame implementacije koje smo objasnili gore. Razni paketi sadrže čvorove i artefakte. Oni grupiraju dijagrame i komponente modela u skupine, slično kao što prostor imena sažima različita imena koja su donekle povezana. U konačnici, paket se također može nadograđivati ​​s nekoliko drugih paketa kako bi se predstavili složeniji sustavi i ponašanje.

Glavna svrha dijagrama paketa je pokazati odnose između različitih velikih komponenti koje čine složeni sustav. Programeri smatraju da je ova značajka apstrakcije dobra prednost pri korištenju dijagrama paketa, posebno kada su neki detalji možda isključeni iz velike slike.

Kao i svaka druga stvar u životu, da biste nešto učinili kako treba, potrebni su vam pravi alati. Alati koji nude UML komentare i predloške dijagrama koriste se za dokumentiranje softvera, procesa ili sustava. Postoje različiti alati za dokumentaciju softvera koji vam mogu pomoći u crtanju dijagrama.

Obično spadaju u sljedeće glavne kategorije:

1. Papir i olovka su jednostavni. Uzmite papir i olovku, otvorite UML sintaksni kod s Interneta i nacrtajte bilo koju vrstu dijagrama koja vam je potrebna.
2. Online alati - Postoji nekoliko online aplikacija koje možete koristiti za izradu grafikona. Većina ih nudi plaćenu pretplatu ili ograničen broj ljestvica u besplatnoj razini.
3. Besplatni online alati gotovo su isti kao oni koji se plaćaju. Glavna je razlika u tome što oni koji se plaćaju također nude upute i gotove predloške za određene dijagrame.
4. Aplikacija za stolna računala - tipična aplikacija za stolna računala koja se koristi za dijagrame i gotovo sve druge dijagrame je Microsoft Visio. Nudi napredne značajke i funkcionalnost. Jedina mana je da to morate platiti.

Stoga je sasvim očito da je UML važan aspekt povezan s objektno orijentiranim razvojem softvera. Koristi grafički zapis za stvaranje vizualnih modela sistemskih programa.

UML dijagram je specijalizirani jezik za grafički opis dizajniran za modeliranje objekata u razvoju različitog softvera. Jezik ima širok profil i otvoreni je standard koji koristi različite grafičke oznake za stvaranje apstraktnog modela sustava. UML je stvoren kako bi omogućio definiranje, vizualizaciju, dokumentaciju i dizajn svih vrsta softverskih sustava. Važno je napomenuti da sam UML dijagram nije programski jezik, ali pruža mogućnost generiranja zasebnog koda na temelju njega.

Zašto je to potrebno?

Korištenje UML-a ne završava modeliranjem svih vrsta softvera. Također, ovaj jezik se danas aktivno koristi za modeliranje različitih poslovnih procesa, provođenje dizajna sustava, ali i prikaz organizacijskih struktura.

Uz UML, programeri softvera mogu osigurati potpuni dogovor u grafičkoj notaciji koja se koristi za predstavljanje uobičajenih koncepata kao što su: komponenta, generičko, klasa, ponašanje i agregacija. Zbog toga se postiže veći stupanj koncentracije na arhitekturu i dizajn.

Također je vrijedno napomenuti da postoji nekoliko vrsta takvih karata.

Dijagram klasa

UML dijagram klasa statički je strukturni dijagram dizajniran za opisivanje strukture sustava, kao i za prikaz atributa, metoda i ovisnosti između nekoliko različitih klasa.

Vrijedno je napomenuti činjenicu da postoji nekoliko stajališta o konstrukciji takvih dijagrama, ovisno o tome kako će se koristiti:

• Konceptualni. U ovom slučaju UML dijagram klasa opisuje model specifičnog predmetnog područja, a pruža samo klase aplikacijskih objekata.
• Specifično. Dijagram se koristi u procesu projektiranja raznih informacijskih sustava.
• Provedba. Dijagram klasa uključuje sve vrste klasa koje se izravno koriste u programskom kodu.

Dijagram komponenti

UML komponentni dijagram je potpuno statičan strukturni dijagram. Namjera mu je demonstrirati raščlanjivanje određenog softverskog sustava na različite strukturne komponente, kao i veze među njima. UML komponentni dijagram može koristiti sve vrste modela, biblioteka, datoteka, paketa, izvršnih datoteka i mnoge druge elemente kao takve.

Dijagram kompozitne/kompozitne strukture

UML kompozitni/kompozitni strukturni dijagram također je statički strukturni dijagram, ali se koristi za prikaz unutarnje strukture klasa. Ako je moguće, ovaj dijagram također može pokazati interakciju elemenata koji se nalaze u unutarnjoj strukturi klase.

Njihova podvrsta je UML dijagram suradnje, koji se koristi za demonstraciju uloga, kao i interakcije različitih klasa unutar granica suradnje. Vrlo su prikladni ako trebate modelirati uzorke dizajna.

Vrijedno je napomenuti da se prikazi dijagrama UML klase i složene strukture mogu koristiti istovremeno.

Dijagram postavljanja

Ovaj se dijagram koristi za modeliranje pokrenutih čvorova, kao i svih vrsta artefakata koji su na njima raspoređeni. U UML 2, artefakti su raspoređeni na različite čvorove, dok su u prvoj verziji samo komponente bile raspoređene. Stoga se dijagram postavljanja UML-a prvenstveno koristi za drugu verziju.

Između artefakta i komponente koju implementira formira se manifestacijska ovisnost.

Dijagram objekta

Ovaj prikaz vam omogućuje da vidite punu ili djelomičnu snimku sustava koji se stvara u određenom trenutku. U potpunosti prikazuje sve instance klasa određenog sustava, navodeći trenutne vrijednosti njihovih parametara, kao i veze između njih.

Dijagram paketa

Ovaj dijagram je strukturne prirode, a njegov glavni sadržaj su sve vrste paketa, kao i odnosi između njih. U ovom slučaju ne postoji stroga podjela između nekoliko strukturnih dijagrama, zbog čega se njihova upotreba najčešće nalazi isključivo radi praktičnosti i ne nosi nikakvo semantičko značenje. Vrijedno je napomenuti da različiti elementi mogu dati druge UML dijagrame (primjeri: paketi i sami dijagrami paketa).

Njihova uporaba provodi se kako bi se osigurala organizacija nekoliko elemenata u skupine prema određenom kriteriju kako bi se pojednostavila struktura, kao i organizirao rad s modelom danog sustava.

Dijagram aktivnosti

UML dijagram aktivnosti prikazuje dekompoziciju određene aktivnosti u nekoliko sastavnih dijelova. U ovom slučaju, koncept "aktivnosti" je specifikacija određenog izvršnog ponašanja u obliku paralelnog, kao i koordiniranog sekvencijalnog izvršavanja različitih podređenih elemenata - ugniježđenih vrsta aktivnosti i različitih akcija, ujedinjenih tokovima koji idu od izlaza određenog čvora na ulaze drugog.

UML dijagrami aktivnosti često se koriste za modeliranje raznih poslovnih procesa, paralelnog i sekvencijalnog računalstva. Između ostalog, simuliraju sve vrste tehnoloških postupaka.

Dijagram stroja

Ovaj tip se naziva i malo drugačije - UML dijagram stanja. Ima prikazan konačni stroj s jednostavnim i složenim stanjima, kao i prijelazima.

Stroj stanja je specifikacija niza različitih stanja kroz koje određeni objekt, ili interakcija, prolazi kao odgovor na određene događaje u svom životu, kao i odgovor objekta na takve događaje. Stroj stanja koji koristi UML dijagram stanja pripojen je izvornom elementu i koristi se za definiranje ponašanja njegovih instanci.

Kao analozi takvih dijagrama mogu se koristiti takozvani zmajevi dijagrami.

Dijagrami slučajeva uporabe

UML dijagram slučajeva upotrebe prikazuje sve odnose koji se javljaju između aktera kao i različite slučajeve upotrebe. Njegova glavna zadaća je pružiti punopravno sredstvo putem kojeg korisnik, krajnji korisnik ili bilo koji programer može zajednički raspravljati o ponašanju i funkcionalnosti određenog sustava.

Ako se UML dijagram slučaja upotrebe koristi u procesu modeliranja sustava, tada će analitičar:

• Jasno odvojite sustav koji se modelira od njegove okoline.
• Identificirati aktere, načine njihove interakcije sa ovim sustavom, kao i njegovu očekivanu funkcionalnost.
• Postavite u pojmovnik kao predmetno područje različite pojmove koji se odnose na detaljan opis funkcionalnosti određenog sustava.

Ako se dijagram korištenja razvija u UML-u, postupak počinje tekstualnim opisom koji se dobiva tijekom rada s kupcem. Važno je napomenuti da su razni nefunkcionalni zahtjevi u potpunosti izostavljeni u procesu izrade modela slučaja uporabe te će se za njih generirati poseban dokument.

Komunikacije

Komunikacijski dijagram, baš kao i UML sekvencijski dijagram, je tranzitivan, odnosno izražava interakciju, ali je istovremeno i demonstrira na različite načine, te se po potrebi može konvertirati iz jednog u drugi sa potrebnim stupnjem točnosti. .

Komunikacijski dijagram odražava interakcije koje se javljaju između različitih elemenata kompozitne strukture, kao i uloge suradnje. Glavna razlika između njega i sekvencijskog dijagrama je u tome što čini odnose između nekoliko elemenata prilično eksplicitnim i ne koristi vrijeme kao zasebnu dimenziju.

Ovaj tip se razlikuje po potpuno slobodnom formatu za raspoređivanje nekoliko objekata i veza na isti način kao što je to učinjeno u dijagramu objekta. Ukoliko postoji potreba za održavanjem redoslijeda poruka u ovom slobodnom formatu, one se numeriraju kronološki. Čitanje ovog dijagrama počinje početnom porukom 1.0, a zatim se nastavlja u smjeru u kojem se poruke prenose s jednog objekta na drugi.

Ovi dijagrami većinom prikazuju potpuno iste informacije koje nam pruža dijagram sekvenci, ali budući da koristi drugačiji način predstavljanja informacija, određene stvari u jednom dijagramu postaje puno lakše prepoznati nego u drugom. Također je vrijedno napomenuti da komunikacijski dijagram jasnije pokazuje s kojim elementima svaki pojedini element stupa u interakciju, dok sekvencijski dijagram jasnije pokazuje kojim redoslijedom se interakcije događaju.

Dijagram slijeda

UML sekvencijski dijagram prikazuje interakcije između višestrukih objekata koji su poredani prema vremenu kada se pojavljuju. Ovaj dijagram prikazuje vremenski uređenu interakciju između nekoliko objekata. Konkretno, prikazuje sve objekte koji sudjeluju u interakciji, kao i cijeli slijed poruka koje se međusobno razmjenjuju.

Glavni elementi u ovom slučaju su oznake različitih objekata, kao i okomite linije koje prikazuju protok vremena i pravokutnici koji predstavljaju aktivnost određenog objekta ili obavljanje neke funkcije.

Dijagram suradnje

Ova vrsta dijagrama omogućuje vam demonstraciju interakcija između nekoliko objekata, apstrahirajući se od slijeda prijenosa poruka. Ova vrsta dijagrama u kompaktnom obliku prikazuje apsolutno sve poslane i primljene poruke određenog objekta, kao i formate tih poruka.

Budući da su sekvencijski i komunikacijski dijagrami jednostavno različiti prikazi istih postupaka, Rational Rose pruža mogućnost stvaranja komunikacijskog dijagrama iz sekvencijskog dijagrama ili obrnuto, te ih također potpuno automatski sinkronizira.

Dijagrami pregleda interakcija

Ovo su UML dijagrami koji su vrsta dijagrama aktivnosti i uključuju i elemente sekvence i konstrukcije tijeka kontrole.

Vrijedno je napomenuti činjenicu da ovaj format kombinira dijagram suradnje i slijeda, koji pružaju mogućnost razmatranja interakcije između nekoliko objekata u sustavu koji se formira s različitih gledišta.

Vremenski dijagram

Predstavlja alternativnu verziju sekvencijskog dijagrama koji eksplicitno pokazuje promjenu stanja duž linije života tijekom određene vremenske skale. Može biti vrlo koristan u raznim aplikacijama u stvarnom vremenu.

Koje su prednosti?

Vrijedno je napomenuti nekoliko prednosti koje razlikuju UML dijagram upotrebe od drugih:

• Jezik je objektno orijentiran, zbog čega su tehnologije za opisivanje rezultata analize i dizajna semantički bliske metodama programiranja u svim vrstama modernih objektno orijentiranih jezika.
• Koristeći ovaj jezik, sustav se može opisati s gotovo bilo koje moguće točke gledišta, a različiti aspekti njegovog ponašanja opisuju se na isti način.
• Svi dijagrami su relativno laki za čitanje čak i nakon relativno brzog uvoda u njihovu sintaksu.
• UML vam omogućuje proširenje i uvođenje vlastitih grafičkih i tekstualnih stereotipa, što promiče njegovu upotrebu ne samo u programskom inženjerstvu.
• Jezik je postao prilično raširen i također se prilično aktivno razvija.

Mane

Unatoč činjenici da konstruiranje UML dijagrama ima mnogo prednosti, često ih se kritizira zbog sljedećih nedostataka:

• Redundancija. U velikoj većini slučajeva kritičari kažu da je UML prevelik i složen, a to je često neopravdano. Uključuje dosta suvišnih ili praktički beskorisnih dizajna i dijagrama, a najčešće su takve kritike usmjerene na drugu verziju, a ne na prvu, jer novije revizije sadrže više kompromisa “designed by Committee”.
• Razne netočnosti u semantici. Budući da je UML definiran kombinacijom samog sebe, engleskog i OCL-a, on nema rigidnost koja je svojstvena jezicima koji su precizno definirani tehnikama formalnog opisa. U određenim situacijama, apstraktna sintaksa OCL-a, UML-a i engleskog počinje proturječiti jedna drugoj, dok su u drugim slučajevima nepotpune. Netočnost u specifikaciji samog jezika podjednako utječe i na korisnike i na dobavljače alata, što u konačnici dovodi do nekompatibilnosti alata zbog jedinstvenog načina na koji se tretiraju različite specifikacije.
• Problemi u procesu implementacije i proučavanja. Sva gore navedena pitanja stvaraju izazove u implementaciji i učenju UML-a, osobito kada menadžment prisiljava inženjere da ga koriste bez prethodnog znanja.
• Šifra odražava šifru. Drugi je stav da nisu važni lijepi i atraktivni modeli, nego sami sustavi koji rade, odnosno kod je projekt. Prema ovom stajalištu, postoji potreba za razvojem učinkovitijeg načina pisanja softvera. UML se obično cijeni u pristupima koji sastavljaju modele za ponovno generiranje izvršnog ili izvornog koda. Ali u stvarnosti to možda neće biti dovoljno jer jeziku nedostaju svojstva Turingove potpunosti, a svaki generirani kod će u konačnici biti ograničen na ono što alat za tumačenje UML-a može pogoditi ili odrediti.
• Neusklađenost opterećenja. Ovaj pojam dolazi iz teorije analize sustava za utvrđivanje nemogućnosti ulaza određenog sustava da percipira drugi izlaz. Kao i kod svake standardne notacije, UML može neke sustave predstaviti učinkovitije i konciznije od drugih. Stoga je programer skloniji onim rješenjima koja ugodnije isprepliću sve prednosti UML-a, ali i drugih programskih jezika. Ovaj problem je očitiji ako razvojni jezik nije u skladu s osnovnim principima objektno orijentirane ortodoksije, odnosno ne pokušava raditi u skladu s principima OOP-a.
• Pokušava biti univerzalan. UML je jezik za modeliranje opće namjene koji pokušava biti kompatibilan s bilo kojim jezikom za obradu koji je danas dostupan. U kontekstu određenog projekta, kako bi dizajnerski tim postigao konačni cilj, potrebno je odabrati primjenjiva svojstva tog jezika. Osim toga, mogući načini ograničavanja opsega UML-a u određenom području su kroz formalizam koji nije u potpunosti artikuliran i koji je sam podložan kritici.

Dakle, upotreba ovog jezika nije relevantna u svim situacijama.