Putem analiza  comportamentul unui sistem orientat pe obiecte din urmatoarele perspective:

• comportamentul extern al sistemului, ca efect al interactiunilor intre obiectele componente
• comportamentul intern al obiectelor.

Modelarea comportamentului la nivel de interactiuni intre obiecte se realizeaza cu ajutorul scenariilor, reprezentate prin diagrame de interactiune.

Modelarea comportamentului unui singur obiect, pe durata sa de viata este realizata cu ajutorul conceptului de masina de stare. O masina de stare poate fi vizualizata in 2 moduri:

• cu ajutorul diagramelor de activitate, care reliefeaza activitatile ce au loc in interiorul unui obiect;
• cu ajutorul diagramelor de tranzitie a starilor, care evidentiaza comportamentul obiectului ca efect al evenimentelor receptionate de obiect; aceste diagrame vor fi prezentate in lucrarea de fata.

Scenarii
Scenariile se folosesc pentru a descrie cum sunt realizate cazurile de utilizare ca interactiuni intre obiecte. Un scenariu reprezinta o instanta a unui caz de utilizare, adica o ramura a fluxului de evenimente al cazului. Intuitiv, un scenariu este pentru un caz de utilizare ceea ce este un obiect fata de clasa careia ii apartine.
Fluxurile de evenimente (care capteaza functionalitatea cazurilor de utilizare) sunt redate cu ajutorul textului, in timp ce scenariile sunt redate prin diagrame de interactiune.
Scenariile reprezinta totodata un mijloc de comunicare cu beneficiarii sistemului, in vederea stabilirii cerintelor, deoarece scenariile "vorbesc" in limbajul utilizatorilor si al expertilor in domeniul aplicatiei.
Fiecarui caz de utilizare ii corespunde o retea de scenarii, formata din:

• scenarii principale - corespunzatoare fluxului normal de evenimente;
• scenarii secundare - corespunzatoare fluxurilor alternative.

Diagrame de interactiune
Sunt de 2 tipuri:

• diagrame de secventa
• diagrame de colaborare

Diagrame de secventa
O diagrama de secventa ilustreaza ordonarea in timp a interactiunilor dintre obiectele implicate intr-un scenariu. Interactiunile la acest nivel sunt de fapt schimburi de mesaje intre obiecte, avand ca scop realizarea functiunilor scenariului.
Diagramele de secventa sunt de regula asociate cu cazurile de utilizare ale sistemului modelat.

In UML, un obiect dintr-o diagrama de secventa poate fi reprezentat sub una din urmatoarele forme:
(ob_diagr_secv.gif)
Obiectele anonime se utilizeaza pentru a desemna orice obiect al unei clase.

Fiecarui obiect din diagrama ii corespunde cate o axa temporala, reprezentata printr-o linie punctata verticala, numita si linia vietii obiectului.
Mesajele se reprezinta prin sageti trasate intre axele temporale ale obiectelor, avand sensul dinspre client (obiectul emitator) spre server (obiectul receptor).
(ex_diagr_secv.gif)

In diagramele de secventa apar si actorii asociati cu cazurile de utilizare reprezentate. Actorii sunt considerati ca obiecte anonime, numele de actor fiind utilizat pe post de nume de clasa. Simbolul de reprezentare ramane insa cel cunoscut de la diagramele de use-case. De altfel, trebuie spus ca in UML actorii sunt tratati ca forme particulare de clase.

Diagramele de secventa ofera posibilitatea de a privi un scenariu din punct de vedere al desfasurarii in timp a faptelor. Ele pot fi usor intelese si interpretate de client si de aceea, aceste diagrame sunt utile in fazele incipiente ale analizei.

Diagrame de colaborare
Constituie o alta posibilitate de reprezentare a scenariilor. Intr-o asemenea diagrama interactiunile sunt centrate pe obiecte si pe legaturile dintre acestea, oferindu-se astfel imagini ale organizarii obiectelor participante la interactiune. Diagramele de colaborare sunt utile in faza de proiectare, mai precis la proiectarea relatiilor.
Diagramele de colaborare si cele de secventa se pot obtine unele pe baza celorlalte. Astfel, diagrama de colaborare echivalenta cu diagrama de secventa din figura (...) este:
(ex_diagr_colab.gif)

Cum ajungem la diagramele de interactiune?
Pentru a putea demara construirea diagramelor de interactiune este necesara o identificare, macar si minimala, a claselor si obiectelor care concura la indeplinirea responsabilitatilor (functiunilor) unui caz de utilizare. Activitatea de identificare a claselor si obiectelor este una prin excelenta creativa, pentru care nu exista retete fixe, si in legatura cu care Booch face o afirmatie cel putin descurajanta, anume: "This is hard!".
Experienta castigata in aplicarea procesului de dezvoltare Rational Objectory a condus insa la formularea unor recomadari-cadru, printre care si aceea ca identificarea claselor pentru un sistem se incepe cu cautarea a 3 categorii de clase:

• clasele limitrofe (boundary classes)
• clasele de tip entitate (entity classes)
• clasele de control

