Alati za crtanje UML dijagrama. Modeliranje u UML-u. Opći dijagrami Primjer dijagrama u uml jeziku

UML je jedinstveni grafički jezik modeliranja za opisivanje, vizualizaciju, projektovanje i dokumentovanje OO sistema. UML je dizajniran da podrži proces modeliranja softvera zasnovanog na OO pristupu, organizuje odnos konceptualnih i programskih koncepata i odražava probleme skaliranja složenih sistema. UML modeli se koriste u svim fazama životnog ciklusa softvera, od poslovne analize do održavanja sistema. Različite organizacije mogu koristiti UML kako smatraju prikladnim, ovisno o svojim problemskim područjima i tehnologijama koje koriste.

Kratka istorija UML-a

Do sredine 90-ih, razni autori su predložili nekoliko desetina metoda OO modeliranja, od kojih je svaka koristila vlastitu grafičku notaciju. Štaviše, svaka od ovih metoda imala je svoje snage, ali nije dozvolio da se izgradi dovoljno full model PS, pokažite ga “sa svih strana”, odnosno sve potrebne projekcije (vidi članak 1). Osim toga, nedostatak standarda OO modeliranja otežavao je programerima da izaberu najprikladniju metodu, što je spriječilo široko usvajanje OO pristupa razvoju softvera.

Na zahtjev Object Management Group (OMG), organizacije odgovorne za usvajanje standarda u oblasti objektnih tehnologija i baza podataka, hitan problem unifikacije i standardizacije riješili su autori tri najpopularnije OO metode - G. Butch, D. Rambo i A. Jacobson, koji su zajedničkim naporima stvorili verziju UML 1.1, koju je OMG odobrio 1997. godine kao standard.

UML je jezik

Svaki jezik se sastoji od rječnika i pravila za kombiniranje riječi kako bi se stvorile smislene konstrukcije. Ovo je, posebno, način na koji su strukturirani programski jezici, kao što je UML. Njegova posebnost je u tome što je jezički rječnik formiran od grafičkih elemenata. Svaki grafički simbol ima specifičnu semantiku, tako da model koji je kreirao jedan programer može jasno razumjeti drugi, a također softver, tumačeći UML. Odavde, posebno, proizilazi da se softverski model predstavljen u UML-u može automatski prevesti u OO programski jezik (kao što je Java, C++, VisualBasic), odnosno ako postoji dobar alat za vizualno modeliranje koji podržava UML, koji ima izgradili model, također ćemo dobiti uzorak programskog koda koji odgovara ovom modelu.

Treba naglasiti da je UML jezik, a ne metoda. Objašnjava od kojih elemenata kreirati modele i kako ih čitati, ali ništa ne govori o tome koje modele treba razviti i u kojim slučajevima. Za kreiranje metode zasnovane na UML-u potrebno je dopuniti je opisom procesa razvoja softvera. Primjer takvog procesa je Racionalni ujedinjeni proces, o kojem će biti riječi u narednim člancima.

UML Dictionary

Model je predstavljen u obliku entiteta i odnosa između njih, koji su prikazani dijagramima.

Entiteti su apstrakcije koje su glavni elementi modela. Postoje četiri tipa entiteta - strukturni (klasa, interfejs, komponenta, slučaj upotrebe, saradnja, čvor), bihevioralni (interakcija, stanje), grupisanje (paket) i anotacija (komentari). Svaki tip entiteta ima svoj grafički prikaz. Entiteti će biti detaljno razmotreni prilikom proučavanja dijagrama.

Veza pokazuju različite veze između entiteta. UML definira sljedeće tipove odnosa:

Ovisnost pokazuje takvu vezu između dva entiteta kada promjena jednog od njih - nezavisnog - može uticati na semantiku drugog - zavisnog. Zavisnost je predstavljena isprekidanom strelicom usmjerenom od zavisnog entiteta prema nezavisnom.
Udruženje je strukturni odnos koji pokazuje da su objekti jednog entiteta povezani sa objektima drugog. Grafički, asocijacija je prikazana kao linija koja povezuje povezane entitete. Asocijacije služe za navigaciju između objekata. Na primjer, asocijacija između klasa "Narudžba" i "Proizvod" može se koristiti za pronalaženje svih proizvoda navedenih u određenoj narudžbi - s jedne strane, ili za pronalaženje svih narudžbi koje imaju ovaj proizvod, - sa drugom. Jasno je da odgovarajući programi moraju implementirati mehanizam koji obezbjeđuje takvu navigaciju. Ako je potrebna navigacija samo u jednom smjeru, to je označeno strelicom na kraju asocijacije. Poseban slučaj asocijacije je agregacija - odnos oblika "cjelina" - "dio". Grafički je istaknut dijamantom na kraju blizu esencije-cjeline.
Generalizacija je odnos između roditeljskog entiteta i podređenog entiteta. U suštini, ovaj odnos odražava svojstvo nasljeđivanja za klase i objekte. Generalizacija je prikazana kao linija koja završava trouglom usmjerenom prema matičnom entitetu. Dijete nasljeđuje strukturu (atribute) i ponašanje (metode) roditelja, ali u isto vrijeme može imati nove elemente strukture i nove metode. UML dozvoljava višestruko nasljeđivanje, gdje je entitet povezan s više od jednog nadređenog entiteta.
Implementacija– odnos između entiteta koji definira specifikaciju ponašanja (interfejs) sa entitetom koji definira implementaciju ovog ponašanja (klasa, komponenta). Ovaj odnos se obično koristi pri modeliranju komponenti i biće detaljnije opisan u narednim člancima.

Dijagrami. UML pruža sljedeće dijagrame:

Dijagrami koji opisuju ponašanje sistema:

Dijagrami stanja
dijagrami aktivnosti,
dijagrami objekata,
dijagrami sekvenci,
Dijagrami suradnje;

Dijagrami koji opisuju fizičku implementaciju sistema:

Dijagrami komponenti;
Dijagrami implementacije.

Model Control View. Paketi.

Već smo rekli da je, kako bi ljudi dobro razumjeli model, potrebno ga hijerarhijski organizirati, ostavljajući mali broj entiteta na svakom nivou hijerarhije. UML uključuje sredstva za organizovanje hijerarhijske reprezentacije modela - pakete. Svaki model se sastoji od skupa paketa koji mogu sadržavati klase, slučajeve upotrebe i druge entitete i dijagrame. Paket može sadržavati druge pakete, što omogućava kreiranje hijerarhija. UML ne pruža zasebne dijagrame paketa, ali se mogu pojaviti u drugim dijagramima. Paket je prikazan kao pravougaonik sa obeleživačem.

Šta UML pruža.

hijerarhijski opis složenog sistema identifikacijom paketa;
formalizacija funkcionalnih zahtjeva za sistem korištenjem aparata slučajeva korištenja;
detaljiziranje sistemskih zahtjeva konstruiranjem dijagrama aktivnosti i scenarija;
identificiranje klasa podataka i konstruiranje konceptualnog modela podataka u obliku dijagrama klasa;
identificiranje klasa koje opisuju korisnički interfejs i kreiranje šeme za navigaciju na ekranu;
opis procesa interakcije objekata pri obavljanju sistemskih funkcija;
opis ponašanja objekta u obliku dijagrama aktivnosti i stanja;
opis softverskih komponenti i njihove interakcije kroz interfejse;
opis fizičke arhitekture sistema.

I poslednja stvar...

Bez obzira na svu privlačnost UML-a, bilo bi teško koristiti ga u stvarnom softverskom modeliranju bez alata za vizualno modeliranje. Takvi alati vam omogućavaju da brzo predstavite dijagrame na ekranu, dokumentujete ih, generišete predloške programskog koda u različitim OO programskim jezicima i kreirate šeme baze podataka. Većina njih uključuje mogućnost reinženjeringa programskih kodova – obnavljanje određenih projekcija softverskog modela automatskim analizom izvornih kodova programa, što je veoma važno kako bi se osigurala usklađenost modela i kodova i prilikom projektovanja sistema koji nasljeđuju funkcionalnost prethodnika.

