Diagram komponent in njihovih interakcij prek vmesnikov. Modeliranje v UML. Izvedbeni diagrami. Opis in glavne lastnosti

Ta razdelek je posvečen dvema diagramoma hkrati: komponentam in postavitvi, za katere lahko uporabite splošno ime ‒ izvedbeni diagrami. To je posledica dejstva, da postanejo ti diagrami še posebej pomembni v kasnejših fazah razvoja – v fazi implementacije in dobave. Medtem ko se v zgodnjih fazah razvoja - analiza in načrtovanje - ti diagrami sploh ne uporabljajo ali pa so videti zelo splošno, ne podrobno.

Z izvedbenega vidika je zasnovani sistem sestavljen iz komponent (predstavljenih v diagramih komponent), porazdeljenih po računalniških vozliščih (predstavljenih v diagramih postavitve).

V UML 2 je v primerjavi z UML 1 prišlo do bistvene spremembe, in sicer se je koncept »komponente« razdelil na dve komponenti: logično in fizično. Logična komponenta, ki še naprej nosi ime komponento(komponenta), je element logičnega modela sistema, fizična komponenta, t.i artefakt(artefakt), pooseblja fizični element oblikovanega sistema, ki se nahaja na računalniško vozlišče(vozlišče).

Diagrami komponent in postavitve imajo veliko skupnega, saj združujejo naslednje, tesno povezane stvari:

• struktura logičnih elementov (komponent);
• preslikava logičnih elementov (komponent) v fizične elemente (artefakte);
• struktura uporabljenih virov (vozlišča) s fizičnimi elementi (artefakti), porazdeljenimi po njih.

V tem razdelku bomo odstopali od pravila, ki smo ga sprejeli pri opisovanju preostalih diagramov. Ne bomo namreč za vsak diagram posebej obravnavali uporabljenih entitet. Bolj pravilno se nam zdi, da vse entitete in odnose obravnavamo skupaj v enem razdelku, kar bomo tudi storili.

3.4.1. Vmesnik

∇ Možnosti prevoda, ki jih najdemo v literaturi: "implemented", "provided".

∇∇ Možnost prevoda, ki jo najdete v literaturi, je "zahtevana"

Vendar ne smemo pozabiti, da je sam vmesnik preprosto opis pogodbe in postane zagotovljen ali potreben glede na to, kako se ta vmesnik uporablja:

• če klasifikator implementira vmesnik, potem za ta klasifikator je zavarovano vmesnik in to dejstvo je prikazano z uporabo izvedbene relacije 3;
• če klasifikator kliče operacije vmesnika, potem za ta klasifikator je potrebno vmesnik in to dejstvo je prikazano z uporabo razmerja odvisnosti 4.

Ko smo obravnavali vmesnike, preidimo na komponente.

3.4.2. Komponente, artefakti in sklopi

Komponenta(komponenta) je modularni fragment logične predstavitve sistema, interakcija s katerim je opisana z nizom predvidenih in zahtevanih vmesnikov.

Koncept "komponente" je pogosto povezan s programiranjem komponent ali sestavov, vendar za UML to dopisovanje ni legitimno. Komponenta UML je del modela in opisuje logično entiteto, ki obstaja samo v čas oblikovanja(čas načrtovanja), čeprav se lahko v prihodnosti poveže s fizično izvedbo (artefakt) čas izvedbe(čas delovanja).

Standard UML zagotavlja stereotipe za komponente, kot je prikazano v naslednji tabeli.

Tabela Stereotipi standardnih komponent

Analog komponente v smislu programiranja sestavljanja je koncept artefakta v UML. Pa ne kakršen koli artefakt, ampak le nekateri njegovi stereotipi.

Artefakt‒ je vsak umetno ustvarjen element programskega sistema.

Elementi programskega sistema in torej artefakti lahko vključujejo izvedljive datoteke, izvorno kodo programa, spletne strani, datoteke pomoči, podporne dokumente, podatkovne datoteke, modele in številne druge fizične elemente informacij. Z drugimi besedami, artefakti so tisti informacijski elementi, ki se tako ali drugače uporabljajo med delovanjem programskega sistema in so vključeni v njegovo sestavo.

Da bi nekako odražal takšno raznolikost tipov artefaktov, UML ponuja standardne stereotipe, navedene v tabeli

Tabela Standardni stereotipi artefaktov

Vendar pa so resnični artefakti v svojih vrstah veliko bolj raznoliki kot zgoraj našteti. Da bi to upoštevali, številna orodja poleg standardnih stereotipov podpirajo dodatne stereotipe artefaktov, pogosto s posebnimi ikonami in oblikami, zaradi katerih so diagrami zelo vidni.

Najpomembnejši vidik uporabe koncepta artefakta v UML je, da lahko artefakt sodeluje v razmerju manifestacije.

Manifestacija‒ to je odnos odvisnosti od »manifestnega« stereotipa, ki povezuje element modela (na primer razred ali komponento) in njegovo fizično izvedbo v obliki artefakta.

Spodaj je razred Podjetje, ki ima odnos manifestacije (odvisnost od stereotipa "manifest") z dvema artefaktoma s stereotipom "vir", ki definirata artefakt izvajalnega časa, dinamično knjižnico (s stereotipom "knjižnica") Podjetje .

Na splošno je manifestacijsko razmerje razmerje mnogo proti mnogo; en element modela je lahko implementiran s številnimi artefakti, en artefakt pa lahko sodeluje pri implementaciji številnih elementov modela.

Manifestacija je grafično prikazana z odnosom odvisnosti s stereotipom »manifest« od artefakta do realizirane entitete. Ker je manifestacija razmerje veliko proti mnogo, bodo morda potrebna več razmerij odvisnosti v modelu za popoln opis manifestacijskega razmerja.

Tretja entiteta, obravnavana v tem razdelku, je vozlišče.

∇ Pri uporabi UML na drugih predmetnih področjih je lahko vozlišče ne samo računalnik, ampak tudi drug predmet: oseba, mehanska naprava itd.

UML nudi dva stereotipa za vozlišča "executionEnvironment" in "device".

Vozlišče s stereotipom »executionEnvironment« vam omogoča modeliranje platforme strojne in programske opreme, na kateri se izvaja aplikacija. Primeri izvajalnih okolij so: operacijski sistem, sistem za upravljanje baz podatkov itd.

Vozlišče s stereotipom »naprava« prav tako modelira platformo strojne in programske opreme, vendar dopušča možnost ugnezdenja enega vozlišča znotraj drugega, kot je prikazano na naslednji sliki.

Artefakti sistema med njegovim delovanjem so postavljeni na vozlišča, kar je grafično izraženo bodisi z navedbo znotraj vozlišča 1 (glej sliko zgoraj) bodisi z odnosom odvisnosti s stereotipom »razporeditev« med artefaktom in vozliščem 1 (glej sliko spodaj). ) ali s prikazovanjem artefakta znotraj slik vozlišča 2 (glejte sliko spodaj). Vse možnosti zapisa so enakovredne.

Če imajo parametri, specifični za okolje, pomembno vlogo pri postavljanju artefakta na vozlišče, jih je mogoče določiti z specifikacije uvajanja(specifikacija uvajanja).

Specifikacija razmestitve je prikazana kot klasifikator (kot pravokotnik), vendar s stereotipom »deploymentSpec« in je povezana z razmerjem odvisnosti od artefakta.

Zadnja stvar, ki jo moramo upoštevati v tem razdelku, je odnos asociacije med vozlišči.

Če so vozlišča povezana z asociacijskim razmerjem, potem to pomeni isto kot v drugih kontekstih: možnost izmenjave sporočil. V zvezi z računalniškimi omrežji, sestavljenimi iz vozlišč, povezava pomeni prisotnost komunikacijskega kanala. Če morate podati dodatne informacije o lastnostih kanala, lahko to storite z običajnimi mehanizmi: stereotipi (na primer »tcp/ip«, glejte spodnjo sliko), omejitve in poimenovane vrednosti.

Tu bomo zaključili ta pregledni odstavek, da se bomo v naslednjem podrobneje seznanili s shemami komponent in postavitve na primeru informacijskega sistema za kadrovsko službo.

3.4.3. Uporaba diagramov komponent in postavitve

Poskusimo odgovoriti na vprašanje, katere vmesnike, komponente in artefakte lahko prepoznamo v kadrovskem informacijskem sistemu ter kako je priporočljivo razvito programsko opremo postaviti na računalniška vozlišča.

Glavni namen zasnovanega informacijskega sistema je shranjevanje kadrovskih podatkov in izvajanje določenih operacij s temi podatki po navodilih uporabnika. Če analiziramo sestavo operacij, vidimo, da se te nanašajo na ustvarjanje, spreminjanje in brisanje shranjenih podatkovnih elementov. Standardna rešitev v takšnih situacijah je uporaba že pripravljenega DBMS (DBMS - Data Base Management System). Z vidika načrtovanja informacijskega sistema za kadrovsko službo je priporočljivo obravnavati DBMS kot že pripravljeno komponento z vnaprej določenimi vmesniki in protokolom interakcije. Ni se nam treba osredotočati na strukturo te komponente - je standardna in verjetno precej dobro opisana zunaj našega modela.

DBMS bo prevzel vse funkcije neposredne manipulacije s podatki: ustvarjanje, brisanje in iskanje zapisov v tabelah itd. Izvajanje delovanja našega kadrovskega informacijskega sistema se spušča v določeno zaporedje elementarnih operacij s podatki. Na primer, premestitev zaposlenega z enega položaja na drugega bi verjetno zahtevala spremembe treh podatkovnih elementov: podatkov o zaposlenem ter starih in novih podatkov o delovnem mestu. Vendar, ali je priporočljivo upoštevati, da je definiranje in izvajanje samega zaporedja elementarnih operacij s podatki tudi v pristojnosti komponente, ki smo jo izbrali - DBMS? Običajna praksa na to vprašanje odgovarja nikalno. Iz več razlogov je bolje to ločiti v ločeno komponento, ki se običajno imenuje poslovna logika ∇. Poleg tega moramo domnevati, da mora naš sistem imeti komponento, odgovorno za uporabniški vmesnik. Kot prvi približek pridemo do spodnje strukture komponent, ki se imenuje »trinivojska arhitektura«.

∇ Izredno neposrečen, a pogosto uporabljen izraz, ki je preslikava angleške poslovne logike. Poslovna logika nima nobene zveze niti s poslom (v ruskem pomenu besede) niti z logiko. Bolj pravilno bi bilo uporabiti zapleteno besedno zvezo "pravila obdelave podatkov", vendar se bojimo, da bi nas napačno razumeli.

