Fluxul de Evenimente al unui Use-Case
Fiecare use-case este in mod normal documentat prin intermediul unui flux de evenimente. Fluxul de evenimente pentru un use-case este o descriere a evenimentelor care trebuie sa se desfasoare pentru a realiza comportamentul dorit pentru acel use-case. Un flux de evenimente se scrie in termenii "ce trebuie sa faca sistemul", si nu "cum trebuie sa realizeze sistemul acel lucru". Cu alte cuvinte, un flux de evenimente se scrie folosind limbajul problemei si nu limbajul implementarii.

Un flux de evenimente trebuie sa includa urmatoarele informatii despre use-case-ul (UC) pe care il documenteaza:

Declansarea si Terminarea. Cand si cum incepe si respectiv se termina acel UC.

Interactiunea cu Actorii. Care sunt actorii cu care interactioneaza UC-ul precum si modul in care se desfoasoara aceasta interactiune.

Datele Necesare. Care sunt datele necesare pentru realizarea UC-ului

Secventa Normala de evenimente pentru UC.

Fluxurile de Exceptie. Descrierea tuturor fluxurilor de exceptie - denumite si fluxuri alternative - pentru acel UC.

Structura unui Document-Standard pentru Descrierea Fluxului de Evenimente
Fiecare proiect trebuie sa utilizeze un document-standard (template) pentru crearea fluxurilor de evenimente. Redam mai jos structura propusa de T. Quatrani [Quatr98] cu precizarea ca orice alta structura poate fi folsita cu conditia sa includa toate informatiile necesare unui flux de evenimente si mai ales sa fie folosit cu consecventa in cadrul proiectului:
 

Exemplu unui Flux de Evenimente in Problema Inscrierii
Vom prezenta in continuarea exemplul de documentarea al Use-Case-ului Selectie Cursuri pentru Predare.
 

Interactiunea intre Obiecte. Scenarii.
Diagramele use-case prezinta o perspectiva exterioara asupra sistemului. Functionalitatea UC-urilor este descrisa prin intermediul fluxurilor de evenimente. Spuneam mai sus ca fluxurile de evenimente sunt definite folosind limbajul problemei si nu pe cel al implementarii. Pentru a descrie implementarea use-case-urile sub forma interactiunii intre o societate de obiecte folosim scenariile.

Scenarii
Un scenariu reprezinta instanta unui use-case, adica o modalitate de desfasurare a fluxului de evenimente.Scenariile sunt dezvoltate pentru a facilita identificarea obiectelor, a claselor si a interactiunilor intre obiecte, prin intermediul carora este realizata o anumita functionalitate, specificata printr-un use-case. Scenariile documenteaza deciziile despre distribuirea responsabilitatilor asupra obiectelor si a claselor din sistem. Deasemenea, scenariile ofera un excelent mediu de comunicare utilizabil in discutiile cu clientii sistemului cu privire la specificare cerintelor pentru sistem.

Fiecare use-case este o retea de scenarii (web of scenarios) impartite in scenarii principale (fluxul normal al use-case-ului) si scenarii secundare(atunci cand sunt parcurse fluxurile alternative). Prin urmare, trebuie sa intelegem ca un sistem se compune dintr-un numar mare de scenarii.

Scenariile in Contextul Analizei
La inceputul etapei de analiza este suficienta identificare scenariilor primare pentru fiecare use-case. Atunci cand incepem sa observam ca noile scenarii repeta foarte mult dintr-unul sau mai multe scenarii definite anterior inseamna ca am atins punctul in care au fost definite toate scenariile principale. "Aceasta faza de analiza trebuie incheiata atunci cand echipa a elaborat aproximativ 80% din scenariile principale, precum si o submultime reprezentativa a scenariilor secundare. Daca elaborati mai mult decat atat veti constata ca rezultatele analizei nu se vor mai imbunatati. Elaborati insa mai putin decat atat si veti observa ca nu aveti o suficienta intelegere a comportamentului sistemului si nici o intelegere adecvata a riscurilor implicate."[Boo95]
 

Diagrame de Interactiune.

Fluxurile de evenimente pentru un use-case sunt descrise in format text, in timp ce scenariile sunt reprezentate prin intermediul diagramelor de interactiune. Exista doua tipuri de diagrame de interactiune: diagrame de secventa si diagrame de colaborare.

