Splošne značilnosti jezika UML. Vrste diagramov UML Vrste diagramov UML

Opomba: Predmet tega tečaja je UML – Unified Modeling Language. V prejšnjem predavanju smo govorili o tem, kaj je UML, o njegovi zgodovini, namenu, načinih uporabe jezika, strukturi njegove definicije, terminologiji in zapisu. Ugotovljeno je bilo, da je model UML niz diagramov. V tem predavanju bomo obravnavali vprašanja: zakaj potrebujemo več vrst diagramov; vrste diagramov; OOP in diagram zaporedja

Preden preidemo na razpravo o glavnem gradivu tega predavanja, se pogovorimo o tem, zakaj sploh graditi kakršne koli diagrame. Razvoj modela katerega koli sistema (ne samo programske opreme) je vedno pred njegovim ustvarjanjem ali posodabljanjem. To je potrebno vsaj zato, da bi si jasneje predstavljali, da se problem rešuje. Premišljeni modeli so zelo pomembni tako za interakcijo znotraj razvojne ekipe kot za medsebojno razumevanje s stranko. Navsezadnje vam omogoča, da se prepričate, da je projekt "arhitekturno skladen", preden se izvede v kodi.

Modele kompleksnih sistemov gradimo, ker jih ne moremo v celoti opisati, »poglejte si jih na prvi pogled«. Zato izpostavimo le lastnosti sistema, ki so bistvene za določeno nalogo, in zgradimo njegov model, ki te lastnosti odraža. Metoda objektno usmerjene analize omogoča, da se realni kompleksni sistemi opišejo na najbolj primeren način. Ker pa sistemi postajajo vse bolj zapleteni, obstaja potreba po dobri simulacijski tehnologiji. Kot smo povedali v prejšnjem predavanju, se kot taka »standardna« tehnologija uporablja enoten sistem. jezik modeliranja(Unified Modeling Language, UML), ki je grafični jezik za specifikacijo, vizualizacijo, načrtovanje in dokumentacijo sistemov. Z uporabo UML lahko razvijete podroben model ustvarjenega sistema, ki ne odraža le njegovega koncepta, temveč tudi posebne izvedbene značilnosti. V okviru modela UML so vse predstave o sistemu fiksirane v obliki posebnih grafičnih konstrukcij, imenovanih diagrami.

Opomba. Ne bomo upoštevali vseh, ampak le nekatere vrste grafikonov. Na primer, v tem predavanju ni zajet komponentni diagram, ki je le kratek pregled vrst diagramov. Število vrst grafikonov za določen model aplikacije ni na noben način omejeno. Za preproste aplikacije ni treba graditi diagramov vseh vrst brez izjeme. Nekateri od njih morda preprosto manjkajo in to dejstvo se ne bo štelo za napako. Pomembno je razumeti, da je razpoložljivost diagramov določene vrste odvisna od posebnosti določenega projekta. Informacije o drugih (tukaj ne obravnavanih) vrstah diagramov lahko najdete v standardu UML.

Zakaj potrebujete več vrst grafikonov

Najprej opredelimo terminologijo. V predgovoru k temu predavanju smo večkrat uporabili koncepte sistema, modela in diagrama. Avtor je prepričan, da vsak od nas intuitivno razume pomen teh pojmov, a da bo popolnoma jasno, poglejmo še enkrat v glosar in preberimo naslednje:

sistem- sklop med seboj povezanih nadzorovanih podsistemov, ki jih združuje skupni cilj delovanja.

Ja, ni preveč informativno. Kaj je potem podsistem? Če želite razjasniti situacijo, se obrnimo na klasiko:

sistem imenujemo nabor podsistemov, organiziranih za doseganje določenega cilja in opisanih z uporabo niza modelov, po možnosti z različnih zornih kotov.

No, nič ne moreš narediti, poiskati moraš definicijo podsistema. Tam tudi piše, da podsistem je niz elementov, od katerih nekateri določajo obnašanje drugih elementov. Ian Sommerville razlaga koncept na naslednji način:

Podsistem je sistem, katerega delovanje ni odvisno od storitev drugih podsistemov. Programski sistem je strukturiran kot niz relativno neodvisnih podsistemov. Določene so tudi interakcije med podsistemi.

Tudi ni zelo jasno, ampak bolje. Če govorimo v "človeškem" jeziku, je sistem predstavljen kot niz enostavnejših entitet, ki so relativno samozadostne. To lahko primerjamo s tem, kako v procesu razvoja programa gradimo grafični vmesnik iz standardnih "kock" - vizualnih komponent ali kako je tudi samo programsko besedilo razdeljeno na module, ki vsebujejo podprograme, ki so združeni glede na funkcionalno funkcijo in jih je mogoče znova uporabiti v naslednjih programih.

Razumeti koncept sistema. V procesu načrtovanja se upošteva sistem z različnih zornih kotov s pomočjo modelov, katerih različne predstavitve se pojavljajo v obliki diagramov. Bralec ima lahko spet vprašanja o pomenu pojmov modeli in diagrami. Mislimo, da je lepa, a ne zelo jasna definicija modeli kot pomensko zaprta sistemska abstrakcija verjetno ne bo razjasnil situacije, zato poskusimo razložiti "z lastnimi besedami."

Model- to je določen (materialni ali ne) objekt, ki prikazuje le najpomembnejše značilnosti sistema za to nalogo. Modeli so različni - oprijemljivi in ​​nematerialni, umetni in naravni, dekorativni in matematični...

Navedimo nekaj primerov. Vsi znani plastični avtomobilčki, ki smo se jih v otroštvu s tako strastjo igrali, niso nič drugega kot material umetni dekorativni pravi model avtomobila. Seveda v takem "avtu" ni motorja, rezervoarja ne polnimo z bencinom, menjalnik v njem ne deluje (poleg tega je sploh odsoten), a kot model ta igrača v celoti izpolnjuje svoje funkcije: daje otroku predstavo o avtu, saj prikazuje njegove značilne lastnosti, so prisotnost štirih koles, karoserije, vrat, oken, sposobnosti vožnje itd.

V medicinskih raziskavah so testiranja na živalih pogosto pred kliničnimi preskušanji zdravil pri ljudeh. V tem primeru žival deluje kot material naravenčloveški modeli.

Zgoraj prikazana enačba je tudi model, vendar je to matematični model in opisuje gibanje materialne točke pod delovanjem gravitacije.

Ostaja samo reči, kaj je diagram. diagram je grafični prikaz nabora elementov. Običajno je prikazan kot graf z oglišči (entitete) in robovi (relacije). Obstaja veliko primerov diagramov. To je blokovni diagram, ki ga vsi poznamo iz šolskih let, in namestitveni diagrami za različno opremo, ki jih lahko vidimo v uporabniških priročnikih, ter drevo datotek in imenikov na disku, ki si ga lahko ogledamo z zagonom drevesnega ukaza v Konzola Windows in še veliko, veliko več. V vsakdanjem življenju nas diagrami obkrožajo z vseh strani, saj je sliko lažje zaznati kot besedilo ...

Toda nazaj k oblikovanju programske opreme (in ne samo). V tej industriji od z uporabo diagramov si lahko sistem vizualizirate z različnih zornih kotov. Eden od diagramov lahko na primer opisuje interakcijo uporabnika s sistemom, drugi - spremembo stanj sistema med njegovim delovanjem, tretji - interakcijo med elementi sistema itd. Kompleks sistem lahko in ga je treba predstaviti kot niz majhnih in skoraj neodvisnih modelov - diagramov, pri čemer noben od njih ne zadostuje za opis sistema in pridobitev popolne slike o njem, saj se vsak od njih osredotoča na določen vidik delovanja sistema. sistema in izraža drugačno stopnja abstrakcije. Z drugimi besedami, vsak model ustreza nekemu posebnemu, posebnemu pogledu na sistem, ki se načrtuje.

Kljub temu, da smo bili v prejšnjem odstavku zelo ohlapni s konceptom modela, je treba razumeti, da v kontekstu zgornjih definicij noben posamezen diagram ni model. Diagrami so le sredstvo za vizualizacijo modela in oba je treba razlikovati. Samo niz diagramov sestavlja model sistema in ga najbolj popolno opisuje, vendar ne enega diagrama, vzetega iz konteksta.

Vrste grafikonov

UML 1.5 definiran dvanajst vrst grafikonov razdeljeni v tri skupine:

• štiri vrste diagramov predstavljajo statično strukturo aplikacije;
• pet predstavlja vedenjske vidike sistema;
• tri predstavljajo fizične vidike delovanja sistema (izvedbeni diagrami).

Trenutna različica UML 2.1 ni naredila preveč sprememb. Diagrami so se nekoliko spremenili na videz (pojavili so se okvirji in druge vizualne izboljšave), zapis se je nekoliko izboljšal, nekateri diagrami so dobili nova imena.

Vendar pa natančna številka kanonični diagrami za nas je popolnoma nepomemben, saj jih ne bomo upoštevali vseh, ampak le nekatere - iz razloga, ker število vrst diagramov za določen model določene aplikacije ni strogo določeno. Za preproste aplikacije ni treba graditi vseh diagramov brez izjeme. Na primer, za lokalno aplikacijo ni treba zgraditi diagrama uvajanja. Pomembno je razumeti, da je seznam diagramov odvisen od posebnosti projekta, ki se razvija, in ga določi razvijalec sam. Če radovedni bralec še vedno želi vedeti o vseh diagramih UML, ga bomo napotili na standard UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Spomnimo se, da namen tega tečaja ni opisati absolutno vseh možnosti UML, ampak le predstaviti ta jezik, dati začetno predstavo o tej tehnologiji.

Torej si bomo na kratko ogledali takšne vrste grafikonov, kot so:

• diagram primerov uporabe;
• diagram razredov;
• objektni diagram;
• diagram zaporedja;
• diagram interakcije;
• diagram stanja;
• diagram aktivnosti;
• diagram uvajanja.

O nekaterih od teh diagramov bomo podrobneje govorili v naslednjih predavanjih. Za zdaj se ne bomo osredotočali na podrobnosti, ampak smo si zastavili cilj, da bralca naučimo, da vsaj vizualno razlikuje med vrstami diagramov, da dobi začetno predstavo o namenu glavnih vrst diagramov. Torej, začnimo.

Diagram primerov uporabe

