Parodykite vieno objekto elgesį per jo gyvavimo laikotarpį, nuo objekto sukūrimo iki jo sunaikinimo. Kiekviena būsenos diagrama vaizduoja tam tikrą automatą.

Veiksmų planas

Skiltyje Aprašas sužinokite pagrindinį būsenos diagramos simbolių rinkinį, reikalingą norint skaityti diagramas.

Perskaitę kitus skyrius (Pavyzdys, Taikymas), galite patys išbandyti savo jėgas kurdami būsenų diagramas.

Pastabos (aprašas)

Čia yra pagrindinis simbolių rinkinys būsenų diagramos, būtinas norint perskaityti diagramą. Perskaitę kitus skyrius („Pavyzdys“, „Programa“) galėsite kurti būsenų diagramos savarankiškai!

Terminas	Vaizdas	apibūdinimas
Pradinis pseudostatas		Pradinė sistemos būsena
Perėjimas		Perėjimas reiškia perėjimą iš vienos būsenos į kitą.
valstybė		Nurodo sistemos atliekamus veiksmus (gali būti galimi variantai), o tai lemia rezultatus, kuriuos gali pastebėti veikėjai.
valstybė veiklos būsena		Sunkus precedento žingsnis gali būti pavaizduotas kitu precedentu. UML sąlygomis sakome, kad pirmasis naudojimo atvejis apima antrąjį.
Galutinė būsena		Leidžia apibrėžti sistemų ar posistemių ribas.
Vidinė veikla		Atvejis, kai valstybės gali reaguoti į įvykius nedarydami perėjimo, tokiu atveju įvykis, apsauga ir veikla patalpinti būsenos stačiakampio viduje.
Įvesties veikla		Įvesties veikla vykdoma kiekvieną kartą, kai įeinate į būseną
Išvesties veikla		Išvykimo veikla – vykdoma kaskart, kai išvykstate iš valstijos.
Supervalstybė		Dažnai atsitinka taip, kad kelios valstybės turi bendrų perėjimų ir vidinės veiklos. Tokiais atvejais jas galima paversti subbūsenomis, o bendrą elgesį perkelti į supervalstybę.
Lygiagrečios būsenos		Būsenas galima padalyti į kelias lygiagrečias būsenas, kurios veikia vienu metu.

Kaip panaudoti kūrybiškumo technikas

UML būsenos diagramos tinka apibūdinti vieno objekto elgseną keliais naudojimo atvejais. Bet jie nelabai tinka apibūdinti elgesį, kuriam būdinga daugelio objektų sąveika. Todėl prasminga naudoti kitas technologijas kartu su būsenos diagramomis. Pavyzdžiui, sąveikos diagramos (4 skyrius) puikiai apibūdina kelių objektų elgesį vienu atveju, o UML veiklos diagramos. yra tinkami norint parodyti pagrindinę kelių objektų veiksmų seką keliais naudojimo atvejais.

Ne visi būklės diagramas laiko natūraliomis. Stebėkite, kaip su jais dirba ekspertai. Gali būti, kad jūsų komandos nariai nemano, kad būsenos diagramos tinka jų darbo stiliui. Tai nėra didžiausias sunkumas; turite nepamiršti kartu naudoti skirtingus darbo metodus.

Jei naudojate būsenų diagramas, nemėginkite jų braižyti kiekvienai sistemos klasei. Šis metodas dažnai naudojamas siekiant formaliai griežto išsamumo, tačiau tai beveik visada yra pastangų švaistymas. Būsenos diagramas naudokite tik toms klasėms, kurios pasižymi įdomiu elgesiu, kur būsenos diagramos piešimas padeda suprasti, kaip viskas vyksta.

Daugelis ekspertų tuo įsitikinę UI redaktorius ir valdymo objektai turi funkcijų, kurios yra naudingos, kai rodomos naudojant būsenos diagramą.

Kaip išmokti

Čia mes stengėmės pateikti kuo paprastesnį mokymosi būdą UML būsenos diagramos.

Kaip ir daugelyje kitų kalbų, aprašymui naudojamas simbolių rinkinys. Šių ženklų reikšmę rasite skilties „Pastabos (aprašas)“ lentelėje. Kiekvienas ženklas turi savo pavadinimą (terminą) ir rašybą. Be to, kiekvienas terminas pateikiamas su trumpu paaiškinimu, kad būtų galima greitai suprasti pagrindinę jo esmę.

Toliau rekomenduojame eiti į skyrių „Pavyzdžiai“. būsenų diagramos išbandyti savo jėgas skaitant įvairias diagramas. Tada verta išstudijuoti skyrių „Taikymas“, nes, nors diagramų tipų skaičius UML yra mažas, galite gauti maksimalią naudą iš jų naudojimo tik tuo atveju, jei naudosite atitinkamas diagramas pagal paskirtį.

Naudojimo pavyzdys

Būsenos mašinų diagramos yra gerai žinoma sistemos elgsenos apibūdinimo technologija. Būsenos diagramos viena ar kita forma egzistuoja nuo 1960 m., o pirmaisiais objektinio programavimo laikais jos buvo naudojamos sistemos elgsenai pavaizduoti. Taikant į objektus orientuotus metodus, braižote vienos klasės būsenos diagramą, kad parodytumėte vieno objekto elgseną per visą jo gyvavimo laikotarpį.

Kai rašoma apie ribotos būklės aparatus, pavyzdžiais neišvengiamai yra pastovaus greičio palaikymo sistemos arba pardavimo automatai.
Gotikinėje pilyje nusprendėme panaudoti slaptą valdymo pulto valdiklį. Šioje pilyje norime paslėpti savo lobius, kad juos būtų sunku rasti. Norėdami prieiti prie seifo spynos, turime nuimti strateginę žvakę nuo žvakidės, tačiau spyna atsiras tik uždarius duris. Pasirodžius spynai galime įkišti į ją raktą ir atidaryti seifą. Dėl didesnio saugumo padarėme taip, kad seifą būtų galima atidaryti tik nuėmus žvakę. Jei vagis nekreips dėmesio į šią atsargumo priemonę, tada paleisime bjaurią pabaisą, kuri prarys vagį.

Fig. 10.1 parodyta būsenos diagrama valdiklio klasė, kuri valdo mano išgalvotą apsaugos sistemą. Būsenos diagrama prasideda nuo kuriamo valdiklio objekto būsenos: būsena Laukti. Tai diagramoje nurodoma pradinis pseudostatas, kuri nėra būsena, bet turi rodyklę, rodančią pradinę būseną.
Diagrama rodo, kad valdiklis gali būti vienoje iš trijų būsenų: Palaukite, užrakinkite ir atidarykite. Diagramoje taip pat parodytos taisyklės, pagal kurias valdiklis pereina iš vienos būsenos į kitą. Šios taisyklės pateikiamos perėjimų – linijų, jungiančių būsenas, pavidalu.

Perėjimas reiškia perėjimą iš vienos būsenos į kitą. Kiekvienas perėjimas turi savo etiketę, kurią sudaro trys dalys:
trigeris-parašas /veikla. Visi jie yra neprivalomi. Paprastai, trigerio ID yra vienintelis įvykis, galintis sukelti būsenos pasikeitimą.

Apsauga, jei nurodyta, yra logiška sąlyga, kuri turi būti įvykdyta, kad įvyktų perėjimas. Veikla yra tam tikras sistemos elgesys perėjimo metu. Tai gali būti bet kokia elgesio išraiška. Visa ID aktyviklio forma gali apimti kelis įvykius ir parametrus. Perėjimą iš laukimo būsenos (10.1 pav.) į kitą būseną galima perskaityti taip: „Laukimo būsenoje, jei žvakė nuimama, matote užraktą ir pereinate į užrakinimo būseną“.

Visos trys perėjimo aprašymo dalys yra neprivalomos. Veiklos praleidimas reiškia, kad perėjimo metu niekas nevyksta. Praleisti skydai reiškia, kad perėjimas visada atliekamas, jei įvyksta paleidimo įvykis. Trigerio ID retai trūksta, bet taip nutinka. Tai reiškia, kad perėjimas įvyksta iš karto, o tai daugiausia galima pastebėti aktyviose būsenose.

Kai įvykis įvyksta tam tikroje būsenoje, iš šios būsenos galima atlikti tik vieną perėjimą, pvz., Užrakinimo būsenoje (10.1 pav.), apsaugos turi būti viena kitą nesuderinamos. Jei įvykis įvyksta, bet nėra leidžiamų perėjimų, pavyzdžiui, uždarant seifą laukimo būsenoje arba nuimant žvakę, kai atidarytos durys, – įvykis ignoruojamas.

Galutinė būsena ( galutinė būsena) reiškia, kad būsenos mašina baigė veikti, todėl valdiklio objektas buvo ištrintas. Taigi tiems, kurie buvo pakankamai neatsargūs, kad pakliūtų į spąstus, kadangi valdiklio objektas nustoja egzistuoti, esame priversti grąžinti triušį į narvą, nušluostyti grindis ir iš naujo paleisti sistemą.

Atminkite, kad būsenos mašinos gali rodyti tik tuos objektus, kurie yra tiesiogiai stebimi arba veikiami. Taigi, nors galite tikėtis, kad ką nors įdėsime arba išimsime iš seifo, kai durys atidarytos, mes to nepažymėjome diagramoje, nes valdiklis negali mums nieko apie tai pasakyti.

Kai kūrėjai kalba apie objektus, jie dažnai nurodo objektų būseną, ty visų duomenų, esančių objektų laukuose, derinį. Tačiau būsena būsenos mašinos diagramoje yra abstraktesnė būsenos samprata; esmė ta, kad įvairios būsenos reiškia įvairių būdų reakcijos į įvykius.

Vidinė veikla būsenos diagramoje

Valstybės gali reaguoti į įvykius nedarant perėjimo naudodamos vidinė veikla (vidinė veikla), tokiu atveju įvykis, apsauga ir veikla patalpinti būsenos stačiakampio viduje.

Fig. 10.2 rodoma būsena su vidine simbolių veikla ir pagalbos sistemos įvykiais, kuriuos galite stebėti teksto laukelius redaktorius UI. Vidinė veikla yra tarsi savaiminis perėjimas – perėjimas, kuris grįžta į tą pačią būseną. Vidinės veiklos sintaksė kuriama pagal tą pačią loginę įvykių, apsaugos ir procedūrų schemą.

