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

UML je objedinjeni grafički jezik za modeliranje za opisivanje, vizualizaciju, projektiranje i dokumentiranje OO sustava. UML je osmišljen kako bi podržao proces modeliranja softvera temeljen na OO pristupu, organizirao odnos konceptualnih i programskih koncepata te odražavao probleme skaliranja složenih sustava. UML modeli se koriste u svim fazama životnog ciklusa softvera, od poslovne analize do održavanja sustava. Različite organizacije mogu koristiti UML kako smatraju prikladnim, ovisno o svojim problematičnim područjima i tehnologijama koje koriste.

Kratka povijest UML-a

Do sredine 90-ih različiti su autori predložili nekoliko desetaka metoda OO modeliranja, od kojih je svaka koristila vlastitu grafičku notaciju. Štoviše, svaka od ovih metoda imala je svoje snage, ali nije dopustio da se dovoljno izgradi puni model PS, prikaži "sa svih strana", odnosno sve potrebne projekcije (vidi članak 1). Osim toga, nedostatak standarda OO modeliranja otežavao je programerima odabir najprikladnije metode, što je spriječilo široko usvajanje OO pristupa razvoju softvera.

Na zahtjev Object Management Group (OMG), organizacije zadužene za donošenje standarda u području 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 snagama stvorili verziju UML 1.1, odobrenu od strane OMG-a 1997. kao standard.

UML je jezik

Svaki jezik sastoji se od vokabulara i pravila za kombiniranje riječi za stvaranje smislenih konstrukcija. To je, posebno, kako su strukturirani programski jezici, kao što je UML. Njegova posebnost je da je jezični rječnik sastavljen od grafičkih elemenata. Svaki grafički simbol ima specifičnu semantiku, tako da model koji je izradio jedan programer drugi može jasno razumjeti, a također softver, tumačenje UML-a. Odavde, posebice, slijedi da se softverski model predstavljen u UML-u može automatski prevesti u OO programski jezik (kao što su Java, C++, VisualBasic), to jest, ako postoji dobar alat za vizualno modeliranje koji podržava UML, imajući izgradili model, također ćemo dobiti primjer programskog koda koji odgovara ovom modelu.

Treba naglasiti da je UML jezik, a ne metoda. Objašnjava od kojih elemenata izraditi modele i kako ih čitati, ali ne govori ništa o tome koje modele treba razvijati i u kojim slučajevima. Za izradu metode temeljene na UML-u potrebno ju je dopuniti opisom procesa razvoja softvera. Primjer takvog procesa je Rational Unified Process, o kojem će biti riječi u sljedećim člancima.

UML rječnik

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 vrste entiteta - strukturni (klasa, sučelje, komponenta, slučaj upotrebe, suradnja, čvor), bihevioralni (interakcija, stanje), grupiranje (paketi) i komentar (komentari). Svaki tip entiteta ima svoj grafički prikaz. Entiteti će biti detaljno obrađeni prilikom proučavanja dijagrama.

Odnos pokazuju razne veze između entiteta. UML definira sljedeće vrste odnosa:

Ovisnost pokazuje takvu vezu između dva entiteta kada promjena u jednom od njih – nezavisnom – može utjecati na semantiku drugog – zavisnog. Ovisnost je prikazana točkastom strelicom usmjerenom od ovisnog entiteta prema nezavisnom.
Udruga je strukturni odnos koji pokazuje da su objekti jednog entiteta povezani s objektima drugog. Grafički, asocijacija je prikazana kao linija koja povezuje pridružene entitete. Asocijacije služe za navigaciju između objekata. Na primjer, veza 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, - s drugim. Jasno je da odgovarajući programi moraju implementirati mehanizam koji omoguć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 rombom na kraju u blizini essence-cjeline.
Generalizacija je odnos između nadređenog entiteta i podređenog entiteta. U biti, ovaj odnos odražava svojstvo nasljeđivanja za klase i objekte. Generalizacija je prikazana kao linija koja završava trokutom usmjerenim prema nadređenom entitetu. Dijete nasljeđuje strukturu (atribute) i ponašanje (metode) roditelja, ali istovremeno može imati nove elemente strukture i nove metode. UML dopušta višestruko nasljeđivanje, gdje je entitet povezan s više od jednog roditeljskog entiteta.
Provedba– odnos između entiteta koji definira specifikaciju ponašanja (sučelje) s entitetom koji definira implementaciju tog ponašanja (klasa, komponenta). Ovaj se odnos obično koristi pri modeliranju komponenti i bit će detaljnije opisan u sljedećim člancima.

Dijagrami. UML nudi sljedeće dijagrame:

Dijagrami koji opisuju ponašanje sustava:

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

Dijagrami koji opisuju fizičku implementaciju sustava:

Dijagrami komponenti;
Dijagrami postavljanja.

Kontrolni prikaz modela. Paketi.

Već smo rekli da je model, kako bi ga ljudi dobro razumjeli, potrebno hijerarhijski organizirati, ostavljajući mali broj entiteta na svakoj razini hijerarhije. UML uključuje sredstva za organiziranje hijerarhijskog prikaza modela - pakete. Bilo koji model sastoji se od skupa paketa koji mogu sadržavati klase, slučajeve upotrebe i druge entitete i dijagrame. Paket može sadržavati druge pakete, omogućujući stvaranje hijerarhija. UML ne nudi zasebne dijagrame paketa, ali se mogu pojaviti u drugim dijagramima. Paket je prikazan kao pravokutnik s oznakom.

Što UML pruža.