Vsi (vključno s programsko opremo) sistemi so zasnovani ob upoštevanju dejstva, da jih bodo pri svojem delu uporabljali ljudje in / ali sodelovali z drugimi sistemi. Entitete, s katerimi sistem sodeluje pri svojem delu, se imenujejo igralci, in vsak akter pričakuje, da se bo sistem obnašal na strogo določen in predvidljiv način. Poskusimo dati bolj strogo definicijo ektorja. Za to uporabljamo čudovit vizualni besednjak za UML Zicom mentor:

Hektor (igralec)- to je niz logično povezanih vlog, ki se izvajajo pri interakciji s precedensi ali entitetami (sistem, podsistem ali razred). Akter je lahko oseba ali drug sistem, podsistem ali razred, ki predstavlja nekaj zunaj entitete.

Grafično je vektor prikazan bodisi " Mali človek«, podobni tistim, ki smo jih risali v otroštvu, ki upodabljajo člane naše družine, oz simbol razreda z ustreznim stereotipom, kot je prikazano na sliki. Obe obliki predstavitve imata enak pomen in se lahko uporabljata v diagramih. "Stereotipna" oblika se pogosteje uporablja za predstavitev sistemskih akterjev ali v primerih, ko ima akter lastnosti, ki jih je treba prikazati (slika 2.1).

Pozorni bralec lahko takoj postavi vprašanje: Zakaj je Hektor in ne igralec?? Strinjamo se, beseda "ektor" Rusu nekoliko reže uho. Razlog, zakaj to rečemo, je preprost - ektor je tvorjen iz besede dejanje, kar v prevodu pomeni dejanje. Dobesedni prevod besede "ektor" - igralec- predolgo in neprijetno za uporabo. Zato bomo tako govorili še naprej.

riž. 2.1.

Isti pozoren bralec je lahko opazil, da je v definiciji ektorja utripala beseda "precedens". Kaj je to? To vprašanje nas bo še bolj zanimalo, če se spomnimo, o čemer zdaj govorimo diagram primerov uporabe. torej

Precedens (primer uporabe)- opis posameznega vidika obnašanja sistema z vidika uporabnika (Butch).

Opredelitev je precej razumljiva in izčrpna, vendar jo je mogoče z uporabo istega še dodatno izpopolniti Zicom mentor"om:

primer uporabe- opis niza zaporednih dogodkov (vključno z različicami), ki jih izvede sistem, ki vodijo do rezultata, ki ga opazuje akter. Primer uporabe predstavlja vedenje entitete z opisom interakcije med akterji in sistemom. Precedens ne kaže, "kako" je določen rezultat dosežen, ampak le "kaj" je.

Precedensi so označeni na zelo preprost način - v obliki elipse, znotraj katere je navedeno njegovo ime. Primeri uporabe in akterji so povezani s črtami. Pogosto je na enem koncu črte upodobljen riž. 2.3

oblikovanje splošnih zahtev za obnašanje sistema, ki se načrtuje;

razvoj konceptualnega modela sistema za njegovo naknadno detajliranje;

priprava dokumentacije za interakcijo s strankami in uporabniki sistema.

UML je zdaj standardni zapis za vizualno modeliranje programskih sistemov, ki ga je jeseni 1997 sprejela skupina za upravljanje objektov (OMG) in ga podpirajo številni objektno usmerjeni izdelki CASE.

Standard UML ponuja naslednji niz diagramov za modeliranje:

Diagram primerov uporabe (use case diagram) - za modeliranje poslovnih procesov organizacije ali podjetja in določanje zahtev za informacijski sistem, ki se ustvarja;

diagram razredov (razredni diagram) - za modeliranje statične strukture sistemskih razredov in odnosov med njimi;

diagram obnašanja sistema (diagrami obnašanja);

interakcijski diagrami;

Diagrami zaporedja - za modeliranje procesa sporočanja med objekti znotraj enega primera uporabe;

diagram sodelovanja (diagram sodelovanja) - za modeliranje procesa sporočanja med objekti znotraj istega primera uporabe;

diagram stanja - za modeliranje obnašanja sistemskih objektov med prehodom iz enega stanja v drugo;

diagram aktivnosti - za modeliranje obnašanja sistema v okviru različnih primerov uporabe, oziroma modeliranje aktivnosti;

diagram izvedbe (izvedbeni diagrami):

Komponentni diagrami (komponentni diagrami) - za modeliranje hierarhije komponent (podsistemov) informacijskega sistema;

razmestitveni diagram (deployment diagram) - za modeliranje fizične arhitekture zasnovanega informacijskega sistema.

Na sl. 1.1 predstavlja integriran model informacijskega sistema, vključno z glavnimi diagrami, ki jih je treba razviti v tem predmetnem projektu.

riž. 1. Integrirani model informacijskega sistema v zapisu jezika UML

4.2. Diagram primerov uporabe

Primer uporabe je zaporedje dejanj, ki jih izvede sistem kot odgovor na dogodek, ki ga sproži nek zunanji objekt (aktor). Primer uporabe opisuje tipično interakcijo med uporabnikom in sistemom. V najpreprostejšem primeru se primer uporabe določi v procesu pogovora z uporabnikom o funkcijah, ki bi jih želel implementirati v ta informacijski sistem. V UML je primer uporabe prikazan na naslednji način:

sl.2. Primer uporabe

Igralec je vloga, ki jo igra uporabnik v odnosu do sistema. Igralci predstavljajo vloge, ne določenih ljudi ali delovnih mest. Čeprav so v diagramih primerov uporabe prikazani kot stilizirane človeške figure, je igralec lahko tudi zunanji informacijski sistem, ki potrebuje nekaj informacij iz sistema. V diagramu bi morali prikazati igralce le, če res potrebujejo nekaj primerov uporabe. V UML so akterji predstavljeni kot oblike:

sl.3. lik (igralec)

Igralci so razdeljeni na tri glavne vrste:

Uporabniki

sistemi;

Drugi sistemi, ki sodelujejo s tem;

Čas postane akter, če je od njega odvisno sprožitev kakršnih koli dogodkov v sistemu.

4.2.1. Odnosi med primeri uporabe in akterji

V UML diagrami primerov uporabe podpirajo več vrst razmerij med elementi diagrama:

Komunikacija (komunikacija),

Vključitev (vključi),

razširitev (podaljšanje),

posploševanje.

komunikacijska komunikacija je razmerje med primerom uporabe in akterjem. V UML so komunikacijske povezave prikazane z uporabo enosmerne povezave (polna črta).

sl.4. Primer komunikacijske povezave

Vključna povezava uporablja se v situacijah, ko obstaja nekaj vedenja sistema, ki se ponovi v več kot enem primeru uporabe. S pomočjo takšnih povezav se običajno modelira funkcija za večkratno uporabo.

Razširitvena povezava uporablja za opis sprememb v normalnem obnašanju sistema. Omogoča, da en primer uporabe po potrebi uporabi funkcionalnost drugega primera uporabe.

sl.5. Primer odnosa vključitve in razširitve

Posplošitev komunikacije označuje, da ima več akterjev ali razredov skupne lastnosti.

sl.6. Primer odnosa posploševanja

4.3.

Interakcijski diagrami opišejo vedenje medsebojno delujočih skupin predmetov. Običajno interakcijski diagram zajema samo obnašanje predmetov znotraj posameznega primera uporabe. Takšen diagram prikazuje številne predmete in sporočila, ki si jih izmenjujejo med seboj.

sporočilo je sredstvo, s katerim pošiljateljski objekt zahteva od prejemnika, da izvede eno od svojih operacij.

Informativno (informativno) sporočilo je sporočilo, ki prejemnemu objektu zagotovi nekaj informacij za posodobitev njegovega stanja.

Sporočilo zahteve (vprašljivo) je sporočilo, ki zahteva izpis nekaterih informacij o objektu prejemnika.

Nujno sporočilo je sporočilo, ki od prejemnika zahteva, da izvede nekaj dejanj.

Obstajata dve vrsti interakcijskih diagramov: diagrami zaporedja in diagrami sodelovanja.

4.3.1. Diagrami zaporedja

diagram zaporedja odraža tok dogodkov, ki se zgodijo znotraj posameznega primera uporabe.

Vsi akterji (akterji, razredi ali objekti), vključeni v dani scenarij (primer uporabe), so prikazani na vrhu diagrama. Puščice ustrezajo sporočilom, posredovanim med akterjem in objektom ali med objekti za izvajanje zahtevanih funkcij.

V diagramu zaporedja je predmet upodobljen kot pravokotnik, iz katerega je narisana črtkana navpična črta navzdol. Ta vrstica se imenuje rešilna linija predmeta . Je del življenjskega cikla predmeta v procesu interakcije.

Vsako sporočilo je predstavljeno kot puščica med življenjskimi črtami dveh predmetov. Sporočila so prikazana v vrstnem redu, kot so prikazana na strani od zgoraj navzdol. Vsako sporočilo je označeno vsaj z imenom sporočila. Po želji lahko dodate tudi argumente in nekaj kontrolnih informacij. Lahko prikažete samopooblastilo, sporočilo, ki ga objekt pošlje samemu sebi, pri čemer puščica sporočila kaže na isto rešilno vrv.

riž. 7. Primer diagrama zaporedja

4.3.2. Diagram sodelovanja

Diagrami sodelovanja prikaže tok dogodkov znotraj določenega scenarija (primer uporabe). Sporočila so razvrščena po času, čeprav se diagrami sodelovanja bolj osredotočajo na odnose med predmeti. Diagram sodelovanja prikazuje vse informacije, ki jih ima diagram zaporedja, vendar diagram sodelovanja opisuje tok dogodkov na drugačen način. Iz nje je lažje razumeti povezave, ki obstajajo med predmeti.

V diagramu sodelovanja, tako kot v diagramu zaporedja, puščice predstavljajo sporočila, ki se izmenjujejo v danem primeru uporabe. Njihovo časovno zaporedje je označeno s številčenjem sporočil.

riž. 8. Primer diagrama sodelovanja

4.4. razredni diagram

4.4.1. Splošne informacije

razredni diagram definira vrste sistemskih razredov in različne vrste statičnih povezav, ki obstajajo med njimi. Diagrami razredov prikazujejo tudi atribute razreda, operacije razreda in omejitve, ki so postavljene na odnose med razredi.