10.4. UML DIJAGRAMI

10.4.1. Vrste UML vizuelnih dijagrama

UML vam omogućava da kreirate nekoliko vrsta vizuelnih dijagrama:

Dijagrami slučajeva upotrebe;

Dijagrami sekvenci;

Cooperative Charts;

Dijagrami klasa;

dijagrami stanja;

Dijagrami komponenti;

Dijagrami postavljanja.

Dijagrami ilustruju različite aspekte sistema. Na primjer, kooperativni dijagram pokazuje kako objekti moraju biti u interakciji da bi implementirali neku funkcionalnost sistema. Svaki dijagram ima svoju svrhu.

10.4.2. Dijagrami slučajeva upotrebe

Dijagrami slučajeva upotrebe prikazuju interakcije između slučajeva upotrebe, koji predstavljaju funkcije sistema, i aktera, koji predstavljaju ljude ili sisteme koji primaju ili prenose informacije ovaj sistem. Primjer dijagrama slučajeva upotrebe bankomata (ATM) prikazan je na Sl. 10.1.

Rice. 10.1. Dijagram slučaja upotrebe

Dijagram predstavlja interakciju između slučajeva upotrebe i aktera. Odražava sistemske zahtjeve sa stanovišta korisnika. Dakle, slučajevi upotrebe su funkcije koje obavlja sistem, a akteri su stejkholderi u odnosu na sistem koji se stvara. Dijagrami pokazuju koji akteri pokreću slučajeve upotrebe. Oni također pokazuju kada akter primi informacije iz slučaja upotrebe. U suštini, dijagram slučaja upotrebe može ilustrirati sistemske zahtjeve. U našem primjeru, klijent banke pokreće različite slučajeve upotrebe: „Podigni novac sa računa“, „Prenesi novac“, „Uplati novac na račun“, „Prikaži stanje“, „Promijeni ID broj“, „Uplati“. Zaposlenik banke može pokrenuti slučaj korištenja promjene identifikacionog broja. Iz slučaja upotrebe „Izvrši plaćanje“ nalazi se strelica za kreditni sistem. Glumci mogu biti eksterni sistemi, u ovom slučaju, Kreditni sistem je prikazan upravo kao akter – on je eksteran u odnosu na ATM sistem. Strelica koja pokazuje od slučaja upotrebe do aktera pokazuje da slučaj upotrebe daje neke informacije akteru. U ovom slučaju, slučaj upotrebe Izvrši plaćanje daje kreditnom sistemu informacije o plaćanju kreditnom karticom.

Dijagrami slučajeva upotrebe mogu pružiti dosta informacija o sistemu. Ovaj tip dijagrama opisuje ukupnu funkcionalnost sistema. Korisnici, menadžeri projekata, analitičari, programeri, stručnjaci za osiguranje kvaliteta i svi zainteresovani za sistem u cjelini mogu pogledati dijagrame slučajeva korištenja kako bi razumjeli šta sistem treba da radi.

10.4.3. Dijagrami sekvenci

Dijagrami sekvenci opisuju tok događaja koji se dešavaju unutar slučaja upotrebe. Na primjer, slučaj upotrebe “Podigni novac” pruža nekoliko mogućih sekvenci: podizanje novca, pokušaj podizanja novca kada nema dovoljno novca na računu, pokušaj podizanja novca koristeći pogrešan identifikacijski broj i neke druge. Normalan scenario za podizanje 20 dolara sa računa (u nedostatku problema kao što je netačan identifikacioni broj ili nedovoljno sredstava na računu) prikazan je na Sl. 10.2.

Slika 10.2. Dijagram sekvence za Joeovog klijenta koji podiže 20 dolara sa svog računa

Na vrhu dijagrama su prikazani svi akteri i objekti koji su potrebni sistemu za izvršavanje slučaja korištenja Povlačenja novca. Strelice odgovaraju porukama proslijeđenim između aktera i objekta ili između objekata za obavljanje potrebnih funkcija. Također treba napomenuti da dijagram sekvence prikazuje objekte, a ne klase. Klase su tipovi objekata. Objekti su konkretni; umjesto klase Klijent Dijagram sekvence predstavlja određenog kupca, Joea.

Slučaj upotrebe počinje kada kupac ubaci svoju karticu u čitač - ovaj objekt je prikazan u pravokutniku na vrhu dijagrama. Čita broj kartice, otvara Joe Account objekt i inicijalizira ekran bankomata. Ekran pita Joea za njegov registracijski broj. Kupac unosi broj 1234. Ekran provjerava broj u odnosu na objekt Joe Account i utvrđuje da je tačan. Na ekranu se Joeu tada prikazuje meni za izbor, a on odabire "Podigni novac". Ekran pita koliko želi povući, a Joe unese 20 dolara. Ekran podiže novac sa računa. Čineći to, on pokreće niz procesa koje izvodi objekt "Joe's account". Istovremeno je potvrđeno da ovaj račun sadrži, prema najmanje, 20 USD i potreban iznos se odbija od računa. Kasa dobija instrukcije da "izda ček i 20 dolara u gotovini." Konačno, isti objekat "Joe's account" daje instrukcije čitaču kartica da vrati karticu.

dakle, ovaj dijagram sekvenca ilustruje slijed radnji koje implementiraju "povlačenje novca sa računa" korištenjem konkretnog primjera Joeovog klijenta koji podiže 20 dolara. Gledajući ovaj dijagram, korisnici se upoznaju sa specifičnostima svog rada. Analitičari vide slijed (tok) radnji, programeri vide objekte koje treba kreirati i njihove operacije. Stručnjaci za kontrolu kvaliteta će razumjeti detalje procesa i mogu razviti testove kako bi ih potvrdili. Dakle, dijagrami sekvence su korisni za sve uključene u projekat.

10.4.4. Kooperativni dijagrami

Kooperativni dijagrami odražavaju iste informacije kao i dijagrami sekvence. Međutim, oni to rade drugačije i s drugim ciljevima. Prikazano na sl. 10.2 dijagram sekvence prikazan je na Sl. 10.3 u obliku kooperativnog dijagrama.

Kao i ranije, objekti se prikazuju kao pravokutnici, a likovi kao figure. Dok dijagram sekvence pokazuje interakciju između aktera i objekata tokom vremena, kooperativni dijagram ne pokazuje nikakvu vezu tokom vremena. Tako možete vidjeti da čitač kartica daje instrukciju da se "Joeov račun" otvori, a "Joeov račun" uzrokuje da uređaj vrati karticu vlasniku. Objekti koji su u direktnoj interakciji povezani su linijama. Ako, na primjer, čitač kartica komunicira direktno sa ekranom bankomata, između njih treba povući liniju. Odsustvo linije znači da ne postoji direktna komunikacija između objekata.

Rice. 10.3. Kooperativni dijagram koji opisuje proces podizanja novca sa računa

Dakle, kooperativni dijagram prikazuje iste informacije kao dijagram sekvence, ali je potreban za drugu svrhu. Stručnjaci za osiguranje kvaliteta i arhitekte sistema moći će razumjeti distribuciju procesa između objekata. Recimo da neka vrsta kooperativnog dijagrama liči na zvijezdu, gdje je nekoliko objekata povezano s jednim središnjim objektom. Arhitekta sistema može zaključiti da je sistem previše ovisan o centralnom entitetu i da ga treba redizajnirati kako bi se procesi distribuirali ravnomjernije. U dijagramu sekvence, ovu vrstu interakcije bilo bi teško uočiti.

