Orodja za risanje UML diagramov. Modeliranje v UML. Splošni diagrami Primer diagramov v jeziku uml

UML je enoten jezik za grafično modeliranje za opisovanje, vizualizacijo, načrtovanje in dokumentiranje OO sistemov. UML je zasnovan tako, da podpira proces modeliranja programske opreme, ki temelji na pristopu OO, organizira odnos konceptualnih in programskih konceptov ter odraža probleme skaliranja kompleksnih sistemov. Modeli UML se uporabljajo v vseh fazah življenjskega cikla programske opreme, od poslovne analize do vzdrževanja sistema. Različne organizacije lahko uporabljajo UML, kot se jim zdi primerno, odvisno od njihovih težav in tehnologij, ki jih uporabljajo.

Kratka zgodovina UML

Do sredine 90-ih so različni avtorji predlagali več deset metod modeliranja OO, od katerih je vsaka uporabljala svoj grafični zapis. Poleg tega je imela vsaka od teh metod svoje prednosti, vendar ni dovolil dovolj zgraditi polni model PS, pokaži ga "z vseh strani", torej vse potrebne projekcije (glej 1. člen). Poleg tega je pomanjkanje standarda za modeliranje OO razvijalcem otežilo izbiro najprimernejše metode, kar je preprečilo široko sprejetje pristopa OO k razvoju programske opreme.

Na zahtevo skupine za upravljanje objektov (OMG), organizacije, odgovorne za sprejemanje standardov na področju objektnih tehnologij in baz podatkov, so pereč problem poenotenja in standardizacije rešili avtorji treh najbolj priljubljenih metod OO - G. Butch, D. Rambo in A. Jacobson, ki so skupaj ustvarili različico UML 1.1, ki jo je OMG leta 1997 odobril kot standard.

UML je jezik

Vsak jezik je sestavljen iz besedišča in pravil za kombiniranje besed za ustvarjanje smiselnih konstrukcij. Zlasti tako so strukturirani programski jeziki, kot je UML. Njegova značilnost je, da je jezikovni slovar sestavljen iz grafičnih elementov. Vsak grafični simbol ima določeno semantiko, tako da lahko model, ki ga je ustvaril en razvijalec, drugi jasno razume in tudi programsko opremo, tolmačenje UML. Iz tega zlasti sledi, da je programski model, predstavljen v UML, mogoče samodejno prevesti v OO programski jezik (kot so Java, C++, VisualBasic), to je, če obstaja dobro orodje za vizualno modeliranje, ki podpira UML, ki ima zgradili model, bomo prejeli tudi vzorčno programsko kodo, ki ustreza temu modelu.

Poudariti je treba, da je UML jezik, ne metoda. Pojasnjuje, iz katerih elementov ustvariti modele in kako jih brati, ne pove pa ničesar o tem, katere modele je treba razviti in v kakšnih primerih. Za ustvarjanje metode, ki temelji na UML, jo je treba dopolniti z opisom procesa razvoja programske opreme. Primer takega procesa je Rational Unified Process, o katerem bomo razpravljali v naslednjih člankih.

Slovar UML

Model je predstavljen v obliki entitet in odnosov med njimi, ki so prikazani v diagramih.

Entitete so abstrakcije, ki so glavni elementi modelov. Obstajajo štiri vrste entitet – strukturne (razred, vmesnik, komponenta, primer uporabe, sodelovanje, vozlišče), vedenjske (interakcija, stanje), združevanje (paketi) in opombe (komentarji). Vsaka vrsta entitete ima svojo grafično predstavitev. O entitetah bomo podrobneje razpravljali pri preučevanju diagramov.

Razmerje prikazujejo različne povezave med entitetami. UML definira naslednje vrste odnosov:

Zasvojenost prikazuje takšno povezavo med dvema entitetama, ko lahko sprememba ene od njiju – neodvisne – vpliva na semantiko druge – odvisne. Odvisnost je predstavljena s pikčasto puščico, usmerjeno od odvisne entitete k neodvisni.
Združenje je strukturno razmerje, ki kaže, da so predmeti ene entitete povezani s predmeti druge. Grafično je povezava prikazana kot črta, ki povezuje povezane entitete. Asociacije služijo za krmarjenje med objekti. Na primer, povezavo med razredoma »Naročilo« in »Izdelek« lahko uporabite za iskanje vseh izdelkov, določenih v določenem naročilu - na eni strani ali za iskanje vseh naročil, ki imajo ta izdelek, - z drugim. Jasno je, da morajo ustrezni programi izvajati mehanizem, ki zagotavlja takšno navigacijo. Če je potrebna navigacija samo v eno smer, je to označeno s puščico na koncu povezave. Poseben primer združevanja je agregacija - odnos oblike "celota" - "del". Grafično je poudarjen z rombom na koncu blizu bistvene celote.
Posploševanje je razmerje med nadrejeno entiteto in podrejeno entiteto. V bistvu to razmerje odraža lastnost dedovanja za razrede in objekte. Posplošitev je prikazana kot črta, ki se konča s trikotnikom, usmerjenim proti nadrejeni entiteti. Otrok podeduje strukturo (atribute) in vedenje (metode) starša, hkrati pa ima lahko nove strukturne elemente in nove metode. UML omogoča večkratno dedovanje, kjer je entiteta povezana z več kot eno nadrejeno entiteto.
Izvedba– odnos med entiteto, ki definira specifikacijo vedenja (vmesnik), z entiteto, ki definira izvedbo tega vedenja (razred, komponenta). To razmerje se običajno uporablja pri modeliranju komponent in bo podrobneje opisano v naslednjih člankih.

Diagrami. UML nudi naslednje diagrame:

Diagrami, ki opisujejo obnašanje sistema:

Diagrami stanja
diagrami dejavnosti,
Diagrami objektov,
diagrami zaporedja,
Diagrami sodelovanja;

Diagrami, ki opisujejo fizično izvedbo sistema:

Diagrami komponent;
Diagrami razmestitve.

Nadzorni pogled modela. Paketi.

Povedali smo že, da je treba model, da bi ga ljudje dobro razumeli, organizirati hierarhično in pustiti majhno število entitet na vsaki ravni hierarhije. UML vključuje sredstva za organiziranje hierarhične predstavitve modela - pakete. Vsak model je sestavljen iz nabora paketov, ki lahko vsebujejo razrede, primere uporabe ter druge entitete in diagrame. Paket lahko vsebuje druge pakete, kar omogoča ustvarjanje hierarhij. UML ne zagotavlja ločenih diagramov paketov, vendar se lahko pojavijo v drugih diagramih. Paket je upodobljen kot pravokotnik z zaznamkom.

Kaj ponuja UML.

hierarhični opis kompleksnega sistema z identifikacijo paketov;
formalizacija funkcionalnih zahtev za sistem z uporabo aparata primerov uporabe;
podrobno določanje sistemskih zahtev z izdelavo diagramov dejavnosti in scenarijev;
prepoznavanje podatkovnih razredov in konstruiranje konceptualnega podatkovnega modela v obliki razrednih diagramov;
prepoznavanje razredov, ki opisujejo Uporabniški vmesnik in ustvarjanje navigacijske sheme zaslona;
opis procesov interakcije objektov pri izvajanju sistemskih funkcij;
opis obnašanja objekta v obliki diagramov aktivnosti in stanja;
opis komponent programske opreme in njihove interakcije prek vmesnikov;
opis fizične arhitekture sistema.

In zadnja stvar ...

Kljub vsej privlačnosti UML bi ga bilo težko uporabiti v resničnem modeliranju programske opreme brez orodij za vizualno modeliranje. Takšna orodja vam omogočajo hitro predstavitev diagramov na zaslonu, njihovo dokumentiranje, ustvarjanje predlog programske kode v različnih OO programskih jezikih in ustvarjanje shem baz podatkov. Večina med njimi vključuje možnost reinženiringa programskih kod – obnavljanje določenih projekcij programskega modela s samodejno analizo izvornih kod programov, kar je zelo pomembno za zagotavljanje skladnosti med modelom in kodami ter pri načrtovanju sistemov, ki podedujejo funkcionalnost predhodnih sistemov.

