MODELAREA SISTEMELOR INFORMATICE

Informatica

ALTE DOCUMENTE

Tabel de dispersie. Tipul abstract dictionar.

Liste înlãntuite. Multimi realizate ca liste

Tutorial administrare cont e-mail

Instalarea emblemelor romanesti in TCM2004

UTILIZAREA PROGRAMULUI INTERNET EXPLORER

Header and Footer (antete si subsoluri)

Prezentarea unui algoritm:

Identificarea structurii hardware

Schema aplicatiei \"Magazin Virtual\" baze de date

Memoria interna a calculatorului

MODELAREA SISTEMELOR INFORMATICE

Modelele construite pe parcursul dezvoltarii unui sistem sunt reprezentari abstracte ale sistemului. Fiecare model reflecta o anumita vedere asupra sistemului si corespunde unui nivel de detaliu.

In etapa de analiza se construiesc modele care exprima cerintele impuse sistemului. Modelele de analiza corespund unei vederi externe asupra sistemului. Se folosesc de catre client, viitorii utilizatori ai sistemului, experti ai domeniului aplicatiei, analisti, echipa de verificare si validare a sistemului.

In etapa de proiectare se construiesc modele care redau arhitectura sistemului, alocarea cerintelor pe subsisteme, distributia proceselor in sistem, sincronizarea lor, starile si tranzitiile intre stari. Alte modele descriu realizarea fizica a sistemului, echipamentele din componenta sa si repartitia componentelor program.

Fiecare vedere asupra unui sistem poate avea aspecte structurale si aspecte comportamentale. In functie de natura sistemului, unele modele pot fi mai importante decat altele. De exemplu, pentru unele sisteme sunt mai importante aspectele structurale si functionale, pentru altele aspectele temporale.

Construirea modelelor este ghidata de metode. O metoda defineste o abordare reproductibila care permite obtinerea de rezultate fiabile n mod repetat. Toate domeniile cunoasterii utilizeaza metode mai mult sau mai putin sofisticate si mai mult sau mai putin formalizate. De exemplu, bucatarii utilizeaza retete de bucatarie, arhitectii construiesc planuri, muzicienii urmeaza reguli de compozitie.

Modelele sunt alcatuite din elemente de modelare care constituie concepte fundamentale pentru reprezentarea sistemelor sau a fenomenelor. Elementele de modelare sunt adesea notatii grafice. Ele constituie limbajul de modelare.

In plus fata de limbajul de modelare, o metoda defineste reguli de aplicare care descriu coordonarea diferitelor puncte de vedere, nlantuirea actiunilor, ordonarea sarcinilor si repartizarea responsabilitatilor.

Principalele scopuri ale modelarii sistemelor informatice sunt:

vizualizarea, ca mijloc de usurare a comunicarii si intelegerii;

specificarea, prin construirea de modele precise, neambigue si complete;

documentarea cerintelor, a solutiilor de proiectare si a modului de realizare.

2.1. Metode de analiza si de proiectare

Proiectarea unui sistem are loc pe baza unei specificatii a cerintelor, deci este o continuare a procesului de analiza. Metodele de proiectare sunt strans legate de cele folosite in analiza, modelele de proiectare fiind adesea construite plecand de modelele de analiza. De aceea, multe dintre metodele de dezvoltare a programelor furnizeaza atat elemente de modelare utile in analiza cerintelor cat si elemente de modelare specifice fazei de proiectare.

Exista doua strategii de structurare a unui sistem informatic, pe baza carora metodele de analiza si proiectare sunt clasificate in metode functionale si metode orientate obiect.

2.1.1. Metodele functionale

Aceste metode si au originile n dezvoltarea limbajelor procedurale. Mai orientate catre prelucrari dec t spre date, ele propun o abordare ierarhica descendenta, bazata pe descompunerea prelucrarilor care trebuie sa fie efectuate de un sistem. Principalul instrument de analiza este diagrama de flux de date. Metodele de analiza structurata (Structured Analysis) si de proiectare structurata (Structured Design) sunt reprezentative pentru aceasta categorie de metode. Ele cuprind un ansamblu de notatii pentru specificarea programului. Astfel, n timpul fazei de analiza se folosesc diagrame de flux de date, diagrame de stari/tranzitii si diagrame entitate/legatura. In faza de proiectare sunt adaugate detalii modelelor de analiza si plec nd de la diagramele de flux de date sunt construite diagramele de structura.

Diagramele de flux de date

Se folosesc pentru a modela transformarile datelor pe masura ce acestea tranziteaza sistemul. O diagrama de flux de date este alcatuita din blocuri de prelucrare si blocuri " rezervoare de date". Fluxul datelor este reprezentat prin sageti. Fig. 2.1 ilustreaza tratarea propunerilor facute unei ntreprinderi de catre societati de servicii[ ]. Prelucrarile sunt reprezentate prin elipse iar rezervoarele prin dreptunghiuri.

Fig. 2.1. Diagrama de flux de date

Plec nd de la diagrama de cel mai nalt nivel, prelucrarile complexe sunt descompuse recursiv n subdiagrame p na la prelucrari simple, usor de implementat. Prelucrarile simple sunt specificate n pseudocod, folosind tabele de decizie, sau alte tehnici.

Diagramele de flux de date sunt simple si intuitive. Ele pot fi folosite ca mijloc de comunicare cu potentialii utilizatori ai sistemului care participa la validarea cerintelor. Totodata, la nivelul proiectarii arhitecturale, ele pot reflecta schimbul de date intre sub-sisteme. Nu sunt adecvate pentru modelarea sub-sistemelor cu interfete complexe. Este necesara o diagrama pentru fiecare intrare particulara.

Diagramele de stari-tranzitii

Se folosesc pentru a modela comportamentul dependent de timp al sistemului. Ele sunt similare celor din notatia UML (prezentate n paragraful 2.3.).

Diagramele entitate/legatura (ER)

Reflecta relatiile dintre rezervoarele de date. Fiecare "entitate" corespunde unui rezervor de date dintr-o diagrama de flux de date. Relatiile dintre entitati sunt numite "asocieri". Entitatile si asocierile pot fi caracterizate prin atribute. Figura 2.2 pune n evidenta trei entitati: proiect, propunere si societate servicii, reprezentate prin dreptunghiuri, fiecareia fiindu-i asociate atribute. De exemplu, entitatii proiect i se asociaza un cod proiect care identifica ntr-o maniera unica proiectul, un nume de proiect, un nume de responsabil si o data limita.

Fig. 2.2. Diagrama entitate/legatura

Proiectarea structurata urmeaza analizei structurate si stabileste modalitatile concrete de realizare a sistemului. De exemplu, prelucrarile din diagramele de flux de date sunt grupate n task-uri si alocate proceselor sistemului de operare.

Diagramele de structura

Modeleaza arhitectura unui sistem ca o ierarhie de module ( functii) si o prezinta sub forma unei structuri arborescente (figura 2.3). Modulele sunt reprezentate prin noduri iar conexiunile intre module prin arce. Un arc conecteaza un modul, situat pe nivelul n, de modulul care-l apeleaza, situat pe nivelul (n-1). Parametrii de intrare si de iesire sunt indicati de-a lungul conexiunilor, prin texte si sageti.

Pot fi construite mai multe diagrame de structura pornind de la o diagrama de flux. Proiectantul trebuie sa aleaga solutia care conduce la componente slab cuplate si cu o coeziune interna puternica.

Fig 2.3. Diagrama de structura.

Identificarea modulelor program pornind de la o diagrama de flux este simplificata daca se aloca fiecarui modul una dintre urmatoarele functii, derivate din fluxul datelor (figura 2.4):

Figura 2.4. Tipuri de module program

Un modul de intrare accepta date de intrare ale sistemului sau date de la un modul situat pe un nivel mai coborat al diagramei si le transfera unui modul situat pe un nivel superior, intr-o forma transformata. Un modul de transformare accepta date de la un modul de nivel superior, le transforma si le transfera inapoi modulului.

Mai intai se identifica modulele de intrare-iesire la cel mai inalt nivel de 21121n1315v abstractizare. Procesul se repeta pentru fiecare dintre blocurile definite pe primul nivel, etc. Intr-un proiect bine structurat fiecare nod al diagramei de structura trebuie sa aiba 2-7 descendenti.

Dictionarul de date

Contine detalii care nu sunt cuprinse n diagramele prin care se modeleaza sistemul. El descrie fluxuri de date, rezervoare de date, entitati, module si semnificatia numelor atribuite.

