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

Napomena: Predmet ovog kursa je UML - Unified Modeling Language. U prethodnom predavanju govorili smo o tome šta je UML, o njegovoj istoriji, nameni, načinima korišćenja jezika, strukturi njegove definicije, terminologiji i notaciji. Primećeno je da je UML model skup dijagrama. U ovom predavanju ćemo razmotriti pitanja: zašto nam je potrebno nekoliko tipova dijagrama; vrste dijagrama; OOP i dijagram sekvence

Prije nego što pređemo na raspravu o glavnom materijalu ovog predavanja, hajde da razgovaramo o tome zašto uopće graditi bilo kakve dijagrame. Razvoj modela bilo kog sistema (ne samo softvera) uvek prethodi njegovom kreiranju ili ažuriranju. Ovo je neophodno barem da bismo jasnije zamislili problem koji se rješava. Promišljeni modeli su veoma važni kako za interakciju unutar razvojnog tima, tako i za međusobno razumevanje sa kupcem. Na kraju krajeva, omogućava vam da se uverite da je projekat "arhitektonski konzistentan" pre nego što se implementira u kodu.

Mi gradimo modele složenih sistema jer ih ne možemo u potpunosti opisati, „pogledajte ih na prvi pogled“. Stoga izdvajamo samo svojstva sistema koja su bitna za određeni zadatak i gradimo njegov model koji odražava ta svojstva. Metoda objektno orijentisane analize omogućava da se realni složeni sistemi opisuju na najadekvatniji način. Ali kako sistemi postaju složeniji, postoji potreba za dobrom tehnologijom simulacije. Kao što smo rekli u prethodnom predavanju, kao takva „standardna“ tehnologija koristi se objedinjeni sistem. jezik modeliranja(Unified Modeling Language, UML), koji je grafički jezik za specifikaciju, vizualizaciju, dizajn i dokumentaciju sistema. Koristeći UML, možete razviti detaljan model sistema koji se kreira, koji odražava ne samo njegov koncept, već i specifične karakteristike implementacije. U okviru UML modela, sve reprezentacije o sistemu su fiksirane u obliku posebnih grafičkih struktura koje se nazivaju dijagrami.

Bilješka. Nećemo razmatrati sve, već samo neke od tipova grafikona. Na primjer, dijagram komponenti nije obrađen u ovom predavanju, što je samo kratak pregled tipova dijagrama. Broj tipova grafikona za određeni model aplikacije nije ni na koji način ograničen. Za jednostavne aplikacije, nema potrebe za izradom dijagrama svih tipova bez izuzetka. Neki od njih mogu jednostavno nedostajati i ova činjenica se neće smatrati greškom. Važno je shvatiti da dostupnost dijagrama određenog tipa ovisi o specifičnostima određenog projekta. Informacije o drugim (o kojima se ovdje ne govori) tipovima dijagrama mogu se naći u UML standardu.

Zašto vam treba više vrsta grafikona

Prvo, hajde da definišemo terminologiju. U predgovoru ovog predavanja više puta smo koristili koncepte sistema, modela i dijagrama. Autor je siguran da svako od nas intuitivno razumije značenje ovih pojmova, ali da bismo bili potpuno jasni, pogledajmo još jednom pojmovnik i pročitajmo sljedeće:

Sistem- skup međusobno povezanih kontrolisanih podsistema ujedinjenih zajedničkim ciljem funkcionisanja.

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

sistem nazivaju skup podsistema organizovanih za postizanje određenog cilja i opisanih pomoću skupa modela, moguće sa različitih gledišta.

Pa, ne možete ništa učiniti, morate tražiti definiciju podsistema. To takođe piše tamo podsistema je skup elemenata, od kojih neki specificiraju ponašanje drugih elemenata. Ian Sommerville objašnjava koncept na ovaj način:

Podsistem je sistem čije funkcionisanje ne zavisi od usluga drugih podsistema. Softverski sistem je strukturiran kao skup relativno nezavisnih podsistema. Interakcije između podsistema su također definirane.

Takođe nije baš jasno, ali bolje. Govoreći "ljudskim" jezikom, sistem je predstavljen kao skup jednostavnijih entiteta koji su relativno samodovoljni. To se može uporediti s tim kako u procesu razvoja programa gradimo grafičko sučelje od standardnih "kockica" - vizualnih komponenti, ili kako se sam programski tekst također dijeli na module koji sadrže potprograme koji su kombinovani prema funkcionalnom funkcije i mogu se ponovo koristiti u sljedećim programima.

Razumjeti koncept sistema. Tokom procesa projektovanja, sistem se razmatra sa različitih tačaka gledišta uz pomoć modela čiji se različiti prikazi pojavljuju u obliku dijagrama. Opet, čitalac 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 sistemska apstrakcija malo je vjerovatno da će razjasniti situaciju, pa hajde da pokušamo objasniti "svojim riječima".

Model- ovo je određeni (materijalni ili ne) objekat koji prikazuje samo najvažnije karakteristike sistema za ovaj zadatak. Modeli su različiti - materijalni i nematerijalni, veštački i prirodni, dekorativni i matematički...

Navedimo nekoliko primjera. Svima nama poznati plastični autići, kojima smo se s takvom strašću igrali u djetinjstvu, nisu ništa drugo do materijal umjetni ukrasni pravi model automobila. Naravno, u takvom "automobilu" nema motora, ne punimo njegov rezervoar benzinom, mjenjač u njemu ne radi (štaviše, uopće ga nema), ali kao model, ova igračka u potpunosti ispunjava svoje funkcije: daje djetetu predstavu o automobilu, jer pokazuje njegove karakteristične karakteristike su prisustvo četiri točka, karoserija, vrata, prozori, sposobnost vožnje itd.

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

Gore prikazana jednačina je također model, ali ovo je matematički model i opisuje kretanje materijalne točke pod djelovanjem gravitacije.

Ostaje samo reći šta je dijagram. Dijagram je grafički prikaz skupa elemenata. Obično se prikazuje kao graf sa vrhovima (entitetima) i ivicama (relacijama). Postoji mnogo primjera dijagrama. Ovo je blok dijagram koji nam je svima poznat iz školskih godina, i instalacijski dijagrami za razne opreme koje možemo vidjeti u korisničkim priručnicima, te stablo datoteka i direktorija na disku, koje možemo vidjeti pokretanjem komande tree u Windows konzola i još mnogo, mnogo više. U svakodnevnom životu dijagrami nas okružuju sa svih strana, jer sliku lakše percipiramo nego tekst...

Ali vratimo se dizajnu softvera (i ne samo). U ovoj industriji od koristeći dijagrame, možete vizualizirati sistem iz različitih uglova. Jedan od dijagrama, na primjer, može opisati interakciju korisnika sa sistemom, drugi - promjenu stanja sistema tokom njegovog rada, treći - interakciju između elemenata sistema, itd. Kompleks sistem se može i treba predstaviti kao skup malih i gotovo nezavisnih modela – dijagrama, a nijedan od njih nije dovoljan da opiše sistem i dobije potpunu sliku o njemu, jer se svaki od njih fokusira na neki određeni aspekt funkcionisanja sistema. sistema i izražava drugačije nivo apstrakcije. Drugim riječima, svaki model odgovara nekoj specifičnoj, posebnoj tački gledišta na sistem koji se dizajnira.

Uprkos činjenici da smo u prethodnom pasusu bili vrlo labavi s konceptom modela, treba shvatiti da u kontekstu gornjih definicija nijedan dijagram nije model. Dijagrami su samo sredstvo za vizualizaciju modela i treba ih razlikovati. Samo skup dijagrama čini model sistema i opisuje ga najpotpunije, ali ni jedan dijagram izvučen iz konteksta.

Vrste grafikona

Definiran UML 1.5 dvanaest vrsta grafikona podijeljeni u tri grupe:

• četiri tipa dijagrama predstavljaju statičku strukturu aplikacije;
• pet predstavljaju aspekte ponašanja sistema;
• tri predstavljaju fizičke aspekte rada sistema (dijagrami implementacije).

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