hijerarhijski opis složenog sustava identificiranjem paketa;
formalizacija funkcionalnih zahtjeva za sustav korištenjem aparata slučajeva uporabe;
detaljiziranje zahtjeva sustava konstruiranjem dijagrama aktivnosti i scenarija;
identificiranje klasa podataka i konstruiranje konceptualnog modela podataka u obliku dijagrama klasa;
identificiranje klasa koje opisuju korisničko sučelje i stvaranje navigacijske sheme zaslona;
opis procesa interakcije objekata pri obavljanju funkcija sustava;
opis ponašanja objekta u obliku dijagrama aktivnosti i stanja;
opis programskih komponenti i njihove interakcije kroz sučelja;
opis fizičke arhitekture sustava.

I zadnja stvar...

Unatoč svoj atraktivnosti UML-a, bilo bi ga teško koristiti u stvarnom softverskom modeliranju bez alata za vizualno modeliranje. Takvi alati vam omogućuju brzo predstavljanje dijagrama na zaslonu, njihovo dokumentiranje, generiranje predložaka programskog koda u različitim OO programskim jezicima i stvaranje shema baze podataka. Većina njih uključuje mogućnost reinženjeringa programskih kodova – vraćanje određenih projekcija softverskog modela automatskom analizom izvornih kodova programa, što je vrlo važno kako bi se osigurala usklađenost između modela i kodova te kod projektiranja sustava koji nasljeđuju funkcionalnost prethodnika.

10.4. UML DIJAGRAMI

10.4.1. Vrste UML vizualnih dijagrama

UML vam omogućuje stvaranje nekoliko vrsta vizualnih dijagrama:

Dijagrami slučajeva uporabe;

Dijagrami sekvenci;

Zadružne karte;

Dijagrami klasa;

Dijagrami stanja;

Dijagrami komponenti;

Dijagrami postavljanja.

Dijagrami ilustriraju različite aspekte sustava. Na primjer, kooperativni dijagram pokazuje kako objekti moraju međusobno djelovati da bi implementirali neku funkcionalnost sustava. Svaki dijagram ima svoju svrhu.

10.4.2. Dijagrami slučajeva uporabe

Dijagrami slučajeva upotrebe prikazuju interakcije između slučajeva upotrebe, koji predstavljaju funkcije sustava, i aktera, koji predstavljaju ljude ili sustave koji primaju ili prenose informacije ovaj sustav. Primjer dijagrama slučaja upotrebe za bankomat (ATM) prikazan je na sl. 10.1.

Riža. 10.1. Dijagram slučajeva uporabe

Dijagram predstavlja interakcije između slučajeva upotrebe i aktera. Odražava zahtjeve sustava s korisnikove točke gledišta. Stoga su slučajevi upotrebe funkcije koje obavlja sustav, a akteri su dionici u odnosu na sustav koji se stvara. Dijagrami pokazuju koji akteri pokreću slučajeve upotrebe. Također pokazuju kada akter prima informacije iz slučaja upotrebe. U biti, dijagram slučaja upotrebe može ilustrirati zahtjeve sustava. U našem primjeru, klijent banke inicira različite slučajeve korištenja: “Podignite novac s računa”, “Prijenos novca”, “Uplatite novac na račun”, “Prikaži stanje”, “Promijeni ID broj”, “Izvrši plaćanje”. Zaposlenik banke može pokrenuti slučaj korištenja promjene identifikacijskog broja. Iz slučaja upotrebe "Izvrši plaćanje" nalazi se strelica do kreditnog sustava. Glumci mogu biti vanjski sustavi, u ovom slučaju Kreditni sustav prikazan je upravo kao akter - on je vanjski u odnosu na ATM sustav. Strelica koja pokazuje od slučaja upotrebe do aktera označava da slučaj upotrebe pruža neke informacije akteru. U ovom slučaju, slučaj upotrebe Izvrši plaćanje pruža kreditnom sustavu informacije o plaćanju kreditnom karticom.

Dijagrami slučajeva uporabe mogu pružiti dosta informacija o sustavu. Ova vrsta dijagrama opisuje cjelokupnu funkcionalnost sustava. Korisnici, voditelji projekata, analitičari, programeri, stručnjaci za osiguranje kvalitete i svi zainteresirani za sustav u cjelini mogu pogledati dijagrame slučajeva uporabe kako bi razumjeli što bi sustav trebao raditi.

10.4.3. Dijagrami sekvenci

Dijagrami slijeda prikazuju tok događaja koji se pojavljuju unutar slučaja upotrebe. Na primjer, slučaj upotrebe "Podignite novac" nudi nekoliko mogućih nizova: podizanje novca, pokušaj podizanja novca kada nema dovoljno novca na računu, pokušaj podizanja novca korištenjem netočnog identifikacijskog broja i neki drugi. Uobičajeni scenarij za podizanje 20 USD s računa (u nedostatku problema kao što je netočan identifikacijski broj ili nedovoljno sredstava na računu) prikazan je na slici. 10.2.

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

Vrh dijagrama prikazuje sve aktere i objekte koji su potrebni sustavu za izvršenje slučaja korištenja povlačenja novca. Strelice odgovaraju porukama koje se prenose između aktera i objekta ili između objekata za izvođenje potrebnih funkcija. Također treba napomenuti da dijagram sekvenci prikazuje objekte, a ne klase. Klase su tipovi objekata. Objekti su betonski; umjesto razreda Klijent Dijagram sekvenci predstavlja određenog kupca, Joea.

Slučaj upotrebe počinje kada korisnik umetne svoju karticu u čitač - ovaj objekt je prikazan u pravokutniku na vrhu dijagrama. Očitava broj kartice, otvara objekt Joe Account i inicijalizira zaslon bankomata. Zaslon pita Joea za njegov registarski broj. Kupac unosi broj 1234. Zaslon provjerava broj u odnosu na objekt Joe Account i otkriva da je točan. Zaslon zatim prikazuje Joea s izbornikom za odabir, a on odabire "Podignite novac". Zaslon pita koliko želi podići, a Joe upisuje 20 dolara. Ekran povlači novac s računa. Pritom pokreće niz procesa koje provodi objekt "Joeov račun". Ujedno se provjerava da ovaj račun sadrži, prema barem, 20 dolara i traženi iznos se odbija od računa. Blagajna tada dobiva upute da "izda ček i 20 dolara u gotovini". Na kraju, isti objekt "Joe's account" upućuje čitač kartice da vrati karticu.

