Elementele arhitecturii

Vizualizarea, specificarea, construirea si documentarea unui sistem software necesita ca sistemul sa fie analizat din mai multe perspective, si anume sa se ia in considerare modurile in care sistemul este perceput de catre diversele persoane care participa la dezvoltarea si apoi la utilizarea sistemului.

Astfel, fiecarei persoane care are tangenta cu sistemul software intr-un fel sau altul (in constructie sau in utilizare), sistemul i se infatiseaza sub o anume fateta (view). Se poate spune ca totalitatea acestor fatete compun arhitectura sistemului. Fiecare dintre fatete poate constitui o descriere de sine statatoare a sistemului (mai precis a unui aspect al lui), dar intre ele exista si interferente deoarece impreuna ele compun un intreg.

In cazul sistemelor orientate pe obiecte au fost identificate 5 coordonate principale ale arhitecturii (fig.11.1):

Aceasta viziune asupra arhitecturii unui sistem se mai numeste si abordarea din cele "4+1" perspective.

Cazurile de utilizare (Use Cases view)

Descriu comportarea sistemului asa cum este ea perceputa de utilizatori, de analistii care urmaresc captarea cerintelor si de cei ce realizeaza testarea sistemului. Cazurile de utilizare reflecta "ce face" sistemul la "suprafata", fara a intra in dedesubturile legate de "cum face" sistemul acele functii. Ele nu specifica propriu-zis organizarea sistemului, ci mai degraba reprezinta elementul care imprima forma sistemului.

Planul logic (Logical view) sau proiectul (Design view)

Cuprinde clasele, interfetele si relatiile care formeaza vocabularul problemei si al solutiei. Proiectul constituie suportul cerintelor functionale ale sistemului, adica al serviciilor oferite catre utilizatori.

Implementarea (Implementation view) sau planul componentelor (Component view)

Se refera la modulele (subsistemele) software utilizate pentru a asambla fizic sistemul dorit. Un modul este un ansamblu de componente care, la randul lor, sunt fisiere software (de ex: cod sursa, unitati de program precompilate).

In cazul sistemelor orientate pe obiecte modulele sunt organizate stratificat, fiecare strat avand o interfata clar definita. Straturile sunt dispuse ierarhic. Aceasta stratificare ierarhica este pana la urma o consecinta a insasi definitiei unui obiect (o abstractizare a unei entitati din lumea reala sau a unui concept, care realizeaza o singura functie in cadrul aplicatiei).

Un sistem va include in mod tipic urmatoarele straturi:

• interfata utilizator
• componente specifice aplicatiei
• componente de uz general (reutilizabile)
• mecanisme cheie (de ex: tratarea erorilor, mecanisme de comunicare)
• componente ale sistemului de operare sau implementate hardware.

Cuprinde totalitatea componentelor care participa pe durata executiei sistemului (de ex: programe executabile, biblioteci cu legare dinamica, mecanisme de sincronizare si executie concurenta) si a relatiilor de dependenta dintre ele.

Planul repartizarii (Deployment view)

Se refera la topologia hardware utilizata ca suport de procesare pentru sistemul dezvoltat. Modelul corespunzator acestei fatete va reda nodurile utilizate si conexiunile dintre ele. Prin nod se intelege in general o resursa dotata cu o anumita capacitate de memorare si, cel mai adesea, cu o anumita capacitate de procesare.

Fiecare dintre fatetele arhitecturale enumerate mai sus poate da o imagine de sine statatoare asupra sistemului, astfel incat diferitele persoane implicate in dezvoltarea si utilizarea sistemului sa-si poata concentra atentia asupra acelor aspecte care le privesc cel mai mult. Pe de alta parte, intre cele 5 fatete exista interactiuni. Astfel, nodurile topologiei hardware sunt masinile care vor executa componentele implementarii, care, la randul lor, constituie realizarea fizica a elementelor planului logic (clase, obiecte, intefete, relatii).
 
 

Notatia UML ca suport de modelare a arhitecturii