10.4.5. Dijagrami klasa

Dijagrami klasa odražavaju interakcije između klasa u sistemu. Na primjer, "Joeov račun" je objekt. Tip takvog objekta može se općenito smatrati računom, tj. "Račun" je klasa. Klase sadrže podatke i ponašanje (radnje) koje utječe na te podatke. Dakle, klasa Račun sadrži identifikacioni broj klijenta i radnje koje ga verificiraju. U dijagramu klasa, klasa se kreira za svaki tip objekta iz dijagrama sekvenci ili kooperativnih dijagrama. Dijagram klasa za slučaj upotrebe Povlačenje novca prikazan je na Sl. 10.4.

Dijagram prikazuje odnose između klasa koje implementiraju slučaj upotrebe Povlačenja novca. Postoje četiri klase uključene u ovaj proces: čitač kartica, račun, ekran bankomata i dispenzer za gotovinu. Svaka klasa u dijagramu klasa je prikazana kao pravougaonik podijeljen na tri dijela. Prvi dio označava naziv klase, drugi - njen atributi. Atribut je neka informacija koja karakterizira klasu. Na primjer, klasa Račun ima tri atributa: Broj računa, PIN i Stanje. Posljednji dio sadrži operacije klase, koje odražavaju njenu ponašanje(radnje koje obavlja klasa). Linije koje povezuju klase pokazuju interakcije između klasa.

Rice. 10.4. Dijagram klasa

Programeri koriste dijagrame klasa da bi zapravo kreirali klase. Alati kao što je Rose generišu jezgro koda klase koji programeri popunjavaju detaljima na jeziku po svom izboru. Koristeći ove dijagrame, analitičari mogu pokazati detalje sistema, a arhitekte mogu razumjeti njegov dizajn. Ako, na primjer, klasa nosi previše funkcionalnog opterećenja, to će biti vidljivo u dijagramu klasa, a arhitekta to može preraspodijeliti među druge klase. Dijagram takođe može pomoći da se identifikuju slučajevi u kojima nema definisanih odnosa između klasa koje komuniciraju. Dijagrame klasa treba kreirati kako bi prikazali interakciju klasa u svakom slučaju upotrebe. Također možete napraviti opštije dijagrame koji pokrivaju sve sisteme ili podsisteme.

10.4.6. Dijagrami stanja

Dijagrami stanja su dizajnirani da modeliraju različita stanja u kojima objekt može biti. Dok dijagram klasa pokazuje statičnu sliku klasa i njihovih odnosa, dijagrami stanja se koriste za opisivanje dinamike ponašanja sistema.

Dijagrami stanja prikazuju ponašanje objekta. Dakle, bankovni račun može imati nekoliko različitih stanja. Može biti otvoren, zatvoren ili prekoračen. Ponašanje računa se mijenja ovisno o stanju u kojem se nalazi. Dijagram stanja pokazuje upravo ove informacije. Na sl. Slika 10.5 prikazuje primjer dijagrama stanja za bankovni račun.

Rice. 10.5. Dijagram stanja za klasu Račun

Ovaj dijagram prikazuje moguća stanja računa, kao i proces prelaska računa iz jednog stanja u drugo. Na primjer, ako klijent zatraži zatvaranje otvorenog računa, potonji prelazi u stanje "Zatvoreno". Zahtjev klijenta se zove događaj, događaji su ti koji uzrokuju prelazak iz jednog stanja u drugo.

Kada klijent podiže novac sa otvorenog računa, račun može ući u stanje prekoračenja. Ovo se dešava samo ako je stanje na računu manje od nule, što se odražava stanjem [negativan saldo] u našem grafikonu. U uglastim zagradama stanje određuje kada se prijelaz iz jednog stanja u drugo može ili ne može dogoditi.

Na dijagramu postoje dva posebna stanja - početni I final. Početno stanje je označeno crnom tačkom: odgovara stanju objekta u trenutku njegovog stvaranja. Konačno stanje je označeno crnom tačkom u bijelom krugu: ono odgovara stanju objekta neposredno prije njegovog uništenja. U dijagramu stanja može postojati jedno i samo jedno početno stanje. U isto vrijeme, može biti onoliko konačnih stanja koliko vam je potrebno, ili ih uopće nema.

Kada je objekat u određenom stanju, određeni procesi se mogu izvršiti. U našem primjeru, ako je kredit prekoračen, klijentu se šalje odgovarajuća poruka. Pozivaju se procesi koji se javljaju kada je objekt u određenom stanju akcije.

Grafikoni stanja ne moraju biti kreirani za svaku klasu, oni se koriste samo u vrlo složenim slučajevima. Ako objekat klase može postojati u više stanja i ponaša se različito u svakom stanju, vjerovatno će mu trebati takav dijagram. Međutim, mnogi projekti ih uopće ne koriste. Ako su dijagrami stanja napravljeni, programeri ih mogu koristiti prilikom kreiranja klasa.

Grafikoni stanja su potrebni uglavnom za dokumentaciju.

10.4.7. Dijagrami komponenti

Dijagrami komponenti pokazuju kako model izgleda fizički nivo. Prikazuje komponente softver vaš sistem i veze između njih. Postoje dvije vrste komponenti: izvršne komponente i biblioteke kodova.

Na sl. Slika 10.6 prikazuje jedan od dijagrama komponenti za ATM sistem. Ovaj dijagram prikazuje komponente klijenta ATM sistema. U ovom slučaju, razvojni tim je odlučio da izgradi sistem koristeći C++ jezik. Svaka klasa ima svoju datoteku zaglavlja i datoteku ekstenzije. CPP, tako da se svaka klasa transformiše u svoje komponente u dijagramu. Poziva se odabrana tamna komponenta specifikacija paketa i odgovara datoteci tijela klase ATM u C++ (datoteka sa ekstenzijom. CPP). Neodabrana komponenta se takođe naziva specifikacijom paketa, ali odgovara datoteci zaglavlja klase jezika C++ (datoteka sa ekstenzijom .H). ATM komponenta. EXE je specifikacija zadatka i predstavlja tok obrade informacija. U ovom slučaju, nit obrade je izvršni program.

Komponente su povezane isprekidanom linijom, koja predstavlja zavisnosti između njih. Sistem može imati višekomponentne dijagrame u zavisnosti od broja podsistema ili izvršne datoteke. Svaki podsistem je paket komponenti.

Dijagrame komponenti koriste oni učesnici projekta koji su odgovorni za kompajliranje sistema. Dijagram komponenti daje predstavu o redoslijedu po kojem komponente trebaju biti kompajlirane, kao io tome koje će izvršne komponente kreirati sistem. Dijagram prikazuje mapiranje klasa na implementirane komponente. Dakle, potrebno je tamo gdje počinje generiranje koda.

Rice. 10.6. Dijagram komponenti

10.4.8. Dijagrami postavljanja

Dijagrami izgleda pokazuju fizičku lokaciju različitih komponenti sistema na mreži. U našem primjeru, ATM sistem se sastoji od velikog broja podsistema koji rade na odvojenim fizičkim uređajima ili čvorovima. Dijagram postavljanja ATM sistema prikazan je na Sl. 10.7.

Iz ovog dijagrama možete naučiti o fizičkom izgledu sistema. Klijentski programi bankomata će se izvoditi na više lokacija na više lokacija. Klijenti će komunicirati sa regionalnim ATM serverom kroz zatvorene mreže. Pokrenut će softver servera bankomata. Zauzvrat, kroz lokalna mreža regionalni serverće biti u interakciji sa serverom bankarske baze podataka na kojem radi Oracle. Konačno, štampač je povezan sa regionalnim ATM serverom.