Diagram razredov v UML je graf, katerega vozlišča so elementi statične strukture projekta (razredi, vmesniki), loki pa razmerja med vozlišči (povezave, dedovanje, odvisnosti).

Diagram razreda prikazuje naslednje elemente:

· Paket (paket) - niz elementov modela, ki so med seboj logično povezani;

· Razred (razred) - opis skupnih lastnosti skupine podobnih predmetov;

· Vmesnik (vmesnik) – abstraktni razred, ki definira niz operacij, ki jih objekt poljubnega razreda, povezanega z danim vmesnikom, zagotavlja drugim objektom.

4.4.2. razred

razred je skupina entitet (objektov), ​​ki imajo podobne lastnosti, in sicer podatke in vedenje. Posamezen član razreda se imenuje predmet razreda ali preprosto objekt.

Obnašanje predmeta v UML se nanaša na vsa pravila za interakcijo predmeta z zunanjim svetom in s podatki samega objekta.

V diagramih je razred upodobljen kot pravokotnik s trdno obrobo, razdeljen z vodoravnimi črtami na 3 odseke:

Zgornji del (razdelek z imenom) vsebuje ime razreda in druge splošne lastnosti (zlasti stereotip).

Srednji del vsebuje seznam atributov

Na dnu je seznam operacij razreda, ki odražajo njegovo vedenje (dejanja, ki jih izvaja razred).

Noben od razdelkov atributov in operacij morda ne bo prikazan (ali oboje). Za manjkajoči odsek vam ni treba narisati ločnice in nekako označiti prisotnost ali odsotnost elementov v njem.

Dodatni razdelki, kot so izjeme, se lahko uvedejo po presoji posamezne izvedbe.

riž. 9. Primer diagrama razreda

4.4.2.1.Razredni stereotipi

Razredni stereotipi so mehanizem za razvrščanje razredov v kategorije.

UML opredeljuje tri glavne stereotipe razreda:

Meja (meja);

Entiteta (entiteta);

Nadzor (upravljanje).

4.4.2.2.Mejni razredi

Mejni razredi so tisti razredi, ki se nahajajo na meji sistema in celotnega okolja. To so zasloni, poročila, vmesniki s strojno opremo (kot so tiskalniki ali skenerji) in vmesniki z drugimi sistemi.

Če želite najti mejne razrede, morate raziskati diagrame primerov uporabe. Vsaka interakcija med akterjem in primerom uporabe mora imeti vsaj en mejni razred. Prav ta razred omogoča igralcu interakcijo s sistemom.

4.4.2.3.Entitetni razredi

Razredi entitet vsebujejo shranjene informacije. Za uporabnika imajo največji pomen, zato se v njihovih imenih pogosto uporabljajo izrazi s predmetnega področja. Običajno se za vsak razred entitete izdela tabela v bazi podatkov.

4.4.2.4.Kontrolni razredi

Kontrolni razredi so odgovorni za usklajevanje delovanja drugih razredov. Običajno ima vsak primer uporabe en kontrolni razred, ki nadzoruje zaporedje dogodkov za ta primer uporabe. Kontrolni razred je odgovoren za koordinacijo, vendar sam po sebi nima nobene funkcionalnosti, saj mu drugi razredi ne pošiljajo velikega števila sporočil. Namesto tega sam pošilja veliko sporočil. Razred manager preprosto prenese odgovornost na druge razrede, zato se pogosto imenuje razred manager.

V sistemu so lahko drugi kontrolni razredi, ki so skupni za več primerov uporabe. Na primer, lahko obstaja razred SecurityManager, ki je odgovoren za spremljanje dogodkov, povezanih z varnostjo. Razred TransactionManager upravlja koordinacijo sporočil, povezanih s transakcijami baze podatkov. Morda obstajajo drugi upravljavci, ki se ukvarjajo z drugimi elementi delovanja sistema, kot so souporaba virov, porazdeljena obdelava podatkov ali obravnavanje napak.

Poleg zgoraj omenjenih stereotipov lahko ustvarite svoje.

4.4.2.5.Lastnosti

Atribut je informacija, povezana z razredom. Atributi hranijo enkapsulirane podatke razreda.

Ker so atributi v razredu, so skriti pred drugimi razredi. Zaradi tega bo morda treba določiti, kateri razredi imajo pravico do branja in spreminjanja atributov. Ta lastnost se imenuje vidnost atributa.

Atribut ima lahko štiri možne vrednosti za ta parameter:

Javno (splošno, odprto). Ta vrednost vidnosti predvideva, da bo atribut viden vsem drugim razredom. Vsak razred si lahko ogleda ali spremeni vrednost atributa. V skladu z zapisom UML je pred skupnim atributom znak "+".

Zasebno (zaprto, tajno). Ustrezni atribut ni viden nobenemu drugemu razredu. Zasebni atribut je v skladu z zapisom UML označen z znakom "-".

Zaščiten (zaščiten). Takšen atribut je na voljo samo razredu samemu in njegovim potomcem. Oznaka UML za zaščiteni atribut je znak "#".

Paket ali izvedba (serija). Predpostavimo, da je dani atribut v skupni rabi, vendar samo znotraj svojega paketa. Ta vrsta vidnosti ni označena s posebno ikono.

S pomočjo zaprtosti ali varnosti se je mogoče izogniti situaciji, ko vrednost atributa spremenijo vsi razredi sistema. Namesto tega bo logika spreminjanja atributa zavita v isti razred kot sam atribut. Možnosti vidnosti, ki jih nastavite, bodo vplivale na ustvarjeno kodo.

4.4.2.6.Operacije

Operacije izvajajo vedenje, povezano z razredom. Operacija ima tri dele - ime, parametre in tip vrnitve.

Parametri so argumenti, ki jih operacija prejme kot vhod. Vrnitvena vrsta se nanaša na rezultat dejanja operacije.

V diagramu razredov lahko prikažete tako imena operacij kot imena operacij skupaj z njihovimi parametri in vrsto vrnitve. Za zmanjšanje obremenitve diagrama je koristno prikazati le imena operacij na nekaterih od njih, na drugih pa njihov popoln podpis.

V UML imajo operacije naslednji zapis:

Ime operacije (argument: podatkovni tip argumenta, argument2: podatkovni tip argument2,...): vrnitveni tip

Upoštevati je treba štiri različne vrste operacij:

Izvedbene operacije;

Poslovanje upravljanja;

Dostopne operacije;

Pomožne operacije.

Izvedbene operacije

Operacije izvajalca izvajajo nekatere poslovne funkcije. Takšne operacije je mogoče najti s pregledovanjem diagramov interakcij. Diagrami te vrste se osredotočajo na poslovne funkcije in vsako sporočilo v diagramu je najverjetneje povezano z operacijo izvajanja.

Vsaka operacija izvajanja mora biti zlahka sledljiva do ustrezne zahteve. To se doseže v različnih fazah simulacije. Operacija je izpeljana iz sporočila v interakcijskem diagramu, sporočila so izpeljana iz podrobnega opisa toka dogodkov, ki je generiran na podlagi primera uporabe, slednji pa na podlagi zahtev. Možnost sledenja tej celotni verigi pomaga zagotoviti, da je vsaka zahteva implementirana v kodi in vsak kos kode izvaja neko zahtevo.

Poslovanje upravljanja

Operacije upravitelja upravljajo ustvarjanje in uničenje objektov. Konstruktorji in destruktorji razreda spadajo v to kategorijo.

Dostopne operacije

Atributi so običajno zasebni ali zaščiteni. Vendar pa morajo drugi razredi včasih videti ali spremeniti svoje vrednosti. Za to obstajajo operacije dostopa. Ta pristop omogoča varno kapsuliranje atributov znotraj razreda, ki jih ščiti pred drugimi razredi, vendar še vedno omogoča nadzorovan dostop do njih. Ustvarjanje operacij Get in Set (pridobivanje in spreminjanje vrednosti) za vsak atribut razreda je standard.

Pomožne operacije

Pomožne (pomožne operacije) so tiste operacije razreda, ki so potrebne za izpolnjevanje svojih nalog, o katerih drugi razredi ne bi smeli vedeti ničesar. To so operacije zasebnega in zaščitenega razreda.

Če želite prepoznati transakcije, naredite naslednje:

1. Preučite diagrame zaporedja in kooperativne diagrame. Večina sporočil v teh diagramih je izvedbenih operacij. Odsevna sporočila bodo pomožne operacije.

2. Razmislite o kontrolnih operacijah. Morda boste morali dodati konstruktorje in destruktorje.

3. Razmislite o operacijah dostopa. Za vsak atribut razreda, s katerim bodo morali delati drugi razredi, morate ustvariti operacije Get in Set.

4.4.2.7.Povezave

Razmerje je pomensko razmerje med razredi. Razredu daje možnost, da se uči o atributih, operacijah in odnosih drugega razreda. Z drugimi besedami, da lahko en razred pošlje sporočilo drugemu v zaporednem ali kooperativnem diagramu, mora med njimi obstajati povezava.

Obstajajo štiri vrste odnosov, ki jih je mogoče vzpostaviti med razredi: asociacije, odvisnosti, združevanja in posplošitve.

Komunikacijsko združenje

Asociacija je pomensko razmerje med razredi. Na diagramu razredov so narisane kot navadna črta.

riž. 10. Komunikacijsko združenje

Združitve so lahko dvosmerne, kot v primeru, ali enosmerne. V UML so dvosmerne povezave narisane kot preprosta črta brez puščic ali s puščicami na obeh straneh črte. Enosmerna zveza ima samo eno puščico, ki kaže njeno smer.

Smer združenja je mogoče določiti s preučevanjem diagramov zaporedja in diagramov sodelovanja. Če vsa sporočila na njih pošlje samo en razred in jih prejme samo drug razred, ne pa obratno, obstaja enosmerna komunikacija med temi razredi. Če je vsaj eno sporočilo poslano v nasprotni smeri, mora biti povezava dvosmerna.

Asociacije so lahko refleksivne. Refleksna povezava pomeni, da en primerek razreda komunicira z drugimi primerki istega razreda.

Zasvojenost s komunikacijo

Relacije odvisnosti odražajo tudi razmerje med razredi, vendar so vedno enosmerne in kažejo, da je en razred odvisen od definicij drugega. Na primer, razred A uporablja metode razreda B. Potem, ko se razred B spremeni, je treba narediti ustrezne spremembe v razredu A.