Notatia UML nu este obligatoriu legata de un anumit mod de abordare a dezvoltarii unui sistem software. Autorii notatiei afirma insa ca: "pentru a obtine maximum de beneficii din utilizarea ei, se recomanda ca ea sa se aplice in contextul unui proces de dezvoltare software care sa fie:

• dirijat de cazurile de utilizare
• centrat pe arhitectura
• iterativ si incremental" [BoRuJa99].

Un proces centrat pe arhitectura este acela care utilizeaza arhitectura sistemului ca baza pentru conceptualizarea, constructia si managementul sistemului aflat in dezvoltare.

Ce este un proces iterativ si incremental am vazut in lucrarea precedenta.

In ceea ce priveste legatura dintre arhitectura unui sistem si notatia UML, trebuie spus ca fiecare dintre fatetele arhitecturii prezentate in paragraful anterior pot fi modelate si puse in corespondenta unele cu altele folosind notatia UML, si anume cu ajutorul diagramelor UML.

Fiecare fateta arhitecturala poate fi modelata sub 2 aspecte:

• Static:
• cazurile de utilizare - prin diagramele cazurilor de utilizare;
• planul logic - prin diagramele claselor si diagramele obiectelor;
• implementarea si procesele - prin diagrame de componente;
• repartizarea - prin diagrame de repartizare.
• Dinamic, prin:
• diagrame de interactiune
• diagrame de stare
• diagrame de activitate.

In cele ce urmeaza vom prezenta elementele de baza ale limbajului UML, pentru a putea trece la descrierea modelelor corespunzatoare fatetelor arhitecturale.

Vocabularul notatiei UML cuprinde 3 categorii de elemente primare:

• entitati
• relatii intre entitati
• diagrame = colectii de entitati grupate dupa o anumita logica.

Entitatile
Sunt de 4 feluri:

• structurale
• comportamentale
• grupari
• adnotari.

Sunt echivalentele substantivelor din vocabularul unui limbaj natural. Ele au un caracter preponderent static si pot corespunde unor obiecte fizice sau unor concepte. In UML exista 7 tipuri de entitati structurale:

• [a] Clase: o clasa este descrierea unei multimi de obiecte caracterizate prin aceleasi atribute, operatii, relatii si semantica. O clasa implementeaza una sau mai multe interfete. Simbolul grafic utilizat pentru reprezentarea unei clase este:

• [b] Interfete: o interfata este o colectie de operatii care formeaza impreuna un serviciu oferit de o clasa sau de o componenta. Interfata descrie comportarea unei clase sau componente asa cum este ea perceputa din exterior. Interfata contine doar specificatiile (sau semnaturile) operatiilor, nu si definitiile (implementarile) acestora. O interfata nu apare de obicei singura, ci mai degraba atasata clasei sau componentei ale carei operatii le descrie. Simbolul grafic utilizat pentru reprezentarea unei interfete este:

• [c] Colaborari: o colaborare defineste o interactiune intre elementele componente ale unui ansamblu, elemente care functioneaza in cooperare, astfel incat comportamentul ansamblului este superior sumei comportamentelor fiecarui element luat separat. Simbolul grafic utilizat pentru reprezentarea unei colaborari este:



• [d] Cazuri de utilizare: reprezinta descrieri ale unor secvente de actiuni executate de sistem, in urma carora se furnizeaza utilizatorului rezultate semnificative. Actiunile descrise intr-un caz de utilizare se executa ca urmare a interactiunii dintre sistem si un factor extern numit actor. Actorul poate fi o persoana sau un alt sistem care apartin mediului exterior in raport cu sistemul de modelat, dar care intra in contact cu acesta, furnizandu-i si/sau preluand informatii de la el. Simbolul grafic utilizat pentru reprezentarea unui caz de utilizare este:



• [e] Clase active: sunt clase ale caror obiecte contin un numar oarecare de procese sau fire de executie cu comportament concurential. Spre deosebire de obiectele obisnuite (obiecte pasive), obiectele active isi initiaza si controleaza singure executia proceselor. Simbolul grafic utilizat pentru reprezentarea unei clase active este similar celui pentru clase, dar conturul este ingrosat.
• [f] Componente: sunt parti fizice si inlocuibile ale sistemului, care concretizeaza operatiile descrise de unele interfete. Componentele reprezinta de regula ansambluri de elemente logice (clase, interfete, colaborari). Exemple tipice de componente sunt fisierele de cod sursa. Simbolul grafic utilizat pentru reprezentarea unei componente este:



• [g] Noduri: un nod este un element fizic reprezentand o resursa computationala dotata cel putin cu capacitate de memorare si, adesea, cu capacitate de procesare. Un set de componente pot sa rezide intr-un nod sau pot migra de la un nod la altul. Simbolul grafic utilizat pentru reprezentarea unui nod este:

Reprezinta partea dinamica a modelelor UML, fiind echivalentele verbelor dintr-un vocabular. Ele modeleaza comportamentul ca functie de timp si spatiu. In UML exista 2 tipuri de entitati comportamentale:

• [a] Interactiunile: o interactiune este comportamentul rezultat ca urmare a unui schimb de mesaje intre anumite obiecte, avand ca scop indeplinirea unui anumit serviciu. Notiunea de interactiune include tot ansamblul format din: mesaje, operatiile invocate de mesaje si legaturile (conexiunile) dintre obiectele implicate. Simbolul grafic utilizat pentru reprezentarea unui mesaj este:



• [b] Masinile de stari: o masina de stari specifica succesiunea starilor prin care trece un obiect sau o interactiune pe durata existentei sale, ca raspuns la anumite evenimente. Notiunea de masina de stari include: stari, tranzitii (treceri de la o stare la alta), evenimente (ceea ce declanseaza tranzitiile) si activitatile (raspunsurile la tranzitii). Simbolul grafic utilizat pentru reprezentarea unei stari este:

Reprezinta aspectul organizatoric al modelelor UML. In UML exista un singur tip de entitati de grupare, si anume pachetele.

Un pachet este un mecanism general care serveste la organizarea diferitelor elemente in grupuri. Intr-un pachet pot fi plasate entitati de orice fel. Spre deosebire de componente (care exista in timpul executiei), pachetele sunt o notiune pur conceptuala, ele existand doar pe durata dezvoltarii. Simbolul grafic utilizat pentru reprezentarea unui pachet este:

Adnotarile

Reprezinta partea explicativa a modelelor UML. Adnotarile sunt comentarii care se pot atasa oricarui element din model. In UML exista un singur tip de adnotari, si anume notele. Simbolul grafic utilizat pentru reprezentarea unei note este:
 

Relatiile
Sunt de 4 feluri:

• de dependenta (dependente)
• asocieri
• generalizari
• realizari.

Este o relatie semantica intre 2 entitati al carei sens este urmatorul: o modificare adusa uneia dintre entitati (cea independenta) poate afecta semantica celeilalte entitati (cea dependenta). Simbolul grafic utilizat pentru reprezentarea unei dependente este:

Asocierea

Este o relatie structurala care descrie un set de legaturi, o legatura fiind o conexiune intre obiecte. Un caz particular de asociere este agregarea, care reprezinta o relatie structurala stabilita intre un intreg si partile care il compun. Simbolul grafic utilizat pentru reprezentarea unei asocieri este un segment de dreapta pe care se inscriu, dupa caz, ordine de multiplicitate si nume de roluri.

Generalizarea

Este o relatie de tip specializare/generalizare intre 2 obiecte, al carei sens este urmatorul: unul dintre obiecte este obiectul specializat (sau fiul) si el poate substitui obiectul celalalt, care este obiectuil generalizat (sau parintele).Simbolul grafic utilizat pentru reprezentarea unei generalizari este:

Realizarea

Este o relatie semantica intre 2 entitati, al carei sens este urmatorul: una dintre entitati specifica un contract pe care cealalta entitate se angajeaza sa-l indeplineasca. Relatiile de realizare se intalnesc in 2 cazuri:

• intre interfete si clasele sau componentele care le implementeaza
• intre cazurile de utilizare si colaborarile care le indeplinesc.

Diagramele
O diagrama este o prezentare grafica a unui set de elemente, cel mai adesea de forma unui graf, posibil orientat. Nodurile grafului corespund de regula entitatilor, iar arcele - relatiilor. Diagramele permit vizualizari ale unui sistem din diferite perspective. De aceea, se poate spune ca o diagrama reprezinta o proiectie asupra sistemului.
Teoretic, o diagrama poate contine orice combinatie de entitati dimpreuna cu relatiile dintre ele. Practic insa, un numar mic de diagrame sunt cu adevarat utile si prezinta consistenta in raport cu cele 5 fatete ale arhitecturii unui sistem.
Notatia UML propune 9 tipuri de diagrame:

• Diagrame de clase: contin seturi de clase, interfete, colaborari si relatiile dintre ele. Reprezinta cele mai frecvent utilizate diagrame in modelele UML. Diagramele de clase surprind aspectul static al planului logic al unui sistem. Diagramele care contin clase active surprind aspectul static al planului proceselor.
• Diagrame de obiecte: contin seturi de obiecte si relatiile dintre ele. Diagramele de obiecte reprezinta imagini statice ale instantelor entitatilor din diagramele de clase. Ele adreseaza aceleasi aspecte ale unui sistem ca si diagramele de clase, dar din perspectiva unor situatii reale sau a unor prototipuri.
• Diagrame ale cazurilor de utilizare: includ seturi de actori, cazuri de utilizare si relatiile dintre ele. Surprind aspectu static al cazurilor de utilizare, fiind foarte importante in organizarea si modelarea comportamentului sistemului.
• Diagrame de secventa, si
• Diagrame de colaborare: amandoua sunt tipuri de diagrame de interactiune, in sensul ca includ seturi de obiecte aflate in interactiune impreuna cu mesajele schimbate intre ele. Diagramele de secventa reliefeaza succesiunea in timp a mesajelor, in timp ce diagramele de colaborare descriu organizarea structurala a setului de obiecte care trimit/receptioneaza mesaje. Aceste diagrame formeaza un cuplu izomorf, adica oricare dintre cele doua tipuri de diagrame poate fi transformat in celalalt tip. Ambele tipuri de diagrame acopera aspecte dinamice ale sistemului.
• Diagrame de stari: contin masini de stari, adica ansambluri de stari, tranzitii, evenimente si activitati. Sunt foarte importante in modelarea comportamentului interfetelor, claselor si a colaborarilor. Reliefeaza modul in care evenimentele determina comportarea unui obiect. Acopera aspecte dinamice ale unui sistem, fiind utile in modelarea sistemelor reactive.
• Diagrame de activitate: sunt o varianta speciala a diagramelor de stari, care ilustreaza fluxul de activitati in interiorul sistemului. Sunt utile in modelarea functionarii sistemelor.
• Diagrame de componente: redau modul de organizare si dependentele intr-o multime de componente. Acopera aspectul static al implementarii unui sistem. Aceste diagrame sunt legate de diagramele de clase, in sensul ca unei componente ii corespund una sau mai multe clase, interfete sau colaborari.
• Diagrame de repartizare: ilustreaza configuratia nodurilor folosite in procesare si a componentelor care rezida pe ele. Acopera aspectul static al planului repartizarii din arhitectura unui sistem. Aceste diagrame sunt legate de diagramele de componente, in sensul ca unui nod ii corespund una sau mai multe componente.

Modul de operare in cadrul mediului de dezvoltare Rational Rose precum si organizarea interfetei utilizator a mediului sunt favorabile abordarii unui sistem software prin prisma celor "4+1" fatete.

Mediul Rational Rose a fost conceput sa functioneze sub sistemele MSWindows. Spatiul de lucru al ferestrei principale este divizat in 3 regiuni de baza:

• fereastra de baleiere (browsing)
• fereastra de documentare
• ferestrele pentru diagrame.

Ca mod de functionare, aceasta fereastra se comporta similar cu omoloaga ei din programul Windows Explorer. Daca in Explorer fereastra de browsing este dedicata vizualizarii structurii de directoare si fisiere, in Rational Rose aceeasi fereastra vizualizeaza o structura arborescenta a arhitecturii sistemului de dezvoltat. Nodurile de pe primul nivel sunt predefinite si ele desemneaza fatetele:

• cazurile de utilizare,
• planul logic,
• planul componentelor si
• planul repartizarii.

Nodurile de pe nivelele inferioare vor fi adaugate pe masura elaborarii modelelor sistemului si ele vor corespunde elementelor ce compun modelele respective: entitati si diagrame. Unele dintre aceste noduri sunt predefinite, acestea corespunzand elementelor obligatorii din componenta modelelor. Numele acestor noduri este Main. De exemplu, fiecare sistem are un caz principal de utilizare, o diagrama principala a claselor etc.
Adaugarea de elemente noi in fereastra de browsing se face in principiu astfel: se da un clic cu butonul drept pe nodul "parinte" => un meniu de comenzi rapide din care se selecteaza optiunea New, apoi din submeniul afisat se selecteaza tipul elementului dorit (de ex: Actor, Use Case etc).

Fereastra de documentare

Este o simpla fereastra de editare de text cu ajutorul careia se pot atasa comentarii explicative elementelor din fereastra de browsing. Pentru aceasta este suficient sa se selecteze elementul dorit in fereastra de browsing, apoi sa se pozitioneze cursorul in fereastra de documentare si sa se tasteze textul necesar.

Ferestrele de diagrame

Reprezinta spatiul in care se realizeaza editarea diagramelor. Totalitatea diagramelor, impreuna cu legaturile dintre ele compun modelul unui sistem. Modelul poate fi salvat intr-un fisier care primeste extensia implicita .mdl.
Principiul de desenare a unei diagrame consta in a trage cu mouse-ul elementele ce constituie nodurile grafului din fereastra de browsing spre fereastra diagramei. Arcele (legaturile) vor fi create cu ajutorul butoanelor de pe bara de intrumente atasata ferestrelor de diagrame (aflata in stanga acestora).
 

Studiu de caz

In cele ce urmeaza vom incepe prezentarea modului de elaborare a unui model de sistem software cu ajutorul mediului Rational Rose, bazandu-ne pe un exemplu concret. In lucrarea de fata va fi prezentata partea de elaborare a diagramelor cazurilor de utilizare, urmand ca in lucrarile urmatoare sa fie abordate si alte diagrame.
Inainte de a da enuntul problemei vom detalia putin notiunile legate de cazurile de utilizare.

Rolul cazurilor de utilizare
Cazurile de utilizare documenteaza, prin intermediul unor modele de cazuri de utilizare, comportarea unui sistem, asa cum este ea perceputa din exterior. Rolul cel mai important al unui asemenea model este acela de comunicare, el fiind un mijloc prin care utilizatorii si proiectantii isi transmit unii altora ideile legate de functionalitatea sistemului dorit.
Un model de caz de utilizare include:

• functiile asteptate de la sistem = cazurile de utilizare propriu-zise
• factorii externi care interactioneaza cu sistemul = actorii
• relatiile dintre actori si cazurile de utilizare, ilustrate prin diagrame ale cazurilor de utilizare.

Actorii
Actorul este orice persoana sau obiect care nu face parte din sistem, dar interactioneaza cu acesta.
Un actor poate sa introduca si/sau sa obtina informatii in/din sistem.
De obicei actorii sunt mentionati in enuntul problemei, respectiv pot fi identificati din conversatiile cu beneficiarii sistemului si cu expertii in domeniu.
Pentru identificarea actorilor pot fi folosite urmatoarele intrebari ajutatoare:

• cine este interesat intr-o anumita cerinta?
• unde va fi utilizat sistemul in cadrul institutiei beneficiarului?
• cine beneficiaza prin utilizarea sistemului?
• cine furnizeaza/consulta/sterge o anumita informatie in/din sistem?
• cine va intretine si gestiona sistemul?
• ce resurse externe va utiliza sistemul?
• ce roluri distincte joaca fiecare persoana care are contact cu sistemul?
• exista mai multe persoane care joaca acelasi rol?
• sistemul analizat va interactiona cu un alt sistem deja existent?

Cazurile de utilizare

Un caz de utilizare modeleaza un dialog intre un actor si sistem, reprezentand functionalitatea oferita de sistem acelui actor. Colectia tuturor cazurilor de utilizare ale unui sistem constituie multimea tuturor cailor definite in care sistemul poate fi utilizat.
Definitia formala a unui caz de utilizare: o secventa de tranzactii efectuate de sistem, prin care se genereaza un rezultat masurabil pentru un anumit actor.
Pentru identificarea cazurilor de utilizare pot fi folosite urmatoarele intrebari ajutatoare:

• care sunt sarcinile fiecarui actor?
• exista actori care creaza/stocheaza/modifica/elimina/consulta informatii in/din sistem?
• in ce imprejurari au loc operatiile de mai sus?
• exista vreun actor care trebuie sa informeze sistemul in legatura cu aparitia unor modificari exterioare bruste?
• exista vreun actor care trebuie informat in legatura cu anumite evenimente aparute in sistem?
• care sunt situatiile in care au loc operatii de intretinere a sistemului?
• pot toate cerintele functionale sa fie acoperite de cazurile de utilizare identificate?

Fluxul de evenimente al unui caz de utilizare

Este o descriere a evenimentelor necesare pentru ca functiunile cerute printr-un caz de utilizare sa fie indeplinite. Descrierea este formulata in termenii a ceea ce sistemul trebuie sa faca si nu cum ar trebui sa faca. Cu alte cuvinte, fluxul evenimentelor este exprimat in limbajul domeniului problemei si nu al implementarii.
Fluxul de evenimente trebuie sa includa:

• cand si cum incepe/se sfarseste un caz de utilizare;
• ce interactiuni are cazul de utilizare cu actorii;
• de ce date are nevoie cazul de utilizare;
• secventa normala a evenimentelor pentru cazul de utilizare;
• descrierea fluxurilor alternative sau de exceptie.

• n.0 Titlu: Fluxul evenimentelor pentru cazul de utilizare <nume_caz>
• n.1 Preconditii
• n.2 Fluxul principal
• n.3 Subfluxuri (daca e cazul)
• n.4 Fluxuri alternative

Relatiile cazurilor de utilizare

Relatiile in care sunt implicate cazurile de utilizare pot fi:

• Relatii intre actori si cazurile de utilizare: sunt relatii de asociere, care se mai numesc si asocieri de tip comunicare, pentru ca ele modeleaza realmente niste comunicari. O asociere poate fi parcursa in ambele sensuri sau doar intr-un sens, intre actor si cazul de utilizare. Sensul parcurgerii este impus de initiatorul comunicarii: actorul sau cazul de utilizare. Daca asocierea poate fi parcursa intr-un singur sens, segmentul care constituie simbolul UML pentru asociere se prevede cu un varf de sageata in capatul opus initiatorului comunicarii.
• Relatii intre 2 cazuri de utilizare: pot fi de tipul
  • "utilizeaza" (uses): daca se constata ca mai multe cazuri de utilizare includ aceeasi secventa de functionare, atunci secventa respectiva se poate constitui ca un caz separat, iar intre cazurile care contin aceasta secventa si noul caz vor fi stabilite relatii de tip "utilizeaza".
  • "extinde" (extends): se foloseste pentru a indica functionalitati optionale, functii care se executa in anumite conditii sau un set de fluxuri distincte care se vor executa daca sunt selectate de un actor.
  Ambele sunt relatii de generalizare, motiv pentru care se vor reprezenta cu acelasi simbol UML. Pentru a le distinge totusi, se va utiliza un concept al limbajului UML, numit stereotip. Acest concept permite extinderea unui set minimal de simboluri pentru a crea elemente de modelare noi. Un stereotip se reprezinta sub forma unui nume incadrat de simbolurile << si >>, si plasat alaturi de elementul de modelare care trebuie extins.
  Prin urmare, pentru relatiile de tip "utilizeaza" si "extinde", se pot folosi stereotipurile: <<uses>>, respectiv <<extends>> (nu e obligatoriu sa se foloseasca termeni in limba engleza!).

