Diagrama de cazuri de utilizare reprezintă imaginea sistemului privit din exterior. Funcţionalitatea unui caz de utilizare este dată de un flux de evenimente (specificat în documentul de descriere al cazului de utilizare).
Un scenariu reprezintă o cale (un drum) prin fluxul de evenimente al unui caz de utilizare. Scenariile pot fi privite ca instanţe (sau realizări) ale cazurilor de utilizare: ele descriu o secvenţă de acţiuni concrete care pot avea loc la un moment dat în sistem.
Determinarea scenariilor are rolul de a ajuta:
- înţelegerea funcţionalităţii cazurilor de utilizare,
- specificarea modului în care responsabilităţile unui caz de utilizare sunt distribuite obiectelor şi claselor din sistem,
- identificarea obiectelor şi claselor,
- identificarea interacţiunilor între obiecte, necesare pentru realizarea unei părţi funcţionale concrete descrisă de un caz de utilizare.
- comunicarea pe baza specificaţiilor proiectului
Fiecare caz de utilizare este o reţea de scenarii conţinând un scenariu principal şi mai multe scenarii secundare. Iniţial se definesc scenariile primare pentru toate cazurile de utilizare. Scenariile alternative (secundare) se definesc până în momentul în care se observă că fiecare nou scenariu repetă o serie de paşi identificaţi în scenariile precedente (de obicei, acest fapt are loc dupa modelarea a 80% din scenariile secundare identificate).
Dacă fluxul de eveniment al unui caz de utilizare este descris prin intermediul unui text (documentul de descriere al cazurilor de utilizare), scenariile se descriu prin intermediul aşa-numitelor diagrame de interacţiune. În UML avem două tipuri de diagrame de interacţiune: diagramele de secvenţă şi de colaborare. Fiecare dintre aceste diagrame reprezintă o vedere grafică diferită a unui scenariu.
Diagramele de secvenţă prezintă interacţiunile care au loc între diverse obiecte ale unui sistem, ordonate cronologic. Ele determină obiectele şi clasele implicate într-un scenariu şi secvenţele de mesaje transmise între obiecte necesare îndeplinirii funcţionalităţii scenariului. Diagramele de secvenţă sunt asociate unui caz de utilizare.
Reprezentarea grafică a obiectelor în diagrama de secvenţă se realizează ca în figura 1, Curs 3. Prezenţa numelui obiectului sau al clasei este opţională, însă nu pot lipsi ambele în acelaşi timp. Atunci când numele obiectului lipseşte, reprezentarea grafică simbolizează un obiect anonim (utilizat în reprezentarea opricărui obiect al unei clase).
Fiecărui obiect îi corespunde o linie a timpului, reprezentată printr-o linie punctată sub reprezentarea obiectului. Mesajele transmise între obiecte sunt reprezentate prin săgeţi (de la obiectul client, sursă spre obiectul server, destinaţie, receptor) etichetate cu numele mesajului (figura 1).

Figura 1.
În cadrul unei diagrame de secvenţă pot fi implicaţi şi actori (figura 2).

Figura 2.
Figura 3 prezintă scenariul de adăugare a unui nou curs opţional în sistem (unde CursuriDlg este clasă de interfaţă, CursuriCtl este clasă de control, iar CursOptional este clasă entitate).

Figura 3.
În fazele timpurii ale analizei, diagramele de secvenţă sunt utilizate şi la specificarea funcţionalităţii claselor de interfaţă, fără a sugera modul de implementare a acestora.
Observaţii:
'Cât de complexe trebuie să fie diagramele de secvenţă?' Diagramele de secvenţă trebuie să fie cat mai simple (abordarea KISS – Keep It Simple and Stupid) - ele sugereaza ce mesaje sunt transmise intre obiecte si nu cum se realizeaza in detaliu o anumita functionalitate
'Cum se modelează
scenariile ce conţin logică condiţională?' În cazul în care logica este
simplă, se construieşte o diagramă de secvenţă simplă, cu puţine mesaje, la care
se adaugă comentarii de descriere a condiţiilor de parcurgere (in figura 3 se
poate adauga un mesaj suplimentar transmis de un obiect al clasei
CursuriCtl pentru a semnala o eroare la verificarea datelor
introduse ).
Dacă logica condiţională
implică un set numeros de mesaje, atunci se va realiza câte o diagramă de
secvenţă pentru fiecare dintre cele trei componente ale logicii (una pentru
if, una pentru then şi o a treia pentru
else).
Diagramele de colaborare prezintă interacţiunile dintre obiecte organizate relativ la acestea şi a legăturilor dintre ele. Diagramele de colaborare conţin (figura 4):
- obiecte, în reprezentarea lor grafică sub formă de dreptunghiuri
- legături între obiecte, reprezentate grafic prin linii de conectare
- mesaje, reprezentate ca etichete ale legăturilor, şi care conţin o săgeată îndreptată spre obiectul server (receptor al mesajului).

Figura 4.
Folosind instrumentul RationalRose se pot genera diagramele de colaborare din diagrame de secvenţă (meniu ‘Browse’, comanda ‘Create Collaboration Diagram’) sau invers (meniu ‘Browse’, comanda ‘Create Sequence Diagram’).
Observaţii:
'De ce sunt utilizate două diagrame echivalente ca
putere de modelare dar diferite din punct de vedere notaţional?' Diagramele
de secvenţă oferă o imagine temporală a scenariului. Ele sunt uşor de ‘citit’ şi
înţeles de către client sau utilizatorul final. De asemenea sunt utile în fazele
timpurii ale analizei pentru identificarea obiectelor si claselor. Deoarece diagramele de colaborare
surprind legăturile dintre obiecte, acestea sunt utile la faza de proiectare,
atunci când se modelează implementarea relaţiilor.