10.4. DIAGRAMI UML

10.4.1. Vrste vizualnih diagramov UML

UML vam omogoča ustvarjanje več vrst vizualnih diagramov:

Diagrami primerov uporabe;

Diagrami zaporedja;

Zadružni grafikoni;

diagrami razredov;

diagrami stanja;

Diagrami komponent;

Diagrami postavitve.

Diagrami ponazarjajo različne vidike sistema. Na primer, kooperativni diagram prikazuje, kako morajo objekti medsebojno delovati, da izvajajo nekatere funkcije sistema. Vsak diagram ima svoj namen.

10.4.2. Diagrami primerov uporabe

Diagrami primerov uporabe prikazujejo interakcije med primeri uporabe, ki predstavljajo funkcije sistema, in akterji, ki predstavljajo ljudi ali sisteme, ki prejemajo ali prenašajo informacije ta sistem. Primer diagrama primera uporabe za bankomat (bankomat) je prikazan na sliki. 10.1.

riž. 10.1. Diagram primerov uporabe

Diagram predstavlja interakcije med primeri uporabe in akterji. Odraža sistemske zahteve z vidika uporabnika. Tako so primeri uporabe funkcije, ki jih izvaja sistem, akterji pa so zainteresirane strani v zvezi s sistemom, ki se ustvarja. Diagrami prikazujejo, kateri akterji sprožijo primere uporabe. Prikazujejo tudi, kdaj igralec prejme informacije iz primera uporabe. V bistvu lahko diagram primera uporabe ponazori sistemske zahteve. V našem primeru stranka banke sproži različne primere uporabe: “Dvig denarja z računa”, “Prenos denarja”, “Polog denarja na račun”, “Prikaži stanje”, “Spremeni ID številko”, “Izvedi plačilo”. Bančni uslužbenec lahko sproži primer uporabe Spremeni identifikacijsko številko. Od primera uporabe »Izvedi plačilo« je puščica do kreditnega sistema. Igralci so lahko zunanji sistemi, v tem primeru je Kreditni sistem prikazan ravno kot akter - je zunaj sistema ATM. Puščica, ki kaže od primera uporabe do akterja, označuje, da primer uporabe akterju zagotavlja nekaj informacij. V tem primeru primer uporabe Izvedi plačilo zagotovi kreditnemu sistemu informacije o plačilu s kreditno kartico.

Diagrami primerov uporabe lahko zagotovijo kar nekaj informacij o sistemu. Ta vrsta diagrama opisuje celotno funkcionalnost sistema. Uporabniki, vodje projektov, analitiki, razvijalci, strokovnjaki za zagotavljanje kakovosti in vsi, ki jih zanima sistem kot celota, si lahko ogledajo diagrame primerov uporabe, da bi razumeli, kaj naj bi sistem počel.

10.4.3. Diagrami zaporedja

Diagrami zaporedja prikazujejo tok dogodkov, ki se zgodijo znotraj primera uporabe. Na primer, primer uporabe »Dvig denarja« ponuja več možnih zaporedij: dvig denarja, poskus dviga denarja, ko na računu ni dovolj denarja, poskus dviga denarja z uporabo napačne identifikacijske številke in nekateri drugi. Običajni scenarij za dvig 20 USD z računa (če ni težav, kot je napačna identifikacijska številka ali nezadostna sredstva na računu) je prikazan na sliki. 10.2.

Slika 10.2. Diagram zaporedja za Joejevo stranko, ki dviguje 20 $ z njegovega računa

Na vrhu diagrama so prikazani vsi akterji in objekti, ki jih sistem zahteva za izvedbo primera uporabe Dvig denarja. Puščice ustrezajo sporočilom, posredovanim med igralcem in objektom ali med objekti za izvajanje zahtevanih funkcij. Upoštevati je treba tudi, da diagram zaporedja prikazuje objekte, ne razredov. Razredi so vrste predmetov. Objekti so betonski; namesto razreda Stranka Diagram zaporedja predstavlja določeno stranko, Joe.

Primer uporabe se začne, ko stranka vstavi svojo kartico v čitalnik – ta predmet je prikazan v pravokotniku na vrhu diagrama. Prebere številko kartice, odpre objekt Joe Account in inicializira zaslon bankomata. Zaslon vpraša Joeja za njegovo registrsko številko. Stranka vnese številko 1234. Zaslon preveri številko glede na objekt Joe Account in ugotovi, da je pravilna. Na zaslonu se nato prikaže Joe z menijem, med katerim lahko izbira, in on izbere »Dvigni denar«. Zaslon vpraša, koliko želi dvigniti, in Joe vnese 20 $. Zaslon dviguje denar z računa. Pri tem sproži vrsto procesov, ki jih izvaja objekt "Joejev račun". Hkrati se preverja, da je na tem računu po vsaj, 20 $ in zahtevani znesek se odšteje od računa. Blagajni se nato naroči, naj "izda ček in 20 $ v gotovini." Končno isti objekt "Joejev račun" naroči bralniku kartic, naj kartico vrne.

Torej, ta diagram zaporedje ponazarja zaporedje dejanj, ki izvajajo primer uporabe »Dvig denarja z računa« z uporabo specifičnega primera Joejeve stranke, ki je dvignila 20 $. Ob pogledu na ta diagram se uporabniki seznanijo s posebnostmi svojega dela. Analitiki vidijo zaporedje (potek) dejanj, razvijalci vidijo objekte, ki jih je treba ustvariti, in njihove operacije. Strokovnjaki za nadzor kakovosti bodo razumeli podrobnosti postopka in lahko razvijejo teste za njihovo preverjanje. Tako so diagrami zaporedja uporabni za vse, ki sodelujejo pri projektu.

10.4.4. Kooperativni diagrami

Kooperativni diagrami odražajo iste informacije kot diagrami zaporedja. Vendar to počnejo drugače in z drugimi cilji. Prikazano na sl. 10.2 diagram zaporedja je prikazan na sl. 10.3 v obliki kooperativnega diagrama.

Kot prej so predmeti prikazani kot pravokotniki, znaki pa kot figure. Medtem ko diagram zaporedja prikazuje interakcijo med akterji in predmeti skozi čas, kooperativni diagram ne kaže nobenega odnosa skozi čas. Tako lahko vidite, da bralnik kartic ukaže, naj se odpre »Joejev račun«, »Joejev račun« pa povzroči, da naprava vrne kartico lastniku. Objekti, ki so v neposredni interakciji, so povezani s črtami. Če na primer čitalnik kartic komunicira neposredno z zaslonom bankomata, je treba med njima potegniti črto. Odsotnost črte pomeni, da ni neposredne komunikacije med predmeti.

riž. 10.3. Kooperativni diagram, ki opisuje postopek dviga denarja z računa

Kooperativni diagram torej prikazuje iste informacije kot diagram zaporedja, vendar je potreben za drugačen namen. Strokovnjaki za zagotavljanje kakovosti in sistemski arhitekti bodo lahko razumeli porazdelitev procesov med objekti. Recimo, da nekakšen kooperativni diagram spominja na zvezdo, kjer je več objektov povezanih z enim osrednjim objektom. Arhitekt sistema lahko sklepa, da je sistem preveč odvisen od osrednjega subjekta in ga je treba preoblikovati za bolj enakomerno porazdelitev procesov. V diagramu zaporedja bi bilo to vrsto interakcije težko videti.

10.4.5. Diagrami razredov