Međutim, tačan broj kanonski dijagrami za nas je apsolutno nevažno, budući da ih nećemo razmatrati sve, već samo neke - iz razloga što broj tipova dijagrama za određeni model određene aplikacije nije striktno fiksiran. Za jednostavne aplikacije, nema potrebe za izradom svih dijagrama bez izuzetka. Na primjer, za lokalnu aplikaciju nije potrebno graditi dijagram implementacije. Važno je razumjeti da lista dijagrama ovisi o specifičnostima projekta koji se razvija i da je određuje sam programer. Ako radoznali čitalac i dalje želi da zna o svim UML dijagramima, uputićemo ga na UML standard (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Podsjetimo, svrha ovog kursa nije da opiše apsolutno sve mogućnosti UML-a, već samo da predstavi ovaj jezik, da da početnu ideju o ovoj tehnologiji.

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

• dijagram slučaja upotrebe;
• dijagram klasa;
• dijagram objekta;
• dijagram sekvence;
• dijagram interakcije;
• dijagram stanja;
• dijagram aktivnosti;
• dijagram raspoređivanja.

O nekim od ovih dijagrama ćemo detaljnije govoriti u narednim predavanjima. Za sada se nećemo fokusirati na detalje, već smo si postavili cilj da naučimo čitatelja da barem vizualno razlikuje tipove dijagrama, kako bi dao početnu predstavu o svrsi glavnih tipova dijagrama. Dakle, počnimo.

Dijagram slučaja upotrebe

Bilo koji (uključujući softverski) sistem dizajniran je uzimajući u obzir činjenicu da će ih tokom svog rada koristiti ljudi i/ili komunicirati s drugim sistemima. Pozivaju se entiteti sa kojima sistem komunicira u toku svog rada glumci, a svaki akter očekuje da se sistem ponaša na striktno definisan, predvidljiv način. Pokušajmo dati rigorozniju definiciju ektora. Da bismo to učinili, koristimo prekrasan vizualni vokabular za UML Zicom Mentor:

Hektor (glumac)- ovo je skup logički povezanih uloga koje se obavljaju prilikom interakcije sa prethodnim ili entitetima (sistem, podsistem ili klasa). Akter može biti osoba ili drugi sistem, podsistem ili klasa koji predstavlja nešto izvan entiteta.

Grafički, vektor je prikazan ili " mali čovek“, slične onima koje smo crtali u djetinjstvu, prikazujući članove naše porodice, ili simbol klase sa odgovarajućim stereotipom, kao što je prikazano na slici. Oba oblika prezentacije imaju isto značenje i mogu se koristiti u dijagramima. „Stereotipni“ oblik se češće koristi za predstavljanje aktera sistema ili u slučajevima kada akter ima svojstva koja treba da budu prikazana (slika 2.1).

Pažljivi čitalac može odmah postaviti pitanje: Zašto je Hektor a ne glumac?? Slažemo se, reč "ektor" malo reže uho Rusu. Razlog zašto to kažemo je jednostavan - ektor se formira od riječi akcija, što u prevodu znači akcija. Doslovni prijevod riječi "ektor" - glumac- predugačak i neudoban za upotrebu. Stoga ćemo i dalje tako govoriti.

Rice. 2.1.

Isti pažljivi čitalac mogao je primijetiti da je riječ "presedan" bljesnula u definiciji ektora. Šta je? Ovo pitanje će nas još više zanimati ako se sjetimo o čemu sada govorimo dijagram slučaja upotrebe. dakle,

presedan (upotreba)- opis određenog aspekta ponašanja sistema iz ugla korisnika (Butch).

Definicija je sasvim razumljiva i iscrpna, ali se može dalje precizirati korištenjem iste Zicom Mentor"om:

slučaj upotrebe- opis skupa uzastopnih događaja (uključujući varijante) koje izvodi sistem, a koji dovode do rezultata koji akter posmatra. Slučaj upotrebe predstavlja ponašanje entiteta opisujući interakciju između aktera i sistema. Presedan ne pokazuje "kako" se postiže određeni rezultat, već samo "šta" jeste.

Presedani su naznačeni na vrlo jednostavan način - u obliku elipse, unutar koje je naznačeno njegovo ime. Slučajevi upotrebe i akteri povezani su linijama. Često se na jednom kraju linije prikazuje pirinač. 2.3

formiranje opštih zahteva za ponašanje sistema koji se projektuje;

razvoj konceptualnog modela sistema za njegovu naknadnu detaljizaciju;

priprema dokumentacije za interakciju sa korisnicima i korisnicima sistema.

UML je sada standardna notacija za vizuelno modeliranje softverskih sistema, usvojena od strane Object Managing Group (OMG) u jesen 1997. godine i podržana od strane mnogih objektno orijentisanih CASE proizvoda.

UML standard nudi sljedeći skup dijagrama za modeliranje:

Dijagram slučaja upotrebe (use case diagram) - za modeliranje poslovnih procesa organizacije ili preduzeća i određivanje zahtjeva za informacioni sistem koji se kreira;

dijagram klasa (dijagram klasa) - za modeliranje statičke strukture klasa sistema i odnosa između njih;

dijagram ponašanja sistema (dijagrami ponašanja);

interakcijski dijagrami;

Dijagrami sekvenci - za modeliranje procesa razmjene poruka između objekata unutar jednog slučaja upotrebe;

kolaboracioni dijagram (collaboration diagram) - za modeliranje procesa razmjene poruka između objekata unutar istog slučaja upotrebe;

dijagram stanja - za modeliranje ponašanja objekata sistema tokom prelaska iz jednog stanja u drugo;

dijagram aktivnosti - za modeliranje ponašanja sistema u okviru različitih slučajeva upotrebe, odnosno aktivnosti modeliranja;

dijagram implementacije (implementacijski dijagrami):

Dijagrami komponenti (komponentni dijagrami) - za modeliranje hijerarhije komponenti (podsistema) informacionog sistema;

dijagram implementacije (deployment diagram) - za modeliranje fizičke arhitekture projektovanog informacionog sistema.

Na sl. 1.1 predstavlja integrisani model informacionog sistema, uključujući glavne dijagrame koji će se razviti u ovom predmetnom projektu.

Rice. 1. Integrisani model informacionog sistema u notaciji UML jezika

4.2. Dijagram slučaja upotrebe

Slučaj upotrebe je niz radnji koje sistem izvodi kao odgovor na događaj koji je pokrenuo neki vanjski objekt (akter). Slučaj upotrebe opisuje tipičnu interakciju između korisnika i sistema. U najjednostavnijem slučaju, slučaj upotrebe se utvrđuje u procesu razgovora sa korisnikom o funkcijama koje bi on želio da implementira u ovaj informacioni sistem. U UML-u, slučaj upotrebe je prikazan na sljedeći način:

Fig.2. Slučaj upotrebe

Glumac je uloga koju korisnik igra u odnosu na sistem. Glumci predstavljaju uloge, a ne određene ljude ili poslove. Iako su prikazani kao stilizovane ljudske figure u dijagramima slučajeva upotrebe, akter može biti i eksterni informacioni sistem kojem su potrebne neke informacije iz sistema. Glumce biste trebali prikazati na dijagramu samo kada im zaista trebaju neki slučajevi upotrebe. U UML-u, akteri su predstavljeni kao oblici:

Fig.3. lik (glumac)

Glumci su podijeljeni u tri glavne vrste:

Korisnici

sistemi;

Drugi sistemi koji su u interakciji sa ovim;

Vrijeme postaje akter ako od njega zavisi pokretanje bilo kojeg događaja u sistemu.

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

U UML-u, dijagrami slučajeva upotrebe podržavaju nekoliko tipova odnosa između elemenata dijagrama:

Komunikacija (komunikacija),

Uključivanje (uključuje),

proširenje (produženje),

generalizacija.

komunikacija komunikacija je odnos između slučaja upotrebe i aktera. U UML-u, komunikacijske veze su prikazane korištenjem jednosmjerne asocijacije (puna linija).

Fig.4. Primjer komunikacijske veze

Inkluzivna veza koristi se u situacijama kada postoji neki dio ponašanja sistema koji se ponavlja u više od jednog slučaja upotrebe. Uz pomoć takvih veza obično se modelira funkcija za višekratnu upotrebu.

Produžna veza koristi se za opisivanje promjena u normalnom ponašanju sistema. Omogućuje jednom slučaju upotrebe da koristi funkcionalnost drugog slučaja kada je to potrebno.

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

Generalizacija komunikacije označava da nekoliko aktera ili klasa imaju zajednička svojstva.

Fig.6. Primjer odnosa generalizacije

4.3.

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

poruka je način na koji objekt pošiljalac traži od objekta primaoca da izvrši jednu od svojih operacija.

Informativna (informativna) poruka je poruka koja daje objektu koji prima neke informacije za ažuriranje njegovog stanja.

Poruka zahtjeva (upitna) je poruka koja traži izlaz nekih informacija o objektu primaoca.

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

Postoje dvije vrste dijagrama interakcije: dijagrami sekvence i dijagrami saradnje.

4.3.1. Dijagrami sekvenci

dijagram sekvence odražava tok događaja koji se dešavaju unutar jednog slučaja upotrebe.

Svi akteri (akteri, klase ili objekti) uključeni u dati scenario (slučaj upotrebe) prikazani su na vrhu dijagrama. Strelice odgovaraju porukama proslijeđenim između aktera i objekta, ili između objekata za obavljanje traženih funkcija.

U dijagramu sekvence, objekt je prikazan kao pravougaonik, iz kojeg je isprekidana vertikalna linija povučena prema dolje. Ova linija se zove životna linija objekta . To je fragment životnog ciklusa objekta u procesu interakcije.

Svaka poruka je predstavljena kao strelica između linija života dva objekta. Poruke se pojavljuju onim redom kojim se pojavljuju na stranici od vrha do dna. Svaka poruka je označena barem imenom poruke. Opciono, također možete dodati argumente i neke kontrolne informacije. Možete prikazati samodelegiranje, poruku koju objekt šalje samom sebi, sa strelicom poruke koja pokazuje na istu liniju spasavanja.

Rice. 7. Primjer dijagrama sekvence

4.3.2. Dijagram saradnje

Dijagrami saradnje prikazati tok događaja unutar određenog scenarija (slučaj upotrebe). Poruke su poredane po vremenu, iako se dijagrami saradnje više fokusiraju na odnose između objekata. Dijagram saradnje pokazuje sve informacije koje dijagram sekvence ima, ali dijagram saradnje opisuje tok događaja na drugačiji način. Iz njega je lakše razumjeti veze koje postoje između objekata.

U dijagramu saradnje, kao iu dijagramu sekvence, strelice predstavljaju poruke koje se razmjenjuju unutar datog slučaja upotrebe. Njihov vremenski redosled je označen numerisanjem poruka.

Rice. 8. Primjer dijagrama saradnje

4.4. dijagram klasa

4.4.1. Opće informacije

dijagram klasa definira tipove sistemskih klasa i razne vrste statičkih veza koje postoje između njih. Dijagrami klasa također pokazuju atribute klase, operacije klasa i ograničenja koja se postavljaju na odnose između klasa.

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

Dijagram klasa prikazuje sljedeće elemente:

· Paket (paket) - skup elemenata modela, logički povezanih jedan s drugim;

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

· Interfejs (interfejs) - apstraktna klasa koja specificira skup operacija koje objekt proizvoljne klase pridružene datom interfejsu pruža drugim objektima.

4.4.2. Klasa

Klasa je grupa entiteta (objekata) koji imaju slična svojstva, odnosno podatke i ponašanje. Pojedinačni član klase naziva se objektom klase ili jednostavno objektom.

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

Na dijagramima, klasa je prikazana kao pravougaonik sa čvrstim rubom, podijeljen horizontalnim linijama u 3 dijela:

Gornji odeljak (sekcija imena) sadrži naziv klase i druga opšta svojstva (posebno stereotip).

Srednji dio sadrži listu atributa

Na dnu je lista operacija klase koje odražavaju njeno ponašanje (akcije koje obavlja klasa).

Nijedan od odjeljaka atributa i operacija možda neće biti prikazan (ili oboje). Za dio koji nedostaje, ne morate nacrtati liniju razdvajanja i nekako naznačiti prisustvo ili odsustvo elemenata u njemu.

Dodatni odjeljci, kao što su izuzeci, mogu se uvesti prema nahođenju određene implementacije.

Rice. 9. Primjer dijagrama klasa

4.4.2.1.Klasni stereotipi

Klasni stereotip je mehanizam za klasifikaciju klasa u kategorije.

UML definira tri glavna stereotipa klase:

Granica (granica);

Entitet (entitet);

Kontrola (upravljanje).

4.4.2.2.Granične klase

Granične klase su one klase koje se nalaze na granici sistema i čitavog okruženja. To su displeji, izveštaji, interfejsi sa hardverom (kao što su štampači ili skeneri) i interfejsi sa drugim sistemima.

Da biste pronašli granične klase, morate istražiti dijagrame slučajeva upotrebe. Svaka interakcija između aktera i slučaja upotrebe mora imati barem jednu graničnu klasu. Upravo ova klasa omogućava glumcu interakciju sa sistemom.

4.4.2.3.Entitetske klase

Klase entiteta sadrže pohranjene informacije. Oni imaju najveće značenje za korisnika, pa se u njihovim nazivima često koriste termini iz predmetne oblasti. Obično se za svaku klasu entiteta kreira tabela u bazi podataka.

4.4.2.4.Kontrolne klase

Kontrolne klase su odgovorne 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. Kontrolna klasa je odgovorna za koordinaciju, ali sama po sebi ne nosi nikakvu funkcionalnost, jer joj druge klase ne šalju veliki broj poruka. Umjesto toga, on sam šalje mnogo poruka. Klasa menadžera jednostavno delegira odgovornost drugim klasama, zbog čega se često naziva klasom menadžera.

Mogu postojati i druge kontrolne klase u sistemu koje su zajedničke za nekoliko slučajeva upotrebe. Na primjer, može postojati klasa SecurityManager odgovorna za praćenje događaja vezanih za sigurnost. Klasa TransactionManager upravlja koordinacijom poruka koje se odnose na transakcije baze podataka. Možda postoje i drugi menadžeri koji se bave drugim elementima rada sistema, kao što su dijeljenje resursa, distribuirana obrada podataka ili rukovanje greškama.

Pored gore navedenih stereotipa, možete kreirati i svoje.

4.4.2.5.Atributi

Atribut je dio informacije povezan s klasom. Atributi pohranjuju inkapsulirane podatke klase.

Budući da su atributi sadržani unutar klase, oni su skriveni od drugih klasa. Zbog toga će možda biti potrebno specificirati koje klase imaju pravo čitanja i mijenjanja atributa. Ovo svojstvo se 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 ostalim klasama. Bilo koja klasa može vidjeti ili promijeniti vrijednost atributa. U skladu sa UML notacijom, uobičajenom atributu prethodi znak "+".

Privatno (zatvoreno, tajno). Odgovarajući atribut nije vidljiv nijednoj drugoj klasi. Privatni atribut je označen znakom "-" u skladu sa UML notacijom.

Zaštićen (zaštićen). Takav atribut je dostupan samo samoj klasi i njenim potomcima. UML notacija za zaštićeni atribut je znak "#".

Paket ili implementacija (serija). Pretpostavimo da je dati atribut zajednički, ali samo unutar svog paketa. Ova vrsta vidljivosti nije označena nikakvom posebnom ikonom.

Uz pomoć zatvorenosti ili sigurnosti moguće je izbjeći situaciju da se vrijednost atributa mijenja od strane svih klasa sistema. Umjesto toga, logika modifikacije atributa bit će umotana u istu klasu kao i sam atribut. Opcije vidljivosti koje postavite će uticati na generisani kod.

4.4.2.6.Operacije

Operacije implementiraju ponašanje vezano za klase. Operacija ima tri dijela - ime, parametre i tip povratka.

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

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

U UML-u operacije imaju sljedeću notaciju:

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

Postoje četiri različite vrste operacija koje treba uzeti u obzir:

Operacije implementacije;

Operacije upravljanja;

Operacije pristupa;

Pomoćne operacije.

Operacije implementacije

Operacije implementatora implementiraju neke poslovne funkcije. Takve operacije se mogu pronaći ispitivanjem dijagrama interakcije. Dijagrami ovog tipa fokusiraju se na poslovne funkcije, a svaka poruka u dijagramu najvjerovatnije može biti povezana s operacijom implementacije.

Svaka operacija implementacije mora se lako pratiti do odgovarajućeg zahtjeva. Ovo se postiže u različitim fazama simulacije. Operacija je izvedena iz poruke u dijagramu interakcije, poruke su izvedene iz detaljnog opisa toka događaja, koji se generiše na osnovu slučaja upotrebe, a ovaj drugi na osnovu zahteva. Mogućnost praćenja cijelog ovog lanca pomaže da se osigura da je svaki zahtjev implementiran u kodu, a svaki dio koda implementira zahtjev.

Operacije upravljanja

Operacije menadžera upravljaju kreiranjem i uništavanjem 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 vidjeti ili promijeniti svoje vrijednosti. Za ovo postoje operacije pristupa. Ovaj pristup omogućava sigurno enkapsuliranje atributa unutar klase, štiteći ih od drugih klasa, ali i dalje dozvoljavajući im kontroliran pristup. Kreiranje Get i Set operacija (dobivanje i promjena vrijednosti) za svaki atribut klase je standard.

Pomoćne operacije

Pomoćne (pomoćne operacije) su one operacije klase koje su joj potrebne da ispuni svoje 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, učinite sljedeće:

1. Proučite dijagrame sekvence i kooperativne dijagrame. Većina poruka u ovim dijagramima su operacije implementacije. Reflektivne poruke će biti pomoćne operacije.

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

3. Razmotrite operacije pristupa. Za svaki atribut klase sa kojim će druge klase morati da rade, morate kreirati operacije Get i Set.

4.4.2.7.Veze

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

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

Komunikacijsko udruženje

Asocijacija je semantički odnos između klasa. Oni su nacrtani na dijagramu klasa kao obična linija.

Rice. 10. Komunikacijsko udruženje

Asocijacije mogu biti dvosmjerne, kao u primjeru, ili jednosmjerne. U UML-u, dvosmjerne asocijacije su nacrtane kao jednostavna linija bez strelica ili sa strelicama na obje strane linije. Jednosmjerna asocijacija ima samo jednu strelicu koja pokazuje 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 ovih klasa. Ako je barem jedna poruka poslana u suprotnom smjeru, asocijacija mora biti dvosmjerna.

Asocijacije mogu biti refleksivne. Refleksna asocijacija znači da jedna instanca klase stupa u interakciju s drugim instancama iste klase.

Ovisnost o komunikaciji

Odnosi zavisnosti takođe odražavaju odnos između klasa, ali su uvek jednosmerni i pokazuju da jedna klasa zavisi od definicija u drugoj. Na primjer, klasa A koristi metode klase B. Zatim, kada se promijeni klasa B, potrebno je izvršiti odgovarajuće promjene u klasi A.

Zavisnost je predstavljena isprekidanom linijom povučenom između dva elementa dijagrama, a za element koji je usidren na kraju strelice kaže se da zavisi od elementa koji je usidren na početku te strelice.

Rice. 11. Ovisnost o komunikaciji

Prilikom generiranja koda za ove klase, neće im se dodati novi atributi. Međutim, bit će kreirani operatori specifični za jezik koji su potrebni za podršku komunikacije.

Agregacija komunikacija

Agregacije su čvršći oblik udruživanja. Agregacija je veza između cjeline i njenog dijela. Na primjer, možete imati klasu automobila, kao i klase motora, guma i klase za druge automobilske dijelove. Kao rezultat toga, objekat klase Car će se sastojati od objekta klase Engine, četiri objekta Tires, itd. Agregacije se vizualiziraju kao linija s rombom za klasu koja je cijeli broj:

Rice. 11. Agregacija komunikacija

Pored jednostavnog agregiranja, UML uvodi jači oblik agregacije koji se zove kompozicija. Prema kompoziciji, predmet-dio može pripadati samo jednoj cjelini, a po pravilu se životni ciklus dijelova poklapa sa ciklusom cjeline: oni žive i umiru s njim. Svako uklanjanje cjeline proteže se na njene dijelove.

Ovo kaskadno brisanje se često smatra dijelom definicije agregacije, ali se uvijek podrazumijeva kada je višestrukost uloga 1..1; na primjer, ako kupca treba izbrisati, tada se to brisanje mora prenijeti na narudžbe (i, zauzvrat, na redove naloga).

UML je jezik za grafičko modeliranje opšte namene za specifikaciju, vizualizaciju, dizajn i dokumentaciju svih artefakata stvorenih u razvoju softverskih sistema.

Postoje mnoge dobre knjige koje detaljno opisuju UML (ponekad čak i vrlo detaljno), želio bih na jednom mjestu sakupiti osnovne koncepte o dijagramima, entitetima i odnosima između njih radi brzog prisjećanja, nešto kao cheat sheet.

Bilješka koristi materijale iz knjiga: Ivanov D. Yu., Novikov F. A. Unified modeling language UML i Leonenkov. UML Tutorial.

Počnimo od urednika. Pod Linuxom sam isprobao različite UML editore, najviše mi se dopao UMLet, iako je napisan na Javi, kreće se vrlo brzo i većina praznina entiteta je u njemu. Tu je i ArgoUML, multi-platformski UML uređivač, također napisan na Javi, funkcionalno bogat, ali više usporava.

Zaustavio sam se UMLet, instalirajte ispod Arch Linux i ubuntu:

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

U UML-u se svi entiteti mogu raščlaniti na sljedeće tipove:

• strukturalni;
• ponašanja;
• grupisanje;
• annotational;

UML koristi četiri glavna tipa odnosa:

Zavisnost- ukazuje da promjena nezavisnog entiteta na neki način utiče na zavisni entitet. Grafički, odnos zavisnosti je prikazan kao isprekidana linija sa strelicom koja pokazuje od zavisnog entiteta do nezavisnog entiteta.

Udruženje- odvija se ako je jedan entitet direktno povezan sa drugim (ili sa drugima - asocijacija može biti ne samo binarna). Grafički, asocijacija je prikazana kao puna linija sa raznim dodacima koji povezuju povezane entitete.

Generalizacija je odnos između dva entiteta, od kojih je jedan poseban (specijalizirani) slučaj drugog. Grafički, generalizacija je prikazana kao linija sa trouglastom nepopunjenom strelicom na kraju, usmjerena od posebnog (podklase) ka općem (superklasa).

Implementacije- relacija implementacije ukazuje da je jedan entitet implementacija drugog. Grafički, implementacija je prikazana kao isprekidana linija sa trouglastom nepopunjenom strelicom na kraju, usmjerenom od implementacionog entiteta ka implementiranom.

AT UML 2 definisano 13 vrste grafikona. Po standardima, svaki grafikon treba da ima okvir sa pravougaonikom (donji desni ugao zakošen) u gornjem levom uglu, koji označava ID (oznaku) grafikona i naslov.

Dijagrami koji prikazuju strukturu sistema:

• Dijagram komponenti (dijagram komponenti, oznaka komponenta);
• Dijagram implementacije (dijagram implementacije, oznaka raspoređivanje);
• Dijagram klasa (dijagram klasa, oznaka klasa);
• Dijagram objekta (dijagram objekta, oznaka objekt);
• Dijagram unutrašnje strukture (kompozitni strukturni dijagram, oznaka klasa);

Dijagrami koji prikazuju ponašanje sistema:

• Dijagram sinhronizacije (dijagram interakcije, oznaka tajming);
• Dijagram aktivnosti (dijagram aktivnosti, oznaka aktivnost);
• dijagram sekvence (dijagram sekvence, oznaka sd);
• Komunikacijski dijagram (komunikacijski dijagram, oznaka comm);
• Dijagram automata (dijagram državnog stroja, oznaka državna mašina);
• Dijagram pregleda interakcije, oznaka interakcija);