UML 2 je uvedel naslednje spremembe v notacijo diagrama komponent.

Prvič, komponente, tako kot vsak klasifikator, so lahko prikazane enotno, v obliki pravokotnikov, v katerih je označena stereotipna "komponenta" 1 ali eden od pojasnjevalnih stereotipov, navedenih v tabeli. Standardni komponentni stereotipi v odstavku 3.4.2 2 ali ustrezno ikono v zgornjem desnem kotu pravokotnika 3.

Drugič, zahtevane in ponujene vmesnike je mogoče predstaviti z zapisom lizike 4 (glejte razdelek 3.3.1), tako da je razmerje med komponentami prek nekega vmesnika videti naravno in simetrično.

To ponazarja spodnja slika, ki prikazuje iste entitete in razmerja kot na zgornji sliki.

Navedeni primer sestavnega diagrama je dokaj trivialen in z vidika uporabnosti v arhitekturnem načrtovanju ne deluje preveč prepričljivo. Ob spoznanju te pomanjkljivosti bomo podali še en primer, povezan s kadrovskim informacijskim sistemom, v katerem bomo poskušali pokazati, da so komponentni diagrami dokaj ekspresivno orodje za arhitekturno načrtovanje.

Predpostavimo, da je v predvidenem informacijskem sistemu kadrovske službe potrebno razlikovati pravice do opravljanja poslov in dostopa do podatkov za različne kategorije uporabnikov. Čeprav naše tehnične specifikacije o tem ne govorijo niti z besedo, je za sodobne sisteme ta zahteva postala običajna (včasih očitno nepotrebna), zato primer ni pretiran. Poznamo veliko načinov za izvajanje diferenciacije pravic dostopa do podatkov, verjetno pa je še več načinov, ki nam niso neznani. Ne bomo se spuščali v njihov opis in razpravo, ampak se bomo omejili na eno stvar - zelo preprosto, a učinkovito. Naša aplikacija ima dva akterja (glejte odstavek 2.2.1), tj. dve kategoriji uporabnikov. Predpostavimo, da je dovolj razlikovati pravice na ravni uporabniških kategorij. Potem lahko storite naslednje: preprosto naredite dve različni aplikaciji (ali, kot običajno rečejo v takih primerih, dve avtomatizirane delovne postaje- ARMA). Uporabniki, ki imajo dostop do delovne postaje kot celote, lahko izvajajo vse operacije na delovni postaji in imajo s tem tiste in samo tiste pravice dostopa do podatkov, ki jih zagotavljajo operacije, ki se izvajajo na delovni postaji.

Za aplikacijo, kot je kadrovski informacijski sistem, takšna rešitev praktično zadostuje. Tako se diferenciacija pravic dostopa do podatkov prenese na raven dostopa do računalnikov in na njih nameščenih aplikacij, to pa so že problemi operacijskih sistemov in varnostnih storitev podjetja, za katere v kadrovskem informacijskem sistemu ni mogoče poskrbeti.

Sprejeto odločitev je enostavno izraziti v diagramu komponent.

Vse, kar je treba storiti, je določiti sestavo komponent, tj. pokazati, kateri razredi so vključeni v katere komponente.

Najenostavnejši način za prikaz odnosa med komponento in njenimi članskimi razredi je uporaba implementacijske relacije 1, kot je prikazano spodaj.

Drug način za določitev sestave komponente je, da jo obravnavamo kot strukturiran klasifikator in uporabimo notranji strukturni diagram (glej odstavek 1.6.2 in odstavek 3.5.1).

Naslednji strukturni vidik, o katerem je treba razpravljati, je opis postavitve artefaktov glede na vključene računalniške vire.

Če govorimo o namizni aplikaciji, ki je v celoti shranjena in se izvaja na enem računalniku, potem ločen diagram postavitve ni potreben - dovolj je diagram komponent (in morda lahko brez njega). Pri modeliranju porazdeljenih aplikacij se pomen diagramov umestitve močno poveča: so opis topologije ∇ razporejen sistem.

∇ Programerji so si izposodili ime veje matematike (topologija) kot izraz. Na primer, pogosto lahko naletite na izraz "topologija lokalnega omrežja". Ne moremo reči, da je takšno izposojanje povsem nepravilno, hkrati pa ni povsem bistveno. Enostavno govorimo o opisovanju strukture povezav končne množice vozlišč, tj. o štetju.

Nadaljujmo obravnavo informacijskega sistema kadrovske službe s tega vidika. Predpostavimo, da smo sprejeli arhitekturo, prikazano zgoraj na sliki "Diagram komponent IC OK". Koliko računalnikov bo uporabljenih pri izvajanju te aplikacije? Na to vprašanje je treba odgovoriti tudi z vprašanjem, koliko uporabnikov bo imel sistem in koliko jih bo hkrati delalo z aplikacijo? Če je samo en uporabnik (ali, še huje, bo naš sistem nameščen "za ogled" in ne bo uporabljen), potem ni problema - namizna aplikacija - en računalnik in ni potreben noben diagram umestitve. Recimo, da mora imeti naš sistem veliko uporabnikov, ki lahko delujejo hkrati. Potem je odgovor očiten: vozlišč ne sme biti manj, kot je število sočasnih uporabnikov, saj je navadnim uporabnikom neprijetno delati skupaj na enem osebnem računalniku. Najverjetneje bi moralo biti eno vozlišče več kot uporabnikov, ker Večina organizacij ima posebej namenski računalnik (strežnik) za shranjevanje korporativnih podatkov. Tam bomo postavili našo bazo podatkov, v pričakovanju, da je zahtevani DBMS najverjetneje že nameščen na strežniku. Odprto ostaja vprašanje umeščanja artefaktov, ki implementirajo poslovno logiko. Tukaj so različne možnosti: na uporabnikovem računalniku, na vmesnem stroju (aplikacijskem strežniku), na strežniku baze podatkov podjetja. Če se odločimo za slednjo možnost (ki se v žargonu imenuje "arhitektura odjemalec/strežnik s tankim odjemalcem"), dobimo diagrame, prikazane na naslednjih dveh slikah.

Oba diagrama sta diagrama umestitve, vendar ima vsak svoje značilnosti. V prvem diagramu je poudarek na označevanju korespondence med komponentami in artefakti, izraženo v prisotnosti velikega števila odnosov odvisnosti od stereotipa "manifest" (glej na primer 1 v prvem diagramu). Drugi diagram prikazuje razmerja med artefakti ali z drugimi besedami določa, kateri artefakt je odvisen od tega, na primer zahteva podatke (za primer glejte 1 v drugem diagramu). Oba diagrama prikazujeta računalniška vozlišča in razmerja med njimi (2 v obeh diagramih). Upoštevajte, da se je na diagramu pojavil dodaten artefakt - Pomoč (na primer 3 v drugem diagramu). To je dokument, ki vsebuje osnovne informacije.

Na koncu tega razdelka bomo podali nekaj nasvetov o tem, kdaj uporabiti diagrame komponent in postavitve.

Začnimo z osnovnim premislekom, ki je bil že izražen: v primeru razvoja "monolitne" namizne aplikacije diagrami postavitve niso potrebni - izkažejo se za trivialne in ne vsebujejo nobenih uporabnih informacij. Zato se diagrami postavitve uporabljajo samo pri modeliranju večkomponentnih aplikacij.

Če je aplikacija dobavljena v obliki »konstruktorja« (niz »kock«), iz katerega se med namestitvijo sestavi določen unikaten primerek aplikacije, potem so diagrami umestitev preprosto nepogrešljivo orodje. Dejansko je veliko sodobnih aplikacij, zlasti razvitih sistemov za avtomatizacijo pisarniškega upravljanja v podjetjih, dobavljenih v obliki velikega (na desetine in stotine) nabora artefaktov, iz katerih se »na kraju samem« sestavi uporabniško potrebna, pogosto edinstvena konfiguracija. Nekateri organi priporočajo uporabo diagramov postavitve za upravljanje konfiguracije ne samo med fazo dostave in namestitve programske opreme, ampak tudi med razvojnim procesom: za sledenje različic komponent, možnosti gradnje itd.

Pri razvoju aplikacij, ki morajo komunicirati s t.i podedovana(podedovanih) aplikacij in podatkov je težko brez komponentnih diagramov. Dejstvo je, da so skoraj edino orodje UML, ki vam omogoča, da nekako opišete in vključite podedovane aplikacije in podatke v model, komponente (in njihovi vmesniki). To vključuje tudi primer modeliranja dostopa do podatkov iz »tujerodnega« DBMS.

Zadnji (na našem seznamu) primer uporabe diagramov umestitve je modeliranje sistemov z dinamično arhitekturo, to je sistemov, ki med izvajanjem spreminjajo sestavo in število primerkov svojih artefaktov. ∇. Številne spletne aplikacije na primer spremenijo svojo konfiguracijo med izvajanjem glede na trenutno obremenitev. Kadrovski informacijski sistem ni sistem dinamične arhitekture, zato primera ne navajamo.

∇ Ponovno upoštevajte, da se med izvajanjem ne ukvarjamo s samimi klasifikatorji, ampak z njihovimi primerki. Razdelek 3.5.4 je posvečen predstavitvi instanc klasifikatorja.

Danes si procesa ustvarjanja kompleksnih programskih aplikacij ni mogoče predstavljati brez razdelitve na stopnje življenjskega cikla. Z življenjskim ciklom programa razumemo niz stopenj:

• Analiza vsebine in izdelava tehničnih specifikacij (interakcija s stranko)
• Oblikovanje strukture programa
• Kodiranje (nabor programske kode po projektni dokumentaciji)
• Testiranje in odpravljanje napak
• Izvedba programa
• Programska podpora
• Odstranjevanje

Oglejmo si podrobneje postopek oblikovanja. Med postopkom načrtovanja arhitekt ali izkušen programer ustvari projektno dokumentacijo, vključno z besedilnimi opisi, diagrami in modeli bodočega programa. Pri tej težki nalogi nam bo pomagal jezik UML.