Dakle, ovaj dijagram prikazuje fizički izgled sistema. Na primjer, naš ATM sistem slijedi troslojnu arhitekturu, sa bazom podataka na prvom sloju, regionalnim serverom na drugom i klijentom na trećem.

10.7. Dijagram postavljanja

Dijagram rasporeda koriste menadžer projekta, korisnici, arhitekta sistema i operativno osoblje kako bi razjasnili fizički izgled sistema i lokaciju njegovih pojedinačnih podsistema. Menadžer projekta će korisnicima objasniti kako će izgledati gotov proizvod. Operativno osoblje će moći planirati radove na instalaciji sistema.

Iz knjige microsoft office autor Leontjev Vitalij Petrovič

Grafikoni Brojevi u tabeli ne omogućavaju vam uvijek da steknete potpun utisak, čak i ako su sortirani na način koji vam najviše odgovara. Koristeći one dostupne od Microsofta Excel šabloni dijagrama, možete dobiti jasnu sliku podataka u vašoj tabeli, a ne

Iz knjige Kompjuter za 100. Počnimo od Windows Vista autor Zozulya Yuri

Grafikoni Grafikoni se koriste za predstavljanje tabelarnih podataka u grafički oblik, koji mogu značajno poboljšati vidljivost informacija, pokazuju odnos između različitih parametara ili dinamiku njihove promjene. Da biste umetnuli dijagrame u Word, koristite alate

Iz knjige Efikasan kancelarijski rad autor Ptašinski Vladimir Sergejevič

Dijagrami Najvizuelniji Excel sposobnost je prezentacija rezultata proračuna ili akumuliranih podataka u obliku grafikona (dijagrama): ponekad najupečatljivije brojke nisu u stanju uvjeriti na način koji se može učiniti čak ni jednostavnim grafikama. Excel ima

Iz Excel radne knjige. Multimedijalni kurs autor Medinov Oleg

Poglavlje 8 Dijagrami Često Excel program koristi se za izradu dokumenata koji predstavljaju različite statističke i analitičke izvještaje. To mogu biti izvještaji o prodaji, tabele mjerenja temperature zraka, podaci iz socioloških istraživanja, itd. Brojevi nisu uvijek

Iz knjige Word 2007. Popularni vodič autor Krainsky I

Izrada grafikona Za prvi primjer, morat ćete kreirati tabelu prikazanu na Sl. 8.1. Rice. 8.1. Tabela mjerenja temperature Na osnovu podataka u ovoj tabeli konstruisaćemo jednostavan grafikon promjena temperature.1. Odaberite popunjeni raspon u tabeli.2. Idi

Iz knjige Priručnik za samouvođenje za rad na računaru autor Kolisničenko Denis Nikolajevič

6.6. Dijagrami Osim grafičke datoteke, V Word dokumenti možete umetnuti dijagrame. Koristeći dijagrame, možete vizualno predstaviti numeričke podatke, na primjer, pratiti kako se podaci mijenjaju, vidjeti razvoj određenog projekta tokom vremena. Dijagrami su slični

Iz knjige Objektno orijentirana analiza i dizajn s primjerima aplikacija u C++ by Butch Grady

14.9. Dijagrami Možda je vrijeme da suhe brojeve pretvorimo u grafiku, čineći našu tablicu ljepšom i informativnijom? Za to se koriste dijagrami. Šta god da kažete, dijagram se percipira bolje od tabele. Da biste konstruisali dijagram, potrebno je da izaberete vrednosti po kojima

Iz knjige Programske tehnologije autor Kamaev V A

5.2. Osnovni dijagrami klasa: Klase i njihovi odnosi Dijagram klasa prikazuje klase i njihove odnose, predstavljajući tako logički aspekt dizajna. Zaseban dijagram klasa predstavlja specifičan pogled na strukturu klase. U fazi analize mi

Iz knjige Modeliranje poslovnih procesa uz BPwin 4.0 autor Maklakov Sergej Vladimirovič

5.4. Osnovni dijagrami objekata: Objekti i njihovi odnosi Dijagram objekata prikazuje postojeće objekte i njihove odnose u logičkom dizajnu sistema. Drugim riječima, dijagram objekata je snimak toka događaja u nekoj konfiguraciji

Iz knjige OrCAD PSpice. Analiza električna kola od Keown J.

5.7. Procesni dijagrami. Osnovno: Procesori, uređaji i veze Dijagrami procesa se koriste da pokažu distribuciju procesa među procesorima u dizajnu fizičkog sistema. Zaseban dijagram procesa prikazuje jedan pogled na strukturu procesa

Iz knjige VBA for Dummies od Stevea Cummingsa

10.4. UML DIJAGRAMI 10.4.1. Tipovi vizuelnih dijagrama UMLUML vam omogućava da kreirate nekoliko tipova vizuelnih dijagrama: dijagrame slučajeva upotrebe; dijagrami sekvence; kooperativni dijagrami; dijagrami klasa; dijagrami stanja; dijagrami

Iz knjige Priručnik za samouputstvo za rad na Macintosh-u autor Sofia Skrylina

1.2.6. Okvir dijagrama Na sl. Slika 1.2.26 prikazuje tipičan primjer dijagrama dekompozicije sa graničnim okvirima koji se nazivaju okvir dijagrama. Rice. 1.2.26. Primjer dijagrama dekompozicije sa žičanim okvirom. Okvir sadrži naslov ( gornji dio okviri) i podrum (donji dio).

Iz knjige autora

Vremenski dijagrami Da biste dobili vremenske dijagrame ulaznog i izlaznog napona, morate malo izmijeniti ulaznu datoteku. Kao iu prethodnom primjeru, koristit će se sinusoidalni ulazni napon: Vi 1 0 sin (0 0.5V 5kHz) Zajedno s tranzijentnom analizom

Iz knjige autora

Grafikoni i grafikoni Samo stručnjak može razabrati značenje iza beskrajnih redova brojeva, ali svako može razumjeti (ili barem tvrditi da razumije) histogram ili tortni grafikon. VBA nema ugrađene alate za kreiranje dijagrama, ali takve

Iz knjige autora

5.1.14. Grafikoni Grafikoni su grafički prikazi numeričkih podataka u tabeli. Pages nudi nekoliko vrsta grafikona: stupac, naslagani stupac, trakasti grafikon, naslagani trakasti grafikon, linija, površina, naslagana površina

Iz knjige autora

