Šiam straipsniui ar jo daliai trūksta išnašų į patikimus šaltinius Jūs galite padėti Vikipedijai pridėdami tinkamas išna

Šiam straipsniui ar jo daliai .
Jūs galite padėti Vikipedijai pridėdami su šaltiniais.

Panaudos atvejų diagrama (Užduočių diagrama) (angl. use case diagram) – UML diagrama, aprašanti ką projektuojama sistema gali atlikti, kartu aprašydama ir išorinius sistemos veikėjus (aktorius). Didelėms sistemoms ši diagrama skirstoma į posistemes. Pagrindinis šios diagramos elementas – , aprašantis aibę panašių sąveikos scenarijų. Kiekvienas panaudos atvejis paprastai turi vieną pagrindinį ir keletą šalutinių scenarijų, kurie aprašomi dinaminėmis UML diagramomis (sekų, bendradarbiavimo, veiklos).

Panaudojimo atvejų diagramą ir metodą sugalvojo švedas , šiuo metu Microsoft kuriantis naują metodiką .

Šį puslapį ar jo dalį reikia pagal .
Jei galite, sutvarkykite.

USE Case metamodelis

UML (Unifield Modeling Language, Vieninga modeliavimo kalba) – modeliavimo ir specifikacijų kūrimo kalba, skirta specifikuoti, atvaizduoti ir konstruoti objektiškai orientuotų programų dokumentus.

Sistemos funkcionalumas yra padalinamas į operacijas („panaudos atvejus“), kurios yra svarbios vartotojams („aktoriams“). Aprašo sistemos įvykių seką ir sistemos atsaką į sistemos aktorių veiksmus. Rodo reikalavimus, o ne realizavimo detales. Jo tikslas pavaizduoti grafiškai bendrą funkcionalumo supratimą aprūpinant sistemą aktorių išraiška, jos tikslas – pavaizduoti kaip veikla – ir jų priklausomybe tarp veiklų. Kol SysML tokia pat žymėjimas kaip panaudos atvejų UML, sistemos inžinieriai modeliuoja sistemoje ar sistemų sistemų lygiuose.

UML panaudos atvejų diagrama

OMG UML standartai apibrėžia grafinį žymėjimą panaudos atvejų diagramose, bet ne formatą aprašantis panaudos atvejus. Kol grafinis aprašymas ir apibūdinimas yra svarbūs, jie yra panaudos atvejų dokumentacija – tikslas, kad aktoriai gali naudotis sistema. Teisinga panaudos atvejų vertė išdėstytą dviejuose laukuose.

Raštu aprašyti sistemos funkcionalumą laikantis verslo taisyklių ar poreikių. Šis aprašymas sutelkia vertingą sistemos vertę išorinėms esybėms, tokiems kaip žmonių vartotojams ar kitoms sistemoms.

Padėtis ar situacija panaudos atvejų tarp kitų panaudos atvejų. Kaip suorganizuotas mechanizmas, suteikti pastovumą, vaizdžiau pavaizduoti sistemos funkcionalumą susietomis panaudos atvejus naudingame paveikslėlyje, paplitęs susitarimas tarp pirkėjų, savininkų, naudotojų ir kūrėjų komandos.

Panaudos atvejų diagrama:elementai

panaudos atvejis

Veiksmų seka (įskaitant jų variantus), kurią sistema gali atlikti sąveikaudama su sistemos aktoriais.

aktorius

Su sistema sąveikaujantis vartotojas (kita išorės sistema).

sistemos riba

Vaizduoja ribą tarp sistemos ir aktorių, kurie sąveikauja su sistema.

Panaudos atvejų diagrama:ryšiai

asociacija

Aktoriaus dalyvavimas panaudos atvejyje, t. y., aktoriaus egzempliorius ir panaudos atvejis bendrauja tarpusavyje.

apibendrinimas

Ryšys tarp bendresnio panaudos atvejo ir konkretesnio panaudos atvejo.

įtraukimas "include"

Ryšys, nurodantis, kaip bazinio panaudos atvejo elgsena priklauso nuo įtraukiamo panaudos atvejo elgsenos. Bazinis panaudos atvejis priklauso nuo įtraukiamo panaudos atvejo.

išplėtimas "extend"

Ryšys, nurodantis, kaip išplėsto panaudos atvejo elgsena priklauso nuo bazinio panaudos atvejo elgsenos. Bazinis panaudos atvejis nepriklauso nuo išplėtimo panaudos atvejo.

UML panaudos atvejų pavyzdys: Restorano sistema

Teisingoje diagramoje pavaizduojamos paprastas Restorano sistemos funkcionalumas. Panaudos atvejai yra pervaizduojamos ovalais ir aktoriai yra pervaizduojami šakos figūra. Nuolatinis aktorius gali valgyti maistą, mokėti už maistą ar gerti vyną. Tiktai virėjo aktorius gali gaminti maistą. Atkreipsime dėmesį, kad Nuolatinis klientas ir Kasininkas yra susieti mokėti už maistą panaudos atveju. Dėžė aprašo restorano sistemos ribas, t. y. panaudos atvejis yra sistemos dalis modeliuojantis. aktorius nėra. Bendravimas tarp aktorių nėra parodyta panaudos atvejų diagramoje. Jeigu šis bendravimas yra svarbiai susijęs aprašant trokštamą funkcionalumą, galbūt sistema ar panaudos atvejo ribos reiktų iš naujo nagrinėjamos. Kitaip sąveika tarp aktorių gali būti dalis prielaidos naudojant panaudos atvejyje.