Fig. 10.2 taip pat rodo specialią veiklą: įvesties ir išvesties veikla. Įvesties veiklaįvykdomas, kai tik įeinate į būseną; išvesties veikla- kai tik išvykstate iš valstybės. Tačiau vidinė veikla nėra inicijuojama įvesties ir išvesties veikla; tai yra skirtumas tarp vidinė veikla irsavaiminiai perėjimai .

Veiklos būsenos būsenos diagramoje

Iki šiol aprašytose būsenose objektas tyli ir laukia kito įvykio, prieš ką nors darydamas. Tačiau galimos būsenos, kai objektas demonstruoja tam tikrą veiklą.

valstybė Ieškoma pav. 10.3 yra tokia būsena veiklos būsena: vykdoma veikla žymima simboliu daryti/; taigi terminas daryti veiklą (buk aktyvus). Baigus paiešką, perėjimai atliekami be veiklos, pvz., naujos įrangos rodymo (Rodyti naują aparatinę įrangą). Jei veiklos metu įvyksta atšaukimo įvykis ( atšaukti), tai daryti veiklą tiesiog pertraukia ir grįžtame į būseną Atnaujinkite aparatūros langą.

Ir veikla, ir įprasta veikla yra tam tikro elgesio apraiška. Esminis skirtumas tarp šių dviejų yra tas, kad įprasta veikla įvyksta „akimirksniu“ ir negali būti nutraukta įprastais įvykiais, o veikla gali trukti tam tikrą ribotą laiką ir gali būti nutraukta, kaip parodyta 1 paveiksle. 10.3. Momentiškumas skirtingoms sistemoms interpretuojamas skirtingai; realaus laiko sistemose tai gali užtrukti kelias kompiuterio instrukcijas, o darbalaukio programinei įrangai tai gali užtrukti kelias sekundes.

IN UML 1 terminu buvo nurodyta įprastinė veikla veiksmas(veiksmas) ir terminas veikla(veikla) ​​buvo naudojamas tik užsiimti veikla.

Supervalstybės

Dažnai atsitinka taip, kad kelios valstybės turi bendrų perėjimų ir vidinės veiklos. Tokiais atvejais jie gali būti paversti subbūsenomis, o bendras elgesys gali būti perkeltas į supervalstybę, kaip parodyta Fig. 10.4. Be supervalstybės turėtume nubrėžti perėjimą atšaukti(atšaukti) visoms trims būsenoms valstybėje Įveskite ryšio informaciją.

Lygiagrečios būsenos

Būsenas galima padalyti į kelias lygiagrečias būsenas, kurios veikia vienu metu. Fig. 10.5 paveiksle parodytas paprastas žadintuvas, kuris gali įjungti kompaktinį diską arba radiją ir rodyti esamą laiką arba žadintuvo laiką.

Kompaktinio disko/radijo ir esamo laiko/žadintuvo laiko parinktys yra lygiagrečios. Jei norėtumėte tai pavaizduoti naudodami nelygiagrečią būsenos diagramą, jums prireikus pridėti būsenų susidarytų netvarkinga diagrama. Atskyrus dvi elgesio sritis į dvi būsenų diagramas, tai tampa daug aiškiau.

Ryžiai. 10.5 taip pat apima priešistorės būsena(istorijos pseudostatas). Tai reiškia, kad įjungus laikrodį radijo/CD parinktis pereina į būseną, kurioje laikrodis buvo išjungus. Iš priešistorės išeinanti rodyklė rodo, kokia valstybė egzistavo iš pradžių, kai priešistorės nebuvo.

Būsenų diagramų įgyvendinimas

Būsenos diagrama gali būti įgyvendinta trimis pagrindiniais būdais: naudojant įdėtą jungiklio sakinį, būsenos šabloną ir būsenų lentelę. Tiesiausias būdas dirbti su būsenos diagramomis yra įdėtas jungiklio sakinys, pvz., Pav. 10.6.

Nors šis metodas yra paprastas, net ir šiuo paprastu atveju jis yra labai ilgas. Be to, taikant šį metodą labai lengva prarasti kontrolę, todėl nerekomenduojame jo naudoti net elementariose situacijose.
Būsenos modelis atspindi būsenų klasių hierarchiją, skirtą valdyti būseną. Kiekviena būsenos diagramos būsena turi savo būsenos poklasį. Valdiklis turi metodus kiekvienam įvykiui, kuris tiesiog persiunčia į būsenos klasę. Būsenos diagrama, parodyta pav. 10.1 galima įgyvendinti naudojant klases, pateiktas pav. 10.7.

Hierarchijos viršūnė yra abstrakti klasė, kurioje yra visų metodų, kurie apdoroja įvykius, tačiau neįgyvendinami, aprašymas.
Kiekvienai konkrečiai būsenai pakanka perrašyti tvarkyklės metodą konkrečiam įvykiui, kuris inicijuoja perėjimą iš būsenos.
Būsenos lentelė vaizduoja būsenos diagramą kaip duomenis.

Taigi, diagrama pav. 10.1 galima pateikti lentelės pavidalu. 10.1.
Tada sukuriame interpretatorių, kuris naudoja vykdymo laiko būsenų lentelę, arba kodo generatorių, kuris generuoja klases iš tos lentelės.

Akivaizdu, kad didžioji dalis darbo prie būsenos lentelės atliekama vieną kartą, tačiau vėliau ją galima naudoti, kai reikia išspręsti būsenos problemą. Vykdymo laiko būsenos lentelę galima modifikuoti be pakartotinio kompiliavimo, o tai yra šiek tiek patogu. Būsenos šabloną lengviau surinkti, ir nors kiekvienai būsenai reikia atskiros klasės, kodo kiekis, kurį reikia parašyti, yra gana mažas.

Parodytas įgyvendinimas yra beveik minimalus, tačiau jie suteikia idėją, kaip naudoti būsenų diagramos. Kiekvienu atveju įgyvendinant būsenos modelius susidaro gana stereotipinė programa, todėl dažniausiai tam pasiekti geriau griebtis kokios nors kodo generavimo formos.

Prenumeruokite svetainės naujienas; prenumeratos formą rasite dešiniajame svetainės stulpelyje.

Jei norite išmokti profesionaliai dirbti laisvai samdomu vertėju, kviečiame į „“ kursą.

        Vieningoji modeliavimo kalba (UML) yra specifikacijų, vizualizavimo, dizaino ir dokumentacijos kalba programinės įrangos sistemos, taip pat verslo modeliai ir kitos ne programinės įrangos sistemos. UML yra inžinerinių metodų, kurie anksčiau buvo sėkmingai naudojami didelėms ir sudėtingoms sistemoms modeliuoti, derinys

        UML kūrėjai pateikia ją kaip kalbą, skirtą programinės įrangos sistemoms, verslo sistemoms ir kitoms įvairaus pobūdžio sistemoms apibrėžti, reprezentuoti, projektuoti ir dokumentuoti. UML apibrėžia žymėjimą ir metamodelį. Žymėjimas yra grafinių objektų, naudojamų modeliuose, rinkinys; tai modeliavimo kalbos sintaksė.

        UML suteikia išraiškingų kūrimo įrankių vizualiniai modeliai, kuris:

• yra vienodai suprantami visiems projekte dalyvaujantiems kūrėjams;
• yra komunikacijos priemonė projekte.

        Vieningoji modeliavimo kalba (UML):

• nepriklauso nuo objektinio (OO) programavimo kalbų;
• nepriklauso nuo naudojamos projekto rengimo metodikos;
• gali palaikyti bet kurią OO programavimo kalbą.

        UML yra atvira ir turi įrankius pagrindiniam branduoliui išplėsti. UML gali būti naudojamas prasmingai apibūdinti klases, objektus ir komponentus įvairiose dalykinėse srityse, dažnai labai skiriasi viena nuo kitos.

UML diagramos

        „Rational Rose“ sistemos dizaineriui pateikia šių tipų diagramas, kurias nuosekliai kurdami galite susidaryti išsamų visos suprojektuotos sistemos ir atskirų jos komponentų vaizdą:

• Naudojimo atvejų schema;
• Išskleidimo diagrama (topologijos diagramos);
• Būsenos diagramos diagrama;
• Sąveikos diagrama; Veiklos diagrama;
• Sekos diagrama;
• Bendradarbiavimo schema;
• Klasių diagrama;
• Komponentų diagrama (komponentinės diagramos);
• Elgesio diagramos;
• Veiklos diagrama;
• Įgyvendinimo diagramos;

        Kiekvienoje iš šių diagramų pateikiamos skirtingos idėjos apie sistemos modelį. Tuo pačiu metu naudojimo atvejų diagrama parodo konceptualų sistemos modelį, kuris yra visų kitų diagramų kūrimo pradžios taškas. Klasių diagrama yra loginis modelis, atspindintis statinius sistemos struktūrinio dizaino aspektus, o elgesio diagramos, kurios taip pat yra loginio modelio rūšys, atspindi dinaminius jos veikimo aspektus. Diegimo diagramos skirtos sistemos komponentams pavaizduoti ir nurodyti jos fizinį modelį.

        Iš aukščiau išvardytų diagramų kai kurios skirtos dviem ar daugiau porūšių žymėti. Šios diagramos naudojamos kaip nepriklausomos reprezentacijos: naudojimo atvejai, klasės, būsenos, veiklos, sekos, bendradarbiavimas, komponentai ir diegimas.

        UML diagramose yra trijų tipų vaizdiniai simboliai, kurie yra svarbūs juose esančios informacijos požiūriu:

• komunikacijos, kurios plokštumoje pavaizduotos skirtingomis linijomis;
• tekstą, esantis atskirų geometrinių formų ribose;
• grafiniai simboliai, pavaizduotas šalia vaizdinių diagramų elementų.

        Grafiškai vaizduojant diagramas, rekomenduojama laikytis šių taisyklių:

• kiekviena diagrama turi visiškai atvaizduoti kokį nors modeliuojamos dalykinės srities fragmentą;
• diagramoje pateikti modelio subjektai turi būti to paties konceptualaus lygio;
• visa informacija apie subjektus turi būti aiškiai pateikta diagramoje;
• diagramose neturėtų būti prieštaringos informacijos;
• diagramos neturėtų būti perkrautos tekstine informacija;
• kiekviena diagrama turi būti savarankiška, kad būtų galima teisingai interpretuoti visus jos elementus;
• diagramų tipų skaičius, reikalingas konkrečiai sistemai apibūdinti, nėra griežtai fiksuotas ir yra nustatomas kūrėjo;
• sistemos modeliuose turi būti tik tie elementai, kurie yra apibrėžti UML žymėjime.

