Vieningoji modeliavimo kalba (UML) yra bendrosios paskirties modeliavimo kalba. Pagrindinis UML tikslas yra apibrėžti standartinį būdą vizualizuoti kaip buvo sukurta sistema. Tai gana panašu į brėžinius, naudojamus kitose inžinerijos srityse. UML yra ne programavimo kalba , tai veikiau vaizdinė kalba.

Svarbios vieningos modeliavimo kalbos (UML) diagramų temos

paveldėjimo java

• Kas yra UML?
• Kodėl mums reikia UML?
• Įvairūs UML diagramų tipai
• Struktūrinės UML diagramos
• Elgesio UML diagramos
• Objektinės sąvokos, naudojamos UML diagramose
• Įrankiai UML diagramoms kurti
• UML diagramų kūrimo žingsniai
• UML diagramų geriausia praktika
• UML ir judrusis vystymas
• Dažni UML modeliavimo iššūkiai
• UML diagramų naudojimo pranašumai

1. Kas yra UML?

Vieningoji modeliavimo kalba (UML) yra standartizuota vizualinio modeliavimo kalba, naudojama programinės įrangos inžinerijos srityje, siekiant suteikti bendros paskirties, plėtojamą ir intuityvų būdą vizualizuoti sistemos dizainą. UML padeda nurodyti, vizualizuoti, konstruoti ir dokumentuoti programinės įrangos sistemų artefaktus.

• Norėdami pavaizduoti, naudojame UML diagramas elgesys ir struktūra sistemos.
• UML padeda programinės įrangos inžinieriams, verslininkams ir sistemų architektams modeliuoti, projektuoti ir analizuoti.
• Objektų valdymo grupė (OMG) 1997 m. priėmė vieningą modeliavimo kalbą kaip standartą. Nuo tada ją valdo OMG.
• 2005 m. Tarptautinė standartizacijos organizacija (ISO) paskelbė UML kaip patvirtintą standartą. Bėgant metams UML buvo peržiūrimas ir periodiškai peržiūrimas.

2. Kodėl mums reikia UML?

• Sudėtingoms programoms reikia bendradarbiavimo ir planavimo iš kelių komandų, todėl reikia aiškaus ir glausto būdo bendrauti tarp jų.
• Verslininkai nesupranta kodo. Taigi UML tampa būtina norint bendrauti su ne programuotojais apie esminius sistemos reikalavimus, funkcijas ir procesus.
• Sutaupoma daug laiko, kai komandos gali vizualizuoti procesus, vartotojų sąveikas ir statinę sistemos struktūrą.

3. Įvairūs UML diagramų tipai

UML yra susietas su objektiniu projektavimas ir analizė. UML naudoja elementus ir formuoja jų asociacijas, kad sudarytų diagramas. Diagramos UML gali būti plačiai klasifikuojamos kaip:

4. Struktūrinės UML diagramos

4.1. Klasės diagrama

Plačiausiai naudojama UML diagrama yra klasių diagrama. Tai yra visų objektų orientuotų programinės įrangos sistemų kūrimo blokas. Statinei sistemos struktūrai pavaizduoti naudojame klasių diagramas, rodydami sistemos klases, jų metodus ir atributus. Klasių diagramos taip pat padeda mums nustatyti ryšį tarp skirtingų klasių ar objektų.

4.2. Sudėtinės struktūros diagrama

Mes naudojame sudėtines struktūros diagramas, kad pavaizduotume vidinę klasės struktūrą ir jos sąveikos taškus su kitomis sistemos dalimis.

• Sudėtinės struktūros diagrama vaizduoja ryšį tarp dalių ir jų konfigūracijos, kuri nustato, kaip veikia klasifikatorius (klasė, komponentas arba diegimo mazgas).
• Jie atspindi struktūrinio klasifikatoriaus vidinę struktūrą, naudojant dalis, prievadus ir jungtis.
• Taip pat galime modeliuoti bendradarbiavimą naudodami sudėtines struktūros diagramas.
• Jos yra panašios į klasių diagramas, išskyrus tai, kad jos detaliai atspindi atskiras dalis, palyginti su visa klase.

4.3. Objekto diagrama