Na grafikonima se ističu:

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

Dijagram upotrebe

Dijagram upotrebe(dijagram slučaja upotrebe) je najopštiji prikaz funkcionalne svrhe sistema.

Uzimajući u obzir dijagram slučaja upotrebe kao model sistema, možemo ga povezati sa modelom crne kutije. Svaki slučaj upotrebe definira niz radnji koje mora izvršiti dizajnirani sistem kada je u interakciji s odgovarajućim akterom.

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

odnos asocijacije- Ovaj odnos utvrđuje koju specifičnu ulogu akter igra u interakciji sa instancom slučaja upotrebe. Odnos asocijacije je označen čvrstom linijom između aktera i slučaja upotrebe. Ova linija može imati dodatne simbole, kao što su, na primjer, ime i višestrukost.

Relacija ekstenzije- definiše odnos instanci jednog slučaja upotrebe sa opštijim slučajem upotrebe, čija se svojstva određuju na osnovu načina na koji su te instance kombinovane zajedno. Dakle, ako postoji odnos proširenja od slučaja upotrebe A do slučaja upotrebe B, onda to znači da se svojstva instance slučaja upotrebe B mogu dopuniti 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 (slučaj odnosa zavisnosti) koja pokazuje dalje od slučaja upotrebe koji je proširenje originalnog slučaja upotrebe.

