Vieningoji modeliavimo kalba (UML) yra programinės įrangos inžinerijos srities modeliavimo kalba, kuria siekiama nustatyti standartinius būdus vizualizuoti sistemos dizainą. UML padeda kurti kelių tipų diagramas, tokias kaip sąveikos, struktūros ir elgesio diagramos. A sekos diagrama yra dažniausiai naudojamas sąveika diagrama.

Sąveikos diagrama

Sąveikos diagrama naudojama parodyti interaktyvus elgesys sistemos. Kadangi sistemos sąveikos vizualizavimas gali būti sudėtingas, mes naudojame įvairių tipų sąveikos diagramas, kad užfiksuotume įvairias sistemos sąveikos ypatybes ir aspektus.

• 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.

Svarbios temos sekos diagramoms

• Sekos diagramos žymėjimas
• Aktoriai
  • Gelbėjimo linijos
  • Žinutės
  • Sukurti pranešimą
  • Ištrinti pranešimą
  • Savęs žinutė
  • Atsakyti žinutę
  • Rastas pranešimas
  • Prarasta žinutė
  • Sargybiniai
• Kaip sukurti sekos diagramas?
• Sekos diagramų naudojimo atvejai
• Sekos diagramų naudojimo iššūkiai

1. Sekos diagramos žymėjimas

1.1. Aktoriai

Aktorius UML diagramoje reiškia vaidmenį, kai jis sąveikauja su sistema ir jos objektais. Čia svarbu pažymėti, kad veikėjas visada nepatenka į sistemos, kurią siekiame modeliuoti naudojant UML diagramą, taikymo sritį.

Naudojame aktorius, kad pavaizduotų įvairius vaidmenis, įskaitant žmonių vartotojus ir kitus išorinius subjektus. Atvaizduojame veikėją UML diagramoje naudodami asmens žymėjimą. Sekos diagramoje galime turėti kelis veikėjus.

Pavyzdžiui:

Čia vartotojas vietų rezervavimo sistemoje rodomas kaip veikėjas, kai jis egzistuoja už sistemos ribų ir nėra sistemos dalis.

1.2. Gelbėjimo linijos

Gelbėjimo linija yra pavadintas elementas, vaizduojantis atskirą dalyvį sekos diagramoje. Taigi iš esmės kiekvienas sekos diagramos pavyzdys vaizduojamas gelbėjimo linija. Gyvybės linijos elementai yra sekos diagramos viršuje. UML standartas, skirtas gelbėjimo linijai pavadinti, yra toks:

Pavyzdžio pavadinimas: klasės pavadinimas

css pabrauktas tekstas

Mes rodome gelbėjimo liniją stačiakampyje, vadinamame galva su jo pavadinimu ir tipu. Galva yra ant vertikalios punktyrinės linijos (vadinamos koteliu), kaip parodyta aukščiau.

• Jei norime modeliuoti neįvardytą egzempliorių, laikomės to paties modelio, tik dabar gyvybės linijos pavadinimo dalis paliekama tuščia.
• Skirtumas tarp gelbėjimosi rato ir aktoriaus
  • Gelbėjimo linija visada vaizduoja sistemos viduje esantį objektą, o aktoriai naudojami vaizduoti sistemos išorės objektus.

Toliau pateikiamas sekos diagramos pavyzdys:

1.3. Žinutės

Ryšys tarp objektų vaizduojamas naudojant pranešimus. Pranešimai gelbėjimo linijoje rodomi nuoseklia tvarka.

• Pranešimus pavaizduojame rodyklėmis.
• Gyvybės linijos ir pranešimai sudaro sekos diagramos pagrindą.

Pranešimus galima iš esmės suskirstyti į šias kategorijas:

Sinchroniniai pranešimai

Sinchroninis pranešimas laukia atsakymo, kol sąveika gali tęstis. Siuntėjas laukia, kol gavėjas baigs apdoroti pranešimą. Skambintojas tęsia tik tada, kai žino, kad gavėjas apdorojo ankstesnį pranešimą, t. y. gavo atsakymo pranešimą.

• Daug skambučių objektinio programavimo metu yra sinchroniniai.
• Mes naudojame a kieta strėlės galvutė sinchroniniam pranešimui atstovauti.

Asinchroniniai pranešimai