Odvisnost je predstavljena s črtkano črto, narisano med dvema elementoma diagrama, element, zasidran na koncu puščice, pa naj bi bil odvisen od elementa, zasidranega na začetku te puščice.

riž. 11. Zasvojenost s komunikacijo

Pri generiranju kode za te razrede jim ne bodo dodani novi atributi. Vendar pa bodo ustvarjeni operaterji, specifični za jezik, ki so potrebni za podporo komunikacije.

Komunikacijsko združevanje

Združitve so tesnejša oblika povezovanja. Agregacija je povezava med celoto in njenim delom. Na primer, morda imate razred avtomobilov, pa tudi razrede motorja, pnevmatike in razrede za druge avtomobilske dele. Posledično bo objekt razreda Car sestavljen iz predmeta razreda Engine, štirih objektov Tires itd. Agregacije so vizualizirane kot črta z rombom za razred, ki je celo število:

riž. 11. Komunikacijsko združevanje

Poleg preprostega združevanja UML uvaja močnejšo obliko združevanja, imenovano sestava. Po sestavi lahko del predmeta pripada samo eni celoti, poleg tega pa življenjski cikel delov praviloma sovpada s ciklom celote: z njim živijo in umirajo. Vsaka odstranitev celote sega na njene dele.

To kaskadno brisanje se pogosto šteje za del definicije združevanja, vendar je vedno implicirano, ko je množica vlog 1..1; na primer, če je treba stranko izbrisati, se mora ta izbris razširiti na naročila (in posledično na vrstice naročil).

UML je grafični jezik za modeliranje splošnega namena za specifikacijo, vizualizacijo, načrtovanje in dokumentacijo vseh artefaktov, ustvarjenih pri razvoju programskih sistemov.

Obstaja veliko dobrih knjig, ki podrobno opisujejo UML (včasih celo zelo podrobno), na enem mestu bi rad zbral osnovne pojme o diagramih, entitetah in odnosih med njimi za hiter priklic, nekaj podobnega kot goljuf.

Zapis uporablja gradivo iz knjig: Ivanov D. Yu., Novikov F. A. Poenoten jezik modeliranja UML in Leonenkov. Vadnica za UML.

Začnimo z urednikom. Pod Linuxom sem preizkusil različne urejevalnike UML, najbolj mi je bil všeč UMLet, čeprav je napisan v Javi, se zelo hitro premika in je v njem večina praznih entitet. Obstaja tudi ArgoUML, večplatformski urejevalnik UML, prav tako napisan v Javi, funkcionalno bogat, vendar bolj upočasnjen.

Ustavil sem se pri UMLet, ga namestite pod Arch Linux in ubuntu:

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

V UML lahko vse entitete razdelimo na naslednje vrste:

• strukturni;
• vedenjski;
• združevanje v skupine;
• opomba;

UML uporablja štiri glavne vrste odnosov:

Odvisnost- označuje, da sprememba neodvisnega subjekta na nek način vpliva na odvisno entiteto. Grafično je razmerje odvisnosti prikazano kot pikčasta črta s puščico, ki kaže od odvisne entitete na neodvisno entiteto.

Združenje- poteka, če je ena entiteta neposredno povezana z drugo (ali z drugimi - povezava ni lahko samo binarna). Grafično je asociacija prikazana kot polna črta z različnimi dodatki, ki povezujejo povezane entitete.

Posploševanje je razmerje med dvema entitetama, od katerih je ena poseben (specializiran) primer druge. Grafično je posploševanje prikazano kot črta s trikotno neizpolnjeno puščico na koncu, usmerjeno od posebnega (podrazreda) k splošnemu (nadrazredu).

Izvedbe- relacija izvajanja kaže, da je ena entiteta implementacija druge. Grafično je izvedba prikazana kot pikčasta črta s trikotno neizpolnjeno puščico na koncu, usmerjeno od izvajalske enote do izvedene.

AT UML 2 opredeljeno 13 vrste grafikonov. Po standardih mora vsak grafikon imeti okvir s pravokotnikom (spodnji desni kot poševno) v zgornjem levem kotu, ki označuje ID (oznako) grafikona in naslov.

Diagrami za prikaz strukture sistema:

• Diagram komponent (diagram komponent, oznaka komponento);
• Diagram uvajanja (diagram uvajanja, oznaka uvajanje);
• Diagram razreda (razredni diagram, oznaka razred);
• Objektni diagram (objektni diagram, oznaka predmet);
• Notranji strukturni diagram (sestavljeni strukturni diagram, oznaka razred);

Diagrami za prikaz obnašanja sistema:

• Sinhronizacijski diagram (diagram interakcije, oznaka čas);
• Diagram aktivnosti (diagram aktivnosti, oznaka dejavnost);
• diagram zaporedja (diagram zaporedja, oznaka sd);
• Komunikacijski diagram (komunikacijski diagram, oznaka kom);
• Diagram avtomata (diagram državnega stroja, oznaka državni stroj);
• Pregledni diagram interakcije, oznaka interakcijo);

Izstopajo grafikoni:

• Diagram primerov uporabe (diagram primerov uporabe, oznaka primera uporabe);
• Diagram paketa (diagram paketa, oznaka paket);

Diagram uporabe

Diagram uporabe(diagram primerov uporabe) je najbolj splošen prikaz funkcionalnega namena sistema.

Če upoštevamo diagram primerov uporabe kot model sistema, ga lahko povežemo z modelom črne škatle. Vsak primer uporabe definira zaporedje dejanj, ki jih mora izvesti zasnovan sistem, ko je v interakciji z ustreznim akterjem.

Diagram uporabe uporablja dve vrsti osnovnih entitet: primere uporabe in akterje, med katerimi so vzpostavljene naslednje osnovne vrste razmerij.

asociacijski odnos- Ta odnos določa, kakšno specifično vlogo igra igralec pri interakciji s primerom primera uporabe. Povezavo razmerje je označeno s polno črto med akterjem in primerom uporabe. Ta vrstica ima lahko dodatne simbole, kot sta na primer ime in množica.

Razširitveni odnos- opredeljuje razmerje med primeri posameznega primera uporabe s splošnim primerom uporabe, katerega lastnosti se določijo glede na način, kako so ti primerki združeni skupaj. Če torej obstaja razmerje razširitve od primera uporabe A do primera uporabe B, potem to pomeni, da se lastnosti primera uporabe B lahko dopolnijo zaradi prisotnosti lastnosti v razširjenem primeru uporabe A.

Razmerje razširitve med primeri uporabe je označeno s črtkano črto s puščico (primer razmerja odvisnosti), ki kaže stran od primera uporabe, ki je razširitev prvotnega primera uporabe.

Relacija posploševanja služi za označevanje dejstva, da je mogoče nek primer uporabe A posplošiti na primer uporabe B. V tem primeru bo primer uporabe A specializacija primera uporabe B. V tem primeru se B imenuje prednik ali starš A in uporablja A je potomec uporabe V.

Grafično je to razmerje predstavljeno s polno črto z odprto trikotno puščico, ki kaže na nadrejeni primer uporabe.

Razmerje posploševanja med primeri uporabe se uporablja, ko je treba opozoriti, da imajo otroški primeri uporabe vse atribute in vedenje primerov starševske uporabe.

Relacija vključevanja med dvema primeroma uporabe pomeni, da je določeno vedenje za en primer uporabe vključeno kot komponenta v zaporedju vedenja drugega primera uporabe.

Razmerje vključitve, od primera uporabe A do primera uporabe B, kaže, da vsak primer uporabe A vključuje funkcionalne lastnosti, določene za primer uporabe B.

Grafično je to razmerje predstavljeno s pikčasto črto s puščico (različica odvisnosti), ki kaže od osnovnega primera uporabe do vključenega primera uporabe.

razredni diagram

razredni diagram(diagram razreda) - glavni način za opis statične strukture sistema.

Diagram razredov uporablja eno glavno vrsto entitet: razrede (vključno s številnimi posebnimi primeri razredov: vmesniki, primitivni tipi, asociacijski razredi itd.), med katerimi so vzpostavljene naslednje glavne vrste odnosov: odvisnosti, asociacije, posplošitve, implementacije.

Odnos odvisnosti na splošno označuje neko pomensko razmerje med dvema elementoma modela ali dvema nizoma takšnih elementov, ki ni povezava, posplošitev ali implementacijski odnos. Razmerje odvisnosti se uporablja v situaciji, ko lahko neka sprememba v enem elementu modela zahteva spremembo drugega odvisnega elementa modela.

Razmerje odvisnosti je grafično predstavljeno s črtkano črto med ustreznimi elementi s puščico na enem koncu, pri čemer puščica kaže od odjemalskega razreda odvisnosti do neodvisnega ali izvornega razreda.

Nad puščico lahko postavite posebne ključne besede (stereotipe):

• "dostop" - služi za označevanje razpoložljivosti javnih atributov in operacij izvornega razreda za odjemalske razrede;
• "bind" - odjemalski razred lahko uporabi nekaj predloge za svojo kasnejšo parametrizacijo;
• "izpeljani" - atribute odjemalskega razreda je mogoče izračunati iz atributov izvornega razreda;
• "uvoz" - javni atributi in operacije izvornega razreda postanejo del odjemalskega razreda, kot da bi bili deklarirani neposredno v njem;
• "izboljšati" - označuje, da razred odjemalca služi kot izpopolnitev izvornega razreda iz zgodovinskih razlogov, ko postanejo dodatne informacije na voljo med delom na projektu.

asociacijski odnos ustreza prisotnosti nekega razmerja med razredi. Ta odnos je označen s polno črto z dodatnimi posebnimi simboli, ki označujejo posamezne lastnosti določene zveze. Kot dodatne posebne znake se lahko uporabi ime združenja, pa tudi imena in množica razredov vlog združenja. Ime združenja je neobvezen element njegove označbe.

Agregacijski odnos se pojavi med več razredi, če je eden od razredov entiteta, ki vključuje druge entitete kot komponente. Uporablja se za predstavitev sistemskih razmerij tipa "del-celota".