Tako, ovaj dijagram niz ilustrira niz radnji koje implementiraju slučaj upotrebe "Podignite novac s računa" koristeći konkretan primjer Joeovog klijenta koji je podigao 20 USD. Gledajući ovaj dijagram, korisnici se upoznaju sa specifičnostima svog rada. Analitičari vide slijed (tijek) akcija, programeri vide objekte koje je potrebno kreirati i njihove operacije. Stručnjaci za kontrolu kvalitete razumjet će detalje procesa i mogu razviti testove za njihovu provjeru. Stoga su sekvencijski dijagrami korisni svima koji su uključeni u projekt.

10.4.4. Zadružne karte

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

Kao i prije, objekti su prikazani kao pravokutnici, a likovi kao figure. Dok sekvencijski dijagram prikazuje interakciju između aktera i objekata tijekom vremena, kooperativni dijagram ne pokazuje nikakav odnos tijekom vremena. Dakle, možete vidjeti da čitač kartica upućuje "Joeov račun" da se otvori, a "Joeov račun" uzrokuje da uređaj vrati karticu vlasniku. Objekti koji izravno djeluju povezani su linijama. Ako, primjerice, čitač kartica komunicira izravno sa zaslonom bankomata, između njih treba povući crtu. Odsutnost linije znači da nema izravne komunikacije između objekata.

Riža. 10.3. Kooperativni dijagram koji opisuje proces povlačenja novca s računa

Dakle, kooperativni dijagram prikazuje iste informacije kao i sekvencijski dijagram, ali je potreban za drugu svrhu. Stručnjaci za osiguranje kvalitete i arhitekti sustava moći će razumjeti distribuciju procesa između objekata. Recimo da neka vrsta kooperativnog dijagrama nalikuje zvijezdi, gdje je nekoliko objekata povezano s jednim središnjim objektom. Arhitekt sustava može zaključiti da je sustav previše ovisan o središnjem entitetu i da ga treba redizajnirati kako bi se procesi ravnomjernije distribuirali. U dijagramu sekvenci ovu vrstu interakcije bilo bi teško vidjeti.

10.4.5. Dijagrami klasa

Dijagrami klasa odražavaju interakcije između klasa u sustavu. 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ču na te podatke. Dakle, klasa Account sadrži identifikacijski broj klijenta i radnje koje ga provjeravaju. U dijagramu klasa, klasa se stvara za svaki tip objekta iz sekvencijskih dijagrama ili kooperativnih dijagrama. Dijagram klasa za slučaj upotrebe povlačenja novca prikazan je na sl. 10.4.

Dijagram prikazuje odnose između klasa koje implementiraju slučaj korištenja povlačenja novca. Četiri su klase uključene u ovaj proces: čitač kartica, račun, ekran bankomata i aparat za izdavanje gotovine. Svaka klasa u dijagramu klasa prikazana je kao pravokutnik podijeljen na tri dijela. Prvi dio označava naziv klase, drugi - njen atributi. Atribut je neka informacija koja karakterizira klasu. Na primjer, klasa računa ima tri atributa: broj računa, PIN i stanje. Posljednji dio sadrži operacije klase, odražavajući njezinu ponašanje(radnje koje izvodi klasa). Linije koje povezuju klase pokazuju interakcije između klasa.

Riža. 10.4. Dijagram klasa

Programeri koriste dijagrame klasa za stvaranje klasa. Alati poput Rose generiraju jezgru koda klase koju programeri popunjavaju detaljima na jeziku po vlastitom izboru. Pomoću ovih dijagrama analitičari mogu prikazati detalje sustava, a arhitekti mogu razumjeti njegov dizajn. Ako npr. klasa nosi preveliko funkcionalno opterećenje, to će biti vidljivo u dijagramu klasa, a arhitekt to može preraspodijeliti među ostalim klasama. Dijagram također može pomoći u identificiranju slučajeva u kojima nisu definirani odnosi između klasa koje komuniciraju. Trebalo bi izraditi dijagrame klasa kako bi se prikazale klase u interakciji u svakom slučaju upotrebe. Također možete izgraditi općenitije dijagrame koji pokrivaju sve sustave ili podsustave.

10.4.6. Dijagrami stanja

Dijagrami stanja dizajnirani su za modeliranje različitih stanja u kojima objekt može biti. Dok dijagram klasa prikazuje statičnu sliku klasa i njihovih odnosa, dijagrami stanja se koriste za opisivanje dinamike ponašanja sustava.

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

Riža. 10.5. Dijagram stanja za klasu računa

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". Poziva se zahtjev klijenta događaj, događaji su ti koji uzrokuju prijelaz iz jednog stanja u drugo.

Kada korisnik podiže novac s otvorenog računa, račun može ući u stanje prekoračenja. To se događa samo ako je stanje na računu manje od nule, što se odražava u stanju [negativnog stanja] 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.

U dijagramu postoje dva posebna stanja - početni I konačni. Početno stanje označeno je crnom točkom: ono odgovara stanju objekta u trenutku njegovog stvaranja. Konačno stanje označeno je crnom toč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 možda uopće nema.

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

Grafikone stanja nije potrebno izraditi za svaku klasu, oni se koriste samo u vrlo složenim slučajevima. Ako objekt klase može postojati u više stanja i ponaša se drugačije u svakom stanju, vjerojatno će trebati takav dijagram. Međutim, mnogi projekti ih uopće ne koriste. Ako su dijagrami stanja izgrađeni, programeri ih mogu koristiti pri stvaranju klasa.