Diagramele cazurilor de utilizare

Cuprind o parte sau toti actorii, cazurile de utilizare si relatiile lor, pentru un sistem dat.
Orice sistem are de obicei o diagrama a cazului principal, care ofera o imagine a frontierelor sistemului (adica actorii) si a functionalitatii de baza oferite de sistem. Alte diagrame pot fi create dupa necesitati si pot include:

• o diagrama a tuturor cazurilor corespunzatoare unui actor dat;
• o diagrama a tuturor cazurilor identificate intr-o singura iteratie a procesului de dezvoltare;
• o diagrama reprezentand un caz de utilizare cu toate relatiile in care este implicat;
• etc.

Enuntarea problemei

Problema analizata se refera la dezvoltarea unui sistem de evidenta a inscrierii la cursuri a studentilor unei universitati.
La inceputul fiecarui semestru studentii pot solicita un catalog continand ofertele de cursuri. Pentru fiecare curs catalogul va include informatii referitoare la titular, departament si cunostintele necesare pentru a urma cursul. Studentii trebuie sa selecteze cate 4 cursuri, indicand la fiecare cate 2 alternative, pentru cazurile in care la unele cursuri nu mai sunt locuri sau cursurile au fost anulate. Se precizeaza ca pentru un curs se pot inscrie max. 10 studenti si min. 3 studenti. Daca la un curs se inscriu mai putin de 3 studenti, cursul respectiv se anuleaza.
Pe de alta parte, profesorii trebuie sa aiba acces on-line la sistem pentru a indica ce cursuri ofera spre predare, respectiv pentru a vedea ce studenti s-au inscris la cursurile lor.
Studentii vor beneficia de o anumita perioada "de razgandire", timp in care vor putea sa-si modifice optiunile.
Dupa incheierea perioadei de inscriere, sistemul de evidenta a inscrierilor trebuie sa trimita spre un alt sistem, insarcinat cu taxarea studentilor, informatii necesare intocmirii notelor de plata.
Gestionarea bazei de date cuprinzand informatiile despre profesorii din universitate, studentii inmatriculati si planul de invatamant + orar va fi efectuata de catre un registrator.
 

• Identificarea actorilor: pentru cazul studiat s-au putut identifica urmatorii actori: Student, Profesor, Registrator si Sistem de taxare. Un exemplu de problema care apare la analiza actorilor pentru problema data este cea a statutului unui preparator. Acesta este in acelasi timp si student si cadru didactic si se pune intrebarea daca e necesar sa fie considerat ca un actor distinct. Raspunsul este nu, deoarece operatiile de inscriere la cursuri, respectiv de predare sunt deja acoperite de actorii Student si Profesor.
  Reguli:
  • Daca 2 persoane distincte joaca roluri identice in raport cu sistemul (adica utilizeaza sistemul in acelasi fel), ele vor fi reprezentate de un singur actor.
  • Daca aceeasi persoana joaca mai multe roluri distincte in raport cu sistemul, iar aceste roluri sunt deja "acoperite" cu actori, pentru persoana respectiva nu se va crea un nou actor.

• Cazurile de utilizare: pentru problema prezentata se pot considera urmatoarele cazuri de utilizare:
  • inscriere la cursuri,
  • selectie cursuri pentru predare,
  • solicitarea spre consultare a listei de cursuri,
  • intretinerea informatiilor despre planul de invatamant,
  • intretinerea informatiilor despre profesori,
  • intretinerea informatiilor despre studenti si
  • crearea catalogului de cursuri.