UML je grafični jezik za vizualizacijo, opis parametrov, načrtovanje in dokumentiranje različnih sistemov (predvsem programov). Diagrami so ustvarjeni s posebnimi orodji CASE, kot sta Rational Rose (http://www-01.ibm.com/software/rational/) in Enterprise Architect (http://www.sparxsystems.com.au/). Enoten informacijski model je zgrajen na osnovi tehnologije UML. Zgornja orodja CASE so sposobna generirati kodo v različnih objektno usmerjenih jezikih in imajo tudi zelo uporabno funkcijo obratnega inženiringa. (Vzvratno inženirstvo vam omogoča, da ustvarite grafični model iz obstoječe programske kode in komentarjev k njej.)

Poglejmo vrste diagramov za vizualizacijo modela (to je obvezno, čeprav obstaja veliko več vrst):

Diagram primerov uporabe

Načrtovani sistem je predstavljen kot niz entitet ali akterjev, ki komunicirajo s sistemom z uporabo tako imenovanih precedensov. V tem primeru je igralec ali igralec katera koli entiteta, ki je v interakciji s sistemom od zunaj. Z drugimi besedami, vsak primer uporabe definira določen nabor dejanj, ki jih izvaja sistem med dialogom z akterjem. Nič pa ni rečeno o tem, kako bo izvedena interakcija akterjev s sistemom.

razredni diagram

Diagram razredov služi za predstavitev statične strukture sistemskega modela v terminologiji razredov objektno orientiranega programiranja. Diagram razredov lahko odraža predvsem različne odnose med posameznimi domenskimi entitetami, kot so objekti in podsistemi, opisuje pa tudi njihovo notranjo strukturo (polja, metode ...) in vrste odnosov (dedovanje, implementacija vmesnikov ...). ). Ta diagram ne zagotavlja informacij o časovnih vidikih delovanja sistema. S tega vidika je razredni diagram nadaljnji razvoj konceptualnega modela zasnovanega sistema. Na tej stopnji je nujno poznavanje pristopa OOP in vzorcev oblikovanja.

diagram stanja

Glavni namen tega diagrama je opisati možna zaporedja stanj in prehodov, ki skupaj označujejo obnašanje elementa modela v njegovem življenjskem ciklu. Diagram stanja predstavlja dinamično vedenje entitet, ki temelji na specifikaciji njihovega odziva na zaznavanje nekaterih specifičnih dogodkov.

Diagram zaporedja

Za modeliranje interakcije objektov v jeziku UML se uporabljajo ustrezni interakcijski diagrami. Interakcije objektov si je mogoče ogledati v času, nato pa se uporabi diagram zaporedja za predstavitev časa prenosa in sprejema sporočil med objekti. Medsebojno delujoči objekti med seboj izmenjujejo nekatere informacije. V tem primeru so informacije v obliki izpolnjenih sporočil. Z drugimi besedami, čeprav ima sporočilo informativno vsebino, pridobi dodatno lastnost izvajanja usmerjenega vpliva na prejemnika.

Diagram sodelovanja

V diagramu sodelovanja so predmeti, ki sodelujejo v interakciji, prikazani v obliki pravokotnikov, ki vsebujejo ime predmeta, njegov razred in po možnosti vrednosti atributov. Tako kot diagram razredov so povezave med objekti označene v obliki različnih povezovalnih črt. V tem primeru lahko eksplicitno določite imena povezave in vloge, ki jih predmeti igrajo v tej povezavi.
Za razliko od diagrama zaporedja diagram sodelovanja prikazuje le odnose med objekti, ki igrajo določene vloge v interakciji.

Diagram komponent

Komponentni diagram za razliko od prej obravnavanih diagramov opisuje značilnosti fizične predstavitve sistema. Diagram komponent vam omogoča, da definirate arhitekturo sistema, ki se razvija, tako da vzpostavite odvisnosti med komponentami programske opreme, ki so lahko izvorna, binarna in izvršljiva koda. V mnogih razvojnih okoljih modul ali komponenta ustreza datoteki. Pikčaste puščice, ki povezujejo module, prikazujejo razmerja soodvisnosti, podobna tistim, ki se pojavijo pri prevajanju izvorne kode programa. Glavni grafični elementi diagrama komponent so komponente, vmesniki in odvisnosti med njimi.

Diagram razmestitve

Razmestitveni diagram je zasnovan za vizualizacijo elementov in komponent programa, ki obstajajo le v fazi izvajanja. V tem primeru so predstavljene samo komponente primerka programa, ki so izvršljive datoteke ali dinamične knjižnice. Tiste komponente, ki se med izvajanjem ne uporabljajo, niso prikazane v diagramu razmestitve.
Diagram razmestitve vsebuje grafične predstavitve procesorjev, naprav, procesov in povezav med njimi. Za razliko od diagramov logične predstavitve je diagram uvajanja enoten za sistem kot celoto, saj mora v celoti odražati značilnosti njegove izvedbe. Ta diagram v bistvu zaključi postopek OOAP za določen programski sistem in njegov razvoj je običajno zadnja stopnja specifikacije modela.