Grafikoni stanja su potrebni uglavnom za dokumentaciju.

10.4.7. Dijagrami komponenti

Dijagrami komponenti pokazuju kako model izgleda fizička razina. Prikazuje komponente softver vaš sustav i veze između njih. Postoje dvije vrste komponenti: izvršne komponente i biblioteke koda.

Na sl. Slika 10.6 prikazuje jedan od dijagrama komponenti ATM sustava. Ovaj dijagram prikazuje komponente klijenta ATM sustava. U ovom slučaju, razvojni tim je odlučio izgraditi sustav koristeći C++ jezik. Svaka klasa ima vlastitu datoteku zaglavlja i datoteku proširenja. CPP, tako da se svaka klasa transformira u vlastite komponente u dijagramu. Poziva se odabrana tamna komponenta specifikacija paketa i odgovara datoteci tijela klase ATM u C++ (datoteka s nastavkom. CPP). Neodabrana komponenta također se naziva specifikacija paketa, ali odgovara datoteci zaglavlja klase jezika C++ (datoteka s nastavkom .H). komponenta bankomata. EXE je specifikacija zadatka i predstavlja tijek obrade informacija. U ovom slučaju, nit za obradu je izvršni program.

Komponente su povezane isprekidanom linijom koja predstavlja ovisnosti među njima. Sustav može imati dijagrame više komponenti ovisno o broju podsustava ili izvršne datoteke. Svaki podsustav je paket komponenti.

Dijagrame komponenti koriste oni sudionici projekta koji su odgovorni za sastavljanje sustava. Dijagram komponenti daje ideju o redoslijedu kojim komponente treba kompajlirati, kao io tome koje će izvršne komponente sustav kreirati. Dijagram prikazuje mapiranje klasa u implementirane komponente. Dakle, potreban je tamo gdje počinje generiranje koda.

Riža. 10.6. Dijagram komponenti

10.4.8. Dijagrami postavljanja

Dijagrami rasporeda pokazuju fizičku lokaciju različitih komponenti sustava na mreži. U našem primjeru, ATM sustav sastoji se od velikog broja podsustava koji rade na zasebnim fizičkim uređajima ili čvorovima. Dijagram postavljanja ATM sustava prikazan je na sl. 10.7.

Iz ovog dijagrama možete saznati više o fizičkom izgledu sustava. Klijentski programi bankomata izvodit će se na više lokacija na više stranica. Klijenti će komunicirati s regionalnim ATM serverom kroz zatvorene mreže. Pokretat će softver ATM poslužitelja. Zauzvrat, kroz lokalna mreža regionalni poslužitelj komunicirat će s poslužiteljem bankarske baze podataka koji pokreće Oracle. Na kraju, pisač je spojen na regionalni ATM poslužitelj.

Dakle, ovaj dijagram prikazuje fizički izgled sustava. Na primjer, naš ATM sustav slijedi troslojnu arhitekturu, s bazom podataka na prvom sloju, regionalnim poslužiteljem na drugom i klijentom na trećem.

10.7. Dijagram postavljanja

Dijagram izgleda koriste voditelj projekta, korisnici, arhitekt sustava i operativno osoblje kako bi razjasnili fizički izgled sustava i lokaciju njegovih pojedinačnih podsustava. Voditelj projekta objasnit će korisnicima kako će izgledati gotov proizvod. Operativno osoblje moći će planirati radove instalacije sustava.

Iz knjige Microsoft Office Autor Leontjev Vitalij Petrovič

Grafikoni Brojevi u tablici ne omogućuju vam uvijek da dobijete potpuni dojam, čak i ako su poredani na način koji vam najviše odgovara. Koristeći one dostupne od Microsofta Excel predlošci dijagrame, možete dobiti jasnu sliku podataka u vašoj tablici, a ne

Iz knjige Računalo za 100. Počnimo s Windows Vista autor Zozulya Yuri

Grafikoni Grafikoni se koriste za prikaz tabelarnih podataka grafički oblik, koji mogu značajno poboljšati preglednost informacija, prikazati odnos između različitih parametara ili dinamiku njihove promjene. Za umetanje dijagrama u Word, koristite alate

Iz knjige Učinkovit uredski rad Autor Ptašinskij Vladimir Sergejevič

Dijagrami Najvizualniji Excel sposobnost je prikaz rezultata izračuna ili akumuliranih podataka u obliku grafikona (dijagrama): ponekad najimpresivnije brojke nisu u stanju uvjeriti na način na koji se to može učiniti čak i jednostavnom grafikom. Excel ima

Iz Excel radne knjige. Multimedijski tečaj autor Medinov Oleg

Poglavlje 8 Dijagrami Često Excel program koriste se za izradu dokumenata koji predstavljaju različita statistička i analitička izvješća. To mogu biti izvješća o prodaji, tablice mjerenja temperature zraka, podaci iz socioloških istraživanja itd. Brojevi nisu uvijek

Iz knjige Word 2007. Popularni tutorial autor Krainsky I

Izrada grafikona Za prvi primjer, morat ćete stvoriti tablicu prikazanu na sl. 8.1. Riža. 8.1. Tablica mjerenja temperature Na temelju podataka u ovoj tablici konstruirat ćemo jednostavan grafikon promjena temperature.1. Odaberite popunjeni raspon u tablici.2. Ići

Iz knjige Samoučni priručnik za rad na računalu Autor Kolisničenko Denis Nikolajevič

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

Iz knjige Objektno orijentirana analiza i dizajn s primjerima primjene u C++ od Butcha Gradyja