• Fluxul de evenimente: se va lua ca exemplu fluxul corespunzator cazului Selectia cursurilor de predat. Documentul care contine descrierea unui flux este un fisier extern mediului Rational Rose, creat cu un editor oarecare. In Rational Rose se inregistreaza doar legaturi intre cazurile de utilizare si aceste fisiere.

• Diagramele cazurilor de utilizare: daca este vorba de o diagrama auxiliara, ea trebuie mai intai adaugata in fereastra de browsing, conform mecanismului prin care au fost creati actorii si cazurile de utilizare (in ultimul meniu afisat se selecteaza optiunea Use Case Diagram); daca este vorba de diagrama principala, aceasta este deja prezenta in fereastra de browsing, sub numele Main, subordonata nodului "parinte" Use Case view. Pentru a desena diagrama propriu-zisa, se da dublu-clic pe numele ei in fereastra de browsing => deschiderea unei ferestre de diagrama; in aceasta fereastra se trag cu mouse-ul actorii si cazurile de utilizare dorite din fereastra de browsing. Relatiile (arcele) din diagrama se creaza folosind butoanele de pe bara cu instrumente atasata ferestrei de diagrama si urmand o procedura similara celei aplicate la desenarea unui segment de dreapta sau a unei sageti cu Word-ul. Se considera ca punctele de delimitare ale unui segment sau sageti sunt de fapt simbolurile actorilor si/sau cazurilor de utilizare implicate.

Adaugarea de stereotipuri la relatii, acolo unde e necesar, se face astfel: se da dublu clic pe segmentul corespunzator relatiei si in fereastra afisata, in campul Stereotype se tasteaza (sau se selecteaza dintr-o lista drop-down) numele stereotipului.

In figura 11.2 este ilustrata diagrama principala a cazurilor de utilizare pentru exemplul analizat:

In figura 11.3 este prezentat un exemplu de diagrama auxiliara a cazurilor de utilizare, in care apare o relatie de tip "utilizeaza". Din analiza cazurilor Selectie cursuri de predat si Cerere lista de cursuri s-a dedus ca in ambele apare cate o operatie de validare a identificatorului profesorului. Ca urmare, aceasta operatie s-a constituit intr-un caz de utilizare aparte (cu alte cuvinte, s-a efectuat o "factorizare" a cazurilor).

Probleme

Se cere sa se identifice si apoi sa se modeleze in Rational Rose actorii, cazurile de utilizare si relatiile aferente, pentru un sistem de rezervare a biletelor CFR care are urmatoarele cerinte:
Calatorii vor avea acces on-line la sistem, pentru a consulta mersul trenurilor, in speta oferta de trenuri intre 2 statii date.
Casierii vor accesa sistemul pentru a realiza, daca este posibil, rezervari la un anumit tren, pentru o anumita destinatie si un anumit numar de locuri. In cazul efectuarii rezervarii, sistemul va calcula costul, pe baza unor tabele de tarife. Casierul va confirma plata, iar sistemul va tipari biletele de calatorie.
Gestionarea bazei de date cu informatii legate de mersul trenurilor si tabelele de tarife va fi efectuata de un operator central.
Calatorii, prin intermediul casierilor, vor avea posibilitatea sa renunte la rezervari, caz in care sistemul va trebui sa calculeze suma de rambursat; aceasta va depinde de momentul renuntarii (inainte sau dupa plecarea trenului).
Se lasa la latitudinea proiectantilor alegerea informatiilor care trebuie introduse/extrase in cazul fiecarui caz de utilizare, precum si identificarea unor cazuri de exceptie posibile.

Bibliografie

[BoRuJa99] Grady Booch, James Rumbaugh, Ivar Jacobson  - "The Unified Modeling Language User Guide", Addison-Wesley, 1999
[Qua98] Terry Quatrani - "Visual Modeling with Rational Rose and UML", Addison-Wesley, 1998