Diagrami razredov odražajo interakcije med razredi v sistemu. Na primer, "Joejev račun" je predmet. Vrsta takega predmeta se lahko šteje za račun na splošno, tj. »Račun« je razred. Razredi vsebujejo podatke in vedenje (dejanja), ki vplivajo na te podatke. Tako razred Account vsebuje identifikacijsko številko stranke in dejanja, ki jo preverjajo. V diagramu razredov je razred ustvarjen za vsako vrsto predmeta iz diagramov zaporedja ali diagramov sodelovanja. Diagram razredov za primer uporabe Dvig denarja je prikazan na sliki. 10.4.

Diagram prikazuje razmerja med razredi, ki izvajajo primer uporabe Dvig denarja. V ta proces so vključeni štirje razredi: čitalnik kartic, račun, zaslon bankomata in avtomat za gotovino. Vsak razred v razrednem diagramu je prikazan kot pravokotnik, razdeljen na tri dele. Prvi del označuje ime razreda, drugi - njegovo lastnosti. Atribut je neka informacija, ki označuje razred. Na primer, razred račun ima tri atribute: številko računa, PIN in stanje. Zadnji del vsebuje operacije razreda, ki odražajo njegovo obnašanje(dejanja, ki jih izvaja razred). Črte, ki povezujejo razrede, prikazujejo interakcije med razredi.

riž. 10.4. Razredni diagram

Razvijalci uporabljajo diagrame razredov za dejansko ustvarjanje razredov. Orodja, kot je Rose, ustvarijo jedro razredne kode, ki jo programerji izpolnijo s podrobnostmi v jeziku po lastni izbiri. Z uporabo teh diagramov lahko analitiki prikažejo podrobnosti sistema, arhitekti pa lahko razumejo njegovo zasnovo. Če na primer razred nosi preveliko funkcionalno obremenitev, bo to vidno v razrednem diagramu in arhitekt ga lahko prerazporedi med druge razrede. Diagram lahko tudi pomaga prepoznati primere, ko med komunikacijskimi razredi ni definiranih nobenih odnosov. Diagrame razredov je treba ustvariti tako, da prikažejo medsebojno delujoče razrede v vsakem primeru uporabe. Ustvarite lahko tudi bolj splošne diagrame, ki pokrivajo vse sisteme ali podsisteme.

10.4.6. Diagrami stanja

Diagrami stanj so zasnovani za modeliranje različnih stanj, v katerih je lahko predmet. Medtem ko diagram razredov prikazuje statično sliko razredov in njihovih odnosov, se diagrami stanj uporabljajo za opis dinamike vedenja sistema.

Diagrami stanja prikazujejo obnašanje objekta. Tako ima lahko bančni račun več različnih stanj. Lahko je odprt, zaprt ali presežen. Obnašanje računa se spreminja glede na stanje, v katerem se nahaja. Diagram stanja prikazuje točno to informacijo. Na sl. Slika 10.5 prikazuje primer diagrama stanja za bančni račun.

riž. 10.5. Diagram stanja za razred računa

Ta diagram prikazuje možna stanja računa, kot tudi postopek prehoda računa iz enega stanja v drugo. Na primer, če stranka zahteva zaprtje odprtega računa, slednji preide v stanje "Zaprto". Kliče se zahteva naročnika dogodek, dogodki so tisti, ki povzročijo prehod iz enega stanja v drugo.

Ko stranka dvigne denar z odprtega računa, lahko račun preide v stanje prekoračitve. To se zgodi le, če je stanje na računu manjše od nič, kar se odraža v stanju [negativno stanje] v našem grafikonu. V oglatih oklepajih stanje določa, kdaj lahko pride do prehoda iz enega stanja v drugo ali ne.

V diagramu sta dve posebni stanji - začetnica in dokončno. Začetno stanje je označeno s črno piko: ustreza stanju predmeta v času njegovega nastanka. Končno stanje je označeno s črno piko v belem krogu: ustreza stanju predmeta neposredno pred njegovim uničenjem. V diagramu stanj je lahko eno in samo eno začetno stanje. Hkrati je lahko toliko končnih stanj, kot jih potrebujete, ali pa jih sploh ni.

Ko je objekt v določenem stanju, se lahko izvajajo določeni procesi. V našem primeru, če je kredit presežen, se stranki pošlje ustrezno sporočilo. Kličejo se procesi, ki se zgodijo, ko je objekt v določenem stanju dejanja.

Diagramov stanja ni treba ustvariti za vsak razred, uporabljajo se samo v zelo zapletenih primerih. Če lahko predmet razreda obstaja v več stanjih in se v vsakem stanju obnaša drugače, bo verjetno potreboval tak diagram. Vendar jih veliko projektov sploh ne uporablja. Če so bili zgrajeni diagrami stanj, jih lahko razvijalci uporabijo pri ustvarjanju razredov.

Grafi stanja so potrebni predvsem za dokumentacijo.

10.4.7. Diagrami komponent

Diagrami komponent prikazujejo, kako izgleda model fizični ravni. Prikazuje komponente programsko opremo vaš sistem in povezave med njimi. Obstajata dve vrsti komponent: izvršljive komponente in knjižnice kod.

Na sl. Slika 10.6 prikazuje enega od diagramov komponent za sistem ATM. Ta diagram prikazuje komponente odjemalca sistema ATM. V tem primeru se je razvojna ekipa odločila za izgradnjo sistema z uporabo jezika C++. Vsak razred ima svojo datoteko glave in razširitveno datoteko. CPP, tako da se vsak razred pretvori v svoje komponente v diagramu. Pokliče se izbrana temna komponenta specifikacija paketa in ustreza telesni datoteki razreda ATM v C++ (datoteka s pripono .CPP). Neizbrana komponenta se imenuje tudi specifikacija paketa, vendar ustreza datoteki glave razreda jezika C++ (datoteka s pripono .H). komponenta bankomata. EXE je specifikacija naloge in predstavlja tok obdelave informacij. V tem primeru je procesna nit izvršljiv program.

Komponente so povezane s črtkano črto, ki predstavlja odvisnosti med njimi. Sistem ima lahko več komponentnih diagramov, odvisno od števila podsistemov oz izvršljive datoteke. Vsak podsistem je paket komponent.

Diagrame komponent uporabljajo tisti udeleženci projekta, ki so odgovorni za sestavljanje sistema. Diagram komponent daje predstavo o vrstnem redu, v katerem naj bodo komponente prevedene, pa tudi o tem, katere izvedljive komponente bo sistem ustvaril. Diagram prikazuje preslikavo razredov v implementirane komponente. Torej je potreben tam, kjer se začne ustvarjanje kode.

riž. 10.6. Diagram komponent

10.4.8. Diagrami postavitve

Diagrami postavitve prikazujejo fizično lokacijo različnih komponent sistema v omrežju. V našem primeru je sistem ATM sestavljen iz velikega števila podsistemov, ki se izvajajo na ločenih fizičnih napravah ali vozliščih. Diagram postavitve za sistem ATM je prikazan na sl. 10.7.

Iz tega diagrama lahko spoznate fizično postavitev sistema. Odjemalski programi bankomatov se bodo izvajali na več lokacijah na več mestih. Stranke bodo z regionalnim ATM strežnikom komunicirale prek zaprtih omrežij. Zagnal bo strežniško programsko opremo ATM. V zameno, skozi lokalno omrežje regionalni strežnik bo sodeloval s strežnikom bančne baze podatkov, ki izvaja Oracle. Nazadnje je tiskalnik povezan z regionalnim strežnikom ATM.

Ta diagram torej prikazuje fizično postavitev sistema. Na primer, naš sistem bankomatov sledi trinivojski arhitekturi, z bazo podatkov na prvem nivoju, regionalnim strežnikom na drugem in odjemalcem na tretjem.

10.7. Diagram postavitve

Diagram postavitve uporabljajo vodja projekta, uporabniki, sistemski arhitekt in operativno osebje za razjasnitev fizične postavitve sistema in lokacije njegovih posameznih podsistemov. Vodja projekta bo uporabnikom razložil, kako bo videti končni izdelek. Operativno osebje bo lahko načrtovalo namestitev sistema.