14.9. Dijagrami Možda je vrijeme da suhe brojeve pretvorimo u grafike, čineći našu tablicu ljepšom i informativnijom? Za to se koriste dijagrami. Što god rekli, dijagram se percipira bolje od tablice. Da biste konstruirali dijagram, trebate odabrati vrijednosti po kojima

Iz knjige Tehnologije programiranja autor Kamaev V A

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

Iz knjige Modeliranje poslovnih procesa s BPwinom 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 sustava. Drugim riječima, dijagram objekta je snimka tijeka događaja u nekoj konfiguraciji

Iz knjige OrCAD PSpice. Analiza električni krugovi od Keowna J.

5.7. Dijagrami procesa. Bitno: procesori, uređaji i veze Dijagrami procesa koriste se za prikaz distribucije procesa po procesorima u dizajnu fizičkog sustava. Poseban dijagram procesa prikazuje jedan pogled na strukturu procesa

Iz knjige VBA for Dummies autora Stevea Cummingsa

10.4. UML DIJAGRAMI 10.4.1. Vrste vizualnih dijagrama UMLUML vam omogućuje stvaranje nekoliko vrsta vizualnih dijagrama: dijagrame slučajeva uporabe; sekvencijski dijagrami; kooperativni dijagrami; dijagrami klasa; dijagrami stanja; dijagrami

Iz knjige Samoučni priručnik za rad na Macintoshu autorice Sofije Skriline

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

Iz autorove knjige

Vremenski dijagrami Za dobivanje vremenskih dijagrama ulaznog i izlaznog napona potrebno je malo modificirati ulaznu datoteku. Kao u prethodnom primjeru, koristit će se sinusoidalni ulazni napon: Vi 1 0 sin (0 0, 5 V 5 kHz) Uz analizu prijelaza

Iz autorove knjige

Grafikoni i grafikoni Samo stručnjak može razlučiti značenje iza beskrajnih nizova brojeva, ali svatko može razumjeti (ili barem tvrditi da razumije) histogram ili tortni grafikon. VBA nema ugrađene alate za izradu dijagrama, ali takav

Iz autorove knjige

5.1.14. Grafikoni Grafikoni su grafički prikazi numeričkih podataka u tablici. Pages nudi nekoliko vrsta grafikona: stupac, naslagani stupac, trakasti grafikon, naslagani trakasti grafikon, linija, područje, naslagano područje

Iz autorove knjige