Relacija generalizacije služi da ukaže na činjenicu da se neki slučaj upotrebe A može generalizirati na slučaj upotrebe B. U ovom slučaju, slučaj upotrebe A će biti specijalizacija slučaja upotrebe B. U ovom slučaju, B se naziva predak ili roditelj A, i koristi A je potomak upotrebe slučaja upotrebe V.

Grafički, ovaj odnos je predstavljen punom linijom sa strelicom otvorenog trougla koja pokazuje na roditeljski slučaj upotrebe.

Odnos generalizacije između slučajeva upotrebe koristi se kada je potrebno napomenuti da dječji slučajevi upotrebe imaju sve atribute i ponašanja roditeljskih slučajeva upotrebe.

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

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

Grafički, ovaj odnos je predstavljen isprekidanom linijom sa strelicom (varijanta odnosa zavisnosti) koja pokazuje od osnovnog slučaja upotrebe do uključenog slučaja upotrebe.

dijagram klasa

dijagram klasa(dijagram klasa) - glavni način da se opiše statička struktura sistema.

Dijagram klasa koristi jedan glavni tip entiteta: klase (uključujući brojne posebne slučajeve klasa: interfejse, primitivne tipove, klase asocijacija, itd.), između kojih su uspostavljene sledeće glavne vrste odnosa: zavisnosti, asocijacije, generalizacije, implementacije.

Relacija zavisnosti općenito ukazuje na neki semantički odnos između dva elementa modela ili dva skupa takvih elemenata koji nije odnos asocijacije, generalizacije ili implementacije. Odnos zavisnosti se koristi u situaciji kada neka promjena u jednom elementu modela može zahtijevati promjenu u drugom zavisnom elementu modela.

Odnos zavisnosti je grafički predstavljen isprekidanom linijom između odgovarajućih elemenata sa strelicom na jednom kraju, sa strelicom koja pokazuje od klijentske klase zavisnosti do nezavisne ili izvorne klase.

Posebne ključne riječi (stereotipi) mogu se postaviti 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 šablon za svoju naknadnu parametrizaciju;
• "derive" - ​​atributi klase klijenta mogu se izračunati iz atributa izvorne klase;
• "import" - javni atributi i operacije izvorne klase postaju dio klase klijenta, kao da su deklarisani direktno u njoj;
• "pročistiti" - označava da klasa klijenta služi kao preciziranje izvorne klase iz istorijskih razloga, kada dodatne informacije postanu dostupne u toku rada na projektu.

odnos asocijacije odgovara prisutnosti nekog odnosa između klasa. Ovaj odnos je označen punom linijom sa dodatnim posebnim simbolima koji karakterišu pojedinačna svojstva određene asocijacije. Kao dodatni specijalni znakovi mogu se koristiti naziv asocijacije, kao i nazivi i višestrukost klasa uloga asocijacije. Naziv udruženja je izborni element njegove oznake.

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

Odnos kompozicije je poseban slučaj relacije agregacije. Ovaj odnos služi da istakne poseban oblik odnosa dio-cjelina u kojem su sastavni dijelovi u nekom smislu unutar cjeline. Specifičnost odnosa između njih je u tome što dijelovi ne mogu djelovati odvojeno od cjeline, odnosno uništavanjem cjeline uništavaju se i svi njeni sastavni dijelovi.