Subjektai UML

        UML apibrėžti keturių tipų objektai: struktūrinis, elgesio, grupavimas ir anotacija. Esybės yra pagrindiniai į objektą orientuoti kalbos, su kuria kuriami modeliai, elementai.

        Struktūriniai subjektai yra UML modelių daiktavardžiai. Paprastai jie vaizduoja statines modelio dalis, atitinkančias konceptualius arba fizinius sistemos elementus. Struktūrinių objektų pavyzdžiai yra „klasė“, „sąsaja“, „bendradarbiavimas“, „naudojimo atvejis“, „komponentas“, „mazgas“, „aktorius“.

        Elgesio subjektai yra dinamiški UML modelio komponentai. Tai veiksmažodžiai, apibūdinantys modelio elgesį laike ir erdvėje. Yra du pagrindiniai elgesio subjektų tipai:

• sąveika – tai elgesys, kurio esmė yra apsikeitimas žinutėmis tarp objektų konkrečiame kontekste siekiant konkretaus tikslo;
• automatas – elgesio algoritmas, apibrėžiantis būsenų seką, per kurią objektas ar sąveika praeina reaguodamas į įvairius įvykius.

        Subjektų grupavimas yra UML modelio organizacinės dalys. Tai yra blokai, į kuriuos galima išskaidyti modelį. Toks pirminis subjektas egzistuoja vienoje kopijoje - tai yra paketas.

        Paketai yra universalus elementų suskirstymo į grupes mechanizmas. Struktūrinius, elgesio ir kitus grupavimo objektus galima sudėti į paketą. Skirtingai nuo komponentų, kurie iš tikrųjų egzistuoja programai veikiant, paketai yra grynai konceptualaus pobūdžio, tai yra, jie egzistuoja tik kūrimo proceso metu.

        Anotacijos objektai- Tai yra aiškinamosios UML modelio dalys: komentarai papildomam aprašymui, paaiškinimui ar pastaboms apie bet kurį modelio elementą. Yra tik vienas pagrindinis tipas anotacijos elementai – pastaba. Pastabos naudojamos pateikiant diagramas su komentarais ar apribojimais, išreikštas neoficialiu ar oficialiu tekstu.

Santykiai UML

        UML kalba apibrėžiami šie ryšių tipai: priklausomybė, asociacija, apibendrinimas ir įgyvendinimas. Šie ryšiai yra pagrindinės UML jungiamosios konstrukcijos ir taip pat naudojami kaip modelių kūrimo objektai.

        Priklausomybė- tai semantinis ryšys tarp dviejų subjektų, kuriame vieno iš jų, nepriklausomo, pokytis gali paveikti kito, priklausomo, semantiką.

        asociacija- struktūrinis ryšys, apibūdinantis semantinių arba loginių ryšių tarp objektų rinkinį.

        Apibendrinimas yra ryšys, kuriame specializuoto elemento objektas (palikuonis) gali būti pakeistas bendruoju elemento objektu (protėviu). Tuo pačiu metu, pagal objektinio programavimo principus, palikuonis (vaikas) paveldi savo protėvio (tėvo) struktūrą ir elgesį.

        Realizacija yra semantinis ryšys tarp klasifikatorių, kai vienas klasifikatorius apibrėžia prievolę, o kitas garantuoja jos įvykdymą. Diegimo santykiai atsiranda dviem atvejais:

• tarp sąsajų ir jas įgyvendinančių klasių ar komponentų;
• tarp precedentų ir juos įgyvendinančio bendradarbiavimo.

Įprasti UML mechanizmai

        Norint tiksliai apibūdinti sistemą UML, naudojami vadinamieji bendrieji mechanizmai:

• specifikacijos;
• papildymai (papuošimai);
• bendri padaliniai;
• plėtiniai (išplečiamumo mechanizmai).

        UML yra ne tik grafinė kalba. Už kiekvieno grafinio elemento yra jo žymėjimas specifikacija, kuriame yra atitinkamos kalbos konstrukcijos tekstinis vaizdas. Pavyzdžiui, klasės piktograma turi specifikaciją, apibūdinančią jos atributus, operacijas ir elgesį, nors vizualiai, diagramoje, piktograma dažnai atspindi tik nedidelę šios informacijos dalį. Be to, modelyje gali būti kitoks šios klasės vaizdas, atspindintis visiškai skirtingus jos aspektus, tačiau vis dėlto atitinkantis specifikaciją. Taigi UML grafinis žymėjimas naudojamas sistemai vizualizuoti, o specifikacijomis aprašyti jos detales.

        Beveik kiekvienas UML elementas turi unikalų grafinį vaizdą, kuris vizualiai atvaizduoja svarbiausias jo charakteristikas. Esybės žymėjime „klasė“ yra jo pavadinimas, atributai ir operacijos. Klasės specifikacijoje gali būti kitų detalių, tokių kaip atributų ir operacijų matomumas, komentarai arba nuoroda, kad klasė yra abstrakti. Daugelis šių detalių gali būti vizualizuojamos kaip grafika arba tekstas. papildymaiį standartinį stačiakampį, kuris reiškia klasę.

        Modeliuojant į objektus orientuotas sistemas, yra padalinys atstovaujamų subjektų.

        Pirma, yra suskirstymas į klases ir objektus. Klasė yra abstrakcija, o objektas yra konkretus tos abstrakcijos įsikūnijimas. Šiuo atžvilgiu beveik visoms kalbos konstrukcijoms būdingas klasės/objekto dvilypumas. Taigi yra precedentų ir precedentų atvejų, komponentų ir komponentų, mazgų ir mazgų atvejų. Grafiniame pavaizdavime įprasta objektui naudoti tą patį simbolį kaip ir klasei, o pavadinimą pabraukti.

        Antra, yra skirstymas į sąsają ir jos įgyvendinimą. Sąsaja deklaruoja įsipareigojimus, o įgyvendinimas parodo konkretų tų įsipareigojimų įgyvendinimą ir užtikrina, kad būtų tiksliai laikomasi deklaruotos semantikos. Dėl šios priežasties beveik visoms UML konstrukcijoms būdingas sąsajos / įgyvendinimo dvilypumas. Pavyzdžiui, precedentai įgyvendinami bendradarbiaujant, o operacijos – metodais.

        UML yra atvira kalba, tai yra, ji leidžia valdomiems plėtiniams atspindėti domenų modelių ypatybes.

        UML plėtinių mechanizmai:

• stereotipai (stereotipas) - praplėsti UML žodyną, leidžiantį pagal esamus kalbos elementus kurti naujus, orientuotus į konkrečios problemos sprendimą;
• pažymėtos reikšmės - išplečia pagrindinių UML konstrukcijų savybes, leidžiančias į elemento specifikaciją įtraukti papildomos informacijos;
• apribojimai (apribojimai) – išplėskite UML konstrukcijų semantiką, leidžiančią kurti naujas ir atšaukti esamas taisykles.

        Kartu šie trys kalbos išplėtimo mechanizmai leidžia jį modifikuoti pagal projekto poreikius arba kūrimo technologijos ypatybes.

Naudojimo atvejo diagrama

        Šio tipo diagramos leidžia sudaryti sistemos atliekamų operacijų sąrašą. Dažnai tokio tipo diagramos vadinamos funkcijų diagrama, nes remiantis tokių diagramų rinkiniu sudaromas sistemos reikalavimų sąrašas ir nustatomas sistemos atliekamų funkcijų rinkinys.

        Naudojimo atvejų diagramos apibūdina sistemos funkcionalumą arba tai, ką sistema turėtų daryti. Diagramos kūrimas turi šiuos tikslus:

• nustatyti bendras modeliuojamos dalykinės srities ribas ir kontekstą;
• suformuluoti bendruosius projektuojamos sistemos funkcinės elgsenos reikalavimus;
• sukurti pradinį konceptualų sistemos modelį, kad vėliau būtų galima detalizuoti loginių ir fizinių modelių pavidalu;
• parengti pirminę dokumentaciją sistemos kūrėjų sąveikai su savo klientais ir vartotojais.

        Naudojimo atvejų diagramos esmė yra tokia. Kuriama sistema vaizduojama kaip subjektų arba veikėjų, kurie sąveikauja su sistema per naudojimo atvejus, rinkinys. Šiuo atveju veikėjas arba veikėjas yra bet koks subjektas, kuris sąveikauja su sistema iš išorės. Tai gali būti žmogus techninis prietaisas, programa ar bet kuri kita sistema, kuri gali tapti įtakos modeliuojamai sistemai, kaip nustato pats kūrėjas. Naudojimo atvejis padeda apibūdinti paslaugas, kurias sistema teikia veikėjui.

        Naudojimo atvejo tikslas yra apibrėžti išsamų kurio nors subjekto elgesio aspektą arba fragmentą, neatskleidžiant jo vidinės struktūros. Toks subjektas gali būti sistema arba bet koks modelio elementas, turintis savo elgesį.

        Kiekvienas naudojimo atvejis atitinka atskirą paslaugą, kurią modeliuojamas subjektas teikia veikėjo prašymu, tai yra, jis nustato, kaip šis objektas bus naudojamas. Paslauga, kuri inicijuojama veikėjo prašymu, yra išbaigta, nedaloma veiksmų seka. Tai reiškia, kad sistemai baigus apdoroti užklausą, ji turi grįžti į pradinė būsena būti pasirengę toliau nurodytiems prašymams

        Naudojimo atvejai gali būti naudojami norint nurodyti išorinius reikalavimus kuriamai sistemai ir nurodyti jau veikiančios sistemos funkcinę elgseną. esama sistema. Naudojimo atvejų visuma turėtų apibrėžti visus galimus numatomos sistemos elgsenos aspektus. Be to, naudojimo atvejai netiesiogiai nustato reikalavimus, kurie apibrėžia, kaip dalyviai turi sąveikauti su sistema, kad galėtų tinkamai teikti teikiamas paslaugas. Patogumui daugelis naudojimo atvejų gali būti traktuojami kaip atskira pakuotė.

        Naudojimo atvejų pavyzdžiais gali būti tokie veiksmai: kliento einamosios sąskaitos būklės patikrinimas, prekių pirkimo užsakymo pateikimas, papildomos informacijos apie kliento kreditingumą gavimas, grafinės formos atvaizdavimas monitoriaus ekrane ir kt. veiksmai.