Objekto diagrama gali būti vadinama sistemos egzempliorių ir tarp jų egzistuojančio ryšio ekrano kopija. Kadangi objektų diagramos vaizduoja elgesį, kai objektai buvo sukurti, mes galime ištirti sistemos elgesį tam tikru momentu.

ascii iš a Java

• Objekto diagrama yra panaši į klasių diagramą, išskyrus tai, kad ji rodo klasių atvejus sistemoje.
• Mes vaizduojame tikrus klasifikatorius ir jų ryšius, naudodami klasių diagramas.
• Kita vertus, objekto diagrama vaizduoja konkrečius klasių atvejus ir ryšius tarp jų tam tikru momentu.

4.4. Komponentų diagrama

Komponentų diagramos naudojamos parodyti, kaip fiziniai sistemos komponentai buvo organizuoti. Juos naudojame modeliuodami įgyvendinimo detales.

• Komponentų diagramos vaizduoja struktūrinį ryšį tarp programinės įrangos sistemos elementų ir padeda suprasti, ar funkciniai reikalavimai buvo įtraukti į planuojamą plėtrą.
• Kuriant ir kuriant sudėtingas sistemas, būtina naudoti komponentų diagramas.
• Sąsajas naudoja sistemos komponentai bendrauti tarpusavyje.

4.5. Diegimo schema

Diegimo diagramos naudojamos sistemos aparatūrai ir jos programinei įrangai pavaizduoti. Jos nurodo, kokie aparatinės įrangos komponentai egzistuoja ir kokie programinės įrangos komponentai juose veikia.

• Sistemos architektūrą iliustruojame kaip programinės įrangos artefaktų paskirstymą paskirstytuose taikiniuose.
• Artefaktas yra informacija, kurią generuoja sistemos programinė įranga.
• Jie pirmiausia naudojami, kai programinė įranga naudojama, platinama arba diegiama keliose skirtingos konfigūracijos mašinose.

4.6. Pakuotės schema

Mes naudojame paketų diagramas, kad pavaizduotume, kaip buvo sutvarkyti paketai ir jų elementai. Paketų diagrama tiesiog parodo skirtingų paketų priklausomybes ir vidinę paketų sudėtį.

• Paketai padeda suskirstyti UML diagramas į reikšmingas grupes ir padaryti diagramą lengvai suprantamą.
• Jie pirmiausia naudojami klasių ir naudojimo atvejų diagramoms organizuoti.

5. Elgesio UML diagramos

5.1. Būsenos mašinos diagramos

Būsenos diagrama naudojama sistemos arba sistemos dalies būklei pateikti baigtiniais laiko atvejais. Tai elgsenos diagrama ir ji vaizduoja elgesį naudojant baigtinių būsenų perėjimus.

• Būsenos diagramos taip pat vadinamos Valstybės mašinos ir Būsenos diagramos diagramos
• Šie terminai dažnai vartojami pakaitomis. Taigi paprastai būsenos diagrama naudojama klasės dinaminiam elgesiui modeliuoti, reaguojant į laiką ir kintančius išorinius dirgiklius.

5.2. Veiklos diagramos

Sistemos valdymo srautui iliustruoti naudojame veiklos diagramas. Taip pat galime naudoti veiklos diagramą, norėdami nurodyti veiksmus, susijusius su naudojimo atvejo vykdymu.

• Naudodamiesi veiklos diagramomis modeliuojame nuoseklią ir lygiagrečią veiklą. Taigi iš esmės darbo eigas vaizduojame vizualiai, naudodami veiklos diagramą.
• Veiklos diagramoje dėmesys sutelkiamas į srauto būklę ir seką, kuria tai vyksta.
• Mes aprašome arba pavaizduojame, kas sukelia tam tikrą įvykį, naudodami veiklos diagramą.

5.3. Naudokite atvejo diagramas

Naudojimo atvejų diagramos naudojamos sistemos ar sistemos dalies funkcionalumui pavaizduoti. Jie plačiai naudojami iliustruoti funkcinius sistemos reikalavimus ir jos sąveiką su išoriniais agentais (aktoriais).