5.2.8. Grafikoni Grafikon je grafički prikaz podataka iz odabranog raspona. Za izradu grafikona slijedite sljedeći algoritam1. Izradite tablicu izračunatih vrijednosti.2. Odaberite željeni raspon (može se sastojati od nesusjednih pravokutnika

Mislim da su svi čuli takvu izreku u djetinjstvu kao što je " Sedam puta mjeri jednom reži". Isto je u programiranju. Uvijek je bolje razmišljati o implementaciji prije nego što potrošite vrijeme na njezino izvođenje. Prilikom implementacije često morate kreirati klase i osmisliti njihovu interakciju. I često vizualni prikaz toga može pomoći riješite problem na najispravniji način.Tu mi pomažemo UML.

Što je UML?

Ako pogledate slike u tražilice, tada će postati jasno da UML– to je nešto o dijagramima, strelicama i kvadratima. Ono što je važno je da se UML prevodi kao Jedinstveni jezik za modeliranje. Ovdje je važna riječ Ujedinjeno. To jest, naše slike nećemo razumjeti samo mi, nego i drugi koji poznaju UML. Ispada da je ovo međunarodni jezik za crtanje dijagrama.

Kako Wikipedia kaže

UML je grafički opisni jezik za modeliranje objekata u razvoju softvera, modeliranje poslovnih procesa, dizajn sustava i prikaz organizacijskih struktura.

Najzanimljivija stvar o kojoj ne razmišljaju svi i ne shvaćaju je da UML ima specifikacije. Štoviš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. Također je zanimljivo da UML nije ograničen na opisivanje strukture klasa. Postoje mnoge vrste UML dijagrama. Kratak opis vrsta UML dijagrama može se vidjeti u istoj Wikipediji: UML - dijagrami ili u videu Timura Batyrshinova Pregled UML dijagrama. UML se također široko koristi za opisivanje raznih procesa, na primjer ovdje: Jedinstvena prijava pomoću JWT-a. Vraćajući se na korištenje UML dijagrama klasa, vrijedi spomenuti knjigu Head First: Design Patterns, u kojoj su uzorci ilustrirani tim istim UML dijagramima. Ispostavilo se da se UML doista koristi. I pokazalo se da je poznavanje i razumijevanje njegove primjene vrlo korisna vještina.

Primjena

Pogledajmo kako možete raditi s tim istim UML-om iz IDE-a. Uzmimo kao IDE IntelliJ ideja. Ako koristite IntelliJ Idea Ultimate, tada ćemo dodatak instalirati "iz kutije" Podrška za UML". Omogućuje vam automatsko generiranje prekrasnih dijagrama klasa. Na primjer, putem Ctrl+N ili stavke izbornika "Kretanje" -> "Razred" idemo do razreda ArrayList. Sada kroz kontekstni izbornik za naziv klase odaberite “Dijagram” -> “Prikaži skočni prozor dijagrama”. Kao rezultat, dobivamo prekrasan dijagram:

Ali što ako ga želite sami nacrtati, pa čak i ako ne želite Ultimativna verzija 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 instalirati Graphviz. Ovo je skup uslužnih programa za vizualizaciju grafikona. Koristi ga dodatak koji ćemo koristiti. Nakon instalacije trebate dodati imenik kanta za smeće iz instaliranog imenika Graphviz na varijablu okoline STAZA. Nakon toga, u IntelliJ Idea, odaberite File -> Settings iz izbornika. U prozoru "Postavke" odaberite kategoriju "Dodaci", kliknite gumb "Pregledaj repozitorije" i instalirajte integracijski dodatak PlantUML. Zašto je ovaj tako dobar? PlantUML? Koristi jezik opisa grafikona koji se zove " točka"a to mu omogućuje da bude univerzalniji, jer... dati jezik Ne koristi se samo PlantUML. Štoviše, sve što radimo u nastavku može se raditi ne samo u IDE-u, već i u online usluga planttext.com. Nakon instaliranja dodatka PlantUML, moći ćemo kreirati UML dijagrame kroz “Datoteka” -> “Novo”. Kreirajmo dijagram tipa "UML klasa". Tijekom ovog procesa automatski se generira predložak s primjerom. Izbrišite njegov sadržaj i stvorimo vlastiti, oboružani člankom s 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 tablica koja pokazuje kako treba opisati veze:

Ovdje također možemo pogledati same veze: "Odnosi između klasa u UML-u. Primjeri." Na temelju ovih materijala, počnimo stvarati naš UML dijagram. Dodajmo sljedeći sadržaj koji opisuje dvije klase: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Da biste vidjeli rezultat u Idea, odaberite "View" -> " Alat Windows" -> "PlantUML". Jednostavno ćemo dobiti dva kvadrata koji označavaju klase. Kao što znamo, obje ove klase implementiraju sučelje List. Ovaj odnos klase naziva se implementacija. Da biste prikazali takav odnos, upotrijebite strelicu s točkasta linija. Oslikajmo to: sučelje List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о paket privatno niz elemenata: ~ Object elementData Sada želimo pokazati da ArrayList sadrži neke objekte. U ovom slučaju, vrsta veze će biti - agregacija(agregacija). Agregat u ovom slučaju je ArrayList, jer sadrži druge predmete. Odabrali smo agregaciju jer objekti na listi mogu živjeti bez liste: oni nisu njen sastavni dio. Njihov životni vijek nije vezan za životni vijek liste. Agregat se s latinskog prevodi kao "sastavljen", to jest nešto što se sastoji od nečega. Na primjer, u životu postoji pumpna jedinica koja se sastoji od pumpe i motora. Sama jedinica se može rastaviti, ostavljajući dio nje komponente. Na primjer, prodati ili staviti u drugu jedinicu. Takav je i popis. I to se izražava u obliku praznog dijamanta u blizini jedinice i kontinuirane linije. Oslikajmo to na sljedeći način: class Object ( ) ArrayList o- Object Sada želimo pokazati da, za razliku od ArrayList, LinkedList klasa sadrži Node - spremnike koji se odnose na pohranjene podatke. U ovom slučaju, čvorovi su dio samog LinkedList-a i ne mogu živjeti odvojeno. Node ne pohranjuje izravno sadržaj, već samo sadrži poveznicu na 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 naziva se sastav(Sastav). 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 ovo sada u obliku tekstualnog prikaza veze: class Node ( ) LinkedList * -- Node A sada moramo naučiti kako prikazati drugi važna vrsta komunikacije - ovisnost(odnos ovisnosti). Koristi se kada jedna klasa koristi drugu, a klasa ne sadrži klasu koja se koristi i nije njezin potomak. Na primjer, LinkedList i ArrayList mogu stvoriti ListIterator. Prikažimo ovo kao strelice s točkastom linijom: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Možete ići u onoliko detalja koliko je potrebno. Ovdje su navedene sve oznake: "PlantUML - dijagram klasa". Osim toga, nema ničeg nadnaravnog u crtanju takvog dijagrama, 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, umjesto nakon što ste proveli dan implementirajući pogrešan model. Mislim da je to dobar razlog da pokušate?)

Automatizacija

Jesti razne načine automatsko generiranje PlantUML dijagrama. Na primjer, u Ideja Postoji SketchIT dodatak, ali ih ne crta sasvim ispravno. Na primjer, implementacija sučelja je netočno nacrtana (prikazuje se kao nasljeđe). Na internetu postoje i primjeri kako to ugraditi životni ciklus izgradnja vašeg projekta. Recimo za Maven postoji primjer korištenja uml-java-docklet. Da pokažemo kako se to radi, koristit ćemo Maven Archetype brzo stvaranje Maven projekt. Pokrenimo naredbu: mvn archetype:generate Na pitanje odabira filtera ( Odaberite broj ili primijenite filtar) ostavite zadano jednostavnim pritiskom na Enter. Uvijek će biti" maven-archetype-quickstart". Odaberite najnoviju verziju. Zatim odgovorite na pitanja i dovršite izradu projekta:

Budući da Maven nije fokus ovog članka, odgovori na vaša pitanja o Mavenu mogu se pronaći u korisničkom centru za Maven. U generiranom projektu otvorite datoteku opisa projekta za uređivanje, pom.xml. Kopirajmo sadržaj iz opisa instalacije uml-java-dockleta u njega. Artefakt korišten u opisu nije se mogao pronaći u Maven Central repozitoriju. Ali uspjelo mi je 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 instalirajte verziju" 1.0.0 ". Nakon ovoga 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 već ispravno prikazana ovdje)

Zaključak

Kao što vidite, UML vam omogućuje vizualizaciju strukture vaše aplikacije. Štoviše, UML nije ograničen samo na ovo. Pomoću UML-a možete opisati različite procese unutar svoje tvrtke ili opisati poslovni proces unutar kojeg funkcionira funkcija koju pišete. Koliko je UML koristan za vas osobno ovisi o vama, no odvojite vrijeme da ga detaljnije pročitate bit će korisno u svakom slučaju. #Viacheslav Engleska verzija ovog posta: UML dijagram Java na CodeGymu

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

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

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

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

