Süsteemianalüüs - Kolmanda loengutöö konspekt (0)

Near far wherever UML are
1. Tarkvara Nõuete analüüs
Äri(...tegelt ka või see on kuradi esimene vastus??) modelleerimise (distsiblinni) tulemused annavad konteksti ning “keele” (põhimõistestiku) tarkvara nõuete püstitamiseks. Iteratiivses arendusprotsessis UP toimub tarkvara nõuete püstitamine ja analüüs põhiliselt tarkvara kasutusjuhtude kirjutmise, modelleerimise ja analüüsimise kaudu.
2. Kasutusjuhtude mudel ehk (kui te olete inglise keeles väga sitt juhuslikult) Use Case Model
UP defineerib Use Case mudeli nõuete analüüsi distsiblinni sees. Use Case mudel on kõikide kasutusjuhtude hulk: süsteemi funktsionaalsuse(kasutusjuhud) ja keskkonna(tegutsejad) mudel
Eesmärgid ja kasutuslood
Tellijad ja lõppkasutajad omavad eesmärke (goals, UP-s needs , sest UP on needy motherfucker) ning soovivad, et süsteem aitaks neid täita. Kasutusjuhud on jutustused süsteemi kasutamisest nende eesmärkide täitmiseks.
Näide:
Ülikoolis käimine:
Kursus avastab et homme on loengutöö, mida nad soovivad läbida edukalt (vähemalt hindele 1. Kursus avastab, et saab juutida ühe kursusekaaslase konspekte. Nad sisestavad FB textboxi oma appikarjed ja Süsteem edastab need kursusekaaslasele. Kursusekaaslane võib valida kas neid sõnumeid ignoreerida või olla aasta inimene 2016 . Kursusekaaslane avaldab lingi materjalidele ja annab ligipääsu teistele.
Ok see oli veits õel. Te olete nummid. I’m sorry .
Probleem? (Mart, kas sa oled salamisi dank meemer??)
Kiputakse üle tähtsustama teisejärgulisi probleeme nagu kasutusjuhu diagrammid , seosed, paketid, mittekohustuslikud atribuudid jne, selle asemel, et kirjutada lslt kõigile arusaavad kasutuslood.
Kasutusjuhtude tugevus seisneb selles, et nad skaleeruvad (the fuck ?) keerukuses ja formaalsuses nii üles kui allapoole, vastavalt vajadusele.
Use case vs Stsenaarium
Stsenaarium - konktreetne tegevuste ja suhtlemiste järjestus tegutsejate ning käsitletava süsteemi vahel. Stsenaarium on kasutusjuhu eksemplar , üks võimalik tee läbi kasutusjuhu (nt Ülikoolis käimise stsenaariumeid on kaks - te kas saate konspekti või mitte).
Kasutusjuht - seotud (edukate ja mitteedukate) stsenaariumite kogum, mis kirjeldavad tegutsejaid kasutamas süsteemi oma eesmärkide toetamiseks.
EHK KASUTUSJUHT koosneb STSENAARIUMITEST. Stsenaariumid on võimalikud kasutusjuhu käekäigud ehk kõik hargnevused ja võimalused mis võivad juhtuda.
3. Juhuformaat
Kasutusjuhu kirjeldamiseks kasutatav formaat , mis sisaldab ka alternatiivseid stsenaariumeid.
Kasutusjuht: Ülikoolis käimine
Põhiline edukas stsenaarium: Tudengid edastavad oma palved kursusekaaslasele, kes jagab vajalikke google drive linke , et kõik saaksid konspekti kasutada.
Alternatiivsed stsenaariumid:
1. Google drive on persses
2. Kursusekaaslasel pole internetti ja näeb sõnumeid alles hommikul kuna ta läheb normaalsel ajal magama.
3. Kursusekaaslane otsustab olla cunt ja keelduda jagamisest.
4. Tegutseja väärtus
Kasutusjuht loob tegutsejale väärtuse. Oma olemuselt on ta stsenaariumite hulk (mida me õppisime mõnikümmend rida kõrgemal caps lockis), millest igaüks on süsteemi poolt läbiviidavate tegevuste jada mille tulemus on jälgitav ja see annabki konkreetsele tegutsejale väärtuse.
Süsteemi nõuetest ei tohi mõelda kui lihtsalt funktsioonide ja omaduste loetelust. Peab keskenduma küsimusele: Kuidas saab süsteemi kasutada nii, et see annaks kasutajatele jälgitava väärtuse e täidaks nende eesmärke.
5. Täieliku kirjelduse formaat e laiformaat
Koosneb:
1. Sissejuhatavad elemendid (kõige tähtsamad elemendid paigutatakse põhilise eduka stsenaariumi ette)
2. Eeltingimused ja Edu Garantiid (Järeltingimused)
3. Põhiline Edukas Stsenaarium ja selle sammud (e põhivoog)
4. Laiendused (e alternatiivsed vood )
5. Erinõuded ( special requirements)
6. Tehnoloogia ja Andmete Variatsioonide loetelu
1. Sissejuhatavad elemendid
Primaarne tegutseja : Põhiline tegutseja, kes kasutab süsteemi oma eesmärkide täitmiseks
Osapoolte ja huvide loetelu: Praktikas hullult tähtis, soovitab ja piirab mida süsteem peaks tegema. Süsteem täidab lepingut osapoolte vahel, kasutusjuhud täpsustavad selle lepingu käitumuslikke osi. Kasutusjuht on leping käitmise jaoks, mis hõlmab kõiki ja ainult neid käitumisi, mis on seotud osapoolte huvide rahuldamisega.
Küsimus: Mis peaks sisalduma kasutusjuhus? Ainult see, mis rahuldab kõigi osapoolte huvisid ehk palun mitte suvalist sitta panna sinna, et sõnamahtu täis saada me pole keskkoolis ja +/- 10% kehtib vist ülikoolis ka.
NÄIDE
Primaarne tegutseja:
Tudeng
Osapooled ja Huvid:
Tudeng: Soovib korraliku, mitte powerpoindi kujul materjali, mis on täis huumorit, mis on sama must kui Anne Franki söestunud luud , sest kui materjali ei oska siis ta peab loobuma analüütiku tööst ja hakkama kingseppaks (mis tundub nagu sitaks fun töö see on mu tagavaravariant).
Kursusekaaslane: Soovib häid karmapunkte ja tahab rahuldada oma haiglast vajadust inimestele meeldida. (See oli nali...VÕI KAS OLI??? nvm)
2. Eeltingimused - määravad, mis peab olema tõene enne use case-i stsenaariumi alustamist. Neid ei esitata kasutusjuhu sees, vaid eeldatakse, et on tõesed. Tüüpiliselt eeltingimus tähendab mingi teise kasutusjuhu edukat lõppemist.
Edu garantiid e järeltingimused - määravad, mis peab olema tõene kasutusjuhu eduka lõpetamise korral (PS! Nii põhistsenaariumi kui ka mingi alternatiivse tee korral)
NÄIDE
Eeltingimused: Tudengil on internetiühendus
Järeltingimused: Sõnumid on kursusekaaslaseni jõudnud, link on jagatud kõigi tudengitega.
3. Põhivoog
Kirjeldab tüüpilist edukat kulgu, mis rahuldab osapoolte vajadusi/huvisid, enamasti EI SISALDA ühtegi tingimust ega hargnemist (need soovitatakse paigutada laienduste osasse)
Stsenaarium koosneb kolme liiki sammudest:
1. Suhtlemione tegutsejate (sh süsteem) vahel
2. Kontrollimine (tavaliselt süsteemi poolt)
3. Seisundi muutmine süsteemi poolt (nt millegi salvestamine , muutmine)
Kasutusjuhu esimene samm tavaliselt ei allu sellele klassifikatsioonile, vaid kirjeldab stsenaariumi käivitavat sündmust.
NÄIDE
1. Tudeng edastab oma sõnumid kursusekaaslasele.
2. Kursusekaaslane laeb materjalid Drive’i ja postitab lingid kohta, kus võimalikult palju tudengeid pääseb sellele ligi.
3. Kõik saavad süsteemi max punktid!!!!
4. Laiendused e alternatiivsed vood
Super tähtsad, kuna näitavad kõike mis võib pucci minna. Nende osa on tüüpiliselt pikem ja keerukam kui põhilise eduka stsenaariumi osa. Õnneliku tee ja laienduste stsenaariumite kombinatsioon peaks rahuldama peaaegu kõiki osapoolte huvisid.
NÄIDE
1a. Tudengi sõnumid ei jõua kohale interneti ühenduse puudmise tõttu
1. Süsteem teatab veast ja ruuterile tehakse restart.
1b. Kursusekaaslane on magama läinud
1. Tudeng peab pikast vaikusest ise järeldama, et kursusekaaslane magab ja mõtlema välja, kas saaks kuskilt ta telefoni numbri
Jne
Laiendusel on kaks osa: tingimus ja käsitlemine. Tingimus VÕIB täituda mitme sammu vahemikus.
Laienduse käsitlemise lõpus vaikimisi stsenaarium ühineb põhilise eduka stsenaariumiga kui laiendus ei näita teisiti (nt süsteemi peatamine, või kursusekaaslane on juba magama läinud ja telefoni hääletule lükanud). Vahel on konkreetne laienduspunkt piisavalt keerukas, et seda saab väljendada eraldi kasutusjuhuna.
Nendes saab ka käsitleda vigu. Kui soovitakse kirjeldada laiendamise tingimust, mis võib tekkida igas või enamuses sammudest võib kasutada märgendeid *a, *b
NÄIDE
*a. Iga kord kui internetiühendus kaob:

Osapool teeb oma ruuterile restardi
5. Erinõuded
Kui mitefunktsionaalne nõue, kvaliteediatribuut v piirang on seotud spetsiaalselt kindla kasutusjuhuga, siis salvestatakse see koos vastava kasutusjuhuga.
NÄIDE
Kursusekaaslasel peab olema piisavalt viitsmist ja ta peab givema vähemalt paar shitti sellest kuidas teistel läheb.
6. Tehnoloogia ja Andmete Variatsioonide loetelu
Varased disaini otsused, mille esitamist varastes iteratsioonides üldiselt peaks vältima. Sageli on need seotud konktreetse sisend -väljund tehnoloogia või konkreetsete klassifikaatorite kasutamisega konkreetse kasutaja poolt. Siin ei tohiks kirjeldada paljusid erinevaid võimalusi ja hargnemisi (see sobiks laienduste alla).
NÄIDE
1a. Sõnumid edastatakse üle interneti ja sisestatakse klaviatuurilt
6. Nõuded
Süstemaatilist nõuete analüüsi nimetatakse ka nõuete inseneeriaks või siis, nõuete kogumiseks või nõuete spetsifitseerimiseks. Nõuete inseneeria on tarkvaratehnika ja süsteemitehnika alamdistsipliin.
Tarkvara nõue on omadus, mida tarkvara peab omama/väljendama selleks, et lahendada konkreetset probleemi reaalses maailmas. Lahendatavaks probleemiks võib olla organisatsiooni äriprotsessis osaleva tarkvarakasutaja konkreetse tööülesande mingi osa automatiseerimine.
Nõuete analüüsi kolm baasi *wink wink* when’s the homerun
Nõuete kogumine - Suhtlemine tellijatega/kasutajatega selleks, et välja selgitada nende nõuded.
Nõuete analüüsimine - kindlaks tegemine, kas püstitatud nõuded on ebaselged, mittetäielikud, mitmetähenduslikud, või vastuolulised, ja siis nende probleemide lahendamine.
Nõuete salvestamine - Nõuded võivad olla dokumenteeritud erinevates vormides nagu tekstidokumendid, kasutusjuhud, kasutuslood või protsessispetsifikatsioon.
Nõudeid on kaht liiki:
Funktsionaalsed - Mida süsteem peab tegema?
Mittefunktsionaalsed - ehk kvaliteedinõuded, Milline peab süsteem olema?
Arhitektuurinõuded - läbivad süsteemi kõiki osi
Disaininõuded - puudutavad süsteemi konkreetset osa
1. User Story e Funktsionaalne nõue
Formaat (Muster) - (Kellena) ma soovin (eesmärk) selleks et (põhjus)
Näited: Tudengina ma soovin konspekti selleks et ma ei põruks elus.
2. Mittefunktsionaalne nõue
Piirang, millele süsteem peab alluma. Mõnikord puudutavad piirangud kindlaid kasutusjuhtusid (disaini nõudeid). Enamasti on mittefunktsionaalseteks nõueteks kogu süsteemi puudutavad piirangud (arhitektuuri nõuded).
Näiteks: Piirang oleks, et tudeng peab olema vähemalt 18 aastane.
FURPS+ mudel: nõuete tüübid
FURPS mudel organiseerib kõik nõuded viide kategooriasse:
F - Functional U - Usability R - Reliability P - Performance S - Supportability, FURPS + lisab veel mõned kategooriad.
Kasutatavus
Eeldatav kasutaja kompetents/kogemus
Kasutajaliidese standardite rakendamine
Dokumentatsiooni ja juhendite võimaldamine
Usaldusväärsus
Töökindluse ja turvalisuse nõuded
Süsteemi kättesaadavus, lihtsus ja usaldusväärsus
Veakäsitlus, vigade vaheline aeg
Veakindlus
Andmete kaotamise (mitte)lubatavus
Jõudlus
Kutid, ma olen nii magamata, what is this even ? Miks see relevant on hahaha what is going on?
Paralleelkasutajate arv
Reaktsiooniaeg
Toimingute arv sekundis
Toetatavus
Kuidas süsteemi laiendatakse/muudetakse?
Kes hooldab(hoiab ülal) süsteemi?
Implementeerimine
Platvorm ? (Platvorm mis? Saapad ? Käi mööda mu selga nendega)
Liidesed
Liidesed olemasolevate süsteemidega
Kasutatavad/toetatavad protokollid
Toimimine (Operation)
Kes juhib töötavat süsteemi?
Pakendamine (Packaging)
Kes installeerib süsteemi?
Erinevate installeerimiste arv?
Juriidika (Legal)
Litsensid?
Vastutuse küsimused?
Litsensitasud või kohustused, mis tulenevad kolmandate osapoolte komponentide või algoritmide kasutamisest?
Nõuded omavad seoseid :
Funktsionaalne - mittefunktsionaalne
Vastuolu seos
Sisalduvusseos
Hästidefineeritud nõue on (SWEBOK, SE2004 järgi (tra mart ei pane enam mingi keerulise triipkoodiga küsimust)) - korrektne , täielik, selge, kooskõlaline , verifitseeritav, jälgitav, tostatav, modulaarne , disainist sõltumatu
7. Elementaarne äriprotsess
Nõuete analüüsis konkreetse arvutirakenduse jaoks keskenda use case-id elementaarsete äriprotsesside (EBPs) tasandile .
EBP on ülesanne, mis teostatakse ühe isiku poolt kindlas asukohas kindlal ajal vastuseks ärisündmusele; mis lisab mõõdetavat äriväärtust ning annab andmed kooskõlalises seisundis.

• See ei ole väike tehniline samm nagu “kustuta rida” või “trüki dokument”. Põhiline edukas stsenaarium sisaldab tavaliselt 5-10 sammu
  
• Ta ei kesta päevi, ega hõlma paljusid seansse nagu “hankelepingu läbirääkimised”. Ta on ülesanne, mis täidetakse ühe seansiga ning kestab mõned minutid kuni tund
  
• Viib süsteemi ja andmed stabiilsesse kooskõlalisse seisundisse, lisades jälgitava või mõõdetava äriväärtuse
  
• Tavaline viga on paljude use case-ide defineerimine liiga madalal tasemel, nagu EBP üksiks samm, alamfunktsioon, alamülesanne.
  

8. Alamkasutusjuhud
Kuigi rakenduste puhul kasutusjuhud peaks järgima EBPd, siis vahel on ikkagi normaalsem luua eraldi “alam” (haha dom) use case-id, mis esindavad põhilise use case-i alamülesandeid või samme.
Näiteks, alamülesannet või laiendust “ maksmine krediitkaardiga” võib korrata erinevates põhilistes kasutusjuhtudes. Et ei peaks dubleerima teksti, siis on mõtekam eraldada ta omaette use case-iks (mis ei täida EBP juhtnööri) ning linkida (include seosega) see erinevate põhiliste kasutusjuhtudega.
Ka madalama taseme tegevust, mis on paljude põhiliste kasutusjuhtude eeltingimuseks (nt “identifitseerimine”) võib kirjutada eraldi kasutusjuhuna. Arvukate mahukate madala taseme kasutusjuhtude kirjutamist soovitatakse vältida.
9. Kasutusjuhud ja eesmärgid
EBP taseme kasutusjuhtu nimetatakse ka kasutaja eedmärgi taseme kasutusjuhuks, sest see täidab süsteemi kasutaja/ primaarse tegutseja konkreetset eesmärki. Soovtav tegevuste järjekord on 1. Leia kasutajate eesmärgid 2. Defineeri kasutusjuht iga eesmärgi jaoks.
Mida te teete (otseselt kasutusjuhtudele orienteeritud küsimus) vs Millised on teie eesmärgid.
Esimese küsimuse vastus peegeldab pigem olemasolevaid lahendusi ja protseduure, teise küsimuse vastused avavad visiooni uutele ja parematele lahendustele, mida osapooltel on tegelikult vaja. EHK esimesega saate teada mis on, teine küsimus annab võimaluse arendada midagi paremat välja.
10. Kasutusjuhtude defineerimine
Seda tehakse kasutajate eesmärkide täitmiseks, seetõttu:
1. Määra süsteemi piirid. Kas on tegemist tarkvararakendusega ( riistvara , rakendus + inimkasutaja) või terve organisatsioon ?
2. Tuvasta Kasutajad/Primaarsed tegutsejad, kes omavad eesmärke, mida täidab süsteem.
3. Leia iga kasutaja jaoks tema eesmärgid. Tõsta need kõige kõrgemale kasutajaeesmärkide tasemele , mis veel rahuldab EBP tingimust.
4. Defineeri kasutusjuhud, mis rahuldavad kasutajaeesmärke, nimeta need vastavalt oma eesmärgile .
11. Sündmusanalüüs
Tegutsejaid, eesmärke ja kasutusjuhte saab leida ka väliste sündmuste tuvastamise kaudu:
Kes antud sündmuse tekitab? Miks?
Mingi sündmuste grupp võib kuuluda samale EBP taseme eesmärgile või kasutusjuhule.
4. Kasutusjuhu defineerimine - Üldjuhul defineeritakse üks EBP taseme kasutusjuht iga kasutajaeesmärgi kohta. Kasutusjuhtu nimetatakse sarnaselt eesmärgile, nt Eesmärk: töödelda müüki, UseCase: Töötle müüki.
Oluline erand, mis rikub eesmärk - kasutusjuht üks-ühele vastavust on CRUD (create, retrieve, update, delete ), nt Halda Isikuid, kus üks kasutusjuht täidab esinevaid eesmärke: “redigeeri isikut”, “kustuta isik” jne.
12. Sisuline stiil
Kirjuta kasutusjuhud sisulises stiilis, hoia kasutajaliidesest eemale ning keskendu tegutseja kavatsustele.
Kavatsus ( intention , intent) ja eesmärk (goal) on sarnased. (Ahah???) Tegutseja kavatsuste sammude all kasutusjuhus tuleks mõelda selle kasutusjuhu allfunktsioonide või tegevussammude eesmärkidest.
Sisuline vs Konkreetne - konkreetses on kasutajaliidese disainiotsused (aknad, eksaanielemendid, navigeerimine jne) kirjutatud kasutusjuhu teksti sisse. Sellised konkreetsed kasutusjuhud on kasulikud detailses kasutajaliidese disaini töös hilisematel arendussammudel ja mitte varases nõuete analüüsi töös.
13. Tegutsejad
1. Primaarne tegutseja - omab kasutajaeesmärke, mis täidetakse käsitletava süsteemi teenuse kasutamise läbi. Näiteks kassiir. Miks identifitseeritakse? Et leida kasutajaeesmärke, mis juhivad kasutusjuhte.
2. Toetav tegutseja - võimaldab teenuseid (nt informatsioon) käsitletavale süsteemile. Nt automatiseeritud maksete autoriseerimise teenus. Sageli arvutisüsteem , kuid võib olla ka inimene või organisatsioon. Miks identifitseeritakse? Er selgitada välja välised liideseid ja protokolle.
3. Kõrvalseisev, lavatagune/offstage tegutseja - omab huvi kasutusjuhu käitumise suhtes, kuid pole primaarne ega toetav, nt riiklik maksuamet . Milleks? Et kindlustada kõigi vajalike huvide identifitseerimine ja rahuldamine.
14. Kasutusjuhtude mudel vs kasutusjuhtude diagramm
Diagrammid on UMLi tehnika kasutusjuhtude illustreerimiseks. Diagrammid ja seosed ei ole põhi fookus, pigem peaks keskenduma mudelile ehk see pikk kaunis tekstidokument , kus on kogu asi detailselt, laialt ja mõistlikult lahti kirjutatud, ehk eelda , et su lugeja on primitiiv ja sa tõesti pead iga sammu eriti üksikasjalikult välja kirjutama. Rõhk tekstile , mitte diagrammile!
AGA - kuna diagrammid pole ikkagi täiesti kasutud, siis Mardi pro tips on how to make the best use case diagrams evaaaa
1. Joonista esmaslt lihtne kasutusjuhu diagramm kooskõlas tegutseja-eesmärgi loeteluga. Kasutusjuhu diagrammile joonista esialgu ainult kasutajaeesmärgi tasemelised kasutusjuhud (alamkasutusjuhud lisa hiljem, kui üldse & laiformaadis kirjelduse keerukamatest laiendustest)
2. Primaarsed tegutsejad joonista süsteemist vasakule poole.
3. Toetavad tegutsejad käivad paremale.
4. Arvutisüsteemid-tegutsejad joonista teistmoodi kui inimtegutsejad (nt klassi ristkülik aga pane stereotüüp actor juurde)
Süsteemi jadadiagramm kasutusjuhu mudeli osana
Süsteemi jadadiagramm väljendab tegutsejate poolt genereeritavaid sisend-väljund sündmusi süsteemi jaoks. Süsteemi jadadiagramm on kasutusjuhu mudeli osa, mis näitab “mida süsteem peab tegema”, süsteem on antud juhul must kast. Süsteemi jadadiagramm tehakse detailimisfaasi iteratsiooni nõuete analüüsi osas (tra Kaarel) konkreetsete kasutusjuhtude kohta.
Kasutusjuhud kirjeldavad, kuidas kasutajad suhtlevad loodava süsteemiga. Suhtlemise käigus genereerib tegutseja süsteemile sisendsündmusi, nõudes vastuseks operatsioonide täitmist. Konkreetse sisendsündmusega paaris võidakse vaadata väljundsündmust, milleks on sisendsündmuse töötlemise tulemuse(andmed) tagastamine tegutsejale. Süsteemi jadadiagrammi peaks tegema põhilise eduka stsenaariumi kohta ja maaaaybe kõige huvipakkuvamate laienduste kohta
Jadadiagrammi elemendid:
Välissubjektid/actorid, kes suhtlevad vahetult süsteemiga
Süsteem kui “must kast”
Süsteemi sündmused, mida subjektid genereerivad. Süsteemi sündmused võivad sisaldada parameetreid.
Ajatelg ülalt-alla, mis tekitab sündmuste ajalise järjestuse kasutusjuhus (hence the name JADAdiagramm)
Kordust võidakse näidata kastiga, mis hõlmab korduvaid sündmusi ning korduse tingimust.
Süsteemi sündmused ja süsteemi operatsioonid
Süsteemi sisendsündmus algatab vastava süsteemi operatsiooni. Sündmuse ja operatsiooni nimed on identsed, kuid sündmus on stiimul ja operatsioon on reaktsioon sellele.
Süsteemi operatsioonide kirjeldamine:
Vajalike süsteemi operatsioonide hulk määratakse süsteemi sündmuste määramisega. Süsteemi operatsioonid grupeeritakse Süsteemi nimelise tüübi (tüüp on abstraktne klass) operatsioonidena. Kui tegemist on hajussüsteemi või -rakendusega, siis iga osalev süsteem saab unikaalse nime (System1, System2…) (Mart pls, pigem nagu OptimusPrime, Rocky) ninga samuti omad süsteemi operatsioonid (allsüsteemid ja nende teenused).
How do I süsteemi jadadiagramm?
1. Joonista joon, mis esitab süsteemi kui musta kasti.
2. Identifitseeri kõik tegutsejad, kes otseselt tegutsevad süsteemiga. Joonista vertikaaljoon iga sellise tegutseja jaoks.
3. Identifitseeri kasutusjuhu tüüpstsenaariumi tekstist süsteemi välissündmused, mida iga tegutseja genereerib. Joonista nad diagrammile. Kordustele tee kast ümber ja nt lõpetamistingimus.
4. Vajaduse korral lülita kasutusjuhu tekstiline stsenaarium diagrammi vasakule küljele.
PS. Antud juhul näita oma põhistsenaariumit, mitte kõiki võimalikke teid.
Lepingud süsteemi operatsioonidele
Lepingud aitavad defineerida süsteemi käitumist, kirjeldades operatsioonide mõju süsteemile (kuidas muutub süsteemi seisund iga operatsiooni täitumise tulemusena). UMLis saab seda teha operatsioonide eel- ja järeltingimuste defineerimise teel.
Süsteemi operatsioonide lepingute loomine toimub detailimisfaas (elaboration) iteratsioonides, nõuete analüüsi distsipliinis, kasutusjuhu mudeli osana. Eelnevalt peavad olemas olema kontseptuaalne klassidiagramm (domeeni mudel), süsteemi jadadiagramm ning identifitseeritud süsteemi operatsioonid.
Lepingu osad
Operatsioon: Operatsiooni nimi ja parameetrid
Viited ( cross references): kasutusjuhud, milles antud operatsioon võib toimuda
Eeltingimused: Olulised eeldused süsteemi või domeeni mudeli objektide seisundi kohta enne operatsiooni täitmist. Neid ei testita selle operatsiooni loogika sees, vaid eeldatakse, et need kehtivad. Kirjutatakse vaid mittetriviaalsed eeldused, mida lugejal on vaja teada.
Järeltingimused: Domeeni mudel objektide seisund pärast operatsiooni lõppu.
Järeltingimused - on lepingu tähtsaimad osad. Nendega on seotud kontseptuaalne klassidiagramm (domeeni mudel), nad toetavad detailset analüüsi.
Konkreetse kasutusjuhu jaoks - 1. Identifitseeri süsteemi operatsioonid jadadiagrammist.
2. Süsteemi operatsioonide jaoks, mis on keerulised või ebaselged tulemuste osas või mis pole piisavalt selged kasutusjuhtudes, konstrueeri leping. 3. Järeltingimuste kirjeldamisel kasuta järgmisi kategooriaid: Objektide (eksemplaride) loomine ja kustutamine, Atribuutide väärtustamine, Assotsiatsioonide loomine ja katkestamine.
Lepingute kirjutamise üldine viga - unustatakse kirjeldada seoste moodustamist. Lepingute kirjutamine võib triggerida kontseptuaalmudeli muutmisele, nt objektide või atribuutide lisamine.
15. Veel kasutusjuhtudega seotud asju
Kasutusjuhud on aluseks Testjuhtude kirjutamisele testimise distsiblinnis. Kasutajaliideste eskiisid kui tarkvara nõuete kogumise vahendid:
Modelleerimise aines õpitud-tehtud
Süsteemianalüüsi projektis teeme ka
Ja kordame hiljem domeenimudeli teemaga koos