Kompozicijski odnos je poseben primer agregacijske relacije. Ta odnos služi za poudarjanje posebne oblike razmerja del-celota, v katerem so sestavni deli v nekem smislu znotraj celote. Posebnost razmerja med njimi je v tem, da deli ne morejo delovati ločeno od celote, torej se z uničenjem celote uničijo tudi vsi njeni sestavni deli.

Relacija posploševanja je razmerje med bolj splošnim elementom (starš ali prednik) in bolj specifičnim ali posebnim elementom (otrok ali potomec). Kot se uporablja za diagram razredov, ta odnos opisuje hierarhično strukturo razredov in dedovanje njihovih lastnosti in obnašanja. To predpostavlja, da ima razred potomcev vse lastnosti in obnašanje razreda prednikov ter ima tudi lastne lastnosti in obnašanje, ki niso prisotni v razredu prednikov.

avtomatski diagram

avtomatski diagram(diagram državnega stroja) oz diagram stanja v UML 1 (diagram stanja) je eden od načinov za podrobno opisovanje obnašanja v UML. V bistvu so avtomatski diagrami, kot pove že ime, graf stanj in prehodov končnega avtomata, naložen s številnimi dodatnimi podrobnostmi in podrobnostmi.

Diagram stanja opisuje proces spreminjanja stanj samo enega razreda ali bolje rečeno enega primerka določenega razreda, torej modelira vse možne spremembe stanja določenega predmeta. V tem primeru lahko spremembo stanja predmeta povzročijo zunanji vplivi drugih predmetov ali od zunaj. Za opis reakcije predmeta na takšne zunanje vplive se uporabljajo diagrami stanja.

V avtomatskem diagramu se uporablja ena glavna vrsta entitete - stanja in ena vrsta razmerja - prehodi, za oba pa je opredeljenih veliko sort, posebnih primerov in dodatnih oznak. Avtomat predstavlja dinamične vidike simuliranega sistema v obliki usmerjenega grafa, katerega oglišča ustrezajo stanjem, loki pa prehodom.

Začetno stanje je poseben primer stanja, ki ne vsebuje nobenih notranjih dejanj (psevdo-stanja). Objekt je v tem stanju privzeto v začetnem trenutku. Služi za označevanje na diagramu stanja grafičnega območja, s katerega se začne proces spreminjanja stanj.

Finale (finale) stanje je poseben primer stanja, ki tudi ne vsebuje nobenih notranjih dejanj (psevdostanja). Objekt bo privzeto v tem stanju po zaključku avtomata ob končnem času.

diagram aktivnosti

Pri modeliranju obnašanja projektiranega ali analiziranega sistema je potrebno ne le predstaviti proces spreminjanja njegovih stanj, ampak tudi podrobno podrobno opisati značilnosti algoritemske in logične izvedbe operacij, ki jih sistem izvaja.

diagram aktivnosti(diagram dejavnosti) je še en način opisovanja vedenja, ki je vizualno podoben dobremu staremu diagramu poteka algoritma. Uporablja se za simulacijo procesa izvajanja operacij.

Glavna smer uporabe diagramov aktivnosti je vizualizacija značilnosti izvajanja operacij razreda, ko je treba predstaviti algoritme za njihovo izvajanje.

V diagramu aktivnosti je uporabljena ena glavna vrsta entitet - akcija in ena vrsta razmerja - prehodi (prenosi nadzora). Uporabljajo se tudi takšne konstrukcije, kot so vilice, združitve, povezave, odcepi. Za ime preprostega dejanja je priporočljivo uporabiti glagol s pojasnjevalnimi besedami.

diagram zaporedja

diagram zaporedja(diagram zaporedja) je način opisovanja obnašanja sistema "s primeri".

Dejansko je diagram zaporedja zapis protokola določene seje sistema (ali fragment takega protokola). Pri objektno usmerjenem programiranju je najpomembnejša stvar v času izvajanja posredovanje sporočil med sodelujočimi objekti. Na tem diagramu je prikazano zaporedje pošiljanja sporočil, od tod tudi ime.

V diagramu zaporedja je uporabljena ena glavna vrsta entitet – primeri medsebojno delujočih klasifikatorjev (predvsem razredi, komponente in akterji) in ena vrsta razmerij – povezave, prek katerih se izmenjujejo sporočila.

Možne vrste sporočil (slika vzeta iz larin.in):

Komunikacijski diagram

Komunikacijski diagram(komunikacijski diagram) - način opisovanja vedenja, pomensko enakovreden diagramu zaporedja. Pravzaprav je to isti opis zaporedja izmenjave sporočil medsebojno delujočih primerkov klasifikatorjev, le izražen z drugimi grafičnimi sredstvi.

Tako se v komunikacijskem diagramu, pa tudi v diagramu zaporedja, uporablja ena glavna vrsta entitet - primeri medsebojno delujočih klasifikatorjev in ena vrsta razmerja - povezave. Vendar tu ni poudarek na času, temveč na strukturi odnosov med posameznimi primeri.

Diagram komponent

Diagram komponent(komponentni diagram) - prikazuje razmerje med moduli (logičnimi ali fizičnimi), ki sestavljajo simulirani sistem.

Glavni tip entitete v diagramu komponent so komponente same, pa tudi vmesniki, prek katerih je prikazano razmerje med komponentami. V diagramu komponent veljajo naslednja razmerja:

• implementacije med komponentami in vmesniki (komponenta implementira vmesnik);
• odvisnosti med komponentami in vmesniki (komponenta uporablja vmesnik);

Diagram umestitve

Diagram umestitve(diagram razmestitve) skupaj s prikazom sestave in razmerij sistemskih elementov prikazuje, kako so med izvajanjem fizično nameščeni na računalniške vire.

V diagramu umestitve sta v primerjavi z diagramom komponent dodani dve vrsti entitet: artefakt, ki je izvedba komponente, in vozlišče (lahko je bodisi klasifikator, ki opisuje vrsto vozlišča, ali določen primer) , kot tudi povezovalni odnos med vozlišči, ki kaže, da so vozlišča med izvajanjem fizično povezana.

Diagram objekta

Diagram objekta(objektni diagram) - je primerek diagrama razreda.

V diagramu objektov je uporabljena ena glavna vrsta entitet: objekti (primerki razreda), med katerimi so navedena posebna razmerja (najpogosteje asociacijski primerki). Diagrami objektov so pomožne narave – pravzaprav so to primeri (lahko bi rekli, pomnilniki), ki prikazujejo, kateri objekti obstajajo in razmerja med njimi v določenem trenutku delovanja sistema.

Diagram notranje strukture(diagram sestavljene strukture) se uporablja za podrobnejšo predstavitev strukturnih klasifikatorjev, predvsem razredov in komponent.

Strukturni klasifikator je prikazan kot pravokotnik z imenom klasifikatorja na vrhu. V notranjosti so deli. Lahko je več delov. Deli lahko medsebojno delujejo. Na to kažejo priključki različnih vrst. Mesto na zunanjem robu dela, na katerega je pritrjen konektor, se imenuje vrata. Vrata se nahajajo tudi na zunanji meji strukturnega klasifikatorja.

Pregledni diagram interakcij(diagram pregleda interakcije) je neke vrste diagram aktivnosti z razširjeno sintakso: povezave do interakcij (uporaba interakcije), opredeljene z diagrami zaporedja, lahko delujejo kot elementi preglednega interakcijskega diagrama.

Časovni diagram

Časovni diagram(časovni diagram) je posebna oblika zaporednega diagrama, v katerem je posebna pozornost namenjena spremembi stanj različnih primerkov klasifikatorjev in njihovi časovni sinhronizaciji.

Diagram paketa

Diagram paketa(diagram paketa) je edino orodje, ki vam omogoča upravljanje s kompleksnostjo samega modela.

Glavni elementi zapisa so paketi in odvisnosti z različnimi stereotipi.

Model razmerja med entitetami (ER-model)

analogni razredni diagrami(UML) je lahko ER model, ki se uporablja pri oblikovanju baz podatkov (relacijski model).

Model razmerja med entitetami (ER-model) je podatkovni model, ki vam omogoča, da opišete konceptualne sheme predmetnega področja. Model ER se uporablja pri oblikovanju baz podatkov na visoki ravni (konceptualni). Z njegovo pomočjo lahko označite ključne entitete in označite odnose, ki jih je mogoče vzpostaviti med temi entitetami. wikipedia

Vsak del predmetnega področja je mogoče predstaviti kot niz entitet, med katerimi obstaja nekaj odnosov.

Osnovni koncepti:

Bistvo(entiteta) je entiteta, ki jo je mogoče identificirati na nek način, ki jo razlikuje od drugih entitet, npr. STRANKA 777. Entiteta je pravzaprav niz atributov.

Nabor entitet(nabor entitet) - niz entitet istega tipa (z enakimi lastnostmi).

Povezava(razmerje) je povezava, vzpostavljena med več subjekti.

domena(domena) - niz vrednosti (domena) atributa.

Obstajajo tri vrste binarnih povezav:

• ena proti ena- en sam primerek entitete enega razreda je povezan z enim samim primerkom entitete drugega razreda, na primer VODJA - ODDELEK;
• 1 do N oz ena proti mnogim- en sam primerek entitete enega razreda je povezan z mnogimi primerki entitete drugega razreda, na primer ODDELEK - ZAPOSLENI;
• N do M oz veliko do mnogih- veliko primerkov entitete enega razreda je povezanih s številnimi primerki entitete drugega razreda, na primer ZAPOSLENI - PROJEKT;
Slovarček osnovnih pojmov v UML

predmet- entiteta, ki ima edinstvenost in zajema stanje in vedenje.

razred- opis niza objektov s skupnimi atributi, ki opredeljujejo stanje, in operacije, ki definirajo vedenje.

vmesnik- poimenovani niz operacij, ki definira nabor storitev, ki jih lahko zahteva potrošnik in jih zagotovi ponudnik storitev.

Sodelovanje- niz predmetov, ki medsebojno delujejo za dosego nekega cilja.

igralec- entiteta, ki je zunaj modeliranega sistema in z njim neposredno sodeluje.

komponento- modularni del sistema z natančno opredeljenim naborom zahtevanih in zagotovljenih vmesnikov.

Artefakt- element informacije, ki se uporablja ali generira v procesu razvoja programske opreme. Z drugimi besedami, artefakt je fizična enota izvedbe, ki izhaja iz elementa modela (kot je razred ali komponenta).