S tem smo zaključili naš pregled zlasti diagramov in oblikovanja na splošno. Omeniti velja, da je proces oblikovanja že dolgo postal standard za razvoj programske opreme, a pogosto se morate soočiti z vrhunsko napisanim programom, ki se zaradi pomanjkanja normalne dokumentacije prerašča z nepotrebnimi stranskimi funkcionalnostmi, berglami, postane okoren in izgubi svojo nekdanjo kakovost. =(

Prepričan sem, da je programer v prvi vrsti koder - NE sme komunicirati s stranko, NE sme razmišljati o arhitekturi sistema, ne sme izumljati vmesnika do programa, on mora samo kodirati - implementirati algoritme, funkcionalnost, videz, uporabnost, ampak nič več …. Oblikovalec mora od abstraktnih diagramov (ki opisujejo predmetno področje) do diagramov, ki predstavljajo strukturo podatkov, razrede in procese njihove interakcije, vse podrobno opisati korak za korakom. To pomeni, da bi morala biti kompleksnost dela in plača oblikovalca za red velikosti višja od tistega programerja == koderja. Oprostite za upor....

        Unified Modeling Language (UML) je jezik za specifikacijo, vizualizacijo, konstruiranje in dokumentiranje sistemov programske opreme ter poslovnih modelov in drugih sistemov, ki niso programska oprema. UML je kombinacija inženirskih tehnik, ki so bile prej uspešno uporabljene za modeliranje velikih in kompleksnih sistemov

        Ustvarjalci UML ga predstavljajo kot jezik za definiranje, predstavljanje, načrtovanje in dokumentiranje programskih sistemov, poslovnih sistemov in drugih sistemov različnih vrst. UML definira notacijo in metamodel. Notacija je zbirka grafičnih objektov, ki se uporabljajo v modelih; to je sintaksa modelnega jezika.

        UML ponuja izrazna orodja za ustvarjanje vizualnih modelov, ki:

• jih enotno razumejo vsi razvijalci, vključeni v projekt;
• so komunikacijsko sredstvo znotraj projekta.

        Unified Modeling Language (UML):

• ni odvisen od objektno usmerjenih (OO) programskih jezikov;
• ni odvisen od uporabljene metodologije razvoja projekta;
• lahko podpira kateri koli OO programski jezik.

        UML je odprt in ima orodja za razširitev osnovnega jedra. UML se lahko uporablja za smiseln opis razredov, objektov in komponent na različnih predmetnih področjih, ki so med seboj pogosto zelo različna.

Diagrami UML

        Rational Rose ponuja naslednje vrste diagramov, ki so na voljo oblikovalcu sistema, katerih zaporedno ustvarjanje vam omogoča, da dobite popolno sliko celotnega zasnovanega sistema in njegovih posameznih komponent:

• Diagram primerov uporabe;
• Diagram postavitve (topološki diagrami);
• diagram stanja;
• Diagram interakcije; Diagram dejavnosti;
• Diagram zaporedja;
• Diagram sodelovanja;
• Diagram razredov;
• Diagram komponent (diagrami komponent);
• vedenjski diagrami;
• Diagram dejavnosti;
• Izvedbeni diagrami;

        Vsak od teh diagramov podaja različne ideje o modelu sistema. Diagram primerov uporabe hkrati predstavlja konceptualni model sistema, ki je izhodišče za gradnjo vseh ostalih diagramov. Razredni diagram je logični model, ki odraža statične vidike strukturne zasnove sistema, vedenjski diagrami, ki so prav tako vrste logičnega modela, pa odražajo dinamične vidike njegovega delovanja. Izvedbeni diagrami služijo za predstavitev komponent sistema in se nanašajo na njegov fizični model.

        Od zgoraj naštetih diagramov nekateri služijo za označevanje dveh ali več podvrst. Naslednji diagrami se uporabljajo kot neodvisne predstavitve: primeri uporabe, razredi, stanja, dejavnosti, zaporedja, sodelovanje, komponente in uvajanje.

        Za diagrame UML obstajajo tri vrste vizualnih simbolov, ki so pomembni glede informacij, ki jih vsebujejo:

• komunikacije, ki so predstavljene z različnimi črtami na ravnini;
• besedilo, vsebovane v mejah posameznih geometrijskih oblik;
• grafični simboli, upodobljen v bližini vizualnih elementov diagramov.

        Pri grafičnem prikazovanju diagramov je priporočljivo upoštevati naslednja pravila:

• vsak diagram mora biti popolna predstavitev nekega fragmenta modeliranega predmetnega področja;
• modelne entitete, predstavljene na diagramu, morajo biti na isti konceptualni ravni;
• vse informacije o entitetah morajo biti jasno predstavljene na diagramu;
• diagrami ne smejo vsebovati nasprotujočih si informacij;
• diagrami ne smejo biti preobremenjeni z besedilnimi informacijami;
• vsak diagram mora biti samozadosten za pravilno interpretacijo vseh svojih elementov;
• število vrst diagramov, potrebnih za opis določenega sistema, ni strogo določeno in ga določi razvijalec;
• sistemski modeli naj vsebujejo le tiste elemente, ki so definirani v zapisu UML.

Entitete v UML

        V UML so definirane štiri vrste entitet: strukturno, vedenjsko, združevanje in označevanje. Entitete so glavni objektno usmerjeni elementi jezika, s katerim so ustvarjeni modeli.

        Strukturne enote so samostalniki v modelih UML. Običajno predstavljajo statične dele modela, ki ustrezajo konceptualnim ali fizičnim elementom sistema. Primeri strukturnih entitet so "razred", "vmesnik", "sodelovanje", "primer uporabe", "komponenta", "vozlišče", "akter".

        Vedenjske entitete so dinamične komponente modela UML. To so glagoli, ki opisujejo obnašanje modela v času in prostoru. Obstajata dve glavni vrsti vedenjskih entitet:

• interakcija je vedenje, katerega bistvo je izmenjava sporočil med objekti znotraj določenega konteksta za dosego določenega cilja;
• avtomat - vedenjski algoritem, ki definira zaporedje stanj, skozi katera gre predmet ali interakcija kot odziv na različne dogodke.

        Združevanje entitet so organizacijski deli modela UML. To so bloki, na katere je mogoče razstaviti model. Takšna primarna entiteta obstaja v eni sami kopiji - to je paket.

        Paketi so univerzalni mehanizem za organiziranje elementov v skupine. Strukturne, vedenjske in druge enote združevanja je mogoče postaviti v paket. Za razliko od komponent, ki dejansko obstajajo, medtem ko program teče, so paketi zgolj konceptualne narave, torej obstajajo le med procesom razvoja.

        Entitete pripisov- To so razlagalni deli modela UML: komentarji za dodaten opis, pojasnila ali pripombe k kateremu koli elementu modela. Obstaja le ena osnovna vrsta elementa opombe – opomba. Opombe se uporabljajo za zagotavljanje diagramov s komentarji ali omejitvami, izraženimi v neformalnem ali uradnem besedilu.

Odnosi v UML

        V jeziku UML so definirane naslednje vrste relacij: odvisnost, asociacija, posploševanje in izvajanje. Ti odnosi so glavni povezovalni konstrukti UML in se uporabljajo tudi kot entitete za gradnjo modelov.

        Odvisnost- to je pomensko razmerje med dvema entitetama, v katerem lahko sprememba ene od njiju, neodvisne, vpliva na semantiko druge, odvisne.

        Združenje- strukturno razmerje, ki opisuje nabor semantičnih ali logičnih povezav med predmeti.

        Posploševanje je razmerje, v katerem je mogoče specializirani elementni objekt (potomec) nadomestiti z generičnim elementnim objektom (prednik). Hkrati v skladu z načeli objektno usmerjenega programiranja potomec (otrok) podeduje strukturo in obnašanje svojega prednika (starša).

        Realizacija je pomensko razmerje med klasifikatorjema, v katerem en klasifikator opredeljuje obveznost, drugi pa zagotavlja njeno izpolnitev. Izvedbena razmerja se pojavijo v dveh primerih:

• med vmesniki in razredi ali komponentami, ki jih izvajajo;
• med precedensi in sodelovanjem, ki jih izvaja.

Pogosti mehanizmi UML

        Za natančen opis sistema v UML se uporabljajo tako imenovani splošni mehanizmi:

• specifikacije;
• dodatki (okraski);
• skupne delitve;
• razširitve (mehanizmi za razširitev).

        UML ni samo grafični jezik. Za vsakim grafičnim elementom je njegov zapis specifikacija, ki vsebuje besedilno predstavitev ustreznega jezikovnega konstrukta. Na primer, ikona za razred ima specifikacijo, ki opisuje njegove atribute, operacije in vedenje, čeprav vizualno, v diagramu, ikona pogosto odraža le majhen del teh informacij. Poleg tega lahko model vsebuje drugačno predstavitev tega razreda, ki odraža popolnoma druge vidike tega razreda, vendar je kljub temu skladna s specifikacijo. Tako se grafični zapis UML uporablja za vizualizacijo sistema in uporaba specifikacij za opis njegovih podrobnosti.

        Skoraj vsak element UML ima edinstveno grafično predstavitev, ki daje vizualno predstavitev njegovih najpomembnejših značilnosti. Zapis entitete "razred" vsebuje njeno ime, atribute in operacije. Specifikacija razreda lahko vsebuje druge podrobnosti, kot je vidnost atributov in operacij, komentarje ali navedbo, da je razred abstrakten. Veliko teh podrobnosti je mogoče vizualizirati kot grafiko ali besedilo. dodatki na standardni pravokotnik, ki predstavlja razred.

        Pri modeliranju objektno usmerjenih sistemov obstaja določena delitev zastopani subjekti.

        Prvič, obstaja delitev na razrede in objekte. Razred je abstrakcija, objekt pa je konkretna utelešenje te abstrakcije. V zvezi s tem je za skoraj vse jezikovne konstrukte značilna dvojnost razred/objekt. Tako obstajajo precedensi in primerki precedensov, komponente in primerki komponent, vozlišča in primerki vozlišč. V grafični predstavitvi je običajno uporabiti isti simbol za objekt kot za razred in podčrtati ime.

        Drugič, obstaja delitev na vmesnik in njegovo izvedbo. Vmesnik navaja zaveze, izvedba pa predstavlja konkretno izvedbo teh zavez in zagotavlja natančno upoštevanje deklarirane semantike. Zaradi tega je za skoraj vse konstrukte UML značilna dvojnost vmesnik/izvedba. Na primer, precedensi se izvajajo s sodelovanjem, operacije pa z metodami.

        UML je odprt jezik, kar pomeni, da omogoča nadzorovane razširitve, da odražajo značilnosti domenskih modelov.

        Razširitveni mehanizmi UML vključujejo:

• stereotipi (stereotip) - razširite besedišče UML, kar vam omogoča ustvarjanje novih na podlagi obstoječih jezikovnih elementov, osredotočenih na reševanje določenega problema;
• označene vrednosti - razširite lastnosti osnovnih konstruktov UML, kar omogoča vključitev dodatnih informacij v specifikacijo elementa;
• omejitve (omejitve) - razširite semantiko konstruktov UML, kar vam omogoča ustvarjanje novih in preklic obstoječih pravil.

        Ti trije mehanizmi razširitve jezika vam skupaj omogočajo, da ga spremenite v skladu s potrebami projekta ali značilnostmi razvojne tehnologije.

Diagram primerov uporabe

        Ta vrsta diagrama vam omogoča, da ustvarite seznam operacij, ki jih izvaja sistem. Pogosto se ta tip diagrama imenuje funkcijski diagram, saj se na podlagi nabora takih diagramov ustvari seznam zahtev za sistem in določi nabor funkcij, ki jih sistem izvaja.

Slika - 1. Diagram primerov uporabe

        Diagrami primerov uporabe opisujejo funkcionalnost sistema ali kaj naj bi sistem počel. Razvoj diagrama ima naslednje cilje:

• določiti splošne meje in kontekst modeliranega predmetnega področja;
• oblikovati splošne zahteve za funkcionalno obnašanje načrtovanega sistema;
• razviti začetni konceptualni model sistema za njegovo kasnejšo podrobnost v obliki logičnih in fizičnih modelov;
• pripraviti začetno dokumentacijo za interakcijo razvijalcev sistema s svojimi strankami in uporabniki.

        Bistvo diagrama primerov uporabe je naslednje. Sistem, ki se načrtuje, je predstavljen kot niz entitet ali akterjev, ki komunicirajo s sistemom prek primerov uporabe. V tem primeru je igralec ali igralec katera koli entiteta, ki je v interakciji s sistemom od zunaj. To je lahko oseba, tehnična naprava, program ali katerikoli drug sistem, ki lahko služi kot vir vpliva na simulirani sistem, kot določi razvijalec sam. Primer uporabe služi za opis storitev, ki jih sistem zagotavlja akterju.

        Namen primera uporabe je definirati celoten vidik ali fragment vedenja neke entitete, ne da bi razkrili njeno notranjo strukturo. Taka entiteta je lahko sistem ali kateri koli element modela, ki ima svoje vedenje.

        Vsak primer uporabe ustreza ločeni storitvi, ki jo modelirana entiteta zagotavlja na zahtevo akterja, kar pomeni, da določa, kako bo ta entiteta uporabljena. Storitev, ki se inicializira na zahtevo akterja, je popolno, nedeljivo zaporedje dejanj. To pomeni, da se mora sistem po končani obdelavi zahteve vrniti v prvotno stanje, da je pripravljen za obdelavo naslednjih zahtev.

        Primere uporabe je mogoče uporabiti za določitev zunanjih zahtev za sistem, ki se načrtuje, in za določitev funkcionalnega obnašanja obstoječega sistema. Nabor primerov uporabe kot celota mora definirati vse možne vidike pričakovanega obnašanja sistema. Poleg tega primeri uporabe implicitno določajo zahteve, ki določajo, kako morajo akterji komunicirati s sistemom, da lahko pravilno upravljajo ponujene storitve. Zaradi udobja je mogoče številne primere uporabe obravnavati kot ločen paket.

        Primeri uporabe so lahko naslednja dejanja: preverjanje stanja na tekočem računu stranke, oddaja naročila za nakup blaga, pridobivanje dodatnih informacij o kreditni sposobnosti stranke, prikaz grafičnega obrazca na zaslonu monitorja in drugo. dejanja.

razredni diagram

        Osrednje mesto v objektno usmerjenem programiranju je razvoj logičnega modela sistema v obliki diagrama razredov. Diagram razredov se uporablja za predstavitev statične strukture sistemskega modela v terminologiji razredov objektno usmerjenega programiranja. Diagram razredov lahko odraža predvsem različne odnose med posameznimi domenskimi entitetami, kot so objekti in podsistemi, ter opisuje njihovo notranjo strukturo in vrste odnosov.

Slika - 2. Diagram razredov

        Ikone diagramov vam omogočajo prikaz kompleksne hierarhije sistemov, odnosov med razredi (Classes) in vmesniki (Interfaces). Ta tip diagrama je vsebinsko nasproten diagramu sodelovanja, ki prikazuje sistemske objekte. Rational Rose vam omogoča ustvarjanje razredov z uporabo te vrste diagramov v različnih zapisih. podobno oblaku. Tako je razred le predloga, po kateri bo v prihodnosti izdelan določen objekt.

        Diagram razredov je graf, katerega vozlišča so elementi tipa "klasifikator", povezani z različnimi vrstami strukturnih odnosov. Diagram razredov lahko vsebuje tudi vmesnike, pakete, relacije in celo posamezne primerke, kot so objekti in relacije.

        Razred v jeziku UML služi za označevanje nabora objektov, ki imajo enako strukturo, obnašanje in odnose z objekti drugih razredov. Grafično je razred prikazan kot pravokotnik, ki ga lahko dodatno razdelimo z vodoravnimi črtami na odseke oz. Ti razdelki lahko vključujejo ime razreda, atribute (spremenljivke) in operacije (metode).

diagram stanja

        Vsak diagram stanja v UML opisuje vsa možna stanja enega primerka določenega razreda in možna zaporedja njegovih prehodov iz enega stanja v drugo, to pomeni, da modelira vse spremembe stanj objekta kot njegov odziv na zunanje vplivi.

        Diagrami stanja se najpogosteje uporabljajo za opis vedenja posameznih objektov, lahko pa se uporabljajo tudi za določanje funkcionalnosti drugih komponent modela, kot so primeri uporabe, akterji, podsistemi, operacije in metode.

Slika - 2. Diagram stanja

        Diagram stanja je posebna vrsta grafa, ki predstavlja določen avtomat. Oglišča grafa so možna stanja stroja, prikazana z ustreznimi grafičnimi simboli, loki pa označujejo njegove prehode iz stanja v stanje. Diagrame stanja je mogoče ugnezditi, da zagotovijo podrobnejšo predstavitev posameznih elementov modela.

        V metamodelu UML stroj je paket, ki definira številne koncepte, potrebne za predstavitev vedenja modelirane entitete v obliki diskretnega prostora s končnim številom stanj in prehodov.

        Trajanje sistema v katerem koli od možnih stanj znatno presega čas, porabljen za prehod iz enega stanja v drugo. Predpostavlja se, da je v limitu lahko prehodni čas enak nič (razen če ni drugače določeno), to pomeni, da lahko pride do spremembe stanja objekta v trenutku.

        Obnašanje avtomata je modelirano kot zaporedno gibanje vzdolž grafa od točke do točke, pri čemer se upošteva orientacija lokov, ki ju povezujejo.

        Za stroj morajo biti izpolnjeni naslednji obvezni pogoji:

• stanje, v katerega lahko preide predmet, je določeno le z njegovim trenutnim stanjem in ni odvisno od njegove prejšnje zgodovine;
• V vsakem trenutku je lahko avtomat samo v enem od svojih stanj. Istočasno lahko avtomat ostane v ločenem stanju poljubno dolgo, če se ne zgodi noben dogodek;
• čas, ko je stroj v enem ali drugem stanju, kot tudi čas, ki je potreben, da doseže eno ali drugo stanje, ni na noben način določen;
• število stanj avtomata mora biti končno in vsa morajo biti eksplicitno navedena. Posamezna psevdostanja morda nimajo specifikacij (začetno in končno stanje). V tem primeru sta njihov namen in semantika popolnoma določena iz konteksta modela in obravnavanega diagrama stanja;
• Avtomatski graf ne sme vsebovati izoliranih stanj in prehodov. Za vsako stanje, razen začetnega, je treba določiti prejšnje stanje, vsak prehod pa mora povezati dve stanji stroja;
• avtomat ne sme vsebovati konfliktnih prehodov, ko lahko objekt hkrati prehaja v dve ali več zaporednih stanj (razen v primeru vzporednih podavtomatov). V UML je odprava konflikta možna z uvedbo varovalnih pogojev.

država je temeljnega pomena ne samo v metamodelu jezika UML, ampak tudi v uporabni sistemski analizi. Celoten koncept dinamičnega sistema temelji na konceptu stanja. Semantika stanja v jeziku UML ima številne posebne značilnosti.

        V UML je stanje abstrakten metarazred, ki se uporablja za modeliranje specifične situacije, med katero so izpolnjeni določeni pogoji. Stanje je mogoče podati kot niz določenih vrednosti atributa razreda ali predmeta. Spremembe posameznih vrednosti atributov bodo odražale spremembe v stanju razreda ali predmeta, ki se modelira.

Diagram dejavnosti

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

        Pravzaprav se ta tip diagrama lahko uporablja tudi za prikaz stanj modeliranega objekta, vendar je glavni namen diagrama dejavnosti odraz poslovnih procesov objekta. Ta vrsta diagrama vam omogoča prikaz ne le zaporedja procesov, temveč tudi razvejanost in celo sinhronizacijo procesov.

        Ta vrsta diagrama vam omogoča oblikovanje algoritmov za obnašanje objektov katere koli kompleksnosti, vključno z uporabo za pripravo blokovnih diagramov.

        Za modeliranje procesa izvajanja operacij v jeziku UML se uporabljajo diagrami dejavnosti. Grafični zapis, uporabljen v njih, je v marsičem podoben zapisu diagrama stanja, saj ti diagrami vsebujejo tudi simbole stanja in prehoda. Vsako stanje v diagramu dejavnosti ustreza zaključku neke osnovne operacije, prehod v naslednje stanje pa se pojavi šele, ko je ta operacija končana.

        Tako lahko diagrame aktivnosti obravnavamo kot poseben primer diagramov stanj. Omogočajo vam, da v jeziku UML implementirate funkcije postopkovnega in sinhronega nadzora zaradi zaključka notranjih dejavnosti in dejanj. Glavna uporaba diagramov aktivnosti je vizualizacija izvedbenih značilnosti razrednih operacij, ko je treba predstaviti algoritme za njihovo izvedbo.

        V kontekstu jezika UML dejavnost je niz posameznih izračunov, ki jih izvede avtomat, ki vodijo do nekega rezultata ali dejanja. Diagram dejavnosti prikazuje logiko in zaporedje prehodov iz ene dejavnosti v drugo in usmerja analitikovo pozornost na rezultate. Posledica dejavnosti je lahko sprememba stanja sistema ali vrnitev neke vrednosti.

        Akcijsko stanje je poseben primer stanja z določenim vhodnim dejanjem in vsaj enim prehodom, ki zapusti stanje. Ta prehod implicitno predvideva, da je vnosno dejanje že zaključeno. Akcijsko stanje ne more imeti notranjih prehodov, ker je elementarno. Običajna uporaba stanja dejanja je modeliranje enega koraka v izvajanju algoritma (postopka) ali krmilnega toka.

Diagram zaporedja

        Pri obravnavi diagramov stanja in aktivnosti je bilo ugotovljeno, da čeprav se ti diagrami uporabljajo za določanje dinamike obnašanja sistema, čas v njih ni eksplicitno prisoten. Časovni vidik vedenja je lahko pomemben pri modeliranju sinhronih procesov, ki opisujejo interakcije objektov. Za modeliranje interakcije objektov skozi čas UML uporablja diagrame zaporedja.

        Samo tisti predmetov, ki so neposredno vključeni v interakcijo. Ključ do diagramov zaporedja je dinamika medsebojnega delovanja predmetov skozi čas.

        V UML ima diagram zaporedja dve dimenziji. Prvi je od leve proti desni v obliki navpičnih črt, od katerih vsaka prikazuje življenjsko linijo ločenega predmeta, ki sodeluje v interakciji. Objekt na skrajni levi strani diagrama je tisti, ki sproži interakcijo. Desno je še en predmet, ki je v neposredni interakciji s prvim. Tako vsi predmeti v diagramu zaporedja tvorijo nek vrstni red, ki ga določa vrstni red ali stopnja aktivnosti predmetov pri medsebojni interakciji.

        Grafično je vsak predmet upodobljen kot pravokotnik in se nahaja v zgornjem delu njegove življenjske črte. Znotraj pravokotnika napišite ime predmeta in ime razreda, ločena z dvopičjem. V tem primeru je poudarjen celoten zapis, ki je znak predmeta.

        Druga dimenzija diagrama zaporedja je navpična časovna os, usmerjena od zgoraj navzdol. Najvišji del diagrama ustreza začetnemu trenutku časa. Interakcije objektov se izvajajo prek sporočil, ki jih en objekt pošlje drugemu. Sporočila so prikazana kot vodoravne puščice z imenom sporočila, njihov vrstni red pa je določen s časom nastanka. To pomeni, da se sporočila, ki se nahajajo višje v zaporednem diagramu, začnejo pred tistimi, ki se nahajajo nižje. Lestvica na časovni osi ni navedena, saj diagram zaporedja modelira le časovno urejenost interakcij »prej-pozneje«.

Diagram sodelovanja

        Glavna značilnost diagrama sodelovanja je zmožnost grafične predstavitve ne le zaporedja interakcije, temveč tudi vseh strukturnih odnosov med objekti, ki sodelujejo v tej interakciji.

Slika - 3. Diagram sodelovanja

        Ta vrsta diagrama vam omogoča, da opišete interakcije predmetov, pri čemer abstrahirate zaporedje prenosa sporočil. Ta vrsta diagrama prikazuje v strnjeni obliki vsa prejeta in poslana sporočila posameznega objekta in tipe teh sporočil.

        Najprej diagram sodelovanja prikazuje predmete, ki sodelujejo v interakciji, v obliki pravokotnikov, ki vsebujejo ime predmeta, njegov razred in po možnosti vrednosti atributov. Nadalje, kot v diagramu razredov, so povezave med objekti označene v obliki različnih povezovalnih črt. V tem primeru lahko eksplicitno določite imena povezave in vloge, ki jih predmeti igrajo v tej povezavi. Poleg tega je mogoče prikazati dinamične povezave - tokove sporočil. Predstavljene so tudi kot povezovalne črte med objekti, nad katerimi je puščica, ki označuje smer, ime sporočila in zaporedno številko v splošnem zaporedju inicializacije sporočila.

        Za razliko od diagrama zaporedja diagram sodelovanja prikazuje le odnose med objekti, ki igrajo določene vloge v interakciji. Ta grafikon ne prikazuje časa kot ločene dimenzije. Zato lahko zaporedje interakcij in vzporednih tokov določimo z uporabo zaporednih številk. Če morate torej izrecno podati razmerja med objekti v realnem času, je bolje, da to storite v diagramu zaporedja.

        Koncept sodelovanje je eden temeljnih pojmov v jeziku UML. Služi za označevanje niza objektov, ki medsebojno delujejo z določenim namenom v splošnem kontekstu modeliranega sistema. Namen samega sodelovanja je določitev izvedbenih značilnosti posameznih najpomembnejših operacij v sistemu. Sodelovanje definira strukturo vedenja sistema v smislu interakcije udeležencev v tem sodelovanju.

        Sodelovanje lahko predstavljamo na dveh ravneh:

• raven specifikacije - prikazuje vloge klasifikatorjev in vloge asociacij v obravnavani interakciji;
• nivo primera - označuje instance in odnose, ki tvorijo posamezne vloge v sodelovanju.

        Diagram sodelovanja na ravni specifikacije prikazuje vloge elementov, vključenih v interakcijo. Elementi sodelovanja na tej ravni so razredi in asociacije, ki označujejo posamezne vloge klasifikatorjev in asociacij med udeleženci v sodelovanju.

        Diagram sodelovanja na ravni primera je predstavljen z nizom objektov (primeri razredov) in povezav (primeri asociacij). V tem primeru so povezave dopolnjene s puščicami sporočil. Na tej ravni so prikazani le objekti, ki so neposredno povezani z izvajanjem operacije ali klasifikatorja. V tem primeru sploh ni potrebno prikazati vseh lastnosti ali vseh asociacij, saj diagram sodelovanja vsebuje samo vloge klasifikatorjev, ne pa tudi samih klasifikatorjev. Medtem ko klasifikator zahteva popoln opis vseh svojih primerkov, vloga klasifikatorja zahteva opis samo tistih lastnosti in povezav, ki so potrebne za sodelovanje v določenem sodelovanju.

        Iz tega sledi pomembna posledica. Isti niz objektov lahko sodeluje v različnih kooperacijah. Glede na obravnavano sodelovanje se lahko spremenijo tako lastnosti posameznih objektov kot tudi povezave med njimi. To je tisto, kar razlikuje diagram sodelovanja od diagrama razredov, ki mora navesti vse lastnosti in povezave med elementi diagrama.

Diagram komponent

        Ta vrsta diagrama je namenjena porazdelitvi razredov in objektov med komponente med fizičnim načrtovanjem sistema. To vrsto diagramov pogosto imenujemo modulni diagrami.

Slika - 4. Diagram komponent

        Popolna zasnova programskega sistema je niz modelov logične in fizične ravni, ki morajo biti med seboj skladni. UML uporablja izvedbene diagrame za fizično predstavitev sistemskih modelov, ki vključujejo komponentni diagram in diagram razmestitve.

        Komponentni diagram za razliko od prej obravnavanih diagramov opisuje značilnosti fizične predstavitve sistema. Omogoča vam, da določite arhitekturo sistema, ki se razvija, tako da vzpostavite odvisnosti med komponentami programske opreme, ki so lahko izvorna in izvršljiva koda. Glavni grafični elementi diagrama komponent so komponente, vmesniki in odvisnosti med njimi.

        Diagram komponent je razvit za naslednje namene:

• vizualizacija splošne strukture izvorne kode programskega sistema;
• specifikacije izvršljive različice programskega sistema;
• zagotavljanje ponovne uporabe posameznih fragmentov programske kode;
• predstavitve konceptualnih in fizičnih shem baze podatkov.

        Pri razvoju komponentnih diagramov sodelujejo tako sistemski analitiki in arhitekti kot tudi programerji. Komponentni diagram zagotavlja dosleden prehod od logične predstavitve do konkretne izvedbe projekta v obliki programske kode. Nekatere komponente lahko obstajajo samo na stopnji prevajanja programske kode, druge na stopnji njenega izvajanja. Komponentni diagram odraža splošne odvisnosti med komponentami in slednje obravnava kot klasifikatorje.

        Za predstavitev fizičnih entitet v jeziku UML se uporablja poseben izraz - komponento. Komponenta implementira določen nabor vmesnikov in služi za splošno označevanje elementov fizične predstavitve modela. Za grafično predstavitev komponente se uporablja poseben simbol - pravokotnik z dvema manjšima pravokotnikoma na levi strani. Znotraj velikega pravokotnika je ime komponente in po potrebi nekaj dodatnih informacij. Videz tega simbola se lahko nekoliko razlikuje glede na naravo informacij, povezanih s komponento.

Diagram razmestitve

        Ta vrsta diagrama je namenjena analizi strojne opreme sistema, torej strojne opreme, ne programov. Neposredno prevedeno iz angleščine Deployment pomeni "razmestitev", vendar izraz "topologija" natančneje odraža bistvo te vrste diagrama.

Slika - 5. Diagram namestitve

        Fizična predstavitev programskega sistema ne more biti popolna, če ni informacij o tem, na kateri platformi in na katerih računalniških sredstvih je implementiran. Če se razvija program, ki deluje lokalno na uporabnikovem računalniku in ne uporablja perifernih naprav in virov, potem ni potrebe po razvoju dodatnih diagramov. Pri razvoju korporativnih aplikacij je lahko prisotnost takšnih diagramov izjemno koristna za reševanje problemov racionalne namestitve komponent za učinkovito uporabo porazdeljenih računalniških in komunikacijskih virov omrežja, zagotavljanje varnosti in drugo.

        Diagrami razmestitve se uporabljajo za predstavitev splošne konfiguracije in topologije sistema porazdeljene programske opreme v UML.

        Razmestitveni diagram je zasnovan za vizualizacijo elementov in komponent programa, ki obstajajo samo v fazi izvajanja. V tem primeru so predstavljene samo komponente primerka programa, ki so izvršljive datoteke ali dinamične knjižnice. Tiste komponente, ki se med izvajanjem ne uporabljajo, niso prikazane v diagramu razmestitve. Tako so komponente z izvorno kodo programa lahko prisotne samo na diagramu komponent. Niso označeni na diagramu razmestitve.

        Diagram uvedbe vsebuje grafične predstavitve procesorjev, naprav, procesov in povezav med njimi. Za razliko od diagramov logične predstavitve je diagram uvajanja enoten za sistem kot celoto, saj mora v celoti odražati značilnosti njegove izvedbe. Razvoj diagrama uvajanja je običajno zadnji korak pri določanju modela sistema programske opreme.

        Pri razvoju diagrama uvajanja se zasledujejo naslednji cilji:

• določi porazdelitev sistemskih komponent po njegovih fizičnih vozliščih;
• prikazati fizične povezave med vsemi vozlišči implementacije sistema v fazi njegovega izvajanja;
• identificira ozka grla v sistemu in ponovno konfigurira njegovo topologijo, da doseže zahtevano zmogljivost.

        Diagrame uvajanja skupaj razvijejo sistemski analitiki, omrežni inženirji in sistemski tehniki.

Lastnosti delovnega vmesnika Rational Rose

        Orodje Rational Rose CASE implementira splošno sprejete standarde za operacijski vmesnik programa, podobno kot dobro znana okolja za vizualno programiranje. Po namestitvi Rational Rose na uporabnikov računalnik, ki ne povzroča skoraj nobenih težav niti za začetnike, zagon tega programa v MS Windows 95/98 vodi do videza delujočega vmesnika na zaslonu (slika 6).

Slika - 6. Splošni pogled na delovni vmesnik programa Rational Rose

        Operacijski vmesnik Rational Rose je sestavljen iz različnih elementov, med katerimi so glavni:

• Glavni meni programa
• Okno diagrama
• Okno z dokumentacijo
• Okno brskalnika
• Dnevniško okno

Na kratko razmislimo o namenu in glavnih funkcijah vsakega od teh elementov.

Glavni meni programa

Glavni meni programa je izdelan v splošno sprejetem standardu in izgleda tako (slika 7).

Posamezni menijski elementi, katerih namen je jasen iz njihovih imen, združujejo podobne operacije, povezane s celotnim projektom kot celoto. Nekateri elementi menija vsebujejo znane funkcije (odpiranje projekta, tiskanje diagramov, kopiranje in lepljenje različnih elementov diagramov iz odložišča). Druge so tako specifične, da lahko zahtevajo dodatne napore za preučevanje (možnosti generiranja kode, preverjanje skladnosti modela, povezovanje dodatnih modulov).

Slika - 7. Videz glavnega menija programa

Standardna orodna vrstica

Standardna orodna vrstica se nahaja pod glavnim menijem programa in izgleda tako (slika 8). Nekatera orodja niso na voljo (novi projekt nima elementov). Standardna orodna vrstica omogoča hiter dostop do menijskih ukazov, ki jih razvijalci najpogosteje uporabljajo.

Slika - 8. Videz standardne orodne vrstice

Uporabnik lahko prilagodi videz te plošče po lastni presoji. To storite tako, da izberete menijsko točko Orodja -> Možnosti in odprete zavihek Orodne vrstice. Na ta način lahko prikažete ali skrijete različne orodne gumbe in spremenite njihovo velikost.

Okno brskalnika

Privzeto okno brskalnika se nahaja na levi strani delovnega vmesnika pod standardno orodno vrstico (slika 9).

Brskalnik organizira poglede modela v hierarhično strukturo, ki poenostavlja navigacijo in omogoča iskanje katerega koli elementa modela v projektu. V tem primeru se vsak element, ki ga razvijalec doda modelu, takoj prikaže v oknu brskalnika. V skladu s tem lahko element z izbiro v oknu brskalnika vizualiziramo v oknu diagrama ali spremenimo njegovo specifikacijo. Brskalnik omogoča tudi organiziranje elementov modela v pakete in premikanje elementov med različnimi pogledi modela. Če želite, lahko okno brskalnika postavite na drugo mesto v delovnem vmesniku ali ga v celoti skrijete z uporabo menijske postavke Pogled. Velikost brskalnika lahko spremenite tudi tako, da z miško povlečete njegov zunanji okvir.

Slika - 9. Videz brskalnika

Posebna orodna vrstica

Posebna orodna vrstica se nahaja med oknom brskalnika in oknom grafikona v srednjem delu delovnega vmesnika. Privzeto je na voljo orodna vrstica za izdelavo diagrama razreda modela (slika 10).

Slika - 10. Videz posebne orodne vrstice za razredni diagram

Mesto posebne orodne vrstice lahko spremenite tako, da premaknete okvir plošče na želeno mesto. Sestavo plošče lahko prilagodite tudi tako, da dodate ali odstranite posamezne gumbe, ki ustrezajo določenim orodjem. Dodelitev gumbov se lahko naučite iz namigov orodij, ki se prikažejo, ko kazalec miške premaknete nad ustrezni gumb.

Okno diagrama

Okno diagrama je glavno delovno področje njegovega vmesnika, v katerem so vizualizirani različni pogledi na model projekta. Okno diagrama se privzeto nahaja na desni strani delovnega vmesnika, vendar lahko njegovo lokacijo in velikost tudi spremenite. Če pri razvoju novega projekta niste uporabili čarovnika za projekt, je okno diagrama prazno območje, ki ne vsebuje elementov modela (slika 11).

Ime diagrama, ki se nahaja v tem oknu, je navedeno v naslovni vrstici programa (najvišja vrstica programa) ali, če okno ni povečano na celoten zaslon, v naslovni vrstici okna grafikona. V oknu grafikona je lahko hkrati prisotnih več grafikonov, vendar je lahko samo eden od njih aktiven. Na primer na sl. 11 je aktivni diagram razmestitveni diagram, čeprav obstajajo tudi drugi diagrami. Preklapljanje med diagrami je možno z izbiro želenega pogleda v standardni orodni vrstici ali prek menijske postavke Okno. Ko aktivirate ločen pogled grafikona, se spremeni videz posebne orodne vrstice, ki je prilagojena posameznemu pogledu grafikona.

Slika - 11. Videz okna diagrama z različnimi vrstami pogledov modela

Okno z dokumentacijo

Okno dokumentacije morda privzeto ni na zaslonu. V tem primeru ga lahko aktiviramo preko menijske postavke Pogled -> Dokumentacija, nato pa se prikaže pod brskalnikom (slika 12).

Dokumentacijsko okno, kot pove že njegovo ime, je zasnovano za dokumentiranje elementov pogleda modela. Vanj lahko posnamete najrazličnejše informacije, in kar je pomembno - v ruskem jeziku. Te informacije se nato pretvorijo v komentarje in na noben način ne vplivajo na logiko izvajanja programske kode.

V dokumentacijskem oknu se aktivirajo informacije, ki se nanašajo na posamezni izbrani element diagrama. V tem primeru lahko izberete element v oknu brskalnika ali v oknu diagrama. Ko v diagram dodate nov element (na primer razred), se samodejno ustvari dokumentacija zanj, ki je prazna (Ni dokumentacije). Nato razvijalec samostojno vnese potrebne razlagalne informacije, ki si jih zapomni in jih je mogoče med delom na projektu spremeniti.

Tako kot pri drugih oknih delovnega vmesnika lahko spremenite velikost in položaj okna dokumentacije.

Slika - 12. Videz dokumentacijskega okna

Dnevniško okno

Okno Dnevnik je zasnovano za samodejno beleženje različnih servisnih informacij, ki nastanejo med delom s programom. Dnevnik beleži čas in naravo dejanj, ki jih izvaja razvijalec, kot je posodabljanje modela, prilagajanje menijev in orodnih vrstic, kot tudi sporočila o napakah, ki se pojavijo pri generiranju programske kode.

Okno dnevnika je vedno prisotno na delovnem vmesniku v območju okna diagrama (slika 13). Lahko pa je skrito z drugimi okni grafikona ali pomanjšano. Okno dnevnika lahko aktivirate prek menija Okno->Dnevnik. V tem primeru je prikazan na vrhu drugih oken v desnem delu delovnega vmesnika. Tega okna ni mogoče v celoti odstraniti, lahko ga le pomanjšate.

Slika - 13. Videz okna dnevnika

Zaključek

        Sčasoma bo jezik UML postal »esperanto«, v katerem se bodo lahko sporazumevali matematiki, sistemski analitiki, fiziki, programerji, menedžerji, ekonomisti in strokovnjaki drugih strok, ki bodo svoje strokovno znanje predstavljali v enotni obliki. Konec koncev, v bistvu vsak od strokovnjakov deluje z modelnimi predstavitvami na svojem področju znanja. In ravno ta vidik modela je mogoče določiti z uporabo jezika UML.

        Pri tem se pomembno povečuje pomen jezika UML, saj vse bolj pridobiva lastnosti jezika za predstavitev znanja. Hkrati prisotnost vizualnih sredstev v jeziku UML za predstavitev strukture in obnašanja modela omogoča doseganje ustrezne predstavitve deklarativnega in proceduralnega znanja in, kar je nič manj pomembno, vzpostavitev semantične korespondence med temi oblikami znanja. Vse te značilnosti jezika UML nam omogočajo, da sklepamo, da ima v bližnji prihodnosti najresnejše možnosti.

Ta članek opisuje novo dobo razvoja programske opreme, njen vpliv na nove zahteve UML in najboljše prakse za njihovo izpolnjevanje.
  7. »Modeliranje podatkov v Rational Rose« Sergey Trofimov Opisuje modeliranje fizične predstavitve podatkov z uporabo Rational Rose
  8. Jezik UML. Splošno razumevanje jezika UML: strukture, grafični elementi in diagrami jezika.
  9. Praktični UML. Ta dokument je prevod dokumenta "Praktični UML. Praktični uvod za razvijalce". Praktični uvod za razvijalce
  10. “Standardni objektno usmerjen jezik za modeliranje UML” Vendrov Aleksander Mihajlovič. Zgodovina UML
  11. UML – enoten jezik za modeliranje. To gradivo vsebuje začetne informacije o metodah za opis sistemov programske opreme in zapisov, ki se uporabljajo v UML
  12. Jezik UML. Navodila. Avtorji: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. "Diagrami UML v Rational Rose" Sergej Trofimov
  14. "Analiza in oblikovanje. Vizualno modeliranje (UML) Rational Rose" Konstantin Domolego
  15. Knjižnica Genadija Vernikova. Popolni opisi standardov oblikovanja in modeliranja.
  16. "Primer opisa predmetnega področja z uporabo UML pri razvoju programskih sistemov" E.B. Zolotukhina, R.V. Alfimov. Članek na konkretnem primeru prikazuje možen pristop k modeliranju domen, ki temelji na uporabi poenotenega jezikovnega modeliranja (UML).

       

UML je splošni jezik za grafično modeliranje za določanje, vizualizacijo, oblikovanje in dokumentiranje vseh artefaktov, ustvarjenih med razvojem programskih sistemov.

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

Ta članek uporablja materiale iz knjig: Ivanov D. Yu., Novikov F. A. Enotni modelni jezik UML in Leonenkov. UML vadnica.

Najprej se odločimo za urejevalnik. Pod Linuxom sem preizkusil različne urejevalnike UML, najbolj mi je bil všeč UMLet, čeprav je napisan v Javi, se zelo hitro premika in vsebuje večino entitetnih predlog. Obstaja tudi ArgoUML, večplatformski urejevalnik UML, prav tako napisan v Javi, ki je funkcionalno bogat, vendar bolj upočasnjuje.

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

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

V UML lahko vse entitete razdelimo na naslednje vrste:

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

V UML se uporabljajo štiri glavne vrste odnosov:

Odvisnost- označuje, da sprememba v neodvisni entiteti nekako vpliva na odvisno entiteto. Grafično je razmerje odvisnosti prikazano kot pikčasta črta s puščico, usmerjeno od odvisne entitete k neodvisni entiteti.

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

Posploševanje je razmerje med dvema entitetama, od katerih je ena poseben (specializiran) primer druge. Grafično je posplošitev prikazana kot črta s trikotno, nezapolnjeno puščico na koncu, usmerjeno od posameznega (podrazred) k splošnemu (nadrazred).

Izvedbe- Implementacijsko razmerje kaže, da je ena entiteta implementacija druge. Grafično je implementacija prikazana kot pikčasta črta s trikotno, nezalito puščico na koncu, usmerjeno od izvajalske entitete k izvajalski entiteti.

IN UML 2 definiran 13 vrste diagramov. V skladu s standardi mora imeti vsak diagram okvir s pravokotnikom (spodnji desni kot poševno) v zgornjem levem kotu, ki označuje identifikator diagrama (tag) in naslov.

Diagrami za prikaz strukture sistema:

• Diagram komponent (oznaka komponento);
• Diagram razmestitve, oznaka uvajanje);
• Diagram razreda (diagram razreda, oznaka razred);
• Diagram objekta (tag predmet);
• Diagram sestavljene strukture, oznaka razred);

