Caz de utilizare , caz de utilizare, caz de utilizare ( ing. caz de utilizare ) - în dezvoltarea de software și proiectarea sistemului, aceasta este o descriere a comportamentului unui sistem atunci când interacționează cu cineva (sau ceva) din mediul extern. Sistemul poate răspunde solicitărilor externe ale actorului ( actor englez , în rusă accentul este pe prima silabă; poate fi folosit termenul Actant [1] ), poate acționa el însuși ca inițiator al interacțiunii. Cu alte cuvinte, cazul de utilizare descrie „cine” și „ce” poate face cu sistemul în cauză sau ce poate face sistemul cu „cine” sau „ce”. Metodologia cazului de utilizare este utilizată pentru a identifica cerințele comportamentale ale sistemului , cunoscute și sub denumirea de cerințe funcționale și de utilizator.
În ingineria sistemelor, cazurile de utilizare sunt aplicate la un nivel mai înalt decât în dezvoltarea de software, reprezentând adesea obiective sau misiuni ale părților interesate. În timpul etapei de analiză a cerințelor , cazurile de utilizare pot fi convertite într-un set de cerințe detaliate și documentate folosind diagrame de cerințe SysML sau alte mecanisme similare.
În 1986, Ivar Jakobson , mai târziu co-inventator al limbajului de modelare unificat (UML) și al procesului rațional unificat (RUP), a formulat pentru prima dată o tehnică de modelare vizuală pentru descrierea cazurilor de utilizare. Inițial, a folosit termeni ușor diferiți - ing. scenarii de utilizare și cazuri de utilizare , dar niciunul dintre ele nu a fost firesc pentru limba engleză. Și în cele din urmă s-a hotărât pe termenul caz de utilizare - caz de utilizare. De când a fost dezvoltată metodologia de modelare a cazurilor de utilizare a lui Jakobson, mulți ingineri de software au contribuit la îmbunătățirea metodologiei, inclusiv Kurt Bittner, Alistair Coburn , Gunner Overgaard și Jerry Schneider.
În anii 1990, cazurile de utilizare au devenit una dintre cele mai comune tehnici de documentare a cerințelor funcționale, în special în mediul orientat pe obiecte din care provin. Dar utilizarea lor nu se limitează la sistemele orientate pe obiect, deoarece cazurile de utilizare nu sunt de natură orientate pe obiecte.
„Fiecare caz de utilizare se concentrează pe descrierea modului de atingere a unui scop sau obiectiv. Pentru majoritatea proiectelor software, aceasta înseamnă că vor fi necesare multe cazuri de utilizare pentru a determina setul dorit de proprietăți pentru noul sistem. Gradul de formalitate al unui proiect software și stadiul acestuia vor influența nivelul de detaliu necesar pentru fiecare caz de utilizare.”
Cazurile de utilizare nu trebuie confundate cu conceptul de proprietăți ale sistemului ( Caracteristică engleză ). Un caz de utilizare poate fi asociat cu una sau mai multe proprietăți ale sistemului, iar o proprietate poate fi asociată cu unul sau mai multe cazuri de utilizare.
Cazul de utilizare definește interacțiunile dintre agenții externi și sistemul care vizează atingerea scopului. Un actor este un rol pe care o persoană sau un lucru îl joacă atunci când interacționează cu un sistem. Aceeași persoană care folosește sistemul poate fi reprezentată ca actori diferiți, deoarece joacă roluri diferite. De exemplu, „Jack” poate juca rolul unui Client care folosește ATM-ul pentru a retrage numerar sau poate juca rolul unui Angajat al Băncii care utilizează sistemul pentru a încărca bancomatul cu bancnote.
Cazurile de utilizare tratează sistemul ca pe o „cutie neagră”, iar interacțiunile cu sistemul, inclusiv răspunsurile sistemului, sunt descrise din perspectiva unui observator extern. Aceasta este o politică deliberată, deoarece obligă autorul să se concentreze pe ceea ce ar trebui să facă sistemul mai degrabă decât pe modul în care ar trebui să fie făcut și evită să facă presupuneri cu privire la modul în care va fi implementată funcționalitatea.
Cazurile de utilizare pot fi descrise la un nivel abstract, descriind un subdomeniu (caz de utilizare în afaceri, denumit uneori un caz de utilizare cheie) sau la nivel de sistem (caz de utilizare a sistemului). Diferențele dintre ele stau în detalii.
Cazul de utilizare ar trebui:
Alistair Coburn, în cartea sa Writing Effective Use Cases, a identificat trei niveluri de detaliu în cazurile de utilizare:
Pentru unele procese de dezvoltare software, un caz de utilizare simplu este suficient pentru a determina cerințele de sistem. Alții au nevoie de multe cazuri de utilizare detaliate. În general, cu cât proiectul este mai mare și mai complex, cu atât este mai probabil să fie nevoie de multe scenarii detaliate.
Nivelul de detaliu într-un caz de utilizare depinde adesea de stadiul proiectului. Scenariile inițiale pot fi scurte, dar pe măsură ce proiectul progresează, ele devin mai detaliate. Acest lucru reflectă cerințe diferite pentru cazurile de utilizare. Inițial, acestea ar trebui să fie doar scurte, deoarece sunt folosite pentru a obține cerințe generale de afaceri din punctul de vedere al utilizatorului. Cu toate acestea, mai târziu în procesul de construire a unui sistem, dezvoltatorii au nevoie de îndrumări mult mai specifice și detaliate.
Procesul Rational Unified (RUP) încurajează dezvoltatorii să folosească o scurtă descriere a cazurilor de utilizare într- o diagramă a cazurilor de utilizare, cu nivelul obișnuit de detaliu ca comentariu și descriere detaliată în analiza textului. Scripturile pot fi documentate folosind instrumente speciale (de exemplu Instrumentul UML , Instrumentul SysML) sau pot fi scrise într-un editor de text obișnuit.
În Unified Modeling Language, relațiile dintre toate sau o parte din cazurile de utilizare și actori sunt reprezentate sub forma unei diagrame de cazuri de utilizare sau în diagrame bazate inițial pe notația obiectului lui Ivar Jakobson. SysML folosește aceeași reprezentare la nivel de sistem.
În diagramele de cazuri de utilizare UML , un scenariu este afișat ca o elipsă . În interiorul sau sub elipsă se află numele elementului.
Următoarele tipuri de relații se aplică cazurilor de utilizare în UML:
Inclusiv între precedente:
Opțiunile de utilizare a scripturilor în procesul de dezvoltare depind de metodologia de dezvoltare utilizată. În unele metodologii de dezvoltare, tot ceea ce este necesar este o scurtă prezentare generală a scenariului. Alte cazuri de utilizare devin mai complexe și se schimbă în timpul dezvoltării. În unele metodologii, acestea pot începe ca cazuri de afaceri scurte, se pot dezvolta în cazuri detaliate de utilizare a sistemului și apoi pot crește în teste extrem de detaliate și exhaustive.
Nu există un șablon standard pentru documentarea cazurilor de utilizare detaliate. Există multe scheme concurente, dar cel mai bine este să folosiți șabloanele care se potrivesc cel mai bine proiectului. Există, totuși, un sens să menționăm principalele puncte cărora merită să le acordăm atenție.
Nume script Numele scenariului trebuie scris în format verb-substantiv (de exemplu, Împrumută cărți, Take Cash). Ar trebui să descrie un obiectiv realizabil (de exemplu, Înregistrarea unui utilizator este mai bună decât înregistrarea unui utilizator) și ar trebui să explice semnificația cazului de utilizare. Este o idee bună să folosiți numele scenariului, ținta actorului, asigurându-vă astfel că nevoile utilizatorului sunt luate în considerare. Două sau trei cuvinte sunt cele mai bune. Dacă în nume există mai multe cuvinte, atunci există de obicei un nume mai scurt și mai informativ. Ţintă Fără un scop, scenariul este inutil. Nu este nevoie de un caz de utilizare când nu este nevoie ca vreun actor să atingă scopul. Scopul descrie pe scurt ceea ce utilizatorul intenționează să realizeze cu acest scenariu. Actori (actor) Un actor este cineva sau ceva din afara sistemului și care influențează sau este influențat de sistem. Un actor poate fi o persoană, un dispozitiv, un alt sistem sau subsistem sau timp. O persoană din lumea reală poate fi reprezentată de mai mulți actori dacă au mai multe roluri și scopuri diferite în raport cu sistemul. Ei interacționează cu sistemul și efectuează unele acțiuni asupra acestuia. Părți interesate ( Părți interesate ) Stakeholder - Persoana sau departamentul care este afectat de cazul de utilizare. De obicei, aceștia sunt angajați ai organizației sau departamentului pentru care se creează scenariul. O parte interesată i se poate cere să furnizeze informații, feedback sau permisiunea pentru un caz de utilizare. Cerințe preliminare Merită să definiți toate condițiile care trebuie să fie adevărate (adică să descrieți starea sistemului) în care execuția scriptului are sens. Astfel, dacă sistemul nu se află în starea descrisă în precondiții, comportamentul scriptului este nedefinit. Rețineți, de asemenea, că precondițiile nu sunt „activatori” (vezi mai jos). Deoarece precondițiile corecte NU vor declanșa execuția scriptului. Activatori Un activator este un eveniment care declanșează execuția unui script. Acest eveniment poate fi extern, temporar sau intern. Dacă activatorul nu este un eveniment real (de exemplu, clientul apasă un buton), ci o serie de condiții complexe, atunci merită să descrieți procesul de activare. Acest proces ar trebui să verifice periodic sau continuu condițiile de activare și să inițieze scriptul.Există mai multe moduri de a descrie situația în care are loc o activare, dar condițiile preliminare nu sunt îndeplinite.