Käyttötapaus , käyttötapaus, käyttötapaus ( eng. use case ) - ohjelmistokehityksessä ja järjestelmäsuunnittelussa tämä on kuvaus järjestelmän käyttäytymisestä, kun se on vuorovaikutuksessa jonkun (tai jonkin) kanssa ulkoisesta ympäristöstä. Järjestelmä voi vastata näyttelijän ulkoisiin pyyntöihin ( englanniksi näyttelijä , venäjäksi painotus on ensimmäisessä tavussa; termiä Actant [1] voidaan käyttää ), se voi itse toimia vuorovaikutuksen aloittajana. Toisin sanoen käyttötapaus kuvaa "kuka" ja "mitä" voi tehdä kyseisellä järjestelmällä tai mitä järjestelmä voi tehdä "kuka" tai "mitä". Käyttötapausmenetelmiä käytetään tunnistamaan järjestelmän käyttäytymisvaatimukset , jotka tunnetaan myös nimellä käyttäjä- ja toiminnalliset vaatimukset.
Järjestelmäsuunnittelussa käyttötapauksia sovelletaan korkeammalla tasolla kuin ohjelmistokehityksessä, mikä edustaa usein sidosryhmien tavoitteita tai missioita. Vaatimusanalyysivaiheessa käyttötapaukset voidaan muuntaa yksityiskohtaisiksi vaatimuksiksi ja dokumentoida SysML - vaatimuskaavioilla tai muilla vastaavilla mekanismeilla.
Vuonna 1986 Ivar Jakobson , myöhemmin Unified Modeling Language (UML) ja Rational Unified Process (RUP) keksijä , muotoili ensimmäisen kerran visuaalisen mallinnustekniikan käyttötapausten kuvaamiseksi. Aluksi hän käytti hieman erilaisia termejä - eng. käyttöskenaariot ja käyttötapaukset , mutta mikään niistä ei ollut luonnollinen englannin kielelle. Ja lopulta hän päätyi termiin käyttötapaus - käyttötapaus. Sen jälkeen kun Jakobsonin käyttötapausten mallinnusmetodologia on kehitetty, monet ohjelmistosuunnittelijat ovat osallistuneet metodologian parantamiseen, mukaan lukien Kurt Bittner, Alistair Coburn , Gunner Overgaard ja Jerry Schneider.
1990-luvulla käyttötapauksista tuli yksi yleisimmistä toiminnallisten vaatimusten dokumentointitekniikoista, erityisesti olioympäristössä, josta ne ovat peräisin. Mutta niiden käyttö ei rajoitu oliojärjestelmiin, koska käyttötapaukset eivät ole luonteeltaan oliokeskeisiä.
"Jokaisessa käyttötapauksessa keskitytään kuvaamaan, kuinka tavoite tai tavoite saavutetaan. Useimmissa ohjelmistoprojekteissa tämä tarkoittaa, että uuden järjestelmän haluttujen ominaisuuksien määrittämiseen tarvitaan useita käyttötapauksia. Ohjelmistoprojektin muodollisuus ja sen vaihe vaikuttavat kussakin käyttötapauksessa vaadittavaan yksityiskohtaisuuteen.
Käyttötapauksia ei pidä sekoittaa järjestelmän ominaisuuksien käsitteeseen ( englanninkielinen ominaisuus ). Käyttötapaus voi liittyä yhteen tai useampaan järjestelmän ominaisuuteen, ja ominaisuus voi liittyä yhteen tai useampaan käyttötapaukseen.
Käyttötapaus määrittelee tavoitteen saavuttamiseen tähtäävän vuorovaikutuksen ulkoisten toimien ja järjestelmän välillä. Näyttelijä on rooli , jota henkilö tai asia esittää vuorovaikutuksessa järjestelmän kanssa. Sama järjestelmää käyttävä henkilö voidaan esittää eri toimijoina, koska heillä on eri rooleja. Esimerkiksi "Jack" voi toimia asiakkaan roolissa, joka käyttää pankkiautomaattia käteisen nostamiseen, tai pankkityöntekijän roolissa, joka käyttää järjestelmää pankkiautomaatin lisäämiseen seteleillä.
Käyttötapaukset käsittelevät järjestelmää "mustana laatikkona" ja vuorovaikutuksia järjestelmän kanssa, mukaan lukien järjestelmän vastaukset, kuvataan ulkopuolisen tarkkailijan näkökulmasta. Tämä on tarkoituksellista politiikkaa, koska se pakottaa kirjoittajan keskittymään siihen, mitä järjestelmän pitäisi tehdä, eikä siihen, miten se pitäisi tehdä, ja välttää oletuksia siitä, kuinka toiminnallisuus toteutetaan.
Käyttötapaukset voidaan kuvata abstraktilla tasolla, joka kuvaa aliverkkotunnusta (liiketoiminnan käyttötapaus, jota joskus kutsutaan avainkäyttötapaukseksi) tai järjestelmätasolla (järjestelmän käyttötapaus). Niiden väliset erot ovat yksityiskohdissa.
Käyttötapauksen tulee:
Alistair Coburn tunnisti kirjassaan Writing Effective Use Cases kolme käyttötapausten yksityiskohtaisuutta:
Joissakin ohjelmistokehitysprosesseissa yksinkertainen käyttötapaus riittää määrittämään järjestelmävaatimukset. Toiset tarvitsevat monia yksityiskohtaisia käyttötapauksia. Yleisesti ottaen mitä suurempi ja monimutkaisempi projekti on, sitä todennäköisemmin on käytettävä monia yksityiskohtaisia skenaarioita.
Käyttötapauksen yksityiskohtaisuus riippuu usein projektin vaiheesta. Alustavat skenaariot voivat olla lyhyitä, mutta projektin edetessä ne tarkentuvat. Tämä kuvastaa erilaisia käyttötapauksia koskevia vaatimuksia. Aluksi niiden tulisi olla vain lyhyitä, koska niitä käytetään yleisten liiketoiminnan vaatimusten selvittämiseen käyttäjän näkökulmasta. Myöhemmin järjestelmän rakentamisen aikana kehittäjät tarvitsevat kuitenkin paljon tarkempaa ja yksityiskohtaisempaa ohjausta.
Rational Unified Process (RUP) kannustaa kehittäjiä käyttämään lyhyttä kuvausta käyttötapauksista käyttötapauskaaviossa, jossa on tavanomaista yksityiskohtaisuutta kommenttina ja yksityiskohtainen kuvaus tekstianalyysissä. Skriptit voidaan dokumentoida erikoistyökaluilla (esim . UML Tool , SysML Tool) tai kirjoittaa tavallisella tekstieditorilla.
Unified Modeling Languageissa kaikkien tai osien käyttötapausten ja toimijoiden väliset suhteet esitetään käyttötapauskaavion muodossa tai alun perin Ivar Jakobsonin objektinotaatioon perustuvissa kaavioissa. SysML käyttää samaa esitystapaa järjestelmätasolla.
UML - käyttötapauskaavioissa skenaario näytetään ellipsinä . Ellipsin sisällä tai alapuolella on elementin nimi.
Seuraavat suhteet koskevat käyttötapauksia UML:ssä:
Mukaan lukien ennakkotapausten välillä:
Skriptien käyttövaihtoehdot kehitysprosessissa riippuvat käytetystä kehitysmetodologiasta. Joissakin kehitysmenetelmissä vaaditaan vain lyhyt katsaus skenaarioon. Muut käyttötapaukset monimutkaistuvat ja muuttuvat kehityksen aikana. Joissakin menetelmissä ne voivat alkaa lyhyistä liiketoimintatapauksista, kehittyä yksityiskohtaisiksi järjestelmän käyttötapauksiksi ja kasvaa sitten erittäin yksityiskohtaisiksi ja tyhjentäviksi testeiksi.
Ei ole olemassa vakiomallia yksityiskohtaisten käyttötapausten dokumentoimiseksi. Kilpailevia malleja on monia, mutta on parasta käyttää projektiin parhaiten sopivia malleja. On kuitenkin järkevää mainita tärkeimmät kohdat, joihin kannattaa kiinnittää huomiota.
Skriptin nimi Käsikirjoituksen nimi tulee kirjoittaa verbi-substantiivimuodossa (esim. Lainaa kirjoja, Ota käteistä). Sen tulee kuvata saavutettavissa oleva tavoite (esimerkiksi käyttäjän rekisteröinti on parempi kuin käyttäjän rekisteröinti) ja selittää käyttötapauksen merkitys. On hyvä idea käyttää käsikirjoituksen nimeä, näyttelijän kohdetta, jolloin varmistetaan, että käyttäjän tarpeet huomioidaan. Kaksi tai kolme sanaa on paras. Jos nimessä on enemmän sanoja, on yleensä lyhyempi ja informatiivisempi nimi. Kohde Ilman tavoitetta käsikirjoitus on hyödytön. Ei tarvita käyttötapausta, kun tavoitteen saavuttamiseksi ei tarvita ketään toimijaa. Tavoite kuvaa lyhyesti, mitä käyttäjä aikoo saavuttaa tällä skenaariolla. Näyttelijät (näyttelijät) Toimija on joku tai jokin järjestelmän ulkopuolella ja joka vaikuttaa järjestelmän vaikutuksiin tai siihen vaikuttaa. Toimija voi olla henkilö, laite, toinen järjestelmä tai osajärjestelmä tai aika. Ihmistä todellisessa maailmassa voivat edustaa useat toimijat, jos heillä on useita erilaisia rooleja ja tavoitteita suhteessa järjestelmään. He ovat vuorovaikutuksessa järjestelmän kanssa ja suorittavat sille joitain toimintoja. Sidosryhmät ( Stakeholders ) Sidosryhmä – henkilö tai osasto, johon käyttötapaus vaikuttaa. Yleensä nämä ovat sen organisaation tai osaston työntekijöitä, jolle skenaario luodaan. Sidosryhmää voidaan pyytää antamaan tietoja, palautetta tai lupaa käyttötapaukseen. Edellytykset Kannattaa määritellä kaikki ehdot, joiden on oltava tosia (eli kuvattava järjestelmän tilaa), joissa komentosarjan suorittaminen on järkevää. Näin ollen, jos järjestelmä ei ole edellytyksissä kuvatussa tilassa, komentosarjan käyttäytyminen on määrittelemätön. Huomaa myös, että ennakkoehdot eivät ole "aktivaattoreita" (katso alla). Koska oikeat ennakkoehdot EIVÄT käynnistä komentosarjan suorittamista. Aktivaattorit Aktivaattori on tapahtuma, joka käynnistää komentosarjan suorittamisen. Tämä tapahtuma voi olla ulkoinen, väliaikainen tai sisäinen. Jos aktivaattori ei ole todellinen tapahtuma (esimerkiksi asiakas painaa painiketta), vaan sarja monimutkaisia olosuhteita, kannattaa aktivointiprosessia kuvailla. Tämän prosessin tulee tarkistaa säännöllisesti tai jatkuvasti aktivointiehdot ja käynnistää komentosarja.On useita tapoja kuvata tilannetta, jossa aktivointi tapahtuu, mutta edellytykset eivät täyty.