Diagrama de Secventa (Sequence Diagram)
O diagrama de secventa reprezinta interactiunea intre obiecte ordonata intr-o secventa de timp. O astfel de diagrama arata obiectele (si clasele) implicate in scenariu impreuna cu secventa de mesaje transmise intre obiecte pentru a duce la indeplinire functionalitatea scenariului. In mod uzual, in modelul sistemului diagramele de secventa sunt asociate cu use-case-urile (In Rational Rose se regasesc in mod normal in Use Case View).

In notatie UML, un obiecteste desenat sub forma unui dreptunghi continand numele obiectului subliniat. Numele unui obiect poate fi reprezentat in trei moduri: cu numele sau, cu numele sau impreuna cu numele clasei, sau doar prin numele clasei (obiecte anonime). Obiectele anonime sunt adesea folosite pentru a ilustra un obiect oarecare al acelei clase. Notatia pentru un obiect, impreuna cu cele trei modalitati de reprezentare a numelui sunt ilustrate in figura de mai jos:
 

Intr-o diagrama de secventa fiecare obiect are asociata o linie a timpului reprezentata printr-o linie verticala punctata  plasata sub obiectul respectiv. Mesajele dintre obiecte sunt reprezentate sageti care pornesc dinspre obiectul-client (cel care transmite mesajul) si sunt indreptate spre obiectul-server (cel care receptioneaza mesajul). Toate aceste elemente ce compun interactiunea dintre doua obiecte intr-o diagrama de secventa este exemplificata mai jos:

Focus of control
Focus of Control is an advanced notational technique that enhances sequence diagrams. It represents the relative time that the flow of control is focused in an object, thereby representing the time an object is directing messages. Focus of Control is portrayed through narrow rectangles that adorn the vertical lines that descend from each object.

Diagramele de Secventa si Clasele Limitrofe
In **lucrarea viitoare** vom prezenta o impartire tripartita a spatiului claselor ce descriu un sistem. Una dintre aceste trei categorii de clase o reprezinta clasele limitrofe.  Aceste clase sunt introduse in diagramele de secventa pentru a reprezenta interactiunea cu utilizatorul sau cu un alt sistem (altfel spus cu actorii). La inceputul procesului de analiza, scopul reprezentarii claselor limitrofe in aceste diagrame este acela de a capta si documenta cerintele legate de interfata, si NU pentru a descrie modul in care va fi implementata interfata. De fapt, mesajele transmise de actori spre clasele limitrofe depind de framework-ul folosit la dezvoltarea aplicatiei si prin urmare ele vor suferi probabil modificari pe masura ce se avanseaza de la "ce sistem se dezvolta" spre "cum se dezvolta sistemul".

Complexitatea Diagramelor de Secventa
O intrebare legitima este: cat de complexe pot fi diagramele de secventa? Raspunsul pe scurt ar fi sa incercam sa le pastram cat mai simple. Frumusetea acestor diagrama sta in simplitatea lor -- obiectele pot fi usor vazute, la fel ca si interactiunea dintre ele si functionalitatea captata de scenariu.

O alta intrebare legitima este: cum rezolvam problema logicii conditionale? (toata acea logica if-then-else ce caracterizeaza lumea reala). Daca logica este simpla, implicand doar cateva mesaje, ea poate fi adaugata integral intr-o singura diagrama, utilizand note (comentarii) pentru a documenta deciziile care apar in diagrama. Pe de alta parte, daca logica if-then-else implicata implica o multime de mesaje complexe, este recomandabila desenarea unei diagrame separate -- una pentru ramura de if, una pentru conditia then si alta pentru cazul else. Si toate acestea dintr-o singura dorinta: aceea de a pastra aceste diagrame cat mai simple.

Diagrama de Colaborare (Collaboration Diagram)
Diagramele de colaborare sunt o maniera alternativa de reprezentare a unui scenariu. Acest tip de diagrama grupeaza interactiunea dintre obiecte in jurul obiectelor si a legaturilor dintre ele. O diagrama de colaborare contine urmatoarele elemente:

Obiectele desenate ca si dreptunghiuri

Conexiunile dintre obiecte desenate prin linii care leaga obiectele conectate.

Mesajele reprezentate ca text impreuna cu o sageata care indica inspre obiectul care receptioneaza mesajul.

Practic: Diagramele de colaborare pot fi construite manual sau, in cazul in care pentru un anumit scenariu a fost deja construita diagrama de secventa, ele pot fi generate direct din diagrama de secventa. In Rational Rose acest lucru se realizeaza cel mai rapid apasand tasta F5.