• Naudojimo atvejis iš esmės yra diagrama, vaizduojanti skirtingus scenarijus, kuriuose sistema gali būti naudojama.
• Naudojimo atvejų diagrama suteikia mums aukšto lygio vaizdą apie tai, ką veikia sistema ar jos dalis, nesigilinant į įgyvendinimo detales.

5.4. Sekos diagrama

Sekos diagrama tiesiog vaizduoja sąveiką tarp objektų nuoseklia tvarka, ty tvarka, kuria šios sąveikos vyksta.

• Taip pat galime naudoti terminus įvykių diagramos arba įvykių scenarijai, norėdami nurodyti sekos diagramą.
• Sekos diagramos aprašo, kaip ir kokia tvarka veikia sistemos objektai.
• Šias diagramas plačiai naudoja verslininkai ir programinės įrangos kūrėjai, norėdami dokumentuoti ir suprasti naujų ir esamų sistemų reikalavimus.

5.5. Bendravimo diagrama

Ryšio diagrama (žinoma kaip bendradarbiavimo diagrama UML 1.x) naudojama norint parodyti sekos pranešimus, kuriais keičiasi objektai.

• Bendravimo diagramoje daugiausia dėmesio skiriama objektams ir jų santykiams.
• Panašią informaciją galime pavaizduoti naudodami sekos diagramas, tačiau komunikacijos diagramos vaizduoja objektus ir nuorodas laisva forma.

5.6. Laiko diagrama

Laiko diagrama yra speciali sekos diagramų forma, kuri naudojama objektų elgsenai per tam tikrą laikotarpį pavaizduoti. Mes naudojame juos, norėdami parodyti laiko ir trukmės apribojimus, kurie valdo objektų būsenų ir elgesio pokyčius.

5.7. Sąveikos apžvalgos diagrama

Sąveikos apžvalgos diagrama modeliuoja veiksmų seką ir padeda supaprastinti sudėtingas sąveikas į paprastesnius įvykius. Tai veiklos ir sekos diagramų mišinys.

pavasario mvc

6. UML diagramose naudojamos objektinės sąvokos

1. Klasė: Klasė apibrėžia mėlyną atspaudą, ty objekto struktūrą ir funkcijas.
2. Objektai : Objektai padeda mums suskaidyti dideles sistemas ir padeda mums moduliuoti mūsų sistemą. Moduliškumas padeda padalinti mūsų sistemą į suprantamus komponentus, kad galėtume kurti sistemą po gabalo.
3. Paveldėjimas: Paveldėjimas yra mechanizmas, pagal kurį antrinės klasės paveldi savo pirminių klasių savybes.
4. Abstrakcija: Abstrakcija UML reiškia esminių sistemos ar objekto aspektų pabrėžimo procesą, neatsižvelgiant į nereikšmingas detales. Pašalinus nereikalingus sudėtingumus, abstrakcija palengvina suinteresuotųjų šalių aiškesnį supratimą ir bendravimą.
5. Inkapsuliavimas: Duomenų surišimas ir apsauga nuo išorinio pasaulio vadinamas inkapsuliavimu.
6. Polimorfizmas: Mechanizmas, pagal kurį funkcijos ar subjektai gali egzistuoti įvairiomis formomis.

6.1. UML 2.0 papildymai

• Buvo įtrauktos programinės įrangos kūrimo metodikos, tokios kaip „Agile“, ir išplėsta originalios UML specifikacijos apimtis.
• Iš pradžių UML nurodė 9 diagramas. UML 2.x padidino diagramų skaičių nuo 9 iki 13. Pridėtos keturios diagramos: laiko diagrama, ryšio diagrama, sąveikos apžvalgos diagrama ir sudėtinės struktūros diagrama. UML 2.x pervadino būsenos diagramos diagramas į būsenos mašinų diagramas.
• UML 2.x pridėjo galimybę išskaidyti programinės įrangos sistemą į komponentus ir subkomponentus.

7. UML diagramų kūrimo įrankiai

Yra keletas įrankių, skirtų sukurti vieningos modeliavimo kalbos (UML) diagramas, kurios dažniausiai naudojamos kuriant programinę įrangą, kad vizualiai pavaizduotų sistemos architektūrą, dizainą ir įgyvendinimą. Štai keletas populiarių UML diagramų kūrimo įrankių:

• Lucidchart: „Lucidchart“ yra žiniatinklio diagramų sudarymo įrankis, palaikantis UML diagramas. Tai patogu naudoti ir bendradarbiauti, todėl keli vartotojai gali dirbti su diagramomis realiuoju laiku.
• Draw.io: Draw.io yra nemokamas žiniatinklio diagramų sudarymo įrankis, palaikantis įvairius diagramų tipus, įskaitant UML. Jis integruojamas su įvairiomis debesų saugojimo paslaugomis ir gali būti naudojamas neprisijungus.
• Vizualinė paradigma: „Visual Paradigm“ pateikia išsamų programinės įrangos kūrimo įrankių rinkinį, įskaitant UML diagramų sudarymą. Ji siūlo tiek internetines, tiek darbalaukio versijas ir palaiko daugybę UML diagramų.
• StarUML: StarUML yra atviro kodo UML modeliavimo įrankis su patogia sąsaja. Jis palaiko standartines UML 2.x diagramas ir leidžia vartotojams tinkinti bei išplėsti jo funkcijas naudojant papildinius.
• Papirusas: Papyrus yra atvirojo kodo UML modeliavimo įrankis, kuris yra Eclipse Modeling Project dalis. Tai suteikia tinkinamą aplinką UML diagramoms kurti, redaguoti ir vizualizuoti.
• PlantUML: PlantUML yra teksto įrankis, leidžiantis kurti UML diagramas naudojant paprastą ir žmogui suprantamą sintaksę. Jis dažnai naudojamas kartu su kitais įrankiais ir palaiko įvairius diagramų tipus.

8. UML diagramų kūrimo žingsniai

rujira banerjee

Vieningos modeliavimo kalbos (UML) diagramų kūrimas apima sistemingą procesą, kuris paprastai apima šiuos veiksmus:

• 1 veiksmas: nustatykite tikslą:
  • Nustatykite UML diagramos kūrimo tikslą. Įvairių tipų UML diagramos naudojamos įvairiems tikslams, pavyzdžiui, fiksuoti reikalavimus, projektuoti sistemos architektūrą arba dokumentuoti klasių ryšius.
• 2 veiksmas: nustatykite elementus ir ryšius:
  • Nurodykite pagrindinius elementus (klases, objektus, naudojimo atvejus ir kt.) ir jų ryšius, kuriuos reikia pavaizduoti diagramoje. Šis žingsnis apima modeliuojamos sistemos struktūros ir elgesio supratimą.
• 3 veiksmas: pasirinkite tinkamą UML diagramos tipą:
  • Pasirinkite UML diagramos tipą, kuris geriausiai atitinka jūsų modeliavimo poreikius. Įprasti tipai yra klasių diagramos, naudojimo atvejų diagramos, sekos diagramos, veiklos diagramos ir kt.
• 4 veiksmas: sukurkite apytikslį eskizą:
  • Prieš naudojant UML modeliavimo įrankį, gali būti naudinga ant popieriaus ar lentos sukurti apytikslį eskizą. Tai gali padėti vizualizuoti elementų išdėstymą ir ryšius.
• 5 veiksmas: pasirinkite UML modeliavimo įrankį:
  • Pasirinkite UML modeliavimo įrankį, atitinkantį jūsų pageidavimus ir reikalavimus. Yra įvairių įrankių, tiek prisijungus, tiek neprisijungus, kurie siūlo UML diagramų kūrimo ir redagavimo funkcijas.
• 6 veiksmas: sukurkite diagramą:
  • Atidarykite pasirinktą UML modeliavimo įrankį ir sukurkite naują projektą arba diagramą. Pradėkite prie diagramos pridėti elementų (pvz., klasių, naudojimo atvejų, veikėjų) ir susiekite juos su atitinkamais ryšiais (pvz., asociacijomis, priklausomybėmis).
• 7 veiksmas: apibrėžkite elemento ypatybes:
  • Kiekvienam diagramos elementui nurodykite atitinkamas savybes ir atributus. Tai gali apimti klasės atributus ir metodus, išsamią naudojimo atvejo informaciją arba bet kokią kitą diagramos tipui būdingą informaciją.
