Esti aici: Qreferat » Documente informatica

Modelarea sistemelor informatice

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 in 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, inlantuirea 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.

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.

Metode functionale

Aceste metode isi au originile in dezvoltarea limbajelor procedurale. Mai orientate catre prelucrari decat 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, in 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 plecand 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. Figura urmatoare ilustreaza tratarea propunerilor facute unei intreprinderi de catre societati de servicii[ ]. Prelucrarile sunt reprezentate prin elipse iar rezervoarele prin dreptunghiuri.

Diagrama de flux de date

Plecand de la diagrama de cel mai inalt nivel, prelucrarile complexe sunt descompuse recursiv in subdiagrame pana la prelucrari simple, usor de implementat. Prelucrarile simple sunt specificate in 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.

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 urmatoare pune in 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 intr-o maniera unica proiectul, un nume de proiect, un nume de responsabil si o data limita.

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 in 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. 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.

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:

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 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 in 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.

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 punandu-se in 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 in 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 in 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, distingand 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, in particular, celebra in Europa. JSD nu face distinctie intre analiza si proiectare, cele doua faze find grupate ca activitate de specificare. JSD divizeaza dezvoltarea sistemelor in doua etape: specificarea si apoi implementarea. Metoda este conceputa in special pentru aplicatii in care este important elementul timp. Ea utilizeaza modele grafice ca cele din SA/SD, OMT si alte tehnici.

Un model JSD descrie lumea reala in 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 in lumea reala. Ele au loc la momente de timp date, sunt atomice si nedecompozabile. Etapa de structurare a entitatilor ordoneaza partial actiunile fiecarei entitati in timp. Etapa de modelare initiala face legatura intre lumea reala si modelul abstract. Etapa functie utilizeaza pseudocod pentru descrierea actiunilor. La sfarsitul acestei etape, se dispune de o specificatie completa a sistemului cerut.

Etapa de analiza a aspectelor temporale ale sistemului examineaza modul in care modelul se poate decupla de lumea reala. Rezultatul acestei etape este un ansamblu de note informale asupra constrangerilor 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 in modelul obiect;

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

redate in modelul dinamic;

- aspectele functionale si de transformare de date, reprezentate in

modelul functional.

Cele trei modele decupeaza sistemul in vederi ortogonale care pot fi reprezentate cu o notatie uniforma. Interconexiunile intre 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 in 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 in etapa de proiectare descrie modul concret de realizare a sistemului; el poate sa contina obiecte (constructii) informatice.

Modelul dinamic descrie sistemul in 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 in modelul functional. Evenimentele corespund mesajelor (apeluri ale operatiilor), schimbate intre obiectele modelului.

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

Comparatie intre metodele functionale si metodele orientate obiect

Metodele functionale (de exemplu SA/SD) si metodele orientate obiect (de exemplu OMT) au multe in 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 sfarsit modelul functional.

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

O conceptie obiect este mai extensibila decat 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 inteles, corespondenta dintre specificatie si cod fiind simplificata.

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

UML - Unified Modelling Language

Necesitatea solutiilor de modelare a crescut odata cu cresterea numarului si a complexitatii sistemelor software. Ca urmare, au fost definite tot mai multe metodologii de dezvoltare.

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

Experienta in utilizarea acestor metode a facut posibila unificarea lor.

Prima versiune UML a fost publicata in 1996. Ea a fost rezultatul colaborarii intre cei trei lideri recunoscuti in domeniul metodologiilor orientate obiect: Booch, Rumbaugh, and Jacobson.

Necesitatea standardizarii in modelarea sistemelor informatice a devenit din ce in ce mai recunoscuta iar UML a fost adoptat imediat de mai multe firme. Ca urmare, OMG (Object Management Group) a publicat o cerere de propuneri (RFP - Request for Proposals) iar Rational Software Corporation a creat un consortiu de parteneri pentru definirea UML ca 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 in vederea standardizarii, in ianuarie 1997 . Au urmat apoi versiunile 1.1 (noiembrie 1997), 1.2 (iunie 1998), 1.3 (1999), 1.4 (2002) si ultima, 2.0 (octombrie 2004).