Sequence vs. Collaboration Diagram
Diagramele de secventa ofera posibilitatea de a privi la un scenariu intr-o ordine cronologica. Clientii pot citi si intelege cu usurinta acest tip de diagrama. Asadar aceste diagrame sunt foarte utile la inceputul fazei de analiza. Diagramele de colaborare tind sa ofere imaginea de ansamblu asupra unui scenariu intrucat colaborarile intre sunt organizate in jurul legaturilor existente intre obiecte. Aceste diagrama sunt de obicei utilizate mai ales in faza de proiectare a dezvoltarii sistemului, atunci cand are loc proiectarea modului de implementare al relatiilor existente intre obiecte.

Modelare Comportamentului Dinamic al Unei Clase.
Use-case-urile si scenariile ofera o modalitate de descriere a comportamentului unui sistem, adica a interactiunii dintre obiectele din sistem. Uneori este necesar ca pe langa aceasta sa privim si la comportamentul unui obiect. Acest lucru se realizeaza prin intermediul diagramelor de tranzitie a starilor.

Diagrama de Tranzitie a Starilor
O diagrama tranzitie a starilor reda starile in care se poate afla un obiect la un moment de timp, evenimentele sau mesajele care provoaca tranzitia dintr-o stare in alta stare precum si actiunile care trebuie executate ca urmare a schimbarii starii obiectului.

O astfel de diagrama de tranzitie a starilor nu se creaza pentru fiecare clasa din sistem. Aceasta diagrama va fi creata doar pentru clasele cu un comportament dinamic semnificativ. Diagramele de interactiune sunt studiate pentru a determina obiectele cele mai dinamice din sistem - cele care primesc si transmit cele mai multe mesaje. Diagramele de tranzitie a starilor sunt deasemenea utile pentru a investiga comportamentul unei clase in ansamblu. Trebuie insa sa nu ne departam de la analiza problemei, ceea ce inseamna ca accentul cade pe intelegerea problemei si nu pe implementarea solutiei.

Starile
O stare inseamna de fapt totalitatea reperelor care descriu un anumit moment din viata unui obiect, adica daca obiectul indeplineste anumite conditii, daca el executa anumite actiuni sau daca se afla in asteptarea unui eveniment. Starea unui obiect poate fi caracterizata prin valoarea uneia sau a mai multor atribute ale clasei. De exemplu un obiect OfertaDeCurs poate sa fie in starea "deschis" (permitand adaugarea unui student) sau "inchis" (a fost deja atins numarul maxim de studenti ce pot participa la acea oferta de curs). Starea obiectului depinde de numarul de studenti asignat acelui obiect concret OfertaDeCurs. Pe langa aceasta, starea unui obiect poate fi caracterizata prin existenta unei legaturi catre un alt obiect. Astfel, un obiect Profesor poate sa se gaseasca in starea "activ"(este implicat in predare) sau "sabatic" (se afla intr-un an de odihna, si deci nu preda). Starea unui astfel de obiect depinde de existenta unei legaturi catre cel putin un obiect de tip OfertaDeCurs. In concluzie, starile unui obiect pot fi detectate examinand atributele si legaturile definite pentru acel obiect.

Notatia UML pentru o stare este un dreptunghi cu colturile rotunjite:
 

O diagrama de tranzitie a starilor cuprinde toate mesajele pe care un obiect le poate trimite si receptiona. In termenii acestei diagrame, un scenariu reprezinta o "cale" de parcurgere a starilor pornind din starea initiala si terminand cu starea finala. De obicei, o stare este reprezentata de intervalul parcurs intre trimiterea succesiva a doua mesaje. Prin urmare, diagramele de secventa pot fi examinate pentru a descoperi starile pentru un obiect (priviti la spatiul dintre doua linii reprezentand mesajele receptionate de catre obiect). Analizand exemplul inregistrarii cursurilor, dupa ce au fost definite toate diagramele de secventa pentru toate UC-urile, observam ca un obiect din clasa OfertaDeCurs se poate in una din urmatoarele stari:  Initializare(crearea a fost realizata inaintea inceperii inregistrarii, dar studentii nu pot inca sa se inscrie), Deschis(studentii se pot inscrie), Inchis(a fost atins nr. de studenti maxim admis pentru acel curs) si Anulat(oferta de curs nu mai este valabila).
 