Dictionarul de date este un mijloc de management al numelor. El nu este specific unei metode de dezvoltare. Un sistem mare este modelat de un numar mare de persoane, fiecare adaugand diverse nume pentru entitati si relatii. Pot sa apara inconsistente si conflicte de denumiri. Dictionarul de date permite verificarea unicitatii numelor. Crearea, actualizarea si interogarea dictionarului de date sunt necesare pe intreaga durata de viata a unui sistem. Aceste operatii trebuie sa fie efectuate cu ajutorul unui program al mediului de dezvoltare.

2.1. 2. Metode orientate obiect

Aceste metode se bazeaza pe conceptele de clasa, obiect, abstractie, specializare si comunicare prin mesaje.

Analiza orientata obiect permite examinarea unei probleme pun ndu-se n evidenta clasele sub forma de componente independente si obiectele care interactioneaza dupa modalitati bine definite. Rezultatele unei asemenea analize pot sa serveasca de baza pentru o proiectare orientata obiect.

In majoritatea metodelor orientate obiect, studiul unei probleme este realizat urmarind trei aspecte:

aspectul static sau descriptiv, care reda obiectele si legaturile dintre ele;

aspectul dinamic, care precizeaza comportamentul obiectelor, diferitele stari prin care ele trec si evenimentele care declanseaza trecerea dintr-o stare n alta.

aspectul functional, care precizeaza functiile realizate de obiecte prin intermediul metodelor.

Metoda Grady Booch

Metoda propusa de Booch este o metoda de proiectare definita initial pentru programare n ADA, apoi generalizata pentru alte limbaje. Ea propune patru etape:

- identificarea obiectelor si a claselor la un nivel de abstractie dat;

- precizarea semanticii claselor precum si a interfetei fiecarei clase;

- identificarea relatiilor dintre clase, disting nd pe de o parte aspectele statice iar pe de alta parte aspectele dinamice;

- implementarea claselor si a comunicatiei dintre obiecte.

Abordarea nu este nici ascendenta, nici descendenta. Este mai degraba o metoda de proiectare incrementala si iterativa.

Metoda Jackson ( Jackson Structured Development )

Metoda JSD este, n particular, celebra n Europa. JSD nu face distinctie ntre analiza si proiectare, cele doua faze find grupate ca activitate de specificare. JSD divizeaza dezvoltarea sistemelor n doua etape: specificarea si apoi implementarea. Metoda este conceputa n special pentru aplicatii n care este important elementul timp. Ea utilizeaza modele grafice ca cele din SA/SD, OMT si alte tehnici.

Un model JSD descrie lumea reala n termeni de entitati, de actiuni si de ordonare a actiunilor. Dezvoltarea unui program consta din sase etape secventiale: etapa actiune a entitatilor, etapa de structurare a entitatilor, etapa de modelare initiala, etapa functie, etapa de analiza a aspectelor temporale ale sistemului si etapa de implementare.

In timpul etapei de actiune a entitatilor, sunt identificate entitatile si actiunile din lumea reala (domeniul problemei). Alegerea este ghidata de scopul realizarii sistemului. Etapa foloseste ca intrare definitia cerintelor; ea produce o lista de entitati si de actiuni. Actiunile se petrec n lumea reala. Ele au loc la momente de timp date, sunt atomice si nedecompozabile. Etapa de structurare a entitatilor ordoneaza partial actiunile fiecarei entitati n timp. Etapa de modelare initiala face legatura ntre lumea reala si modelul abstract. Etapa functie utilizeaza pseudocod pentru descrierea actiunilor. La sf rsitul acestei etape, se dispune de o specificatie completa a sistemului cerut.

Etapa de analiza a aspectelor temporale ale sistemului examineaza modul n care modelul se poate decupla de lumea reala. Rezultatul acestei etape este un ansamblu de note informale asupra constr ngerilor de performanta. Etapa de implementare se concentreaza pe problema proceselor si a alocarii lor la procesoare. Numarul de procese poate fi diferit de numarul de procesoare. Dupa cele sase etape se scriu programele si se concepe baza de date.

OMT ( Object Modeling Technique)

OMT propune modelarea unui sistem pe baza a trei puncte de vedere corelate dar distincte, fiecare evidentiind aspecte importante ale sistemului:

- aspectele statice, care sunt reprezentate n modelul obiect;

- aspectele temporale, comportamentale si de "control" ale sistemului,

redate n modelul dinamic;

- aspectele functionale si de transformare de date, reprezentate n

modelul functional.

Cele trei modele decupeaza sistemul n vederi ortogonale care pot fi reprezentate cu o notatie uniforma. Interconexiunile ntre modele sunt limitate si explicite.

Modelul obiect descrie structura obiectelor, identitatea lor, relatiile dintre obiecte, atributele lor si operatiile asociate obiectelor. Modelul obiect este reprezentat grafic prin diagrame de clase si diagrame de obiecte. Clasele sunt conectate prin diferite tipuri de asocieri si organizate n ierarhii de clase cu o structura si un comportament comun. Modelul obiect obtinut din analiza descrie obiectele domeniului aplicatiei (obiectele lumii reale). Modelul obiect rafinat n etapa de proiectare descrie modul concret de realizare a sistemului; el poate sa contina obiecte (constructii) informatice.

Modelul dinamic descrie sistemul n relatie cu timpul si secventierea operatiilor: evenimentele care marcheaza schimbarile, secventele de evenimente, starile care definesc contextul evenimentelor si organizarea starilor si evenimentelor. Modelul dinamic este reprezentat grafic prin diagrame de stare. Fiecare diagrama de stare descrie comportamentul dinamic al obiectelor unei clase. Activitatile si actiunile atasate starilor sunt descrise n modelul functional. Evenimentele corespund mesajelor (apeluri ale operatiilor), schimbate ntre obiectele modelului.

Modelul functional prezinta prelucrarile dintr-un sistem, independent de momentul la care sunt executate. El contine functii (operatii atasate claselor), constr ngeri si dependente functionale. Modelul functional este reprezentat prin diagrame de flux de date.

Comparatie ntre metodele functionale si metodele

orientate obiect

Metodele functionale (de exemplu SA/SD) si metodele orientate obiect (de exemplu OMT) au multe n comun. Ele utilizeaza constructii de modelare similare si suporta cele trei vederi ortogonale ale unui sistem. Diferenta este de stil si de punct de vedere. In abordarea functionala, modelul functional domina, urmeaza apoi ca importanta modelul dinamic, iar modelul obiect este cel mai putin important. Metodele obiect considera modelul obiect ca cel mai important, apoi modelul dinamic si la sf rsit modelul functional.

Metodele functionale organizeaza un sistem n jurul procedurilor. Invers, o tehnica de modelare obiect (cum ar fi OMT) organizeaza un sistem n jurul obiectelor lumii reale sau al obiectelor conceptuale care exista n viziunea utilizatorului din lumea reala. Cea mai mare parte a modificarilor cerintelor sunt modificari de functii; n general, obiectele din domeniul aplicatiei nu se schimba. Astfel, modificarile functionale pot presupune un efort mare de adaptare a programului n cazul unei proiectari bazate pe proceduri. Aceste modificari pot fi efectuate cu usurinta n cazul unei proiectari orientate pe obiectele din domeniul aplicatiei, adaug nd sau modific nd operatii, structura de baza a obiectelor ram n nd neschimbata. Metode cum ar fi SA/SD, sunt utile pentru dezvoltarea de programe n care prelucrarile sunt mai importante si mai complexe dec t datele.

O conceptie obiect este mai extensibila dec t o conceptie functionala. Se adauga pur si simplu obiecte si relatii care nu existau anterior.

Analogia directa dintre obiectele unei conceptii obiect si obiectele domeniului face ca sistemele sa fie mai usor de nteles, corespondenta dintre specificatie si cod fiind simplificata.

In SA/SD, descompunerea unei prelucrari n subprelucrari este oarecum arbitrara. Persoane diferite pot produce descompuneri diferite. In conceptia obiect, descompunerea este bazata pe obiectele domeniului problemei.

2.3. UML - Unified Modelling Language

In prima jumatate a anilor '90 au aparut diverse metode obiect. Aceasta proliferare a nsemnat o recunoastere a avantajelor orientarii obiect, dar totodata a evidentiat multitudinea de interpretari a ceea ce nseamna "obiect". Majoritatea metodelor se bazeaza nsa pe unele elemente comune, cum sunt notiunile de clasa, de asociere (introdusa de James Rumbough), de partitionare n subsisteme (Grady Booch), de exprimare a cerintelor plec nd de la studiul interactiunii utilizator - sistem ("use cases" introduse de Ivan Jacobson.)

