Use case , use case, use case ( eng. use case ) - inom mjukvaruutveckling och systemdesign är detta en beskrivning av beteendet hos ett system när det interagerar med någon (eller något) från den externa miljön. Systemet kan svara på externa förfrågningar från skådespelaren ( engelska skådespelaren , på ryska ligger betoningen på första stavelsen; termen aktant [1] kan användas ), det kan självt fungera som en initiator till interaktion. Manuset med andra ordanvändning beskriver "vem" och "vad" kan göra med systemet i fråga, eller vad systemet kan göra med "vem" eller "vad". Användningsfallsmetoden används för att identifiera systembeteendekrav , även känd som användar- och funktionskrav.
Inom systemteknik tillämpas användningsfall på en högre nivå än i mjukvaruutveckling, ofta representerande intressenternas mål eller uppdrag. Under kravanalysfasen kan användningsfall omvandlas till en uppsättning detaljerade krav och dokumenteras med hjälp av SysML - kravdiagram eller andra liknande mekanismer.
1986 formulerade Ivar Jakobson , senare meduppfinnare av Unified Modeling Language (UML) och Rational Unified Process (RUP), först en visuell modelleringsteknik för att beskriva användningsfall. Till en början använde han lite andra termer - eng. användningsscenarier och användningsfall , men inget av dem var naturligt för det engelska språket. Och slutligen bestämde han sig för termen use case - use case. Sedan Jakobsons metod för användningsfallsmodellering har utvecklats har många mjukvaruingenjörer bidragit till förbättringen av metodiken, inklusive Kurt Bittner, Alistair Coburn , Gunner Overgaard och Jerry Schneider.
Under 1990-talet blev användningsfall en av de vanligaste teknikerna för att dokumentera funktionskrav, särskilt i den objektorienterade miljö som de härrörde från. Men deras användning är inte begränsad till objektorienterade system eftersom användningsfall inte är objektorienterade till sin natur.
"Varje användningsfall fokuserar på att beskriva hur man uppnår ett mål eller mål. För de flesta programvaruprojekt innebär detta att många användningsfall kommer att behövas för att bestämma den önskade uppsättningen egenskaper för det nya systemet. Graden av formalitet för ett programvaruprojekt och dess skede kommer att påverka den detaljnivå som krävs för varje användningsfall."
Användningsfall ska inte förväxlas med begreppet systemegenskaper ( English Feature ). Ett användningsfall kan vara associerat med en eller flera systemegenskaper, och en egenskap kan vara associerat med ett eller flera användningsfall.
Användningsfallet definierar interaktionerna mellan externa agenter och systemet som syftar till att uppnå målet. En skådespelare är en roll som en person eller sak spelar när den interagerar med ett system. Samma person som använder systemet kan representeras som olika aktörer eftersom de spelar olika roller. Till exempel kan "Jack" spela rollen som en kund som använder bankomaten för att ta ut kontanter, eller spela rollen som en bankanställd som använder systemet för att fylla på bankomaten med sedlar.
Användningsfall behandlar systemet som en "svart låda" och interaktioner med systemet, inklusive systemsvar, beskrivs ur en extern observatörs perspektiv. Detta är en medveten policy eftersom den tvingar författaren att fokusera på vad systemet ska göra snarare än hur det ska göras, och undviker att göra antaganden om hur funktionalitet kommer att implementeras.
Användningsfall kan beskrivas på en abstrakt nivå som beskriver en underdomän (business use case, ibland kallat key use case), eller på systemnivå (system use case). Skillnaderna mellan dem ligger i detaljerna.
Användningsfallet bör:
Alistair Coburn identifierade i sin bok Writing Effective Use Cases tre detaljnivåer i användningsfall:
För vissa programvaruutvecklingsprocesser räcker ett enkelt användningsfall för att fastställa systemkrav. Andra behöver många detaljerade användningsfall. Generellt gäller att ju större och mer komplext projektet är, desto mer sannolikt är det att många detaljerade scenarier kommer att behöva användas.
Detaljnivån i ett användningsfall beror ofta på projektets skede. De initiala scenarierna kan vara korta, men allt eftersom projektet fortskrider blir de mer detaljerade. Detta speglar olika krav för användningsfall. Inledningsvis bör de bara vara korta, eftersom de används för att få allmänna affärskrav från användarens synvinkel. Men senare i processen att bygga ett system behöver utvecklare mycket mer specifik och detaljerad vägledning.
Rational Unified Process (RUP) uppmuntrar utvecklare att använda en kort beskrivning av användningsfall i ett användningsfallsdiagram, med den vanliga detaljnivån som en kommentar och detaljerad beskrivning i textanalys. Skript kan dokumenteras med hjälp av specialverktyg (t.ex. UML Tool , SysML Tool), eller skrivas i en vanlig textredigerare.
I Unified Modeling Language är relationerna mellan hela eller delar av användningsfall och aktörer representerade i form av ett use case-diagram, eller i diagram som ursprungligen bygger på Ivar Jakobsons objektnotation. SysML använder samma representation på systemnivå.
I UML- användningsfallsdiagram visas ett scenario som en ellips . Inom eller under ellipsen finns namnet på elementet.
Följande typer av relationer gäller för användningsfall i UML:
Inklusive mellan prejudikat:
Alternativen för att använda skript i utvecklingsprocessen beror på vilken utvecklingsmetodik som används. I vissa utvecklingsmetoder är allt som krävs en kort översikt över scenariot. Andra användningsfall blir mer komplexa och förändras under utvecklingen. I vissa metoder kan de börja som korta affärsfall, utvecklas till detaljerade systemanvändningsfall och sedan växa till extremt detaljerade och uttömmande tester.
Det finns ingen standardmall för att dokumentera detaljerade användningsfall. Det finns många konkurrerande system, men det är bäst att använda de mallar som bäst passar projektet. Det finns dock en mening att nämna de huvudpunkter som är värda att uppmärksamma.
Skriptnamn Manusnamnet ska skrivas i verb-substantiv-format (t.ex. låna böcker, ta kontanter). Den bör beskriva ett uppnåeligt mål (till exempel är det bättre att registrera en användare än att registrera en användare) och bör förklara innebörden av användningsfallet. Det är en bra idé att använda namnet på manuset, skådespelarens mål, för att säkerställa att användarens behov beaktas. Två eller tre ord är bäst. Om det finns fler ord i namnet så finns det oftast ett kortare och mer informativt namn. Mål Utan ett mål är manuset värdelöst. Det finns inget behov av ett användningsfall när det inte finns något behov av någon aktör för att uppnå målet. Målet beskriver kortfattat vad användaren avser att uppnå med detta scenario. Skådespelare (skådespelare) En aktör är någon eller något utanför systemet och som påverkar eller påverkas av systemet. En aktör kan vara en person, en enhet, ett annat system eller delsystem, eller tid. En person i den verkliga världen kan representeras av flera aktörer om de har flera olika roller och mål i förhållande till systemet. De interagerar med systemet och utför några åtgärder på det. Intressenter ( Stakeholders ) Intressent - Den person eller avdelning som berörs av användningsfallet. Vanligtvis är dessa anställda i organisationen eller avdelningen för vilken scenariot skapas. En intressent kan bli ombedd att ge information, feedback eller tillstånd för ett användningsfall. Förutsättningar Det är värt att definiera alla villkor som måste vara sanna (det vill säga beskriva systemets tillstånd) under vilka exekveringen av skriptet är vettigt. Således, om systemet inte är i det tillstånd som beskrivs i förutsättningarna, är skriptets beteende odefinierat. Observera också att förutsättningar inte är "aktivatorer" (se nedan). Eftersom korrekta förutsättningar INTE kommer att utlösa skriptkörning. Aktivatorer En aktivator är en händelse som utlöser exekvering av ett skript. Denna händelse kan vara extern, tillfällig eller intern. Om aktivatorn inte är en verklig händelse (till exempel trycker klienten på en knapp), utan en serie komplexa förhållanden, är det värt att beskriva aktiveringsprocessen. Denna process bör periodiskt eller kontinuerligt kontrollera aktiveringsvillkoren och initiera skriptet.Det finns flera sätt att beskriva situationen där en aktivering sker men förutsättningarna inte är uppfyllda.