Vienotā modelēšanas valoda (UML) ir modelēšanas valoda programmatūras inženierijas jomā, kuras mērķis ir noteikt standarta veidus, kā vizualizēt sistēmas dizainu. UML palīdz izveidot vairāku veidu diagrammas, piemēram, mijiedarbības, struktūras un uzvedības diagrammas. A secības diagramma ir visbiežāk izmantotais mijiedarbība diagramma.

Mijiedarbības diagramma

Mijiedarbības diagramma tiek izmantota, lai parādītu interaktīva uzvedība sistēmas. Tā kā mijiedarbības vizualizācija sistēmā var būt sarežģīta, mēs izmantojam dažāda veida mijiedarbības diagrammas, lai attēlotu dažādas sistēmas mijiedarbības pazīmes un aspektus.

• Secību diagramma vienkārši attēlo mijiedarbību starp objektiem secīgā secībā, t.i., secībā, kādā notiek šīs mijiedarbības.
• Mēs varam arī izmantot terminus notikumu diagrammas vai notikumu scenāriji, lai atsauktos uz secības diagrammu.
• Secību diagrammas apraksta, kā un kādā secībā darbojas objekti sistēmā.
• Šīs diagrammas plaši izmanto uzņēmēji un programmatūras izstrādātāji, lai dokumentētu un izprastu prasības jaunām un esošajām sistēmām.

Svarīgas tēmas secību diagrammām

• Secības diagrammas apzīmējumi
• Aktieri
  • Dzīves līnijas
  • Ziņojumi
  • Izveidot ziņojumu
  • Dzēst ziņojumu
  • Pašziņa
  • Atbildēt uz ziņojumu
  • Atrasts ziņojums
  • Pazaudēta ziņa
  • Aizsargi
• Kā izveidot secības diagrammas?
• Secību diagrammu izmantošanas gadījumi
• Izaicinājumi, izmantojot secības diagrammas

1. Secības diagrammas apzīmējums

1.1. Aktieri

Aktieris UML diagrammā attēlo lomu, kurā tas mijiedarbojas ar sistēmu un tās objektiem. Šeit ir svarīgi atzīmēt, ka dalībnieks vienmēr atrodas ārpus tās sistēmas darbības jomas, kuru mēs vēlamies modelēt, izmantojot UML diagrammu.

Mēs izmantojam aktierus, lai attēlotu dažādas lomas, tostarp cilvēkus un citus ārējus objektus. Mēs attēlojam aktieri UML diagrammā, izmantojot nūjas personas apzīmējumu. Mums var būt vairāki dalībnieki secības diagrammā.

Piemēram:

Šeit lietotājs vietu rezervēšanas sistēmā tiek parādīts kā dalībnieks, ja tas eksistē ārpus sistēmas un nav sistēmas sastāvdaļa.

1.2. Dzīves līnijas

Dzīves līnija ir nosaukts elements, kas attēlo atsevišķu dalībnieku secības diagrammā. Tātad būtībā katrs secības diagrammas gadījums ir attēlots ar glābšanas līniju. Dzīves līnijas elementi atrodas secības diagrammas augšpusē. UML standarts glābšanas līnijas nosaukšanai ir šāds:

Gadījuma nosaukums: klases nosaukums

algoritma dziļuma pirmā meklēšana

Mēs parādām glābšanas līniju taisnstūrī ar nosaukumu galvu ar tā nosaukumu un veidu. Galva atrodas vertikālas pārtrauktas līnijas augšpusē (saukta par kātu), kā parādīts iepriekš.

• Ja mēs vēlamies modelēt nenosauktu gadījumu, mēs sekojam tam pašam modelim, izņemot to, ka tagad dzīvības līnijas nosaukuma daļa ir atstāta tukša.
• Atšķirība starp glābšanas riņķi ​​un aktieri
  • Glābšanas līnija vienmēr attēlo objektu, kas atrodas sistēmā, turpretī aktieri tiek izmantoti, lai attēlotu objektus ārpus sistēmas.

Tālāk ir sniegts secības diagrammas piemērs.

1.3. Ziņojumi

Saziņa starp objektiem tiek attēlota, izmantojot ziņojumus. Ziņojumi tiek parādīti dzīvības līnijā secīgā secībā.

• Mēs attēlojam ziņojumus, izmantojot bultiņas.
• Dzīves līnijas un ziņojumi veido secības diagrammas kodolu.

Ziņojumus var plaši iedalīt šādās kategorijās:

Sinhronās ziņas