Diagrami za prikaz obnašanja sistema:

• Sinhronizacijski diagram (interakcijski diagram, oznaka čas);
• Diagram dejavnosti (tag dejavnost);
• Diagram zaporedja, oznaka SD);
• Diagram komunikacije (tag sporočila);
• Diagram stanja stroja, oznaka državni stroj);
• diagram pregleda interakcije, oznaka interakcija);

Diagrami izstopajo:

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

Diagram uporabe

Diagram uporabe(diagram primerov uporabe) je najsplošnejši prikaz funkcionalnega namena sistema.

Ko diagram primera uporabe obravnavate kot model sistema, ga lahko povežete z modelom črne skrinjice. Vsak primer uporabe definira zaporedje dejanj, ki jih mora izvesti oblikovani sistem, ko sodeluje z ustreznim akterjem.

Diagram uporabe uporablja dve vrsti osnovnih entitet: primere uporabe in akterje, med katerimi so vzpostavljeni naslednji osnovni tipi odnosov.

Asociacijsko razmerje- To razmerje določa, kakšno specifično vlogo ima akter pri interakciji s primerkom primera uporabe. Asociacijsko razmerje je označeno s polno črto med akterjem in primerom uporabe. Ta vrstica ima lahko dodatne simbole, kot sta ime in množica.

