Use case , use case, use case ( eng. use case ) - i softwareudvikling og systemdesign er dette en beskrivelse af et systems adfærd, når det interagerer med nogen (eller noget) fra det eksterne miljø. Systemet kan reagere på eksterne anmodninger fra skuespilleren ( engelsk skuespiller , på russisk er trykket på den første stavelse; udtrykket Actant [1] kan bruges ), det kan selv fungere som igangsætter af interaktion. Med andre ord beskriver use casen "hvem" og "hvad" kan gøre med det pågældende system, eller hvad systemet kan gøre med "hvem" eller "hvad". Use case-metoden bruges til at identificere systemadfærdskrav , også kendt som bruger- og funktionskrav.
I systemudvikling anvendes use cases på et højere niveau end i softwareudvikling, hvilket ofte repræsenterer interessenternes mål eller missioner. Under kravanalysefasen kan use cases konverteres til et sæt detaljerede krav og dokumenteres ved hjælp af SysML -kravdiagrammer eller andre lignende mekanismer.
I 1986 formulerede Ivar Jakobson , senere medopfinder af Unified Modeling Language (UML) og Rational Unified Process (RUP), først en visuel modelleringsteknik til at beskrive use cases. I starten brugte han lidt andre udtryk - eng. brugsscenarier og usage case , men ingen af dem var naturlige for det engelske sprog. Og til sidst slog han sig fast på udtrykket use case - use case. Siden Jakobsons use case-modelleringsmetodologi er blevet udviklet, har mange softwareingeniører bidraget til forbedringen af metodikken, herunder Kurt Bittner, Alistair Coburn , Gunner Overgaard og Jerry Schneider.
I løbet af 1990'erne blev use cases en af de mest almindelige teknikker til at dokumentere funktionelle krav, især i det objektorienterede miljø, de stammer fra. Men deres brug er ikke begrænset til objektorienterede systemer, fordi use cases ikke er objektorienteret i naturen.
“Hver use case fokuserer på at beskrive, hvordan man opnår et mål eller mål. For de fleste softwareprojekter betyder det, at der vil være behov for mange use cases for at bestemme det ønskede sæt egenskaber for det nye system. Graden af formalitet af et softwareprojekt og dets fase vil påvirke det detaljeringsniveau, der kræves for hver use case."
Use cases bør ikke forveksles med begrebet systemegenskaber ( engelsk Feature ). En use case kan være knyttet til en eller flere systemegenskaber, og en egenskab kan være tilknyttet en eller flere use cases.
Use casen definerer interaktionerne mellem eksterne agenter og systemet, der sigter mod at nå målet. En skuespiller er en rolle, som en person eller ting spiller, når de interagerer med et system. Den samme person, der bruger systemet, kan repræsenteres som forskellige aktører, fordi de spiller forskellige roller. For eksempel kan "Jack" spille rollen som en kunde, der bruger pengeautomaten til at hæve kontanter, eller spille rollen som en bankmedarbejder, der bruger systemet til at fylde pengeautomaten op med pengesedler.
Use cases behandler systemet som en "sort boks", og interaktioner med systemet, herunder systemresponser, beskrives fra en ekstern observatørs perspektiv. Dette er en bevidst politik, fordi den tvinger forfatteren til at fokusere på, hvad systemet skal gøre i stedet for, hvordan det skal gøres, og undgår at lave antagelser om, hvordan funktionalitet vil blive implementeret.
Use cases kan beskrives på et abstrakt niveau, der beskriver et underdomæne (business use case, nogle gange omtalt som en key use case), eller på systemniveau (system use case). Forskellene mellem dem ligger i detaljerne.
Use casen skal:
Alistair Coburn identificerede i sin bog Writing Effective Use Cases tre detaljeringsniveauer i use cases:
For nogle softwareudviklingsprocesser er en simpel use case tilstrækkelig til at bestemme systemkravene. Andre har brug for mange detaljerede use cases. Generelt gælder det, at jo større og mere komplekst projektet er, jo mere sandsynligt er det, at mange detaljerede scenarier skal bruges.
Detaljeringsgraden i en use case afhænger ofte af projektets fase. De indledende scenarier kan være korte, men efterhånden som projektet skrider frem, bliver de mere detaljerede. Dette afspejler forskellige krav til use cases. I første omgang skal de kun være korte, da de bruges til at få generelle forretningskrav fra brugerens synspunkt. Men senere i processen med at bygge et system har udviklere brug for meget mere specifik og detaljeret vejledning.
Rational Unified Process (RUP) opfordrer udviklere til at bruge en kort beskrivelse af use cases i et use case-diagram med det sædvanlige detaljeringsniveau som en kommentar og detaljeret beskrivelse i tekstanalyse. Scripts kan dokumenteres ved hjælp af specielle værktøjer (f.eks . UML Tool , SysML Tool), eller skrives i en almindelig teksteditor.
I Unified Modeling Language er relationerne mellem hele eller dele af use cases og aktører repræsenteret i form af et use case diagram, eller i diagrammer, der oprindeligt er baseret på Ivar Jakobsons objektnotation. SysML bruger den samme repræsentation på systemniveau.
I UML use case-diagrammer vises et scenarie som en ellipse . Inden for eller under ellipsen er navnet på elementet.
Følgende typer relationer gælder for use cases i UML:
Herunder mellem fortilfælde:
Mulighederne for at bruge scripts i udviklingsprocessen afhænger af den anvendte udviklingsmetodologi. I nogle udviklingsmetoder kræves der kun et kort overblik over scenariet. Andre use cases bliver mere komplekse og ændrer sig under udviklingen. I nogle metoder kan de starte som korte business cases, udvikle sig til detaljerede system use cases og derefter vokse til ekstremt detaljerede og udtømmende tests.
Der er ingen standardskabelon til dokumentation af detaljerede use cases. Der er mange konkurrerende ordninger, men det er bedst at bruge de skabeloner, der passer bedst til projektet. Der er dog en mening i at nævne de hovedpunkter, der er værd at være opmærksomme på.
Script navn Scriptnavnet skal skrives i verbum-substantiv-format (f.eks. Lån bøger, Tag kontanter). Den skal beskrive et opnåeligt mål (f.eks. er det bedre at registrere en bruger end at registrere en bruger) og skal forklare betydningen af use casen. Det er en god idé at bruge navnet på manuskriptet, skuespillerens mål, og dermed sikre, at der tages hensyn til brugerens behov. To eller tre ord er det bedste. Hvis der er flere ord i navnet, så er der normalt et kortere og mere informativt navn. Mål Uden et mål er manuskriptet ubrugeligt. Der er ikke behov for en use case, når der ikke er behov for nogen aktør for at nå målet. Målet beskriver kort, hvad brugeren har til hensigt at opnå med dette scenarie. Skuespillere (skuespiller) En aktør er nogen eller noget uden for systemet og som påvirker eller bliver påvirket af systemet. En skuespiller kan være en person, en enhed, et andet system eller undersystem eller tid. En person i den virkelige verden kan være repræsenteret af flere aktører, hvis de har flere forskellige roller og mål i forhold til systemet. De interagerer med systemet og udfører nogle handlinger på det. Interessenter ( Stakeholders ) Interessent - Den person eller afdeling, der er berørt af use casen. Typisk er disse medarbejdere i den organisation eller afdeling, som scenariet oprettes for. En interessent kan blive bedt om at give oplysninger, feedback eller tilladelse til en use case. Forudsætninger Det er værd at definere alle de betingelser, der skal være sande (det vil sige beskrive systemets tilstand), hvorunder udførelsen af scriptet giver mening. Hvis systemet ikke er i den tilstand, der er beskrevet i forudsætningerne, er scriptets adfærd udefineret. Bemærk også, at forudsætninger ikke er "aktivatorer" (se nedenfor). Fordi korrekte forudsætninger IKKE vil udløse scriptudførelse. Aktivatorer En aktivator er en hændelse, der udløser eksekveringen af et script. Denne begivenhed kan være ekstern, midlertidig eller intern. Hvis aktivatoren ikke er en reel begivenhed (for eksempel trykker klienten på en knap), men en række komplekse forhold, så er det værd at beskrive aktiveringsprocessen. Denne proces bør periodisk eller kontinuerligt kontrollere aktiveringsbetingelserne og starte scriptet.Der er flere måder at beskrive situationen, hvor der sker en aktivering, men forudsætningerne ikke er opfyldt.