Scopurile limbajului UML

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.

UML este un limbaj pentru:

Vizualizare si comunicare

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.

Specificare si construire:

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.

Documentare

Modelele UML pot fi folosite:

In documentele de specificare a cerintelor utilizatorilor si a cerintelor software,

in documentele de proiectare arhitecturala si de detaliu.

UML permite modelarea sistemelor din mai multe puncte de vedere si la diferite nivele de detaliu.

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

O alta clasificare:

Diagrame structurale, care redau structura statica a aplicatiei: diagrame de clase, diagrame de obiecte, diagrame de componente si diagrame de distributie.

Diagrame comportamentale, diagrame de cazuri de utilizare, diagrame de secventa, diagrame de activitate, diagrame de colaborare si diagrame de stari.

Diagrame de management al modelului: pachete, subsisteme si modele

Informatii despre UML( specificatii, tutoriale si instrumente) pot fi consultate in site-ul: https://www.uml.org.

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.

Modelul 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,

scenarii,

cazurile de utilizare

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

Linia care conecteaza un actor de un caz de utilizare se numeste legatura de comunicare.

Determinarea actorilor permite precizarea limitelor sistemului intr-o maniera progresiva: vagi la inceput, 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 intre actori si sistem. Ele descriu interactiuni potentiale fara a intra in 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 maxim 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

Urmeaza o descriere similara cu cea anterioara:

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. Ele pot fi incluse in documentele de specificare a cerintelor utilizatorilor si a cerintelor software.

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

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

Diagramele de cazuri de utilizare se folosesc pentru a reprezenta relatiile intre cazurile de utilizare ce descriu un sistem.

Exista trei tipuri de relatii intre cazurile de utilizare:

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 in care functioneaza un 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 urmatoare:

Reprezentarea sistemului intr-o diagrama de caz de utilizare

Sistemul este reprezentat printr-un dreptunghi iar numele sau este scris in interiorul dreptunghiului.

Cazurile de utilizare si diagramele de cazuri de utilizare pot reda comportamentul unui 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.

Diagrame de interactiune

Cazurile de utilizare constituie o descriere functionala a cerintelor, structurata in 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 in cadrul scenariului.

Scenariile, care au fost intocmite la inceputul etapei de analiza, sunt reprezentate in continuare prin diagrame de interactiune: diagrame de colaborare si diagrame de secventa.

o Diagramele de colaborare redau relatiile structurale dintre obiecte si mesajele prin care ele comunica.

o 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 avand limite foarte clare si un sens precis in contextul problemei studiate. Fiecare obiect are o identitate si poate fi distins de celelalte.

In UML, un obiect se reprezinta sub forma unui dreptunghi continand 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 in jos. Axa verticala poate fi gradata in scopul exprimarii mai exacte a constrangerilor temporale in cazul modelarii unui sistem de timp real.

:Apelant

:Linie telefonica

:Apelat

Deschide telefonul

Ton

Formeaza numar

Indicator de sonerie Suna

Deschide telefonul

Alo

Diagrama de secventa

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

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

Ca mijloc de reprezentare exacta a mesajelor schimbate intre 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 urmatoare, 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>>

intoarcere dupa exec. operatie

Apeluri de operatii, crearea si distrugerea obiectelor.

Sagetile 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, 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 a unui mesaj nu intrerupe executia expeditorului. Expeditorul trimite mesajul fara sa stie cand, nici chiar daca mesajul va fi tratat de catre destinatar. In figura urmatoare 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 in etapa de proiectare, pentru a realiza de exemplu o excludere mutuala in utilizarea unei resurse critice. Forma de sincronizare poate fi importanta de asemenea in etapa de analiza. De exemplu, comunicatia prin posta corespunde unei trimiteri asincrone.

Control descentralizat

Pentru a indica bucle si salturi se pot adauga notatii de tip pseudocod pe partea stanga a diagramei:

O asistenta medicala trimite 2 mesaje asincrone: catre laboratorul medical, pentru a rezerva o data pentru un test, si catre o societate de asigurari, pentru aprobarea testului. Ordinea in care sunt trimise cele 2 mesaje nu este importanta. Daca societatea de asigurari aproba testul, atunci asistenta planifica testul la data furnizata de laboratorul medical. Reprezentarea intoarcerii dupa tratarea mesajului asincron nu este obligatorie.

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

Relatiile structurale sunt reprezentate prin "legaturi" - linii care conecteaza obiectele.

Ordinea de trimitere a diferitelor mesaje este indicata printr-un numar amplasat in fata mesajului, ca in figura urmatoare.

Obiectele si legaturile create sau distruse in cursul unei interactiuni pot purta constrangerile , respectiv .

Obiectele care sunt create si distruse in cursul aceleiasi interactiuni sunt identificate prin constrangerea .

"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 in 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 intr-o maniera mai abstracta, fara a se intra in detaliile obiectelor de interfata utilizator. Primul mesaj de interactiune este trimis de actor. Un exemplu este prezentat in figura urmatoare:

Figura urmatoare reda o posibila diagrama de colaborare, corespunzatoare unui scenariu al cazului de utilizare "Imprumut". 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

Cele doua 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.

Urmatoarea diagrama de secventa reda secventa de operatii pentru rezervarea unei camere de hotel. Obiectul care initiaza secventa de mesaje este o fereastra de rezervare.

Fereastra de rezervare trimite mesajul makeReservation() unui obiect HotelChain, care trimite mesajul makeReservation() unui obiect Hotel. Daca obiectul Hotel are camere disponibile, atunci el face o Rezervare si o Confirmare.

In aceasta diagrama mesajele sunt reprezentate prin apeluri de operatii din clasele obiectelor participante.

Semnul * din fata apelului propriu available() inseamna iteratie. Expresia dintre [] este o conditie. Diagrama contine si o nota explificativa. Astfel de note pot fi incluse in orice diagrama UML.

Ordinea mesajelor este indicata prin secvente de numere: mesajele de la acelasi nivel (trimise in timpul aceluiasi apel) au acelasi prefix, sufixele indicand secventa in care au loc.

Semantica asociata unei clase corespunde unui punct de vedere. Obiectele din lumea reala pot fi abstractizate in mod diferit. De exemplu, un cal poate fi incadrat in clasa mijloacelor de transport terestre sau in 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.

Reprezentarea detaliata a unei clase precizeaza vizibilitatea informatiilor din clasa:

Relatiile dintre clase sunt abstractii ale relatiilor existente intre obiecte. Fiecarei familii de legaturi intre obiecte ii corespunde o relatie intre clasele obiectelor.

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

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

o Rolul exprima felul in care o clasa 'vede' o alta clasa in cadrul unei asocieri. De exemplu, in asocierea dintre clasele Firma si Persoana, orice obiect al clasei Persoana este un "Angajat" al unei Firme, care este reprezentata printr-un "Patron" .

Daca intre doua clase exista o singura asociere, numele asocierii este suficient pentru a preciza relatia. Numele de rol se folosesc de regula atunci cand intre 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 in figura de mai jos. De exemplu, asocierea ilustrata in figura urmatoare exprima faptul ca "Proiectele sunt implementate prin Programe scrise in Limbaje de programare".

Fiecare rol al unei asocieri poate purta o indicatie de multiplicitate care arata cate obiecte ale unei clase pot fi legate unui obiect al celeilalte clase. De exemplu, o firma poate avea zero sau mai multi angajati. Multiplicitatea poate fi 'unu', 'mai multe '(*) sau un subansamblu de intregi pozitivi: , M..N, sau (de la zero la mai multi), .

Multiplicitatea unei asocieri exprima o constrangere valabila pe toata durata de existenta a obiectelor claselor asociate. Multiplicitatile nu trebuie sa fie considerate in 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 intre 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 cu atribute este numita asociere atributata. Ea 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 constranse. Constrangerile sunt scrise intre acolade. De exemplu, instantele clasei B asociate unei instante a clasei A trebuie sa fie ordonate:

O asociere poate lega o clasa de ea insasi. O asemenea asociere este numita asociere reflexiva Un exemplu de asociere reflexiva este cel ilustrat in figura 2.26. Fiecare persoana are zero, unu sau doi parinti si zero sau mai multi copii. Numirea rolurilor este in 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 impreuna cu valoarea cheii identifica un sub-ansamblu al instantelor clasei B, care participa la asociere. Exemplu:

Un director impreuna cu un nume de fisier desemneaza toate fisierele din director cu acelasi nume si diferite extensii.

Agregarea este o forma particulara de asociere care exprima un cuplaj mai strans intre clase. Una dintre clase joaca un rol mai important decat cealalta in 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 in care multiplicitatea agragatului are valoarea 1, distrugerea agregatului antreneaza distrugerea componentelor.

Compunerea este un caz particular de agregare. Exprima o agregare prin continere fizica

Distrugerea obiectului agregat antreneaza distrugerea componentelor. De exemplu, in agregarea masina- motor definita mai sus, motorul unei masini poate fi inlocuit cu altul. Motorul unei masini poate fi pus in alta masina! Daca insa reprezentam relatie masina - motor ca relatie de compunere-> fiecare masina are un motor unic, care nu poate fi inlocuit si motorul nu poate fi pus in alta masina!

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 in factorizarea elementelor comune (atribute, operatii si constrangeri) ale unui ansamblu de clase intr-o clasa mai generala, numita superclasa. Clasele sunt ordonate intr-o ierarhie. Sageata care simbolizeaza generalizarea intre doua clase puncteaza catre clasa mai generala:

In ierarhia din figura de mai sus, fiecare clasa (exceptand 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 intr-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 incapsulate in sub-clase care extind functiile existente. De exemplu, daca intr-o aplicatie apare necesar sa se reprezinte 'bicicleta' ca vehicul de transport, in plus fata de cele reprezentate in ierarhia de mai sus, atunci se va defini o clasa noua, sub-clasa a clasei 'Vehicul terestru', in care vor fi definite particularitatile bicicletei ca vehicul terestru. Fiecare sub-clasa a unei ierarhii mosteneste atributele si operatiile definite in clasele aflate pe calea de la clasa radacina la subclasa respectiva, fiind cu atat mai specializata cu cat se afla mai departe de radacina.

Mostenirea este o tehnica oferita de limbajele de programare pentru a construi o clasa plecand de la una sau mai multe clase, partajand atribute, operatii si uneori constrangeri in interiorul unei ierarhii de clase. Clasele copil mostenesc caracteristicile claselor parinte. Atributele si operatiile declarate in clasele parinte sunt accesibile in clasele copil, ca si cum ar fi declarate local. Mostenirea este o modalitate de a realiza clasificarea.

Relatia de generalizare definita in UML este mai abstracta decat relatia de mostenire care exista in limbajele de programare obiect, cum ar fi C++. Ea este mai adecvata etapei de analiza (exista si intre cazuri de utilizare!). Decizia asupra modalitatii de a realiza generalizarea se ia mai tarziu, in 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 in evidenta de arborele de mostenire: fiecare subarbore grupeaza obiectele care impart caracteristicile radacinii sale. De exemplu, adaugarea de noi caracteristici la clasa Articol-de-lux (figura )nu afecteaza clasa imbracaminte 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.

Urmatoarea diagrama de clase modeleaza o aplicatie care permite plati pe baza de ordine ale clientilor.

Sageata asociata asocierii se numeste navigabilitate. Ea indica directia in care trebuie sa fie traversata sau interogata asocierea. De exemplu, un obiect OrderDetail poate fi interogat despre obiectul Item asociat.

Asocierile fara navigabilitate sunt considerate bi-directionale. Navigabilitatea este un element optional. Se adauga pentru a imbunatati claritatea diagramei.

O dependenta este o relatie intre 2 clase in care modificarea uneia poate forta modificarea celeilalte. Exemplu: CompanyDetails depinde de Company. Daca se modifica Company trebuie sa se modifice si CompanyDetails.

O constrangere este o conditie pe care orice implementare a diagramei trebuie sa o satisfaca. Este scrisa intre paranteze . Exemplu: Un obiect Section poate fi parte dintr-un obiect CourseSchedule numai daca nu a fost anulat.

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 legaturile dintre ele la un moment dat.

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.

Se folosesc pentru modelarea aspectelor dinamice ale unui sistem, subsistem, clasa.

O diagrama de stari reda un automat cu stari finite, printr-o succesiune de stari si tranzitii intre stari. Tranzitiile pot fi declansate de evenimente. Exemplu:

Un eveniment poate sa corespunda aparitiei unei situatii date in domeniul aplicatiei. El nu are durata. De exemplu, "utilizatorul apasa pe butonul stanga" sau "o persoana iese din birou'.

Doua evenimente pot fi legate printr-o legatura de cauzalitate. De exemplu, "zborul 100 trebuie sa plece de la Bucuresti inainte sa soseasca la Paris".

Doua evenimente fara legatura de cauzalitate se numesc concurente. De exemplu, "zborul 200 poate sa plece inainte sau dupa zborul 450 care pleaca de la Roma".

Un eveniment este o cale de transmisie de informatii cu sens unic de la un obiect catre un altul.

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

O diagrama de stari descrie comportamentul obiectelor unei clase prin stari si evenimente

Obiectele care nu au un comportament reactiv foarte marcat pot fi considerate ca obiecte care raman intotdeauna in aceeasi stare.

Fiecare obiect este la un moment dat intr-o stare particulara.. De exemplu, starea curenta a unei persoane poate fi: in activitate, in somaj sau la pensie. Este determinata de varsta persoanei si de prezenta unei legaturi catre o firma:

Diagramele de stari sunt grafuri orientate. Starile sunt legate prin conexiuni bidirectionale numite tranzitii.

Trecerea dintr-o stare in alta se poate efectua automat sau atunci cand o tranzitie este declansata de un eveniment. Trecerea dintr-o stare in alta este instantanee, deoarece sistemul trebuie sa fie intotdeauna intr-o stare cunoscuta. Un eveniment poate determina o tranzitie in aceeasi stare. Starile se reprezinta prin dreptunghiuri rotunjite. Fiecarei stari ii este asociat un nume care o identifica.

In unele cazuri, diagramele de stari pot deveni foarte complicate. Problema poate fi rezolvata recurgand la abstractizare. Astfel,

mai multe stari pot fi abstractizate intr-o singura stare, care corespunde unei reprezentari de nivel ierarhic mai inalt, dupa cum

De exemplu, starile A si B din diagrama ilustrata in figura de mai jos, pot fi abstractizate intr-o stare mai generala deoarece din ambele exista o tranzitie in starea C:

o Este posibil sa existe mai multe stari finale, fiecare corespunzand unei conditii de sfarsit diferite.

o 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 in cazul aparitiei unui eveniment.

In cazul in 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 in specificatia unei clase apar in diagramele stari ca actiuni si activitati.

O actiune este considerata ca instantanee, adica are un timp de executie neglijabil in raport cu dinamica sistemului. In diagramele de stari-tranzitii, actiunile sunt atasate evenimentelor:

O actiune poate fi apelul unei operatii, trimiterea unui semnal, crearea/distrugerea unui obiect, evaluarea unei expresii. Timpul de executie al unei actiuni este nesemnificativ.

In figura de mai sus, actiunea corespunde unei operatii declarate in clasa obiectului destinatar al evenimentului. Ea este executata atunci cand evenimentul este receptionat si determina trecerea obiectului din starea X in 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 pana cand un eveniment o intrerupe declansand o tranzitie. Alte activitati sunt secventiale, ca de exemplu executia unui calcul. Activitatile sunt indicate prin cuvantul cheie 'do':

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

Anumite actiuni se executa inainte sau dupa o activitate. Actiunile de intrare/iesire sunt specificate in 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 intalnirea unui eveniment care nu schimba starea curenta:

In cazul in 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 sfarsitul unei activitati secventiale poate fi de asemenea controlata prin garzi:

Crearea unui obiect se reprezinta prin trimiterea unui eveniment de creare clasei obiectului. Parametrii acestui eveniment permit initializarea noului obiect care isi incepe existenta plecand din starea initiala descrisa in automatul clasei.

Distrugerea unui obiect este efectiva atunci cand fluxul de control al automatului ajunge intr-o stare finala.

O diagrama de activitate poate reda pasii unui proces de calcul, fluxul controlului intr-o operatie, executia secventiala sau paralela a unor activitati.

O diagrama de activitate reda fluxul controlului de la o activitate/actiune la alta.

O stare activitate poate fi descompusa si reprezentata prin alte diagrame de activitate. Trecerea de la o activitate/actiune la urmatoarea se reprezinta prin tranzitii. O stare activitate care este la randul sau descrisa printr-o alta diagrama de activitate se reprezinta printr-un nume precedat de cuvantul Do.

Intr-o diagrama de activitate pot fi specificate si obiectele implicate in diverse activitati, conectandu-le printr-o relatie de dependenta sau tranzitie care le creaza, distruge sau modifica. Aceasta utilizare a relatiei de dependenta este numita "flux obiect" deoarece reprezinta participarea unui obiect intr-un flux de control.

O diagrama de activitate poate fi aranjata in coloane distincte, corespunzatoare obiectelor care executa fiecare activitate. Coloanele sunt denumite "swimlanes". De exemplu, cele 3 obiecte care executa activitatile redate in diagrama urmatoare sunt: Clientul, masina ATM si Banca.

Expresiile garda sunt scrise intre paranteze patrate: [expresie garda]. Ramificarile si unificarile sunt reprezentate prin romburi.

Ramificarea in activitati concurente (fork) si reunificarea (join) sunt reprezentate printr-o bara orizontala ingrosata.

a modela aspecte dinamice la nivel de sistem, subsistem, operatie, metoda a unei clase

a modela aspectele dinamice ale unei societati de obiecte reprezentata printr-o diagrama de colaborare

La nivel de sistem se pune accentul pe activitati si actiuni asa cum sunt ele vazute de actorii care comunica cu sistemul.

Pornind de la o diagrama de activitate poate fi generat automat cod sursa ("forward engineering"), in special atunci cand diagrama reprezinta o operatie. De asemenea este posibila generarea diagramei de activitate pornind de la cod ("ingineria inversa" - "reverse engineering").

Se poate simula executia unui proces reprezentat printr-o diagrama de activitate animand starile actiune pe masura ce ele sunt atinse la executia sistemului.

Conceptul de interfata exista in unele limbaje de programare obiect, mai recente, de exemplu in Java, unde interfata este o constructie de limbaj diferita de clasa.

Prin aceasta separare implementarea clasei este ascunsa si clientii clasei sunt fortati sa foloseasca numai interfata clasei. Daca interfetele pot fi definite astfel incat sa fie complet independente de limbajul de programare si de spatiul necesar obiectelor clasei care le implementeaza, atunci codul care utilizeaza interfetele nu va trebui recompilat cand se modifica implementarea interfetei.

In Java, se poate defini o interfata si clasa sau clasele care implementeaza interfata. De asemenea, o clasa poate sa implementeze mai multe interfete. De exemplu, pot fi definite interfetele "Angajat" si "Parinte", ambele fiind implementate de o aceeasi clasa, "Persoana". In anumite contexte clasa "Persoana" este utilizata prin interfata sa "Parinte" in altele prin interfata "Angajat".

Limbajul C++ nu include o constructie numita interfata, dar o interfata poate fi definita printr-o clasa abstracta pura. De exemplu, interfata "Angajat" poate fi definita in C++ prin clasa abstracta "Angajat".

O interfata este un set de metode corelate care definesc o anumita comportare. Toate metodele sunt publice si nu se specifica nici un fel de implementare pentru ele. De asemenea, o interfata nu are stare (nu contine variabile).

De asemenea, intre interfete, clase si componente pot fi stabilite relatii de realizare si dependenta. Astfel, clasa InputStream, din figura urmatoare, este abstracta. Clasa DataInputStream implementeaza atat clasa abstracta InputStream cat si interfata DataInput. Clasa Reader utilizeaza functiile oferite de interfata DataInput.

O clasa care implementeaza mai multe interfete poate prezenta, intr-un anumit context, numai una dintre interfetele pe care le implementeaza. Fiecare interfata reprezinta un rol pe care il poate avea un obiect instanta din clasa respectiva. De exemplu, in asocierea cu clasa Firma, clasa Persoana prezinta interfata Angajat. Intr-o alta asociere ea poate prezenta interfata Parinte.

Intelegerea unei interfete

O interfata trebuie sa asigure o separare clara intre vederea externa si cea interna a unei abstractii, facand posibila utilizarea abstractiei fara a se cunoaste implementarea sa. Pentru ca o interfata sa poata fi mai bine inteleasa, se pot furniza informatii suplimentare cum ar fi:

El specifica domeniul unor obiecte impreuna cu operatiile aplicabile obiectelor de tipul respectiv. Conceptul de tip este strans legat de conceptul de interfata. Deosebirea este ca definitia unui tip poate contine atribute (variabile) in timp ce a unei interfete nu.

Diagrama din figura 3.46 arata ca instantele clasei Persoana pot fi de 3 tipuri:Candidat, Angajat, Pensionar.

In UML, termenul de componenta desemneaza un element software fizic din componenta unui sistem. Astfel, o componenta poate fi: cod binar, document, fisier continand cod sursa sau date, tabela a unei baze de date.

O componenta binara este o parte fizica si substituibila a unui sistem, care realizeaza si este in conformitate cu un set de interfete.

Componentele binare sunt independente de limbajul de programare in care au fost codificate iar utilizarea lor se bazeaza exclusiv pe interfete. Tehnologiile folosite in prezent pentru crearea de componente binare sunt: COM+, DCOM,CORBA, Java Beans.

Diagramele de componente redau relatiile de dependenta intre diferite componente ale unui sistem (fig. 3.47).

Un nod este un element fizic care exista in timpul executiei unui sistem si reprezinta o resursa de calcul. Un nod are cel putin memorie si adesea posibilitati de procesare.

hardware a unui sistem. In mod tipic, un nod reprezinta un procesor sau un dispozitiv pe care pot fi repartizate componente.

Un nod se reprezinta printr-un cub in care este inscris numele sau sau numele si componentele care se excuta pe nod.

Un set de componente care sunt alocate unui nod este numit unitate de distributie.

Nodurile pot fi organizate specificand relatii de dependenta, generalizare si asociere intre ele. Tipul uzual de relatie intre 2 noduri este asocierea. O asociere reprezinta o conexiune fizica intre noduri, cum ar fi o conexiune Ethernet, o linie seriala, un bus, chiar si o conexiune satelit.

Se poate preciza tipul fiecarui nod. De exemplu, "procesor" este un nod care are posibilitati de prelucrare, "dispozitiv" este un nod fara posibilitati de prelucrare care in general se foloseste pentru interfatare cu mediul. Se pot defini tipuri speciale de procesoare si dispozitive. Sistemul ilustrat in figura urmatoare cuprinde: un server, 3 terminale X, mai multe PC-statii pilot si o imprimanta.

Un pachet este o grupare logica de elemente de modelare. De exemplu, poate grupa elemente care participa la furnizarea unui serviciu. Gruparea poate avea drept scop controlul vizibilitatii

De regula, un pachet este redat grafic doar prin numele sau dar reprezentarea poate contine si detalii (fig. 3.50).

Un pachet poate contine: clase, interfete, componente, noduri, colaborari, cazuri de utilizare, diagrame, alte pachete.

Elementele publice ale unui pachet constituie interfata pachetului. Elementele protejate sunt vizibile din pachetele care mostenesc de la pachetul respectiv. Interfata unui pachet este vizibila numai din pachetele care importa explicit pachetul. Generalizarea intre pachete este la fel ca intre clase.

Un sistem este o grupare de elemente organizate pentru realizarea unui scop. Sistemele pot fi descompuse in subsisteme separate, fiecare subsistem putand fi vazut la randul sau ca un sistem, la un nivel de detaliu mai coborat. Subsistemele sunt grupari de elemente care pot fi modelate si dezvoltate relativ independent. Descompunerea are loc in etapa de proiectare arhitecturala, cand se decide cum vor fi realizate cerintele. Relatiile sistem-subsisteme pot fi reprezentate printr-o diagrama de pachete.

Modelul unui sistem este o simplificare a realitatii, o abstractie a sistemului, creata pentru a intelege mai bine sistemul s a-l specifica.

O vedere este o proiectie a unui model dintr-un punct de vedere in care sunt omise aspectele nerelevante din punctul de vedere respectiv.

Cuprinde cazurile de utilizare care descriu comportarea sistemului vazuta de utilizatori, analisti si testori. se folosesc diagrame de cazuri de utilizare, diagrame de interactiune, de stari si de activitati.

diagrame de interactiune, de stari si activitati, pentru modelarea aspectelor dinamice

Descrie procesele si firele de executie care formeaza mecanismele de concurenta si de sincronizare ale sistemului. Cuprinde aceleasi tipuri de diagrame dar cu accent pe clasele si obiectele care reprezinta fire si procese de executie.

Implementation View descrie componentele care alcatuiesc sistemul fizic final. Se folosesc:

diagrame de interactiune, de stari si activitati pentru modelarea aspectelor dinamice.

Deployment View cuprinde nodurile care formeaza topologia hardware a sistemului. Se folosesc:

diagrame de interactiune, de stari si de activitate, pentru modelarea aspectelor dinamice

Un proces de dezvoltare software bine structurat, asa cum este definit in Rational Unified Process, presupune rafinarea succesiva a arhitecturii sistemului intr-o maniera care este dirijata de cazurile de utilizare, centrata pe arhitectura, iterativa si incrementala.

Cazurile de utilizare se folosesc pentru stabilirea comportarii sistemului, pentru testare si comunicare.

Arhitectura sistemului este principalul aspect considerat in conceptia, constructia si evolutia sistemului.

Produce o succesiune de versiuni executabile care sunt livrate clientului pe masura ce sunt create.

Fiecare noua versiune creata include aspecte noi, astfel incat sistemul final este produs intr-o maniera incrementala.

Un proces iterativ si incremental este dirijat de risc ("risk-driven"). Fiecare noua livrare este focalizata pe reducerea celor mai importante riscuri ale succesului proiectului.

Administratie	Alimentatie	Arta cultura	Asistenta sociala	Astronomie
Biologie	Chimie	Comunicare	Constructii	Cosmetica
Desen	Diverse	Drept	Economie	Engleza
Filozofie	Fizica	Franceza	Geografie	Germana
Informatica	Istorie	Latina	Management	Marketing
Matematica	Mecanica	Medicina	Pedagogie	Psihologie
Romana	Stiinte politice	Transporturi	Turism

Modelarea sistemelor informatice

Diagrama de flux de date

Scopurile limbajului UML

Imprumut

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

Diagramele de cazuri de utilizare se folosesc pentru a reprezenta relatiile intre cazurile de utilizare ce descriu un sistem.

Exista trei tipuri de relatii intre cazurile de utilizare:

Control descentralizat

Echivalenta diagrame de interactiune - diagrame de colaborare

Cele doua 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.

Persoana

A

Fisier

Avion

Camion

Masina

Intelegerea unei interfete

Comentarii

Caracterizari

Cauta document