5.2.8. Grafikoni Grafikon je grafički prikaz podataka iz odabranog raspona. Da biste napravili grafikon, slijedite sljedeći algoritam1. Kreirajte tablicu izračunatih vrijednosti.2. Odaberite željeni raspon (može se sastojati od nesusjednih pravokutnika

Mislim da je svako u detinjstvu čuo izreku kao " Sedam puta izmjerite jednom rezu". Isto je i u programiranju. Uvijek je bolje razmisliti o implementaciji prije nego što potrošite vrijeme na njeno izvršavanje. Kada je implementirate, često morate kreirati klase i osmisliti njihovu interakciju. I često vizualni prikaz ovoga može pomoći riješite problem na najispravniji način, tu mi pomažemo UML.

Šta je UML?

Ako pogledate slike u tražilice, tada će to postati jasno UML– to je nešto o dijagramima, strelicama i kvadratima. Ono što je važno je da se UML prevodi kao Unified Modeling Language. Ovdje je važna riječ Unified. Odnosno, naše slike nećemo razumjeti samo mi, već i drugi koji poznaju UML. Ispostavilo se da je ovo međunarodni jezik za crtanje dijagrama.

Kao što Vikipedija kaže

UML je jezik grafičkog opisa za modeliranje objekata u razvoju softvera, modeliranju poslovnih procesa, dizajnu sistema i prikazivanju organizacijskih struktura.

Najzanimljivija stvar o kojoj ne razmišljaju svi ili ne shvataju je da UML ima specifikacije. Štaviše, postoji čak i UML2 specifikacija. Više detalja o specifikaciji možete pronaći na web stranici Object Management Group. Zapravo, ova grupa razvija UML specifikacije. Zanimljivo je i to da UML nije ograničen samo na opisivanje strukture klasa. Postoji mnogo tipova UML dijagrama. Kratak opis tipova UML dijagrama može se vidjeti na istoj Wikipediji: UML - dijagrami ili u videu Timura Batyrshinova Pregled UML dijagrama. UML se također široko koristi za opisivanje različitih procesa, na primjer ovdje: Jednostruka prijava pomoću JWT-a. Vraćajući se upotrebi UML dijagrama klasa, vrijedi napomenuti knjigu Head First: Design Patterns, u kojoj su obrasci ilustrovani tim istim UML dijagramima. Ispostavilo se da se UML zaista koristi. I pokazalo se da je znanje i razumijevanje njegove primjene prilično korisna vještina.

Aplikacija

Pogledajmo kako možete raditi sa ovim istim UML-om iz IDE-a. Uzmimo kao IDE IntelliJ Idea. Ako koristite IntelliJ Idea Ultimate, tada ćemo imati instaliran dodatak "iz kutije" UML podrška". Omogućava vam da automatski generišete prekrasne dijagrame klasa. Na primjer, preko Ctrl+N ili stavke menija "Navigacija" -> "Klasa" idemo na klasu ArrayList. Sada, kroz kontekstni meni za naziv klase, odaberite “Diagram” -> “Show diagram popup”. Kao rezultat, dobijamo prekrasan dijagram:

Ali šta ako to želite sami da nacrtate, pa čak i ako ne želite Ultimate version Ideja? Ako koristimo IntelliJ Idea Community Edition, onda nemamo drugog izbora. Da biste to učinili, morate razumjeti kako je takav UML dijagram strukturiran. Prvo ćemo morati da instaliramo Graphviz. Ovo je skup uslužnih programa za vizualizaciju grafova. Koristi ga dodatak koji ćemo koristiti. Nakon instalacije potrebno je dodati direktorij bin iz instaliranog direktorija Graphviz na varijablu okruženja PUT. Nakon toga, u IntelliJ Idea, izaberite File -> Settings iz menija. U prozoru "Postavke" odaberite kategoriju "Dodaci", kliknite na dugme "Pregledaj spremišta" i instalirajte PlantUML dodatak za integraciju. Zašto je ovaj tako dobar? PlantUML? Koristi jezik opisa grafikona pod nazivom " dot"i to mu omogućava da bude univerzalniji, jer... dati jezik Ne koristi se samo PlantUML. Štaviše, sve što radimo u nastavku može se raditi ne samo u IDE-u, već iu online usluga planttext.com. Nakon instaliranja dodatka PlantUML, moći ćemo kreirati UML dijagrame kroz “File” -> “New”. Kreirajmo dijagram tipa "UML class". Tokom ovog procesa automatski se generiše šablon sa primerom. Izbrišemo njegov sadržaj i kreirajmo vlastiti, naoružani člankom sa Habra: Odnosi klasa - od UML-a do koda. A da bismo razumjeli kako to prikazati u tekstu, uzmimo PlantUML priručnik: plantuml class-diagram. Na samom početku nalazi se tabela koja pokazuje kako treba opisati veze:

Ovdje također možemo pogledati same veze: "Odnosi između klasa u UML-u. Primjeri." Na osnovu ovih materijala, krenimo sa kreiranjem našeg UML dijagrama. Dodajmo sljedeći sadržaj koji opisuje dvije klase: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Da biste vidjeli rezultat u Idea, odaberite "View" -> " Prozori alata" -> "PlantUML". Jednostavno ćemo dobiti dva kvadrata koja označavaju klase. Kao što znamo, obje ove klase implementiraju sučelje liste. Ovaj odnos klase se naziva implementacija. Da biste prikazali takav odnos, koristite strelicu sa tačkasta linija. Hajde da ga opišemo: interfejs Lista Lista< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о paket privatni niz elemenata: ~ Objekt elementData Sada želimo pokazati da ArrayList sadrži neke objekte. U ovom slučaju, tip veze će biti - agregacija(agregacija). Agregat u ovom slučaju je ArrayList, jer sadrži druge objekte. Mi biramo agregaciju jer objekti na listi mogu živjeti bez liste: oni nisu njen sastavni dio. Njihov životni vijek nije vezan za vijek trajanja liste. Agregat se sa latinskog prevodi kao "sastavljen", odnosno nešto što je od nečega sastavljeno. Na primjer, u životu postoji pumpna jedinica koja se sastoji od pumpe i motora. Sama jedinica se može rastaviti, ostavljajući dio komponente. Na primjer, prodati ili staviti u drugu jedinicu. Kao i lista. I to se izražava u obliku praznog romba u blizini jedinice i neprekidne linije. Opišimo je na sljedeći način: klasa Object ( ) ArrayList o- Object Sada želimo pokazati da, za razliku od ArrayList, klasa LinkedList sadrži Node - kontejnere koji se odnose na pohranjene podatke. U ovom slučaju, čvorovi su dio same LinkedList i ne mogu živjeti odvojeno. Čvor ne pohranjuje direktno sadržaj, već sadrži samo vezu do njega. Na primjer, kada dodamo red na LinkedList, dodajemo novi čvor koji sadrži vezu na taj red, kao i vezu na prethodni i sljedeći čvor. Ova vrsta veze se zove kompozicija(Kompozicija). Da bi se prikazao kompozit (onaj koji se sastoji od dijelova), nacrtan je dijamant u boji, s kontinuiranom linijom koja vodi do njega. Zapišimo sada ovo u obliku tekstualnog prikaza veze: klasa Node ( ) LinkedList * -- Node A sada moramo naučiti kako prikazati drugu važan tip komunikacije - ovisnost(odnos zavisnosti). Koristi se kada jedna klasa koristi drugu, a klasa ne sadrži klasu koja se koristi i nije njen potomak. Na primjer, LinkedList i ArrayList mogu kreirati ListIterator. Prikažimo ovo kao strelice sa isprekidanom linijom: klasa ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Možete ulaziti u onoliko detalja koliko je potrebno. Ovdje su naznačene sve oznake: "PlantUML - Class Diagram". Osim toga, u crtanju takvog dijagrama nema ničeg natprirodnog, a kada radite na svojim zadacima, možete ga brzo nacrtati rukom. Ovo će razviti vaše vještine u razmišljanju kroz arhitekturu aplikacije i pomoći vam da rano identificirate nedostatke strukture klase, a ne nakon što ste proveli dan implementirajući pogrešan model. Mislim da je to dobar razlog da probate?)

Automatizacija

Jedi razne načine automatsko generisanje PlantUML dijagrama. Na primjer, u Ideja Postoji SketchIT dodatak, ali ih ne crta sasvim ispravno. Na primjer, implementacija interfejsa je pogrešno nacrtana (prikazuje se kao nasljeđivanje). Na internetu postoje i primjeri kako to ugraditi životni ciklus izgradnju vašeg projekta. Recimo za Maven postoji primjer korištenja uml-java-docklet. Da bismo pokazali kako se to radi, koristit ćemo Maven Archetype za brzo stvaranje Maven projekat. Pokrenimo naredbu: mvn archetype:generate Po pitanju izbora filtera ( Odaberite broj ili primijenite filter) ostavite zadano jednostavnim pritiskom na Enter. uvijek će biti" maven-archetype-quickstart". Odaberite najnoviju verziju. Zatim odgovorite na pitanja i dovršite kreiranje projekta:

Budući da Maven nije u fokusu ovog članka, odgovori na vaša pitanja o Mavenu možete pronaći u Maven korisničkom centru. U generiranom projektu otvorite datoteku opisa projekta za uređivanje, pom.xml. Kopirajmo sadržaj iz opisa instalacije uml-java-docklet u njega. Artefakt korišten u opisu nije se mogao naći u Maven Central repozitoriju. Ali mi je uspjelo s ovim: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Odnosno, samo trebate zamijeniti u tom opisu groupId sa " info.leadinglight" na " com.chfourie"i instaliraj verziju" 1.0.0 ". Nakon toga možemo izvršiti u direktoriju u kojem se datoteka nalazi pom.xml ove naredbe: mvn clean install i mvn javadoc:javadoc . Sada, ako otvorimo generiranu dokumentaciju (explorer target\site\apidocs\index.html), vidjet ćemo UML dijagrame. Usput, implementacija je ovdje već ispravno prikazana)

Zaključak

Kao što vidite, UML vam omogućava da vizualizirate strukturu vaše aplikacije. Štaviše, UML nije ograničen samo na ovo. Koristeći UML, možete opisati različite procese u vašoj kompaniji ili opisati poslovni proces u okviru kojeg funkcioniše funkcija koju pišete. Koliko je UML koristan za vas lično, na vama je da odlučite, ali odvajanje vremena da ga pročitate detaljnije biće korisno u svakom slučaju. #Viacheslav engleska verzija ovog posta: UML dijagram Java na CodeGymu

Napomena: Predmet ovog kursa je UML - Unified Modeling Language. Prethodno predavanje govorilo je o tome šta je UML, 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 sljedeća pitanja: zašto je potrebno nekoliko vrsta dijagrama; vrste dijagrama; OOP i sekvenca dijagrama

Prije nego što pređemo na raspravu o glavnom materijalu ovog predavanja, hajde da razgovaramo o tome zašto uopće trebamo 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. Dobro osmišljeni modeli su veoma važni kako za interakciju unutar razvojnog tima, tako i za međusobno razumevanje sa kupcem. Na kraju, ovo osigurava da je dizajn "arhitektonski konzistentan" prije nego što se implementira u kodu.

Mi gradimo modele složenih sistema jer ih ne možemo u potpunosti opisati, „baciti pogled na njih“. Stoga ističemo samo svojstva sistema koja su bitna za određeni zadatak i gradimo njegov model koji prikazuje ta svojstva. Metoda objektno orijentisane analize nam omogućava da na najadekvatniji način opišemo stvarne složene sisteme. Ali kako se kompleksnost sistema povećava, javlja se potreba za dobrom tehnologijom modeliranja. Kao što smo već rekli u prethodnom predavanju, unificirana jezik modeliranja(Unified Modeling Language, UML), koji je grafički jezik za specifikaciju, vizualizaciju, projektovanje i dokumentovanje 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 njegove implementacije. Unutar UML modela, sve ideje o sistemu se bilježe u obliku posebnih grafičkih struktura koje se nazivaju dijagrami.

Bilješka. Razmotrit ćemo ne sve, već samo neke od tipova dijagrama. Na primjer, dijagram komponenti nije pokriven u ovom predavanju, već samo kratak pregled vrste dijagrama. Broj tipova grafikona za specifičan model aplikacije nisu ni na koji način ograničene. Za jednostavne aplikacije nema potrebe da se grade dijagrami 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 određenih vrsta dijagrama ovisi o specifičnostima određenog projekta. Informacije o drugim tipovima dijagrama (o kojima se ovdje ne govori) mogu se naći u UML standardu.

Zašto vam treba nekoliko vrsta dijagrama

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

Sistem- skup međusobno povezanih kontrolisanih podsistema ujedinjenih zajedničkom svrhom rada.

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

Sistem odnosi se na skup podsistema organiziranih za postizanje određenog cilja i opisanih korištenjem skupa modela, moguće sa različitih gledišta.

Pa, ne možete ništa učiniti, morat ćete potražiti definiciju podsistema. To takođe piše tamo podsistema je kolekcija elemenata, od kojih neki specificiraju ponašanje drugih elemenata. Ian Sommerville objašnjava ovaj koncept na sljedeći 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 je bolje. Govoreći „ljudskim“ jezikom, sistem je predstavljen kao skup jednostavnijih entiteta koji su relativno samodovoljni. Ovo se može uporediti sa onim kako u procesu razvoja programa gradimo GUI od standardnih “kockica” - vizuelnih komponenti, ili kako je i sam tekst programa podijeljen na module koji sadrže potprograme, objedinjene po funkcionalnosti, te se mogu ponovo koristiti u narednim programima.

Razumijemo 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 apstrakcija sistema Malo je vjerovatno da će to razjasniti situaciju, pa ćemo pokušati objasniti "svojim riječima".

Model- ovo je određeni (materijalni ili ne) objekat koji prikazuje samo najznačajnije karakteristike sistema za dati 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, s kojima smo se s takvim uzbuđenjem igrali u djetinjstvu, nisu ništa drugo do materijal umjetni ukrasni model pravog automobila. Naravno, takav "automobil" nema motor, ne punimo njegov rezervoar benzinom, a mjenjač ne radi (zaista, uopće nema mjenjača), 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 na ljudima. U ovom slučaju, životinja djeluje kao materijal prirodan ljudski modeli.

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

Ostaje samo reći šta je dijagram. Dijagram je grafički prikaz mnogih 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 raznu opremu, koje možemo vidjeti u korisničkim priručnicima, i stablo datoteka i direktorija na disku, koje možemo vidjeti izvršavanjem Windows konzola naredba stabla, i mnogo, mnogo više. U svakodnevnom životu dijagrami nas okružuju sa svih strana, jer crteže uočavamo lakše nego tekst...

No, vratimo se na dizajn softvera (i više). U ovoj industriji sa Dijagrami se mogu koristiti za vizualizaciju sistema iz različitih perspektiva. Jedan od dijagrama, na primjer, može opisati interakciju korisnika sa sistemom, drugi može opisati promjenu stanja sistema tokom njegovog rada, treći može opisati međusobnu interakciju elemenata sistema itd. Složen sistem može i treba biti predstavljen kao skup malih i gotovo nezavisnih modela – dijagrama, a nijedan od njih nije dovoljan da opiše sistem i dobije potpunu sliku o njemu, budući da se svaki od njih fokusira na određeni aspekt funkcionisanja sistema i izražava drugačije nivo apstrakcije. Drugim riječima, svaki model odgovara određenoj, posebnoj tački gledišta na projektovani sistem.

Uprkos činjenici da smo u prethodnom pasusu vrlo slobodno tretirali koncept modela, treba shvatiti da u kontekstu gornjih definicija nijedan pojedinačni dijagram nije model. Dijagrami su samo sredstvo za vizualizaciju modela, a dva koncepta se moraju razlikovati. Samo skup dijagrama čini model sistema i opisuje ga najpotpunije, ali ne samo jedan dijagram izvučen iz konteksta.

Vrste grafikona

Definiran UML 1.5 dvanaest tipova grafikona, podijeljen u tri grupe:

četiri tipa dijagrama predstavljaju statičku strukturu aplikacije;
pet predstavlja bihevioralne aspekte sistema;
tri predstavljaju fizičke aspekte rada sistema (dijagrami implementacije).

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

Međutim, tačan broj kanonski dijagrami za nas je to apsolutno nevažno, jer ćemo ih razmotriti ne sve, već samo neke - iz razloga što broj tipova dijagrama za određeni model određene aplikacije nije strogo fiksiran. Za jednostavne aplikacije nema potrebe da se gradi svaki pojedinačni dijagram. 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 upozna ovaj jezik i da početnu ideju o ovoj tehnologiji.