Experienta n utilizarea acestor metode a facut posibila unificarea lor. In 1996, a fost creat un consortiu de parteneri pentru definirea unui limbaj de modelare orientata obiect, care sa integreze conceptele cele mai valoroase din metodele existente si totodata sa unifice notatiile; printre firmele care au contribuit la definirea limbajului UML sunt: DEC, HP, IBM, I-Logix, Intellicorp, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI si Unisys. UML versiunea 1.0, a fost supusa analizei n vederea standardizarii, n ianuarie 1997 . Au urmat apoi versiunile 1.1 (noiembrie 1997), 1.2 (iunie 1998) si ultima versiune, 1.3 (1999).

UML ( The Unified Modeling Language for Object-Oriented Development) este un limbaj de modelare obiect si nu o metoda obiect. UML este independent de procesul de dezvoltare folosit, dar in mod optim ar trebui sa fie folosit intr-un proces de dezvoltare iterativ si incremental, dirijat de cazuri de utilizare si centrat pe arhitectura. Un astfel de proces, numit Rational Unified Process, este descris in cartea celor trei principali autori ai limbajului (Jacobson, Booch si Rumbaugh, 1999).

UML este un limbaj pentru:

Vizualizare

Specificare

Construire

Documentare

UML este un limbaj grafic. Modelele UML usureaza comunicarea intre diversele categorii de persoane implicate in procesul de dezvoltare a unui sistem informatic. Comunicarea este ne-ambigua deoarece notatiile grafice au asociata o semantica bine definita.

UML permite specificarea sistemelor prin modele precise, ne-ambigue si complete la toate nivelele de detaliu: analiza, proiectare si implementare.

Modelele UML pot fi transpuse direct in limbaje de programare ca Java, C++, Visual Basic sau in tabele ale unei baze de date relationale. UML este de asemenea adecvat pentru "Inginerie inversa", adica generarea de modele pornind de la codul sursa.

Modelele UML pot fi folosite in documentele de analiza a cerintelor, de proiectare arhitecturala si de detaliu.

UML permite modelarea sistemelor din mai multe puncte de vedere si la diferite nivele de detaliu. Astfel, elementele de modelare definite in UML pot fi impartite in 3 categorii:

Modelare comportamentala

-Cazuri de utilizare

-Diagrame de cazuri de utilizare

-Diagrame de interactiune

-Diagrame de stari

-Diagrame de activitati

Modelare structurala

-Clase

-Diagrame de clase

-Diagrame de obiecte

-Interfete

-Pachete

Modelare arhitecturala

-Componente

-Diagrame de componente

-Diagrame de distributie

2.3.1. Cazuri de utilizare

Unul dintre aspectele importante in intelegerea si definirea cerintelor unui sistem este acela al interactiunii dintre sistem si utilizatori sau alte componente externe. Scenarii de interactiune tipica a unui sistem au fost folosite deseori in analiza cerintelor dar de regula in mod neformal si rareori documentate.

In UML modelel cazurilor de utilizare ("Use cases") a fost introdus de Jacobson in 1992. El a fost adoptat intr-o masura remarcabila, devenind un instrument folosit in mod frecvent in specificarea sistemelor informatice.

Modelul cazurilor de utilizare include actorii, sistemul, cazurile de utilizare si diagramele de cazuri de utilizare.

Un actor este un rol pe care o entitate externa il joaca in raport cu un sistem. Actorii se determina observand utilizatorii directi ai sistemului, cei care sunt responsabili de exploatarea sau de interogarea sa. Aceeasi persoana fizica poate juca rolul mai multor actori (de exemplu vanzator si client). Mai multe persoane pot sa joace acelasi rol, si deci sa actioneze ca acelasi actor. Un actor poate fi de asemenea un echipament extern sistemului sau un alt sistem.

Actorii se reprezinta sub forma unor mici personaje care declanseaza cazuri de utilizare. De exemplu:

Caz de utilizare

Determinarea actorilor permite precizarea limitelor sistemului ntr-o maniera progresiva: vagi la nceput, ele se precizeaza pe masura elaborarii diferitelor cazuri de utilizare. Aceasta activitate de delimitare este extrem de importanta. Ea permite stabilirea a ceea ce trebuie sa realizeze viitorul sistem, ceea ce face parte din sistemul de dezvoltat si ceea ce nu face parte din el.

Cazurile de utilizare sunt abstractii ale dialogului ntre actori si sistem. Ele descriu interactiuni potentiale fara a intra n detalii ale fiecarui scenariu.

Un scenariu este o secventa de pasi care descrie o posibila interactiune dintre un sistem si un actor.

Sa consideram un sistem de gestiune electronica a cartilor din mai multe biblioteci, de exemplu din intreaga tara. Sistemul urmeaza sa fie utilizat de doua categorii de utilizatori: bibliotecarii si abonatii. Bibliotecarii acceseaza sistemul pentru a inregistra abonati si carti noi sau pentru a elimina carti din evidenta. Abonatii pot cere informatii despre diferite carti si pot cere imprumutarea unei carti. Sistemul trebuie sa pastreze evidenta abonatilor, a cartilor imprumutate de fiecare abonat si alte informatii. Deoarece sistemul realizeaza o gestiune centralizata, pentru accesul sau se propune o interfata Web.

In acest exemplu, actorii sunt: abonatul si bibliotecarul. Cazurile de utilizare ar putea fi:

si altele.

Un posibil scenariu al cazului de utilizare "Imprumut" este urmatorul:

"Un utilizator isi introduce identitatea, apoi completeaza fisa electronica de imprumut pentru o carte si actioneaza butonul "Imprumut" din pagina Web. Sistemul cauta cartea si afiseaza utilizatorului datele necesare in legatura cu imprumutul".

Acesta este un scenariu posibil. Alte scenarii ale cazului de utilizare "Imprumut" pot fi acelea in care sistemul nu autorizeaza accesul utilizatorului sau refuza imprumutul pentru ca utilizatorul are deja imprumutate carti in numarul maxim admis, sau cartea nu a fost gasita.

Un caz de utilizare descrie un set de scenarii corelate, de exemplu, toate scenariile de acces la sistem in scopul imprumutului unei carti. Formatul descrierii consta dintr-o secventa tipica de pasi si alternativele, ca variante ale secventei tipice. Exemplu:

Cazul de utilizare :"Imprumut"

Un utilizator completeaza rubricile afectate numelui si prenumelui sau apoi apasa butonul "Submit".

Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.

Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.

Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele autorului si codul ISBN al cartii apoi apasa butonul "Submit".

Sistemul preia datele si cauta cartea.

Sistemul inregistreaza imprumutul.

Sistemul afiseaza datele necesare imprumutului.

Alternativa "Acces ne-autorizat":

La pasul 2: Utilizatorul nu este inregistrat ca abonat si atunci sesiunea este incheiata de sistem cu un mesaj in care utilizatorul este invitat sa se inregistreze.

Alternativa "Imprumutul nu este posibil"

La pasul 5:

5a) Cartea nu este gasita. Sistemul afiseaza un mesaj si sesiunea este incheiata.

5b) Cartea este gasita dar abonatul a imprumutat deja numarul admis de carti. Sistemul afiseaza un mesaj si incheie sesiunea.

UML admite variatii in privinta descrierii cazurilor de utilizare. De exemplu, o descriere mai exacta a cazului de utilizare anterior este:

Imprumut

Actori:	Abonat
Scop:	Imprumutul unei carti
Descriere generala:	Un abonat acceseaza pagina Web a sistemului de gestiune electronica a cartilor din bibliotecile existente in tara. El isi introduce identitatea si datele de identificare ale cartii pe care doreste sa o imprumute. Sistemul valideaza identitatea abonatului si cauta cartea. Daca cartea exista si abonatul are dreptul sa obtina un nou imprumut atunci sistemul autorizeaza imprumutul.
Pre-conditie:	Daca este necesar, abonatul tebuie sa execute mai intai procedura de acces la sistem (log-in).
Post-conditie:	In baza de date a sistemului exista o inregistrare a imprumutului catre abonat
Cazuri de utilizare referite:	Inregistrarea unui nou abonat

Un utilizator completeaza rubricile afectate numelui si prenumelui sau apoi apasa butonul "Submit".
Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si prenumele autorului si codul ISBN al cartii apoi apasa butonul "Submit".
Sistemul cauta cartea.

5a) Daca sistemul nu gaseste cartea, se executa alternativa "Cartea nu exista".

5b) Daca autorul are deja imprumutat numarul maxim de carti admis, se executa alternativa "Restrictia numarului de carti imprumutate".

Sistemul inregistreaza imprumutul.
Sistemul afiseaza utilizatorului datele necesare imprumutului.

Alternativa "Acces ne-autorizat"