vozlišče- računalniški vir, na katerega so postavljeni in po potrebi izvedeni artefakti.

Vedenjski subjekti so namenjeni opisovanju vedenja. Obstajata le dve osnovni vedenjski entiteti: stanje in dejanje.

država- obdobje v življenjskem ciklu predmeta, v katerem predmet izpolnjuje določen pogoj in opravlja svojo dejavnost ali čaka na nastop nekega dogodka.

dejanje- primitivni atomski izračun.

Stroj je paket, ki definira nabor konceptov, potrebnih za predstavitev obnašanja modelirane entitete kot diskretnega prostora s končnim številom stanj in prehodov.

klasifikator je deskriptor za niz predmetov iste vrste.

Dodatno branje

• Fowler M. UML. Osnove, 3. izdaja
• Butch G., Rambo D., Jacobson I. Jezik UML. Uporabniški priročnik

UML je akronim za Unified Modeling Language. Pravzaprav je ena izmed najbolj priljubljenih tehnik modeliranja poslovnih procesov in je mednarodni standardni zapis za določanje, vizualizacijo in dokumentiranje razvoja programske opreme. Opredeljena s strani skupine za upravljanje objektov, se je pojavila kot rezultat več dodatnih sistemov zapisov UML in je zdaj postala de facto standard za vizualno modeliranje. Temeljno načelo vsakega objektno usmerjenega programiranja se začne z gradnjo modela.

UML je nastal iz kaosa okoli razvoja programske opreme in dokumentacije. V devetdesetih letih prejšnjega stoletja je obstajalo več različnih načinov predstavljanja programskih sistemov. Potreben je bil bolj poenoten vizualni način UML za predstavitev teh sistemov, zato so ga med letoma 1994 in 1996 razvili trije programski inženirji, ki so delali pri Rational Software. Kasneje je bil sprejet kot standard leta 1997 in je tako ostal do danes z le nekaj posodobitvami.

V bistvu je UML splošni jezik za modeliranje na področju razvoja programske opreme. Vendar pa se je zdaj znašel v dokumentaciji več poslovnih procesov ali delovnih tokov, kot so diagrami dejavnosti. Tip diagrama UML se lahko uporablja kot zamenjava za diagrame poteka. Zagotavljajo tako bolj standardiziran način modeliranja delovnih tokov kot širok nabor funkcij za izboljšanje berljivosti in učinkovitosti.

Arhitektura temelji na metaobjektu, ki definira osnovo za ustvarjanje jezika UML. Je dovolj natančen, da ustvarite celotno aplikacijo. Popolnoma izvedljiv UML se lahko namesti na več platformah z uporabo različnih tehnologij z vsemi procesi skozi celoten cikel razvoja programske opreme.

UML je zasnovan za uporabnike, da razvijejo jezik vizualnega modeliranja. Podpira koncepte razvoja na visoki ravni, kot so strukture, vzorci in sodelovanja. UML je zbirka elementov, kot so:

1. Stavki programskega jezika.
2. Akterji opisujejo vlogo uporabnika ali katerega koli drugega sistema, ki je v interakciji s predmetom.
3. Dejavnosti, ki jih je treba izvesti za izvedbo pogodbe o delu in biti predstavljene v diagramih.
4. Poslovni proces, ki vključuje niz nalog, ki ustvarjajo določeno storitev za stranke, vizualizirano z diagramom poteka zaporednih dejanj.
5. Logične in večkrat uporabne programske komponente.

UML diagrami so razdeljeni v dve kategoriji. Prva vrsta vključuje sedem vrst diagramov, ki predstavljajo strukturne informacije, druga - preostalih sedem, ki predstavljajo splošne vrste vedenja. Ti diagrami se uporabljajo za dokumentiranje arhitekture sistemov in so neposredno vključeni v modeliranje sistema UML.

UML diagrami so predstavljeni kot statični in dinamični prikazi modela sistema. Statični pogled vključuje razredne in sestavljene strukturne diagrame, ki poudarjajo statično strukturo. Dinamični pogled predstavlja interakcijo med objekti in spremembami v notranjih stanjih objektov z uporabo diagramov zaporedja, aktivnosti in stanja.

Za poenostavitev modeliranja je na voljo široka paleta orodij za modeliranje UML, vključno z IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner in Dia.

Uporaba UML ima različne oblike tako v dokumentaciji za razvoj programske opreme kot v poslovnih procesih:

1. Skica. V tem primeru se diagrami UML uporabljajo za prenos različnih vidikov in značilnosti sistema. Vendar je to le pogled na sistem z najvišje ravni in najverjetneje ne bo vključeval vseh potrebnih podrobnosti za izvedbo projekta do samega konca.
2. Naprej načrt – načrtovanje skice se izvede, preden je aplikacija kodirana. To je storjeno za boljši pregled nad sistemom ali potekom dela, ki ga uporabnik poskuša ustvariti. Ugotoviti je mogoče številne težave ali pomanjkljivosti pri načrtovanju, kar bo izboljšalo splošno zdravje in dobro počutje projekta.
3. Reverzni dizajn. Ko je koda napisana, se UML diagrami pojavijo kot oblika dokumentacije za različne dejavnosti, vloge, sodelavce in poteke dela.
4. Načrt. V tem primeru diagram služi kot popolna konstrukcija, ki zahteva le dejansko izvedbo sistema ali programske opreme. To se pogosto izvaja z orodji CASE (Computer Aided Software Engineering Tools). Glavna pomanjkljivost uporabe orodij CASE je, da zahtevajo določeno raven znanja, usposabljanja uporabnikov ter vodenja in osebja.

UML ni samostojen programski jezik, kot je Java, C++ ali Python, vendar se lahko s pravimi orodji spremeni v psevdoprogramski jezik UML. Za dosego tega cilja je treba celoten sistem dokumentirati v različnih diagramih, z uporabo prave programske opreme pa je mogoče diagrame neposredno prevesti v kodo. Ta metoda je lahko uporabna le, če čas, porabljen za risanje diagramov, traja manj časa kot pisanje dejanske kode. Čeprav je bil UML ustvarjen za sistemsko modeliranje, je našel več uporab na poslovnih področjih.

Sledi primer UML diagrama za poslovno modeliranje.

Ena praktična rešitev bi bila vizualna predstavitev poteka procesa za televizijsko prodajo prek diagrama aktivnosti. Od trenutka, ko je naročilo vzeto kot vhod, do trenutka, ko je naročilo zaključeno in podan določen izhod.

Obstaja več vrst UML diagramov in vsak od njih opravlja drugačno nalogo, ne glede na to, ali je razvit pred implementacijo ali po njej, kot del dokumentacije. Dve najširši kategoriji, ki pokrivata vse druge vrste, sta vedenjski diagram in strukturni diagram. Kot že ime pove, nekateri UML diagrami poskušajo analizirati in prikazati strukturo sistema ali procesa, drugi pa opisujejo obnašanje sistema, njegovih udeležencev in komponent.

Različne vrste so razdeljene na naslednji način:

1. Vseh 14 različnih vrst UML diagramov se ne uporablja redno pri dokumentiranju sistemov in arhitektur.
2. Paretovo načelo velja tudi za uporabo UML diagramov.
3. 20 % diagramov razvijalci uporabljajo 80 % časa.

Najpogosteje uporabljeni elementi pri razvoju programske opreme so:

• diagrami uporabe;
• diagrami razredov;
• zaporedja.

Diagrami aktivnosti – Najpomembnejši UML diagrami za ustvarjanje modelov poslovnih procesov. Pri razvoju programske opreme se uporabljajo za opis poteka različnih dejavnosti. Lahko so serijski ali vzporedni. Opisujejo predmete, ki jih dejavnost uporablja, porabi ali proizvede, in razmerje med različnimi dejavnostmi.

Vse našteto je bistveno za modeliranje poslovnih procesov, ki vodijo od enega do drugega, saj so med seboj povezani z jasnim začetkom in koncem. V poslovnem okolju se to imenuje tudi preslikava poslovnih procesov. Glavni akterji so avtor, urednik in založnik. Primer UML je naslednji. Ko recenzent pregleda projekt in se odloči, da je treba narediti nekaj sprememb. Avtor nato pregleda osnutek in ga ponovno vrne v analizo.

Diagram uporabe

Temelj sistema - uporablja se za analizo zahtev za sistemsko raven. Te zahteve so izražene v različnih primerih uporabe. Tri glavne komponente diagrama UML so:

1. Funkcionalno - predstavljeno kot primeri uporabe.
2. Glagol, ki opisuje dejanje.
3. Akterji - za interakcijo s sistemom. Akterji so lahko uporabniki, organizacije ali zunanji zahtevek. Odnosi med udeleženci so predstavljeni z ravnimi puščicami.

Na primer za diagram upravljanja zalog. V tem primeru so lastnik, dobavitelj, vodja, inventar in inšpektor. Okrogle posode predstavljajo dejanja, ki jih izvajajo igralci. Možna dejanja: nakup in plačilo delnic, preverjanje kakovosti zalog, vračilo zalog ali distribucija zalog.

Ta vrsta diagrama je zelo primerna za prikaz dinamičnega vedenja med udeleženci v sistemu, zaradi česar je lažje predstaviti brez prikazovanja podrobnosti izvedbe.

Začasno

Časovni diagrami UML se uporabljajo za predstavitev odnosov med objekti, ko je fokus odvisen od časa. V tem primeru ni zanimivo, kako objekti medsebojno delujejo ali se spreminjajo, ampak si želi uporabnik predstavljati, kako objekti in subjekti delujejo vzdolž linearne časovne osi.

Vsak posamezni udeleženec je predstavljen skozi rešilno vrv, ki je v bistvu linija, ki tvori faze, ko se posamezni udeleženec premika iz ene stopnje v drugo. Glavna pozornost je namenjena trajanju časa dogodkov in spremembam, ki nastanejo glede na to.

Glavne komponente časovnega diagrama so:

1. Lifeline je individualni član.
2. Časovna os stanja - edina življenjska pot lahko poteka skozi različna stanja znotraj procesa.
3. Omejitev trajanja – omejitev časovnega intervala, ki predstavlja trajanje omejitve, ki je potrebna za izpolnitev.
4. Časovna omejitev - Omejitev časovnega intervala, v katerem mora udeleženec nekaj izvesti.
5. Destruction Emergence – pojav sporočila, ki uniči posameznega člana in prikazuje konec življenjskega cikla tega člana.