Iz knjige Microsoft Office avtor Leontjev Vitalij Petrovič

Grafi Številke v tabeli vam ne omogočajo vedno popolnega vtisa, tudi če so razvrščene na najprimernejši način za vas. Z uporabo tistih, ki so na voljo pri Microsoftu Excelove predloge diagramov, lahko dobite jasno sliko podatkov v tabeli in ne

Iz knjige Računalnik za 100. Začnimo s Windows Vista avtor Zozulya Yuri

Grafikoni Grafikoni se uporabljajo za prikaz tabelarnih podatkov grafični obliki, ki lahko bistveno izboljšajo preglednost informacij, prikažejo razmerje med različnimi parametri ali dinamiko njihovega spreminjanja. Za vstavljanje diagramov v Word uporabite orodja

Iz knjige Učinkovito pisarniško delo avtor Ptašinski Vladimir Sergejevič

Diagrami Najbolj vizualni Zmogljivost Excela je predstavitev rezultatov izračuna ali zbranih podatkov v obliki grafov (diagramov): včasih najbolj impresivne številke ne morejo prepričati tako, kot je to mogoče storiti s celo preprosto grafiko. Excel ima

Iz Excelovega delovnega zvezka. Multimedijski tečaj avtor Medinov Oleg

Poglavje 8 Diagrami pogosto program Excel uporablja se za izdelavo dokumentov, ki predstavljajo različna statistična in analitična poročila. To so lahko poročila o prodaji, tabele meritev temperature zraka, podatki socioloških raziskav ipd. Številke niso vedno

Iz knjige Word 2007. Priljubljena vadnica avtor Krainsky I

Gradnja grafikona Za prvi primer boste morali ustvariti tabelo, prikazano na sl. 8.1. riž. 8.1. Tabela merjenja temperature Na podlagi podatkov v tej tabeli bomo sestavili preprost graf temperaturnih sprememb.1. V tabeli izberite izpolnjen obseg.2. Pojdi do

Iz knjige Samostojni priročnik za delo na računalniku avtor Kolisničenko Denis Nikolajevič

6.6. Razen diagramov grafične datoteke, V Wordovi dokumenti lahko vstavite diagrame. Z uporabo diagramov lahko vizualno predstavite numerične podatke, na primer spremljate, kako se podatki spreminjajo, vidite razvoj določenega projekta skozi čas. Diagrami so podobni

Iz knjige Objektno usmerjena analiza in načrtovanje s primeri aplikacij v C++ avtorja Butch Grady

14.9. Diagrami Morda je čas, da suhoparne številke spremenimo v grafiko, da bo naša tabela lepša in informativnejša? Za to se uporabljajo diagrami. Karkoli rečete, diagram je bolje zaznati kot tabelo. Če želite sestaviti diagram, morate izbrati vrednosti, po katerih

Iz knjige Tehnologije programiranja avtor Kamaev V A

5.2. Diagrami razredov Essential: razredi in njihova razmerja Diagram razredov prikazuje razrede in njihova razmerja ter tako predstavlja logični vidik zasnove. Ločen diagram razreda predstavlja poseben pogled na strukturo razreda. V fazi analize smo

Iz knjige Modeliranje poslovnih procesov z BPwin 4.0 avtor Maklakov Sergej Vladimirovič

5.4. Objektni diagrami Essential: Objekti in njihova razmerja Objektni diagram prikazuje obstoječe objekte in njihove odnose v logični zasnovi sistema. Z drugimi besedami, objektni diagram je posnetek toka dogodkov v neki konfiguraciji

Iz knjige OrCAD PSpice. Analiza električna vezja avtor Keown J.

5.7. Procesni diagrami. Bistveno: procesorji, naprave in povezave Diagrami procesov se uporabljajo za prikaz porazdelitve procesov po procesorjih v fizični zasnovi sistema. Ločen diagram procesa prikazuje en pogled na strukturo procesa

Iz knjige VBA za telebane avtorja Steve Cummings

10.4. DIAGRAMI UML 10.4.1. Vrste vizualnih diagramov UMLUML vam omogoča ustvarjanje več vrst vizualnih diagramov: diagrami primerov uporabe; diagrami zaporedja; kooperativni diagrami; razredni diagrami; diagrami stanja; diagrami

Iz knjige Samostojni priročnik za delo na Macintosh avtorica Sofia Skrylina

1.2.6. Okvir diagrama Na sl. Slika 1.2.26 prikazuje tipičen primer dekompozicijskega diagrama z omejevalnimi okvirji, imenovanimi okvir diagrama. riž. 1.2.26. Primer dekompozicijskega diagrama z žično strukturo. Žična konstrukcija vsebuje naslov ( zgornji del okvirji) in klet (spodnji del).

Iz avtorjeve knjige

Časovni diagrami Za pridobitev časovnih diagramov vhodne in izhodne napetosti je potrebno nekoliko spremeniti vhodno datoteko. Kot v prejšnjem primeru bo uporabljena sinusna vhodna napetost: Vi 1 0 sin (0 0,5 V 5 kHz) Skupaj z analizo prehodnosti

Iz avtorjeve knjige

Grafi in grafi Samo strokovnjak lahko razbere pomen za neskončnimi vrstami številk, vendar lahko kdorkoli razume (ali vsaj trdi, da razume) histogram ali tortni grafikon. VBA nima vgrajenih orodij za ustvarjanje diagramov, ampak takih

Iz avtorjeve knjige

5.1.14. Grafi Grafi so grafični prikazi numeričnih podatkov v tabeli. Pages ponuja več vrst grafikonov: stolpec, naloženi stolpec, palični grafikon, naložen palični grafikon, črtni, območni, naloženi območni

Iz avtorjeve knjige