Sistemul afiseaza un mesaj prin care invita utilizatorul sa se inregistreze ca abonat apoi incheie sesiunea.

Alternativa "Cartea nu exista"

1. Sistemul afiseaza mesajul "Cartea solicitata nu ese inregistrata in bibliotecile noastre", apoi incheie sesiunea.

Analog pentru alternativa 5b.

Pre-conditia este un predicat (in cazul de fata exprimat ne-formal) care exprima conditia care trebuie sa fie satisfacuta inainte de inceperea cazului de utilizare. Post-conditia exprima conditia care este satisfacuta dupa executia cazului de utilizare (conform descrierii secventei tipice!).

Un caz de utilizare este imaginea unei functionalitati a sistemului, declansata ca raspuns la stimularea unui actor.

Descrierea unui caz de utilizare trebuie sa precizeze:

cum si cand incepe si se termina cazul de utilizare - evenimente care marcheaza inceputul si sfarsitul cazului;

cand au loc interactiunile cu actorii si informatiile schimbate (comunicate intre actori - sistem) in timpul fiecarei interaciuni;

fluxul de baza (comportamentul de baza) si alternativele fiecarei interactiuni;

repetarile de comportament, care pot fi descrise prin formulari de tipul:

ciclu

sfarsit ciclu

cat timp

sfarsit cat timp

Cand se foloseste modelul cazurilor de utilizare?

Cazurile de utilizare definesc comportarea unui sistem fara a da informatii despre modul de realizare a comportarii. Se folosesc ca mijloc de vizualizare, specificare si documentare a unui sistem, subsistem parte sau element.

In fazele initiale ale dezvoltarii, cazurile de utilizare se folosesc ca mijloc de comunicare intre analist si client precum si experti ai domeniului, pentru determinarea contextului sistemului si pentru desprinderea cerintelor.

Pe parcursul dezvoltarii se folosesc pentru validarea arhitecturii sistemului. Se folosesc, de asemenea, in procesul de testare a sistemului executabil.

Modelul cazurilor de utilizare include un set de cazuri de utilizare si un set de diagrame de cazuri de utilizare.

Diagramele de cazuri de utilizare se foloses pentru a reprezenta relatiile intre cazurile de utilizare ce descriu un sistem. Exista trei tipuri de relatii intre cazurile de utilizare (figura 2.5):

Figura 2.5. Relatii intre cazuri de utilizare

Relatia de generalizare

Are acelasi rol ca si relatia de generalizare intre clase. Un caz de utilizare copil mosteneste comportarea si intelesul cazului de utilizare parinte: copilul poate adauga noi aspecte ale comportarii sau poate redefini partial comportarea parintelui.

Relatia de includere

Un caz de utilizare poate incorpora comportarea reprezentata printr-un alt caz de utilizare, intr-un punct specificat al sau. Cazurile de utilizare "incluse" nu pot fi folosite independent, ci doar ca parti ale cazurilor de utilizare care le includ.

Relatia de includere se foloseste pentru a evita descrierea de mai multe ori a aceluiasi flux de evenimente. Un astfel de flux, care apare in mai multe cazuri de utilizare, se defineste ca un caz de utilizare separat, care factorizeaza o comportare comuna.

Relatia de extindere

Un caz de utilizare poate extinde, in anumite conditii, comportarea reprezentata printr-un alt caz. Cazul extins poate fi folosit si singur. El este extins numai in anumite puncte. Relatia de extindere se foloseste:

pentru a modela parti ale cazurilor de utilizare pe care utilizatorii le pot vedea ca optiuni ale comportarii sistemului; in acest caz se separa comportamentul principal de cele optionale.

pentru a modela sub-fluxuri de evenimente, care sunt executate numai in anumite conditii.

Relatiile de includere si extindere favorizeaza structurarea cazurilor de utilizare prin factorizarea comportamentului comun si separarea variantelor.

O diagrama de cazuri de utilizare reda un set de cazuri de utilizare, actori si relatii. In diagramele de cazuri de utilizare, actorii se reprezinta sub forma unor mici personaje care declanseaza cazuri de utilizare.

Diagramele de cazuri de utilizare pot fi utile pentru a reprezenta contextul sau cerintele unui sistem. Contextul unui sistem cuprinde tot ceea ce este exterior sistemului si interactioneaza cu sistemul. El defineste mediul sistemului. O diagrama de caz de utilizare care modeleaza contextul evidentiaza actorii care interactioneaza cu sistemul. Un astfel de exemplu este redat in figura 2.6:

Figure 2.6. Diagrama de caz de utilizare

Cazurile de utilizare si diagramele de cazuri de utilizare pot reda comportamentul uni sistem la diferite nivele de abstractizare. Astfel, cazul de utilizare anterior poate fi detaliat pentru a reda participarea diferitelor componente ale sistemului in cazul de utilizare. O astfel de detaliere apare necesara in etapele de proiectare ale sistemului. In aceste modele actori pot fi: baze de date, programe, componente, etc.

2.3.2. Diagrame de interactiune

Cazurile de utilizare constituie o descriere functionala a cerintelor, structurata n raport cu unul sau mai multi actori. Trecerea catre o structurare obiect se realizeaza asociind o "colaborare" fiecarui scenariu. Colaborarea evidentiaza obiectele domeniului, conexiunile dintre aceste obiecte si mesajele schimbate de catre obiecte n cadrul scenariului. Scenariile, care au fost ntocmite la nceputul etapei de analiza, sunt reprezentate n continuare prin diagrame de interactiune: diagrame de colaborare si diagrame de secventa. Diagramele de colaborare redau relatiile structurale dintre obiecte si mesajele prin care ele comunica. Diagramele de secventa evidentiaza ordonarea in timp a mesajelor.

Diagramele de interactiune includ actori, obiecte sau componente implicate intr-o interactiune si redau mesajele schimbate in cursul interactiunii.

Obiecte

Un obiect este un concept, o abstractie sau un lucru av nd limite foarte clare si un sens precis n contextul problemei studiate. Fiecare obiect are o identitate si poate fi distins de celelalte.

In UML, un obiect se reprezinta sub forma unui dreptunghi contin nd numele obiectului si clasa din care face parte sau numai numele obiectului, subliniat(e). De exemplu:

Mihai : Persoana Mihai IBM: Calculator

Notatia permite de asemenea desemnarea de obiecte anonime, specificand numai numele clasei din care face parte. De exemplu:

:Student :Profesor

Comportamentul unui obiect, ca urmare a unei stimulari externe, este reprezentat prin operatii. Operatiile unui obiect sunt declansate prin mesaje trimise de alte obiecte.

Diagramele de secventa

Diagramele de secventa ilustreaza interactiunile dintre obiecte sau actori si obiecte din punct de vedere temporal. Un obiect este reprezentat printr-un dreptunghi si o bara verticala numita linia de viata a obiectului. Mesajele sunt reprezentate prin sageti orizontale orientate de la emitatorul mesajului catre destinatar. Ordinea de trimitere este data de pozitia pe axa verticala. Timpul se scurge de sus n jos. Axa verticala poate fi gradata n scopul exprimarii mai exacte a constr ngerilor temporale n cazul modelarii unui sistem de timp real.

Diagramele de secventa se construiesc plecand de la cazurile de utilizare. Ele se pot folosi n doua scopuri, care corespund la doua nivele diferite ale procesului de dezvoltare:

Ca mijloc de documentare a cazurilor de utilizare; interactiunea este descrisa n termeni apropiati utilizatorului si fara a intra n detalii de sincronizare. Sagetile corespund evenimentelor care survin n domeniul aplicatiei. De exemplu, diagrama din figura 2.7. reprezinta nceputul unei comunicatii telefonice.

:Apelant

:Linie telefonica

:Apelat

Deschide telefonul

Ton

Formeaza numar

Indicator de sonerie Suna

Deschide telefonul

Alo

Figura 2.7. Diagrama de secventa

Ca mijloc de reprezentare exacta a mesajelor schimbate ntre obiecte. Perioada de activitate a unui obiect este reprezentata cu ajutorul unei benzi rectangulare suprapuse pe linia de viata a obiectului.

In exemplul din figura 2.8, obiectul 1 apeleaza o operatie a obiectului 2. Obiectul 2 creaza obiectul 3 care exista pana cand este distrus tot de obiectul 2. Obiectul 3 apeleaza o operatie proprie.

:Obiect2

:Obiect1

:Obiect3

apel operatie Obiect2 <<creaza>>

return dupa exec. operatie

Figura 2.8.Apeluri de operatii, crearea si distrugerea obiectelor.