Dakle, ukratko ćemo pogledati takve vrste dijagrama 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ć ćemo si postaviti cilj da naučimo čitatelja da barem vizualno razlikuje vrste dijagrama i da da početnu ideju o namjeni glavnih tipova dijagrama. Dakle, počnimo.

Dijagram slučaja upotrebe

Svaki (uključujući softverski) sistem dizajniran je uzimajući u obzir činjenicu da će ih tokom njihovog rada koristiti ljudi i/ili biti u interakciji sa drugim sistemima. Pozivaju se entiteti sa kojima sistem komunicira tokom svog rada glumci, a svaki akter očekuje da se sistem ponaša na striktno definisan, predvidljiv način. Pokušajmo dati strožiju definiciju ektora. Da bismo to učinili, koristit ćemo prekrasan vizualni rječnik za UML Zicom Mentor:

Ektor (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, ektor je prikazan ili " mali čovek“, slične onima koje smo crtali kao djeca, prikazujući članove naše porodice, odn simbol klase sa odgovarajućim stereotipom, kao što je prikazano na slici. Oba oblika predstavljanja imaju isto značenje i mogu se koristiti u dijagramima. “Stereotipni” oblik se češće koristi za predstavljanje aktera sistema ili u slučajevima kada akter ima svojstva i ona moraju biti prikazana (slika 2.1).

Pažljivi čitalac može odmah pitati: zašto glumac a ne glumac? Slažemo se, riječ "ektor" je malo gruba za uši Rusa. Razlog zašto ovo kažemo je jednostavan - ektor je izveden iz riječi akcija, što u prevodu znači akcija. Doslovni prijevod riječi “ektor” je glumac- predugačak i nezgodan za upotrebu. Stoga ćemo i dalje ovako govoriti.

Rice. 2.1.

Isti pažljivi čitalac je možda primijetio da riječ "presedan" treperi kroz definiciju ektora. Šta je? Ovo pitanje će nas još više zanimati ako se sjetimo o čemu sada govorimo dijagram slučaja upotrebe. dakle,

Slučaj upotrebe- opis posebnog aspekta ponašanja sistema sa stanovišta korisnika (Butch).

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

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

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

formiranje opštih zahteva za ponašanje projektovanog sistema;

razvoj konceptualnog modela sistema za njegovu naknadnu detaljizaciju;

priprema dokumentacije za interakciju sa kupcima i korisnicima sistema.

11.1. Struktura objedinjenog jezika modeliranja

Unified Modeling Language (UML) je trenutno de facto standard za opisivanje (dokumentovanje) rezultata dizajna i razvoja objektno orijentisanih sistema. Razvoj UML-a započeli su 1994. Grady Booch i James Rumbaugh, koji su radili u Rational Software-u. U jesen 1995. pridružio im se Ivar Jacobson, au oktobru iste godine objavljena je preliminarna verzija 0.8 Unified Methoda. Od tada je objavljeno nekoliko verzija UML specifikacije, od kojih dvije imaju status međunarodnog standarda:

UML 1.4.2 – "ISO/IEC 19501:2005. informacione tehnologije. Otvorena obrada distribucije. Unified Modeling Language (UML). Verzija 1.4.2" (engleski "Informaciona tehnologija. Otvorena distribuirana obrada. Jedinstveni jezik modeliranja (UML). Verzija 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informaciona tehnologija. Objedinjeni jezik modeliranja grupe za upravljanje objektima (OMG UML). Dio 1. Infrastruktura" (eng. "Informaciona tehnologija -- Objedinjeni jezik za modeliranje grupe za upravljanje objektima (OMG UML) - Dio 1: Infrastruktura") i "ISO/IEC 19505-2:2012. Informaciona tehnologija. Grupa za upravljanje objektima Unified Modeling Language (OMG UML). Dio 2. Superstruktura" (eng. "Informacijska tehnologija -- Grupa za upravljanje objektima Unified Modeling Language (OMG UML) - Dio 2: Superstruktura").

Najnovija specifikacija službenog jezika može se naći na www.omg.org.

Opšta struktura UML-a prikazana je na sljedećoj slici.

Rice. 11.1. UML struktura

11.2. UML semantika i sintaksa

Semantika - grana lingvistike koja proučava značenje jezičkih jedinica, prvenstveno njegovih riječi i izraza.

Sintaksa – načini spajanja riječi i njihovih oblika u fraze i rečenice, spajanja rečenica u složene rečenice, načina stvaranja iskaza kao dijela teksta.

Dakle, u odnosu na UML, semantika i sintaksa određuju stil prezentacije (izgradnja modela), koji kombinuje prirodne i formalne jezike da bi se predstavili osnovni koncepti (elementi modela) i mehanizmi za njihovo proširenje.

11.3. UML notacija

Notacija je grafička interpretacija semantike za njen vizuelni prikaz.

UML definiše tri tip entiteta :

Strukturno - apstrakcija koja je odraz konceptualnog ili fizičkog objekta;

Grupisanje – element koji se koristi za neku semantičku kombinaciju elemenata dijagrama;

Objašnjenje (anotativno) – komentar na element dijagrama.

Sljedeća tabela pokazuje Kratki opis glavni entiteti koji se koriste u grafičkom zapisu i glavni načini njihovog prikazivanja.

Tabela 11.1. Entiteti

Tip	Ime	Oznaka	definicija (semantika)
Strukturno	(razred)		Mnogi objekti koji imaju opšta struktura i ponašanje
	(objekat)		Apstrakcija stvarnog ili zamišljenog entiteta sa jasno definisanim konceptualnim granicama, ličnošću, stanjem i ponašanjem. Sa UML tačke gledišta, objekti su instance klase (instance entiteta)
	(glumac)	Inženjer usluge staza	Entitet izvan sistema koji je u interakciji sa sistemom i koristi ga funkcionalnost za postizanje određenih ciljeva ili rješavanje određenih problema. Dakle, glumac je eksterni izvor ili primaoca informacija
	(slučaj upotrebe)		Opis radnji koje sistem izvodi, što dovodi do značajnog rezultata za aktera
	(država)		Opis trenutka u životu entiteta kada on zadovoljava neki uslov, obavlja neku aktivnost ili čeka da se dogodi neki događaj.
	Saradnja (saradnja)		Opis skupa instanci aktera, objekata i njihove interakcije u procesu rješavanja određenog problema
	(komponenta)		Fizički dio sistema (fajl), uključujući sistemske module koji obezbjeđuju implementaciju konzistentnog skupa interfejsa
	(sučelje)	iCalculation	Skup operacija koji definira uslugu (skup usluga) koju pruža klasa ili komponenta
	(čvor)		Fizički dio sistema (računar, štampač, itd.) koji obezbjeđuje resurse za rješavanje problema
Grupisanje	(paket)		Opšti mehanizam za grupisanje elemenata. Za razliku od komponente, paket je čisto konceptualni (apstraktni) koncept. Posebni slučajevi paketa su sistem i model
	(fragment)		Područje specifične interakcije između instanci aktera i objekata
	(particija aktivnosti)		Grupa operacija (područje odgovornosti) koje obavlja jedan entitet (akter, objekat, komponenta, čvor, itd.)
	(regija prekinute aktivnosti)		Grupa operacija čiji se normalan redoslijed izvođenja može prekinuti zbog pojave neobične situacije
Objašnjavajuće	Bilješka (komentar)		Komentar za element. Pričvršćuje se na komentarisani element isprekidanom linijom

Neki izvori, posebno [,], također identificiraju entitete ponašanja interakcije I konačnih mašina, ali sa logičke tačke gledišta treba ih klasificirati kao dijagrame.

Neki od navedenih entiteta prema njima ih podrazumijevaju Detaljan opis na dijagramima dekompozicije. Na dijagramu najvišeg nivoa oni su označeni posebnom ikonom ili oznakom.

Sljedeća tabela daje opis svih tipova odnosi UML se koristi u dijagramima za označavanje odnosa između entiteta.

Tabela 11.3. Veza

Ime	Oznaka	definicija (semantika)
Udruženje		Opisivanje odnosa smislena veza između dva ili više entiteta. Većina opšti oblik odnos
Agregacija		Podtip asocijacije koji opisuje odnos “dio” – “cjelina”, u kojem “dio” može postojati odvojeno od “cjeline”. Romb je označen sa "cijele" strane. Odnos je specificiran samo između entiteta istog tipa
Kompozicija		Podtip agregacije u kojoj “dijelovi” ne mogu postojati odvojeno od “cjeline”. Po pravilu, "delovi" se stvaraju i uništavaju istovremeno sa "celinom"
Zavisnost		Odnos između dva entiteta u kojem promjena jednog entiteta (nezavisnog) može utjecati na stanje ili ponašanje drugog entiteta (zavisnog). Strana sa strelicom označava nezavisni entitet
Generalizacija		Odnos između generalizovanog entiteta (predak, roditelj) i specijalizovanog entiteta (potomak, ćerka). Trougao je označen sa strane roditelja. Odnos je specificiran samo između entiteta istog tipa
Realizacija		Odnos između entiteta u kojem jedan entitet specificira radnju koju drugi entitet poduzima da izvrši. Odnosi se koriste u dva slučaja: između interfejsa i klasa (ili komponenti), između slučajeva upotrebe i saradnje. Strana sa strelicom označava entitet koji definira radnju (sučelje ili slučaj upotrebe)

Za povezivanje, agregacija i sastav se mogu specificirati višestrukost (eng. multiplicity), karakterizira ukupan broj instanci entiteta koji učestvuju u odnosu. Obično je naznačeno na svakoj strani odnosa u blizini odgovarajućeg entiteta. Višestrukost se može naznačiti na sljedeće načine:

- * – bilo koji broj kopija, uključujući nijedan;

Nenegativan cijeli broj – višestrukost je strogo fiksna i jednaka navedenom broju (na primjer: 1, 2 ili 5);

Raspon nenegativnih cijelih brojeva "prvi broj.. drugi broj" (na primjer: 1..5, 2..10 ili 0..5);

Raspon brojeva od određene početne vrijednosti do proizvoljnog konačnog "prvog broja.. *" (na primjer: 1..*, 5..* ili 0..*);

Navođenje nenegativnih cijelih brojeva i raspona odvojenih zarezima (na primjer: 1, 3..5, 10, 15..*).

Ako višestrukost nije specificirana, tada se pretpostavlja da je njegova vrijednost 1. Višestrukost instanci entiteta koji učestvuju u zavisnosti, generalizaciji i implementaciji uvijek se pretpostavlja da je 1.

Sljedeća tabela daje opis mehanizmi proširenja , koji se koristi za pojašnjavanje semantike entiteta i odnosa. Općenito, mehanizam proširenja je niz teksta zatvoren u zagradama ili navodnicima.

Tabela 11.4. Mehanizmi proširenja

Ime	Oznaka	definicija (semantika)
Stereotip (stereotip)	« »	Oznaka koja specificira semantiku elementa notacije (na primjer: zavisnost sa stereotipom "include" smatra se relacijom uključivanja, a klasa sa stereotipom "graničnog" je granična klasa)
Zaštitno stanje (uvjet za čuvanje)		Boolean uvjet (na primjer: ili [identifikacija dovršena])
Ograničenje (ograničenje)	{ }	Pravilo koje ograničava semantiku elementa modela (na primjer, (vrijeme izvršenja manje od 10 ms))
Označena vrijednost (označena vrijednost)	{ }	Novo ili pojašnjavajuće svojstvo elementa notacije (na primjer: (verzija = 3.2))

Pored stereotipa označenih kao niz teksta u navodnicima, grafički stereotipi se mogu koristiti u dijagramima. Sljedeća slika prikazuje primjere standardnog i stereotipnog prikaza.


a) standardna oznaka		b) standardna oznaka sa stereotipom teksta		c) grafički stereotip