Sinhrons ziņojums gaida atbildi, pirms mijiedarbība var turpināties. Sūtītājs gaida, līdz saņēmējs ir pabeidzis ziņojuma apstrādi. Zvanītājs turpina tikai tad, kad zina, ka saņēmējs ir apstrādājis iepriekšējo ziņojumu, t.i., tas saņem atbildes ziņojumu.

• Liels skaits objektu orientētās programmēšanas zvanu ir sinhroni.
• Mēs izmantojam a cieta bultas galva lai attēlotu sinhronu ziņojumu.

Asinhronās ziņas

Asinhronais ziņojums negaida atbildi no saņēmēja. Mijiedarbība virzās uz priekšu neatkarīgi no tā, vai saņēmējs apstrādā iepriekšējo ziņojumu vai nē. Mēs izmantojam a izklāta bultas galva lai attēlotu asinhronu ziņojumu.

1.4. Izveidot ziņojumu

Mēs izmantojam ziņojumu Izveidot, lai secības diagrammā izveidotu jaunu objektu. Pastāv situācijas, kad konkrētam ziņojumam ir nepieciešams izveidot objektu. Tas ir attēlots ar punktētu bultiņu, un uz tā ir marķēts vārds, lai norādītu, ka tas ir ziņojuma izveides simbols.

Piemēram:

Lai izveidotu jaunu pasūtījumu e-komercijas vietnē, būtu jāizveido jauns Pasūtījumu klases objekts.

1.5. Dzēst ziņojumu

Objekta dzēšanai mēs izmantojam Dzēst ziņojumu. Ja objektam tiek atbrīvota atmiņa vai tas tiek iznīcināts sistēmā, mēs izmantojam simbolu Dzēst ziņojumu. Tas iznīcina objekta rašanos sistēmā. To attēlo bultiņa, kas beidzas ar x.

Piemēram:

atrodiet kartē c++

Zemāk redzamajā scenārijā, kad pasūtījumu saņem lietotājs, pasūtījuma klases objekts var tikt iznīcināts.

1.6. Pašziņa

Var rasties daži scenāriji, kad objektam ir jānosūta ziņojums sev. Šādus ziņojumus sauc par pašziņojumiem, un tie ir attēloti ar a U formas bultiņa .

Vēl viens piemērs:

Apsveriet situāciju, kad ierīce vēlas piekļūt savai tīmekļa kamerai. Šāds scenārijs tiek attēlots, izmantojot pašziņojumu.

1.7. Atbildēt uz ziņojumu

Atbildes ziņojumi tiek izmantoti, lai parādītu ziņojumu, kas tiek nosūtīts no saņēmēja sūtītājam. Mēs pārstāvam atgriešanas/atbildes ziņojumu, izmantojot atvērta bultiņas galva ar punktētu līniju . Mijiedarbība virzās uz priekšu tikai tad, kad saņēmējs nosūta atbildes ziņojumu.

Piemēram:

Apsveriet situāciju, kad ierīce pieprasa lietotāja fotoattēlu. Šeit ziņojums, kas parāda nosūtīto fotoattēlu, ir atbildes ziņojums.

1.8. Atrasts ziņojums

Atrasts ziņojums tiek izmantots, lai attēlotu scenāriju, kad nezināms avots nosūta ziņojumu. Tas tiek attēlots, izmantojot an bulta, kas vērsta pret glābšanas līniju no beigu punkta.

java string.format

Piemēram:

Apsveriet aparatūras kļūmes scenāriju.

Tam var būt vairāki iemesli, un mēs neesam pārliecināti par to, kas izraisīja aparatūras kļūmi.

1.9. Pazaudēta ziņa

Pazaudēts ziņojums tiek izmantots, lai attēlotu scenāriju, kurā adresāts sistēmai nav zināms. Tas tiek attēlots, izmantojot bultiņu, kas vērsta uz dzīves līnijas gala punktu.

Piemēram:

Apsveriet scenāriju, kurā tiek ģenerēts brīdinājums.

Brīdinājums var tikt ģenerēts lietotājam vai citai programmatūrai/objektam, ar kuru mijiedarbojas glābšanas līnija. Tā kā galamērķis iepriekš nav zināms, mēs izmantojam simbolu Lost Message.

1.10. Aizsargi

Lai modelētu apstākļus, mēs izmantojam aizsargus UML. Tos izmanto, ja mums ir jāierobežo ziņojumu plūsma, aizbildinoties ar nosacījuma izpildi. Apsargiem ir svarīga loma, ļaujot programmatūras izstrādātājiem uzzināt par ierobežojumiem, kas saistīti ar sistēmu vai konkrētu procesu.

Piemēram:

Lai varētu izņemt skaidru naudu, ja atlikums ir lielāks par nulli, ir jāievēro nosacījums, kā parādīts zemāk.

Iepriekš redzamā secības diagramma attēlo secības diagrammu uz emocijām balstītam mūzikas atskaņotājam:

1. Vispirms lietojumprogrammu atver lietotājs.
2. Pēc tam ierīce iegūst piekļuvi tīmekļa kamerai.
3. Tīmekļa kamera uzņem lietotāja attēlu.
4. Ierīce izmanto algoritmus, lai noteiktu seju un prognozētu noskaņojumu.
5. Pēc tam tas pieprasa datu bāzi iespējamo noskaņojumu vārdnīcai.
6. Noskaņojums tiek izgūts no datu bāzes.
7. Lietotājam tiek parādīts noskaņojums.
8. Mūzika tiek pieprasīta no datu bāzes.
9. Atskaņošanas saraksts tiek ģenerēts un beidzot parādīts lietotājam.

2. Kā izveidot secības diagrammas?

Secību diagrammas izveide ietver vairākas darbības, un to parasti veic programmatūras izstrādes projektēšanas fāzē, lai ilustrētu dažādu komponentu vai objektu mijiedarbību laika gaitā. Tālāk ir sniegts detalizēts ceļvedis, kā izveidot secības diagrammas.

1. Identificējiet scenāriju:
   • Izprotiet konkrēto scenāriju vai lietošanas gadījumu, ko vēlaties attēlot secības diagrammā. Tā varētu būt konkrēta mijiedarbība starp objektiem vai ziņojumu plūsma noteiktā procesā.
2. Dalībnieku saraksts:
   • Identificējiet scenārijā iesaistītos dalībniekus (objektus vai dalībniekus). Dalībnieki var būt lietotāji, sistēmas vai ārējās vienības.
3. Definējiet dzīvības līnijas:
   • Katram dalībniekam uzzīmējiet vertikālu pārtrauktu līniju, kas atspoguļo katra objekta dzīves līniju laika gaitā. Dzīves līnija atspoguļo objekta esamību mijiedarbības laikā.
4. Sakārtojiet dzīvības līnijas:
   • Novietojiet dzīvības līnijas horizontāli tādā secībā, kādā tās ir iesaistītas mijiedarbībā. Tas palīdz vizualizēt ziņojumu plūsmu starp dalībniekiem.
5. Pievienot aktivizācijas joslas:
   • Katram ziņojumam uzzīmējiet aktivizācijas joslu uz sūtītāja dalībnieka glābšanas līnijas. Aktivizācijas josla norāda laiku, kurā dalībnieks aktīvi apstrādā ziņojumu.
6. Zīmēt ziņojumus:
   • Izmantojiet bultiņas, lai attēlotu ziņojumus starp dalībniekiem. Ziņojumi plūst horizontāli starp dzīvības līnijām, norādot uz saziņu starp objektiem. Dažādu veidu ziņojumi ietver sinhronos (nepārtrauktās bultiņas), asinhronos (punktētās bultiņas) un pašziņojumus.
7. Iekļaut atbildes ziņojumus:
   • Ja dalībnieks nosūta atbildes ziņojumu, uzzīmējiet svītrotu bultiņu, kas atgriežas pie sākotnējā sūtītāja, lai attēlotu atbildes ziņojumu.
8. Norādiet laiku un secību:
   • Izmantojiet ciparus, lai norādītu ziņojumu secību secībā. Varat arī izmantot vertikālas pārtrauktas līnijas, lai attēlotu notikumu vai laika ritējumu.
9. Iekļaut nosacījumus un cilpas:
   • Izmantojiet kombinētos fragmentus, lai attēlotu nosacījumus (piemēram, if paziņojumus) un cilpas mijiedarbībā. Tas padara secības diagrammu sarežģītāku un palīdz detalizēt vadības plūsmu.
10. Apsveriet paralēlo izpildi:
    • Ja notiek paralēlas darbības, attēlojiet tās, zīmējot paralēlas vertikālas pārtrauktas līnijas un attiecīgi izvietojot ziņojumus.
11. Pārskatīt un uzlabot:
    • Pārskatiet secības diagrammu skaidrības un pareizības labad. Pārliecinieties, vai tas precīzi atspoguļo paredzēto mijiedarbību. Precizējiet pēc vajadzības.
12. Pievienot anotācijas un komentārus:
    • Iekļaujiet jebkādu papildu informāciju, anotācijas vai komentārus, kas sniedz kontekstu vai paskaidrojumus par diagrammas elementiem.