Relacija generalizacije je odnos između općenitijeg elementa (roditelj ili predak) i specifičnijeg ili posebnog elementa (dijete ili potomak). U primjeni na dijagram klasa, ovaj odnos opisuje hijerarhijsku strukturu klasa i nasljeđivanje njihovih svojstava i ponašanja. Ovo pretpostavlja da klasa potomka ima sva svojstva i ponašanje klase pretka, a takođe ima svoja svojstva i ponašanje koji nisu prisutni u klasi predaka.

dijagram automata

dijagram automata(dijagram državnog stroja) ili dijagram stanja u UML-u 1 (dijagram dijagrama stanja) je jedan od načina da se detaljno opiše ponašanje u UML-u. U suštini, dijagrami automata, kao što ime implicira, su graf stanja i prijelaza konačnog automata opterećen mnogim dodatnim detaljima i detaljima.

Dijagram stanja opisuje proces promjene stanja samo jedne klase, odnosno 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 iz drugih objekata ili izvana. Dijagrami stanja koriste se za opisivanje reakcije objekta na takve vanjske utjecaje.

U automatskom dijagramu se koristi 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 simuliranog sistema u obliku usmerenog grafa, čiji vrhovi odgovaraju stanjima, a lukovi prelazima.

Početno stanje je poseban slučaj stanja koje ne sadrži nikakve unutrašnje akcije (pseudo-stanja). Objekt je u ovom stanju po defaultu u početnom trenutku vremena. Služi za označavanje na dijagramu stanja grafičkog područja iz kojeg počinje proces promjene stanja.

finale (finale) stanje je poseban slučaj stanja koje takođe ne sadrži nikakve unutrašnje akcije (pseudo-stanja). Objekt će biti u ovom stanju po defaultu nakon završetka automata na kraju vremena.

dijagram aktivnosti

Prilikom modeliranja ponašanja projektovanog ili analiziranog sistema, potrebno je ne samo prikazati proces promene njegovih stanja, već i detaljno razjasniti karakteristike algoritamske i logičke implementacije operacija koje sistem izvodi.

dijagram aktivnosti(dijagram aktivnosti) je još jedan način opisivanja ponašanja koji vizualno liči na stari dobri dijagram toka algoritma. Koristi se za simulaciju procesa izvođenja operacija.

Glavni pravac upotrebe dijagrama aktivnosti je vizualizacija karakteristika implementacije operacija klase, kada je potrebno predstaviti algoritme za njihovo izvršavanje.

U dijagramu aktivnosti koristi se jedan glavni tip entiteta - akcija i jedan tip odnosa - tranzicije (prijenosi kontrole). Koriste se i takve konstrukcije kao što su račve, spajanja, veze, grananja. Preporučljivo je koristiti glagol s riječima za objašnjenje kao naziv jednostavne radnje.

dijagram sekvence

dijagram sekvence(dijagram sekvence) je način opisivanja ponašanja sistema "na primjerima".

U stvari, dijagram sekvence je zapis protokola određene sesije sistema (ili fragment takvog protokola). U objektno orijentiranom programiranju, najvažnija stvar u vremenu izvođenja je prosljeđivanje poruka između objekata koji sarađuju. Na ovom dijagramu je prikazan redoslijed slanja poruka, otuda i naziv.

U dijagramu sekvence koristi se jedan glavni tip entiteta - instance međudjelujućih klasifikatora (uglavnom klase, komponente i akteri) i jedan tip odnosa - veze preko kojih se razmjenjuju poruke.

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

Komunikacioni dijagram

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

Dakle, u dijagramu komunikacije, kao i u dijagramu sekvence, koristi se jedan glavni tip entiteta - instance međudjelujućih klasifikatora i jedna vrsta odnosa - veze. Međutim, ovdje naglasak nije na vremenu, već na strukturi odnosa između konkretnih instanci.

Dijagram komponenti

Dijagram komponenti(dijagram komponenti) - prikazuje odnos između modula (logičkih ili fizičkih) koji čine simulirani sistem.

Glavni tip entiteta u dijagramu komponenti su same komponente, kao i interfejsi, preko kojih se ukazuje odnos između komponenti. U dijagramu komponenti primjenjuju se sljedeći odnosi:

• implementacije između komponenti i interfejsa (komponenta implementira interfejs);
• zavisnosti između komponenti i interfejsa (komponenta koristi interfejs);

Dijagram postavljanja

Dijagram postavljanja(dijagram implementacije), zajedno sa prikazom sastava i odnosa elemenata sistema, pokazuje kako su oni fizički postavljeni na računarske resurse tokom izvršavanja.

U dijagramu postavljanja, u poređenju sa dijagramom komponente, dodaju se dva tipa entiteta: artefakt, koji je implementacija komponente i čvor (može biti ili klasifikator koji opisuje tip čvora ili specifična instanca) , kao i odnos asocijacije između čvorova, koji pokazuje da su čvorovi fizički povezani u vrijeme izvođenja.

Dijagram objekta

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

U dijagramu objekata koristi se jedan glavni tip entiteta: objekti (instance klasa), između kojih su naznačeni specifični odnosi (najčešće instance asocijacije). Dijagrami objekata su pomoćne prirode – u stvari, ovo su primjeri (moglo bi se reći, memorijski dumpi) koji pokazuju koji objekti postoje i odnose između njih u nekom određenom trenutku u radu sistema.

Dijagram unutrašnje strukture(kompozitni dijagram strukture) se koristi za detaljniji prikaz strukturnih klasifikatora, prvenstveno klasa i komponenti.

Strukturni klasifikator je prikazan kao pravougaonik sa imenom klasifikatora na vrhu. Unutra su dijelovi. Može biti nekoliko dijelova. Dijelovi mogu međusobno komunicirati. Na to ukazuju konektori raznih vrsta. Mjesto na vanjskoj ivici dijela na koji je spojen konektor naziva se port. Priključci se također nalaze na vanjskoj granici strukturnog klasifikatora.

Dijagram pregleda interakcije(dijagram pregleda interakcije) je vrsta dijagrama aktivnosti sa proširenom sintaksom: veze do interakcija (upotreba interakcije) definirane dijagramima sekvence mogu djelovati kao elementi preglednog dijagrama interakcije.

Tajming grafikon

Tajming grafikon(vremenski dijagram) je poseban oblik dijagrama sekvence, u kojem se posebna pažnja poklanja promjeni stanja različitih instanci klasifikatora i njihovoj vremenskoj sinhronizaciji.

Dijagram paketa

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

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

Model odnosa entiteta (ER-model)

analogni dijagrami klasa(UML) može biti ER model, koji se koristi u dizajnu baza podataka (relacijski model).

Model odnosa entiteta (ER-model) je model podataka koji omogućava opisivanje konceptualnih shema predmetnog područja. ER model se koristi u (konceptualnom) dizajnu baze podataka na visokom nivou. Uz njegovu pomoć, možete istaknuti ključne entitete i odrediti odnose koji se mogu uspostaviti između ovih entiteta. wikipedia

Svaki fragment predmetne oblasti može se predstaviti kao skup entiteta, između kojih postoji određeni skup odnosa.

Osnovni koncepti:

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

Entitet set(skup entiteta) - skup entiteta istog tipa (koji imaju ista svojstva).

Veza(odnos) je asocijacija uspostavljena između više entiteta.

Domain(domen) - skup vrijednosti (domena) atributa.

Postoje tri vrste binarnih veza:

• jedan na jedan- pojedinačna instanca entiteta jedne klase povezana je sa jednom instancom entiteta druge klase, na primjer, RUKOVODITELJ – ODSJEK;
• 1 do N ili jedan prema mnogima- jedna instanca entiteta jedne klase povezana je sa mnogim instancama entiteta druge klase, na primjer, ODELJENJE - ZAPOSLENI;
• N do M ili mnogo mnogima- mnoge instance entiteta jedne klase su povezane sa mnogim instancama entiteta druge klase, na primjer, ZAPOSLENI - PROJEKT;
Pojmovnik osnovnih pojmova u UML-u

objekt- entitet koji ima jedinstvenost i obuhvata stanje i ponašanje.

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

interfejs- imenovani skup operacija koji definiše skup usluga koje potrošač može zatražiti i koje pruža pružalac usluga.

Saradnja- skup objekata koji međusobno djeluju radi postizanja nekog cilja.

Glumac- entitet koji je izvan modeliranog sistema i direktno je u interakciji sa njim.

komponenta- modularni deo sistema sa dobro definisanim skupom potrebnih i obezbeđenih interfejsa.

Artefakt- element informacije koji se koristi ili generiše u procesu razvoja softvera. Drugim riječima, artefakt je fizička jedinica implementacije izvedena iz elementa modela (kao što je klasa ili komponenta).

Čvor- računarski resurs na koji se artefakti postavljaju i, ako je potrebno, izvršavaju.

Bihevioralni entiteti su namijenjeni da opisuju ponašanje. Postoje samo dva osnovna entiteta ponašanja: stanje i akcija.

stanje- period u životnom ciklusu objekta, u kojem predmet zadovoljava određeni uslov i obavlja sopstvenu aktivnost ili čeka da dođe do nekog događaja.

akcija- primitivni atomski proračun.

Mašina je paket koji definira skup koncepata neophodnih za predstavljanje ponašanja modeliranog entiteta kao diskretnog prostora sa konačnim brojem stanja i prijelaza.

klasifikator je deskriptor za skup objekata istog tipa.

Dodatno čitanje