5.2.8. Grafikoni Grafikon je grafična predstavitev podatkov iz izbranega obsega. Za izdelavo grafikona sledite naslednjemu algoritmu1. Izdelajte tabelo izračunanih vrednosti.2. Izberite želeni obseg (lahko je sestavljen iz nesosednjih pravokotnikov

Mislim, da so vsi v otroštvu slišali tak rek, kot je " Sedemkrat meri enkrat reži". Enako je pri programiranju. Vedno je bolje razmisliti o implementaciji, preden porabite čas za njeno izvajanje. Pri implementaciji morate pogosto ustvariti razrede in se domisliti njihove interakcije. Pogosto lahko vizualna predstavitev tega pomaga rešiti težavo na najbolj pravilen način.Tukaj pomagamo UML.

Kaj je UML?

Če pogledate slike v Iskalniki, potem bo postalo jasno, da UML– je nekaj o diagramih, puščicah in kvadratih. Pomembno je, da se UML prevede kot Poenoten jezik za modeliranje. Tu je pomembna beseda Poenoten. To pomeni, da naše slike ne bomo razumeli samo mi, ampak tudi drugi, ki poznajo UML. Izkazalo se je, da je to mednarodni jezik za risanje diagramov.

Kot pravi Wikipedia

UML je grafični opisni jezik za objektno modeliranje pri razvoju programske opreme, modeliranju poslovnih procesov, načrtovanju sistemov in prikazovanju organizacijskih struktur.

Najbolj zanimiva stvar, o kateri vsi ne razmišljajo ali se je zavedajo, je, da ima UML specifikacije. Poleg tega obstaja celo specifikacija UML2. Več podrobnosti o specifikaciji lahko najdete na spletni strani Object Management Group. Pravzaprav ta skupina razvija specifikacije UML. Zanimivo je tudi, da UML ni omejen na opisovanje strukture razredov. Obstaja veliko vrst diagramov UML. Kratek opis vrst diagramov UML si lahko ogledate v isti Wikipediji: UML - diagrami ali v videu Timurja Batyrshinova Pregled diagramov UML. UML se pogosto uporablja tudi za opis različnih procesov, na primer tukaj: Enotna prijava z uporabo JWT. Če se vrnemo k uporabi diagramov razredov UML, velja omeniti knjigo Head First: Design Patterns, v kateri so vzorci ponazorjeni s temi istimi diagrami UML. Izkazalo se je, da se UML dejansko uporablja. In izkazalo se je, da je poznavanje in razumevanje njegove uporabe precej koristna veščina.

Aplikacija

Poglejmo, kako lahko delate s tem istim UML iz IDE. Vzemimo kot IDE Ideja IntelliJ. Če uporabljate IntelliJ Idea Ultimate, nato bomo vtičnik namestili »izven škatle« Podpora za UML". Omogoča vam samodejno ustvarjanje čudovitih diagramov razredov. Na primer, prek Ctrl+N ali menijske postavke "Navigacija" -> "Razred" gremo v razred ArrayList. Zdaj v kontekstnem meniju za ime razreda izberite »Diagram« -> »Prikaži pojavno okno diagrama«. Kot rezultat dobimo čudovit diagram:

A kaj, ko ga želite narisati sami, pa tudi če nočete Končna različica Ideja? Če uporabljamo IntelliJ Idea Community Edition, potem nimamo druge izbire. Če želite to narediti, morate razumeti, kako je strukturiran tak diagram UML. Najprej bomo morali namestiti Graphviz. To je nabor pripomočkov za vizualizacijo grafov. Uporablja ga vtičnik, ki ga bomo uporabili. Po namestitvi morate dodati imenik koš iz nameščenega imenika Graphviz na spremenljivko okolja POT. Nato v programu IntelliJ Idea v meniju izberite Datoteka -> Nastavitve. V oknu »Nastavitve« izberite kategorijo »Vtičniki«, kliknite gumb »Prebrskaj repozitorije« in namestite integracijski vtičnik PlantUML. Zakaj je ta tako dober? PlantUML? Uporablja opisni jezik grafa, imenovan " pika"in to mu omogoča, da je bolj univerzalen, ker... danem jeziku Ne uporablja se samo PlantUML. Poleg tega je vse, kar počnemo spodaj, mogoče narediti ne samo v IDE, ampak tudi v spletna storitev planttext.com. Po namestitvi vtičnika PlantUML bomo lahko ustvarili diagrame UML prek “Datoteka” -> “Novo”. Ustvarimo diagram tipa "UML class". Med tem postopkom se samodejno ustvari predloga s primerom. Izbrišimo njegovo vsebino in ustvarimo lastno, oboroženi s člankom iz Habra: Odnosi med razredi – od UML do kode. In da bi razumeli, kako to prikazati v besedilu, vzemimo priročnik PlantUML: diagram razreda plantuml. Na samem začetku je tabela, ki prikazuje, kako je treba opisati povezave:

Tukaj si lahko ogledamo tudi same povezave: "Razmere med razredi v UML. Primeri." Na podlagi teh materialov začnimo ustvarjati naš UML diagram. Dodajmo naslednjo vsebino, ki opisuje dva razreda: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Če si želite ogledati rezultat v Idea, izberite "View" -> " Orodje Windows" -> "PlantUML". Enostavno bomo dobili dva kvadrata, ki označujeta razrede. Kot vemo, oba razreda izvajata vmesnik List. To razmerje med razredi se imenuje implementacija. Za prikaz takega odnosa uporabite puščico z črtkana črta. Uparimo ga: vmesnik List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о paket zasebno niz elementov: ~ Object elementData Zdaj želimo pokazati, da seznam ArrayList vsebuje nekaj objektov. V tem primeru bo vrsta povezave - združevanje(združevanje). Agregat je v tem primeru ArrayList, ker vsebuje druge predmete. Združevanje izberemo zato, ker objekti na seznamu lahko živijo brez seznama: niso njegov sestavni del. Njihova življenjska doba ni vezana na življenjsko dobo seznama. Agregat je iz latinščine preveden kot "sestavljen", to je nekaj, kar je sestavljeno iz nečesa. Na primer, v življenju obstaja črpalna enota, ki je sestavljena iz črpalke in motorja. Samo enoto je mogoče razstaviti in nekaj pustiti komponente. Na primer za prodajo ali vgradnjo v drugo enoto. Tudi seznam. In to je izraženo v obliki praznega diamanta v bližini enote in neprekinjene črte. Predstavimo ga takole: class Object ( ) ArrayList o- Object Zdaj želimo pokazati, da za razliko od ArrayList razred LinkedList vsebuje Node – vsebnike, ki se nanašajo na shranjene podatke. V tem primeru so vozlišča del samega seznama LinkedList in ne morejo živeti ločeno. Node vsebine ne shranjuje neposredno, ampak vsebuje le povezavo do nje. Na primer, ko dodamo vrstico na LinkedList, dodamo novo vozlišče, ki vsebuje povezavo do te vrstice ter povezavo do prejšnjega in naslednjega vozlišča. Ta vrsta povezave se imenuje sestava(Sestava). Za prikaz kompozita (ki je sestavljen iz delov) je narisan barvni diamant, do katerega vodi neprekinjena črta. Zapišimo zdaj to v obliki besedilnega prikaza povezave: class Node ( ) LinkedList * -- Node In zdaj se moramo naučiti, kako prikazati drugo pomembna vrsta komunikacije - zasvojenost(odvisniško razmerje). Uporablja se, ko en razred uporablja drugega in razred ne vsebuje uporabljenega razreda in ni njegov potomec. Na primer, LinkedList in ArrayList lahko ustvarita ListIterator. Prikažimo to kot puščice s pikčasto črto: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Lahko greste v toliko podrobnosti, kot je potrebno. Vse oznake so navedene tukaj: "PlantUML - diagram razredov". Poleg tega v risanju takšnega diagrama ni nič nadnaravnega in ko delate na svojih nalogah, ga lahko hitro narišete ročno. To bo razvilo vaše sposobnosti razmišljanja skozi arhitekturo aplikacije in vam pomagalo prepoznati napake v strukturi razreda zgodaj, ne pa potem, ko ste dan preživeli z implementacijo napačnega modela. Mislim, da je to dober razlog, da poskusite?)

Avtomatizacija

Jejte različne načine samodejno ustvarjanje diagramov PlantUML. Na primer, v Ideja Obstaja vtičnik SketchIT, vendar jih ne nariše čisto pravilno. Izvedba vmesnikov je na primer napačno narisana (prikazana kot dedovanje). Na internetu so tudi primeri, kako to vgraditi življenski krog gradnjo vašega projekta. Recimo za Maven obstaja primer uporabe uml-java-docklet. Da bi pokazali, kako se to naredi, bomo uporabili Maven Archetype hitro ustvarjanje Projekt Maven. Zaženimo ukaz: mvn archetype:generate Na vprašanje izbire filtra ( Izberite številko ali uporabite filter) pustite privzeto tako, da preprosto pritisnete Enter. Vedno bo" maven-archetype-quickstart". Izberite najnovejšo različico. Nato odgovorite na vprašanja in dokončajte ustvarjanje projekta:

Ker Maven ni osredotočen na ta članek, lahko odgovore na svoja vprašanja o Maven najdete v uporabniškem središču Maven. V ustvarjenem projektu odprite datoteko z opisom projekta za urejanje, pom.xml. Prepišimo vsebino iz opisa namestitve uml-java-docklet vanj. Artefakta, uporabljenega v opisu, ni bilo mogoče najti v repozitoriju Maven Central. Vendar mi je uspelo s tem: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. To pomeni, da morate samo zamenjati v tem opisu groupId z " info.leadinglight" na " com.chfourie"in namestite različico" 1.0.0 ". Po tem lahko izvedemo v imeniku, kjer se nahaja datoteka pom.xml ta ukaza: mvn čista namestitev in mvn javadoc:javadoc. Zdaj, če odpremo ustvarjeno dokumentacijo (explorer target\site\apidocs\index.html), bomo videli diagrame UML. Mimogrede, izvedba je tukaj že pravilno prikazana)