13. Dokumentu pieņēmumi un ierobežojumi:
    • Ja ir kādi pieņēmumi vai ierobežojumi saistībā ar mijiedarbību, dokumentējiet tos kopā ar diagrammu.
14. Rīki:
    • Izmantojiet UML modelēšanas rīku vai diagrammu programmatūru, lai izveidotu glītu un profesionāla izskata secību diagrammu. Šie rīki bieži nodrošina funkcijas vienkāršai rediģēšanai, sadarbībai un dokumentēšanai.

3. Secību diagrammu izmantošanas gadījumi

• Sistēmas uzvedības vizualizācija:
  • Secību diagrammas tiek izmantotas, lai ilustrētu sistēmas dinamisko uzvedību, parādot dažādu komponentu, objektu vai dalībnieku mijiedarbību laika gaitā.
  • Tie nodrošina skaidru un vizuālu ziņojumu un notikumu plūsmas attēlojumu konkrētā scenārijā.
• Programmatūras dizains un arhitektūra:
  • Programmatūras izstrādes projektēšanas posmā secību diagrammas palīdz izstrādātājiem un arhitektiem plānot un saprast, kā dažādi komponenti un objekti mijiedarbosies, lai veiktu noteiktas funkcijas.
  • Tie nodrošina sistēmas darbības plānu.
• Komunikācija un sadarbība:
  • Secību diagrammas kalpo kā saziņas rīks starp ieinteresētajām personām, tostarp izstrādātājiem, dizaineriem, projektu vadītājiem un klientiem.
  • Tie palīdz nodot sarežģītas mijiedarbības viegli saprotamā vizuālā formātā, veicinot sadarbību un kopīgu izpratni.
• Prasību precizējums:
  • Precizējot sistēmas prasības, secību diagrammas var izmantot, lai precizētu un norādītu paredzamo mijiedarbību starp sistēmas komponentiem vai starp sistēmu un ārējām entītijām.
  • Tie palīdz nodrošināt vienotu izpratni par sistēmas uzvedību starp visām ieinteresētajām personām.
• Atkļūdošana un traucējummeklēšana:
  • Izstrādātāji izmanto secību diagrammas kā atkļūdošanas rīku, lai identificētu un analizētu problēmas, kas saistītas ar ziņojumu secību un laiku sistēmas mijiedarbības laikā.
  • Tas nodrošina kontroles plūsmas vizuālu attēlojumu un palīdz atrast un atrisināt problēmas.

4. Secību diagrammu izmantošanas izaicinājumi

• Sarežģītība un izmērs:
  • Sistēmām pieaugot sarežģītībai, secību diagrammas var kļūt lielas un sarežģītas. Diagrammas lieluma pārvaldība, vienlaikus precīzi attēlojot mijiedarbību, var būt sarežģīta, un pārāk sarežģītas diagrammas var kļūt grūti saprotamas.
• Abstrakcijas līmenis:
  • Pareiza līdzsvara panākšana abstrakcijas ziņā var būt izaicinājums. Secību diagrammām ir jābūt pietiekami detalizētām, lai sniegtu nepieciešamo informāciju, taču pārāk daudz detaļu var nomākt lasītājus. Ir svarīgi koncentrēties uz vissvarīgākajām mijiedarbībām, neiegrimstot sīkumos.
• Dinamiskā daba:
  • Secību diagrammas atspoguļo sistēmas dinamiskos aspektus, un tāpēc izstrādes procesā tās var bieži mainīties. Secību diagrammu atjaunināšana saistībā ar sistēmas attīstību var būt izaicinājums, jo īpaši strauji mainīgā vai elastīgā izstrādes vidē.
• Neskaidrības ziņojumos:
  • Dažreiz var būt grūti noteikt precīzu ziņojumu raksturu starp objektiem. Neskaidrība ziņojuma saturā vai nozīmē var izraisīt pārpratumus starp ieinteresētajām personām un ietekmēt secības diagrammas precizitāti.
• Vienlaicība un paralēlisms:
  • Vienlaicīgu un paralēlu procesu attēlošana var būt sarežģīta. Lai gan secību diagrammās ir mehānismi, kas norāda uz paralēlu izpildi, vairāku vienlaikus notiekošu mijiedarbību vizualizācija var būt sarežģīta un var prasīt papildu diagrammas elementus.
• Reāllaika ierobežojumi:
  • Reāllaika ierobežojumu un precīzu laika prasību atspoguļošana var būt sarežģīta. Lai gan secību diagrammas nodrošina secīgu attēlojumu, reāllaika aspektu precīzai uztveršanai un paziņošanai var būt nepieciešama papildu dokumentācija vai papildu diagrammas.