Asinchroninis pranešimas nelaukia atsakymo iš gavėjo. Sąveika juda į priekį nepriklausomai nuo to, ar gavėjas apdoroja ankstesnį pranešimą, ar ne. Mes naudojame a išklota strėlės galvute atstovauti asinchroniniam pranešimui.

1.4. Sukurti pranešimą

Naujam objektui sekos diagramoje sukurti naudojame pranešimą Sukurti. Yra situacijų, kai tam tikram pranešimo skambučiui reikia sukurti objektą. Jis pavaizduotas taškine rodykle ir ant jos pažymėtas žodis, nurodantis, kad tai yra pranešimo kūrimo simbolis.

Pavyzdžiui:

Norint sukurti naują užsakymą elektroninės prekybos svetainėje, reikėtų sukurti naują Užsakymo klasės objektą.

1.5. Ištrinti pranešimą

Objektui ištrinti naudojame ištrynimo pranešimą. Kai objektui atlaisvinama atmintis arba jis sunaikinamas sistemoje, naudojame simbolį Ištrinti pranešimą. Jis sunaikina objekto atsiradimą sistemoje. Jį pavaizduoja rodyklė, kuri baigiasi x.

Pavyzdžiui:

Toliau pateiktame scenarijuje, kai vartotojas gauna užsakymą, užsakymo klasės objektas gali būti sunaikintas.

1.6. Savęs žinutė

Gali atsirasti tam tikrų scenarijų, kai objektas turi išsiųsti pranešimą sau. Tokie pranešimai vadinami savaiminiais pranešimais ir yra pavaizduoti a U formos rodyklė .

Kitas pavyzdys:

Apsvarstykite scenarijų, kai įrenginys nori pasiekti savo internetinę kamerą. Toks scenarijus vaizduojamas naudojant savęs pranešimą.

1.7. Atsakyti žinutę

Atsakymo pranešimai naudojami norint parodyti pranešimą, siunčiamą iš gavėjo siuntėjui. Mes atstovaujame grąžinimo / atsakymo pranešimą naudodami a atvira rodyklės galvutė su punktyrine linija . Sąveika juda į priekį tik tada, kai gavėjas išsiunčia atsakymo pranešimą.

eilutės skaidymas c++

Pavyzdžiui:

Apsvarstykite scenarijų, kai įrenginys prašo vartotojo nuotraukos. Čia pranešimas, kuriame rodoma siunčiama nuotrauka, yra atsakymo pranešimas.

1.8. Rastas pranešimas

Rastas pranešimas naudojamas vaizduoti scenarijų, kai nežinomas šaltinis siunčia pranešimą. Jis pavaizduotas naudojant an rodyklė nukreipta į gelbėjimo liniją nuo galutinio taško.

Pavyzdžiui:

Apsvarstykite aparatinės įrangos gedimo scenarijų.

Tai gali būti dėl kelių priežasčių ir nesame tikri, kas sukėlė aparatinės įrangos gedimą.

1.9. Prarasta žinutė

Prarastas pranešimas naudojamas vaizduoti scenarijų, kai gavėjas nėra žinomas sistemai. Jis pavaizduotas naudojant rodyklę, nukreiptą į galutinį tašką nuo gyvybės linijos.

Pavyzdžiui:

Apsvarstykite scenarijų, kai sugeneruojamas įspėjimas.

teiginių logika

Įspėjimas gali būti sugeneruotas vartotojui arba kitai programinei įrangai / objektui, su kuriuo sąveikauja gelbėjimo linija. Kadangi kelionės tikslas iš anksto nežinomas, naudojame simbolį Pamestas pranešimas.

1.10. Sargybiniai

Sąlygoms modeliuoti naudojame UML apsaugas. Jie naudojami, kai turime apriboti pranešimų srautą pretekstu įvykdyti sąlygą. Apsaugai atlieka svarbų vaidmenį leisdami programinės įrangos kūrėjams žinoti sistemos ar konkretaus proceso apribojimus.

Pavyzdžiui:

Kad būtų galima atsiimti grynųjų pinigų, likutis didesnis nei nulis yra sąlyga, kurią reikia įvykdyti, kaip parodyta toliau.

Aukščiau pateiktoje sekos diagramoje pavaizduota emocijomis pagrįsto muzikos grotuvo sekos schema:

1. Pirmiausia programą atidaro vartotojas.
2. Tada įrenginys gauna prieigą prie žiniatinklio kameros.
3. Interneto kamera užfiksuoja vartotojo vaizdą.
4. Prietaisas naudoja algoritmus veidui aptikti ir nuotaikai nuspėti.
5. Tada jis prašo duomenų bazės galimų nuotaikų žodynui.
6. Nuotaika paimama iš duomenų bazės.
7. Nuotaika rodoma vartotojui.
8. Muzika prašoma iš duomenų bazės.
9. Grojaraštis sugeneruojamas ir galiausiai parodomas vartotojui.

2. Kaip sukurti sekos diagramas?

Sekos diagramos kūrimas apima kelis veiksmus ir paprastai tai daroma programinės įrangos kūrimo projektavimo etape, siekiant parodyti, kaip įvairūs komponentai ar objektai sąveikauja laikui bėgant. Štai žingsnis po žingsnio vadovas, kaip sukurti sekos diagramas:

1. Nustatykite scenarijų:
   • Supraskite konkretų scenarijų arba naudojimo atvejį, kurį norite pavaizduoti sekos diagramoje. Tai gali būti specifinė sąveika tarp objektų arba pranešimų srautas tam tikrame procese.
2. Dalyvių sąrašas:
   • Nurodykite scenarijuje dalyvaujančius dalyvius (objektus ar veikėjus). Dalyviai gali būti vartotojai, sistemos arba išoriniai subjektai.
3. Apibrėžkite gyvybės linijas:
   • Kiekvienam dalyviui nubrėžkite vertikalią punktyrinę liniją, atspindinčią kiekvieno objekto gyvybės liniją laikui bėgant. Gelbėjimo linija reiškia objekto egzistavimą sąveikos metu.
4. Išdėstykite gyvybės linijas:
   • Padėkite gelbėjimo linijas horizontaliai pagal jų įtraukimo į sąveiką tvarką. Tai padeda vizualizuoti pranešimų srautą tarp dalyvių.
5. Pridėti aktyvinimo juostas:
   • Prie kiekvieno pranešimo nubrėžkite aktyvinimo juostą ant siunčiančio dalyvio gyvybės linijos. Aktyvinimo juosta rodo laiką, per kurį dalyvis aktyviai apdoroja pranešimą.
6. Pieškite pranešimus:
   • Rodyklėmis pavaizduokite pranešimus tarp dalyvių. Žinutės sklinda horizontaliai tarp gyvybės linijų, nurodydamos bendravimą tarp objektų. Įvairių tipų pranešimai yra sinchroniniai (vientisa rodyklė), asinchroniniai (brūkšninė rodyklė) ir savarankiški pranešimai.
7. Įtraukti grįžtamuosius pranešimus:
   • Jei dalyvis siunčia atsakymo pranešimą, nupieškite brūkšninę rodyklę, grįžusią į pradinį siuntėją, vaizduojančią grįžtamąjį pranešimą.
8. Nurodykite laiką ir tvarką:
   • Norėdami nurodyti pranešimų seką, naudokite skaičius. Taip pat galite naudoti vertikalias brūkšnines linijas, kad pavaizduotų įvykių įvykius arba laiko eigą.
9. Įtraukti sąlygas ir kilpas:
   • Naudokite kombinuotus fragmentus, kad pateiktumėte sąlygas (pvz., if teiginius) ir sąveikos kilpas. Tai padaro sekos diagramą sudėtingesnę ir padeda detalizuoti valdymo srautą.
10. Apsvarstykite lygiagretų vykdymą:
    • Jei vyksta lygiagrečios veiklos, pavaizduokite jas nubrėždami lygiagrečias vertikalias punktyrines linijas ir atitinkamai išdėstydami pranešimus.
11. Peržiūrėkite ir patikslinkite:
    • Peržiūrėkite sekos diagramą, kad būtų aiškumo ir teisingumo. Įsitikinkite, kad jis tiksliai atspindi numatomą sąveiką. Patikslinkite pagal poreikį.
12. Pridėti komentarų ir komentarų:
    • Įtraukite bet kokią papildomą informaciją, komentarus ar komentarus, kurie pateikia kontekstą arba paaiškina diagramos elementus.
13. Dokumento prielaidos ir apribojimai:
    • Jei yra kokių nors su sąveika susijusių prielaidų ar apribojimų, dokumentuokite jas kartu su diagrama.