• Fowler M. UML. Osnove, 3. izdanje
• Butch G., Rambo D., Jacobson I. UML jezik. Priručnik

UML je akronim za Unified Modeling Language. U stvari, to je jedna od najpopularnijih tehnika modeliranja poslovnih procesa i međunarodna je standardna notacija za specificiranje, vizualizaciju i dokumentovanje razvoja softvera. Definiran od strane grupe za upravljanje objektima, nastao je kao rezultat nekoliko dodatnih UML sistema notacije i sada je postao de facto standard za vizualno modeliranje. Temeljni princip svakog objektno orijentiranog programiranja počinje izgradnjom modela.

UML je nastao iz haosa oko razvoja softvera i dokumentacije. Tokom 1990-ih postojalo je nekoliko različitih načina predstavljanja softverskih sistema. Postojala je potreba za jedinstvenijim vizuelnim UML načinom predstavljanja ovih sistema, i kao rezultat toga su ga razvila tri softverska inženjera koji su radili u Rational Software-u između 1994. i 1996. godine. Kasnije je usvojen kao standard 1997. godine i ostao je takav do danas uz samo nekoliko ažuriranja.

U osnovi, UML je jezik za modeliranje opšte namene u oblasti razvoja softvera. Međutim, sada je pronašao svoj put u dokumentaciji nekoliko poslovnih procesa ili radnih tokova, kao što su dijagrami aktivnosti. Tip UML dijagrama može se koristiti kao zamjena za dijagrame toka. Oni obezbeđuju i standardizovaniji način za modeliranje tokova posla i širok spektar funkcija za poboljšanje čitljivosti i efikasnosti.

Arhitektura je zasnovana na meta-objektu, koji definiše osnovu za kreiranje UML jezika. Dovoljno je precizan da kreira cijelu aplikaciju. Potpuno izvršni UML može se primijeniti na više platformi koristeći različite tehnologije sa svim procesima tokom cijelog ciklusa razvoja softvera.

UML je dizajniran za korisnike da razviju jezik vizualnog modeliranja. Podržava koncepte razvoja visokog nivoa kao što su strukture, obrasci i saradnja. UML je kolekcija elemenata kao što su:

1. Izjave programskog jezika.
2. Akteri opisuju ulogu koju igra korisnik ili bilo koji drugi sistem koji je u interakciji sa objektom.
3. Aktivnosti koje treba izvršiti za izvršenje ugovora o djelu i biti prikazane dijagramima.
4. Poslovni proces koji uključuje skup zadataka koji kreiraju određenu uslugu za kupce, vizualiziran dijagramom toka sekvencijalnih radnji.
5. Logičke i višekratne softverske komponente.

UML dijagrami spadaju u dvije kategorije. Prvi tip uključuje sedam tipova dijagrama koji predstavljaju strukturalne informacije, drugi - preostalih sedam koji predstavljaju opšte tipove ponašanja. Ovi dijagrami se koriste za dokumentovanje arhitekture sistema i direktno su uključeni u UML modeliranje sistema.

UML dijagrami su predstavljeni kao statički i dinamički prikazi modela sistema. Statički prikaz uključuje dijagrame klase i kompozitne strukture koji naglašavaju statičku strukturu. Dinamički pogled predstavlja interakciju između objekata i promjene u unutrašnjim stanjima objekata koristeći dijagrame sekvenci, aktivnosti i stanja.

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

Upotreba UML-a ima različite oblike kako u dokumentaciji za razvoj softvera tako iu poslovnim procesima:

1. Skica. U ovom slučaju, UML dijagrami se koriste za prenošenje različitih aspekata i karakteristika sistema. Međutim, ovo je samo pogled na sistem na najvišem nivou i najvjerovatnije neće uključivati ​​sve potrebne detalje za izvođenje projekta do samog kraja.
2. Forward Design - Dizajn skice se radi prije nego što se aplikacija kodira. Ovo se radi radi boljeg pregleda sistema ili toka posla koji korisnik pokušava da kreira. Mogu se identifikovati mnogi problemi ili nedostaci u dizajnu, što će poboljšati opšte zdravlje i dobrobit projekta.
3. Reverzni dizajn. Kada je kod napisan, UML dijagrami se pojavljuju kao oblik dokumentacije za različite aktivnosti, uloge, saradnike i tokove posla.
4. Nacrt. U ovom slučaju, dijagram služi kao potpuna konstrukcija koja zahtijeva samo stvarnu implementaciju sistema ili softvera. Ovo se često radi pomoću alata CASE (Computer Aided Software Engineering Tools). Glavni nedostatak korištenja CASE alata je taj što zahtijevaju određeni nivo znanja, obuku korisnika, te menadžment i osoblje.

UML nije samostalan programski jezik kao što je Java, C++ ili Python, međutim, uz odgovarajuće alate, može se pretvoriti u UML pseudoprogramski jezik. Da bi se postigao ovaj cilj, cijeli sistem mora biti dokumentiran u različitim dijagramima, a korištenjem pravog softvera, dijagrami se mogu direktno prevesti u kod. Ova metoda može biti korisna samo ako vrijeme provedeno u crtanju dijagrama traje manje od pisanja stvarnog koda. Iako je UML kreiran za modeliranje sistema, našao je nekoliko upotreba u poslovnim područjima.

Slijedi primjer UML dijagrama za poslovno modeliranje.

Jedno praktično rešenje bilo bi vizuelno predstavljanje toka procesa za teleprodaju kroz dijagram aktivnosti. Od trenutka kada je nalog uzet kao ulaz, pa do trenutka kada je nalog završen i dat konkretan izlaz.

Postoji nekoliko tipova UML dijagrama, a svaki od njih obavlja različit zadatak, bilo da je razvijen prije implementacije ili poslije, kao dio dokumentacije. Dvije najšire kategorije koje pokrivaju sve ostale tipove su dijagram ponašanja i dijagram strukture. Kao što samo ime govori, neki UML dijagrami pokušavaju da analiziraju i opisuju strukturu sistema ili procesa, dok drugi opisuju ponašanje sistema, njegovih učesnika i komponenti.

Različite vrste se dijele na sljedeći način:

1. Ne koriste se svi od 14 različitih tipova UML dijagrama redovno kada se dokumentuju sistemi i arhitekture.
2. Pareto princip se također primjenjuje na korištenje UML dijagrama.
3. 20% dijagrama koriste programeri 80% vremena.

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

• dijagrami upotrebe;
• dijagrami klasa;
• sekvence.

Dijagrami aktivnosti - Najvažniji UML dijagrami za kreiranje modela poslovnih procesa. U razvoju softvera koriste se za opisivanje toka različitih aktivnosti. Mogu biti serijski ili paralelni. Oni opisuju objekte koji se koriste, konzumiraju ili proizvode nekom aktivnošću i odnos između različitih aktivnosti.

Sve navedeno je bitno za modeliranje poslovnih procesa koji vode od jednog do drugog, jer su međusobno povezani jasnim početkom i krajem. U poslovnom okruženju, ovo se takođe naziva mapiranjem poslovnih procesa. Glavni akteri su autor, urednik i izdavač. Primjer UML-a je sljedeći. Kada recenzent pregleda projekat i odluči da je potrebno izvršiti neke promjene. Autor zatim pregleda nacrt i ponovo ga vraća da analizira recenziju.

Dijagram upotrebe

Kamen temeljac sistema - koristi se za analizu zahteva za nivo sistema. Ovi zahtjevi su izraženi u različitim slučajevima upotrebe. Tri glavne komponente UML dijagrama su:

1. Funkcionalno - predstavljeno kao slučajevi upotrebe.
2. Glagol koji opisuje radnju.
3. Glumci - za interakciju sa sistemom. Akteri mogu biti korisnici, organizacije ili eksterni zahtjev. Odnosi između učesnika prikazani su ravnim strelicama.

Na primjer, za dijagram upravljanja zalihama. U ovom slučaju postoji vlasnik, dobavljač, menadžer, specijalista za inventuru i inspektor za popis. Okrugli kontejneri predstavljaju radnje koje glumci izvode. Moguće radnje: kupiti i platiti dionice, provjeriti kvalitet dionica, vratiti dionice ili distribuirati dionice.

Ovaj tip dijagrama je vrlo pogodan za prikazivanje dinamičkog ponašanja između učesnika u sistemu, što ga čini lakšim za predstavljanje bez prikazivanja detalja implementacije.

Privremeno

UML vremenski dijagrami se koriste za predstavljanje odnosa objekata kada fokus zavisi od vremena. U ovom slučaju nije zanimljivo kako objekti međusobno djeluju ili mijenjaju jedni druge, već korisnik želi zamisliti kako objekti i subjekti djeluju duž linearne vremenske ose.

Svaki pojedinačni učesnik je predstavljen kroz liniju života, koja je u suštini linija koja formira faze dok se pojedinačni učesnik kreće iz jedne faze u drugu. Glavna pažnja posvećena je trajanju vremena događaja i promjenama koje se dešavaju u zavisnosti od toga.

Glavne komponente vremenskog dijagrama su:

1. Lifeline je individualni član.
2. Vremenska linija stanja - jedini životni put može proći kroz različita stanja unutar procesa.
3. Ograničenje trajanja - ograničenje vremenskog intervala koje predstavlja trajanje ograničenja potrebnog za ispunjenje.
4. Vremensko ograničenje - Ograničavanje vremenskog intervala tokom kojeg član nešto mora izvesti.
5. Destruction Emergence - Pojava poruke koja uništava pojedinog člana i prikazuje kraj životnog ciklusa tog člana.