Horizontalni diagrami, imenovani tudi grafikoni stanja, se uporabljajo za opis različnih stanj komponente znotraj sistema. Zavzame končno obliko imena, ker je diagram v bistvu stroj, ki opisuje več stanj predmeta in kako se spreminja na podlagi notranjih in zunanjih dogodkov.

Zelo preprost diagram stanja stroja bi bil v igri šaha. Tipična šahovska igra je sestavljena iz potez, ki jih naredijo beli, in potez, ki jih naredijo črni. Beli imajo prvo potezo in tako začnejo igro. Konec igre se lahko zgodi ne glede na to, ali zmaga beli ali črni. Igra se lahko konča z tekmo, odstopom ali remijem (različna stanja avtomobila). Grafikoni stanja se uporabljajo predvsem pri načrtovanju UML naprej in nazaj različnih sistemov.

Zaporedno

Ta vrsta diagramov je najpomembnejši UML diagram ne le v računalniški skupnosti, temveč tudi kot modeli na ravni načrtovanja za razvoj poslovnih aplikacij. Zaradi svoje vizualno samoumevne narave so priljubljeni pri opisovanju poslovnih procesov. Kot pove že ime, diagrami opisujejo zaporedje sporočil in interakcij, ki potekajo med subjekti in predmeti. Akterji ali predmeti so lahko aktivni le, kadar je to potrebno ali ko želi drug objekt komunicirati z njimi. Vsa sporočila so predstavljena v kronološkem vrstnem redu.

Za več informacij si oglejte spodnji primer diagrama zaporedja UML.

Kot izhaja iz primera, se strukturni diagrami uporabljajo za prikaz strukture sistema. Natančneje, jezik se uporablja pri razvoju programske opreme, da predstavi arhitekturo sistema in kako so različne komponente povezane.

Diagram razreda UML je najpogostejša vrsta diagrama za dokumentacijo programske opreme. Ker večina programske opreme, ki se trenutno piše, še vedno temelji na paradigmi objektno usmerjenega programiranja, je uporaba razrednih diagramov za dokumentiranje programske opreme zdrava pamet. To je zato, ker OOP temelji na razredih UML in odnosih med njimi. Na kratko, grafikoni vsebujejo razrede, skupaj z njihovimi atributi, imenovanimi tudi podatkovna polja, in njihovo vedenje, imenovane funkcije članov.

Natančneje, vsak razred ima 3 polja: ime na vrhu, atributi tik pod imenom, operacije/vedenje na dnu. Razmerje med različnimi razredi (predstavljeno z vezno črto) sestavlja diagram razredov. Zgornji primer prikazuje osnovni diagram razreda.

Predmeti

Ko razpravljate o strukturnih diagramih UML, se morate poglobiti v koncepte, povezane z računalništvom. V programskem inženiringu se razredi obravnavajo kot abstraktni podatkovni tipi, objekti pa so primerki. Na primer, če obstaja "Car", ki je generični abstraktni tip, bi bil primerek razreda "Car" "Audi".

Diagrami objektov UML pomagajo razvijalcem programske opreme preveriti, ali je ustvarjena abstraktna struktura izvedljiva struktura, ko se izvaja v praksi, to je, ko so objekti ustvarjeni. Nekateri razvijalci menijo, da je to sekundarna raven preverjanja točnosti. Prikazuje primerke razreda. Natančneje, generični razred "Client" ima zdaj dejanskega odjemalca, na primer z imenom "James". James je primer splošnejšega razreda in ima enake atribute, vendar z danimi vrednostmi. Enako je bilo storjeno z računi in varčevalnimi računi. Oba sta predmeta svojih razredov.

Namestitve

Diagrami uvajanja se uporabljajo za vizualizacijo razmerja med programsko in strojno opremo. Natančneje, z diagrami uvajanja lahko zgradimo fizični model, kako so komponente programske opreme (artefakti) razporejene v komponente strojne opreme, znane kot vozlišča.

Tipična poenostavljena shema uvajanja spletne aplikacije bi vključevala:

1. Vozlišča (strežnik aplikacij in strežnik baz podatkov).
2. Diagram artefaktov odjemalske aplikacije in baze podatkov.

Diagram paketa je podoben makrom za diagrame UML za uvajanje, ki smo jih razložili zgoraj. Različni paketi vsebujejo vozlišča in artefakte. Diagrame in komponente modela združujejo v skupine, podobno kot imenski prostor vsebuje različna imena, ki so nekoliko povezana. Navsezadnje lahko paket ustvari tudi več drugih paketov, ki predstavljajo bolj zapletene sisteme in vedenja.

Glavni namen diagrama paketov je prikazati razmerja med različnimi velikimi komponentami, ki sestavljajo kompleksen sistem. Programerji menijo, da je ta abstrakcija dobra prednost za uporabo paketnih diagramov, še posebej, če je mogoče nekatere podrobnosti izpustiti iz slike.

Kot vsaka druga stvar v življenju, če želite nekaj narediti prav, potrebujete prava orodja. Za dokumentiranje programske opreme, procesov ali sistemov uporabite orodja, ki ponujajo pripise UML in predloge diagramov. Obstajajo različna orodja za dokumentacijo programske opreme, ki lahko pomagajo pri risanju diagrama.

Na splošno sodijo v naslednje glavne kategorije:

1. Papir in pero je enostavno. Vzemite papir in pero, odprite sintaksno kodo UML iz spleta in narišite poljubno vrsto diagrama.
2. Spletna orodja – Obstaja več spletnih aplikacij, ki jih lahko uporabite za ustvarjanje grafikona. Večina jih ponuja plačljivo naročnino ali omejeno število diagramov v brezplačni ravni.
3. Brezplačna spletna orodja so skoraj enaka plačljivim. Glavna razlika je v tem, da plačljivi ponujajo tudi vadnice in že pripravljene predloge za določene diagrame.
4. Namizna aplikacija – tipična namizna aplikacija, ki se uporablja za diagrame in skoraj vse druge diagrame, je Microsoft Visio. Ponuja napredne funkcije in funkcionalnost. Edina pomanjkljivost je, da morate za to plačati.

Tako je jasno, da je UML pomemben vidik, povezan z razvojem objektno usmerjene programske opreme. Za ustvarjanje vizualnih modelov sistemskih programov uporablja grafični zapis.

UML diagram je specializiran grafični opisni jezik, zasnovan za modeliranje objektov pri razvoju različne programske opreme. Ta jezik ima širok profil in je odprt standard, ki uporablja različne grafične zapise za ustvarjanje abstraktnega modela sistema. UML je bil ustvarjen za omogočanje definicije, vizualizacije, dokumentacije in načrtovanja vseh vrst programskih sistemov. Omeniti velja, da sam diagram UML ni programski jezik, vendar zagotavlja možnost generiranja ločene kode na podlagi njega.

Zakaj je potrebna?

Uporaba UML se ne konča z modeliranjem vseh vrst programske opreme. Prav tako se ta jezik danes aktivno uporablja za modeliranje različnih poslovnih procesov, vodenje načrtovanja sistemov, pa tudi za prikaz organizacijskih struktur.

S pomočjo UML lahko razvijalci programske opreme zagotovijo popolno soglasje v grafičnem zapisu, ki se uporablja za predstavljanje skupnih konceptov, kot so: komponenta, posploševanje, razred, obnašanje in združevanje. S tem dosežemo večjo stopnjo koncentracije na arhitekturo in oblikovanje.

Omeniti velja tudi, da obstaja več vrst takšnih grafikonov.

razredni diagram

Diagram razreda UML je diagram statične strukture, zasnovan za opis strukture sistema, pa tudi za prikaz atributov, metod in odvisnosti med več različnimi razredi.

Omeniti velja dejstvo, da obstaja več stališč glede gradnje takšnih diagramov, odvisno od tega, kako se bodo uporabljali:

• Konceptualno. V tem primeru diagram razredov UML opisuje model določenega predmetnega področja in zagotavlja samo razrede aplikacijskih objektov.
• Specifično. Diagram se uporablja pri oblikovanju različnih informacijskih sistemov.
• Izvajanje. Diagram razredov vključuje vse vrste razredov, ki se neposredno uporabljajo v programski kodi.

Diagram komponent

Komponentni diagram UML je popolnoma statičen strukturni diagram. Namenjen je prikazu razčlenitve določenega programskega sistema na različne strukturne komponente, pa tudi odnosov med njimi. Diagram komponent UML lahko uporablja vse vrste modelov, knjižnic, datotek, paketov, izvedljivih datotek in številne druge elemente kot take.

Sestavljeni/sestavljeni strukturni diagram

Diagram sestavljene/sestavljene strukture UML je tudi statičen strukturni diagram, vendar se uporablja za prikaz notranje strukture razredov. Če je mogoče, lahko ta diagram prikaže tudi interakcijo elementov, ki so v notranji strukturi razreda.

Podvrsta teh je diagram sodelovanja UML, ki se uporablja za prikaz vlog in interakcij različnih razredov v okviru sodelovanja. So zelo priročni, če morate modelirati oblikovalske vzorce.

Omeniti velja, da se lahko hkrati uporabljajo diagrami razredov UML in diagrami sestavljene strukture.

Diagram uvajanja

Ta diagram se uporablja za modeliranje tekočih vozlišč, pa tudi vseh vrst artefaktov, ki so bili na njih nameščeni. V UML 2 so artefakti razporejeni na različnih vozliščih, medtem ko so bile v prvi različici nameščene samo komponente. Tako se diagram uvajanja UML uporablja predvsem za drugo različico.

Med artefaktom in komponento, ki jo izvaja, se oblikuje odvisnost manifestacije.

Diagram objekta

Ta pogled vam omogoča, da vidite celoten ali delni posnetek sistema, ki je bil ustvarjen v določenem trenutku. V celoti prikazuje vse primerke razredov določenega sistema, pri čemer navaja trenutne vrednosti njihovih parametrov, pa tudi odnose med njimi.

Diagram paketa