klasės diagrama

        Pagrindinė objektinio programavimo vieta yra loginio sistemos modelio kūrimas klasių diagramos pavidalu. Klasių diagrama naudojama objektinio programavimo klasių terminologijoje sistemos modelio statinei struktūrai pavaizduoti. Klasių diagrama visų pirma gali atspindėti įvairius ryšius tarp atskirų domeno objektų, tokių kaip objektai ir posistemiai, taip pat aprašyti jų vidinę struktūrą ir ryšių tipus.

        Diagramos piktogramos leidžia rodyti sudėtingą sistemų hierarchiją, ryšius tarp klasių (klasių) ir sąsajų (sąsajos). Šio tipo diagramos turinys yra priešingas bendradarbiavimo diagramai, kurioje rodomi sistemos objektai. „Rational Rose“ leidžia kurti klases naudojant tokio tipo diagramas įvairiais žymėjimais. panašus į debesį. Taigi klasė yra tik šablonas, pagal kurį ateityje bus kuriamas konkretus objektas.

        Klasių diagrama yra grafikas, kurio viršūnės yra "klasifikatoriaus" tipo elementai, sujungti įvairių tipų struktūriniai santykiai. Klasių diagramoje taip pat gali būti sąsajų, paketų, ryšių ir net atskirų atvejų, tokių kaip objektai ir ryšiai.

        Klasė UML kalboje žymi objektų, turinčių tokią pačią struktūrą, elgesį ir ryšius su kitų klasių objektais, rinkinį. Grafiškai klasė vaizduojama kaip stačiakampis, kurį galima papildomai padalinti horizontalios linijosį skyrius ar skyrius. Šiose dalyse gali būti klasės pavadinimas, atributai (kintamieji) ir operacijos (metodai).

būsenos diagramos diagrama

        Kiekviena UML būsenų diagrama aprašo visas galimas tam tikros klasės vieno egzemplioriaus būsenas ir galimas jos perėjimų iš vienos būsenos į kitą sekas, ty modeliuoja visus objekto būsenų pokyčius kaip jo atsaką į išorinį veiksnį. įtakos.

        Būsenos diagramos dažniausiai naudojamos atskirų objektų elgsenai apibūdinti, bet gali būti naudojamos ir kitų modelio komponentų funkcionalumui nurodyti, pavyzdžiui, naudojimo atvejams, veikėjams, posistemėms, operacijoms ir metodams.

        Būsenos diagrama yra specialus grafiko tipas, vaizduojantis tam tikrą automatą. Grafo viršūnės yra galimos mašinos būsenos, pavaizduotos atitinkamais grafiniais simboliais, o lankai rodo jos perėjimus iš būsenos į būseną. Būsenos diagramos gali būti įdėtos, kad būtų galima pateikti išsamesnį atskirų modelio elementų vaizdą.

        UML metamodelyje mašina yra paketas, apibrėžiantis daugybę sąvokų, reikalingų modeliuojamo subjekto elgsenai pavaizduoti diskrečios erdvės su baigtiniu skaičiumi būsenų ir perėjimų pavidalu.

        Sistemos trukmė bet kurioje iš galimų būsenų gerokai viršija laiką, praleistą pereinant iš vienos būsenos į kitą. Daroma prielaida, kad riboje perėjimo laikas gali būti lygus nuliui (jei nenurodyta kitaip), tai yra, objekto būsenų pasikeitimas gali įvykti akimirksniu.

        Automato elgsena modeliuojama kaip nuoseklus judėjimas grafike nuo viršūnės iki viršūnės, atsižvelgiant į juos jungiančių lankų orientaciją.

        Įrenginiui turi būti įvykdytos šios privalomos sąlygos:

• būseną, į kurią gali patekti objektas, lemia tik dabartinė jo būsena ir nepriklauso nuo ankstesnės jo istorijos;
• Kiekvienu laiko momentu automatas gali būti tik vienoje iš savo būsenų. Tuo pačiu metu automatas gali likti atskiroje būsenoje tiek, kiek norima, jei neįvyksta jokių įvykių;
• laikas, per kurį mašina yra vienoje ar kitoje būsenoje, taip pat laikas, per kurį pasiekiama viena ar kita būsena, niekaip nenurodytas;
• automato būsenų skaičius turi būti baigtinis ir visos jos turi būti aiškiai nurodytos. Atskiros pseudobūsenos gali neturėti specifikacijų (pradinės ir galutinės būsenos). Šiuo atveju jų paskirtis ir semantika yra visiškai nulemta modelio ir nagrinėjamos būsenos diagramos konteksto;
• Automatiniame grafike neturėtų būti izoliuotų būsenų ir perėjimų. Kiekvienai būsenai, išskyrus pradinę, turi būti nustatyta ankstesnė būsena ir kiekvienas perėjimas turi sujungti dvi mašinos būsenas;
• automate neturėtų būti prieštaringų perėjimų, kai objektas vienu metu gali pereiti į dvi ar daugiau vėlesnių būsenų (išskyrus lygiagrečių subautomatų atvejį). UML konfliktų pašalinimas galimas įvedant apsaugos sąlygas.

valstybė yra esminis ne tik UML kalbos metamodelyje, bet ir taikomojoje sistemų analizėje. Visa dinaminės sistemos samprata remiasi valstybės samprata. Būsenos semantika UML kalboje turi keletą specifinių bruožų.

        UML būsena yra abstrakti metaklasė, naudojama konkrečiai situacijai, kurios metu tenkinamos tam tikros sąlygos, modeliuoti. Būseną galima nurodyti kaip konkrečių klasės ar objekto atributų reikšmių rinkinį. Atskirų atributų reikšmių pokyčiai atspindės modeliuojamos klasės ar objekto būsenos pokyčius.

Veiklos diagrama

        Modeliuojant kuriamos ar analizuojamos sistemos elgseną, atsiranda būtinybė ne tik pateikti jos būsenų keitimo procesą, bet ir detalizuoti sistemos atliekamų operacijų algoritminio ir loginio įgyvendinimo ypatumus.

        Tiesą sakant Šis tipas diagramos taip pat gali būti naudojamos modeliuojamo objekto būsenoms atspindėti, tačiau pagrindinis Veiklos diagramos tikslas yra atspindėti objekto verslo procesus. Šio tipo diagramos leidžia parodyti ne tik procesų seką, bet ir procesų išsišakojimą bei tolygų sinchronizavimą.

        Šio tipo diagramos leidžia kurti bet kokio sudėtingumo objektų veikimo algoritmus, taip pat gali būti naudojami blokinėms diagramoms sudaryti.

        Operacijų atlikimo procesui UML kalba modeliuoti naudojamos veiklos diagramos. Jose naudojamas grafinis žymėjimas daugeliu atžvilgių panašus į būsenos diagramos žymėjimą, nes šiose diagramose taip pat yra būsenos ir perėjimo simbolių. Kiekviena veiklos diagramos būsena atitinka tam tikros elementarios operacijos atlikimą, o perėjimas į kitą būseną įvyksta tik tada, kai ši operacija baigta.

        Taigi veiklos diagramos gali būti laikomos specialiu būsenų diagramų atveju. Jie leidžia UML kalboje įdiegti procedūrinio ir sinchroninio valdymo ypatybes dėl vidinių veiklų ir veiksmų atlikimo. Pagrindinis veiklos diagramų panaudojimas – vizualizuoti klasės operacijų įgyvendinimo ypatybes, kai reikia pateikti jų įgyvendinimo algoritmus.

        UML kalbos kontekste veikla yra automato atliekamų individualių skaičiavimų rinkinys, lemiantis tam tikrą rezultatą ar veiksmą. Veiklos diagramoje rodoma perėjimo iš vienos veiklos prie kitos logika ir seka, o analitiko dėmesys sutelkiamas į rezultatus. Veiklos rezultatas gali pasikeisti sistemos būsenoje arba grąžinti tam tikrą vertę.

        Veiksmo būsena yra ypatingas atvejis, kai būsena turi tam tikrą įvesties veiksmą ir bent vieną perėjimą paliekant būseną. Šis perėjimas netiesiogiai daro prielaidą, kad įvesties veiksmas jau baigtas. Veiksmo būsena negali turėti vidinių perėjimų, nes ji yra elementari. Įprasta veiksmo būsena yra modeliuoti vieną žingsnį vykdant algoritmą (procedūrą) arba valdymo srautą.

Sekos diagrama

        Nagrinėjant būsenos ir veiklos diagramas, buvo pastebėta, kad nors šios diagramos naudojamos sistemos elgsenos dinamikai nurodyti, laikas jose nėra aiškiai nurodytas. Laikinasis elgesio aspektas gali būti reikšmingas modeliuojant sinchroninius procesus, apibūdinančius objektų sąveiką. Norėdami modeliuoti objektų sąveiką laikui bėgant, UML naudoja sekos diagramas.

        Tik tie objektų, kurios tiesiogiai dalyvauja sąveikoje. Esminis dalykas sekos diagramoms yra objektų sąveikos dinamika laikui bėgant.

        UML sekos diagrama turi du matmenis. Pirmasis yra iš kairės į dešinę vertikalių linijų pavidalu, kurių kiekviena vaizduoja atskiro objekto, dalyvaujančio sąveikoje, gyvenimo liniją. Diagramos kairėje pusėje esantis objektas yra tas, kuris inicijuoja sąveiką. Dešinėje yra kitas objektas, kuris tiesiogiai sąveikauja su pirmuoju. Taigi, visi objektai sekos diagramoje sudaro tam tikrą tvarką, kurią lemia objektų eiliškumas arba aktyvumo laipsnis, kai jie sąveikauja vienas su kitu.

        Grafiškai kiekvienas objektas vaizduojamas kaip stačiakampis ir yra viršutinėje jo gyvybės linijos dalyje. Stačiakampio viduje parašykite objekto pavadinimą ir klasės pavadinimą, atskirtą dvitaškiu. Šiuo atveju akcentuojamas visas įrašas, kuris yra objekto ženklas.

        Antrasis sekos diagramos matmuo yra vertikali laiko ašis, nukreipta iš viršaus į apačią. Viršutinė diagramos dalis atitinka pradinį laiko momentą. Objektų sąveika įgyvendinama per pranešimus, kuriuos vienas objektas siunčia kitam. Pranešimai vaizduojami kaip horizontalios rodyklės su pranešimo pavadinimu, o jų eiliškumas nustatomas pagal atsiradimo laiką. Tai reiškia, kad pranešimai, esantys aukščiau sekos diagramoje, inicijuojami anksčiau nei tie, kurie yra žemiau. Laiko ašies skalė nenurodyta, nes sekos diagrama modeliuoja tik „anksčiau-vėliau“ sąveikų laikinį išdėstymą.