Razširitveno razmerje- definira razmerje med primeri določenega primera uporabe in bolj splošnega primera uporabe, katerih lastnosti so določene na podlagi načina, kako so ti primeri združeni. Če torej obstaja razširitvena relacija iz primera uporabe A v primer uporabe B, potem to pomeni, da je mogoče lastnosti primerka primera uporabe B razširiti zaradi prisotnosti lastnosti v razširjenem primeru uporabe A.

Razširitveno razmerje med primeri uporabe je označeno s pikčasto črto s puščico (možnost razmerja odvisnosti), ki kaže stran od primera uporabe, ki je razširitev prvotnega primera uporabe.

Generalizacijska relacija služi za označevanje dejstva, da je mogoče nek primer uporabe A posplošiti na primer uporabe B. V tem primeru bo možnost A specializacija možnosti B. V tem primeru se B imenuje prednik ali starš A, možnost A pa otrok možnosti uporabe V.

Grafično je to razmerje predstavljeno s polno črto s puščico v obliki odprtega trikotnika, ki označuje nadrejeni primer uporabe.

Posplošitveno razmerje med primeri uporabe se uporablja, kadar je treba opozoriti, da imajo podrejeni primeri uporabe vse atribute in vedenje nadrejenih primerov uporabe.

Inkluzivno razmerje med dvema primeroma uporabe nakazuje, da je določeno vedenje za en primer uporabe vključeno kot sestavna komponenta v zaporedju vedenj drugega primera uporabe.