Rice. 11.2. Primjeri standardnog i stereotipnog prikaza klase

Dijagram predstavlja grupiranje elemenata notacije za prikaz nekog aspekta razvijenog informacioni sistem. Dijagrami su obično povezani graf u kojem su entiteti vrhovi, a odnosi lukovi. Sledeća tabela daje kratak opis UML dijagrami.

Tabela 11.5. Dijagrami

Dijagram			Svrha
				prema stepenu fizičke implementacije	prikazom dinamike	prema prikazanom aspektu
(slučaj upotrebe)			Prikazuje funkcije sistema, interakcije između aktera i funkcija	Logično	Statički	Funkcionalni
(razred)			Prikazuje skup klasa, interfejsa i odnosa između njih	Logično ili fizički	Statički	Funkcionalne i informativne
(paket)			Prikazuje skup paketa i odnose između njih	Logično ili fizički	Statički	Komponenta
ponašanja (ponašanje)	(državna mašina)		Prikazuje stanja entiteta i prelaze između njih tokom njegovog životnog ciklusa	Logično	Dynamic	Behavioral
	(aktivnost)		Prikazuje poslovne procese u sistemu (opis algoritama ponašanja)
	Interakcije (interakcija)	(sekvenca)	Prikazuje redoslijed prolaska poruka između objekata i aktera
		(komunikacija)	Slično dijagramu sekvence, ali naglasak je na strukturi interakcija između objekata
Implementacije (implementacija)	(komponenta)		Prikazuje komponente sistema (programe, biblioteke, tabele, itd.) i veze između njih	Fizički	Statički	Komponenta
	(raspoređivanje)		Prikazuje smještaj komponenti na mrežnim čvorovima, kao i njihovu konfiguraciju

UML 2.x standard također definira dodatne, visoko specijalizirane dijagrame:

Dijagram objekata - slično, ali se objekti prikazuju umjesto klasa;

Vremenski dijagram - opisuje stanje objekta tokom vremena;

Kompozitni dijagram strukture - opisuje portove (uključujući interfejse) klase za interakciju sa drugim klasama;

Dijagram profila - slično sa opisom klasa uključenih u njih;

Dijagram pregleda interakcije - sličan, ali sa skrivenim fragmentima interakcije (fragmenti označeni kao ref). Predstavlja kontekstualni (konceptualni) element, čiji će elementi biti specificirani na zasebnim dijagramima dekompozicije.

Za potrebe proširenog konceptualnog prikaza unutrašnje arhitekture sistema, većina konstrukcija dozvoljava upotrebu ustaljenih grafičkih stereotipa za tzv. Takav dijagram se naziva 1, ali ne pripada listi dijagrama definiranih UML standardom.

Prilikom razvoja zasebnog modela sistema, gradi se nekoliko tipova dijagrama. Štaviše, pri razvoju modela složenog sistema, po pravilu se konstruiše nekoliko dijagrama istog tipa. Istovremeno, ne morate da kreirate zasebne tipove grafikona ako to nije neophodno. Na primjer, dijagrami i su zamjenjivi; oni su napravljeni samo za objekte sa složenim ponašanjem. Sljedeća tabela daje preporuke o potrebi razvoja (razjašnjenja) dijagrama za modele sistema.

Tabela 11.6. Odnos između modela i dijagrama

U tabeli ispod nije prikazan model testiranja, jer se u sklopu njegove konstrukcije dijagrami ne razvijaju, već se provjeravaju (testiraju) na potpunost i konzistentnost.

Neki od dijagrama nakon njihove izrade zahtijevaju razvoj i pojašnjenje kao dio razvoja sljedećeg modela ( tehnološki proces). Tako, na primjer, treba ih razjasniti tokom razvoja. U modelima.

4. Definirajte pojam " ".