14. Įrankiai:
    • Naudokite UML modeliavimo įrankį arba diagramų sudarymo programinę įrangą, kad sukurtumėte tvarkingą ir profesionaliai atrodančią sekos diagramą. Šie įrankiai dažnai suteikia funkcijų, leidžiančių lengvai redaguoti, bendradarbiauti ir dokumentuoti.

3. Sekos diagramų naudojimo atvejai

• Sistemos veikimo vizualizacija:
  • Sekos diagramos naudojamos iliustruoti dinamišką sistemos elgesį, parodant įvairių komponentų, objektų ar veikėjų sąveiką laikui bėgant.
  • Jie aiškiai ir vaizdžiai parodo pranešimų ir įvykių srautą konkrečiame scenarijuje.
• Programinės įrangos dizainas ir architektūra:
  • Programinės įrangos kūrimo projektavimo etape sekos diagramos padeda kūrėjams ir architektams planuoti ir suprasti, kaip skirtingi komponentai ir objektai sąveikaus, kad atliktų konkrečias funkcijas.
  • Jie pateikia sistemos elgesio planą.
• Bendravimas ir bendradarbiavimas:
  • Sekos diagramos yra komunikacijos priemonė tarp suinteresuotųjų šalių, įskaitant kūrėjus, dizainerius, projektų vadovus ir klientus.
  • Jie padeda perteikti sudėtingas sąveikas lengvai suprantamu vaizdiniu formatu, skatina bendradarbiavimą ir bendrą supratimą.
• Reikalavimų paaiškinimas:
  • Tikslinant sistemos reikalavimus, sekos diagramos gali būti naudojamos norint paaiškinti ir nurodyti numatomą sąveiką tarp sistemos komponentų arba tarp sistemos ir išorinių objektų.
  • Jie padeda užtikrinti bendrą sistemos elgesio supratimą tarp visų suinteresuotųjų šalių.
• Derinimas ir trikčių šalinimas:
  • Kūrėjai naudoja sekos diagramas kaip derinimo įrankį, kad nustatytų ir analizuotų problemas, susijusias su pranešimų tvarka ir laiku sistemos sąveikos metu.
  • Tai vizualiai atvaizduoja valdymo srautą ir padeda nustatyti bei išspręsti problemas.

4. Sekos diagramų naudojimo iššūkiai

• Sudėtingumas ir dydis:
  • Sistemoms vis sudėtingėjant, sekos diagramos gali tapti didelės ir sudėtingos. Gali būti sudėtinga valdyti diagramos dydį, kartu tiksliai vaizduojant sąveiką, o pernelyg sudėtingas diagramas gali būti sunku suprasti.
• Abstrakcijos lygis:
  • Gali būti sudėtinga rasti tinkamą abstrakcijos pusiausvyrą. Sekos diagramos turi būti pakankamai išsamios, kad perteiktų reikiamą informaciją, tačiau per daug detalių gali priblokšti skaitytojus. Svarbu sutelkti dėmesį į svarbiausias sąveikas, neįklimpstant į smulkmenas.
• Dinamiška prigimtis:
  • Sekos diagramos vaizduoja dinaminius sistemos aspektus, todėl jos gali dažnai keistis kūrimo proceso metu. Atnaujinti sekos diagramas besivystančioje sistemoje gali būti sudėtinga, ypač greitai kintančioje ar judrioje kūrimo aplinkoje.
• Neaiškumai pranešimuose:
  • Kartais gali būti sudėtinga apibrėžti tikslų pranešimų tarp objektų pobūdį. Pranešimo turinio ar reikšmės dviprasmiškumas gali sukelti nesusipratimų tarp suinteresuotųjų šalių ir turėti įtakos sekos diagramos tikslumui.
• Lygiagretumas ir lygiagretumas:
  • Lygiagrečių ir lygiagrečių procesų atvaizdavimas gali būti sudėtingas. Nors sekos diagramos turi lygiagrečiam vykdymui skirtus mechanizmus, kelių sąveikų, vykstančių vienu metu, vizualizavimas gali būti sudėtingas ir gali prireikti papildomų diagramų elementų.
• Realaus laiko apribojimai:
  • Realaus laiko apribojimų ir tikslių laiko reikalavimų pateikimas gali būti sudėtingas. Nors sekos diagramos pateikia nuoseklų vaizdą, norint tiksliai užfiksuoti ir perduoti realaus laiko aspektus, gali prireikti papildomų dokumentų arba papildomų diagramų.