Bendradarbiavimo schema

        Pagrindinis bruožas bendradarbiavimo diagramos – tai galimybė grafiškai pavaizduoti ne tik sąveikos seką, bet ir visus struktūrinius ryšius tarp šioje sąveikoje dalyvaujančių objektų.

        Šio tipo diagramos leidžia apibūdinti objektų sąveiką, abstrahuojantis nuo pranešimų perdavimo sekos. Šio tipo diagramos kompaktiškai parodo visus gautus ir perduotus konkretaus objekto pranešimus ir šių pranešimų tipus.

        Visų pirma, bendradarbiavimo diagramoje sąveikoje dalyvaujantys objektai pavaizduoti stačiakampių pavidalu, kuriuose yra objekto pavadinimas, jo klasė ir, galbūt, atributų reikšmės. Be to, kaip ir klasių diagramoje, asociacijos tarp objektų nurodomos įvairių jungiamųjų linijų pavidalu. Tokiu atveju galite aiškiai nurodyti asociacijos pavadinimus ir vaidmenis, kuriuos objektai atlieka šioje asociacijoje. Papildomai galima pavaizduoti dinaminius ryšius – pranešimų srautus. Jie taip pat vaizduojami kaip jungiamosios linijos tarp objektų, virš kurių yra rodyklė, nurodanti kryptį, pranešimo pavadinimą ir eilės numerį bendroje pranešimų inicijavimo sekoje.

        Skirtingai nuo sekos diagramos, bendradarbiavimo diagrama vaizduoja tik ryšius tarp objektų, kurie sąveikoje atlieka tam tikrus vaidmenis. Šioje diagramoje laikas nerodomas kaip atskiras matmuo. Todėl sąveikų ir lygiagrečių srautų seką galima nustatyti naudojant eilės numerius. Todėl, jei reikia aiškiai nurodyti ryšius tarp objektų realiuoju laiku, geriau tai padaryti sekos diagramoje.

        Koncepcija bendradarbiavimą yra viena iš pagrindinių UML kalbos sąvokų. Jis skirtas objektų, sąveikaujančių su konkrečiu tikslu bendrame modeliuojamos sistemos kontekste, rinkiniui. Paties bendradarbiavimo tikslas – nurodyti atskirų reikšmingiausių sistemos operacijų įgyvendinimo ypatumus. Bendradarbiavimas apibrėžia sistemos elgesio struktūrą šio bendradarbiavimo dalyvių sąveikos požiūriu.

        Bendradarbiavimas gali būti atstovaujamas dviem lygiais:

• specifikacijos lygis – parodo klasifikatorių ir asociacijų vaidmenis nagrinėjamoje sąveikoje;
• pavyzdžio lygis – nurodo atvejus ir ryšius, kurie bendradarbiaujant sudaro atskirus vaidmenis.

        Specifikacijos lygio bendradarbiavimo diagrama parodo sąveikoje dalyvaujančių elementų vaidmenis. Šio lygmens bendradarbiavimo elementai yra klasės ir asociacijos, kurios žymi individualius klasifikatorių vaidmenis ir asociacijas tarp bendradarbiavimo dalyvių.

        Pavyzdžio lygmens bendradarbiavimo diagramą vaizduoja objektų (klasių egzempliorių) ir jungčių (asociacijų atvejų) rinkinys. Šiuo atveju jungtys papildytos pranešimų rodyklėmis. Šiame lygyje rodomi tik tie objektai, kurie yra tiesiogiai susiję su operacijos ar klasifikatoriaus įgyvendinimu. Šiuo atveju visai nebūtina vaizduoti visų savybių ar visų asociacijų, nes bendradarbiavimo diagramoje pateikiami tik klasifikatorių vaidmenys, bet ne patys klasifikatoriai. Taigi, nors klasifikatorius reikalauja išsamaus visų jo atvejų aprašymo, klasifikatoriaus vaidmuo reikalauja aprašyti tik tas savybes ir asociacijas, kurios yra būtinos norint dalyvauti konkrečiame bendradarbiavime.

        Iš to išplaukia svarbi pasekmė. Tas pats objektų rinkinys gali dalyvauti skirtinguose bendradarbiavimuose. Priklausomai nuo nagrinėjamo bendradarbiavimo, gali keistis tiek atskirų objektų savybės, tiek ryšiai tarp jų. Tuo bendradarbiavimo diagrama skiriasi nuo klasių diagramos, kurioje turi būti nurodytos visos diagramos elementų savybės ir sąsajos.

Komponentų diagrama

        Šio tipo diagramos yra skirtos klasėms ir objektams paskirstyti tarp komponentų fizinio sistemos projektavimo metu. Tokio tipo diagramos dažnai vadinamos modulių diagramomis.

        Visas programinės įrangos sistemos projektas – tai loginių ir fizinius lygius, kurios turi derėti viena su kita. UML kalba naudoja diegimo diagramas, kad fiziškai pavaizduotų sistemos modelius, įskaitant komponentų diagrama Ir išdėstymo schema.

        Komponentų diagrama, skirtingai nei anksčiau aptartos diagramos, apibūdina fizinio sistemos vaizdavimo ypatybes. Tai leidžia nustatyti kuriamos sistemos architektūrą nustatant priklausomybes tarp programinės įrangos komponentų, kurie gali būti šaltinio ir vykdomojo kodo. Pagrindiniai komponentų diagramos grafiniai elementai yra komponentai, sąsajos ir priklausomybės tarp jų.

        Komponentų diagrama sukurta šiems tikslams:

• vizualizacija bendra struktūra pirminis kodas programinės įrangos sistema;
• vykdomosios programinės įrangos sistemos versijos specifikacijos;
• užtikrinti pakartotinį atskirų fragmentų panaudojimą programos kodas;
• konceptualių ir fizinių duomenų bazių schemų atvaizdavimas.

        Kuriant komponentų diagramas dalyvauja tiek sistemų analitikai, tiek architektai, tiek programuotojai. Komponentų diagrama suteikia nuoseklų perėjimą nuo loginio vaizdavimo prie konkretaus projekto įgyvendinimo programinės įrangos kodo forma. Kai kurie komponentai gali egzistuoti tik programos kodo kompiliavimo etape, kiti – jo vykdymo etape. Komponentų diagrama atspindi bendras priklausomybes tarp komponentų, o pastarieji laikomi klasifikatoriais.

        Fiziniams objektams pavaizduoti UML kalba naudojamas specialus terminas - komponentas. Komponentas įgyvendina tam tikrą sąsajų rinkinį ir paprastai nurodo fizinio modelio vaizdavimo elementus. Jis naudojamas komponento grafiniam vaizdui ypatingas personažas- stačiakampis su dviem mažesniais stačiakampiais, įterptais kairėje. Didelio stačiakampio viduje parašytas komponento pavadinimas ir, jei reikia, kai kurie Papildoma informacija. Šio simbolio išvaizda gali šiek tiek skirtis priklausomai nuo su komponentu susijusios informacijos pobūdžio.

Dislokavimo schema

        Šio tipo diagramos skirtos sistemos techninei įrangai, ty techninei įrangai, o ne programoms analizuoti. Tiesiogiai išvertus iš anglų kalbos, diegimas reiškia „diegimas“, tačiau terminas „topologija“ tiksliau atspindi tokio tipo diagramos esmę.

        Fizinis programinės įrangos sistemos vaizdas negali būti išsamus, jei nėra informacijos apie tai, kokia platforma ir kokiomis skaičiavimo priemonėmis ji įdiegta. Jei kuriate programą, kuri veikia vietoje vartotojo kompiuteryje ir nenaudoja Išoriniai įrenginiai ir išteklių, nereikia kurti papildomų diagramų. Kuriant korporacines programas, tokių diagramų buvimas gali būti itin naudingas sprendžiant racionalaus komponentų išdėstymo problemas, siekiant efektyviai išnaudoti paskirstytus tinklo skaičiavimo ir ryšio išteklius, užtikrinti saugumą ir kt.

        Diegimo diagramos naudojamos bendrai paskirstytos programinės įrangos sistemos konfigūracijai ir topologijai UML pavaizduoti.

        Diegimo diagrama skirta vizualizuoti programos elementus ir komponentus, kurie egzistuoja tik vykdymo etape. Šiuo atveju pateikiami tik programos egzempliorių komponentai, kurie yra vykdomieji failai arba dinaminės bibliotekos. Tie komponentai, kurie nenaudojami vykdymo metu, nerodomi diegimo diagramoje. Taigi komponentai su programos šaltinio kodais gali būti tik komponentų diagramoje. Jie nėra nurodyti išdėstymo schemoje.

        Diegimo diagramoje yra grafiniai vaizdai procesorius, įrenginius, procesus ir ryšius tarp jų. Skirtingai nuo loginio vaizdavimo diagramų, diegimo diagrama yra vienoda visai sistemai, nes ji turi visiškai atspindėti jos įgyvendinimo ypatybes. Diegimo diagramos kūrimas paprastai yra paskutinis žingsnis nurodant programinės įrangos sistemos modelį.

        Kuriant diegimo schemą, siekiama šių tikslų:

• nustatyti sistemos komponentų pasiskirstymą fiziniuose jos mazguose;
• parodyti fizinius ryšius tarp visų sistemos diegimo mazgų jos vykdymo etape;
• nustatyti sistemos kliūtis ir perkonfigūruoti jos topologiją, kad būtų pasiektas reikiamas našumas.

        Diegimo diagramas kartu kuria sistemų analitikai, tinklo inžinieriai ir sistemų technikai.

„Rational Rose“ darbo sąsajos ypatybės

        „Rational Rose CASE“ įrankis įgyvendina visuotinai priimtus programos veikimo sąsajos standartus, panašius į gerai žinomas vizualinio programavimo aplinkas. Vartotojo kompiuteryje įdiegus Rational Rose, kuri praktiškai nesukelia sunkumų net pradedantiesiems, paleidus šią programą MS Windows 95/98, ekrane atsiranda veikianti sąsaja (6 pav.).

Paveikslas – 6. Bendras Rational Rose programos darbo sąsajos vaizdas

        „Rational Rose“ operacinė sąsaja susideda iš įvairių elementų, iš kurių pagrindiniai yra:

• Pagrindinis programos meniu
• Diagramos langas
• Dokumentacijos langas
• Naršyklės langas
• Žurnalo langas