Zaključek

Kot lahko vidite, vam UML omogoča vizualizacijo strukture vaše aplikacije. Poleg tega UML ni omejen samo na to. Z uporabo UML lahko opišete različne procese v vašem podjetju ali opišete poslovni proces, znotraj katerega deluje funkcija, ki jo pišete. Kako uporaben je UML za vas osebno, se odločite sami, a če si vzamete čas in ga podrobneje preberete, bo v vsakem primeru koristno. #Viacheslav Angleška različica te objave: UML diagram Java na CodeGym

Opomba: Predmet tega tečaja je UML – poenoten jezik za modeliranje. Prejšnje predavanje je govorilo o tem, kaj je UML, njegovi zgodovini, namenu, načinih uporabe jezika, strukturi njegove definicije, terminologiji in notaciji. Ugotovljeno je bilo, da je model UML niz diagramov. V tem predavanju bomo obravnavali naslednja vprašanja: zakaj je potrebnih več vrst diagramov; vrste diagramov; OOP in zaporedje diagramov

Preden preidemo na razpravo o glavnem gradivu tega predavanja, se pogovorimo o tem, zakaj sploh moramo graditi kakršne koli diagrame. Razvoj modela katerega koli sistema (ne samo programske opreme) je vedno pred njegovo izdelavo ali posodobitvijo. To je potrebno vsaj zato, da si jasneje predstavljamo problem, ki ga rešujemo. Dobro premišljeni modeli so zelo pomembni tako za interakcijo znotraj razvojne ekipe kot za medsebojno razumevanje s stranko. Navsezadnje to zagotavlja, da je zasnova "arhitekturno dosledna", preden se implementira v kodo.

Gradimo modele kompleksnih sistemov, ker jih ne moremo v celoti opisati, »poglejte si jih«. Zato izpostavljamo samo tiste lastnosti sistema, ki so bistvene za določeno nalogo, in gradimo njegov model, ki te lastnosti prikazuje. Metoda objektno orientirane analize nam omogoča, da na najbolj primeren način opišemo realne kompleksne sisteme. Ker pa kompleksnost sistemov narašča, se pojavi potreba po dobri tehnologiji modeliranja. Kot smo že povedali v prejšnjem predavanju, enoten jezik modeliranja(Unified Modeling Language, UML), ki je grafični jezik za specifikacijo, vizualizacijo, načrtovanje in dokumentiranje sistemov. Z uporabo UML lahko razvijete podroben model ustvarjenega sistema, ki odraža ne le njegov koncept, temveč tudi posebne značilnosti njegove izvedbe. Znotraj modela UML so vse ideje o sistemu zapisane v obliki posebnih grafičnih struktur, imenovanih diagrami.

Opomba. Ne bomo upoštevali vseh, ampak le nekatere vrste diagramov. Na primer, diagram komponent ni zajet v tem predavanju, kar je le kratek pregled vrste diagramov. Število vrst grafikonov za določen model aplikacije niso na noben način omejene. Za enostavne aplikacije ni potrebe po izdelavi diagramov vseh vrst brez izjeme. Nekateri od njih morda preprosto manjkajo in to dejstvo ne bo obravnavano kot napaka. Pomembno je razumeti, da je razpoložljivost določenih vrst diagramov odvisna od posebnosti posameznega projekta. Informacije o drugih vrstah diagramov (ki jih tukaj ne obravnavamo) lahko najdete v standardu UML.

Zakaj potrebujete več vrst diagramov

Najprej opredelimo terminologijo. V uvodu tega predavanja smo večkrat uporabili pojme sistem, model in diagram. Avtor je prepričan, da vsak od nas intuitivno razume pomen teh pojmov, a da bo popolnoma jasno, poglejmo še enkrat v glosar in preberimo naslednje:

Sistem- niz med seboj povezanih nadzorovanih podsistemov, ki jih združuje skupni namen delovanja.

Da, ne preveč informativno. Kaj je potem podsistem? Da bi razjasnili situacijo, se obrnemo na klasike:

Sistem se nanaša na niz podsistemov, organiziranih za dosego določenega cilja in opisanih z uporabo niza modelov, po možnosti z različnih zornih kotov.

No, nič ne moreš, poiskati boš moral definicijo podsistema. Tam tudi piše, da podsistem je zbirka elementov, od katerih nekateri določajo vedenje drugih elementov. Ian Sommerville ta koncept razloži takole:

Podsistem je sistem, katerega delovanje ni odvisno od storitev drugih podsistemov. Programski sistem je strukturiran kot zbirka relativno neodvisnih podsistemov. Opredeljene so tudi interakcije med podsistemi.

Prav tako ni zelo jasno, vendar je bolje. Če govorimo v »človeškem« jeziku, je sistem predstavljen kot niz enostavnejših entitet, ki so relativno samozadostne. To lahko primerjamo s tem, kako gradimo v procesu razvoja programa GUI iz standardnih “kock” - vizualnih komponent, oziroma kako je tudi samo programsko besedilo razdeljeno na module, ki vsebujejo podprograme, združene po funkcionalnosti, in jih je mogoče ponovno uporabiti v naslednjih programih.

Razumemo koncept sistema. Med postopkom načrtovanja se upošteva sistem z različnih zornih kotov s pomočjo modelov, katerih različni prikazi se pojavljajo v obliki diagramov. Spet se lahko bralec sprašuje o pomenu pojmov modeli in diagrami. Menimo, da je to lepa, a ne zelo jasna definicija modeli kot pomensko zaprta abstrakcija sistema Ni verjetno, da bi razjasnili situacijo, zato bomo poskušali razložiti "s svojimi besedami."

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

Naj navedemo nekaj primerov. Vsi nam znani plastični avtomobilčki, s katerimi smo se tako navdušeno igrali v otroštvu, niso nič drugega kot material umetni dekorativni model pravega avtomobila. Seveda tak "avto" nima motorja, rezervoarja mu ne napolnimo z bencinom in menjalnik ne deluje (pravzaprav ga sploh ni), a kot model ta igračka popolnoma izpolnjuje svoje funkcije : otroku daje predstavo o avtomobilu, saj prikazuje njegove značilne lastnosti, kot so prisotnost štirih koles, karoserija, vrata, okna, sposobnost vožnje itd.

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

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

Ostaja le še povedati, kaj je diagram. Diagram je grafični prikaz številnih elementov. Običajno prikazan kot graf z vozlišči (entitete) in robovi (relacije). Obstaja veliko primerov diagramov. To je blokovni diagram, ki ga vsi poznamo iz šolskih let, in namestitveni diagrami za različno opremo, ki jih lahko vidimo v uporabniških priročnikih, ter drevo datotek in imenikov na disku, ki si ga lahko ogledamo z izvajanjem Windows konzola drevesni ukaz in še veliko, veliko več. V vsakdanjem življenju nas diagrami obkrožajo z vseh strani, saj risbe zaznavamo lažje kot besedilo...

Toda vrnimo se k oblikovanju programske opreme (in še več). V tej industriji z Diagrame je mogoče uporabiti za vizualizacijo sistema z različnih perspektiv. Eden od diagramov lahko na primer opiše interakcijo uporabnika s sistemom, drugi lahko opiše spremembo stanj sistema med njegovim delovanjem, tretji lahko opiše interakcijo sistemskih elementov med seboj itd. Kompleksen sistem lahko in bi morali predstavljati kot niz majhnih in skoraj neodvisnih modelov - diagramov, pri čemer nobeden od njih ne zadostuje za opis sistema in pridobitev celotne slike o njem, saj se vsak od njih osredotoča na določen vidik delovanja sistema in izraža drugačen raven abstrakcije. Z drugimi besedami, vsak model ustreza določenemu, posebnemu pogledu na zasnovani sistem.

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

Vrste grafikonov

Definiran UML 1.5 dvanajst vrst grafikonov, razdeljeni v tri skupine:

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