Ta diagram je strukturne narave, njegova glavna vsebina pa so vse vrste paketov, pa tudi razmerja med njimi. V tem primeru ni stroge ločitve med več strukturnimi diagrami, zaradi česar se njihova uporaba najpogosteje uporablja zgolj zaradi udobja in nima nobenega pomenskega pomena. Omeniti velja, da lahko različni elementi zagotavljajo druge diagrame UML (primeri: paketi in sami diagrami paketov).

Njihova uporaba se izvaja z namenom, da se zagotovi organiziranost več elementov v skupine glede na določen atribut, da se poenostavi struktura in organizira delo z modelom tega sistema.

diagram aktivnosti

Diagram dejavnosti UML prikazuje razgradnjo določene dejavnosti na več sestavnih delov. V tem primeru se koncept "dejavnosti" nanaša na specifikacijo določenega izvedljivega vedenja v obliki vzporednega, pa tudi usklajenega zaporednega izvajanja različnih podrejenih elementov - ugnezdenih vrst dejavnosti in različnih dejanj, združenih s tokovi, ki potekajo od izhodi določenega vozlišča na vhode drugega.

Diagram dejavnosti UML se pogosto uporablja za modeliranje različnih poslovnih procesov, vzporednega in zaporednega računalništva. Med drugim modelirajo vse vrste tehnoloških postopkov.

avtomatski diagram

Ta pogled se imenuje in nekoliko drugače - diagram stanja UML. Ima predstavljen državni stroj s preprostimi in sestavljenimi stanji ter prehodi.

Državni stroj je specifikacija zaporedja različnih stanj, skozi katera prehaja določen objekt, ali interakcija kot odziv na nekatere dogodke v njegovem življenju, pa tudi odziv objekta na take dogodke. Državni stroj, ki ga uporablja diagram stanja UML, je priložen izvirnemu elementu in se uporablja za definiranje obnašanja njegovih primerkov.

Kot analogi takšnih diagramov se lahko uporabljajo tako imenovani diagrami zmajev.

Diagrami primerov uporabe

Diagram primerov uporabe UML prikazuje vse odnose, ki se pojavijo med akterji, kot tudi različne primere uporabe. Njegova glavna naloga je zagotoviti popolno sredstvo, s katerim lahko stranka, končni uporabnik ali kakšen razvijalec skupaj razpravljajo o obnašanju in funkcionalnosti določenega sistema.

Če se diagram primera uporabe UML uporablja v procesu modeliranja sistema, bo analitik:

• Jasno ločite sistem, ki ga modelirate, od njegovega okolja.
• Določite akterje, načine njihove interakcije s tem sistemom in njegovo pričakovano funkcionalnost.
• V glosarju kot predmetno področje nastavite različne koncepte, ki se nanašajo na podroben opis funkcionalnosti tega sistema.

Če se v UML razvija diagram uporabe, se postopek začne z besedilnim opisom, ki ga dobimo pri delu s stranko. Ob tem velja omeniti dejstvo, da so različne nefunkcionalne zahteve v procesu sestavljanja modela primera uporabe popolnoma izpuščene, zanje pa bo že oblikovan ločen dokument.

Komunikacije

Komunikacijski diagram je, tako kot diagram zaporedja UML, tranzitiven, torej izraža interakcijo, hkrati pa jo prikazuje na različne načine in se po potrebi z zahtevano stopnjo natančnosti lahko pretvori v drugega.

Komunikacijski diagram odraža interakcije, ki se pojavljajo med različnimi elementi sestavljene strukture, pa tudi vloge sodelovanja. Njegova glavna razlika od diagrama zaporedja je, da jasno kaže razmerje med več elementi, čas pa se ne uporablja kot ločena dimenzija.

To vrsto odlikuje popolnoma brezplačna oblika razvrščanja več predmetov in razmerij na enak način, kot je to storjeno v diagramu objektov. Če je treba ohraniti vrstni red sporočil v tej brezplačni obliki, so oštevilčena kronološko. Branje tega diagrama se začne z začetnim sporočilom 1.0 in se nato nadaljuje v smeri, v kateri se sporočila prenašajo od enega objekta do drugega.

Večinoma takšni diagrami prikazujejo popolnoma enake informacije, ki nam jih nudi diagram zaporedja, a ker uporablja drugačen način predstavitve informacij, postane nekatere stvari v enem diagramu veliko lažje določiti kot v drugem. Omeniti velja tudi, da komunikacijski diagram bolj jasno kaže, s katerimi elementi vsak posamezen element deluje, medtem ko diagram zaporedja bolj jasno kaže, v kakšnem vrstnem redu se interakcije izvajajo.

diagram zaporedja

Diagram zaporedja UML prikazuje interakcije med več objekti, ki so urejeni glede na čas njihovega nastanka. Tak diagram prikazuje časovno urejeno interakcijo med več objekti. Zlasti prikazuje vse predmete, ki sodelujejo v interakciji, pa tudi celotno zaporedje sporočil, ki si jih izmenjajo.

Glavni elementi v tem primeru so označbe različnih predmetov, pa tudi navpične črte, ki prikazujejo potek časa, in pravokotniki, ki predstavljajo dejavnost določenega predmeta ali izvajanje neke funkcije z njim.

Diagram sodelovanja

Ta vrsta diagrama vam omogoča, da prikažete interakcije med več predmeti, pri čemer abstrahirate od zaporedja prevoda sporočil. Ta vrsta diagramov v kompaktni obliki prikazuje absolutno vsa poslana in prejeta sporočila določenega predmeta, pa tudi formate teh sporočil.

Ker so diagrami zaporedja in komunikacijski diagrami preprosto različni pogledi na iste postopke, Rational Rose ponuja možnost izdelave komunikacijskega diagrama zaporedja iz diagrama zaporedja ali obratno in jih tudi popolnoma samodejno sinhronizira.

Pregledni diagrami interakcij

To so UML diagrami, ki spadajo v vrsto diagramov dejavnosti in vključujejo elemente zaporedja in konstrukcije krmilnega toka.

Omeniti velja dejstvo, da ta format združuje diagram sodelovanja in zaporedja, ki dajeta priložnost, da razmislimo o interakciji med več objekti v sistemu, ki se oblikuje, z različnih zornih kotov.

Časovni diagram

Predstavlja alternativno različico diagrama zaporedja, ki eksplicitno prikazuje spremembo stanja na življenjski črti z določeno časovno skalo. Lahko je zelo uporaben v različnih aplikacijah v realnem času.

Kakšne so prednosti?

Omeniti velja več prednosti, ki razlikujejo diagram uporabe UML in druge:

• Jezik je objektno usmerjen, zaradi česar so tehnologije za opis rezultatov izvedene analize in načrtovanja semantično blizu programskim metodam v vseh vrstah objektno usmerjenih jezikov sodobnega tipa.
• S tem jezikom je mogoče sistem opisati s skoraj katerega koli možnega vidika, na enak način pa so opisani različni vidiki njegovega vedenja.
• Vse diagrame je razmeroma enostavno brati tudi po razmeroma hitrem seznanitvi z njihovo sintakso.
• UML vam omogoča razširitev, pa tudi uvajanje lastnih grafičnih in besedilnih stereotipov, kar prispeva k njegovi uporabi ne le v programskem inženiringu.
• Jezik je postal precej razširjen in se tudi precej aktivno razvija.

Pomanjkljivosti

Kljub dejstvu, da ima gradnja UML diagramov veliko svojih prednosti, jih pogosto kritizirajo zaradi naslednjih pomanjkljivosti:

• redundanca. V veliki večini primerov kritiki pravijo, da je UML prevelik in zapleten, pogosto pa je to neupravičeno. Vključuje precej odvečnih ali skoraj neuporabnih konstrukcij in diagramov, najpogosteje pa gre taka kritika na drugo različico in ne na prvo, saj je v novejših revizijah več kompromisov, ki jih je oblikovala komisija.
• Različne netočnosti v semantiki. Ker je UML opredeljen s kombinacijo samega sebe, angleščine in OCL, mu manjka togost, ki je lastna jezikom, ki so natančno opredeljeni s formalnimi tehnikami opisa. V določenih situacijah si začnejo abstraktna sintaksa OCL, UML in angleščine nasprotovati, v drugih primerih pa so nepopolne. Netočnost opisa samega jezika vpliva tako na uporabnike kot na ponudnike orodij, kar sčasoma vodi do nezdružljivosti orodij zaradi edinstvenega načina obravnavanja različnih specifikacij.
• Težave v procesu izvajanja in študija. Vse naštete težave povzročajo določene težave pri uvajanju in učenju UML, kar še posebej velja, ko vodstvo prisili inženirje, da ga uporabljajo, če nimajo predhodnih znanj.
• Koda odraža kodo. Drugo mnenje je, da niso pomembni lepi in privlačni modeli, ampak neposredno delujoči sistemi, torej koda je projekt. Glede na to stališče je treba razviti učinkovitejši način za pisanje programske opreme. UML je cenjen v pristopih, ki prevajajo modele za regeneracijo izvedljive ali izvorne kode. Toda v resnici to morda ne bo dovolj, ker jezik nima lastnosti Turingove popolnosti in bo vsaka ustvarjena koda sčasoma omejena s tem, kar lahko prevzame ali določi orodje za interpretacijo UML.
• Neusklajenost obremenitve. Ta izraz izhaja iz teorije sistemske analize za ugotavljanje nezmožnosti vhoda nekega sistema, da bi zaznal izhod drugega. Kot pri vsakem standardnem zapisu lahko UML predstavi določene sisteme na učinkovitejši in jedrnat način kot drugi. Tako se razvijalec bolj nagiba k tistim rešitvam, ki so bolj udobne za tkanje vseh prednosti UML, pa tudi drugih programskih jezikov. Ta problem je bolj očiten, če razvojni jezik ni v skladu z glavnimi načeli objektno usmerjene ortodoksne doktrine, torej ne poskuša delovati v skladu z načeli OOP.
• Poskuša biti univerzalen. UML je jezik za modeliranje splošnega namena, ki želi biti združljiv s katerim koli jezikom obdelave, ki trenutno obstaja. V okviru posameznega projekta, da bi oblikovalska ekipa dosegla končni cilj, je treba izbrati uporabne značilnosti tega jezika. Poleg tega so možni načini za omejitev obsega uporabe UML na določenem področju skozi formalizem, ki ni v celoti formuliran, vendar je sam predmet kritik.

Zato uporaba tega jezika ni pomembna v vseh situacijah.