• 8 veiksmas: pridėkite komentarų ir komentarų:
  • Padidinkite diagramos aiškumą pridėdami komentarų, komentarų ir aiškinamųjų pastabų. Tai padeda kiekvienam, peržiūrinčiam diagramą, suprasti projektavimo sprendimus ir jos logiką.
• 9 veiksmas: patvirtinkite ir peržiūrėkite:
  • Peržiūrėkite diagramos tikslumą ir išsamumą. Įsitikinkite, kad ryšiai, apribojimai ir elementai tiksliai atspindi numatytą sistemą ar procesą. Patvirtinkite diagramą pagal reikalavimus ir atlikite reikiamus pakeitimus.
• 10 veiksmas: patikslinkite ir kartokite:
  • Patikslinkite diagramą remdamiesi atsiliepimais ir papildomomis įžvalgomis. UML diagramos dažnai kuriamos iteratyviai, tobulėjant sistemos supratimui.
• 11 veiksmas: kurkite dokumentus:
  • Kai kurie UML įrankiai leidžia kurti dokumentus tiesiai iš diagramų. Tai gali apimti klasės dokumentus, naudojimo atvejų aprašymus ir kitą svarbią informaciją.

Pastaba: Atminkite, kad konkretūs veiksmai gali skirtis atsižvelgiant į UML diagramos tipą ir naudojamą įrankį.

9. UML diagramų geriausia praktika

Unified Modeling Language (UML) yra galingas įrankis vizualizuoti ir dokumentuoti sistemos dizainą. Norint sukurti efektyvias ir prasmingas UML diagramas, būtina laikytis geriausios praktikos. Štai keletas geriausių UML praktikų:

1. Supraskite auditoriją: Kurdami UML diagramas, atsižvelkite į savo auditoriją. Pritaikykite detalumo lygį ir diagramų pasirinkimą, kad atitiktų jūsų auditorijos supratimą ir poreikius, nesvarbu, ar tai kūrėjai, architektai ar suinteresuotosios šalys.
2. Laikykite diagramas paprastas ir sutelktas: Savo diagramose siekite paprastumo. Kiekviena diagrama turėtų sutelkti dėmesį į konkretų sistemos aspektą arba tam tikrą santykių rinkinį. Venkite netvarkos ir nereikalingų detalių, kurios gali atitraukti dėmesį nuo pagrindinės žinutės.
3. Naudokite nuoseklias pavadinimo taisykles: Priimkite nuoseklius ir prasmingus klasių, objektų, atributų, metodų ir kitų UML elementų pavadinimus. Aiškios ir gerai apgalvotos pavadinimų taisyklės pagerina jūsų diagramų suprantamumą.
4. Laikykitės standartinių UML žymėjimų: Laikykitės standartinių UML žymų ir simbolių. Nuoseklumas naudojant UML konvencijas užtikrina, kad jūsų diagramas lengvai supras kiti, susipažinę su UML.
5. Išlaikykite aiškius santykius: Aiškiai apibrėžkite ir pažymėkite ryšius tarp elementų. Naudokite tinkamas rodykles, daugybinius žymėjimus ir asociacijų pavadinimus, kad praneštumėte apie ryšių tarp klasių, objektų ar naudojimo atvejų pobūdį.

10. UML ir Agile Development

Vieninga modeliavimo kalba (UML) ir judrusis kūrimas yra du skirtingi programinės įrangos kūrimo būdai, todėl juos galima veiksmingai integruoti, siekiant pagerinti bendrą kūrimo procesą. Štai keletas pagrindinių punktų apie UML ir Agile plėtros ryšį:

10.1. UML judrioje plėtroje