Trenutna različica UML 2.1 ni naredila preveč sprememb. Diagrami so nekoliko spremenjeni po videzu (pojavili so se okvirji in druge vizualne izboljšave), zapis je bil nekoliko izboljšan, nekateri diagrami pa so dobili nova imena.

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

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

diagram primerov uporabe;
razredni diagram;
objektni diagram;
diagram zaporedja;
interakcijski diagram;
diagram stanja;
diagram dejavnosti;
diagram razmestitve.

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

Diagram primerov uporabe

Vsi (vključno s programsko opremo) sistemi so zasnovani ob upoštevanju dejstva, da jih bodo med delovanjem uporabljali ljudje in/ali sodelovali z drugimi sistemi. Entitete, s katerimi sistem med delovanjem komunicira, se imenujejo igralci, in vsak akter pričakuje, da se bo sistem obnašal na strogo določen, predvidljiv način. Poskusimo podati strožjo definicijo ektorja. Za to bomo uporabili čudovit vizualni slovar za UML Zicom mentor:

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

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

Pozoren bralec se lahko takoj vpraša: zakaj igralec in ne igralec? Strinjamo se, beseda "ektor" je nekoliko ostra za ušesa Rusov. Razlog, zakaj to rečemo, je preprost - ector izhaja iz besede ukrepanje, kar v prevodu pomeni ukrepanje. Dobesedni prevod besede "ector" je igralec- predolg in nepriročen za uporabo. Zato bomo še naprej govorili na ta način.

riž. 2.1.

Isti pozoren bralec je morda opazil besedo "precedens", ki utripa skozi ektorjevo definicijo. Kaj je to? To vprašanje nas bo še bolj zanimalo, če se spomnimo, o čem zdaj govorimo diagram primerov uporabe. Torej,

Primer uporabe- opis ločenega vidika obnašanja sistema z vidika uporabnika (Butch).

Definicija je precej jasna in celovita, vendar jo je mogoče z uporabo iste dodatno pojasniti Zicom mentor"om:

Primer uporabe- opis nabora zaporednih dogodkov (vključno z možnostmi), ki jih izvede sistem in vodijo do rezultata, ki ga opazuje akter. Primer uporabe predstavlja vedenje entitete, ki opisuje interakcijo med akterji in sistemom. Primer uporabe ne prikazuje, "kako" je določen rezultat dosežen, ampak samo "kaj" je doseženo.

Precedens je označen na zelo preprost način - v obliki elipse, znotraj katere je navedeno njegovo ime. Primeri uporabe in akterji so povezani s črtami. Pogosto je na enem koncu črte narisana figura. 2.3

oblikovanje splošnih zahtev za obnašanje načrtovanega sistema;

razvoj konceptualnega modela sistema za njegovo kasnejšo podrobnost;

priprava dokumentacije za interakcijo s strankami in uporabniki sistema.

11.1. Struktura poenotenega modelirnega jezika

Poenoten jezik za modeliranje (UML) je trenutno de facto standard za opisovanje (dokumentiranje) rezultatov načrtovanja in razvoja objektno orientiranih sistemov. Razvoj UML sta leta 1994 začela Grady Booch in James Rumbaugh, ki sta delala pri Rational Software. Jeseni 1995 se jim je pridružil Ivar Jacobson in oktobra istega leta je bila izdana preliminarna različica 0.8 Unified Method. Od takrat je bilo izdanih več različic specifikacije UML, od katerih imata dve status mednarodnega standarda:

UML 1.4.2 – "ISO/IEC 19501:2005. Informacijska tehnologija. Odprta distribucijska obdelava. Unified Modeling Language (UML). Različica 1.4.2" (angleško "Informacijska tehnologija. Odprta porazdeljena obdelava. Poenoteni modelni jezik (UML). Različica 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informacijska tehnologija. Skupina za upravljanje objektov Unified Modeling Language (OMG UML). 1. del. Infrastruktura" (eng. "Information technology -- Object Management Group Unified Modeling Language (OMG) UML) – 1. del: Infrastruktura«) in »ISO/IEC 19505-2:2012. Informacijska tehnologija. Skupina za upravljanje objektov Unified Modeling Language (OMG UML). 2. del. Nadgradnja« (angl. »Informacijska tehnologija -- Skupina za upravljanje objektov Poenoten jezik za modeliranje (OMG UML) – 2. del: Nadgradnja").

Najnovejšo uradno jezikovno specifikacijo lahko najdete na www.omg.org.

Splošna struktura UML je prikazana na naslednji sliki.

riž. 11.1. Struktura UML

11.2. Semantika in sintaksa UML

Semantika - veja jezikoslovja, ki preučuje pomen jezikovnih enot, predvsem njegovih besed in besednih zvez.

Sintaksa – načini združevanja besed in njihovih oblik v besedne zveze in povedi, združevanje povedi v zložene povedi, načini tvorjenja izjav kot dela besedila.

Tako v zvezi z UML semantika in sintaksa določata slog predstavitve (gradnja modela), ki združuje naravne in formalne jezike za predstavitev osnovnih konceptov (elementov modela) in mehanizmov za njihovo razširitev.

11.3. Zapis UML

Notacija je grafična interpretacija semantike za njeno vizualno predstavitev.

UML definira tri tip entitete :

Strukturna - abstrakcija, ki je odsev konceptualnega ali fizičnega predmeta;

Združevanje – element, ki se uporablja za neko semantično kombinacijo elementov diagrama;

Pojasnilo (anotativno) – komentar na element diagrama.

Naslednja tabela prikazuje Kratek opis glavne entitete, ki se uporabljajo v grafičnem zapisu, in glavni načini njihovega prikaza.

Tabela 11.1. Entitete

Vrsta	Ime	Imenovanje	Definicija (semantika)
Strukturni	(razred)		Veliko predmetov, ki imajo splošna struktura in vedenje
	(objekt)		Abstrakcija resnične ali namišljene entitete z jasno definiranimi pojmovnimi mejami, osebnostjo, stanjem in vedenjem. Z vidika UML so predmeti primerki razreda (primeri entitete)
	(igralec)	Inženir storitve poti	Entiteta, ki je zunaj sistema in je v interakciji s sistemom in ga uporablja funkcionalnost za doseganje določenih ciljev ali reševanje določenih problemov. Torej igralec je zunanji vir ali sprejemnik informacij
	(primer uporabe)		Opis dejanj, ki jih izvaja sistem in ki vodijo do pomembnega rezultata za akterja
	(država)		Opis trenutka v življenju entitete, ko izpolnjuje nek pogoj, izvaja neko dejavnost ali čaka, da se zgodi nek dogodek.
	Sodelovanje (sodelovanje)		Opis nabora primerkov akterjev, objektov in njihove interakcije v procesu reševanja določenega problema
	(komponenta)		Fizični del sistema (datoteka), vključno s sistemskimi moduli, ki zagotavljajo implementacijo konsistentnega niza vmesnikov
	(vmesnik)	iCalculation	Nabor operacij, ki definira storitev (nabor storitev), ki jih zagotavlja razred ali komponenta
	(vozlišče)		Fizični del sistema (računalnik, tiskalnik itd.), ki zagotavlja vire za rešitev težave
Združevanje v skupine	(paket)		Splošni mehanizem za združevanje elementov. Za razliko od komponente je paket čisto konceptualni (abstrakten) koncept. Posebna primera paketa sta sistem in model
	(Drobec)		Območje specifične interakcije med igralskimi instancami in predmeti
	(particija dejavnosti)		Skupina operacij (območje odgovornosti), ki jih izvaja en subjekt (akter, predmet, komponenta, vozlišče itd.)
	(območje prekinljive dejavnosti)		Skupina operacij, katerih normalno zaporedje izvajanja se lahko prekine zaradi pojava neobičajne situacije.
Razlagalni	Opomba (komentar)		Komentar za element. Pritrdi se na komentirani element s črtkano črto

Nekateri viri, zlasti [,], prav tako identificirajo vedenjske entitete interakcija in končni avtomati, vendar jih je z logičnega vidika treba klasificirati kot diagrame.

Nekatere od zgornjih entitet v skladu z njimi implicirajo natančen opis na dekompozicijskih diagramih. Na diagramu najvišje ravni so označeni s posebno ikono ali oznako.

Naslednja tabela vsebuje opise vseh vrst odnosov UML, ki se uporablja v diagramih za označevanje odnosov med entitetami.

Tabela 11.3. Razmerje

Ime	Imenovanje	Definicija (semantika)
Združenje		Opis odnosa smiselna povezava med dvema ali več entitetami. večina splošna oblika odnos
Združevanje		Podtip asociacije, ki opisuje razmerje »del«–»celota«, v katerem lahko »del« obstaja ločeno od »celote«. Romb je označen s "cele" strani. Razmerje je podano le med entitetami istega tipa
Sestava		Podvrsta združevanja, v kateri »deli« ne morejo obstajati ločeno od »celote«. Praviloma se "deli" ustvarjajo in uničujejo sočasno s "celoto"
Odvisnost		Razmerje med dvema entitetama, v katerem lahko sprememba ene entitete (neodvisne) vpliva na stanje ali vedenje druge entitete (odvisne). Stran s puščico označuje neodvisno entiteto
Posploševanje		Razmerje med posplošeno entiteto (prednik, starš) in specializirano entiteto (potomec, hči). Trikotnik je označen s strani starša. Razmerje je podano le med entitetami istega tipa
Realizacija		Razmerje med entitetami, kjer ena entiteta določa dejanje, ki se ga druga entiteta zaveže izvesti. Odnosi se uporabljajo v dveh primerih: med vmesniki in razredi (ali komponentami), med primeri uporabe in sodelovanjem. Puščična stran označuje entiteto, ki definira dejanje (vmesnik ali primer uporabe)

Za povezovanje je mogoče določiti združevanje in sestavo večkratnost (eng. multiplicity), ki označuje skupno število primerkov entitet, ki sodelujejo v razmerju. Običajno je navedeno na vsaki strani razmerja v bližini ustrezne entitete. Večkratnost je mogoče navesti na naslednje načine:

- * – poljubno število izvodov, vključno z nobenim;

Nenegativno celo število – večkratnost je strogo določena in enaka določenemu številu (na primer: 1, 2 ali 5);

Obseg nenegativnih celih števil "prvo število.. drugo število" (na primer: 1..5, 2..10 ali 0..5);

Razpon števil od določene začetne vrednosti do poljubne končne "prve številke.. *" (na primer: 1..*, 5..* ali 0..*);

Navajanje nenegativnih celih števil in obsegov, ločenih z vejicami (na primer: 1, 3..5, 10, 15..*).

Če množica ni podana, se predpostavlja, da je njena vrednost 1. Množica primerkov entitete, ki sodelujejo pri odvisnosti, posplošitvi in implementaciji, se vedno predpostavlja, da je 1.

Naslednja tabela vsebuje opis ekspanzijski mehanizmi , ki se uporablja za pojasnitev semantike entitet in odnosov. Na splošno je razširitveni mehanizem niz besedila v oklepajih ali narekovajih.

Tabela 11.4. Razširitveni mehanizmi

Ime	Imenovanje	Definicija (semantika)
Stereotip (stereotip)	« »	Oznaka, ki določa semantiko notacijskega elementa (na primer: odvisnost s stereotipom »vključi« se šteje za relacijo vključitve, razred s stereotipom »meja« pa je mejni razred)
Stanje straže (stanje varovalke)		Logični pogoj (na primer: ali [identifikacija dokončana])
Omejitev (omejitev)	{ }	Pravilo, ki omejuje semantiko elementa modela (na primer (čas izvajanja manj kot 10 ms))
Označena vrednost (označena vrednost)	{ }	Nova ali pojasnjevalna lastnost notnega elementa (na primer: (različica = 3.2))

Poleg stereotipov, označenih kot niz besedila v narekovajih, je mogoče v diagramih uporabiti grafične stereotipe. Naslednja slika prikazuje primere standardnega in stereotipnega prikaza.


a) standardna oznaka		b) standardna oznaka s stereotipom besedila		c) grafični stereotip