Zašto vam je potrebno nekoliko vrsta dijagrama

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

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

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

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

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

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

Također nije baš jasno, ali je bolje. Govoreći “ljudskim” jezikom, sustav se predstavlja kao skup jednostavnijih entiteta koji su relativno samodostatni. To se može usporediti s načinom na koji gradimo u procesu razvoja programa GUI od standardnih “kockica” - vizualnih komponenti, odnosno kako je sam programski tekst također podijeljen na module koji sadrže potprograme, objedinjene funkcionalnostima, te se mogu ponovno koristiti u narednim programima.

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

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

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

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

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

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

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

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

Vrste grafikona

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

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

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

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

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

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

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

Dijagram slučajeva uporabe

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

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

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

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

Riža. 2.1.

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

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

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

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

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

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

razvoj konceptualnog modela sustava za njegovu naknadnu detaljizaciju;

priprema dokumentacije za interakciju s kupcima i korisnicima sustava.

11.1. Struktura jedinstvenog jezika za modeliranje

Jedinstveni jezik za modeliranje (UML) je trenutno de facto standard za opisivanje (dokumentiranje) rezultata dizajna i razvoja objektno orijentiranih sustava. Razvoj UML-a započeli su 1994. Grady Booch i James Rumbaugh, koji su radili za Rational Software. U jesen 1995. pridružio im se Ivar Jacobson, au listopadu iste godine objavljena je preliminarna verzija 0.8 Unificirane metode. Od tada je objavljeno nekoliko verzija UML specifikacije, od kojih dvije imaju status međunarodnog standarda:

UML 1.4.2 – "ISO/IEC 19501:2005. Informacijska tehnologija. Otvorena obrada distribucije. Unified Modeling Language (UML). Verzija 1.4.2" (engleski "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informacijska tehnologija. Grupa za upravljanje objektima Unified Modeling Language (OMG UML). Dio 1. Infrastruktura" (eng. "Information technology -- Object Management Group Unified Modeling Language (OMG) UML) - 1. dio: Infrastruktura") i "ISO/IEC 19505-2:2012. Informacijska tehnologija. Grupa za upravljanje objektima Unified Modeling Language (OMG UML). 2. dio. Nadgradnja" (eng. "Informacijska tehnologija -- Grupa za upravljanje objektima) Unificirani jezik za modeliranje (OMG UML) - 2. dio: Superstruktura").

Najnovija službena jezična specifikacija može se pronaći na www.omg.org.

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

Riža. 11.1. UML struktura

11.2. UML semantika i sintaksa

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

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

Dakle, u odnosu na UML, semantika i sintaksa određuju stil prezentacije (izgradnja modela), koji kombinira prirodne i formalne jezike za predstavljanje osnovnih pojmova (elemenata modela) i mehanizama za njihovo proširenje.

11.3. UML notacija

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

UML definira tri vrsta entiteta :

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

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

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

Sljedeća tablica pokazuje Kratki opis glavne entitete koji se koriste u grafičkom zapisu i glavne načine njihova prikazivanja.

Tablica 11.1. Entiteti

Tip	Ime	Oznaka	Definicija (semantika)
Strukturalni	(razred)		Mnogi predmeti koji imaju opća struktura i ponašanje
	(objekt)		Apstrakcija stvarnog ili zamišljenog entiteta s jasno definiranim pojmovnim granicama, osobnošću, stanjem i ponašanjem. Sa stajališta UML-a, objekti su instance klase (instance entiteta)
	(glumac)	Inženjer usluge staze	Entitet izvan sustava koji je u interakciji sa sustavom i koristi ga funkcionalnost za postizanje određenih ciljeva ili rješavanje određenih problema. Dakle, glumac je vanjski izvor ili primatelja informacija
	(slučaj upotrebe)		Opis radnji koje izvodi sustav, što dovodi do značajnog rezultata za aktera
	(država)		Opis trenutka u životu entiteta kada zadovoljava neki uvjet, obavlja neku aktivnost ili čeka da se dogodi neki događaj.
	Suradnja (suradnja)		Opis skupa instanci aktera, objekata i njihove interakcije u procesu rješavanja određenog problema
	(komponenta)		Fizički dio sustava (datoteka), uključujući sistemske module koji omogućuju implementaciju dosljednog skupa sučelja
	(sučelje)	iIzračun	Skup operacija koji definira uslugu (skup usluga) koju pruža klasa ili komponenta
	(čvor)		Fizički dio sustava (računalo, pisač, itd.) koji osigurava resurse za rješavanje problema
Grupiranje	(paket)		Opći mehanizam za grupiranje elemenata. Za razliku od komponente, paket je čisto konceptualni (apstraktni) koncept. Posebni slučajevi paketa su sustav i model
	(fragment)		Područje specifične interakcije između instanci glumca i objekata
	(podjela aktivnosti)		Grupa operacija (područje odgovornosti) koje izvodi jedan entitet (akter, objekt, komponenta, čvor, itd.)
	(područje prekidne aktivnosti)		Skupina operacija čiji se normalni slijed izvođenja može prekinuti kao rezultat pojave neuobičajene situacije
Objašnjavajući	Bilješka (komentar)		Komentar za element. Priključuje se na komentirani element isprekidanom linijom

Neki izvori, posebice [,], također identificiraju entitete ponašanja interakcije I konačnih automata, ali s logičke točke gledišta treba ih klasificirati kao dijagrame.

Neki od gore navedenih entiteta prema njima impliciraju Detaljan opis na dijagramima dekompozicije. Na dijagramu najviše razine oni su označeni posebnom ikonom ili oznakom.

Sljedeća tablica daje opis svih vrsta odnosa UML koji se koristi u dijagramima za označavanje odnosa između entiteta.

Tablica 11.3. Odnos

Ime	Oznaka	Definicija (semantika)
Udruga		Opisivanje odnosa smislena veza između dva ili više entiteta. Najviše opći oblik odnos
Agregacija		Podvrsta asocijacije koja opisuje odnos "dio"-"cjelina", u kojem "dio" može postojati odvojeno od "cjeline". Romb je označen s "cijele" strane. Odnos se navodi samo između entiteta istog tipa
Sastav		Podvrsta agregacije u kojoj "dijelovi" ne mogu postojati odvojeno od "cjeline". U pravilu, "dijelovi" se stvaraju i uništavaju istovremeno s "cjelinom"
Ovisnost		Odnos između dva entiteta u kojem promjena u jednom entitetu (nezavisnom) može utjecati na stanje ili ponašanje drugog entiteta (ovisnom). Strana sa strelicom označava neovisni entitet
Generalizacija		Odnos između generaliziranog entiteta (predak, roditelj) i specijaliziranog entiteta (potomak, kći). Trokut je označen s roditeljske strane. Odnos se navodi samo između entiteta istog tipa
Ostvarenje		Odnos između entiteta gdje jedan entitet specificira radnju koju drugi entitet obvezuje izvršiti. Odnosi se koriste u dva slučaja: između sučelja i klasa (ili komponenti), između slučajeva korištenja i suradnje. Strana sa strelicom označava entitet koji definira radnju (sučelje ili slučaj upotrebe)

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

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

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 navedena, tada se pretpostavlja da je njezina vrijednost 1. Za višestrukost instanci entiteta koje sudjeluju u ovisnosti, generalizaciji i implementaciji uvijek se pretpostavlja da je 1.

Sljedeća tablica daje opis mehanizmi za proširenje , koristi se za razjašnjavanje semantike entiteta i odnosa. Općenito, mehanizam proširenja je niz teksta unutar zagrada ili navodnika.

Tablica 11.4. Mehanizmi proširenja

Ime	Oznaka	Definicija (semantika)
Stereotip (stereotip)	« »	Oznaka koja specificira semantiku elementa notacije (na primjer: ovisnost sa stereotipom "uključi" smatra se relacijom uključivanja, a klasa sa stereotipom "granica" je klasa granice)
Stanje straže (stanje čuvara)		Booleov 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))

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


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