Trumpai apsvarstykime kiekvieno iš šių elementų paskirtį ir pagrindines funkcijas.

Pagrindinis programos meniu

Pagrindinis programos meniu yra pagamintas pagal visuotinai priimtą standartą ir atrodo taip (7 pav.).

Atskiri meniu punktai, kurių paskirtis aišku iš jų pavadinimų, sujungia panašias operacijas, susijusias su visu projektu kaip visuma. Kai kuriuose meniu punktuose yra gerai žinomų funkcijų (projekto atidarymas, diagramų spausdinimas, įvairių diagramos elementų kopijavimas ir įklijavimas iš mainų srities). Kiti yra tokie specifiniai, kad juos tiriant gali prireikti papildomų pastangų (kodo generavimo galimybės, modelio nuoseklumo tikrinimas, papildomų modulių prijungimas).

Paveikslas – 7. Išvaizda pagrindinis programos meniu

Standartinė įrankių juosta

Standartinė įrankių juosta yra po pagrindiniu programos meniu ir atrodo taip (8 pav.). Kai kurių įrankių nėra (naujame projekte nėra elementų). Standartinė įrankių juosta suteikia greitą prieigą prie meniu komandų, kurias kūrėjai naudoja dažniausiai.

Paveikslas – 8. Standartinės įrankių juostos išvaizda

Vartotojas gali pritaikyti šio skydelio išvaizdą savo nuožiūra. Norėdami tai padaryti, pasirinkite meniu punktą Įrankiai -> Parinktys ir atidarykite skirtuką Įrankių juostos. Tokiu būdu galite rodyti arba paslėpti įvairius įrankių mygtukus ir keisti jų dydį.

Naršyklės langas

Numatytasis naršyklės langas yra kairėje darbo sąsajos pusėje po standartine įrankių juosta (9 pav.).

Naršyklė modelio rodinius tvarko hierarchine struktūra, kuri supaprastina naršymą ir leidžia projekte rasti bet kurį modelio elementą. Tokiu atveju bet koks elementas, kurį kūrėjas prideda prie modelio, iš karto rodomas naršyklės lange. Atitinkamai, naršyklės lange pasirinkę elementą, galime jį vizualizuoti diagramos lange arba pakeisti jo specifikaciją. Naršyklė taip pat leidžia suskirstyti modelio elementus į paketus ir perkelti elementus tarp skirtingų modelio vaizdų. Jei pageidaujama, naršyklės langas gali būti kitoje darbo sąsajos vietoje arba visiškai paslėptas naudojant meniu elementą View. Taip pat galite pakeisti naršyklės dydį pele vilkdami jos išorinį rėmelį.

Paveikslas – 9. Naršyklės išvaizda

Speciali įrankių juosta

Speciali įrankių juosta yra tarp naršyklės lango ir diagramos lango vidurinėje darbo sąsajos dalyje. Pagal numatytuosius nustatymus modelio klasių diagramai sudaryti siūloma įrankių juosta (10 pav.).

Paveikslas – 10. Specialios įrankių juostos, skirtos klasių diagramai, išvaizda

Specialios įrankių juostos vietą galima pakeisti perkeliant skydelio rėmą į norimą vietą. Taip pat galite tinkinti skydelio sudėtį pridėdami arba pašalindami atskirus mygtukus, atitinkančius tam tikrus įrankius. Mygtukų priskyrimas gali būti išmoktas iš įrankių patarimų, kurie atsiranda pelės žymekliui užvedus ant atitinkamo mygtuko.

Diagramos langas

Diagramos langas yra pagrindinė jo sąsajos darbo sritis, kurioje vizualizuojami įvairūs projekto modelio vaizdai. Pagal numatytuosius nustatymus diagramos langas yra dešinėje darbo sąsajos pusėje, tačiau taip pat galima keisti jo vietą ir dydį. Kuriant naują projektą, jei projekto vedlys nebuvo naudojamas, diagramos langas yra tuščia sritis, kurioje nėra modelio elementų (11 pav.).

Diagramos, esančios šiame lange, pavadinimas nurodomas programos pavadinimo juostoje (viršutinėje programos eilutėje) arba, jei langas nėra padidintas iki viso ekrano, diagramos lango pavadinimo juostoje. Diagramos lange vienu metu gali būti kelios diagramos, tačiau tik viena iš jų gali būti aktyvi. Pavyzdžiui, pav. 11 aktyvi diagrama yra diegimo diagrama, nors yra ir kitų diagramų. Perjungti diagramas galima pasirinkus norimą vaizdą standartinėje įrankių juostoje arba per meniu elementą Langas. Kai suaktyvinate atskirą diagramos rodinį, pasikeičia specialios įrankių juostos išvaizda, kuri yra pritaikyta konkrečiam diagramos rodiniui.

Paveikslas – 11. Diagramos lango išvaizda su skirtingų tipų modelių rodiniais

Dokumentacijos langas

Pagal numatytuosius nustatymus dokumentacijos langas ekrane gali nebūti. Tokiu atveju jį galima suaktyvinti per meniu punktą View -> Documentation, po kurio jis atsiras po naršykle (12 pav.).

Dokumentacijos langas, kaip rodo jo pavadinimas, yra skirtas dokumentuoti modelio rodinio elementus. Į jį galima įrašyti įvairiausią informaciją, o kas svarbu – rusų kalba. Ši informacija vėliau paverčiama komentarais ir jokiu būdu neturi įtakos programos kodo vykdymo logikai.

Dokumentacijos lange suaktyvinama informacija, susijusi su atskiru pasirinktu diagramos elementu. Tokiu atveju elementą galite pasirinkti naršyklės lange arba diagramos lange. Kai į diagramą įtraukiate naują elementą (pavyzdžiui, klasę), automatiškai sugeneruojama jo dokumentacija, kuri yra tuščia (Dokumentacijos nėra). Vėliau kūrėjas savarankiškai įveda reikiamą aiškinamąją informaciją, kuri įsimenama ir gali būti pakeista dirbant su projektu.

Kaip ir kituose darbinės sąsajos languose, galite keisti dokumentacijos lango dydį ir padėtį.

Paveikslas – 12. Dokumentacijos lango išvaizda

Žurnalo langas

Žurnalo langas skirtas automatiškai įrašyti įvairią paslaugų informaciją, sugeneruotą dirbant su programa. Žurnale įrašomas kūrėjo atliekamų veiksmų laikas ir pobūdis, pvz., modelio atnaujinimas, meniu ir įrankių juostų tinkinimas, taip pat klaidų pranešimai, atsirandantys generuojant kodą.

Žurnalo langas visada yra darbinėje sąsajoje diagramos lango srityje (13 pav.). Tačiau jis gali būti paslėptas kituose diagramų languose arba sumažintas. Žurnalo langą galite suaktyvinti per meniu Langas->Žurnalas. Tokiu atveju jis rodomas virš kitų langų dešinėje darbo sąsajos srityje. Šio lango negalima visiškai pašalinti, jį galima tik sumažinti.

Paveikslas – 13. Rąsto lango išvaizda

Išvada

        Laikui bėgant UML kalba taps „esperanto“, kuria galės bendrauti matematikai, sistemų analitikai, fizikai, programuotojai, vadybininkai, ekonomistai ir kitų profesijų specialistai, vieninga forma pateikdami savo profesines žinias. Juk iš esmės kiekvienas iš specialistų savo žinių srityje operuoja su pavyzdinėmis reprezentacijomis. Ir būtent šis modelio aspektas gali būti nurodytas naudojant UML kalbą.

        Šiuo atžvilgiu UML kalbos svarba labai didėja, nes ji vis labiau įgyja žinių vaizdavimo kalbos bruožus. Tuo pačiu metu UML kalboje pateikiamos vaizdinės priemonės, skirtos modelio struktūrai ir elgesiui atvaizduoti, leidžia pasiekti tinkamą deklaratyviųjų ir procedūrinių žinių atvaizdavimą ir, ne mažiau svarbu, nustatyti semantinį atitikimą tarp šių formų. žinių. Visos šios UML kalbos savybės leidžia daryti išvadą, kad artimiausioje ateityje ji turi rimčiausių perspektyvų.

Šiame straipsnyje nagrinėjama nauja programinės įrangos kūrimo era, kaip ji veikia naujus UML reikalavimus ir geriausia jų vykdymo praktika.
  7. „Rational Rose duomenų modeliavimas“ Sergejus Trofimovas aprašo fizinio duomenų atvaizdavimo modeliavimą naudojant „Rational Rose“
  8. UML kalba. Bendras UML kalbos supratimas: struktūros, grafiniai elementai ir kalbų diagramos.
  9. Praktinis UML. Šis dokumentas yra dokumento „Praktinis UML. Praktinis įvadas kūrėjams“ vertimas. Praktinis įvadas kūrėjams
  10. „Standartinė objektinio modeliavimo kalba UML“ Vendrovas Aleksandras Michailovičius. UML istorija
  11. UML – vieninga modeliavimo kalba. Šioje medžiagoje pateikiama pradinė informacija apie programinės įrangos sistemų apibūdinimo metodus ir UML naudojamus žymėjimus
  12. UML kalba. Naudotojo gidas. Autoriai: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. „UML diagramos racionalioje rožėje“ Sergejus Trofimovas
  14. "Analizė ir dizainas. Vizualus modeliavimas (UML) Rational Rose" Konstantinas Domolego
  15. Genadijaus Vernikovo biblioteka. Išsamūs projektavimo ir modeliavimo standartų aprašymai.
  16. „Pavyzdys, kaip aprašoma dalykinė sritis naudojant UML kuriant programinės įrangos sistemas“ E.B. Zolotuchina, R.V. Alfimovas. Straipsnyje naudojamas konkretus pavyzdys, norint parodyti galimą domeno modeliavimo metodą, pagrįstą vieningos modeliavimo kalbos (UML) naudojimu.

UML arba Unified Modeling Language yra grafinio aprašymo kalba, skirta objektų modeliavimui programinės įrangos kūrimo srityje. Tačiau UML naudojimas neapsiriboja IT; kita didelė praktinio UML taikymo sritis yra verslo procesų modeliavimas, sistemų projektavimas ir organizacinių struktūrų sudarymas. UML leidžia programinės įrangos kūrėjams susitarti dėl grafinių vaizdavimo ženklų bendrosios sąvokos ir sutelkti dėmesį į dizainą ir plėtrą.

UML privalumai