Stari Speciale
Exista doua stari speciale care sunt figurate intr-o diagrama de tranzitie intre stari. Prima stare este starea de pornire. Fiecare astfel de diagrama trebuie sa aiba o stare de start si numai una, intrucat obiectul trebuie sa fie intr-o stare consistenta atunci cand este creat. Cealalta stare speciala este starea de oprire. Un obiect poate avea mai multe stari de oprire. Notatia UML pentru aceste stari speciale este reprezentata mai jos:

Tranzitie intre Stari
O tranzitie intre stari reprezinta o schimbare de stare, dintr-o stare originara intr-o stare succesoare (ce poate fi chiar starea de origine). Tranzitia poate fi insotita de executarea unei actiuni.

Exista doua tipuri de tranzitii intre stari: automatica si neautomatica. O tranzitie este automatica atunci cand intervine in urma incheierii activitatii din starea originara, adica nu exista un eveniment asociat cu respectiva tranzitie. O tranzitie neautomatica este cauzata de un eveniment anume, ce poate fi declansat fie de un alt obiect, fie de ceva din afara sistemului. Se considera ca ambele tipuri de tranzitie se desfasoara instantaneu si nu pot fi intrerupte. O tranzitie intre stari este reprezentata in notatie UML printr-o sageata care porneste dinspre starea originara si are varful orientat spre starea succesoare.

Detalierea unei Tranzitii intre Stari
Unei tranzitii intre doua stari i se poate asocia o actiune si/sau o conditie de garda si in plus o tranzitie poate declansa
un eveniment. O actiune este acel comportament care conduce la respectiva tranzitie. Un eveniment este un mesaj transmis unui alt obiect din sistem. O conditie de garda este o expresie booleana legata de valoarea unui atribut al obiectului care face ca respectiva tranzitie sa aiba loc doar atunci cand conditia este indeplinita. Atat actiunile cat si conditiile de garda se traduc de obicei prin operatii definite pentru acel obiect. Cel mai adesea aceste operatii sunt metode private, fiind utilizate doar de catre obiectul insusi. Notatia UML pentru detaliile unei tranzitii sunt prezentate in figura de mai jos:
 

Descrierea Detaliata a Starilor
Am vazut mai sus ca trecerea dintr-o stare in alta poate fi insotita de efectuarea unei actiuni. Actiunile care insotesc toate tranzitiile intr-o anumita stare, pot fi reprezentate ca actiuni de intrare in stare(entry). In mod asemanator, daca o actiune insoteste toate tranzitiile dintr-o anumita stare, atunci acea actiune poate fi reprezentata ca actiune de iesire din stare(exit). Un anumit comportament al unui obiect care nu are ca efect o tranzitie se numeste activitate(do). O activitate incepe atunci cand s-a intrat in respectiva stare si ea poate sa se incheie pana la iesirea din stare sau sa fie intrerupta de o tranzitie. Comportamentul unei activitati poate fi o simpla actiune sau transmiterea unui eveniment catre un alt obiect. Notatia UML pentru descrierea detaliata a unei stari este arata in figura de mai jos:

Probleme
1. Sa se creeze o diagrama de secventa pentru scenariul asignarii unui profesor la o oferta de curs. Aceasta diagrama va corespunde sub-fluxului S-1 apartinand fluxului de evenimente prezentat in aceasta lucrare.
Detalii:   * se presupune ca profesorul selecteaza cursul "Algebra/2"
             *  exista un obiect numit ManagerCursuri care va controla toate operatiile efectuate asupra obiectelor apartinand claselor "Curs" si "OferteDeCurs".
Indicatie: in urma unei analize atente in acest scenariu veti detecta cinci obiecte si un actor. Le-ati gasit, deja? ;-)

2. Sa se creeze varianta detaliata a diagramei de tranzitie a starilor pentru clasa OfertaDeCurs prezentata mai sus in care:
        a.) sa fie figurate starea de pornire si cea de oprire
        b.) sa fie figurate toate evenimentele, conditiile de garda si actiunile tranzitiilor ce rezulta din definirea problemei.
        c.) sa fie detaliata stare Deschis
Se vor avea in vedere urmatoarele aspecte: Pentru fiecare oferta de curs va exista cate un catalog cuprinzand studentii inregistrati la acel curs. Asadar pentru fiecare student se va face pe langa actiunea de inregistrare, in obiectul CatalogCurs  se va adauga studentul.

Bibliografie

[Boo94]    G. Booch  - "Object-Oriented Analysis and Design with Applications. Second Edition",  Addison-Wesley, 1994
[Sch97]    H. Shildt - "C++. Manual complet", Editura TEORA,  1997