Sagetile folosite in figura 2.8 se folosesc pentru a reprezenta mesaje care corespund unui apel de proceda intr-un flux de executie cu un singur fir de executie. UML permite si reprezentarea de mesaje intre obiecte care sunt active in fire de executie diferite. Intre astfel de obiecte pot fi trimise mesaje sincrone sau asincrone.

Atunci cand un obiect trimite un mesaj sincron (fig. 2.9.b), el ramane in asteptare pana cand destinatarul trateaza mesajul. De aceea, revenirea dupa tratarea unui mesaj sincron nu este necesar sa fie reprezentata.

Un apel de procedura este un apel sincron. De aceea nici revenirea dupa executia unei proceduri nu este reprezentata intotdeauna.

Trimiterea asincrona (fig. 2.9.a) a unui mesaj nu ntrerupe executia expeditorului. Expeditorul trimite mesajul fara sa stie c nd, nici chiar daca mesajul va fi tratat de catre destinatar. In figura 2.9.a este redata si confirmarea destinatarului dupa tratarea mesajului.

:Ob1

:Ob2

Trimitere mesaj cu timeout = trimitere sincrona cu blocarea expeditorului pe un timp limitat (care poate fi specificat). Expeditorul asteapta ca destinatarul sa primeasca mesajul un timp limitat. Comunicatia nu are loc daca in intervalul de timp dat destinatarul nu ia in considerare mesajul.

Alegerea formei de sincronizare are loc de regula n etapa de proiectare, pentru a realiza de exemplu o excludere mutuala n utilizarea unei resurse critice. Forma de sincronizare poate fi importanta de asemenea n etapa de analiza. De exemplu, comunicatia prin posta corespunde unei trimiteri asincrone.

Diagramele de secventa redau modul de transfer al controlului intre obiecte (figurile 2.10 si 2.11.)

Figura 2.11. Control descentralizat

Pentru a indica bucle si salturi se pot adauga notatii de tip pseudocod pe partea st nga a diagramei (figuriel 2.12 si 2.13):

Diagramele de colaborare sunt n particular indicate pentru faza exploratorie, care corespunde cautarii obiectelor. Ele ilustreaza n acelasi timp interactiuni ntre obiecte si relatiile structurale care permit aceste interactiuni.

Relatiile structurale sunt reprezentate prin "legaturi" - linii care conecteaza obiectele. Mesajele schimbate ntre obiecte sunt reprezentate de-a lungul legaturilor. Ordinea de trimitere a diferitelor mesaje este indicata printr-un numar amplasat in fata mesajului, ca n figura 2.14.

Obiectele si legaturile create sau distruse n cursul unei interactiuni pot purta constr ngerile , respectiv . Obiectele care sunt create si distruse n cursul aceleiasi interactiuni sunt identificate prin constr ngerea .

"Scenariul incepe cu un obiect A care trimite un mesaj X unui obiect B. Acesta trimite un mesaj Y obiectului C care-si trimite un mesaj Z."

Pentru a indica trimiterea unui mesaj catre toate obiectele unei clase, existente la un moment dat, se foloseste notatia *:mesaj, ca n exemplul de mai jos:

In diagramele de colaborare pot fi introdusi actori, pentru a reprezenta declansarea interactiunilor de catre un element extern sistemului. Datorita acestui artificiu, interactiunea poate fi descrisa ntr-o maniera mai abstracta, fara a se intra n detaliile obiectelor de interfata utilizator. Primul mesaj de interactiune este trimis de actor. Un exemplu este prezentat in figura 2.17.

In figura 2.18 este reprezentata o posibila diagrama de colaborare, corespunzatoare unui scenariu al cazului de utilizare descris in paragraful 2.3.1. Scenariul corespunde secventei tipice de evenimente a cazului de utilizare, adica: utilizatorul este inregistrat ca abonat, el nu a imprumutat numarul maxim admis de carti, cartea este gasita si imprumutul inregistrat. Obiectele redate in diagrama sunt: "Fereastra-Abonati", in care utilizatorul completeaza datele necesare imprumutului, "Sistem"-reprezentand modulul central al sistemului, "Fisierul de abonati", "Fisele abonatilor", "Fisierul de carti", "Fisele cartilor" si "Fereastra-mesaj" in care sistemul afiseaza datele necesare imprumutului.

Echivalenta diagrame de interactiune - diagrame de colaborare

Ambele categorii de diagrame reprezinta vederi diferite asupra aceleiasi informatii. In cazul diagramelor de secventa accentul este pus pe secventialitatea mesajelor. In cazul diagramelor de colaborare accentul cade pe colaborarile dintre obiecte. Formele grafice utilizate in cadrul fiecarei categorii de diagrame accentueaza aceste aspecte.

Numeroase editoare UML permit conversia automata de la o diagrama de secventa la cea de colaborare corespunzatoare sau invers.

O clasa de obiecte reprezinta un grup de obiecte care au proprietati similare (atribute), un comportament comun (operatii), relatii comune cu alte obiecte si o aceeasi semantica. De exemplu, "Persoana", "Societate", "proces" sunt clase de obiecte. Semantica asociata unei clase corespunde unui punct de vedere. Obiectele din lumea reala pot fi abstractizate n mod diferit. De exemplu, un cal poate fi ncadrat n clasa mijloacelor de transport terestre sau n clasa animalelor.

In UML, o clasa este reprezentata printr-un dreptunghi alcatuit din trei compartimente care contin: numele clasei, atributele, operatiile. Compartimentul atributelor si cel al operatiilor pot fi omise.

Relatiile dintre clase sunt abstractii ale relatiilor existente între obiecte. Fiecarei familii de legaturi între obiecte îi corespunde o relatie între clasele obiectelor. Asa cum obiectele sunt instante ale claselor, legaturile între obiecte sunt instante ale relatiilor dintre clase.

Diagramele de clase redau structura statica a unui sistem. Exista doua tipuri principale de relatii intre clase: asociere si generalizare.

Asocierea este o conexiune semantica bidirectionala între clase. De exemplu, asocierea "Lucreaza pentru" dintre clasele Persoana si Societate reprezinta toate legaturile posibile dintre obiecte ale clasei Persoana si obiecte ale clasei Societate:

Sageata atasata numelui asocierii nu este obligatorie. Ea indica sensul citirii numelui asocierii.

Extremitatea unei asocieri este numita rol. Rolul exprima felul în care o clasa "vede" o alta clasa în cadrul unei asocieri. De exemplu, în asocierea dintre clasele Societate si Persoana, orice obiect al clasei Persoana este un "Angajat" al unei Societati, care este reprezentata printr-un "Patron" . Numele de rol sunt amplasate la cele doua extremitati ale asocierii:

Daca între doua clase exista o singura asociere, numele asocierii este suficient pentru a preciza relatia. Numele de rol se folosesc de regula atunci c nd ntre doua clase exista mai multe asocieri.

Cea mai mare parte a asocierilor sunt binare - ele unesc doua clase. Asocierile de aritate superioara se reprezinta cu ajutorul unui romb, ca în figura de mai jos. De exemplu, asocierea ilustrata în figura 3.15. exprima faptul ca "Proiectele sunt implementate prin Programe scrise n Limbaje de programare".

Fiecare rol al unei asocieri poate purta o indicatie de multiplicitate care arata c te obiecte ale unei clase pot fi legate unui obiect al celeilalte clase. De exemplu, o societate poate avea zero sau mai multi angajati. Multiplicitatea poate fi "unu", "mai multe "(*) sau un subansamblu de întregi pozitivi: 1, 0..1, M..N, * sau 0..* (de la zero la mai multi), 1..*.

Multiplicitatea unei asocieri exprima o constr ngere valabila pe toata durata de existenta a obiectelor claselor asociate. Multiplicitatile nu trebuie sa fie considerate n timpul regimurilor tranzitorii, de creare sau de distrugere a obiectelor.

Asocierile pot fi caracterizate prin atribute. In figura 2.23, "Nota" este un atribut al asocierii existente între clasa "Student" si clasa "Tema".
Asocierea dintre clasa Student si clasa Tema este de tip N la N. Fiecare student realizeaza individual o tema data iar nota obtinuta nu poate fi reprezentata nici ca atribut al studentului (caci un student efectueaza mai multe teme), nici ca atribut al temei (caci fiecare student primeste o nota pentru aceeasi tema). Nota este un atribut al relatiei dintre clasa studentilor si clasa temelor.

O asociere care contine atribute este numita asociere atributata. O asociere poate fi reprezentata printr-o clasa cu atribute si operatii proprii. O asemenea clasa, numita uneori clasa-associere, este atasata asocierii printr-o linie punctata (figura 2.24).

Asocierile pot fi constr nse. Constr ngerile sunt scrise ntre acolade. De exemplu, instantele clasei B asociate unei instante a clasei A trebuie sa fie ordonate:

O asociere poate lega o clasa de ea însasi. O asemenea asociere este numita asociere reflexiva. Un exemplu de asociere reflexiva este cel ilustrat n figura 2.26. Fiecare persoana are zero, unu sau doi parinti si zero sau mai multi copii. Numirea rolurilor este în acest caz esentiala pentru claritatea diagramei.

Asocierile 1 la mai multi si mai multi la mai multi pot fi calificate. Calificarea este specificata printr-o cheie atasata rolului clasei de plecare.

Fiecare instanta a clasei A mpreuna cu valoarea cheii identifica un sub-ansamblu al instantelor clasei B, care participa la asociere. Exemplu:

In contextul unui director, un nume de fisier identifica un fisier. Un director împreuna cu un nume de fisier desemneaza un fisier.

Agregarea este o forma particulara de asociere care exprima un cuplaj mai str ns între clase. Una dintre clase joaca un rol mai important decât cealalta în relatie. Agregarea permite reprezentarea relatiilor de tip "master-slave", "client-server" si "compus - componenti". Agregarea este desemnata printr-un un mic romb amplasat alaturi de clasa agregat (figura 2.29):

Un document are mai multe paragrafe si fiecare paragraf este alcatuit din mai multe fraze. In cazul în care multiplicitatea agragatului are valoarea 1, distrugerea agregatului antreneaza distrugerea componentelor.

Fiecare masina poseda un motor care nu poate fi partajat cu alte masini. Distrugerea masinii antreneaza distrugerea motorului.

O agregare nereflexiva a carei valoare de multiplicitate este 0 sau 1 de partea agregatului se poate realiza prin continere fizica.

Continerea fizica este un caz particular de agregare, numit compunere. Relatia de compunere este semantic echivalenta cu considerarea componentilor ca atribute ale clasei agregat:

- o actiune asupra obiectelor unei clase implica o actiune asupra obiectelor unei alte clase;

Ierarhiile de clase sunt bazate pe notiunile de clasificare, generalizare si specializare. Generalizarea consta în factorizarea elementelor comune (atribute, operatii si constr ngeri) ale unui ansamblu de clase într-o clasa mai generala, numita superclasa. Clasele sunt ordonate într-o ierarhie. Sageata care simbolizeaza generalizarea între doua clase puncteaza catre clasa mai generala.

In ierarhia din figura de mai sus, fiecare clasa (exceptând clasa radacina) are o singura super-clasa. Reprezentarea grafica corespunde unui arbore, numit si arborele de mostenire. Clasele pot avea mai multe super-clase. In acest caz, generalizarea este numita multipla iar ierarhia de clase se reprezinta printr-un graf , numit si graful de mostenire.

Specializarea permite capturarea particularitatilor unui ansamblu de obiecte, nereprezentate prin clasele existente. Noile caracteristici sunt definite într-o clasa noua, sub-clasa a uneia sau mai multor clase existente. Specializarea este o tehnica foarte eficienta de extensie coerenta a unui ansamblu de clase existente. Noile cerinte sunt încapsulate în sub-clase care extind functiile existente. De exemplu, daca ntr-o aplicatie apare necesar sa se reprezinte "bicicleta" ca vehicul de transport, n plus fata de cele reprezentate n ierarhia de mai sus, atunci se va defini o clasa noua, sub-clasa a clasei "Vehicul terestru", n care vor fi definite particularitatile bicicletei ca vehicul terestru. Fiecare sub-clasa a unei ierarhii mosteneste atributele si operatiile definite în clasele aflate pe calea de la clasa radacina la subclasa respectiva, fiind cu atât mai specializata cu cât se afla mai departe de radacina.

Mostenirea este o tehnica oferita de limbajele de programare pentru a construi o clasa plec nd de la una sau mai multe clase, partaj nd atribute, operatii si uneori constrangeri în interiorul unei ierarhii de clase. Clasele copil mostenesc caracteristicile claselor parinte. Atributele si operatiile declarate în clasele parinte sunt accesibile în clasele copil, ca si cum ar fi declarate local. Mostenirea este o modalitate de a realiza clasificarea. Relatia de generalizare definita n UML este mai abstracta decât relatia de mostenire care exista în limbajele de programare obiect, cum ar fi C++. Ea este mai adecvata etapei de analiza Decizia asupra modalitatii de a realiza generalizarea se ia mai târziu, în etapa de proiectare.

Prin clasificare si generalizare, universul problemei este divizat in parti independente care grupeaza obiectele prin afinitate. Modificarea unei parti antreneaza un minimum de modificari ale celorlalte, fapt pus în evidenta de arborele de mostenire: fiecare subarbore grupeaza obiectele care împart caracteristicile radacinii sale. De exemplu, adaugarea de noi caracteristici la clasa Articol-de-lux (figura )nu afecteaza clasa îmbracaminte si nici subclasele acesteia, dar extinde automat caracteristicile subclaselor clasei Articol-de-lux.

Uneori, anumite clase sunt create doar ca surse de mostenire pentru alte clase; ele sunt clase abstracte. De exemplu, clasa Articol este o clasa abstracta daca nu caracterizeaza complet

nici un obiect din universul problemei. Clasa Articole-electrice a fost introdusa pentru a factoriza proprietatile electrice (de exemplu, tensiunea de alimentare, consumul si altele), comune calculatorului si articolelor electrocasnice.

Nu exista neaparat o legatura directa cu clasele de obiecte utilizate pentru implementare

adesea se foloseste cuvantul "tip" in legatura cu interfata unei clase: un tip poate fi implementat de mai multe clase si o clasa poate implementa mai multe tipuri

O diagrama de obiecte reda un set de obiecte si relatiile dintre ele la un moment dat de timp.

O diagrama de obiecte este o instanta a unei diagrame de clase sau partea statica a unei diagrame de interactiune.

O diagrama de interactiune adauga la o diagrama de obiecte mesajele care sunt schimbate intre obiecte.

O diagrama de stari-tranzitii descrie comportamentul obiectelor unei clase prin stari si evenimente. Obiectele care nu au un comportament reactiv foarte marcat pot fi considerate ca obiecte care ram n ntotdeauna n aceeasi stare. O diagrama stari-tranzitii corespunde unui automat cu stari finite.

Specificarea completa a unui eveniment n UML contine: numele evenimentului, lista parametrilor, obiectul expeditor, obiectul destinatar, descrierea semnificatiei evenimentului.

Fiecare obiect este la un moment dat ntr-o stare particulara. Starea este definita de valorile atributelor sale si de legaturile sale. De exemplu, starea curenta a unei persoane poate fi: n activitate, n somaj sau la pensie. Este determinata de v rsta persoanei si de prezenta unei legaturi catre o societate:

Diagramele stari-tranzitii sunt grafuri orientate. Starile sunt legate prin conexiuni bidirectionale numite tranzitii. Trecerea dintr-o stare n alta se efectueaza n cazul n care o tranzitie este declansata de catre un eveniment. Trecerea dintr-o stare n alta este instantanee, deoarece sistemul trebuie sa fie ntotdeauna ntr-o stare cunoscuta. Un eveniment poate determina o tranzitie n aceeasi stare. Starile se reprezinta prin dreptunghiuri rotunjite. Fiecarei stari i este asociat un nume care o identifica. Exemplu:

In unele cazuri, diagramele de stari tranzitii pot deveni foarte complicate. Problema poate fi rezolvata recurg nd la abstractizare. Astfel, mai multe stari pot fi abstractizate ntr-o singura stare, care corespunde unei reprezentari de nivel ierarhic mai nalt, dupa cum o stare poate fi descompusa n sub-stari disjuncte. De exemplu, starile A si B din diagrama ilustrata n figura 3.29, pot fi abstractizate ntr-o stare mai generala deoarece din ambele exista o tranzitie n starea C:

Automatele acceptate de UML sunt deterministe. Pentru fiecare nivel de abstractizare exista o singura stare initiala. Este posibil sa existe mai multe stari finale, fiecare corespunz nd unei conditii de sf rsit diferite. De asemenea, este posibil sa nu existe nici o stare finala. Este cazul unui sistem care nu se opreste niciodata. Reprezentarile starilor initiala si finala sunt ilustrate astfel:

Tranzitiile pot fi controlate prin garzi. O garda este o conditie booleana care valideaza declansarea unei tranzitii n cazul aparitiei unui eveniment.

In cazul n care mai multe tranzitii pot fi declansate de acelasi eveniment si evenimentul are loc, garzile, care trebuie sa fie mutual exclusive, sunt evaluate, si apoi o singura tranzitie este validata si declansata.