Vključitveno razmerje, usmerjeno od primera uporabe A do primera uporabe B, kaže, da vsak primerek primera uporabe A vključuje funkcionalne lastnosti, določene za primer uporabe B.

Grafično je to razmerje označeno s pikčasto črto s puščico (različica razmerja odvisnosti), usmerjeno od osnovnega primera uporabe k vključenemu.

Razredni diagram

Razredni diagram(diagram razredov) je glavni način za opis statične strukture sistema.

Diagram razredov uporablja eno glavno vrsto entitete: razrede (vključno s številnimi posebnimi primeri razredov: vmesniki, primitivni tipi, asociacijski razredi itd.), med katerimi so vzpostavljeni naslednji glavni tipi odnosov: odvisnosti, asociacije, posplošitve, implementacije.

Odvisniško razmerje na splošno označuje neko pomensko razmerje med dvema elementoma modela ali dvema nizoma takih elementov, ki ni razmerje asociacije, posploševanja ali izvajanja. Razmerje odvisnosti se uporablja v situaciji, ko lahko neka sprememba enega elementa modela zahteva spremembo drugega elementa modela, ki je odvisen od tega.

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

Nad puščico so lahko posebne ključne besede (stereotipi):

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

Asociacijsko razmerje ustreza prisotnosti nekega odnosa med razredi. To razmerje je označeno s polno črto z dodatnimi posebnimi simboli, ki označujejo posamezne lastnosti določene asociacije. Dodatni posebni znaki so lahko ime asociacije, pa tudi imena in množice razredov vlog asociacije. Ime društva je neobvezen element njegovega poimenovanja.