• UML naudoja grafinius modeliuojamos sistemos elementų žymėjimus, o UML diagramas gana lengva suprasti;
• UML leidžia apibūdinti sistemas beveik visais įmanomais požiūriais, atsižvelgiant į įvairius aspektus;
• UML yra orientuotas į objektą: jo analizės ir konstravimo metodai semantiškai artimi programavimo metodams, naudojamiems šiuolaikinėse OOP kalbose;
• UML yra atviras standartas. Standartas tobulinamas ir tobulinamas nuo versijos iki versijos, atitinkantis moderniausius sistemų aprašymo reikalavimus;
• yra išplėtimo mechanizmas, leidžiantis įvesti papildomus teksto ir grafinius tipus, todėl UML galima naudoti ne tik IT srityje.

UML diagramų tipai

UML yra 14 tipų diagramų. Juos galima suskirstyti į 2 kategorijas:

• struktūrinės, reprezentuojanti informacijos struktūrą;
• elgesio, reprezentuojantis sistemos elgesį ir įvairius sąveikos aspektus. Nagrinėjamas atskiras elgesio diagramų potipis sąveikos diagramos.

UML diagramų tipų hierarchija,
pavaizduota klasių diagrama

Struktūrinės diagramos

1. Klasės diagrama yra pagrindinis objektinio modeliavimo elementas. Naudojant šią diagramą (iš tikrųjų, per klases, jų atributai, metodus ir priklausomybės tarp klasių) aprašo srities modelį ir modeliuojamos sistemos struktūrą.
2. Komponentų diagrama rodo programos kodo suskirstymą į didelius blokus (struktūrinius komponentus) ir parodo priklausomybės tarp jų. Komponentai gali būti paketai, moduliai, bibliotekos, failai ir kt.
3. Objekto schema rodo visą arba dalinę modeliuojamos sistemos dalį tam tikru momentu. Tai reiškia klasių egzempliorius (objektus), jų būseną (dabartinės atributų reikšmės) ir ryšius tarp jų.
4. Sudėtinės struktūros diagrama parodo vidinę klasių struktūrą ir, kur įmanoma, sąveiką tarp šios struktūros elementų.
5. Pakuotės schema rodo paketus ir santykius tarp jų. Šio tipo diagramos padeda supaprastinti modelio struktūrą (ir atitinkamai dirbti su ja), sujungiant modelio elementus į grupes pagal tam tikrus kriterijus.
6. Dislokavimo schema imituoja diegimą programinės įrangos komponentai ov ( artefaktai) dėl skaičiavimo išteklių / aparatinės įrangos komponentų ( mazgai).
7. Profilio schema aprašomas išplėtimo mechanizmas, leidžiantis UML pritaikyti įvairioms dalykinėms sritims ir pramonės šakoms.

UML klasės diagramos pavyzdys

Elgesio diagramos

1. Veiklos diagrama rodo veiksmus ( veiksmai) iš kurių susideda tam tikra veikla ( veikla). Veiklos diagramos naudojamos verslo procesams, technologiniams procesams, nuosekliajam ir lygiagrečiam skaičiavimui modeliuoti.
2. Naudojimo atvejo diagrama(arba naudojimo atvejo diagrama) aprašo veikėjų (aktorių) ryšį ir modeliuojamos sistemos (jos galimybių) panaudojimo atvejus. Pagrindinė diagramos paskirtis – būti universaliu įrankiu klientams, kūrėjams ir galutiniams vartotojams bendrai aptarti sistemą – jos galimybes ir elgesį.
3. Būsenos diagrama vaizduoja dinamišką esybės elgesį, parodydamas, kaip ši esybė, priklausomai nuo esamos būsenos, reaguoja į įvairius įvykius. Iš esmės tai yra atomų teorijos būsenos diagrama.
4. Ryšio schema(V ankstesnes versijas bendradarbiavimo diagrama) parodo sudėtinės struktūros dalių sąveiką ir bendradarbiavimo vaidmenis. Diagrama aiškiai nurodo ryšius tarp elementų (objektų).
5. Sekos diagrama naudojamas objektų sąveikų sekai vizualizuoti. Rodo tam tikro objekto gyvavimo ciklą ir veikėjų (aktorių) sąveiką tam tikru naudojimo atveju, pranešimų, kuriais jie keičiasi, seką.
6. Sąveikos apžvalgos diagrama apima sekų diagramos dalį ir valdymo srauto projektą. Padeda nagrinėti objektų sąveiką skirtingais požiūriais.
7. Laiko diagrama- atskiras sąveikos diagramų potipis, kurio specializacija yra laiko nustatymas. Šio tipo diagramos naudojamos objektų elgsenai per tam tikrą laikotarpį tirti.

UML yra vieninga grafinio modeliavimo kalba, skirta OO sistemoms aprašyti, vizualizuoti, projektuoti ir dokumentuoti. UML skirtas palaikyti programinės įrangos modeliavimo procesą, pagrįstą OO metodu, organizuoti konceptualių ir programinių koncepcijų ryšį ir atspindėti sudėtingų sistemų mastelio keitimo problemas. UML modeliai naudojami visuose programinės įrangos gyvavimo ciklo etapuose – nuo ​​verslo analizės iki sistemos priežiūros. Įvairios organizacijos gali naudoti UML, kaip joms atrodo tinkama, priklausomai nuo probleminių sričių ir naudojamų technologijų.

Trumpa UML istorija

Iki 90-ųjų vidurio įvairūs autoriai pasiūlė kelias dešimtis OO modeliavimo metodų, kurių kiekvienas naudojo savo grafinį žymėjimą. Tuo pačiu metu bet kuris iš šių metodų turėjo savo stipriąsias puses, tačiau neleido sukurti pakankamai išsamaus PS modelio, rodančio jį „iš visų pusių“, tai yra, visas būtinas projekcijas (žr. 1 straipsnį). Be to, dėl OO modeliavimo standarto nebuvimo kūrėjams buvo sunku pasirinkti tinkamiausią metodą, o tai neleido plačiai taikyti OO metodo programinės įrangos kūrime.

Objektų valdymo grupės (OMG), organizacijos, atsakingos už standartų priėmimą objektų technologijų ir duomenų bazių srityje, prašymu, aktualią suvienodinimo ir standartizavimo problemą išsprendė trijų populiariausių OO metodų autoriai – G. Butch, D. Rambo ir A. Jacobson, kurie kartu sukūrė UML 1.1 versiją, kurią OMG patvirtino 1997 m. kaip standartą.

UML yra kalba

Bet kurią kalbą sudaro žodynas ir žodžių derinimo taisyklės, siekiant sukurti prasmingas konstrukcijas. Tai visų pirma yra programavimo kalbų, tokių kaip UML, struktūra. Išskirtinis jo bruožas – kalbos žodyną formuoja grafiniai elementai. Kiekvienas grafinis simbolis turi tam tikrą su juo susijusią semantiką, todėl vieno kūrėjo sukurtas modelis gali būti aiškiai suprantamas kitam, taip pat ir programinės įrangos, interpretuojančios UML. Iš čia visų pirma išplaukia, kad programinės įrangos modelis, pateiktas UML, gali būti automatiškai išverstas į OO programavimo kalbą (pvz., Java, C++, VisualBasic), tai yra, jei yra geras vaizdinio modeliavimo įrankis, palaikantis UML. sukurtą modelį , taip pat gausime pavyzdinį programos kodą, atitinkantį šį modelį.

Reikia pabrėžti, kad UML yra kalba, o ne metodas. Jame paaiškinama, iš kokių elementų kurti modelius ir kaip juos skaityti, tačiau nieko nepasakoma apie tai, kokius modelius ir kokiais atvejais reikėtų kurti. Norint sukurti metodą, pagrįstą UML, būtina jį papildyti programinės įrangos kūrimo proceso aprašymu. Tokio proceso pavyzdys yra racionalus vieningas procesas, kuris bus aptartas tolesniuose straipsniuose.

UML žodynas

Modelis vaizduojamas kaip esybės ir ryšiai tarp jų, kurie rodomi diagramose.

Subjektai yra abstrakcijos, kurios yra pagrindiniai modelių elementai. Yra keturių tipų subjektai – struktūriniai (klasė, sąsaja, komponentas, naudojimo atvejis, bendradarbiavimas, mazgas), elgesio (sąveika, būsena), grupavimas (paketai) ir anotacija (komentarai). Kiekvienas subjekto tipas turi savo grafinis vaizdavimas. Esybės bus išsamiai aptariamos studijuojant diagramas.

Santykiai Rodyti įvairūs ryšiai tarp subjektų. UML apibrėžia šiuos ryšių tipus:

• Priklausomybė rodo tokį ryšį tarp dviejų esybių, kai vienos iš jų – nepriklausomo – pokytis gali paveikti kito – priklausomo – semantiką. Priklausomybė vaizduojama taškine rodykle, nukreipta nuo priklausomo subjekto į nepriklausomą.
• asociacija yra struktūrinis ryšys, parodantis, kad vieno subjekto objektai yra susiję su kito objektais. Grafiškai asociacija rodoma kaip linija, jungianti susijusius objektus. Asociacijos skirtos naršyti tarp objektų. Pavyzdžiui, susiejimas tarp klasių „Užsakymas“ ir „Prekė“ gali būti naudojamas norint rasti visas prekes, nurodytas konkrečiame užsakyme, arba rasti visus užsakymus, kuriuose yra ši prekė, kita vertus. Akivaizdu, kad atitinkamose programose turi būti įdiegtas mechanizmas, užtikrinantis tokią navigaciją. Jei navigacija reikalinga tik viena kryptimi, tai nurodo rodyklė susiejimo pabaigoje. Ypatingas asociacijos atvejis yra agregacija – „visa“ – „dalies“ formos santykis. Grafiškai jis paryškintas deimantu gale, šalia esmės visumos.
• Apibendrinimas yra ryšys tarp pirminio subjekto ir antrinio subjekto. Iš esmės šis ryšys atspindi klasių ir objektų paveldėjimo savybę. Apibendrinimas rodomas kaip linija, kuri baigiasi trikampiu, nukreiptu į pirminį objektą. Vaikas paveldi tėvų struktūrą (atributus) ir elgesį (metodus), tačiau tuo pačiu gali turėti naujų struktūros elementų ir naujų metodų. UML leidžia daugybinį paveldėjimą, kai objektas yra susijęs su daugiau nei vienu pirminiu objektu.
• Įgyvendinimas– elgsenos specifikaciją apibrėžiančio subjekto (sąsaja) ryšys su šios elgsenos įgyvendinimą apibrėžiančiu subjektu (klasė, komponentas). Šis ryšys dažniausiai naudojamas modeliuojant komponentus ir bus išsamiau aprašytas tolesniuose straipsniuose.