Clasele limitrofe
Reprezinta suportul pentru comunicarea intre sistem si mediul extern. Ele modeleaza interfata cu utilizatorul sau cu un alt sistem, pe scurt interfata cu actorii. Clasele limitrofe sunt dependente de mediul extern al sistemului.
Pentru a descoperi clasele limitrofe se examineaza fiecare pereche <actor, caz de utilizare>.
Considerand problema prezentata in lucrarea precedenta (legatura...) vom exemplifica identificarea claselor abordand subfluxul  "Adauga oferta de cursuri" (S-1) (legatura...) al cazului de utilizare  "Selectia cursurilor de predat".
Acest caz interactioneaza doar cu actorul Profesor. Subfluxul considerat specifica una dintre capabilitatile pe care cazul de utilizare trebuie sa le ofere Profesorului. In aceasta situatie avem nevoie in primul rand de o clasa care sa gestioneze lista optiunilor disponibile pentru Profesor,  pe care o vom numi OptiuniProfesor. In al doilea rand mai avem nevoie de o clasa care sa se "ocupe" special de optiunea de adaugare, pe care o vom numi AdaugaOfertaCurs.

Clasele de tip entitate
Se mai numesc si clase de domeniu si modeleaza informatii care au o durata lunga de existenta in cadrul sistemului. Ele pot corespunde unor entitati din lumea reala sau pot indeplini sarcini interne in sistem. De regula, ele sunt independente de mediul lor inconjurator si chiar de aplicatie, putand fi utilizate in mai multe aplicatii.
Identificarea lor incepe prin studiul fluxurilor de evenimente, luandu-se ca punct de plecare o lista de substantive care descriu responsabilitatile sistemului.
In exemplul nostru putem identifica drept entitati care intervin in subfluxul analizat urmatoarele: Curs, OfertaCurs si InformatiiProfesor (informatiile de identificare ale profesorului). Se poate observa ca aceste clase pot fi utilizate si in alte aplicatii cu specific universitar.

Clasele de control
Modeleaza inlantuirea operatiilor specifice cazurilor de utilizare. Ele coordoneaza evenimentele necesare pentru a realiza comportamentul specificat de cazurile de utilizare. Aceste clase pot fi gandite ca un fel de suport de executie al cazurilor de utilizare ce modeleaza dinamica acestora. De regula, clasele de control sunt dependente de aplicatie.
La inceputul fazei de Elaborare se prevede cate o clasa de control pentru fiecare pereche <actor, caz de utilizare>. Ulterior, pe masura ce se avanseaza cu analiza si proiectarea, este posibil sa se mai elimine unele clase de control, respectiv clasele existente sa fie comasate sau divizate.
O clasa de control care realizeaza mai mult decat secventializarea evenimentelor unui caz de utilizare nu este bine proiectata. O asemenea clasa trebuie sa "stie" doar cand sa se execute o anumita operatie, NU si cum sa se execute.  Astfel, pentru exemplul considerat mai sus, vom prevedea o clasa care sa gestioneze fluxul evenimentelor pentru cazul "Selectia cursurilor de predat", pe care o vom numi ManagerCursuriProfesor. Aceasta clasa va sti cand trebuie efectuata operatia de adaugare a unei oferte, de exemplu, dar nu ea va realiza operatia respectiva, ci clasa OfertaCurs.

Cu acestea, putem purcede la intocmirea diagramelor de interactiune corespunzatoare subfluxului studiat.
Diagrama de secventa:
(diagr_secv.gif)
Diagrama de colaborare echivalenta:
(diagr_colab.gif)

Construirea unei diagrame de secventa in Rational Rose
Se face in 2 pasi:

• se creaza diagrama de secventa in fereastra de browsing, pe nivelul Use Case View, in mod similar crearii actorilor si a use-case-urilor (in meniul rapid se selecteaza optiunile New-Sequence Diagram);
• se umple diagrama cu elementele componente necesare, operand in fereastra de diagrama corespunzatoare (in mod similar crearii diagramelor de use-case). Pentru popularea diagramei cu obiecte se foloseste butonul Object de pe bara cu instrumente a ferestrei, iar pentru mesaje se foloseste butonul Message.

Construirea unei diagrame de colaborare in Rational Rose
Se poate face in 2 moduri:

• pornind de la diagrama de secventa echivalenta, daca aceasta a fost deja creata:
• se deschide diagrama de secventa
• se selecteaza optiunea Create Collaboration Diagram din meniul Browse
• se rearanjeaza obiectele in diagrama creata, daca e necesar
• pornind de la zero, intr-un mod similar crearii diagramelor de secventa; in acest caz, din diagrama de colaborare se poate crea diagrama de secventa echivalenta.

Diagramele de tranzitii
Se utilizeaza pentru analiza comportamentului obiectelor sub influenta evenimentelor ce actioneaza asupra lor. O diagrama de tranzitie ilustreaza:

• starile unui obiect
• evenimentele sau mesajele care cauzeaza trecerea de la o stare la alta
• actiunile care rezulta in urma modificarilor de stare.

Stari
Starea este o portiune din viata unui obiect cand acesta satisface o anumita conditie, executa o anumita actiune sau asteapta producerea unui anumit eveniment.
Starea unui obiect poate fi caracterizata cu ajutorul valorilor unuia sau ale mai multor atribute si, respectiv, poate sa depinda de existenta unor legaturi cu alte obiecte. Cu alte cuvinte, starile unui obiect pot fi determinate examinand atributele si legaturile sale.
Notatia UML pentru reprezentarea unei stari (legatura...) este un dreptunghi cu colturi rotunjite.

Pentru a descoperi starile unui obiect se pot utiliza diagramele de secventa in care apare obiectul respectiv, si anume, intervalul pe axa temporala dintre 2 mesaje trimise de obiect reprezinta de regula o stare. Aceasta este o examinare din exterior a starilor, in sensul ca ne permite identificarea numarului de stari distincte ale obiectului.

Intr-o diagrama de tranzitie apar toate mesajele pe care un obiect le poate trimite si primi. Un drum dintr-o diagrama de tranzitie reprezinta un scenariu.
Stari speciale: intr-o diagrama de tranzitie apar 2 tipuri de stari speciale:

• starea de pornire (start) - este unica pentru fiecare diagrama si corespunde starii in care se afla un obiect imediat dupa creare (dar inainte de initializare); simbolul UML pentru starea de start:

• starea de oprire (stop) - unui obiect ii pot corespunde zero (situatie specifica obiectelor din sisteme incorporate, care se executa continuu) sau mai multe stari de stop; starea de stop se "instaleaza" fie cand obiectul inceteaza sa mai existe, fie cand acesta trece intr-un regim "stationar" in care nu-si mai modifica starea; simbolul UML pentru starea de stop:

Ca exemplu vom considera un obiect al clasei OfertaCurs. Acestui obiect i se va atasa o lista a studentilor inscrisi, daca va fi cazul. Initial nici un student nu este inscris la oferta respectiva. In momentul in care primul student s-a inscris, obiectul trece in starea "deschis", stare in care poate accepta noi inscrieri. Daca numarul inscrierilor ajunge la 10, obiectul trece in starea "inchis" (nu se mai accepta inscrieri). Dupa trecerea termenului stabilit pentru inscrieri, daca numarul inscrisilor este < 3, obiectul trece in starea "anulat". Starea de stop pentru un asemenea obiect apare in 2 situatii:

• daca oferta este anulata, moment in care se sterge lista eventualilor studenti inscrisi;
• daca oferta a ramas inchisa, caz in care lista inscrisilor ramane cea stabilita.

(ofcurs_dtranz.gif)

Tranzitii intre stari
O tranzitie reprezinta trecerea dintr-o stare numita stare sursa intr-o alta stare, numita stare destinatie (sau tinta). In particular, starea destinatie poate fi aceeasi cu starea sursa.

O tranzitie poate fi insotita de o actiune.

O tranzitie poate sa aiba loc in 2 moduri:

• automat: cand activitatea din starea sursa se termina; in acest caz nu avem un eveniment anumit asociat cu tranzitia;
• neautomat: tranzitia este cauzata de un anumit eveniment (provenit de la un alt obiect sau din afara sistemului).

O tranzitie este reprezentata pe diagrama printr-o sageata indreptata dinspre starea sursa spre cea destinatie.
 
 

Detalii ale tranzitiilor intre stari
O tranzitie poate avea asociate: o actiune si/sau o conditie de garda si, respectiv, poate determina aparitia unui eveniment.

• Actiunea este o secventa atomica de operatii executate cand tranzitia are loc.
• Evenimentul este un mesaj trimis altui obiect din sistem.
• Garda este o expresie booleana care are ca operanzi atributele obiectului. Tranzitia la care este asociata garda poate sa aiba loc doar daca garda are valoarea "true".

In figura de mai jos sunt ilustrate simbolurile din notatia UML corespunzatoare elementelor expuse mai sus.
 
 

Detalii ale starilor
Actiunile care insotesc toate tranzitiile spre o stare destinatie pot fi constituite ca o actiune de intrare (entry) in interiorul starii destinatie respective.

Similar, actiunile care insotesc toate tranzitiile dinspre o stare sursa pot fi constituite ca o actiune de iesire (exit) in interiorul starii sursa respective.

In afara de acestea, in interiorul unei stari pot sa apara alte actiuni pe care obiectul le executa cat timp se afla in starea respectiva. Aceste actiuni formeaza impreuna o activitate. Daca o actiune este considerata atomica, deci neintreruptibila, in schimb activitatea este intreruptibila. O activitate incepe cand obiectul ajunge intr-o anumita stare (dupa ce a executat actiunile de intrare) si fie se termina normal, fie este intrerupta prin declansarea tranzitiei spre alta stare.

Actiunile care apar intr-o stare pot fi:

• actiuni simple
• evenimente trimise spre alte obiecte.