Horizontalni dijagrami, koji se nazivaju i dijagrami stanja, koriste se za opisivanje različitih stanja komponente unutar sistema. Uzima konačni format imena jer je dijagram u suštini mašina koja opisuje višestruka stanja objekta i kako se mijenja na osnovu unutrašnjih i vanjskih događaja.

Vrlo jednostavan dijagram stanja mašine bio bi u igri šaha. Tipična šahovska partija se sastoji od poteza bijelih i poteza crnih. Bijeli ima prvi potez i tako započinje igru. Kraj igre se može dogoditi bez obzira da li bijeli ili crni pobjeđuju. Igra može završiti utakmicom, ostavkom ili neriješenim rezultatom (različita stanja automobila). Dijagrami stanja se uglavnom koriste u naprijed i nazad UML dizajnu različitih sistema.

Sekvencijalno

Ovaj tip dijagrama je najvažniji UML dijagram ne samo među informatičkom zajednicom, već i kao modeli na nivou dizajna za razvoj poslovnih aplikacija. Popularni su u opisivanju poslovnih procesa zbog svoje vizuelno samoobjašnjive prirode. Kao što ime govori, dijagrami opisuju slijed poruka i interakcija koje se odvijaju između subjekata i objekata. Akteri ili objekti mogu biti aktivni samo kada je potrebno ili kada drugi objekt želi komunicirati s njima. Sve komunikacije su prikazane hronološkim redom.

Za više informacija, pogledajte primjer dijagrama UML sekvence ispod.

Kao što slijedi iz primjera, strukturni dijagrami se koriste za prikaz strukture sistema. Preciznije, jezik se koristi u razvoju softvera da predstavi arhitekturu sistema i kako su različite komponente povezane.

UML dijagram klasa je najčešći tip dijagrama za softversku dokumentaciju. Budući da je većina softvera koji se trenutno piše još uvijek zasnovana na objektno orijentiranoj programskoj paradigmi, korištenje dijagrama klasa za dokumentiranje softvera je zdrav razum. To je zato što je OOP zasnovan na UML klasama i odnosima između njih. Ukratko, grafikoni sadrže klase, zajedno sa njihovim atributima, koji se nazivaju i polja podataka, i njihova ponašanja koja se nazivaju funkcije članova.

Tačnije, svaka klasa ima 3 polja: ime na vrhu, atributi odmah ispod imena, operacije/ponašanje na dnu. Odnos između različitih klasa (predstavljenih veznom linijom) čini dijagram klasa. Gornji primjer prikazuje osnovni dijagram klasa.

Objekti

Kada raspravljate o dijagramima strukture UML-a, potrebno je da se udubite u koncepte koji se odnose na informatiku. U softverskom inženjerstvu, klase se smatraju apstraktnim tipovima podataka dok su objekti instance.Na primjer, ako postoji "Car" koji je generički apstraktni tip, tada bi instanca klase "Car" bila "Audi".

UML dijagrami objekata pomažu programerima softvera da provjere da li je generirana apstraktna struktura održiva struktura kada se implementira u praksi, odnosno kada se objekti kreiraju. Neki programeri ovo smatraju sekundarnim nivoom provjere tačnosti. Prikazuje instance klase. Preciznije, generička klasa "Klijent" sada ima stvarnog klijenta, na primer po imenu "James". James je instanca općenitije klase i ima iste atribute, međutim, sa datim vrijednostima. Isto je urađeno i sa računima i štednim računom. Oboje su objekti svojih klasa.

Deployments

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

Tipična pojednostavljena shema implementacije za web aplikaciju bi uključivala:

1. Čvorovi (server aplikacija i server baze podataka).
2. Dijagram artefakata klijentske aplikacije i baze podataka.

Dijagram paketa je sličan makroima za UML dijagrame implementacije koje smo objasnili gore. Razni paketi sadrže čvorove i artefakte. Oni grupišu dijagrame i komponente modela u grupe, slično kao što prostor imena enkapsulira različita imena koja su donekle povezana. Konačno, paket može kreirati i nekoliko drugih paketa koji predstavljaju složenije sisteme i ponašanja.

Glavna svrha dijagrama paketa je da pokaže odnose između različitih velikih komponenti koje čine složeni sistem. Programeri smatraju da je ova apstrakcija dobra prednost za korištenje dijagrama paketa, posebno kada se neki detalji mogu izostaviti iz slike.

Kao i svaka druga stvar u životu, da biste nešto uradili kako treba, potrebni su vam pravi alati. Za dokumentiranje softvera, procesa ili sistema koristite alate koji nude UML napomene i predloške dijagrama. Postoje različiti alati za dokumentaciju softvera koji mogu pomoći u crtanju dijagrama.

Oni općenito spadaju u sljedeće glavne kategorije:

1. Papir i olovka su laki. Uzmite papir i olovku, otvorite UML sintaksni kod s weba i nacrtajte bilo koji tip dijagrama koji želite.
2. Online alati - Postoji nekoliko online aplikacija koje se mogu koristiti za kreiranje dijagrama. Većina njih nudi plaćenu pretplatu ili ograničen broj dijagrama na besplatnom nivou.
3. Besplatni online alati su skoro isti kao i plaćeni. Glavna razlika je u tome što oni koji se plaćaju nude i tutorijale i gotove šablone za određene dijagrame.
4. Desktop aplikacija – Tipična desktop aplikacija koja se koristi za dijagrame i skoro svaki drugi dijagram je Microsoft Visio. Nudi napredne funkcije i funkcionalnost. Jedini nedostatak je što morate platiti za to.

Dakle, jasno je da je UML važan aspekt povezan sa razvojem objektno orijentisanog softvera. Koristi grafičku notaciju za kreiranje vizuelnih modela sistemskih programa.

UML dijagram je specijalizovani grafički opisni jezik dizajniran za modeliranje objekata u razvoju različitih softvera. Ovaj jezik ima širok profil i otvoreni je standard koji koristi različite grafičke notacije za kreiranje apstraktnog modela sistema. UML je kreiran da omogući definiciju, vizualizaciju, dokumentaciju i dizajn svih vrsta softverskih sistema. Vrijedi napomenuti da sam UML dijagram nije programski jezik, ali pruža mogućnost generiranja zasebnog koda na temelju njega.

Zašto je ona potrebna?

Upotreba UML-a ne završava se modeliranjem svih vrsta softvera. Takođe, ovaj jezik se danas aktivno koristi za modeliranje različitih poslovnih procesa, projektovanje sistema, kao i za prikaz organizacionih struktura.

Uz pomoć UML-a, programeri softvera mogu osigurati potpunu saglasnost u grafičkoj notaciji koja se koristi za predstavljanje uobičajenih koncepata kao što su: komponenta, generalizacija, klasa, ponašanje i agregacija. Time se postiže veći stepen koncentracije na arhitekturu i dizajn.

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

dijagram klasa

UML dijagram klasa je dijagram statičke strukture dizajniran da opiše strukturu sistema, kao i da pokaže atribute, metode i zavisnosti između nekoliko različitih klasa.

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

• Konceptualno. U ovom slučaju, UML dijagram klasa opisuje model određene predmetne oblasti i pruža samo klase objekata aplikacije.
• Specifično. Dijagram se koristi u procesu projektovanja različitih informacionih sistema.
• Implementacija. Dijagram klasa uključuje sve vrste klasa koje se direktno koriste u programskom kodu.

Dijagram komponenti

UML komponentni dijagram je potpuno statički dijagram strukture. Namjera mu je da demonstrira raspad određenog softverskog sistema na različite strukturne komponente, kao i odnose između njih. UML komponentni dijagram može koristiti sve vrste modela, biblioteka, datoteka, paketa, izvršnih datoteka i mnoge druge elemente kao takve.

Kompozitni/kompozitni dijagram strukture

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

Njihova podvrsta je UML dijagram saradnje, koji se koristi za demonstriranje uloga i interakcija različitih klasa u okviru saradnje. Prilično su zgodne ako trebate modelirati uzorke dizajna.

Vrijedi napomenuti da se UML dijagrami klasa i dijagrami kompozitne strukture mogu koristiti u isto vrijeme.

Dijagram implementacije

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

Zavisnost manifestacije formira se između artefakta i komponente koju on implementira.

Dijagram objekta

Ovaj prikaz vam omogućava da vidite potpunu ili djelomičnu sliku sistema koji se kreira u određenom trenutku. U potpunosti prikazuje sve instance klasa određenog sistema, ukazujući na trenutne vrijednosti njihovih parametara, kao i na odnose između njih.

Dijagram paketa

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

Njihova upotreba se sprovodi kako bi se obezbedila organizacija više elemenata u grupe prema određenom atributu, kako bi se pojednostavila struktura, kao i da bi se organizovao rad sa modelom ovog sistema.

dijagram aktivnosti

UML dijagram aktivnosti prikazuje dekompoziciju određene aktivnosti na nekoliko komponentnih dijelova. U ovom slučaju, koncept "aktivnosti" se odnosi na specifikaciju određenog izvršnog ponašanja u obliku paralelnog, kao i koordinisanog sekvencijalnog izvršavanja različitih podređenih elemenata - ugniježđenih tipova aktivnosti i različitih akcija, ujedinjenih tokovima koji idu od izlaze određenog čvora na ulaze drugog.