• Vizualizacija ir komunikacija: UML diagramos suteikia vizualų būdą, kaip pavaizduoti sistemos architektūrą, dizainą ir elgesį. Vykdant judrią plėtrą, kur komunikacija yra itin svarbi, UML diagramos gali būti veiksmingos komunikacijos priemonės tarp komandos narių, suinteresuotųjų šalių ir net netechninės auditorijos.
• Vartotojų istorijos ir naudojimo atvejai: UML naudojimo atvejų diagramos gali būti naudojamos norint užfiksuoti ir modeliuoti naudotojų istorijas judrioje plėtroje. Naudojimo atvejai padeda suprasti sistemą iš galutinio vartotojo perspektyvos ir prisideda prie vartotojų istorijų kūrimo.
• Iteratyvus modeliavimas: Agile metodikos pabrėžia kartotinį vystymąsi, o UML galima pritaikyti šiam požiūriui palaikyti. UML modeliai gali būti kuriami ir tobulinami laipsniškai, nes kiekvienos iteracijos metu tobulėja sistemos supratimas.
• Judrūs modeliavimo būdai: Judrūs modeliavimo metodai, tokie kaip vartotojo istorijos ir poveikio žemėlapių sudarymas, papildo UML, nes suteikia lengvų būdų vizualizuoti ir perduoti reikalavimus bei dizainą. Šie metodai atitinka Agile principą, pagal kurį vertinama veikianti programinė įranga, o ne išsami dokumentacija.

10.2. Subalansuotas judrumas ir modeliavimas

• Adaptyvusis modeliavimas: Taikykite adaptyvaus modeliavimo metodą, kai UML naudojamas tiek, kiek reikia efektyviam bendravimui ir supratimui. Didžiausias dėmesys turėtų būti skiriamas vertės teikimui naudojant veikiančią programinę įrangą, o ne išsamią dokumentaciją.
• Komandos įgalinimas: Įgalinkite kūrimo komandą pasirinkti tinkamą modeliavimo lygį, atsižvelgiant į projekto poreikius. Komandos nariai turėtų jaustis patogiai naudodamiesi UML kaip komunikacijos įrankiu, neapsunkindami pernelyg didelių modeliavimo reikalavimų.

11. Dažni UML modeliavimo iššūkiai

1. Daug laiko reikalaujantis: UML modeliavimas gali būti suvokiamas kaip daug laiko reikalaujantis, ypač greito tempo judriose aplinkose, kur akcentuojamas greitas vystymasis. Komandoms gali būti sunku neatsilikti nuo poreikio dažnai atnaujinti UML diagramas.
2. Per didelis dokumentavimas: Agile principai vertina veikiančią programinę įrangą, o ne išsamią dokumentaciją. Naudojant UML kyla per daug dokumentavimo rizika, nes komandos gali skirti per daug laiko detalioms diagramoms, kurios tiesiogiai neprisideda prie vertės teikimo.
3. Reikalavimų keitimas: Judrūs projektai dažnai susiduria su besikeičiančiais reikalavimais, o UML diagramos gali greitai pasenti. Gali būti sudėtinga neatsilikti nuo šių pokyčių ir užtikrinti, kad UML modeliai atspindėtų esamą sistemos būseną.
4. Bendradarbiavimo problemos: Agile pabrėžia komandos narių bendradarbiavimą, o kartais UML diagramos laikomos artefaktais, kuriuos supranta tik tam tikri komandos nariai. Užtikrinti, kad kiekvienas galėtų prisidėti prie UML modelių ir gauti naudos iš jų, gali būti iššūkis.

12. UML diagramų naudojimo pranašumai

1. Standartizavimas: UML suteikia standartizuotą sistemos modelių vaizdavimo būdą, užtikrinantį, kad kūrėjai ir suinteresuotosios šalys galėtų bendrauti naudodami bendrą vaizdinę kalbą.
2. Bendravimas: UML diagramos yra galingas komunikacijos įrankis tarp suinteresuotųjų šalių, įskaitant kūrėjus, dizainerius, testuotojus ir verslo vartotojus. Jie padeda suprantamiau perteikti sudėtingas idėjas.
3. Vizualizacija: UML diagramos palengvina sistemos komponentų, ryšių ir procesų vizualizavimą. Šis vizualinis vaizdas padeda suprasti ir kurti sudėtingas sistemas.
4. Dokumentacija: UML diagramos gali būti naudojamos kaip veiksmingos dokumentacijos priemonės. Jie suteikia struktūrinį ir organizuotą būdą dokumentuoti įvairius sistemos aspektus, tokius kaip architektūra, dizainas ir elgsena.
5. Analizė ir dizainas: UML palaiko programinės įrangos kūrimo analizės ir projektavimo fazes. Tai padeda modeliuoti sistemos reikalavimus ir paversti juos projektu, kurį galima įgyvendinti.