Agregacijsko razmerje se pojavi med več razredi, če eden od razredov predstavlja entiteto, ki vključuje druge entitete kot komponente. Uporablja se za predstavitev sistemskih odnosov tipa "del-celota".

Razmerje sestave je poseben primer agregacijske relacije. Ta relacija služi poudarjanju posebne oblike relacije »del-celota«, v kateri se sestavni deli na nek način nahajajo znotraj celote. Posebnost razmerja med njimi je v tem, da deli ne morejo delovati ločeno od celote, to pomeni, da z uničenjem celote uničijo vse njene sestavne dele.

Generalizacijska relacija je razmerje med bolj splošnim elementom (staršem ali prednikom) in bolj specifičnim ali specializiranim elementom (otrok ali potomec). Če ga uporabimo za diagram razredov, to razmerje opisuje hierarhično strukturo razredov ter dedovanje njihovih lastnosti in obnašanja. To predpostavlja, da ima razred potomec vse lastnosti in obnašanje razreda prednika ter ima tudi lastne lastnosti in obnašanje, ki jih razred prednika nima.

Diagram stroja

Diagram stroja(diagram stanja avtomata) oz diagram stanja v UML 1 (diagram stanja) je eden od načinov za podrobno opisovanje vedenja v UML. V bistvu so strojni diagrami, kot že ime pove, graf stanj in prehodov končnega avtomata, napolnjen s številnimi dodatnimi podrobnostmi in podrobnostmi.

Diagram stanja opisuje proces spreminjanja stanj le enega razreda, natančneje ene instance določenega razreda, torej modelira vse možne spremembe stanja določenega objekta. V tem primeru lahko spremembo stanja predmeta povzročijo zunanji vplivi drugih predmetov ali od zunaj. Diagrami stanja se uporabljajo za opis reakcije objekta na takšne zunanje vplive.

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

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

Končno (končno) stanje je poseben primer stanja, ki tudi ne vsebuje nobenih notranjih dejanj (psevdostanja). Objekt bo privzeto v tem stanju, potem ko bo stroj končal svoje delovanje na končni točki v času.

Diagram dejavnosti

Pri modeliranju obnašanja sistema, ki se načrtuje ali analizira, postane potrebno ne samo predstaviti proces spreminjanja njegovih stanj, ampak tudi podrobno opisati značilnosti algoritemske in logične izvedbe operacij, ki jih izvaja sistem.

Diagram dejavnosti(diagram dejavnosti) je še en način opisovanja vedenja, ki vizualno spominja na stari dobri diagram poteka algoritma. Uporablja se za modeliranje procesa izvajanja operacij.

Glavna uporaba diagramov aktivnosti je vizualizacija izvedbenih značilnosti razrednih operacij, ko je treba predstaviti algoritme za njihovo izvedbo.

Diagram dejavnosti uporablja eno glavno vrsto entitete – dejanje, in eno vrsto razmerja – prehode (prenose nadzora). Uporabljajo se tudi konstrukcije, kot so vilice, združitve, povezave in veje. Priporočljivo je, da kot ime preprostega dejanja uporabite glagol z razlagalnimi besedami.

Diagram zaporedja

Diagram zaporedja(diagram zaporedja) je način opisovanja obnašanja sistema "z uporabo primerov".

Pravzaprav je diagram zaporedja zapis protokola določene seje sistema (ali fragment takega protokola). V objektno usmerjenem programiranju je najpomembnejša stvar med izvajanjem prenos sporočil med komunicirajočimi objekti. V tem diagramu je prikazano zaporedje pošiljanja sporočil, od tod tudi ime.

Diagram zaporedja uporablja eno osnovno vrsto entitete - primerke medsebojno delujočih klasifikatorjev (predvsem razredov, komponent in akterjev) in eno vrsto razmerja - povezave, po katerih se izmenjujejo sporočila.

Možni tipi sporočil (slika iz larin.in):

Komunikacijski diagram

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

Tako se v komunikacijskem diagramu, pa tudi v diagramu zaporedja, uporablja ena glavna vrsta entitete - primerki medsebojno delujočih klasifikatorjev in ena vrsta odnosa - povezave. Vendar tu ni poudarek na času, ampak na strukturi povezav med posameznimi primerki.

Diagram komponent

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

Glavna vrsta entitet v diagramu komponent so komponente same, pa tudi vmesniki, prek katerih so določeni odnosi med komponentami. V diagramu komponent veljajo naslednja razmerja:

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

Diagram postavitve

Diagram postavitve(diagram razmestitve) skupaj s prikazom sestave in povezav sistemskih elementov prikazuje, kako so fizično locirani na računalniških virih med izvajanjem.

Diagram postavitve v primerjavi s komponentnim diagramom doda dve vrsti entitet: artefakt, ki je implementacija komponente in vozlišča (lahko je klasifikator, ki opisuje vrsto vozlišča ali določen primerek), in asociacijsko razmerje med vozlišči, kar kaže, da so se vozlišča fizično povezala med izvajanjem.

Diagram objekta

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

Objektni diagram uporablja eno glavno vrsto entitete: objekte (primerke razredov), med katerimi so označene posebne povezave (najpogosteje primerki asociacij). Objektni diagrami so pomožne narave - pravzaprav so to primeri (lahko bi rekli izpisi pomnilnika), ki prikazujejo, kateri objekti so na voljo in povezave med njimi v določenem trenutku delovanja sistema.

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

Strukturni klasifikator je upodobljen kot pravokotnik z imenom klasifikatorja na vrhu. Notri so deli. Delov je lahko več. Deli lahko medsebojno delujejo. To je označeno z različnimi vrstami priključkov. Mesto na zunanji meji dela, na katerega se priključek pritrdi, se imenuje vrata. Pristanišča se nahajajo tudi na zunanji meji strukturnega klasifikatorja.

Diagram pregleda interakcije Diagram pregleda interakcije je vrsta diagrama dejavnosti z razširjeno sintakso: elementi diagrama pregleda interakcije so lahko povezave do uporab interakcij, ki jih definirajo diagrami zaporedja.

Časovni diagram

Časovni diagramČasovni diagram je posebna oblika zaporednega diagrama, ki se osredotoča na spreminjanje stanj različnih primerkov klasifikatorjev in njihovo časovno sinhronizacijo.

Diagram paketa

Diagram paketa(paketni diagram) je edino orodje, ki omogoča upravljanje kompleksnosti samega modela.

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

Model entiteta-relacija (model ER)

Analogno razredni diagrami(UML) morda ER model, ki se uporablja pri načrtovanju baz podatkov (relacijski model).

Model entiteta-povezava (ER-model) je podatkovni model, ki vam omogoča opisovanje konceptualnih diagramov predmetnega področja. Model ER se uporablja pri načrtovanju baz podatkov na visoki ravni (konceptualni). Z njegovo pomočjo lahko identificirate ključne entitete in prepoznate povezave, ki jih je mogoče vzpostaviti med temi entitetami. wikipedia

Vsak delček predmetnega področja je mogoče predstaviti kot niz entitet, med katerimi obstaja več povezav.

Osnovni pojmi:

Esenca(entiteta) je predmet, ki ga je mogoče identificirati na nek način, ki ga razlikuje od drugih predmetov, na primer STRANKA 777. Entiteta je pravzaprav niz atributov.

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

Povezava(odnos) je povezava, vzpostavljena med več entitetami.

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

Obstajajo tri vrste binarnih vezi:

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

Objekt- entiteta, ki je edinstvena in zajema stanje in vedenje.

Razred- opis nabora objektov s skupnimi atributi, ki definirajo stanje in operacij, ki definirajo vedenje.

Vmesnik- imenovan niz operacij, ki določa niz storitev, ki jih lahko zahteva potrošnik in jih zagotovi ponudnik storitev.

Sodelovanje- niz predmetov, ki medsebojno delujejo, da bi dosegli neki cilj.

Igralec- entiteta, ki se nahaja zunaj modeliranega sistema in z njim neposredno sodeluje.

Komponenta- modularni del sistema z jasno definiranim naborom zahtevanih in predvidenih vmesnikov.

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

Vozlišče- računalniški vir, na katerem se artefakti nahajajo in po potrebi izvajajo.

Vedenjske entitete so namenjene opisovanju vedenja. Obstajata samo dve glavni vedenjski entiteti: stanje in dejanje.

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

Akcija- primitivni atomski izračun.

Stroj je paket, ki definira številne koncepte, potrebne za predstavitev vedenja modelirane entitete v obliki diskretnega prostora s končnim številom stanj in prehodov.

Klasifikator je deskriptor niza predmetov iste vrste.

Dodatno branje

• Fowler M. UML. Osnove, 3. izdaja
• Buch G., Rambo D., Jacobson I. Jezik UML. Navodila

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 sprejemajo ali prenašajo informacije v dani 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. Akterji so lahko tudi zunanji sistemi, v tem primeru je Kreditni sistem prikazan ravno kot akter - je zunanji glede na ATM sistem. 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 preveri, ali je na tem računu vsaj 20 $, in zahtevani znesek se odšteje z 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 zaporedja ponazarja zaporedje dejanj, ki izvajajo primer uporabe »Dvig denarja z računa« z uporabo specifičnega primera Joejeve stranke, ki je dvignila 20 USD. 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 model izgleda na fizični ravni. Prikazuje programske komponente vašega sistema 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č diagramov komponent, odvisno od števila podsistemov ali izvršljivih datotek. 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. Po drugi strani pa bo regionalni strežnik prek lokalnega omrežja 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 predlog grafikonov, ki so na voljo v Microsoft Excelu, lahko dobite jasno sliko podatkov v tabeli in brez nje

Iz knjige Computer 100. Starting with Windows Vista avtor Zozulya Yuri

Grafi Grafikoni se uporabljajo za prikaz tabelaričnih podatkov v grafični obliki, s čimer lahko bistveno izboljšamo preglednost informacij in prikažemo razmerje med različnimi parametri oziroma dinamiko njihovega spreminjanja. Za vstavljanje diagramov v Word uporabite orodja

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

Grafi Najbolj vizualna lastnost Excela je predstavitev rezultatov izračuna ali zbranih podatkov v obliki grafov (diagramov): včasih najbolj impresivne številke ne morejo prepričati tako, kot lahko celo preprosta grafika. Excel ima

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

Poglavje 8 Grafi Excel se pogosto uporablja za ustvarjanje 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. Grafikoni Poleg grafičnih datotek lahko v Wordove dokumente vstavljate grafikone. 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 zaznan bolje kot tabela. Če želite zgraditi 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 projekta. 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čnega tokokroga 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čnim okvirjem Žični okvir vsebuje glavo (zgornji del okvirja) in nogo (spodnji del okvirja).

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čni prikaz 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