UML dijagram aktivnosti se često koristi za modeliranje različitih poslovnih procesa, paralelnog i sekvencijalnog računanja. Između ostalog, modeliraju sve vrste tehnoloških postupaka.

dijagram automata

Ovaj pogled se naziva i nešto drugačije - UML dijagram stanja. Ima predstavljeni državni stroj sa jednostavnim i kompozitnim stanjima, kao i prijelazima.

State Machine je specifikacija niza različitih stanja kroz koje određeni objekt prolazi, ili interakcija kao odgovor na neke događaje u njegovom životu, kao i odgovor objekta na takve događaje. Mašina stanja koju koristi UML dijagram stanja je pripojena originalnom elementu i koristi se za definiranje ponašanja njegovih instanci.

Takozvani dijagrami zmajeva mogu se koristiti kao analozi takvih dijagrama.

Dijagrami slučajeva upotrebe

UML dijagram slučaja upotrebe prikazuje sve odnose koji se javljaju između aktera, kao i različite slučajeve upotrebe. Njegov glavni zadatak je da pruži potpuno sredstvo pomoću kojeg kupac, krajnji korisnik ili neki programer mogu zajednički razgovarati o ponašanju i funkcionalnosti određenog sistema.

Ako se dijagram slučaja upotrebe UML-a koristi u procesu modeliranja sistema, analitičar će:

• Jasno odvojite sistem koji se modelira od njegovog okruženja.
• Identifikovati aktere, načine njihove interakcije sa ovim sistemom, kao i njegovu očekivanu funkcionalnost.
• U pojmovniku se kao predmetna oblast postavljaju različiti koncepti koji se odnose na detaljan opis funkcionalnosti ovog sistema.

Ako je dijagram upotrebe razvijen u UML-u, postupak počinje tekstualnim opisom koji se dobija u radu sa kupcem. Pritom je vrijedno napomenuti činjenicu da su različiti nefunkcionalni zahtjevi potpuno izostavljeni u procesu sastavljanja modela slučaja korištenja, te će se za njih već formirati poseban dokument.

Komunikacije

Komunikacioni dijagram je, baš kao i UML sekvencijski dijagram, tranzitivan, odnosno izražava interakciju, ali je istovremeno demonstrira na različite načine, a ako je potrebno, sa potrebnim stepenom tačnosti, može se transformisati u drugi.

Komunikacioni dijagram odražava interakcije koje se javljaju između različitih elemenata kompozitne strukture, kao i uloge saradnje. Njegova glavna razlika od dijagrama sekvence je u tome što jasno ukazuje na odnos između nekoliko elemenata, a vrijeme se ne koristi kao posebna dimenzija.

Ovaj tip se razlikuje po apsolutno besplatnom formatu uređivanja nekoliko objekata i odnosa na isti način kao što je to učinjeno u dijagramu objekata. Ako postoji potreba da se održi redosled poruka u ovom slobodnom formatu, one se numerišu hronološki. Čitanje ovog dijagrama počinje s početnom porukom 1.0, a zatim se nastavlja u smjeru u kojem se poruke prenose s jednog objekta na drugi.

Uglavnom, takvi dijagrami pokazuju potpuno iste informacije koje nam pruža dijagram sekvence, ali budući da koristi drugačiji način predstavljanja informacija, određene stvari u jednom dijagramu postaje mnogo lakše odrediti nego u drugom. Također je vrijedno napomenuti da komunikacijski dijagram jasnije pokazuje s kojim elementima svaki pojedinačni element stupa u interakciju, dok dijagram sekvence jasnije pokazuje kojim redoslijedom se interakcije izvode.

dijagram sekvence

UML dijagram sekvence prikazuje interakcije između nekoliko objekata, koji su poredani prema vremenu njihovog pojavljivanja. Takav dijagram prikazuje vremenski uređenu interakciju između nekoliko objekata. Konkretno, prikazuje sve objekte koji učestvuju u interakciji, kao i kompletan niz poruka koje oni 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 njime.

Dijagram saradnje

Ovaj tip dijagrama vam omogućava da prikažete interakcije između nekoliko objekata, apstrahirajući od slijeda prijevoda poruke. 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 dijagrami sekvenci i komunikacijski dijagrami jednostavno različiti pogledi na iste procedure, Rational Rose pruža mogućnost kreiranja dijagrama sekvence komunikacije iz dijagrama sekvence ili obrnuto, a također ih potpuno automatski sinhronizira.

Dijagrami pregleda interakcije

Ovo su UML dijagrami, koji pripadaju tipu dijagrama aktivnosti i uključuju elemente sekvence i konstrukcije toka kontrole.

Vrijedi napomenuti činjenicu da ovaj format kombinuje dijagram kolaboracije i sekvence, koji pružaju priliku da se sa različitih gledišta razmotri interakcija između nekoliko objekata u sistemu koji se formira.

Tajming grafikon

Predstavlja alternativnu verziju dijagrama sekvence, koja eksplicitno pokazuje promjenu stanja na liniji života s određenom vremenskom skalom. Može biti vrlo korisno u raznim aplikacijama u realnom vremenu.

Koje su prednosti?

Vrijedi napomenuti nekoliko prednosti koje razlikuju dijagram upotrebe UML-a i druge:

• Jezik je objektno orijentiran, zbog čega su tehnologije za opisivanje rezultata provedene analize i dizajna semantički bliske metodama programiranja u svim vrstama objektno orijentiranih jezika modernog tipa.
• Koristeći ovaj jezik, sistem se može opisati sa gotovo bilo koje moguće tačke gledišta, a različiti aspekti njegovog ponašanja su opisani na isti način.
• Svi dijagrami su relativno laki za čitanje čak i nakon relativno brzog upoznavanja sa njihovom sintaksom.
• UML vam omogućava da proširite, kao i da uvedete vlastite grafičke i tekstualne stereotipe, što doprinosi njegovoj upotrebi ne samo u softverskom inženjerstvu.
• Jezik je postao prilično raširen, a također se prilično aktivno razvija.

Nedostaci

Unatoč činjenici da konstrukcija UML dijagrama ima puno svojih prednosti, često su kritizirani zbog sljedećih nedostataka:

• redundantnost. U velikoj većini slučajeva, kritičari kažu da je UML prevelik i složen, a često je to neopravdano. Uključuje dosta suvišnih ili gotovo beskorisnih konstrukcija i dijagrama, a najčešće takve kritike idu na drugu verziju, a ne na prvu, jer u novijim revizijama ima više „komitetski osmišljenih“ kompromisa.
• Razne nepreciznosti u semantici. Budući da je UML definiran kombinacijom samog sebe, engleskog i OCL-a, nedostaje mu krutost koja je svojstvena jezicima koji su precizno definirani formalnim tehnikama opisa. U određenim situacijama, apstraktna sintaksa OCL-a, UML-a i engleskog jezika počinje da proturječi jedna drugoj, dok je u drugim slučajevima nepotpuna. Netačnost opisa samog jezika podjednako utiče i na korisnike i na dobavljače alata, što na kraju dovodi do nekompatibilnosti alata zbog jedinstvenog načina na koji se tretiraju različite specifikacije.
• Problemi u procesu implementacije i proučavanja. Svi navedeni problemi stvaraju određene poteškoće u procesu implementacije i učenja UML-a, a to je posebno tačno kada menadžment prisiljava inženjere da ga koriste kada im nedostaju prethodne vještine.
• Kod odražava kod. Drugo mišljenje je da nisu važni lijepi i atraktivni modeli, već direktno radni sistemi, odnosno kod je projekat. Prema ovom mišljenju, postoji potreba za razvojem efikasnijeg načina pisanja softvera. UML se cijeni u pristupima koji kompajliraju modele za regeneraciju 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 na kraju biti ograničen onim što UML alat za tumačenje može pretpostaviti ili odrediti.
• Load mismatch. Ovaj termin dolazi iz teorije sistemske analize kako bi se utvrdila nesposobnost ulaza određenog sistema da percipira izlaz drugog. Kao i kod svake standardne notacije, UML može predstaviti neke sisteme na efikasniji i koncizniji način od drugih. Stoga je programer skloniji onim rješenjima koja su udobnija za utkanje svih prednosti UML-a, kao i drugih programskih jezika. Ovaj problem je očigledniji ako razvojni jezik nije u skladu sa glavnim principima objektno orijentisane ortodoksne doktrine, odnosno ne pokušava da radi u skladu sa principima OOP-a.
• Trudi se da bude univerzalan. UML je jezik za modeliranje opšte namene koji nastoji da bude kompatibilan sa bilo kojim jezikom za obradu koji trenutno postoji. U kontekstu određenog projekta, da bi dizajnerski tim postigao konačni cilj, potrebno je odabrati primjenjive karakteristike ovog jezika. Osim toga, mogući načini ograničavanja obima upotrebe UML-a u bilo kojoj određenoj oblasti prolaze kroz formalizam koji nije u potpunosti formulisan, ali koji je sam po sebi predmet kritike.

Dakle, upotreba ovog jezika nije relevantna u svim situacijama.