Diagramos. UML pateikia šias diagramas:

• Diagramos, apibūdinančios sistemos veikimą:
• Būsenų diagramos
• Veiklos diagramos,
• Objektų diagramos,
• sekos diagramos,
• Bendradarbiavimo diagramos;
• Diagramos, apibūdinančios fizinį sistemos įgyvendinimą:
• Komponentų diagramos;
• Diegimo diagramos.

Modelio valdymo vaizdas. Paketai.

Jau sakėme, kad norint, kad modelis būtų gerai suprantamas žmonėms, būtina jį organizuoti hierarchiškai, kiekviename hierarchijos lygyje paliekant nedidelį skaičių esybių. UML apima hierarchinio modelio vaizdavimo organizavimo priemonę – paketus. Bet kurį modelį sudaro paketų rinkinys, kuriame gali būti klasių, naudojimo atvejų ir kitų objektų bei diagramų. Pakete gali būti kitų paketų, leidžiančių kurti hierarchijas. UML nepateikia atskirų paketų diagramų, tačiau jos gali būti kitose diagramose. Pakuotė pavaizduota kaip stačiakampis su žyme.

Ką suteikia UML.

• hierarchinis sudėtingos sistemos aprašymas identifikuojant paketus;
• funkcinių reikalavimų sistemai formalizavimas naudojant naudojimo atvejų aparatūrą;
• detalizuoti sistemos reikalavimus, sudarant veiklos diagramas ir scenarijus;
• duomenų klasių identifikavimas ir koncepcinio duomenų modelio konstravimas klasių diagramų pavidalu;
• identifikuoti klases, apibūdinančias vartotojo sąsają ir sukurti ekrano naršymo schemą;
• objektų sąveikos procesų, vykdant sistemos funkcijas, aprašymas;
• objekto elgesio aprašymas veiklos ir būsenos diagramų pavidalu;
• programinės įrangos komponentų ir jų sąveikos per sąsajas aprašymas;
• fizinės sistemos architektūros aprašymas.

Ir paskutinis dalykas...

Nepaisant viso UML patrauklumo, jį būtų sunku naudoti realiame programinės įrangos modeliavime be vizualinio modeliavimo įrankių. Tokie įrankiai leidžia greitai pateikti diagramas ekrane, jas dokumentuoti, generuoti programos kodo šablonus įvairiomis OO programavimo kalbomis, kurti duomenų bazių schemas. Dauguma jų apima programų kodus pertvarkymo galimybę – tam tikrų programinio modelio projekcijų atkūrimą automatiškai analizuojant programų pirminius kodus, o tai labai svarbu siekiant užtikrinti modelio ir kodų atitiktį bei projektuojant sistemas, paveldinčias pirmtakų sistemų funkcionalumą.

Kas yra UML?

Jei pažvelgsite į nuotraukas paieškos sistemos, tada paaiškės, kad UML- tai kažkas apie diagramas, rodykles ir kvadratus. Svarbu tai, kad UML verčiamas kaip Vieninga modeliavimo kalba. Čia svarbus žodis vieningas. Tai yra, mūsų paveikslėlius supras ne tik mes, bet ir kiti, išmanantys UML. Pasirodo, taip yra tarptautinė kalba brėžinių diagramas.

Kaip sako Vikipedija

UML yra grafinio aprašo kalba, skirta objektų modeliavimui programinės įrangos kūrimo, verslo procesų modeliavimo, sistemų projektavimo ir organizacinių struktūrų atvaizdavimo srityse.

Taikymas

Bet ką daryti, jei norite nupiešti patys ir net neturite „Ultimate“ idėjos versijos? Jei naudosime „IntelliJ Idea Community Edition“, neturėsime kito pasirinkimo. Norėdami tai padaryti, turite suprasti, kaip sudaryta tokia UML diagrama. Pirmiausia turėsime įdiegti „Graphviz“. Tai yra grafikų vizualizavimo paslaugų rinkinys. Jį naudoja papildinys, kurį naudosime. Įdiegę turite pridėti katalogą šiukšliadėžė iš įdiegto katalogo Grafviz V aplinkos kintamasis aplinką KELIAS. Po to IntelliJ Idea meniu pasirinkite Failas -> Nustatymai. Lange „Nustatymai“ pasirinkite kategoriją „Papildiniai“, spustelėkite mygtuką „Naršyti saugyklas“ ir įdiekite „PlantUML“ integravimo įskiepį. Kodėl šis toks geras? AugalasUML? Jame naudojama grafiko aprašymo kalba, vadinama " taškas"ir tai leidžia jai būti universalesniam, nes šią kalbą naudoja ne tik PlantUML. Be to, viską, ką darome žemiau, galime padaryti ne tik IDE, bet ir internetinė paslauga planttext.com. Įdiegę PlantUML įskiepį, UML diagramas galėsime kurti per „Failas“ -> „Naujas“. Sukurkime „UML klasės“ tipo diagramą. Šio proceso metu automatiškai sugeneruojamas šablonas su pavyzdžiu. Ištrinkime jo turinį ir sukurkime savo, apsiginklavę straipsniu iš Habr: Klasių santykiai – nuo ​​UML iki kodo. Ir norėdami suprasti, kaip tai pavaizduoti tekste, paimkime PlantUML vadovą: plantuml klasės diagramą. Pačioje pradžioje yra lentelė, rodanti, kaip reikėtų apibūdinti ryšius:

Taip pat galime pažvelgti į pačius ryšius čia: „Ryšiai tarp klasių UML. Pavyzdžiai“. Remdamiesi šia medžiaga, pradėkime kurti UML diagramą. Pridėkime tokį turinį, apibūdinantį dvi klases: @startuml klasė ArrayList ( ) klasė LinkedList ( ) @enduml Norėdami pamatyti rezultatą Idėje, pasirinkite "View" -> "Tool Windows" -> "PlantUML". Mes tiesiog gausime du kvadratus, vaizduojančius klases. Kaip žinome, abi šios klasės įgyvendina sąrašo sąsają. Šis klasės ryšys vadinamas įgyvendinimu. Norėdami pavaizduoti tokį ryšį, naudokite rodyklę su punktyrine linija. Pavaizduokime jį: sąsajos sąrašo sąrašas< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для sekantis tipas ryšį, prie ArrayList klasės aprašymo pridėsime įrašą apie paketas privatus elementų masyvas: ~ Object elementData Dabar norime parodyti, kad ArrayList yra keletas objektų. Šiuo atveju ryšio tipas bus - agregacija(sujungimas). Šiuo atveju agregatas yra ArrayList, nes jame yra kitų objektų. Mes pasirenkame agregaciją, nes sąraše esantys objektai gali gyventi ir be sąrašo: jie nėra neatsiejama jo dalis. Jų gyvenimo trukmė nėra susieta su sąrašo gyvavimo trukme. Agregatas iš lotynų kalbos išverstas kaip „surinktas“, tai yra, kažkas iš kažko sudarytas. Pavyzdžiui, gyvenime yra siurbimo įrenginys, kurį sudaro siurblys ir variklis. Pats įrenginys gali būti išardomas, paliekant kai kuriuos jo komponentus. Pavyzdžiui, parduoti arba įdėti į kitą vienetą. Taip pat ir sąrašas. Ir tai išreiškiama tuščiu deimantu šalia įrenginio ir ištisine linija. Pavaizduokime jį taip: Class Object ( ) ArrayList o- Object Dabar norime parodyti, kad skirtingai nei ArrayList, LinkedList klasėje yra Node – konteineriai, nurodantys saugomus duomenis. Šiuo atveju mazgai yra paties LinkedList dalis ir negali gyventi atskirai. Mazgas tiesiogiai nesaugo turinio, o turi tik nuorodą į jį. Pavyzdžiui, kai įtraukiame eilutę į LinkedList, pridedame naują mazgą, kuriame yra nuoroda į tą eilutę, taip pat nuoroda į ankstesnį ir kitą mazgą. Šis ryšio tipas vadinamas kompozicija(Sudėtis). Kad būtų rodomas kompozitas (kuris susideda iš dalių), nupieštas spalvotas deimantas, prie kurio veda ištisinė linija. Dabar parašykime tai kaip ryšio tekstinį vaizdą: klasė Mazgas ( ) LinkedList * -- Mazgas Ir dabar turime išmokti parodyti kitą svarbų ryšio tipą - priklausomybė(priklausomybės santykiai). Jis naudojamas, kai viena klasė naudoja kitą, o klasėje nėra naudojamos klasės ir ji nėra jos palikuonė. Pavyzdžiui, „LinkedList“ ir „ArrayList“ gali sukurti „ListIterator“. Rodykime tai kaip rodykles su punktyrine linija: klasė ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Galite įsigilinti į tiek detalių, kiek reikia. Visi pavadinimai nurodyti čia: "PlantUML - klasės diagrama". Be to, braižant tokią diagramą nėra nieko antgamtiško, o dirbdami su užduotimis galite greitai ją nupiešti ranka. Tai lavins mąstymo per programos architektūrą įgūdžius ir padės nustatyti programos klasės struktūros trūkumus. Ankstyva stadija, o ne tada, kai jau praleidote dieną diegdami netinkamą modelį. Manau, kad tai gera priežastis pabandyti?)

Automatika

Kadangi Maven nėra šio straipsnio dėmesio centre, atsakymus į savo Maven klausimus galite rasti Maven vartotojų centre. Sukurtame projekte atidarykite projekto aprašymo failą redaguoti, pom.xml. Nukopijuokime turinį iš uml-java-dockleto diegimo aprašymo į jį. Aprašyme naudoto artefakto nepavyko rasti „Maven Central“ saugykloje. Bet man tai padėjo: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Tai yra, jums tereikia pakeisti tame aprašyme grupės ID Su " info.leadinglight"įjungta" com.chfourie"ir įdiegti versiją" 1.0.0 ". Po to galime vykdyti kataloge, kuriame yra failas pom.xmlšios komandos: mvn clean install ir mvn javadoc:javadoc . Dabar, jei atidarysime sugeneruotą dokumentaciją (explorer target\site\apidocs\index.html), pamatysime UML diagramas. Beje, diegimas čia jau rodomas teisingai)

Išvada