riž. 11.2. Primeri standardnega in stereotipnega prikaza razreda

Diagram predstavlja skupino notnih elementov za prikaz nekaterih vidikov razvitega informacijski sistem. Diagrami so običajno povezani graf, v katerem so entitete vozlišča, razmerja pa loki. Naslednja tabela podaja kratek opis UML diagrami.

Tabela 11.5. Diagrami

Diagram			Namen
				glede na stopnjo fizične izvedbe	s prikazovanjem dinamike	po prikazanem vidiku
(primer uporabe)			Prikazuje sistemske funkcije, interakcije med akterji in funkcijami	Logično	Statično	Delujoč
(razred)			Prikaže nabor razredov, vmesnikov in odnosov med njimi	Logično oz fizično	Statično	Funkcionalno in informativno
(paket)			Prikaže nabor paketov in odnosov med njimi	Logično oz fizično	Statično	Komponenta
vedenja (vedenje)	(državni stroj)		Prikaže stanja entitete in prehode med njimi med njenim življenjskim ciklom	Logično	Dinamično	Vedenjski
	(dejavnost)		Prikazuje poslovne procese v sistemu (opis algoritmov obnašanja)
	Interakcije (interakcija)	(zaporedje)	Prikaže zaporedje prenosa sporočil med objekti in akterji
		(komunikacija)	Podobno kot diagram zaporedja, vendar je poudarek na strukturi interakcij med objekti
Izvedbe (izvedba)	(komponenta)		Prikaže komponente sistema (programe, knjižnice, tabele itd.) in povezave med njimi	Fizično	Statično	Komponenta
	(razporeditev)		Prikaže postavitev komponent na omrežnih vozliščih in njihovo konfiguracijo

Standard UML 2.x definira tudi dodatne, zelo specializirane diagrame:

Objektni diagram - podobno, vendar so namesto razredov prikazani objekti;

Časovni diagram - opisuje stanje objekta skozi čas;

Diagram sestavljene strukture – opisuje vrata (vključno z vmesniki) razreda za interakcijo z drugimi razredi;

Diagram profila - podobno z opisom razredov, ki so vključeni v njih;

Diagram pregleda interakcije - podoben, vendar s skritimi fragmenti interakcije (fragmenti z oznako ref). Predstavlja kontekstualno (konceptualno), katere elementi bodo navedeni na ločenih dekompozicijskih diagramih.

Za povečano konceptualno predstavitev notranje arhitekture sistema večina konstrukcij omogoča uporabo ustaljenih grafičnih stereotipov za t.i. Takšen diagram se imenuje 1, vendar ne spada na seznam diagramov, ki jih določa standard UML.

Pri razvoju ločenega modela sistema se zgradi več vrst diagramov. Poleg tega je pri razvoju modela kompleksnega sistema praviloma izdelanih več diagramov iste vrste. Hkrati vam ni treba ustvarjati ločenih vrst grafikonov, če to ni potrebno. Na primer, diagrami in so zamenljivi; izdelani so samo za objekte s kompleksnim vedenjem. Naslednja tabela podaja priporočila glede potrebe po razvoju (razjasnitvi) diagramov za sistemske modele.

Tabela 11.6. Razmerje med modeli in diagrami

Spodnja tabela ne prikazuje modela testiranja, saj kot del njegove konstrukcije diagrami niso razviti, temveč preverjeni (testirani) glede popolnosti in doslednosti.

Nekateri diagrami po njihovi izdelavi zahtevajo razvoj in pojasnitev kot del razvoja naslednjega modela ( tehnološki proces). Tako jih je na primer treba razjasniti med razvojem. V modelih.

4. Opredelite pojem " ".