Operatiile definite n specificatia unei clase apar n diagramele stari-tranzitii ca actiuni si activitati. O actiune este considerata ca instantanee, adica are un timp de executie neglijabil n raport cu dinamica sistemului. In diagramele de stari-tranzitii, actiunile sunt atasate evenimentelor:

Actiunea corespunde unei operatii declarate n clasa obiectului destinatar al evenimentului. Ea este executata atunci c nd evenimentul este receptionat si determina trecerea obiectului din starea X n starea Y.

O activitate este o operatie care necesita un anumit timp de executie. Ea este asociata unei stari. Anumite activitati sunt ciclice, ca afisarea unei imagini pe un ecran de televizor sau ca soneria telefonului care persista p na c nd un eveniment o ntrerupe declans nd o tranzitie. Alte activitati sunt secventiale, ca de exemplu executia unui calcul. Activitatile sunt indicate prin cuvantul cheie "do":

O activitate poate fi ntrerupta n orice moment, imediat ce este declansata o tranzitie de iesire din starea corespunzatoare activitatii.

Anumite actiuni se executa nainte sau dupa o activitate. Actiunile de intrare/iesire sunt specificate n interiorul starii ce contine activitatea. Ele sunt indicate de cuvintele cheie "entry" si "exit". Pot exista de asemenea actiuni interne. O asemenea actiune este executata la nt lnirea unui eveniment care nu schimba starea curenta (figura 3.33). In cazul n care o activitate secventiala se termina, starea poate fi parasita automat. O asemenea tranzitie, care nu este marcata printr-un eveniment, este numita tranzitie automata. Tranzitia la sf rsitul unei activitati secventiale poate fi de asemenea controlata prin garzi (fig. 3.34.).

Fiecare diagrama de stari-tranzitii descrie comportamentul unui grup de obiecte (cel mai adesea o clasa). Notatia UML permite reprezentarea trimiterii de mesaje ntre doua obiecte ca trimiteri de evenimente ntre automatele de stari ale claselor obiectelor. O trimitere de eveniment catre o clasa este reprezentata sub forma:

De exemplu, evenimentul "buton apasat", adresat obiectului "telecomanda", are ca efect trimiterea evenimentului "comutat" catre un obiect "televizor", ceea ce se reprezinta n diagrama stari-tranzitii a clasei "telecomanda" astfel:

Crearea unui obiect se reprezinta prin trimiterea unui eveniment de creare clasei obiectului. Parametrii acestui eveniment permit initializarea noului obiect care si ncepe existenta plec nd din starea initiala descrisa n automatul clasei. Distrugerea unui obiect este efectiva atunci c nd fluxul de control al automatului ajunge ntr-o stare finala.

Fiecare operatie a unei clase, care reprezinta o activitate, poate fi descrisa n scopul analizei printr-o diagrama numita diagrama de activitate. Activitatea este descompusa n mai multe etape, fiecare etapa put nd fi tratata la r ndul sau ca o activitate. Fiecare operatie-activitate este deci descrisa ca o nlantuire de activitati. Atunci c nd o activitate se termina, activitatea urmatoare demareaza automat. Activitatile nu poseda nici tranzitii interne, nici tranzitii declansate de catre evenimente. De exemplu, o operatie de transformare a unui obiect tridimensional poate fi descrisa de diagrama:

Tranzitiile ntre activitati pot fi controlate prin conditii booleene mutual exclusive. Sincronizarea ntre fluxurile controlului este reprezentata prin barele de sincronizare, ca n figura 3.38. O bara de sincronizare permite deschiderea sau nchiderea ramurilor paralele ale fluxului de executie n cadrul unei metode sau al unui caz de utilizare.

Modelul de analiza corespunde unui punct de vedere logic asupra sistemului. Acest model reflecta cerintele utilizatorilor dar, n acelasi timp, permite identificarea diferitelor parti ale sistemului. Vederea logica cuprinde ca elemente de modelare: obiectele, clasele, colaborarile si interactiunile.

Sistemul trebuie sa tina evidenta cartilor care apartin unei biblioteci si a abonatilor. Bibliotecarul va putea cere sistemului:

Fiecare abonat va trebui sa se identifice prin numele si prenumele sau. Numarul cartilor mprumutate simultan unui abonat va fi limitat.

Sistemul va fi utilizat de doua categorii de utilizatori: bibliotecarii si abonatii. Cerintele functionale pot fi deci partajate n doua categorii: cerintele bibliotecarior si cerintele abonatilor. Numarul cerintelor fiecarei categorii fiind redus, putem considera numai doua cazuri de utilizare:

Cazul de utilizare este declansat de bibliotecar, atunci c nd cere sistemului sa actualizeze fisierul cartilor sau fisierul abonatilor. Bibliotecarul se adreseaza sistemului selection nd un articol specific al meniului aplicatiei.

Bibliotecarul introduce titlul cartii, numele autorului si un cod de identificare al cartii. Sistemul verifica daca codul nu este deja alocat unei alte carti si daca cartea nu este deja nregistrata.

Cazul de utilizare se termina prin afisarea unui mesaj care indica bibliotecarului fie ca a furnizat un cod care este deja asignat unei alte carti fie ca a specificat o carte care este deja nregistrata, fie ca operatia s-a sf rsit cu succes (cartea a fost nregistrata n urma dialogului curent). Cazul de utilizare este ilustrat prin scenariile 1 si 2.

Bibliotecarul introduce codul cartii. Sistemul cauta cartea utiliz nd codul. Daca gaseste cartea, atunci o sterge din fisierul de carti. Cazul de utilizare se termina c nd sistemul afiseaza un mesaj indic nd sau codul este eronat (nu este nici o carte nregistrata av nd codul introdus) sau cartea a fost stersa. Cazul de utilizare este ilustrat prin scenariul 3.

Bibliotecarul introduce numele si prenumele unei persoane. Sistemul cauta persoana n fisierul de abonati. Daca persoana nu este gasita, atunci sistemul adauga persoana n fisierul de abonati. Cazul de utilizare se termina prin afisarea unui mesaj indic nd fie ca persoana este deja nregistrata fie ca sistemul a nregistrat noua persoana.

Bibliotecarul introduce numele si prenumele unui abonat care trebuie sa fie eliminat din lista de abonati. Sistemul cauta abonatul n fisierul de abonati. Daca-l gaseste, atunci l sterge din fisier. Cazul de utilizare se termina cand sistemul afiseaza un mesaj indic nd sau ca persoana al carei nume si prenume au fost introduse nu este nregistrata n fisierul de abonati sau ca abonatul a fost eliminat din fisier.

Cazul de utilizare este declansat de o persoana cand ea se adreseaza sistemului pentru a imprumuta sau pentru a inapoia o carte. Persoana se adreseaza sistemuluis selectionand un articol specific al meniului aplicatiei.

Persona selectioneaza articolul "Imprumuta" al meniului aplicatiei. Sistemul invita persoana sa-si introduca numele si prenumele. Sitemul verifica daca persoana este un abonat al bibliotecii. Daca persoana nu este un abonat, atunci sitemul afiseaza un mesaj explicativ si cazul de utilizare se termina. Daca persoana este un abonat, atunci sistemul verifica daca numarul cartilor deja imprumutate de abonat este mai mic ca numarul maxim admis. Daca nu, sistemul afiseaza un mesaj explicativ si cazul de utilizare se termina. Daca imprumutul este posibil atunci sistemul invita persoana sa introduca titlul cartii si numele autorului.

Persoana alege articolul "restituire" al meniului aplicatie. Sistemul il invita sa-si introduca numele si prenumele. Sistemul cauta persoana in fisierul de abonati. Daca persoana nu este abonata, sistemul afiseaza un mesaj si cazul de utilizare se termina. Daca persoana este abonata, atunci sistemul invita persoana sa introduca titlul cartii si autorul.

Sistemul trebuie sa fie protejat fata de utilizatorii care nu sunt bibliotecari, dar care utilizeaza functiile de gestiune ale bibliotecii. O modalitate de asigurae a acestei protectii este de a permite accesul la functiile de gestiune numai intr-o stare speciala a sistemului.

Starea initiala a sistemului va permite numai functii de exploatare si de asemenea trecerea intr-o stare de login bibliotecarea. Tranzitia din aceasta stare in starea de gestiune va avea loc cand utilizatorul intropduce o parola cunoscuta sistemului. Comportamentul global al sistemului va corespunde deci diagramei de stari tranzitii urmatoare:

Diagrama de clase

In cursul analizei se determina "ceea ce trebuie facut", independent de modul de realizare. In etapa de proiectare trebuie sa se decida asupra modului de rezolvare a problemei, mai nt i la un nivel general, apoi la nivele de detaliu din ce n ce mai fine.