Riža. 11.2. Primjeri standardnog i stereotipnog prikaza razreda

Dijagram predstavlja grupiranje notnih elemenata za prikaz nekog aspekta razvijenog informacijski sistem. Dijagrami su obično povezani grafovi u kojima su entiteti vrhovi, a odnosi lukovi. Sljedeća tablica daje kratak opis UML dijagrami.

Tablica 11.5. Dijagrami

Dijagram			Svrha
				prema stupnju fizičke implementacije	prikazivanjem dinamike	prema prikazanom aspektu
(slučaj upotrebe)			Prikazuje funkcije sustava, interakcije između aktera i funkcija	Logično	Statički	Funkcionalan
(razred)			Prikazuje skup klasa, sučelja i odnosa između njih	Logično ili fizički	Statički	Funkcionalno i informativno
(paket)			Prikazuje skup paketa i odnose između njih	Logično ili fizički	Statički	komponenta
ponašanja (ponašanje)	(državni stroj)		Prikazuje stanja entiteta i prijelaze između njih tijekom životnog ciklusa	Logično	Dinamičan	Bihevioralni
	(aktivnost)		Prikazuje poslovne procese u sustavu (opis algoritama ponašanja)
	Interakcije (interakcija)	(slijed)	Prikazuje redoslijed prijenosa poruka između objekata i aktera
		(komunikacija)	Slično dijagramu sekvenci, ali je naglasak na strukturi interakcija između objekata
Implementacije (implementacija)	(komponenta)		Prikazuje komponente sustava (programe, biblioteke, tablice itd.) i veze između njih	Fizički	Statički	komponenta
	(uvođenje)		Prikazuje položaj komponenti na mrežnim čvorovima, kao i njezinu konfiguraciju

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

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

Vremenski dijagram - opisuje stanje objekta tijekom vremena;

Dijagram složene strukture - opisuje priključke (uključujući sučelja) klase za interakciju s drugim klasama;

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

Dijagram pregleda interakcije - sličan, ali sa skrivenim fragmentima interakcije (fragmenti označeni referencom). Predstavlja kontekstualni (konceptualni) čiji će elementi biti navedeni na zasebnim dekompozicijskim dijagramima.

U svrhu proširenog konceptualnog prikaza unutarnje arhitekture sustava, većina konstrukcija dopušta korištenje ustaljenih grafičkih stereotipa za tzv. Takav se dijagram naziva 1, ali ne pripada listi dijagrama definiranoj UML standardom.

Prilikom razvoja zasebnog modela sustava gradi se nekoliko vrsta dijagrama. Štoviše, pri razvoju modela složenog sustava, u pravilu se konstruira nekoliko dijagrama iste vrste. U isto vrijeme, ne morate stvarati zasebne vrste grafikona ako to nije potrebno. Na primjer, dijagrami i su međusobno zamjenjivi; izgrađeni su samo za objekte sa složenim ponašanjem. Sljedeća tablica daje preporuke o potrebi razvoja (pojašnjenja) dijagrama za modele sustava.

Tablica 11.6. Odnos između modela i dijagrama

Donja tablica ne prikazuje model testiranja, budući da se u sklopu njegove konstrukcije dijagrami ne razvijaju, već se provjerava (testira) cjelovitost i dosljednost.

Neki od dijagrama nakon njihove konstrukcije zahtijevaju razvoj i pojašnjenje u sklopu razvoja sljedećeg modela ( tehnološki proces). Tako bi se, primjerice, trebali razjasniti tijekom razvoja. U modelima.

4. Definirajte pojam " ".