Se ncepe cu proiectarea de sistem, n cursul careia se decide arhitectura sistemului, adica organizarea sistemului n componente numite sub-sisteme. Principalele decizii care trebuie sa se ia n etapa de proiectare de sistem sunt:

Un sub-sistem este n general definit prin serviciile pe care le ofera. Un "serviciu" este un grup de functii corelate, care au acelasi scop: de exemplu, sub-sistemul de fisiere al unui sistem de operare, sub-sistemul care realizeaza interfata cu utilizatorul a unui sistem, etc.

Fiecare sub-sistem trebuie sa aiba o interfata bine definita cu restul sistemului. Interfata specifica interactiunile si fluxul de informatii ntre sub-sisteme si restul sistemului. Fiecare sub-sistem trebuie sa fie conceput astfel nc t majoritatea interactiunilor dintre componente sa fie n interiorul sub-sistemelor si nu ntre sub-sisteme. In acest fel, fiecare sub-sistem poate fi realizat independent de celelalte. El poate fi descompus la r ndul sau n parti mai simple, numite module.

Fiecare sub-sistem se reprezinta printr-un pachet. Un pachet se reprezinta ca n figura de mai jos:

Un pachet poate contine alte pachete. Arhitectura sistemului este definita prin ierarhia de pachete si prin relatiile dintre pachete. Importurile ntre pachete se reprezinta n diagramele de clase si n diagramele de componente.

Anumite pachete sunt utilizate de toate celelalte pachete. Astfel sunt pachetele care grupeaza clasele de baza: lista, multimea, fisierul si altele. Pentru simplificarea reprezentarii grafice, astfel de pachete se declara ca pachete globale. Nu este necesar sa se reprezinte grafic dependentele dintre aceste pachete si utilizatorii lor.

Repartitia sub-sistemelor pe echipamente este reprezentata n diagramele de realizare. Ele ilustreaza configuratia de echipamente a sistemului si repartitia programelor executabile pe aceste echipamente. Nodurile diagramei sunt conectate prin linii care simbolizeaza un suport de comunicare bidirectional. Exemplu:

Sistemul ilustrat n figura 3.49. cuprinde: un server, 3 terminale X, mai multe PC-statii pilot si o imprimanta.

Un sistem poate fi descompus ntr-o secventa de straturi orizontale sau n partitii verticale. Fiecare strat reprezinta un nivel de abstractie. Este implementat folosind serviciile stratului de dedesubt si furnizeaza servicii folosite de nivelul de deasupra. Sunt doua tipuri de arhitecturi n straturi: deschise si nchise. Intr-o arhitectura nchisa fiecare strat foloseste numai serviciile oferite de stratul de sub el. Aceasta limiteaza dependentele ntre straturi si faciliteaza modificarile. Intr-o arhitectura deschisa, un strat poate utiliza functiile realizate de oricare dintre straturile precedente (inferioare). Aceasta limiteaza necesitatile de redefinire a operatiilor la fiecare nivel si conduce astfel la un cod mai eficient. Un aspect negativ al arhitecturii deschise este ca nu respecta principiul mascarii (ascunderii) datelor. Orice schimbare a unui nivel poate afecta toate straturile superioare, deci o arhitectura deschisa este mai putin robusta dec t una nchisa.

In descrierea unei probleme sunt mentionate n general numai primul si ultimul strat; primul ( cel mai nalt) reprezinta sistemul iar ultimul resursele disponibile (echipamente, sistemul de operare, biblioteci existente). In practica se introduce un strat care abstractizeaza primul nivel, adica echipamentele si serviciile oferite de sistemul de operare. Prin aceasta se asigura portabilitatea sistemului pe alte platforme hardware-software.

Partitiile verticale divizeaza un sistem n mai multe sub-sisteme independente sau putin legate, fiecare furniz nd un pachet de servicii proprii. De exemplu, partitiile unui sistem de operare pot contine: sistemul de fisiere, gestiunea procesorului, gestiunea memoriei, gestiunea echipamentelor periferice.

Cele doua tipuri de descompuneri pot fi combinate, adica, un strat poate fi divizat n partitii verticale.

Obiectele identificate n analiza servesc de schelet pentru viitorul sistem. Proiectantul trebuie sa aleaga ntre diferite variante de a le implementa tin nd cont de criterii de performanta si alte criterii ca: reutilizarea, mostenirea, tratarea erorilor, gestiunea memoriei dinamice. In plus, operatiile identificate n analiza trebuie sa fie exprimate prin algoritmi, operatiile complexe descompuse n operatii interne mai simple, atributele si asocierile implementate prin structuri de date.

Principalele activitati efectuate n timpul proiectarii obiectelor sunt urmatoarele:

In proiectarea obiectelor se pleaca de la modelul structural (static) rezultat din analiza, care este reprezentat prin diagramele de clase. Proiectantul trebuie sa converteasca actiunile si activitatile specificate n diagramele de comportament (diagramele de colaborare, de secventa, de stari-tranzitii si de activitati) n operatii asociate claselor. In acest fel se ncepe procesul de reprezentare a modelului de analiza ntr-o structura fizica de program.

Fiecare operatie trebuie sa fie exprimata printr-un algoritm. In alegerea algoritmilor proiectantul trebuie sa tina cont de criterii ca: complexitatea calculelor, usurinta implementarii si a ntelegerii, usurinta modificarilor ulterioare.

Pe parcursul dezvoltarii algoritmilor pot sa apara necesare noi clase. Acestea sunt clase de nivel cobor t, pe baza carora sunt implementate clasele aplicatiei. Ele pot fi clase existente sau clase concepute n aceasta etapa. Astfel de clase pot fi clase utilitare. Ele grupeaza functii (de exemplu, ale unei biblioteci matematice) dar nu reprezinta obiecte. In diagramele UML clasele utilitare sunt desemnate prin stereotipul <<Utilitar>>. Se poate utiliza de asemenea, reprezentarea grafica echivalenta - un dreptunghi cu o bordura grizata:

Mascarea (ascunderea) informatiilor

Una dintre sarcinile importante ale proiectarii este de a defini cu grija interfata fiecarei clase. Interfata constituie partea publica a clasei; numai informatiile cuprinse n aceasta parte pot fi folosite n implementarea altor clase. Detaliile de implementare sunt amplasate n partea privata a clasei. Ele nu sunt accesibile altor clase. Partea privata contine n general datele prin care sunt reprezentate obiectele si legaturile dintre ele. Ascunderea informatiei interne ofera mai multe avantaje:

- contribuie la obtinerea unui program cu o buna adaptabilitate, deoarece orice modificare a structurii obiectelor sau a implementarii metodelor nu afecteaza comunicatia obiectelor din alte clase cu obiectele clasei.

Regulile de vizibilitate permit completarea sau particularizarea mascarii. Cele trei nivele de mascare definite în UML corespund celor existente în limbajul C++: privat, protejat si public. Nivelul de vizibilitate al fiecarui atribut sau operatie poate fi precizat în reprezentarile grafice ale claselor cu ajutorul caracterelor +, #, - .

In timpul fazei de analiza si de proiectare de sistem elementele de modelare au fost repartizate n module si pachete. Este posibil ca aceasta organizare initiala sa nu fie optima. Clasele adaugate n timpul proiectarii fie ca se adauga la pachetele si straturile existente fie ca se organizeaza n pachete si straturi separate.

Un pachet nu este numai o grupare logica de elemente ci si o ncapsulare a lor. Fiecare element continut ntr-un pachet poseda un parametru care indica daca elementul este vizibil sau nu din exteriorul pachetului. Valorile parametrului sunt: "public" sau "implementare". Numai clasele indicate ca publice pot fi referite de clasele membre ale pachetelor client. Pachetele trebuie sa aiba interfete minimale si bine documentate. Interfata dintre doua pachete este compusa din asocierile care leaga clasele unui pachet de clasele celuilalt pachet si din operatiile utilizate n schimbul de mesaje ntre obiecte apartin nd claselor din pachetele respective.

Aceste diagrame descriu elementele fizice si relatiile lor n mediul de realizare. Notiunea de modul, n UML, este foarte geneala. Modulele pot fi fisiere, biblioteci si altele.

Fiecare clasa este realizata prin doua componente: specificatia si corpul (implementarea). Specificatia poate fi generica. In C++ specificatia corespunde unui fisier .h iar corpul unui fisier .cpp. Scopul principal al acestor diagrame este de a reprezenta relatiile stabilite ntre diferite componente. O sageata indica faptul ca o componenta utilizeaza serviciile oferite de o alta componenta. Sageata indica furnizorul.