Introducere Limbajul Unificat de Modelare (UML) reprezint rezultatul colaborrii dintre Gereid Booch, James Rambo, Ivar Jakobson,

Rebecca Wirfs-Brock, Peter Yourdon i muli alii. Jacobson primul a descris procesul de identificare i fixare a cerinelor fa de sistem sub form de seturi de tranzacii, numite cazuri de utilizare (use case). Jacobson, de asemenea, a realizat metoda proiectrii sistemelor sub denumirea de Proiectarea orientat pe obiecte a asigurrii program (Object Oriented Software Engineering, OOSE), concentrnd atenia asupra analizei. Booch, Rambo i Jacobson, despre care de obicei se spune ca despre "trei prieteni" (three amigos), lucreaz n corporaia Rational Software. n general activitatea lor este legat de standardizarea i mbuntirea limbajului UML. Simbolurile UML amintesc foarte mult notaiile lui Booch i OMT, dar, de asemenea conin i elemente din alte notaii. n figura 1 este artat un exemplu de notaii.
Pune bani pe cont Transfera bani

Clientul

Scoate bani de pe cont

Arata balanta

Fig.1. Exemple de simboluri n notaia Booch Procesul de consolidare a metodelor, incluse n UML, a nceput n anul 1993. Fiecare din cei trei autori ai acestui limbaj - Booch, Rambo i a Jacobson - a nceput s introduc n aplicaiile sale ideile celorlali doi autori. O astfel de unificare a metodologiei a durat pn n 1995, cnd a aprut Versiunea 0.8 a Metodei Unificate (Unified Method). n 1996, Metoda Unificat a fost actualizat i transformat n UML. n 1997 UML1.0 a fost ratificat i transmis grupului Object Technology Group, dup care au nceput s-l adapteze muli dintre principalii productori de produse program. n sfrit, la 14 noiembrie 1997 grupul OMG a declarat limbajul UML1.1 standart industrial. Ce reprezint Rational Rose? Rational Rose este un instrument puternic pentru analiza i proiectarea sistemelor software orientate pe obiecte. Acesta permite modelarea sistemelor nainte de a scrie codul, astfel nct de la nceput putei fi siguri n caracterul adecvat al arhitecturii lor. Cu ajutorul modelului gata neajunsurile proiectului sunt uor de detectat la etapele cnd corectarea lor nu este att de costisitoare. Mediul Rational Rose permite proiectarea cazurilor de utilizare i diagramele lor pentru vizualizarea posibilitilor funcionale ale sistemului. Diagramele de interaciune arat cum

lucreaz obiectele mpreun, oferind funcionalitatea necesar. Pentru vizualizarea obiectelor sistemului i relaiilor lor se utilizeaz diagramele Claselor. Diagramele Componentelor ilustreaz modul n care clasele se suprapun cu componente fizice gata ale sistemului. n cele din urm, diagramele Desfurrilor utilizeaz pentru vizualizarea proiectului sisteme distribuite. Modelul Rose - este o imagine a sistemului. Aceasta conine toate diagramele UML, actorii, cazurile de utilizare, obiectele, clasele, componentele i ansamblurile sistemului. Ea descrie detaliat, ce conine sistemul i cum funcioneaz, astfel nct experii o pot folosi n calitate de schi sau ca un plan al sistemului n realizare. Acest plan ajut la rezolvarea problemei vechi. De exemplu, echipa de experi a discutat cu utilizatorii i a determinat cerinele fa de aplicaie. Programatorii sunt gata de a scrie cod. Unul dintre ei (fie Bob) ia o parte din cerine, adopt anumite decizii i scrie un careva fragment de cod. Altul (Jane), de asemenea, ia o parte din cerine, i ia propria sa decizie complet diferit de a lui Bob cu privire la proiect, i scrie un alt cod. Evident ca se atept diferene ntre stilurile de programare; primind acelai set de cerine, 20 de experi vor creea 20 de sisteme diferite. Astfel, fr examinarea detaliat a lucrului cu fiecare participant la proiect va fi dificil de a nelege ce decizii asupra proiectului sunt luate, din ce elemente const sistemul i ce reprezint n sine nsi structura sa general. Neavnd proiectul documentat, este dificil chiar de a fi sigur, c aplicaia creat - este exact ceea ce au dorit utilizatorii. Procesul tradiional pe care l urmrim este prezentat n figura 2.

Cerinte

AC

: Bob

Fig. 2. Analiza i proiectarea sistemului din punctul de vedere a lui Bob Cu toate c cerinele au fost documentate, ntregul proiect se afl n capul lui Bob, i nimeni, dect Bob, nu nelege destul de bine arhitectura sistemului. Cnd Bob prsete echipa, informaia pleac mpreun cu el. Dac v-ai aflat n astfel de situaie, fii de acord, c este foarte greu de a nelege sistemul ru documentat. Modelul Rose - propune o abordare complet diferit (figura 3).
Cerinele Modelul obiectului Codul

Fig. 3. Analiza i proiectarea sistemului cu ajutorul modelului Rose

n acest caz, proiectul este deja documentat. Experii se pot aduna i discuta deciziile luate cu privire la proiect nainte de codificarea real. Nu trebuie s v facei griji c fiecare dintre ei va proiecta n felul su diferit prile unei i aceleai aplicaii. Cu toate acestea, modelele sunt utilizate nu numai de experi: 1. Cu ajutorul Diagramelor Cazurilor de Utilizare, clienii i managerii proiectului vor avea o idee general despre sistem i vor putea lua decizii cu privire la domeniul lui de aplicare. 2. Cu ajutorul Diagramelor Cazurilor de Utilizare manageri proiectului vor putea diviza proiectul pe diferite sarcini de gestionare. 3. Din documentaia privind cazurile de utilizare analitii i consumatorii vor nelege ce va face sistemul deja finisat. 4. Studiind aceeai documentaie scriitorii tehnici vor putea ncepe s scrie un ghid pentru utilizatori i s pregteasc planuri de studiere a lor. 5. Din diagramele de Secven i diagramele de Cooperare analitii i experii vor clarifica ct de logic funcioneaz sistemul, vor nelege obiectele acestuia i mesajele dintre ele. 6. Cu ajutorul documentaiei privind cazurile de utilizare, precum i diagramele de Secven i de Cooperare specialitii cu privire la controlul calitii vor putea obine informaia cerut de acesta pentru a scrie scenarii de testare. 7. Cu ajutorul diagramelor Claselor i Strilor, experii vor avea idee despre fragmentele sistemului i interaciunile dintre ele. 8. Din diagramele Componentelor i Desfurrilor personalul de exploatare va putea cunoate, ce fiiere *. EXE i *. DLL i alte componente vor fi create, precum i unde acestea trebuie s fie plasate n reea. 9. Cu ajutorul modelului ntreaga echip de participani la proiect vor putea monitoriza realizarea cerinelor iniiale fa de cod, deasemenea din orice fragment de cod va arta cerinele iniiale, pe care el le realizeaz. Deci, Rose este un instrument care poate fi utilizat de ctre toi participanii la proiect. Acesta de fapt, este un depozit de informaii despre contextul i proiectul sistemului, din care fiecare participant la proiect poate selecta ceea de ce are nevoie. n afar de cele amintite mai sus, Rational Rose permite generarea unui cod schelet n diferite limbaje, inclusiv C++, Java, Visual Basic i PowerBuilder. Mai mult dect att, putem efectua proiectarea invers a codului i crea, astfel, modelele sistemelor deja existente. Este destul de avantajos de a avea modele Rose pentru aplicaiile deja existente. Dac n model s-au introdus schimbri, Rose permite s modificm codul pentru execuia lui. n cazul n care codul a fost modificat, automat putem rennoi n mod corespunztor i modelul. Datorit acestuia putem menine corespondena dintre model i cod, reducnd riscul de "mbtrnire" a primului.

Mediul Rose poate fi extins cu ajutorul limbajului de programare RoseScript, importat mpreun cu Rose. Cu RoseScript putem scrie codul pentru introducerea automat a modificrilor n model, pentru crearea rapoartelor i efectuarea altor sarcini. n prezent sunt disponibile trei versiuni diferite de Rose: 1. Rose Modeler, care permite de a dezvolta modelele sistemului, dar nu suport posibiliti de generare a codului i de proiectare invers. 2. Rose Professional, ce permite generarea codului ntr-un careva limbaj. 3. Rose Enterprise, permite generarea codului n C++, Java, Visual Basic i scheme Oracle8. Mai mult dect att, n cea mai recent versiune Rose 2002 o atenie deosebit se acord pentru integrarea sa cu aa instrumente, cum ar fi Rational RequisitePro, TeamTest, Visual Basic, C++ i altele. Rose 2002 asigur publicarea modelelor dumneavoastr pe pagini web. La fel ca i versiunea anterioar, aceasta este disponibil n variantele Modeler, Professional i Enterprise. Toate exemplele sunt scrise pentru toate versiunile Rational Rose.

LUCRAREA DE LABORATOR NR. 1 TEMA: Familiarizarea cu tehnologiile, metodologiile i principiile elaborrii modelelor n baza blocurilor constructive ale limbajului UML i CASE Rational Rose

Scopul lucrrii: 1. Studierea prii teoretice i verificarea cunotinelor n mediul instrumentului CASE Rational Rose. 2. Aprecierea importanei tehnologiilor, metodologiilor i principiilor elaborrii modelelor n ingineria softului, evideniind principalele aspecte importante. 3. Studierea notaiei i descrierea destinaiei elementelor/componentelor blocurilor constructive UML. 4. nsuirea principiilor de creare, modificare i salvare a respectivelor modele-diagrame elaborate. 5. Studierea i evidenierea respectrii cerinelor metodologice din exemplul reprezentat n partea teoretic a acestui ndrumar. 6. Analiza propriului sistem i determinarea cerinelor i precedentelor, descriind succint i elocvent scenariul (pas cu pas) cu exemple concrete.

Sarcina: Elaborai cte dou diagrame de fiecare tip utiliznd instrumentul CASE Rational Rose. Descriei 5 exemple din Booch.

Consideraii teoretice generale. Cerinele generale fa de metodologii i tehnologii n ingineria softului Metodologiile, tehnologiile i mijloacele instrumentale de proiectare (CASE - mijloace) alctuiesc baza proiectrii oricrui sistem informaional. Metodologia se realizeaz prin tehnologiile concrete i standardele care le susin, metode i mijloace instrumentale care asigur ndeplinirea proceselor ciclului vital. Tehnologia proiectrii se definete ca un ntreg din trei componente: (fig. 1); criteriile i regulile, care se folosesc pentru aprecierea rezultatelor de ndeplinire a notaii (a mijloacelor grafice i textuale), folosite pentru descrierea sistemului proiectat. operaiilor tehnologice;
-

procedura pas-cu-pas, care definete succesiunea operaiilor tehnologice de proiectare

Fig.1.1. Reprezentarea operaiei tehnologice de proiectare Instruciile tehnologice, care alctuiesc coninutul general al tehnologiei, trebuie s fie alctuite din descrierea succesiunii operaiilor tehnologice, condiiile, n dependen de care se efectuiaz o operaie sau alta, i descrierea nsui a operaiilor. Tehnologia de elaborare: analiza, proiectarea, dezvoltarea i sprijinul sistemului informaional ar trebui s satisfac urmtoarele cerine generale:
1. 2.

Tehnologia ar trebui s acorde suport deplin ciclului vital al softului; Tehnologia ar trebui s asigure realizarea scopurilor garantat de dezvoltarea sistemului informaional cu calitatea fix i n timpul stabilit; Tehnologia ar trebui s furnizeze un prilej de realizare a proiectelor mari, pe msur ce subsistemele (adic prilejul de decompoziie a proiectului pe componente, care au fost dezvoltate de grupuri de executori ntr-un numr limitat, cu integrarea ulterioar de componente). Experiena de elaborare a sistemelor informaionale mari, arat c pentru sporirea eficienei lucrului este necesar de a separa proiectul pe pri slab legate ntre ele, pe date i funcii a unor subsisteme. Realizareaa subsistemelor ar trebui s fie ndeplinit de grupurile separate de experi. Astfel este necesar de a furniza coordonarea executrii proiectului comun pentru a exclude duplicatul ntre grupuri de proiectare care poate s apar din cauza prezenei datelor i funciilor comune;

3.

4.

Tehnologia ar trebui s furnizeze un prilej de dirijare a ocupaiei de proiectare a subsistemelor separate de grupurile mici (3-7 persoane). Fapt cauzat de principiile de controlare a colectivului, i sporirea productivitii pe seama minimizrii comunicrilor externe;

5.

Tehnologia ar trebui s furnizeze timpul minim de recepie a sistemului informaional eficient. ntrebarea nu este despre termenul de realizare a ntregului sistem informaional, ci despre termenul de realizare a subsistemelor separate. Realizarea sistemului informaional ca ntreg ntr-un timp scurt poate atrage un numr mare de programatori, astfel nct efectul poate fi mai slab, dect la ndeplinirea ntr-un timp mai scurt a subsistemelor aparte cu un numr mai mic de programatori. Practica arat, ns c chiar i la prezena n ntregime a proiectului complet, introducerea merge consecvent pe subsisteme separate;

6.

Tehnologia ar trebui s furnizeze prilej unei configuraii a proiectului, dirijnd versiunile proiectului i ale componentelor sale, un prilej de eliberare automat a documentaiei de proiect i sincronizarea ei cu versiuni ale proiectului;

7.

Tehnologia ar trebui s furnizeze independena realizrilor de proiect, de mijloacele realizrii sistemului informaional (sisteme de gestiune a bazelor de date (SGBD), sisteme operaionale, limbaje i sisteme de programare);

8.

Tehnologia ar trebui s fie meninut cu complexul coordonat de Case-mijloace, furnizatori de automatizarea proceselor care se ndeplinesc pe toate scenariile ciclului vital. Aplicarea real a oricrei tehnologii de proiectare, elaborare i nsoire a sistemului

informaional ntr-o organizaie concret i proiectul concret, este imposibil fr elaborarea unui ir de standarde (reguli, nelegeri) care ar trebui s fie observate de toi participanii proiectului. Din aceste standarde fac parte urmtoarele: standardul proiectrii; standardul de nregistrare a documentaiei de proiectare; standardul interfeei utilizatorului.

Standardul de proiectare ar trebui s fondeze:

1.

Configuraiile modelelor necesare (diagrame) pe fiecare scen a proiectului i gradul lor de detalizare; Regulile de fixare a deciziilor proiectului pe diagrame, incluznd: reguli de denumire a obiectelor (incluznd nelegeri pe terminologie), un set de atribute pentru toate obiectele i regulile lor de oformare la fiecare nivel, regulile de oformare a diagramelor, incluznd cererile la forme i dimensiunile obiectelor, etc.

2.

3. Cererile privind configuraiile locurilor de munc a elaboratorilor, incluznd opiunile sistemului de operare, opiunile mijloacelor CASE, opiunile generale ale proiectului, etc.
4.

Mecanismul asigurrii lucrului n colaborare asupra proiectului, i desigur regulile de integrare a subsistemelor proiectului, regulile de ntreinere a proiectului n stare similar pentru toi elaboratorii (regulamentul schimbului informaiei de proiect, mecanismul fixrii obiectelor comune, etc), regulile de verificare a rezultatelor de proiect la noncontrazicere, etc. Standardul oformrii documentaiei de proiect trebuie s stabileasc:

1. 2.

Completarea, componena i structura documentaiei pe fiecare nivel al proiectrii; Cerinele privid oformarea acestei documentaii (incluznd cerinele la coninutul compartimentelor, subcompartimentelor, punctelor, tabelelor, etc.);

3. Regulile de pregtire, de privire, nelegere i acceptare a documentaiei cu indicarea limitelor maxime pentru fiecare nivel;

4. Cerinele la setrile sistemului de editare, folosite n funcie de mijloc integrat pentru pregtirea documentaiei;
5.

Cerinele la setrile mijloacelor CASE pentru asigurarea pregtirii documentaiei n corespundere cu cerinele stabilite. Standardul interfeei utilizatorului trebuie s stabileasc:
1.

Regulile de oformare a ecranului (fonturi i paleta de culori), componena i Regulile de folosire a tastaturii i a mouse-ului; Regulile de oformare a textelor de ajutor; Setul de mesaje standarde; Regulile de prelucrare a reaciei utilizatorului.

plasarea ferestrelor i elementelor de rulare;

2.

3. 4. 5.

Una din nelegerile de baz a metodologiei de proiectare a sistemului informaional este nelegerea ciclului vital al softului ei. Ciclul vital al softului (CVS) e un proces nentrerupt, care se ncepe de la momentul hotrrii despre necesitatea crerii lui i se termin n momentul excluderii lui totale din exploatare. Documentul normativ de baz, care reglementeaz CVS este standardul internaional ISO/IEC 12207 [1,2] ( ISO International Organization of Standardization, IEC International Electrotechnical Commision). El determin structura CV, care conine procese, aciuni i probleme, care trebuie s fie rezolvate n timpul crerii softului. Etapele elaborrii / dezvoltrii tradiionale ale produselor software n timpul dezvoltrii produselor software s-a constatat c exist anumite tipuri de activiti care trebuie efectuate la un moment dat: -analiza cerinelor ntreinerea. 1.1. Analiza cerinelor. Se stabilete ce anume vrea clientul ca s fac programul. Scopul este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se refer la lipsa ambiguitii, iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt cu cuvnt). 1.2. Proiectarea arhitectural. Din motive de complexitate, programele mari nu pot fi concepute i implementate ca o singur bucat. Astfel programul va trebui construit din module sau componente. Proiectarea arhitectural mparte sistemul ntr-un numr de module mai mici i mai simple, care pot fi abordate individual. 1.3. Proiectarea detaliat. Se realizeaz proiectarea fiecrui modul al aplicaiei, n cele mai mici detalii. -proiectarea arhitectural proiectarea detaliat -scrierea codului -integrarea componentelor -validarea -verificarea -

1.4. Scrierea/ generarea codului. Proiectul detaliat este transpus ntr-un limbaj de programare. n mod tipic, aceasta se realizeaz modular, pe structura rezultat la proiectarea arhitectural. 1.5. Integrarea componentelor. Modulele programului sunt combinate n produsul final. Rezultatul este sistemul complet. De obicei specialitii se conduc de anumite metodologii ale elaborrii i metodele lor conform modelului ciclui de via a sistemului care cuprinde mai multe etape. ns, pentru nceput, n timpul elaborrii cnd ncepem dezvoltarea unui produs soft avem nevoie de: -

o nelegere clar a ceea ce se cere; un set de metode i instrumente de lucru; un plan de aciune. Deci trebuie s ne punem urmtoarele ntrebri, cel puin, n legtur cu arhitectura

sistemului: Ce diagrame exist, ce legturi sunt ntre ele? Care mecanisme regleaz interaciunea claselor? Unde trebuie s fie prezentat fiecare diagram? Etc. Metodologia spiral. Metodologia spiral, propus tot de Boehm, este un alt exemplu bine cunoscut de metodologie a ingineriei programrii. Acest model ncearc s rezolve problemele modelului n cascad, pstrnd avantajele acestuia: planificare, faze bine definite, produse intermediare. El definete urmtorii pai n dezvoltarea unui produs: a) studiul de fezabilitate;
b)

analiza cerinelor;

c) proiectarea arhitecturii software; d) implementarea. Modelul n spiral recunoate c problema principal a dezvoltrii programelor este riscul. Riscul nu mai este eliminat prin aseriuni de genul: n urma proiectrii am obinut un model corect al sistemului, ca n modelul cascad. Aici riscul este acceptat, evaluat i se iau msuri pentru contracararea efectelor sale negative. Exemple de riscuri: a) n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt ignorate; b) clientul schimb cerinele; c) o firm concurent lanseaz un program rival pe pia; d) un dezvoltator/arhitect prsete echipa de dezvoltare; e) o echip nu respect un termen de livrare pentru o anumit component. n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de activiti comune:

1.

pregtirea: se identific obiectivele, alternativele, constrngerile;

2. gestionarea riscului: analiza i rezolvarea situaiilor de risc; 3. activiti de dezvoltare specifice pasului curent (de exemplu analiza specificaiilor sau scrierea codului);
4.

planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea strii proiectului.

Fig.1.2. Metodologia spiral Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri: Ciclul 1 Analiza preliminar: 1. Obiective, alternative, constrngeri 2. Analiza riscului i prototipul 3. Conceperea operaiilor 4. Cerinele i planul ciclului de via 5. Obiective, alternative, constrngeri 6. Analiza riscului i prototipul Ciclul 2 Analiza final: 7. Simulare, modele, benchmark-uri 8. Cerine software i validare 9. Plan de dezvoltare 10. Obiective, alternative, constrngeri 11. Analiza riscului i prototipul Ciclul 3 Proiectarea: 12. Simulare, modele, benchmark-uri 13. Proiectarea produsului software, validare i verificare 14. Integrare i plan de test 15. Obiective, alternative, constrngeri 16. Analiza riscului i prototipul operaional

Ciclul 4 Implementarea i testarea: 17. Simulare, modele, benchmark-uri 18. Proiectare detaliat 19. Cod 20. Integrarea unitilor i testarea acceptrii 21. Lansarea produsului Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe msur ce spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se apropie de soluia final. Dei este considerat ca un exemplu generic pentru metodologia ciclic, metoda are i elemente secveniale, puse n eviden de evoluia constant de la o etap la alta. Metodologiile orientate pe obiecte. Abordarea orientat pe obiecte se bazeaz pe identificarea obiectelor, entiti distincte care pot fi concrete (la nivel fizic) sau abstracte (la nivel conceptual). Obiectele sunt caracterizate prin structura datelor care le descriu i prin comportamentul pe care l pot manifesta, altfel spus operaiile care lucreaz cu datele lor. Rumbaugh subliniaz c fiecare obiect are identitatea sa chiar dac dou obiecte au aceleai valori ale atributelor ele rmn totui dou obiecte distincte. Obiectele sunt clasificate, definind clase pentru toate obiectele cu aceeai structur i comportament. Un principiu important n abordarea OO este ascunderea informaiilor n interiorul clasei - numit ncapsulare. Astfel, aspectele externe, vizibile din exteriorul clasei, de ctre utilizatorii acesteia, sunt separate de detaliile interne de implimentare, care trebuie ascunse. Aceeai operaie poate avea comportri diferite n clase diferite proprietate numit polimorfism. ntr-un limbaj OO metoda corect este selectat automat, n funcie de numele su i de clasa din care face parte obiectul. Dac mai multe clase au atribute i operaii comune, ele pot fi incluse ntr-o superclas care este apoi divizat n subclase ce i includ proprietile, prin mecanismul de motenire, i adaug, de asemenea, atribute i operaii noi. Astfel, se reduce redundana att la nivel conceptual al proiectului ct i la nivelul codului, obinndu-se unul dintre cele mai importante avantaje ale abordrii orientate pe obiecte. Pentru a reduce complexitatea problemelor se folosete abstractizarea ce permite concentrarea pe aspectele eseniale, inerente ale unei entiti; nu se iau decizii legate de implimentare pn nu se ajunge la o nelegere aprofundat a problemei. Poate urma astfel o

proiectare clar, care s contribuie la o abordare mai uoar a etapelor urmtoare: implimentarea, documentarea, ntreinerea. Limbajul UML UML (Unified Modeling Language) este prima platform pentru dezvoltarea rapid a aplicaiilor. Cauza apariiei UML a fost necesitatea abordrii unificate despre descrierea modelelor aplicaiilor business la nceputul anilor 90 ai secolului XX. Atunci au i aprut cteva zeci de variante de instrumentarii pentru crearea modelelor de acest tip, ns incompatibilitatea dintre ele, fcea dificil dezvoltarea CASE (Computer Aided Software Engineering) - mijloacelor i introducea unele neclariti. CASE - dezvoltarea soft-ului cu ajutorul calculatorului, adic dezvoltarea automatizat a soft-ului. CASE-mijloacele pe atunci aveau n majoritatea cazurilor, rolul de interfa a SGBD, ceea ce permitea automat generarea bazei de date dup schema ei grafic. Dezvoltarea UML a fost efectuat de ctre compania Rational Software, care a creat unul din primele CASE mijloace Rational Rose. UML apare datorit efortului colaborativ a lui Grady Booch, Dr. James Rumbaugh, Ivar Jacobson, Rebecca Wirfs-Brock, Peter Yourdon, i muli alii. UML a fost recunoscut ca standard al notaiilor folosit la modelarea sistemelor n baza celor mai relevante concepte ale primilor trei autori cu completri i de la ali specialiti. n UML mai este prevzut un important aspect ce reprezint creterea rigorii n definirea conceptelor utilizate, cretere realizat prin utilizarea limbajului OCL (este un limbaj tipizat de modelare, fr efecte secundare) la definirea semanticii conceptelor metamodelului. UML a aprut ca urmare a unificrii diferitor metode i a experienei anterioare, unde principalele obiective au fost: de a reflecta cele mai bune practici ale industriei; de a demistifica procesul de modelare a sistemului soft. Prima versiune a UM (Unified Method) 0.8 a fost introdus n 1995. UM a fost refcut i schimbat n UML n 1996. n octombrie 1995 a demarat procesul de unificare a metodelor OOD i OMT. Acest proces a fost extins pn n anul 1996 prin integrarea metodei Objectory i aderarea lui Ivar Jacobson la grupul format de Booch i Rumbaugh. n septembrie 1997 'rzboiul metodelor' ia sfrit prin adoptarea de ctre OMG a limbajului UML ca limbaj standard de modelare a aplicaiilor. OMG (Object Management Group) reprezint un consoriu internaional al crui obiectiv principal l constituie promovarea abordrii orientate obiect n cadrul ingineriei softului. Pentru a ne crea o imagine corect despre noile limbaje de modelare trebuie inut cont att de avantajele ct i de dezavantajele inerente ale unei unificri. Pe scurt, avantajele principale constau n:

 Eliminarea

unor diferene existente ntre conceptele i notaiile unor metode, diferene

nesemnificative, dar care au produs multe confuzii. Realizarea unei stabiliti n lumea productorilor i utilizatorilor de instrumente CASE, prin intermediul unui limbaj i metodologii care acoper integral etapele realizrii aplicaiilor. Eliminarea conceptelor care nu i-au dovedit viabilitatea i pstrarea celor care s-au dovedit a fi utile. Stabilirea unui numr suficient de documente (diagrame, rapoarte) pentru toate etapele (de via). Inconvenienele majore se datoreaz faptului c: Unificarea unor metode distincte presupune aproape inevitabil creterea numrului de concepte utilizate. Cu toate eforturile de generalizare, noua metod (noul limbaj) devine mai complex. Fiecare din metodele participante la procesul de fuziune accentueaz anumite aspecte ale procesului de modelare. Metoda rezultat nu poate ine cont de aceste aspecte n egal msur. De aceea este posibil ca modelarea unui tip particular de aplicaii s poat fi mai bine realizat cu o metod participant la procesul de reunificare, i nu cu metoda unificat. UML 1.0 a fost ratificat i dat OMG-ului n 1997. n 1997, OMG a emis UML 1.1 ca un standard industrial. Peste ani, UML a evoluat cu noi idei, ca de exemplu: sisteme web-based i modelarea datelor. Mai trziu n 2000 a fost ratificat versiunea UML 1.4. n prezent se lucreaz asupra noilor versiuni mai moderne i mai puternice. Utilizarea UML la modelarea i designerului bazei de date nu doar simplific comunicarea, dar i nltur barierile dintre elaboratori, oferindu-le un mediu mai eficient de modelare. Cu modelul bazei de date n limbajul UML, proiectantul bazei de date poate primi aa informaie ca constrngerile, triggere i indeci direct pe diagram. Cnd aceast informaie e modelat, utilizatorilor le este mult mai simplu s asigure comunicarea cu modelul bazei de date n ntregime. Pe scurt UML furnizeaz imagini standardizate ale aplicaiilor soft, el este un limbaj i un proces cu notaie neutr, ceea ce nseamn c se poate utiliza la designul ntregului sistem orientat pe obiecte n orice limbaj de programare i n orice proces de dezvoltare. UML este un limbaj de vizualizare, specificare, construire i documentare a componentelor sistemelor. Ca limbaj de vizualizare nseamn c mai nti se face designul sistemului desennd diagrame, adic asigur reprezentarea grafic a modelului prin una sau mai multe scheme, i apoi se folosesc instrumente pentru a converti aceste diagrame n cod. Valoarea acesteia const n faptul c deseori codul este scris automat elibernd programatorul de elaboararea codului, plus tranziia de la design

la faza de implimentare este mai simpl i mai rapid. Mai mult ca att folosind generarea codului, proiectantul se poate mica n cod i ntre cod i design care este exprimat prin diagrame. Ca limbaj de specificare ne permite specificarea tuturor soluiilor importante care se refer la analiza, proiectarea i realizarea n procesul elaborrii i dezvoltrii construirea modelelor fixe i complete. Ca limbaj de construire cu toate c UML nu este limbaj de programare vizual (UML n primul rnd este un mijloc de descriere) dar ne permite ca toate modelele elaborate n baza lui s fie traduse automat n diverse limbaje de programare ca: Java, ANSI, C++. Practic toi productorii mondiali ai mijloacelor CASE au anunat despre susinerea UML n versiunile urmtoare ale lui. Deja azi exist multe mijloace CASE ce automatizeaz procesul analizei i proiectrii n UML (Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic i altele), susin multe limbaje de programare C++, Java, Delphi, Power Builder, Visual Basic, Centura, Forte, Ada, Smalltalk, de asemenea permite generarea bazelor de date pentru majoritatea SQL-serverelor. Modelele, elaborate n UML, permit simplificarea considerabil a procesului de codare i transferul nemijlocit al eforturilor programatorilor asupra sistemului. Diagramele mresc caracteristicile proiectului i uureaz procesul desfurrii documentaiei sistemului soft. UML este limbaj de modelare independent de platform, se abstractizeaz de specificul limbajelor de programare concrete i mijloacele lor de dezvoltare etc. UML mai este necesar:

produselor soft adic

conductorilor de proiecte, care conduc cu gestionarea sarcinilor i controlul asupra proiectului; proiectanilor sistemelor informaionale, care dezvluie sarcini tehnice pentru programatori; business analitilor, care cerceteaz sistemul i care administreaz afacerile unei companii; programatorilor care efectueaz modulele sistemului informaional.

Fiind un instrument orientat pe obiecte de modelare Rational Rose se bazeaz pe UML, care a fost elaborat cu scopul de a crea un limbaj mai optimal i universal pentru descrierea att a domeniului de obiecte ct i pentru probleme concrete de programare. Una dintre proprietile cele mai importante ale Rational-Rose se consider arhitectura accesibil, ceea ce permite de a completa instrumentele existente cu noi funcii.

Rational Rose este un instrument pentru crearea i modelarea sistemelor informaionale, deci poate fi utilizat pentru crearea unui sistem informaional definitivat sub form grafic i n form de cod. Rational Rose este o resurs orientat pe obiecte de proiectare capabil de a modela situaii de orice dificultate: de la proiectul unui sistem bancar pn la elaborarea codului n diverse limbaje de programare: C++, Delphi, Java etc. Modelarea bazei de date n Rational-Rose ofer urmtoarele posibiliti: 1. Corespunderea dintre structurile orientate pe obiecte i modelul de date permite urmrirea transformrii modelului obiectului n modelul bazei de date. Aceast form de corespundere permite analiza legturii dintre aplicaiile i bazele de date i nnoirea lor pe baza schimbrilor efectuate n procesul elaborrii. 2. Proiectarea direct i invers a modelului de date i a bazei de date permite crearea modelului de date bazat pe structura bazei de date prin proiectarea direct sau invers, schema poate fi generat vis a vis de baza de date sau salvat ca script pentru utilizarea ulterioar. Ea va conine tabele, coloane, limite, indeci, triggere, etc.
3.

Integritatea referenial pstreaz integritatea bazei de date datorit transferului automat al cheilor primare ale tabelelor principale n tabele dependente, cnd referina este creat s aleag cum s asigure integritatea referenial: sau prin trigger sau prin integritate declarativ.

Rational-Rose spre deosebire de alte resurse de acest tip de proiectare e capabil de a proiecta sisteme de orice complexitate, adic programul permite att redarea la nivel nalt (abstract) (de exemplu schema automatizrii unei ntreprinderi), ct i la nivel jos (interfaa unui program, schema unei baze de date). Modelarea se bazeaz pe nou (unsprezece) diagrame care n funcie de situaie sunt capabile s descrie diverse aciuni. La modificarea sistemului aspectul obiectual permite uor de a include n sistem obiecte noi i de a le exclude pe cele vechi fr schimbul esenial al ciclului de via. Folosirea modelului construit, n timpul modificrii sistemului, permite de a elimina consecinele nedorite ale schimbrilor, deoarece ele nu distrug structura stabil a sistemului, ci numai schimb comportamentul obiectelor. Sfera de aplicare a limbajului UML nu se limiteaz doar la modelarea produsului soft, experimentarea lui permite modelarea documentelor n sistemele juridice, modelarea structurii i funcionrii sistemelor de deservire a pacienilor n spitale, la proiectarea unor mijloace de aparataj. Pentru a nelege limbajul UML e necesar de neles modelul conceptual al lui, care include n sine trei pri principale: blocurile principale de construire ale limbajului (sistemul de notaii grafice),

regulile de mbinare i unele mecanisme principale eficiente pentru tot limbajul n ntregime. Cunoscnd aceste lucruri, nu doar c vei putea citi modelele n limbajul UML, ba chiar vei crea altele noi. Sistemul de notaii grafice O consideraie important n modelarea vizual este alegerea notaiilor grafice ce vor fi folosite pentru reprezentarea variatelor aspecte ale unui sistem. Aceast notaie trebuie s fie convenit de toate prile interesate n caz contrar modelul nu va fi de folos. Muli au propus notaii pentru modelarea vizual. Schemele-bloc reprezint n sine o minune a simplitii. nsemnrile grafice convenionale descriu pe deplin paii necesari pentru a ncheia o aciune sau alta. Procesele se aeaz n consecutiviti logice clare, care fac ca schemele-bloc s reprezinte un mijloc excelent de redare a unei sarcini de afacere i simplific codificarea aplicaiilor. Spre exemplu, n schemele bloc uor se observ legtura etapelor predecesoare cu cele succesoare. n acelai timp descrierea fiecrei aciuni necesit o cantitate de detalii, astfel nct ea poate fi conceput ca un proces aparte. Nu e greu de observat c la construcia unei scheme bloc se atrage mult atenie descrierii situaiilor comune (de exemplu imposibilitatea accesului la o baz de date). Nivelul necesar de detaliere complic descrierea proceselor, nedorind se ajunge la greeli i neclariti. Dezvoltarea de mai departe a fost condiionat de aspectul obiectual orientativ. Creatorii de soft au primit o concepie care reflect viaa real. Lumea e compus din obiecte. Fiecare din ele avnd atribute i comportament propriu. Limbajele orientate pe obiecte permit determinarea elementelor de conducere, responsabile de comportamentul unui sau altui obiect. Tehnologiile orientate pe obiecte permit elaboratorilor s reprezinte obiectele ca o totalitate de date i funcii, ridicnd prin aceasta proiectarea la un nou nivel calitativ. Programatorii pot elimina din codul programului fragmentele de operaii tipice ce se repet, nlocuindu-le cu descrierea fiecrui obiect. Datorit arhitecturii care face ca funciile i elementele de conducere s fie public accesibile, totodat ascunznd codul care le creaz, creatorii pot utiliza obiectele neavnd idee despre structura lor interioar. n rezultat, la scrierea codului, programatorul se poate concentra la sarcinile reale ale sistemului, excluznd nevoia de a cunoate structura interioar a obiectelor. Odat cu apariia tehnologiei orientate pe obiecte a aprut necesitatea n mijloace instrumentale care permit de a primi o descriere mai complex dect prin simplele scheme bloc. Programatorilor le sunt necesare instrumente care s le creeze nchipuirea vizual a proceselor. n anii 90 au aprut o serie de metode de dezvoltare a aplicaiilor, fiecare dintre acestea introducnd notaii (grafice sau formale) particulare. Printre cele mai populare metode se numrau

notaiile OMT (Object Modeling Technique James Rumbaugh ), OOD (Object Oriented Design Greedy Booch) i OOSE (Object-Oriented Software Engineering) Ivar Jacobson. Fiecare dintre aceste metode aveau puncte tari i slabe. OMT era potrivit pentru etapa de analiz, OOD pentru etapa de proiectare, iar OOSE avea n vedere n special etapa de analiz comportamental. Anii 90 sunt caracterizai de aa-numitul 'rzboi al metodelor', n care fiecare dintre autori (numii i guru) ncerca s impun propria metod de analiz i proiectare a aplicaiilor. Rational Rose suporta toate aceste trei notaii; totui, UML este standardul care a fost adoptat de majoritatea industriei ca i ANSI i OMG( Object Management Group). Blocurile constructive n UML n limbajul UML sunt incluse trei tipuri de blocuri de construcie: 1
2

Entitile Relaiile Diagramele Entitile sunt abstracii ale principalelor elemente din model. Relaiile fac legtur dintre

diferite entiti, pe cnd diagramele grupeaz ansamblurile de entiti pe interese. Entitile Entitile sunt unicele blocuri orientate obiectual n UML. n UML sunt patru tipuri de entiti: 1 2 3 4 Structurate Comportamentale De grup De adnotare Entitile structurate sunt numite substantive n model care de obicei reprezint prile statice, care corespund elementelor conceptuale sau fizice ale modelului. Sunt prevzute apte tipuri de entiti structurate:

Clasa (Class) reprezint descrierea ansamblului de obiecte cu atribute comune. Clasa realizeaz una sau mai multe interfee. Clasa are nume (Casete), atribute (Seria, Mrimea, Timecod), precum i operaii (de inserare, de tergere i de modificare).

Interfaa (Interface) reprezint un ansamblu de operaii, care determin setul de servicii, pe care poate s le asigure respectiva clas sau component. Astfel interfaa descrie componentul vzut din exterior. Interfaa determin numai specificarea operaiei semantice, dar nici o dat executarea operaiei. Grafic interfaa este reprezentat n form de un cerc. Numele interfeei se afl n partea de jos a cercului. Interaciunea (Collaboration) reprezint prin sine ansamblul de roluri i de alte elemente care funcioneaz mpreun producnd un oarecare efect de colaborare. Interaciunea, aadar, are aspect att structural ct i de comportament. Una i aceeai clas poate s participe n mai multe interaciuni. Astfel ea realizeaz imaginea de comportament, care la rndul su formeaz sistemul. Grafic interaciunea este reprezentat n form de o elips care este alctuit dintr-o linie ntrerupt, iar n mijlocul ei de obicei se scrie numai numele interaciunii.

Precedentele (Use case) reprezint o descriere, o succesiune de aciuni pe care le efectueaz sistemul i produce rezultatul urmrit important pentru un oarecare actor. Ele se folosesc pentru structurizarea entitilor comportamentale i se realizeaz prin intermediul cooperrii. Grafic precedentul este reprezentat printr-o elips. Urmtoarele trei entiti descriu totalitatea obiectelor cu ajutorul atributelor, operaiilor, relaiilor i a semanticii. Dar totui ele n bun msur difer una de alta i au o mare importan la modelarea sistemelor obiect-orientate trebuie atras atenia fiecrei n parte. Clasele active (Active class ) sunt clasele obiectele crora sunt atrase n una sau mai multe proceduri, sau fire (Threads), i de aceea ele pot s iniieze aciuni de gestionare (comand). Clasa activ seamn cu clasa obinuit, cu excepia c obiectele ei reprezint elemente, aciunile crora se efectueaz paralel cu alte elemente. Reprezentarea grafic e aceeai ca i la clasa obinuit care const dintr-un dreptunghi i la fel are nume, atribute i operaii. ns diferena const n conturul liniei groase ce contureaz dreptunghiul.
New Component

Componentele (Component) reprezint prile fizice ale sistemului, care corespund unui set de interfee i asigur realizarea lor. n sistem se pot ntlni aa fel de componente ca COM sau Java, chiar i componentele care sunt artefactele procesului de elaborare, de exemplu fiierul cod. Componentele de regul reprezint prin sine o cutie fizic, care conine elemente logice, aa ca clasele, interfeele i cooperrile.

Ne w De vice

Nodurile (Node) reprezint un element fizic real al sistemului, care exist n timpul funcionrii complexului de programe, i reprezint prin sine resurse de calcul, care de obicei deine minimum un oarecare volum de memorie, dar mai des i posibilitatea de prelucrare a informaiei. Grafic nodurile sunt reprezentate n form de cub, ce conine doar numele. Aceste apte elemente de baz clasele, interfeele, cooperrile, precedentele, clasele active, componentele i nodurile sunt entitile principale, care pot fi incluse n modelele UML. Exist diferite modificri ale acestor entiti de structuri: actori, semnale, utilite, procese i fire, aplicaii, documente, fiiere, biblioteci, pagini i tabele. Entitile de comportament (Behavioral things) sunt componente dinamice ale limbajului UML i sunt verbe care descriu comportamentul modelului n timp i spaiu. Exist doar dou tipuri de entiti de comportament: interaciunea i automatul. Interaciunea (Interaction) reprezint comportamentul esena cruia const n schimbul de mesaje (Messages) dintre obiecte n cadrul unui context concret, pentru atingerea scopului dorit. Cu ajutorul interaciunii se poate descrie att o operaie aparte, ct i comportamentul unui ansamblu de obiecte. Ea propune un alt set de elemente, aa ca comunicarea, consecutivitatea faptelor i legturilor. Reprezentarea grafic a interaciunii are forma unei sgei deasupra creia este scris numele operaiei corespunztoare .
Nu exi sta seri a

Automatul (State machine) reprezint prin sine un algoritm de comportament, care determin succesiunea strilor prin care trece obiectul sau interaciunea pe tot parcursul ciclului de via. De asemenea pot fi i reacii de evenimente. Cu ajutorul automatului se poate descrie comportamentul unei clase aparte sau a unui grup de clase. Ele au legturi i cu alte elemente ca: starea, tranziii, evenimente i tipuri de aciuni. Grafic starea este reprezentat printr-un dreptunghi cu muchiile rotungite ce conine numele i posibil substarea. Automatele i interaciunile sunt unicele entiti de comportament, care intr n modelul limbajului UML. Schematic ele deseori sunt legate cu diferite elemente de structur i n primul rnd cu clasele, cooperrile i cu obiectele.

Entitile de grup sunt prile organizatorice ale modelelor limbajului UML. Acestea sunt blocurile pe care se bazeaz modelul. Exist numai o singur esen de grup i anume Pachetele.
NewPackage

Pachetele (Packages) reprezint prin sine un mecanism universal de organizare a elementelor n grup. Pachetul poate conine entiti de structur, de comportament chiar i alte tipuri de entiti de grup. n comparaie cu alte elemente, care exist pe parcursul lansrii programului, pachetul poart un caracter conceptual, adic exist numai n timpul elaborrii. Exist i diferite variaii ale pachetelor de exemplu ca: carcasa (Frameworks), modele i subsisteme. Esene de adnotare reprezint un model de comentariu. El se folosete pentru descrierea, explicarea sau pur i simplu pentru notie la orice element al modelului. Exist numai un singur tip de baz de adnotare acesta e comentariul (Note).
Note

Comentariu pur i simplu reprezint un simbol de marcare a notielor sau a restriciilor, anexate la un element sau un grup de elemente. Grafic comentariul este reprezentat sub forma unui dreptunghi cu colul din partea dreapt de sus ndoiat n interior. Acest element este unica esen de notare care poate fi inclus n modelele UML. Cel mai des comentariile se folosesc pentru a nsoi diagramele cu comentariu sau cu restricii, care se poate de reprezentat prin text formal sau neformal. Exist variaii ale acestui element, de exemplu cerinele, n care este descris comportamentul dorit din punctul de vedere exterior al modelului. Relaiile n limbajul UML sunt definite patru tipuri de relaii:
1 2 3 4

Dependene Asociaii Generalizri Realizri

Aceste relaii sunt unicele relaii ce leag blocurile de construcii n UML i se folosesc pentru crearea modelelor corecte.

Dependenele (Dependency) reprezint o relaie semantic ntre dou entiti, n care schimbarea uneia dintre ele poate s provoace schimbarea celei de-a doua esen dependent. Grafic dependena este notat printr-o sgeat punctat .

Asociaiile (Association) reprezint o relaie structurat, care descrie un ansamblu de legturi, iar prin legturi se subneleg legturile dintre obiecte. Exist i alte tipuri de asociaii. Una din cele mai rspndite este Agregarea (Aggregation). Astfel se numete relaia structurat dintre partea ntreag i prile ei componente. Reprezentarea grafic a asociaiei este efectuat printr-o linie dreapt, cte o dat se poate termina cu o sgeat fiind completat cu semnificaii specifice suplimentare, de exemplu, 0..1 arat multiplicitatea, lucrtor, patron numele rolului i * arat c e patron.

Generalizrile (Generalization) reprezint un raport dintre specializare i generalizare, adic cnd un obiect al unui element specializat (urma) poate nlocui un alt element generalizat (printe). n aa mod urmaul (Child) motenete structura i comportamentul printelui su (Parent). Grafic generalizarea este reprezentat printr-o sgeat transparent i care indic spre printe .

Realizarea (Realization) reprezint un raport semantic dintre clasificatoare, unde un clasificator determin contractul, iar altul asigur ,,ndeplinirea lui. Cel mai des realizrile se ntlnesc n dou cazuri: 1. 2. ntre interfee i componentele care le realizeaz; ntre precedente i componentele care le realizeaz;

Grafic realizarea este descris sub form de o sgeat triunghiular transparent ntrerupt . Aceste patru relaii descrise mai sus sunt unicele tipuri de relaii pe care le putem folosi n UML. ns mai exist i abateri referitor la aceste relaii, de exemplu: precizri (Refinement), calea (Trace), includerea i lrgirea (pentru dependene). Diagramele UML n UML sunt diverse tipuri de diagrame de baz, care sunt necesare unui proiect, pentru a fi neles din toate perspectivele. Astfel, cu ajutorul diagramelor noi crem modelul sistemului, dnd

de neles altora ce dorim s elaborm de fapt. Apoi dup construirea diagramelor folosim un soft special pentru a genera codul din diagrame. Diagramele n UML sunt reprezentrile grafice ale unui set de elemente, cel mai des descriu legturile unui graf unde vrfurile sunt entitile, iar muchiile sunt relaiile. Diagramele reprezint sisteme din mai multe puncte de vedere. n oarecare msur, diagrama reprezint una din proieciile sistemului. Diagramele redau o imagine strns a elementelor din care este alctuit sistemul. Unul i acelai element poate s fie prezent n orice diagram, sau aproape n toate, ori de loc (foarte rar). Teoretic diagramele pot conine orice numr de combinaii de entiti i de relaii. n practic sunt folosite comparativ o parte mic de diagrame, care alctuiesc arhitectura sistemului. UML permite elaborarea a cel puin nou tipuri de diagrame: diagrama claselor, obiectelor, precedentelor, succesiunilor, interaciunii, de stare, de aciune, componentelor, de desfurare. Limbajul UML nu e o simpl totalitate de rezolvri alternative. Concepia sa,difer esenial de tehnologiile vechi. n loc s ilustreze prile izolate ale procesului, UML prefer diagramele de nivel superior, ce permit de a ascunde detaliile i de a concentra atenia asupra particularitilor funcionale i nu pe traiectoria aciunilor. Acest aspect permite de a crea la nceput o impresie general asupra aplicaiei, apoi detaliile precezndu-le pe parcurs. Fiecare diagram folosit n UML permite aprecierea proceselor sub unghiuri diferite. Diagrama variantelor de utilizare prezint aciunile reciproce dintre variantele posibile de utilizare i personaje sau sisteme. Diagramele reflect cerinele fa de sistem din punctul de vedere al utilizatorului. n aa mod variantele de utilizare sunt funciile efectuate de sistem, iar persoanele snt persoane cointeresate de sistemul elaborat. Diagrama arat c persoana iniiaz varianta diagramei de utilizare. La fel din ea se vede c persoanele cointeresate primesc date de la varianta de utilizare. Din diagrama variantelor de utilizare se poate afla mult informaie coninut n sistem. Acest tip de diagrame descrie funcionarea sistemului la general, iar utilizatorii, managerii proiectrii analitice, specialiti i toi cei cointeresai n sistemul dat pot s neleag sistemul studiat. Limbajul UML se bazeaz pe abordarea obiect-orientat i include diagrama claselor pentru descrierea structurii si consistena modelului. Diagrama claselor este de baz pentru formarea modelului aplicaiei i joac rolul principal n lucrul cu unele medii de dezvoltare. Diagrama claselor i obiectelor descrie starea static a elementelor n sistem n fiecare moment concret, arat structura obiectelor, atributele lor, legturile reciproce. Specialitii folosesc diagrama claselor i obiectelor pentru a nelege cum pot include componentele date n codul lor. Diagrama claselor i de stare (pentru sisteme n timp-real) sunt foarte importante pentru generarea codului.

Diagramele de aciune reflect fluxurile conductoare, care vin de la o aciune la alta. Consecutivitatea i legturile reciproce oglindesc procesele interactive: se vd nu numai obiectele i clasele ci i mesajele cu care comunic. n aa fel cu ajutorul sistemului se pot modela situaii folosind tehnologia ce dac. Diagramele de stare se utilizeaz pentru descrierea obiectelor dinamice ce transmit i primesc mesaje. i diagramele componentelor i amplasrii snt destinate pentru nchipuirea fizic a sistemului (inclusiv modulele folosite, biblioteci i interfee). Elaborarea diagramelor nc nu nseamn analiz i proiectare. Diagramele ne permit s descriem comportamentul sistemului (pentru analiz) sau prezentarea detaliilor arhitecturale (pentru proiectare). Una din cele mai importante tendine n lumea UML este stereotipizarea. Aceast metod permite extinderea vocabularului fundamental al UML. Utiliznd blocurile de construcie n schema UML se poate obine un nou cod ce descrie procese concrete. Codul stereotipic se folosete pentru identificarea fiierelor executabile i fizice, pentru crearea i distrugerea exemplarelor claselor, pentru generarea programelor trigger, ce reacioneaz la apariia unui eveniment. Programatorii pot lega pictogramele de stereotipurile pentru modificarea modelului UML, innd cont de particularitile operaiilor specifice. Pachetele instrumentale UML (spre exemplu Rational Rose) conin mijloace instrumentale ce uor permit crearea modelelor UML i generarea codului n diferite limbaje de programare. Majoritatea pachetelor arat informaia detaliat despre obiectul ales. E necesar numai un click pe pictograma lui. Intrnd n comand, se observ setul de operaii ce se pot efectua asupra obiectului i se observ diagrama de aciuni consecutiv. Limbajele de modelare servesc i pentru proiectarea invers a sistemelor deja existente. Deci, limbajul UML propune un set de instrumente, ce permit analiza proiectelor complexe din mai multe puncte de vedere, att din punct de vedere tehnic, ct i din punctul de vedere al necesitii businessului. Limbajul dat simplific procesul de proiectare, micoreaz cheltuielile i mrete eficiena. Concepia UML permite programatorilor s determine metodele aplicaiilor complicate tehnic, care se vor efectua ntr-un mediu multinivel.

Analiza exemplului elaborrii modelelor serviciului bancar pentru clieni (ATM) Diagrama variantelor de utilizare (Use Case) - Diagrama ce descrie sistemul ca un tot ntreg, integru. Aici se conin actori (care execut anumite roluri, funcii) i precedente (funciile propriuzise ce pot fi obinute) i relaii dintre actori.

t a se r nf r

d p z ae e o it r sh br P c imae I N c n lie t oit rb n a f e ac r

d c nae eo t r p t laa v r ic r b n eif ae ila t s d ce it is e r d

Fig.1.3. Diagrama precedentelor pentru ATM Aceast diagram arat interaciunea dintre precedentele i actorii unui sistem ATM (Automated Teller Machine). Sgeata care vine de la precedent la un actor arat c precedentul produce o informaie pe care o folosete actorul. Analiznd diagrama precedentelor putem obine mult informaie. Utilizatorii, managerii de proiect, analitii, inginerii ce asigur calitatea, orice persoan care este cointeresat n sistem ca un ntreg poate analiza diagrama i nelege ce trebuie s realizeze sistemul. Diagrama de activiti - descrie cursul functionalitii sistemului. Poate fi folosit pentru a ilustra cursul evenimentelor printr-un precedent. Acest diagram definete unde ncepe cursul lucrului i unde se sfrete, ce activiti au loc pe parcursul lucrului, i n ce ordine au loc activitile.
otn i f r ae b en mi i o t ds r cet ep l n ei

cer a ni r a uu e c nnu ot o

cn ot

s t r lm d e ei i a e a t cei rd t

r v ues r ei ir i t ie z o dc d er i et cn ot r s in ep s cn ot ac p t cet a sm r ene a dcm t ou e e n

Fig.1.4. Diagrama de activiti pentru deschiderea unui cont n aceast diagram putem observa cursul obiectelor. Cursul obiectelor ne arat ce obiecte sunt folosite sau create de o activitate i cum obiectul i schimb starea parcurgnd cursul de lucru. Liniile se numesc tranziii, ele arat modul n care o activitate pleac la alta n proces. Dac este nevoie putem plasa mai multe detalii pe tranziii, descriind circumstanele sub influena crora tranziia poate sau nu poate avea loc i ce aciune va fi luat n timpul tranziiei. Nu e nevoie de creat diagrama de activiti pentru orice curs de lucru n parte, ele (diagramele de activiti) fiind un puternic instrument de comunicare, n special n cursul de lucru mare i complex. Diagrama de secven - arat cursul funcionalitii ntr-un precedent. De exemplu, precedentul decontare are cteva secvene posibile, decontare, ncercarea de a deconta fr bani

disponibili, ncercarea de a deconta cu PIN greit, i multe altele. Scenariul normal de decontare a 20$ (fr nici o problem) este artat n fig.5.
clie t n acce ta ca p rd c ste n ca ite r rd in itializ re e a cran d sch e con e id t c ere P IN in du PN tro ce I ce tra z re n actia se lecta tra z ctie re n a cere su a m in d ce c tita a tro u an te d c ta e on re v rifica b n e r ai ex ge tra d istribu ca ie sh distrib iece u c sco tere ca a rd v rific PN e a I card re de a r A Me n T cra co t n em to b n ita r a i

Fig.1.5. Diagrama de secven Aceast diagram de secven arat cursul procesrii ntr-un precedent Decontare. n diagrama de sus sunt obiectele de care are nevoie sistemul pentru a realiza precedentul Decontare. Fiecare sgeat reprezint un mesaj transmis ntre actori i obiect sau obiect i obiect pentru a ndeplini funcionalitatea necesar. Utilizatorii pot vedea n aceste diagrame specificul procesrii afacerii. Analitii vd cursul procesrii. Dezvoltatorii vd obiectele ce trebuie create i operaiile pentru aceste obiecte. Inginerii ce asigur calitatea pot vedea detaliile procesului i dezvolta teste pentru procesare. Diagrama de colaborare - arat exact aceeai informaie ca i cea de secven. Totui, Diagrama de colaborare arat aceast informaie n alt mod i cu un scop diferit. Diagrama din fig.6 este o diagram de colaborare.

6 in d c PN : tro u e I 9 s le ta tra z c : e c re n a tie 1 : in d c c n te 1 tro u e a tita a

AM T e ra c n

c n lie t

5 c rePN : e I 8 c retra z c : e n a tia 1 : c re s m 0 e u a 3 in liz re e ra : itia a c n 1 a c p c rd : c e ta a 2 c s n c rd : ite te r a

7 v rific P : e a IN 1 : d c n re 2 e o ta 1 : v rific r b n 3 e a ai 1 : e tra e 4 x g

4 d s h ec n : e c id o t c rd a re d r ae

cn ot

1 : s o te c rd 7 c a re a 1 : d trib iec s 5 is u a h 1 : d trib iec c 6 is u e

e ita r m to bn ai

Fig.1.6. Diagrama de colaborare pentru decontarea 20$ de pe cont Diagrama claselor - arat interaciunea dintre clase n sistem. Clasele pot fi privite ca nite prototipuri pentru obiecte. Clasele conin informaie i comportament care conduce cu aceast informaie.
cr r a r a ee d d na r r cd a ea cr ( c pr a ) ct e d s a cr ( ct a) oe d c s cr ( ieea ) t t d A ea T cn Mr cr ( e) e a ea ta a c p i rr ( c t n e)

cn o t no r n ct P I N bn ia l t d cd ) e he si ( d oa ( e nr ) ct e s a b i) c t a( oe n v ii ao( e c cn r f t) eiar a mo n tt b i b na ia cs l t h dti u cs ) i r i a( s be h dti u cc i r i e) s be (

Fig.1.7. Diagrama claselor pentru sistemul ATM precedentul Decontare bani Liniile ce conecteaz clasele arat relaiile dintre ele. De exemplu, clasele Cont i ATM ecran sunt conectate pentru c comunic direct ntre ele. Dezvoltatorii folosesc diagramele claselor pentru a le dezvolta. Instrumente precum Rational Rose genereaz scheletul codului pentru clase, dezvoltatorii introduc detaliile n limbajul ales de ei. Analitii folosesc diagramele claselor pentru a arat detaliile sistemului. Arhitecii se uit la diagramele claselor ca s neleag structura sistemului. Un arhitect cu ajutorul diagramei claselor poate vedea dac aceasta conine prea mult informaie i poate mpri functionalitatea n clase multiple. Diagrama de stare - distribuie un mod de modelare variat a strilor n care un obiect se poate afla. n timp ce diagrma claselor arat imaginea static a claselor i relaiilor dintre ele,

diagrama de stare este utilizat la modelarea comportamentului dinamic al sistemului. Aceste tipuri de diagrame sunt folosite extensiv n construirea sistemelor n timp-real. Rational Rose poate chiar genera codul ntreg pentru un sistem n timp-real din diagramele de stare. O diagram de stare arat comportamentul unui obiect. De exemplu, un cont bancar poate exista n cteva stri diferite. Un cont se poate comporta diferit cnd este n fiecare din aceste stri.
d c nae b n 0] e o t r [ ila t < d sh e e c id c ng l ot o

cr r d eee e in h eea c id r c nu i lie t lu

d p s [b n< ] e o it ila t 0

v ric r b a t b n 0p n u3 ze] ef ae il n[ ila t < e t 0 il r

in h c is

Fig.1.8. Diagrama de stare pentru clasa Cont n aceast diagram putem observa strile n care se poate afla contul. Chiar putem vedea cum contul trece dintr-o stare n alta. De exemplu cnd contul este deschis i clientul cere nchiderea contului, contul trece n starea nchis. Cererea clientului este numit eveniment, iar evenimentul este ceea ce cauzeaz tranziia. Condiia din paranteze ptrate se numete condiie de gard i controleaz cnd o tranziie poate sau nu poate avea loc. De asemenea sunt dou stri speciale - starea nceput i starea sfirit. Diagrama de stare se creaz numai pentru clase complexe. ns multe proiecte nu au nevoie de astfel de diagrame. Diagramele de stare sunt create doar pentru documentare. Diagrama componentelor - arat viziunea fizic a modelului, adic componentele software n sitem i relaiile dintre ele. Sunt dou tipuri de componente executabile i biblioteci.
AMx T. e e

n diagram:

cr r ae a edr d

d ti uocs i rbi r ah s t

d ti uocs is bi r ah r t AMc n T er a c r r ae a edr d

AMc n T er a

Fig.1.9. Diagrama componentelor pentru ATM client

Componentele haurate sunt numite corpul pachetului. Ele reprezint corpul fiierului (.cpp) a clasei ATM ecran n C++. Componentele nehaurate sunt numite specificaia pachetului. Specificaia reprezint fiierul antet (.h) n C++. Componenta ATM.exe este numit specificaia sarcinii i reprezint un fir de execuie. n acest caz, firul de execuie este programul executabil. Componentele sunt unite prin sgei ntrerupte artnd relaiile de dependen dintre ele. Diagramele componentelor sunt folosite de responsabilii de compilarea sistemului. Diagramele indic ordinea n care componentele necesit a fi compilate. Diagrama de amplasament arat schema fizic a reelei i unde vor fi amplasate diferite componente variate. Aceast diagram este folosit de managerii de proiect, utilizatori, arhiteci, i echipa de amplasament pentru a nelege amplasamentul fizic al sistemului i unde vor fi amplasate variate subsisteme. Toate aceste diagrame mpreun descriu sistemul din diferite perspective. Deci, aceste diagrame sunt foarte importante n modelarea vizual a sistemelor. UML este un limbaj foarte puternic dac este folosit de persoane, echipe bine familiarizate cu el i cu modelarea vizual. Instrumente ca Rational Rose pot genera scheletul codului proiectului sau invers poate genera diagramele din cod (Re-Engineering). Pachetele instrumentale UML (spre exemplu Rational Rose) conin mijloace instrumentale ce permit uor crearea modelelor UML i generarea codului n diferite limbaje de programare. Majoritatea pachetelor arat informaia detaliat despre obiectul ales. E necesar numai un click pe pictograma lui. Intrnd n comand, se observ setul de operaii ce se pot efectua asupra obiectului i se observ diagrama de aciuni consecutiv. Limbajele de modelare servesc i pentru proiectarea invers a sistemelor deja existente. UML se dezvolt n continuu, de exemplu, n versiunea 1.3 s-au inclus o serie de mbuntiri, la care se refer noile construcii semantice, citirea perfecionat a documentelor i de asemenea susinerea interfeei XMI (XML Metadata Interchange). S-au exclus erorile detectate anterior. Mai departe creatorii intenioneaz s propun interfee pentru tehnologiile CORBA, Enterprise JavaBeans i XML, mijloace de control asupra versiunilor modelelor i schimbul reciproc cu diagrame. ntrebri de control: 1. Care sunt elementele componente ale tehnologiei proiectrii? 2. Descriei etapele elaborrii tradiionale ale produselor software. 3. Care sunt etapele metodologiei spiral?

4. Ce numim polimorfism? 5. Ce aduce nou limbajul UML? 6. Descriei principalele blocuri constructive din UML. 7. Caracterizai toate tipurile de diagrame folosite n UML.

LUCRAREA DE LABORATOR NR. 2 TEMA: Analiza sistemului n baza metodologiei APOO i elaborarea modelelor prin

diagramele cazurilor de utilizare n mediul Rational Rose i dezvoltarea lor n alte diagrame Scopul lucrrii: 1. Studierea prii teoretice i verificarea cunotinelor nsuite pentru modelarea sistemului dat n mediul instrumentului CASE Rational Rose. 2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea, destinaia elementelor i modelarea precedentelor cu use case diagram (cu perspectiva dezvoltrii n Sequence i Collaboration) din Rational Rose. 3. Reprezentarea structurii sistemului real i analiza n baza metodologiei APOO (etapa planificrii, sincronizrii, analizei), evideniind artefactele, precedentele pentru elaborarea modelului conceptual din domeniul respectiv al sistemului. 4. nsuirea tehnicii de creare, modificare i salvare a respectivelor modele elaborate n diagramele use case ale sistemului real-propus. 5. Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor din meniurile: Browse, Create, Model Properties, TOOLS din Logical View, componentele i operaiile de manipulare (generare, modificare i salvare a modelului). 6. Efectuarea diverselor manipulri n diagrama use case pentru evidenierea tehnicii eficiente. 7. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n procesul efecturii lucrrii de laborator. 8. Dezvoltarea elaborrilor cu alte diagrame (Sequence i Collaboration) pentru diverse modele din domeniul IT n baza limbajului de modelare UML. Sarcina: Pentru un sistem concret realizai cinci diagrame ale precedentelor. Consideraii teoretice generale. Descriere general n ultimul timp o atenie deosebit i se acord alegerii metodologiei dezvoltrii soft-ului. Cum arat experiena, fr o metodologie corect chiar i unele proiecte mici puin probabil pot fi reuite. Astfel tot mai muli dezvoltatori, analiti i conductori de proiecte ncep s contientizeze acest lucru.

Mai nti se formuleaz scopurile, fr care nu este posibil nici un proiect. Sarcina de baz a oricrui proiect reuit const n aceea, ca la momentul pornirii sistemului i pe parcursul ntregii perioade de exploatare s fie posibil de asigurat: funcionalitatea necesar a sistemului i nivelul de adaptare la condiiile schimbtoare ale funcionalitii lui; permitivitatea (rata de transfer) necesar sistemului; timpul de reacie necesar la cererea sistemului; lucrul sistemului fr ntreruperi n regimul stabilit, adic: gradul de pregtire i accesibilitatea sistemului la prelucrarea cererilor utilizatorilor; simplitatea exploatrii i ntreinerii sistemului; sigurana cerut. Randamentul constituie factorul fundamental, care determin eficiena sistemului. O soluie de proiect este baza sistemului de mare randament. n condiii reale proiectarea sistemelor informaionale - este cutarea metodei, care asigur funcionalitatea necesar a sistemului prin intermediul tehnologiilor, lundu-se n consideraie restriciile date. Prin metodologie de dezvoltare se subnelege un ansamblu de metode i criterii de evaluare, care se folosesc pentru formularea sarcinii, planificarea, analiza i modelarea pentru atingerea scopului necesar. nceputul tradiional - n care se precizeaz informaii de baz despre proiect i despre acest sistem. 1. Cercetarea domeniului de interes.
2.

Analiza unde sunt prevzute cerinele, modelul logic (identificarea obiectelor i dinamica legturilor) i static (determinarea detaliat a structurii fiecrui component).

3. Proiectarea generalizarea tuturor obiectelor i crearea claselor ce determin obiectele date, modul de interaciune ntre clase prin intermediul diagramelor de clase. 4. Realizarea determinarea specificrilor, generarea codului n limbajul de programare (C+ +, Delphi etc.).
5.

Implementarea implementarea proiectului. de dezvoltare a Soft-ului se realiza n concordan cu

Un timp ndelungat procesul

metodologiile, obinute n domeniul ingineresc - practica standard a crerii pe etape a produsului, ncepnd cu ntocmirea specificaiior i finisnd cu livrarea la client. Exist standarde (Rusia) i ISO (Europa, Rusia), CMM (Capabity Maturity Model - rspindit n SUA), care reglementeaz procesul dat (de dezvoltare)

Modelul spiral al ciclului de via al sistemului - o atenie deosebit se acord etapelor nceptoare de dezvoltare: elaborarea strategiei, analiza i proiectarea, unde realizarea unor sau altor soluii tehnice se verific i se fundamenteaz prin intermediul crerii, modelrii (prototiturilor, machetare). Fiecare cerc al spiralei presupune crearea unei versiuni a produsului sau careva component a lui. Modelarea vizual este metoda de percepere a diferitor probleme cu ajutorul abstraciilor vizuale, care reproduc noiunile i obiectele lumii reale. Modelul servete drept un instrument comod pentru analiza diferitor probleme, n privina schimbului de informaii ntre prile cointeresate (utilizatorii, specialitii din domenii de interes, analitii, programatorii, e.t.c.), care particip la proiectarea produselor soft, precum i la pregtirea documentaiei corespunztoare. Modelarea conduce la asimilarea mai complet a cerinelor, ridicarea calitii arhitecturii sistemului i a gradului de administrare a acestui sistem. Cu ajutorul modelului problema propus poate fi simplificat, n rezultatul dezicerii de la detalii nesemnificative, adic concentrrii asupra esenialului. Capacitatea de abstractizare este proprietatea fundamental a intelectului uman, care asigur nvingerea fenomenului de complexitate. Pentru a crea un sistem soft complex, proprietile acestuia necesit abstractizare din diferite puncte de vedere. Cu ajutorul unui limbaj de notaii determinat se realizeaz modelul, dup, care se revine la cerinele iniiale fa de sistem, i se controleaz dac modelul corespunde acestor cerine. Dup aceasta modelul se realizeaz practic, i n continuare se extinde cu funcii noi. Notaiile menionate nainte, sunt necesare n orice model deoarece reprezint acele elemente care asigur unificarea proceselor. Notaia realizeaz urmtoarele funcii:

joac rolul unui limbaj, folosit pentru descrierea concluziilor neevidente, care nu reies din codul propriu-zis.

descrie semantica deciziilor strategice i tactice.

asigur o form de reprezentare, destul de concret pentru perceperea de ctre om, i posibilitatea manipulrii acesteia prin intermediul instrumentelor. Un astfel de limbaj este Unified Modeling Language, care cuprinde etapa analizei, ct i cea

de design. Unele elemente ale limbajului (clasele, asociaii i ierarhii de derivare) se folosesc n procesul de analiz, iar altele (elemente de realizare i definirea proprietilor) se introduc n perioada de proiectare. Necesitatea i importana modelrii const n aceea c omul nu poate percepe o problem complex concomitent. Modelarea permite o viziune general asupra relaiilor dintre componentele proiectului ocolind necesitatea analizei proprietilor specifice fiecrui component. n ajutor vine

modelarea care permite, conceperea, organizarea, vizualizarea i construirea celor mai complicate sisteme. Determinarea i definirea scopului proiectului O importan deosebit o are ntrebarea, care trebuie formulat naintea iniierii proiectului, i aceast ntrebare nu atinge sfera metodologic i nici cea tehnic. La prima vedere pare simplu. Pentru unele sisteme poate va fi, simplu, pentru celelalte ns formularea scopului reprezint garania succesului, cci n caz contrar linia de via a proiectului nu va ncepe. Deci ntrebarea sun astfel: Care sistem anume necesit a fi elaborat, i pentru cine?. Procesul formulrii scopurilor viitorului sistem, mpreun cu definirea formei de reprezentare al acestuia, ntocmesc faza ciclului de via a proiectului, care se sfrete cu declararea ce sun astfel: Sistemul care necesit a fi proiectat, trebuie s ndeplineasc . n acest proces sunt implicai nu numai, specialitii care particip la proiectare, dar i reprezentanii (consultaniipotenialii utilizatori) din domeniul de interes pentru care se proiecteaz sistemul. Acetia ajut la analiza specificului domeniului, potenialelor riscuri i avantaje. La nceputul fazei se formuleaz problemele propuse spre rezolvare, i se disting diferite propuneri, unele din ele se accept. Deci aciunile ntreprinse la aceast faz a elaborrii sistemului, pot purta caracter formal sau neformal, dar ele totdeauna trebuie s prevad necesitile reale a businessului, resursele, tehnologiile la moment, i dorinele utilizatorilor. Rezultatul desfurrii eficiente a acestei faze servete la formularea strict a cerinelor fa de calitile tehnologice ale sistemului i condiiile de exploatare. Modelul sistemului Un model este o abstractizare a unui sistem, ntr-un anumit context, pentru un scop bine precizat. Un model capteaz conceptele relevante ale acelui sistem (din punct de vedere al scopului pentru care a fost conceput), ignornd aspectele neeseniale. Conceptele definite se numesc abstractizri, iar tehnica de identificare a acestor concepte se numete abstractizare. Aa cum un sistem complex poate fi descompus n multiple subsisteme i fiecare subsistem poate fi descompus n continuare, pn la elemente primitive (care nu mai pot fi descompuse), un model al unui sistem poate fi, la rndul su structurat pe mai multe nivele, ca modele ale subansamblelor componente. Caracteristicile comportamentului sistemului se fixeaz i se documenteaz cu ajutorul elementelor modelului, care definete funciile produsului (precedente dialog dintre actor i sistem) accesibile utilizatorului, determin mediul sistemului (actorii interacioneaz direct cu sistemul), i relaiile dintre precedente i actori (diagrama precedentelor). Fundamentele modelului

ncep nc de la etapa procesului elaborrii, cnd sunt obiectele active i precedentele, apoi la etapa de planificare, modelul se dezvolt i se extinde prin adugarea unor elemente noi. Modelul conceptual La aceast etap poate fi vorba fie de un model unic, fie de un prim model dintr-un grup, care s constituie punctul de pornire pentru modelele elaborate ulterior, prin modificarea unor elemente sau prin includerea unor elemente noi. Modelul trebuie s reflecte esena sistemului real, fr a include detalii inutile. Precedentele, fiind unele din cele mai importante componente ale modelului conceptual, iniial se deduc din formularea sarcinii, reieind din cerinele fa de sistem. Formal, precedentele reprezint setul de tranzacii, efectuat de sistem, n scopul obinerii unui rezultat, i acest rezultat este nu altceva dect ceea ce ateapt utilizatorul. La depistarea precedentelor sunt utile astfel de ntrebri: Ce fel de probleme trebuie s rezolve sistemul nostru? Poate sau nu, utilizatorul, s vizualizeze, s salveze informaii din contextul sistemului? Care sunt precedentele care garanteaz efectuarea operaiilor n privina informaiei, din ntrebarea pus anterior? La elaborarea unui sistem e necesar de a se ine cont de urmtoarele etape, prevzute conform metodologiei APOO (analiza i proiectarea orientat - obiectual): etapa de elaborare: -

planificarea sincronizarea analiza proiectarea construirea testarea

etapa de ntreinere:
-

nvarea utilizarea modificarea reutilizarea

Etapa de ntreinere se parcurge doar dup implementarea sistemului, deaceea n lucrare se va analiza (parcurge) doar etapa de elaborare.

Planificarea include evidenierea noiunilor, surselor iniiale ale domeniului de obiecte, formularea cerinelor, obinerea schiei modelului conceptual. Artefactele. Artefactele este denumirea simpl pentru diferite tipuri de informaii create, schimbate de colaboratori la crearea sistemului. Drept exemple de artefacte pot servi diagramele limbajului de unificare i modelare. Se pot enumara 2 tipuri principale de artefacte tehnice i de conducere. n timpul elaborrii programelor se creaz i artefacte de conducere. Unele artefacte de conducere triesc un timp scurt, doar n timpul de via al proiectului. Din ele fac parte busness planul, planul de elaborare, planul de selectare a cadrelor i mprirea tipurilor de activitate ale angajatului n colaborare cu planul. Aceste artefacte se caracterizeaz ca text sau diagrame n orice izvor de vizualizare necesare pentru explicarea cerinelor date echipei de elaborare i oamenilor interesai. Artefactele de conducere la fel includ specificarea cilor de elaborare, a programului pentru automatizarea procesului de elaborare a platformelor de calculatoare, necesare pentru elaborarea i pstrarea artefactelor tehnice. n fiecare caz al procesului raional unificat sunt artefacte care sunt date la intrare sau se primesc la ieire. Artefactele se folosesc ca date de ieire pentru activitatea ulterioar, conin date, dicionare despre proiecte i au rolul de primire a contractului de baz. O parte din prezentrile arhitecturale sunt prezentrile modelelor precedentelor, ce sunt necesare pentru arhitectura precedentelor. La ele se refer precedentele care descriu capacitatea funcional important, ndeosebi se realizeaz cele mai importante cerine, sau una i alta. Arhitectura unui sistem informaional include o interfa grafic i legatura cu bazele de date n cteva nivele. Arhitectura unui sistem trebuie s posede urmtoarele caliti: s prezinte prin sine un sistem abstract pe mai multe nivele de prezentare; interfaa abstraciilor la orice nivel este restrns de la realizare, ns relizarea se poate arhitectura s fie simpl: se folosesc abstracii, mecanisme comune etc. Elaborarea sistemului trebuie s fie iterativ, elaborarea iterativ reprezint modificarea multipl a sistemului n decursul cruia el se mbuntete la orice etap. Cerinele fa de sistem pot rmne neschimbate pentru cteva cicluri, dar pot fi i concretizate de la un ciclu la altul. n procesul iterativ de elaborare se mresc posibilitile funcionale ale sistemului, fiecare din versiunile lui realiznd noi i noi funcii.

efectua fr a se schimba interfaa;

Specificarea cerinelor pentru realizarea proiectului : 1. Utiliznd APOO e necesar s se modeleze un sistem de calcul i anume fazele: pregtirea sistemului de lucru i ndeplinirea de ctre sistem a unei comenzi. 2. Proiectul va fi modelat prin intermediul limbajului UML. 3. Proiectul e necesar s fie fiabil, flexibil i eficient (s permit cu uurin efectuarea modificrilor). Analiza cerinelor i modelarea sistemului. Programul unui sistem elaborat, se bazeaz pe un ansamblu de caracteristici care sunt identificate din discuiile dintre clieni, utilizatorii finali, experii domeniului aplicaiei, personalul de la nivelul conducerii i echipa de dezvoltare a software-ului. Aceste condiii sau sarcini care trebuie ndeplinite de ctre sistem sunt cunoscute sub denumirea de cerine. Pentru a determina i formula cerinele se contacteaz toate categoriile de persoane interesate de programul respectiv, se organizeaz grupuri de discuii, se analizeaz obiectivele organizaiilor implicate, se trimit chestionare, se analizeaz diverse documente. Utilizarea unui prototip al produsului poate oferi o alt perspectiv asupra aplicaiei, att pentru partea care comand software-ul, ct i pentru cea care particip la dezvoltare. Important este c analitii descoper nevoile reale ale clienilor i elaboreaz o specificaie a cerinelor utilizatorilor. Acest lucru este posibil numai lucrnd ntr-o manier iterativ i coopernd strns cu toate persoanele care pot constitui surse de informaii legate de diagrama respectiv. Faza de analiz. Aceast faz definete cerinele sistemului, independent de modul n care acestea vor fi ndeplinite. Aici se definete problema pe care clientul dorete s o rezolve. Rezultatul acestei faze este documentul cerinelor, care trebuie s precizeze clar ce trebuie construit. Documentul red cerinele din perspectiva clientului, definind scopurile i interaciunile la un nivel descriptiv nalt, independent de detaliile de implementare, cum ar fi, de exemplu: formularea problemei, ateptrile clientului sau criteriile pe care trebuie s le ndeplineasc produsul. Hotarul dintre descrierile de nivel nalt i cele de nivel sczut nu este foarte bine trasat. Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n document. Totui, aceasta trebuie s fie excepie i nu regul. Aceste excepii pot fi determinate de necesitatea meninerii compatibilitii cu alte sisteme deja existente, sau a unor anumite opiuni dorite de client, de exemplu utilizarea unui anumit standard sau o constrngere asupra dimensiunilor imaginii aplicaiei, care poate fi destinat unei categorii speciale de utilizatori sau care va rula pe nite sisteme cu o serie de particulariti (monitoare care nu suport rezoluii mari).

Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel nalt i cele de nivel sczut sunt puse mai bine n eviden de abordrile top-down (unde se merge ctre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt). Documentul cerinelor poate fi realizat ntr-o manier formal, bazat pe logic matematic, sau poate fi exprimat n limbaj natural. n mod tradiional, el descrie obiectele din sistem i aciunile care pot fi realizate cu ajutorul obiectelor. Aici noiunea de obiect nu trebuie confundat cu obiectul din programarea orientat obiect. Descrierea obiectelor i aciunilor trebuie s fie general i s nu depind de o anumit tehnologie. Desigur, ntr-o abordare POO, descrierile vor lua forma obiectelor i metodelor, ns n alte abordri, obiectele pot fi de exemplu servicii care acceseaz baze de date. n general, documentul cerinelor descrie ontologia proiectului, adic vocabularul de cuvinte cheie (n special construcii substantivale i verbale) care va fi utilizat pentru definirea protocolului specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturii aplicaiei, ci enumerarea prilor componente i a modului n care acestea se comport. Mai trziu, n faza de proiectare, acestea vor fi transformate n primitive informatice, precum liste, stive, arbori, grafuri, algoritmi i structuri de date. Mai concret, documentul trebuie s conin descrieri pentru urmtoarele categorii:
1.

Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului, care este bazat n mare parte pe construcii substantivale pentru identificarea pieselor, prilor componente, constantelor, numelor i a relaiilor dintre acestea;

2.

Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuie s le ndeplineasc sistemul i care sunt sugerate n general de construcii verbale. Exemple de aciuni sunt: metodele, funciile sau procedurile;

3.

Stri: Sunt definite ca mulimi de setri i valori care separ sistemul n dou ipostaze spaiotemporale. Fiecare sistem trece printr-o serie de schimbri de stare. Exemple de stri sunt: starea iniial, cea final sau strile de eroare. Cele mai multe stri depind de domeniul problemei. Strile sunt asociate cu obiectele sistemului. Un eveniment declaneaz o tranziie de stare care poate conduce la ndeplinirea unei aciuni de ctre sistem;

4.

Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinirea unui scop. Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie s poat utiliza, ntr-o manier ct mai facil i clar specificat, toate scenariile tipice ale aplicaiei. Scenariile tipice trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei. Ponderea acestora variaz de la un sistem la altul, dar 90% se consider o proporie acceptabil. Bineneles c un sistem cu un singur scenariu de utilizare este relativ simplu de obinut, pe cnd unul cu mii de scenarii posibile va fi mult mai dificil de analizat. Deseori este invocat regula 80/20: 80% din

funcionalitatea sistemului se realizeaz cu 20% din efortul de munc. Executarea restului minoritar de funcionalitate necesit marea majoritate a timpului de lucru;
5.

Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este un eveniment atipic. Totui, sistemul trebuie s gestioneze un numr ct mai mare de categorii de erori, prin tehnici stabilite, precum tratarea excepiilor, monitorizarea proceselor etc.;

6.

Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru toate situaiile care pot aprea n condiii de lucru reale nu este posibil. n logica tradiional, o teorie este definit de o mulime finit de axiome. Teoremele din teoria respectiv sunt propoziii adevrate. Dac se adaug ulterior noi axiome, teoremele existente rmn valide iar noile teoreme dezvoltate sunt adugate teoremelor stabilite. n logica nemonoton, adugarea de noi axiome poate invalida unele teoreme care au fost demonstrate anterior. O nou teorie nu mai este o simpl extensie a teoriei vechi, ci o mulime de teoreme noi, mpreun cu o parte din teoremele vechi. Procesul de stabilire a cerinelor are o natur iterativ i nemonoton. Mulimea iniial de cerine (axiomele) definete posibilitile (teoremele) sistemului. Noile cerine pot infirma soluiile vechi. Pe msur ce un sistem crete n dimensiuni i complexitate, stabilirea cerinelor devine din ce n ce mai dificil, mai ales cnd procesul de colectare a cerinelor este distribuit, fiind realizat de indivizi cu specializri diferite. Precedente. Pentru asigurarea eficienei elaborrii procesul trebuie s fie bazat pe analiza

precedentelor. Precedentul poate fi o descriere sau un caz de utilizare (use case) al sistemului. Principalele artefacte pentru reformularea precedentelor sunt: -

reformularea general a problemei; determinarea utilizatorilor (consumatorilor) sistemului; definirea scopului; funciile sistemului; atributele sistemului etc. Precedente ideale (essential use-case) - ele exprim o entitate general a procesului fr detalierea realizrii lor. Precedente reale (real use-case) - descrie concret procesul n termeni de soluii reale, n baza tehnologiilor concrete de introducere i afiare a informaiei.

Exist dou tipuri de precedente:

-

Precedentele reprezint consecutivitatea aciunilor pe care le efectueaz actorul n concordan cu sistemul pentru a cpta un anumit rezultat. Precedentele sunt reprezentate sub form de elips. Denumirea precedentului poate fi amplasat n interiorul elipsei sau sub ea. UML

prevede i existena de legturi ntre diferite cazuri de utilizare - extensia, generalizarea i incluziunea. Diagramele cazurilor de utilizare (Use case diagram, prezentare) Diagrama variantelor de utilizare reprezint partea nceptoare de la care se ncepe modelarea unui sistem nou. Aici se reflect aciunile reciproce dintre variantele posibile de utilizare i persoanele cointeresate sau sisteme. Diagrama reflect cerinele ctre sistem din punctul de vedere al utilizatorului. Variantele de utilizare sunt funciile efectuate de sistem. Avantajul principal al variantelor de utilizare este c folosindu-le separm implementarea sistemului de descrierea funciilor sale. Acest fapt ajut la concentrarea ateniei la aa ntrebri precum satisfacerea cerinelor sistemului fr a fi nevoie de a defini modul cum sistemul va fi implementat. Diagramele variantelor de utilizare ne demonstreaz ce va face sistemul i cum poate fi utilizat nc la nceputul proiectului. Metoda diagramelor variantelor de utilizare nu este cea standard i difer de ea foarte mult. Separnd proiectul n diagramele variantelor noi atragem atenia mai mult asupra procesului de percepere a sistemului, nu i felului de implementare a lui. Decompoziia funcional are ca scop divizarea poiectului n subprobleme cu care se va confrunta sistemul, apoi diagramele variantelor de utilizare concentreaz atenia asupra aspiraiilor utilizatorului ctre sistem. La nceputul oricrui proiect apare ntrebarea: Care sunt variantele de utilizare pentru proiectul dat?. Este preferabil de citit atent documentaia clientului, luai n vedere opinia oricrui utilizator care va folosi acest sistem. Este bine s obinei rspunsuri la urmtoarele ntrebri de la fiecare din viitorii utilizatori ai sistemului: 1
2 3

Ce vrea s fac cu sistemul? Va lucra cu informaie (introducere, tergere, etc)? Va fi nevoie de a informa sistemul despre careva evenimente din afar? Va fi nevoie ca sistemul s informeze utilizatorul despre careva evenimente?

Setul de variante de utilizare creat ajut la familiarizarea utilizatorilor cu funciile sistemului la nivelul cel mai general, de aceea dac numrul lor este foarte mare elasticitatea i uurina de percepere se pierde; de obicei un proiect are 20-50 de variante de utilizare. Pentru a organiza schema mai bine variantele de utilizare pot fi adunate n pachete. Variantele de utilizare atrag atenia asupra cererilor utilizatorilor ctre sistem. Fiecare variant de utilizare prezint o tranzacie terminat ntre utilizator i sistem. Denumirile variantelor de utilizare trebuie s fie alese din sfera de utilizare a sistemului, nu i din cea tehnic, prin aceasta

se ajunge la o mai bun nelegere a sistemului de ctre utilizatori. De obicei variantele de utilizare sunt numite folosind verbe care descriu rezultatul tranzaciei respective. Utilizatorul nu este curios s tie cum se va face una sau alt varianta de utilizare, pe el l intereseaz doar rezultatul final al tranzaciei. Pentru a fi sigur c orice variant de utilizare este prezent n modelul respectiv este necesar de a: 1. controla ca orice cerin funcional s fie prezent cel puin ntr-o variant de utilizare; 2. lua n consideraie cum va interaciona cu sistemul oricare din utilizatorii finali; 3. cunoate ce fel de informaie va introduce/scoate din sistem utilizatorii;
4.

ti cine va porni/opri sistemul dat;

5. specifica toate sistemele din afar cu care va interaciona sistemul dat i ce fel de informaie va fi trimis ntre ele. O diagram a cazurilor de utilizare prezint o colecie de cazuri de utilizare i actori i este folosit n general pentru a indica sau caracteriza funcionalitile i comportamentul ntregii aplicaii a sistemului interacionnd cu unul sau mai muli actori. Utilizatorii i orice sistem ce poate interaciona cu sistemul sunt actorii. Atta timp ce actorii reprezint utilizatorii, ei ajut la delimitarea sistemului i ofer o imagine clar a ceea ce se ateapt a se ntmpla n sistem. Cazurile de utilizare sunt construite pe baza nevoilor pe care le au actorii (utilizatorii). Aceasta asigur faptul c sistemul va produce ceea ce s-a dorit. Diagramele cazurilor de utilizare conin elemente ce pot reprezenta actori, relaii de asociere, relaii de generalizare, pachete i cazuri de utilizare. Se poate crea o diagram a cazurilor de utilizare de nivel nalt, pentru a vizualiza limitele i comportamentul sistemului. De asemenea, se pot crea una sau mai multe diagrame pentru a descrie o parte a aplicaiei sistemului. Cazurile de utilizare pot include alte cazuri de utilizare ca o parte a comportamentului su. O diagram a cazurilor de utilizare indic un set de actori externi i cazurile de utilizare ale sistemului n care particip respectivii actori. Cazuri de utilizare. Un caz de utilizare este o secven a tranzaciilor realizate de sistem ca rspuns la evenimentele declanate de un actor al sistemului. Un caz de utilizare complet trebuie s ofere o valoare msurabil unui actor, cnd actorul execut o sarcin anume. Un caz de utilizare conine toate evenimentele care pot surveni n cadrul perechii actor - caz de utilizare, nu neaparat unul ce va aparea n orice scenariu particular. Un caz de utilizare conine un set de scenarii care explic diferitele secvene ale interaciunii din interiorul tranzaciei.

Un caz de utilizare poate de asemenea descrie comportamentul unui set de obiecte, ca de exemplu o organizaie. Reprezentarea grafic. Forma de baz a cazului de utilizare este o elips:

Un caz de utilizare poate avea un nume, care este caracteristic i nu un nume simplu. Adesea este scris ca o descriere informativ a actorilor externi i a secvenelor evenimentelor dintre obiecte care acoper tranzacia. Numele unui studiu de caz ncepe de obicei cu un verb. Fiecare apariie a unui caz de utilizare n diagram indic un subset de informaii ale modelului despre cazul de utilizare; toate aceste informaii ale modelului pot fi vizualizate n specificaiile cazului de utilizare. n diagramele cazurilor de utilizare se pot desena asocieri ntre cazuri de utilizare i actori, respectiv generalizri ntre cazuri de utilizare. Actori. Un actor este un stereotip al unei clase. Utilizatorii i orice sistem care poate interaciona cu sistemul n cauz sunt actori. Astfel, un actor reprezint un rol jucat de o persoan sau o entitate care interacioneaz cu sistemul. Cum actorii reprezint utlizatorii sistemului, ei ajuta la delimitarea sistemului i ofer claritate n ceea ce se va ntmpla n respectivul sistem. Aceeai persoan fizic poate juca rolul mai multor actori, aa cum mai multe persoane pot juca acelai rol, i astfel interaciona ca acelai actor. Reprezentarea grafic. Actorii se reprezint sub forma unor mici personaje avnd propriul su nume ca n figura:

Fiecare actor trebuie s aib un nume, iar numele acestuia descrie rolul jucat de ctre actor. Exist trei tipuri primare de actori: - utilizatorii sistemului - o persoan fizic, sau un utilizator. Aceti actori fiind cel mai des utilizai, sunt prezeni n orice sistem. Un individ poate avea mai multe roluri, de exemplu o persoan poate fi reprezentant al serviciului i n acelai timp client. Utiliznd ca denumire a actorului rolul su vom obine o imagine mai stabil a actorilor deoarece poziia se schimb n timp, iar rolurile trec de la o poziie la alta i nu va aprea n viitor necesitatea de modificare a modelului.

- sisteme ce interacioneaz cu sistemul dat . De exemplu un sistem de rezervare a biletelor va interaciona cu alt sistem de validare a cartelelor de credit. n acest caz sistemul de validare a cartelelor de credit este un actor. El este alt sistem care nu va necesita modificri, deci el se afl n afara proiectului dat, dar necesit interaciunea cu sitemul nostru. - timpul, care devine actor cnd la expirarea unei poriuni de timp vor avea loc unele evenimente n sistem. De exemplu n sistemul de rezervare a biletelor exist posibilitatea de a ctiga un bilet gratis. n fiecare zi la o or anumit sistemul selecteaz automat un client ctigtor al biletului dat. Deoarece timpul se afl n afara controlului nostru el este un actor. n diagrama cazurilor de utilizare se pot desena asocieri de la actor la cazul de utilizare sau generalizri ntre actori: - reprezint asocierea unidirecional care presupune o legatur ntre obiecte
-

reprezint agregarea ce arat prile componente ale unui ntreg.

Asocieri. Definiie: O asociere reprezint o conexiune semantic ntre cazurile de utilizare i actori. Asocierile sunt unidirecionale; ele sunt relaiile cele mai generale i cele mai slabe din punct de vedere semantic. Reprezentarea grafic: Asocierile se reprezint printr-o linie plasat ntre entitile de asociat:

Numele asocierilor. O asociere poate avea nume i un stereotip care sa identifice tipul sau semnificaia relaiei. Relaiile de asociere se pot desena ntre cazuri de utilizare i actori. Fiecare apariie a unei asocieri n diagram etaleaz un set de informaii ale modelului despre relaia de asociere n cauz, aceste informaii fiind cuprinse n sp. Generalizare. O generalizare ntre dou cazuri de utilizare indic faptul c cazul de utilizare poate mprti comportamentul definit n unul sau mai multe cazuri de utilizare. Deasemenea, generalizarea suport utilizatori i extinde stereotipuri. O generalizare ntre actori arat c un actor motenete structura i comportamentul unui actor sau mai multor actori. Reprezentarea grafic:

Generalizarea se reprezint printr-o sgeat ce leag dou elemente (cazuri de utilizare i actori):

Se folosete numele relaiei i a stereotipului pentru a identifica tipul sau semnficaiile relaiei respective. Relaia de generalizare de la cazul B spre A indic faptul c B este o specializare a lui A. Notaia grafic de realizare cu ajutorul simbolului standart de generalizare.

Un exemplu de generalizare ntre cazurile de utilizare

Inchiere asigurare v iata

Inchiere asigurare auto

Inchiere asigurare

Cazul de utilizare specializat trebuie s utilizeze n totalitate i cazul de utilizare mai general, chiar dac ntr-o ordine n care aciunile celor dou se ntreptrund. Ca i pentru clase exist i alte posibiliti de a defini i alte cazuri de utilizare abstracte. Spre exemplu, ncheierea de asigurri pe via i de asigurri auto poate fi generalizat n cazul de utilizare ,,ncheiere asigurare. Cu ajutorul relaiei de generalizare noi accentum faptul c mai muli actori au caliti comune. De exemplu clienii pot fi de dou tipuri: persoane fizice i persoane juridice. De obicei acest tip de relaii este util cnd comportamentul unui tip de actori difer de cel a altui tip ntr-aa fel nct cauzeaz aciunile sistemului. De exemplu dac un tip de actori poate iniializa un fel de variant de utilizare, iar al doilea nu poate, atunci este bine s introducem ambele tipuri ca fiind generalizri a unui tip comun. ns dac tipul A i tipul B iniializeaz aceleai variante de utilizare cu mici diferene este mai preferabil s nu crem dou tipuri de actori generalizai, ci s implementm prelucrarea n fluxul de evenimente a variantei de utilizare. Se pot desena relaii de generalizare ntre cazuri de utilizare i actori. Apariia unei generalizri n cadrul unei diagrame indic un set de informaii ale modelului despre relaia de generalizare. Aceste informaii reprezint specificaiile generalizrii.

Precedentele reprezint consecutivitatea aciunilor pe care le efectueaz actorul n concordan cu sistemul pentru a cpta un anumit rezultat. Precedentele sunt reprezentate sub form de elips. Denumirea precedentului poate fi amplasat n interiorul elipsei sau sub ea. UML prevede i existena de legturi dintre diferite cazuri de utilizare extensia (se reprezint printr-o sgeata trasat cu linie ntrerupt, notat cu cuvntul rezervat extensie). O relaie de extensie cuprinde o condiie de autorizare i referine la unul sau mai multe puncte de extensie din CU destinaie, n care extensia poate fi inserat. Extensia mai permite adugarea de cazuri de utilizare aprute ulterior, n cursul dezvoltrii sistemului. Ca exemplu: s presupunem un market. Personalul nu este obligat s prezinte fiecrui client catalogul mrfurile propuse spre vnzare. Rezult o extindere a funciilor acordate de ctre personal; generalizarea (de la cazul B spre cazul A, indic faptul c B este o specializare a lui A). Notaia grafic se realizeaz cu ajutorul simbolului standard de generalizare. Ca exemplu poate servi o bibliotec electronic, avem nevoie de o carte i dm la cutare. Prin intermediul relaiei de generalizare noi putem s cutam prin mai multe moduri: dup numele autorului, fie dup denumirea crii, sau chiar dup ambele mpreun. Cu alte cuvinte relaia de generalizare este o relaie de motenire i incluziunea (indic faptul c o instan a unui caz de utilizare cuprinde i comportamentul specificat printr-un alt caz de utilizare). Notaia grafic este folosit cea pentru extensie, etichetat ns cu cuvntul rezervat include. Pentru acelai exemplu de mai sus: vnztorii sunt obligai s primeasc taxa de la cumprtori, aceasta ar fi una din obligaiuni, rezult c acest serviciu este obligator inclus n serviciile marketului. Limbajul UML presupune un numr de legturi ntre actori i variante de utilizare. Aceste legturi sunt de comunicaie (communication), de utilizare (uses), de extindere (extends) i de generalizare (actor generalization). Legturile de comunicaie descriu legturile ntre actori i variantele de utilizare. Cele de utilizare i de extindere numai ntre variantele de utilizare, iar cele de generalizare ntre actori. Legturi de comunicaie. Este legtura ntre un actor i o variant de utilizare. n limbajul UML este prezentat sub forma unei sgei:

Direcia sgeii indic pe cel care a iniializat comunicaia. Legturi de utilizare. O legtur de utilizare (Uses relationship) ofer posibilitatea ca o variant de utilizare s folosesc funcionalitatea altei variante de utilizare. Cu ajutorul acestei legturi se modeleaz comportamentul care se ntlnete n mai multe variante de utilizare.

Legtura de utilizare n limbajul UML este prezentat cu ajutorul unei sgei i a cuvntului <<uses>> Legturi de extindere. Legturi de extindere (Extends relations) sunt asemntoare celor de utilizare, ns varianta concret de utilizare poate s nu foloseasc funcionalitatea variantei de utilizare abstracte cu care este legat prin legtura de extindere. n limbajul UML astfel de relaii se reprezint printr-o sgeat cu cuvntul <<extends>> Relaiile ntre cazuri de utilizare Extensia. O relaie de extensie arat c un caz de utilizare poate fi extins cu un comportament adiional diferit, ntr-un alt caz de utilizare. O relaie de extensie cuprinde o condiie de autorizare, referine i unul sau mai multe puncte de extensie din cazul de utilizare al destinaiei, n care extensia poate fi inserat.

Client

Comanda produs

<<extend>>

Livre aza prod us

Mai sus avem prezentat un caz de utilizare care poate extinde un alt caz de utilizare. Extensia se reprezint printr-o sgeat trasat cu linie ntrerupt, notat cu cuvntul rezervat <<extensie>>. Spre exemplu cazul de utilizare ,,Comand produs poate fi extins cu ,,Livreaz produs, condiia ce autorizeaz extensia fiind existena produsului respectiv n stoc. Prin relaiile de extensie pot fi introduse, sub form de cazuri de utilizare distincte, prelucrri ce constituie excepii n utilizarea cazurilor de utilizare de baz. Spre exemplu, preluarea (telefonic) de comenzi de vnzare pe baz de catalog poate fi nsoit de prelucrri legate de clientul care face comanda: nregistrarea unui client nou, dac acesta este la prima comand sau modificarea datelor personale, cum ar fi adresa sau numrul de telefon.

<<extend>> Inregistrare client nou

M odificare date client a

<<extend>>

Functionar com ercial

Preluarea com anda

Fig.2.1. Diagrama cazurilor de utilizare pentru varianta de utilizare ,,Preluare comand Cazul de utilizare ,,Preluare comand poate fi extins prin alte dou cazuri de utilizare: ,,nregistrarea clientului nou i ,,Modificarea datelor client. Extensia mai permite adugarea cazurilor de utilizare aprute ulterior n cursul dezvoltrii sistemului.

Incluziunea Relaia de incluziune indic faptul c o instan a unui caz de utilizare cuprinde i comportamentul specificat printr-un alt caz de utilizare.
Sistem Bancomat

R tr g r an m r r e a ee u ea < in lu e > < c d> C n lie t

C n u r s ld o s ltae o

Fig.2.2. Diagrama cazurilor de utilizare pentru cazul de utilizare,,Retrage numerar Cazul de utilizare ,,Retrage numerar include i cazul de utilizare, Consultare sold. Notaia grafic este cea folosit pentru extensie, ns eticheta este cuvntul rezervat <<include>>. Revenind la exemplul referitor la operaiile cu numerar din bancomat, un client poate solicita fie o retragere de numerar fie o consultare a soldului contului respectiv. Retragerea include i consultarea soldului (rmas dup efectuarea retragerii). n consecin ntre cele dou cazuri de utilizare exist o relaie de incluziune ceea ce este artat n figura de mai sus. Figura de mai jos prezint un alt exemplu de relaii de includere ntre cazurile de utilizare: livrarea produselor comandate include expedierea produselor i emiterea facturii.

Factura re

Expedierea produs <<includ e>> <<includ e>>

Liv rare prod use

Functio r na com rcial e

Fig.2.3. Diagrama cazurilor de utilizare pentru cazul de utilizare Livrarea produselor Relaiile de extindere i de includere ocazionate de vnzarea produselor. Notele. Definiie: O not cuprinde ipotezele i deciziile aplicate n timpul analizei i a reprezentrii grafice. Notele pot conine orice informaie, inclusiv textul planului, fragmente de cod sau referine la alt document. O not conine un volum nelimitat de text. n consecin notele pot fi dimensionate.

Notele se comport ca nite etichete. Ele se pot folosi n orice tip de diagram. Notele sunt doar explicaii oferite acolo unde apar n diagram. Ele nu sunt considerate c fac parte din model. Ele pot fi terse ca orice alt component a diagramei. ancora notei Ancora notei conecteaz o not la un element pe care l simuleaz. Aceste elemete pot lega o not de un element sau mai multe elemente ale diagramei respective. O not poate sa nu fie conectat, caz n care aceasta se refer la ntreaga diagram. Reprezentarea grafic Forma grafic a unei note este un dreptungi care are un col ndoit :

n diagram dac nota d explicaii unor anumite elemente, atunci folosim i ancore ale notei care se reprezint printr-o linie punctat ce face legatura dintre element i not :

Elaborarea Diagramelor USE-CASE Lucrul asupra proiectului n mediul Rational Rose ncepe cu analiza general a problemei puse, apoi se construiete diagrama variantelor, USE-CASE. Diagramele cazurilor de utilizare au rolul de a reprezenta ntr-o form grafic funcionalitile pe care trebuie s le ndeplineasc sistemul informatic n faza sa final. USE-CASE reprezint o mulime de secvene de activiti (inclusive variantele), ndeplinite de sistem cu scopul ca actorul s primeasc un rezultat bine determinat. Actorul reprezint o mulime de roluri logic legate, jucate de diverse persoane sau sisteme informatice i care interacioneaz cu sistemul informatic aflat n dezvoltare. Cazurile de utilizare reprezint secvene de tranziie ce au loc n dialogul cu sistemul i care sunt nrudite din punct de vedere comportamental. Un caz de utilizare modeleaz un dialog ntre un actor i mulimea de cazuri de utilizare a unui sistem, reprezint toate modalitile n care sistemul poate fi folosit. Sistemul nostru de analiz a microprocesorului va avea urmtoarele diagrame Use-Case. Deci Use-Case reprezint contractul ntre sistem i actori.

Fig.2.4. Diagrama cazurilor de utilizare pentru un sistem de control al accesului

Fig.2.5. Diagrama cazurilor de utilizare pentru viramentul prin serviciul Internet Deci diagrama Use Case reprezint interaciunea dintre cazurile de utilizare, care sunt funcii ale sistemului i persoanele acestui sistem. Adic sunt reprezentai oameni sau sisteme, care primesc sau transmit informaia n sistemul dat. n diagram sunt prezente aciunile reciproce dintre variantele de utilizare i persoanele acestui sistem. Astfel variantele de utilizare sunt funcii efectuate de sistem, iar persoanele sunt persoane cointeresate n sistemul elaborat. Diagrama prezint care persoan iniiaz sistemul i cnd persoanele cointeresate primesc datele necesare. Cu alte cuvinte diagrama Use Case ilustreaz modul de utilizare a sistemului de ctre actor, i reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care sunt nrudite din punct de vedere comportamental. Mulimea de cazuri de utilizare a unui sistem reprezint toate modalitile n care sistemul dat poate fi utilizat. Use Case (Cazurile de Utilizare) i actorii definesc scopurile sistemului dat. Cazurile de utilizare includ toate evenimentele din sistem, iar actorii includ toate componentele externe sistemului dat.

Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor din meniurile: Browse, Create, Model Properties, TOOLS din Logical View, componentele i operaiile de manipulare (generare, modificare i salvare a modelului). Meniul:

Browse. Browser-ul este un instrument de navigare ierarhic care d posibilitatea de a vedea pictogramele interaciunilor, claselor, variantelor de utilizare, activitilor, strilor, ct i altor elemente ale modelului. Use Case Diagram afieaz diagrama cazurilor de utilizare Class Diagram afieaz diagrama claselor Component Diagram afieaz diagrama componentelor Deployment Diagram afieaz diagrama exploatrii Interaction Diagram afieaz diagrama interaciunilor State Machine Diagram afieaz diagrama de stare Expand afieaz diagrama proprie pachetului selectat Parent afieaz diagrama ce conine pachetul de componente a crui diagram este cea din fereastra activ Specification permite specificarea fiecrui element selectat Top Level comanda dat este folosit pentru vizualizarea nivelului superior al unei diagrame a claselor sau componentelor Referenced Item afieaz diagrama referit de elementul selectat Previous Diagram vizualizeaz diagrama afiat anterior. Report Show Usage afieaz lista locaiilor unde elementul selectat este folosit. Show Instances afieaz lista tuturor diagramelor de colaborare unde este prezent instanierea clasei selectate. Show Acces Violations afieaz lista tuturor conflictelor ntre pachetele unei diagrame a claselor. Show Participants in UC afieaz lista tuturor participanilor la o preceden selectat.

Tools Create este un submeniu ce reprezint o alternativ a barei de instrumente speciale. Text adaug un text Note adaug un comentariu Note Anchor leag un comentariu de elementul (comentat) Class adaug o clas Parametrized Class adaug o clas parametrizat (ablon, temlate) Class Utility adaug un utilitar pentru clase Parametrized Class Utility adaug un utilitar parametrizat pentru clase Association adaug o relaie de asociaie Aggregate Association adaug o relaie de agregare Unidirectional Association adaug o relaie de asociaie unidirecional Unidirectional Aggregate Association adaug o relaie de agregare unidirecional Generalization adaug o relaie de generalizare Dependency adaug o relaie de dependen Pachet adaug un pachet Instantiated Class adaug o instan de clas Instantiated Class Utility adaug o instan de utilitar pentru clase Actor adaug un actor Use Case adaug un caz de utilizare Interface adaug o interfa Realize adaug o relaie de realizare Check Model permite gsirea referinelor nedeterminate ntr-un model. Rezultatul este pus n jurnalul evenimentelor. Model Properties Edit schimb specificrile modelului deschis Replace nlocuiete setul de proprieti a modelului cu un nou set dintr-un fiier Export export setul de proprieti a modelului ntr-un fiier Add actualizeaz proprietile modelului cu datele dintr-un fiier Update actualizeaz datele dintr-un fiier cu proprietile modelului deschis Options permite modificarea proprietilor aplicaiei Rational Rose Open Script deschide un fiier surs a limbajului RoseScript New Script creeaz un nou cod surs a limbajului RoseScript Synchronize lanseaz Rational Suite Synchronizer

Window Cascade aranjeaz ferestrele diagramelor deschise n cascad (una asupra alteia). Title aranjeaz ferestrele diagramelor deschise astfel nct fiecare este vzut Arrange Icons aranjeaz ferestrele minimizate a diagramelor deschise (doar cnd ele sunt amplasate haotic) Help Contents and Index apeleaz ghidul de utilizare a aplicaiei Rational Rose Search for Help on... caut informaiei cu privire la o anumit tem Using Help informaie cu privire la modul de folosire a ghidului de utilizare Extended Help obine informaii cu ajutorul Rational Unified Process Contacting Technical Support apeleaz la suportul tehnic prin Internet precum i alte metode (telefon, fax, e-mail) Rational on the Web Pagina Web a companiei Rational Rose About Rational Rose informaii cu privire la versiunea programului Rational Rose precum i a componentelor sale standard i adiionale. Diagrame Use Case. Diagramele cazurilor de utilizare au rolul de a reprezenta ntr-o form grafic funcionalitile pe care trebuie s le ndeplineasc sistemul informatic n faza sa final. De asemenea diagrama cazurilor de utilizare reprezint imaginea sistemului privit din exterior. Diagramele permit specificarea cerinelor ntr-o manier care ar permite o nelegere uoar. Pe ea sunt prezentate relaiile dintre actori i cazurile de utilizare. Cazurile de utilizare reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care sunt nrudite din punct de vedere comportamental. Practic, un caz de utilizare modeleaz un dialog ntre un actor i sistemul informatic. Mulimea de cazuri de utilizare a unui sistem reprezint toate modalitile n care sistemul poate fi folosit. Bara de instrumente speciale proprie Diagramei Use Case

1 2

4 5

10

1. Comanda de selectare. 2. Comanda de scriere a unui text. 3. Comanda de adugare a unui comentariu. 4. Comanda de legare a comentariului de elementul pe care-l nsoete.

5. Comanda de adugare a unui pachet. 6. Comanda de adugare a unui precedent. 7. Comanda de adugare a unui actor. 8. Comanda de adugare a asociaiilor. 9. Comanda de adugare a dependenelor. 10. Comanda de adugare a generalizrilor. Elaborarea diagramelor USE-CASE (variantelor) n mediul Rational Rose Lucrul asupra proiectului n mediul Rational Rose ncepe cu analiza general a problemei puse, apoi se construiete diagrama variantelor, USE-CASE. Pentru elaborarea acestei diagrame este necesar de selectat diagrama dat din fereastra diagramei. De deschis browserul, i de acolo de ales pictograma main ce semnific nsui diagrama variantelor de utilizare. Tot atunci pe interfaa de lucru ne apare setul special de instrumente specific pentru acest tip de diagrame. n setul acesta sunt toate elementele necesare pentru construirea diagramei variantelor de utilizare. Pentru adugarea unui nou element este necesar de selectat cu ajutorul mouseului butonul cu imaginea elementului necesar, dup aceea tot cu ajutorul mouseului elementul se depune pe diagram. Pe diagram apare imaginea elementului selectat cu dimensiunile geometrice modificate i cu un nume aproximat. Numele elementului poate fi schimbat de ctre eleboratorii proiectului, fie imediat dup depunerea lui pe diagram, fie n cursul de elaborare a proiectului. Tastnd click dreapta pe elementul dat se cheam meniul contextual al acestui element, printre opiunile cruia este i punctul Open Specification. n acest caz se activeaz o fereastr de dialog cu casete speciale, n cmpurile crora este posibil de a nscrie toat informaia despre elementul dat. Diagrama variantelor de utilizare este reprezantarea modelului la un nivel nalt, i din aceast cauz ea nu trebuie s conin multe variante de utilizare i actori. n continuare diagrama poate fi modificat adugnd sau eliminnd diferite elemente din ea. Eliminarea complet a unui element din diagram, adic toate legturile cu acest element s fie pierdute se efectueaz tastnd edit>delete from model sau cu combinaia de taste Ctrl+D. La folosirea legturilor este necesar de inut cont de semnificaia acestei legturi, n cazul cnd dou elemente nu pot s fie legate cu un oarecare tip de legtur sistemul ne va informa despre aceasta.

Fig.2.6. Diagrama cazurilor de utilizare privind Conectarea clientului la reelele electrice n diagrama de mai sus avem urmtorii actori:
1.

Conducere conducerea ntreprinderii Union Fenosa instalarea reelelor de distribuie, reparaia lor, instalarea contoarelor etc.

2. Departament Tehnic reprezint un departament al Union Fenosa care se ocup cu 3. Departament control reprezint un departament al Union Fenosa care se ocup cu citirea datelor de la contoarele consumatorilor, prelucrarea lor etc. 4. Contabilitatea reprezint contabilitatea Union Fenosa care se ocup cu gestionarea resurselor financiare
5.

Consumator consumatorii de curent electric fie persoane fizice, fie persoane juridice

6. Productor productorii de curent electric 7. Banca bncile prin intermediul crora se efectueaz transferuri de bani. i urmtoarele cazuri de utilizare: 1. Conectarea conectarea consumatorului la furnizorul de energie
2.

ntocmirea Facturii ntocmirea facturii consumatorului pe baza datelor citite de la contor

3. Achitarea Facturii achitarea facturii de ctre consumator 4. ncheierea contractului ncheierea contractului ntre Union Fenosa i productorul de energie. Diagrame Interaction Funcionalitatea unui caz de utilizare este dat de un flux de evenimente (specificat n documentul de descriere al cazului de utilizare).

Un scenariu reprezint o cale (un drum) prin fluxul de evenimente al unui caz de utilizare. Scenariile pot fi privite ca instane (sau realizri) ale cazurilor de utilizare: ele descriu o secven de aciuni concrete care pot avea loc la un moment dat n sistem. Determinarea scenariilor are rolul de a ajuta: - nelegerea funcionalitii cazurilor de utilizare; - specificarea modului n care responsabilitile unui caz de utilizare sunt distribuite obiectelor i claselor din sistem; - identificarea obiectelor i claselor; - identificarea interaciunilor ntre obiecte, necesare pentru realizarea unei pri funcionale concrete descris de un caz de utilizare; - comunicarea pe baza specificaiilor proiectului. Dac fluxul de evenimente al unui caz de utilizare este descris prin intermediul unui text (documentul de descriere al cazurilor de utilizare), scenariile se descriu prin intermediul aanumitelor diagrame de interaciune. n Rational Rose avem dou tipuri de diagrame de interaciune: diagramele de secven i de colaborare. Fiecare dintre aceste diagrame reprezint o vedere grafic diferit a unui scenariu. Diagrame Sequence Diagramele de secven prezint interaciunile care au loc ntre diverse obiecte ale unui sistem, ordonate cronologic. Ele determin obiectele i clasele implicate ntr-un scenariu i secvenele de mesaje transmise ntre obiecte, necesare ndeplinirii funcionalitii scenariului. Diagramele de secven sunt asociate unui caz de utilizare. Fiecrui obiect, clas i corespunde o linie a timpului, reprezentat printr-o linie punctat sub reprezentarea obiectului. Mesajele transmise ntre obiecte sunt reprezentate prin sgei etichetate cu numele mesajului. Bara de instrumente speciale proprie Diagramei Sequence

1 2

6 7

1. Comanda de selectare. 2. Comanda de scriere a unui text. 3. Comanda de adugare a unui comentariu . 4. Comanda de legare a comentariului de elementul pe care-l nsoete.

5. Comanda de adugare a unui obiect. 6. Comanda de adugare a unui mesaj transmis de un obiect altui obiect. 7. Comanda de adugare a unui mesaj transmis de un obiect lui nsui. 8. Comanda de adugare a unui mesaj de rspuns. 9. Comanda de adugare a punctului terminus a liniei timpului (proprie fiecrui obiect).

Fig.2.7. Diagrama secvenelor pentru cazul de utilizare ncheie contract Productorul de energie electric propune gama sa de servicii i produse. Conducerea ntreprinderii Union Fenosa analizeaz oferta apoi negociaz preurile i condiiile cu productorul. n cazul cnd ajung la o nelegere comun este ncheiat contractul.

Fig.2.8. Diagrama secvenelor pentru cazul de utilizare Achit factura O dat fiind ntocmit factura, contabilitatea o transmite consumatorului. Consumatorul verific i el contorul i calculeaz consumul de energie. n cazul cnd calculele sale corespund cu cele din factur el achit factura la banc.

Fig.2.9. Diagrama secvenelor pentru cazul de utilizare Conectare O persoan sau o firm dac dorete s fie racordat la reelele Union Fenosa trebuie s nainteze o cerere conducerii Union Fenosa. Aceasta consult Departamentul Tehnic n vederea posibilitii conectrii persoanei date. Dac este posibil conectarea, persoana ce a naintat cererea trebuie s achite taxa de conectare. Contabilitatea primind banii anun conducerea, care d dispoziie de conectare. Departamentul Tehnic conecteaz solicitantul la reelele electrice.

Fig.2.10. Diagrama secvenelor pentru cazul de utilizare ntocmete factura Un angajat al Departamentului control responsabil de citirea datelor de la contoare consult contorul unui consumator. Datele citite sunt transmise altui angajat al aceluiai departament, care calculeaz consumul curent. Datele prelucrate sunt transmise la contabilitate, unde este ntocmit factura. Aceasta fiind transmis apoi consumatorului.

Diagrame Colaboration Diagramele de colaborare prezint interaciunile dintre obiecte organizate relativ la acestea i a legturilor dintre ele. Diagramele de colaborare conin: - obiecte, n reprezentarea lor grafic sub form de dreptunghiuri; - legturi ntre obiecte, reprezentate grafic prin linii de conectare; - mesaje, reprezentate ca etichete ale legturilor, i care conin o sgeat ndreptat spre obiectul server (receptor al mesajului). Bara de instrumente speciale proprie Diagramei Collaboration

9 10 11 12

1. Comanda de selectare. 2. Comanda de scriere a unui text. 3. Comanda de adugare a unui comentariu. 4. Comanda de legare a comentariului de elementul pe care-l nsoete. 5. Comanda de adugare a unui obiect. 6. Comanda de adugare a unei instane de clas. 7. Comanda de adugare a unei legturi dintre dou obiecte. 8. Comanda de adugare a unei legturi a obiectului cu sine nsui. 9. i 10. Comanda de adugare a unei legturi dintre dou obiecte ntre care se transmit mesaje. 11. i 12. Comanda de adugare a unei legturi dintre dou obiecte ntre care se transmite fluxul de informaie.

Fig.2.11. Diagrama de colaborare pentru cazul de utilizare ncheie contract

Fig.2.12. Diagrama de colaborare pentru cazul de utilizare Achit factura

Fig.2.13. Diagrama de colaborare pentru cazul de utilizare Conectare

Fig.2.14. Diagrama de colaborare pentru cazul de utilizare ntocmete factura Spre deosebire de diagramele Collaboration care ne prezint doar interaciunile dintre obiecte i mesajele transmise ntre ele, diagramele Sequence ne prezint evoluia lor n timp, astfel ele sunt uor de citit i neles.

ntrebri de control: 1. Care sunt etapele metodologiei dezvoltrii soft-ului? 2. Cum nelegei modelul spiral al ciclului de via al sistemului? 3. Numii principalele etape utilizate la elaborarea unui sistem, conform metodologiei APOO. 4. Cte tipuri de artefacte cunoatei? 5. Ce reprezint diagrama cazurilor de utilizare? Caracterizai elementele de baz ale acestei diagrame. 6. Care este diferena dintre extensie i incluziune? 7. Descriei diagramele de secven.

LUCRAREA DE LABORATOR NR. 3 TEMA: Analiza rezultatelor modelrii din diagrama cazurilor de utilizare i dezvoltarea n diagramele Sequence i Collaboration n mediul Rational Rose Scopul lucrrii: 1. Studierea prii teoretice i verificarea cunotinelor nsuite n mediul instrumentului CASE Rational Rose. 2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea i destinaia elementelor diagramelor Sequence i Collaboration din Rational Rose. 3. Dezvoltarea elaborrilor cu alte diagrame pentru modelul din domeniul propus n precedenta lucrare de laborator. nsuirea tehnicilor de dezvoltare, modificare i salvare a respectivelor modele elaborate n diagrame. 4. Studierea aprofundat i descrierea destinaiei funcionale a submeniurilor/opiunilor din meniurile: Browse, Create, Model Properties, TOOLS din Logical View, componentele i operaiile de manipulare (generare, modificare i salvare a modelului) pentru respectivele diagrame. 5. Efectuarea diverselor manipulri n diagramele respective pentru evidenierea tehnicii eficiente. 6. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n procesul efecturii lucrrii de laborator. Sarcina: Pentru un sistem concret realizai cte trei diagrame Sequence i Collaboration.

Consideraii teoretice generale. Descriere general O diagram ofer utilizatorului un mijloc de vizualizare i de manevrare a elementelor de modelare. Diagramele pot art o parte sau toate caracteristicile elementelor de modelare, conform nivelului de detaliu util n contextul unei diagrame date. Diagramele pot grupa informaii interdependente, pentru a art caracteristicile respective n UML. n UML Entitile de comportament (Behavioral things) sunt componente dinamice ale limbajului UML i sunt verbe care descriu comportamentul modelului n timp i spaiu. Exist doar dou tipuri de entiti de comportament: interaciunea i automatul.

Interaciunea (Interaction) reprezint comportamentul, esena cruia const n schimbul de mesaje (Messages) dintre obiecte n cadrul unui context concret pentru atingerea scopului dorit. Cu ajutorul interaciunii se poate descrie att o operaie aparte, ct i comportamentul unui ansamblu de obiecte. Ea propune un alt set de elemente, aa ca comunicarea, consecutivitatea faptelor i legturilor. Diagrama interaciunii (Interaction) descrie un proces de prelucrare a informaiei din varianta de utilizare. Exist dou tipuri de diagrame de interaciune diagramele succesiunilor (Sequence) i cele de colaborare (Collaboration). Primul tip de diagrame este organizat n jurul timpului. Ambele tipuri de diagrame descriu aceeai informaie ns au dou diferene principale. Diagramele succesiunilor atrage atenia asupra controlului, iar diagramele de colaborare asupra fluxului de date. Diagrama de interaciune este folosit pentru a modela comportamentul unei mulimi de obiecte dintr-un anumit context care interacioneaz ntre ele pentru a ndeplini un anumit scop. Scopul unei diagrame de interaciuni este de a specifica modul n care se realizeaz o operaie sau un cadru de utilizatori. Diagramele de interaciune prezint aceleai date care au fost introduse n fluxul evenimentelor i o fac ntr-o form mai inteligibil. Principalul sunt obiectele care sunt create pentru a realiza calitile funcionale ale sistemului. Este posibil de a plasa obiecte i clase pe diagramele succesiunilor i cele de colaborare. Tot ce ne nconjoar este un obiect, practic acelai lucru este obiectul din limbajul UML. Un obiect este o entitate care ncapsuleaz n structura sa nite date i comporatamentul. Obiectul este un termen care descrie lucruri concrete. Datele obiectului se numesc atribute (attributes), valoarea lor poate s se schimbe ns numrul i proprietile sale nu pot fi schimbate. Comportamentul obiectului este determinat de operaiile sale (operations). n mediul Rose obiectele sunt plasate pe diagramele de interaciune. n cazul cnd un actor este stereotipul unei clase sau o clas este plasat pe diagram automat se creaz o instan a acestei clase. Cu ajutorul diagramelor de interaciune programatorii definesc clasele necesare modelrii sistemului, relaiile dintre ele, operaiile i resposabilitile fiecrei clase. ntrun fel diagramele de interaciune sunt baza oricrui proiect. Diagramele succesiunilor sunt organizate n jurul timpului, i ajut s nelegem succesiunea logic a evenimentelor. Dei informaia pe diagramele succesiunilor i cele de colaborare este aceeai, totui diagramele succesiunilor sunt mai inteligibile.

Diagramele de colaborare sunt utile cnd este necesar de estimat valoarea schimbrilor unei clase, unei operaii etc. nct diagrama dat arat ce obiecte sunt legate ntre ele, schimbnd unul din obiecte vei nelege care obiecte vor fi atinse de aceast schimbare. Diagramele de interaciune conin obiecte i mesajele (cu ajutorul mesajelor un obiect i cere altui obiect s execute o operaie). Obiectele de pe diagramele de interaciune au nite responsabiliti, acelai lucru se poate spune i despre mesaje. Trebuie s controlai ca responsabilitile obiectelor i a mesajelor pe care le trimit s corespund. Diagramele succesiunilor sunt diagramele de interaciune organizate n jurul timpului. Ele trebuie citite din sus n jos. Fiecare variant de utilizare poate avea un numr nelimitat de fluxuxi alternative, fiecare din ele este prezentat printr-o diagram a succesiunilor. Obiectele fluxului sunt prezentate n partea de sus sub forma unor dreptunghi. Fiecare obiect are linie de via (lifeline) prezentat pe diagram de o linie vertical. Mesajele dintre obiecte sunt prezentate prin sgei de la linia de via a obiectului care iniializeaz activitatea la obiectul operaia cruia se execut. n etapele urmtoare fiecare mesaj va fi o funcie a clasei respective. Mesajele pot fi reflexive obiectul execut funcia proprie. Orice diagram de interaciune trebuie s aib un obiect-actor. El este acela care iniializeaz procesul, el este instana actorilor de pe diagrama variantelor de utilizare. Fiecare diagram de interaciune conine obiecte. Obiectele reprezint substantive n fluxul evenimentelor. Diagrama succesiunilor Diagrama succesiunilor - reflect fluxul de evenimente care sunt efectuate n limitele variantelor de utilizare a unui operand. Diagrama ne arat succesiunea aciunilor n timp i ne ajut s nelegem succesiunea logic a evenimentelor. Adic diagrama de secven prezint temporal obiectele i interaciunile lor. Tipurile de relaii folosite n aceast diagram sunt: simple (sunt de cinci feluri: simple, sincrone, asincrone, timeout, balking) i frecventa (sunt de dou feluri: periodic i aperiodic). Mediul Rose accept urmtoarele tipuri de persisten pentru obiecte:
1.

Persistent: obiectul persistent este stocat ntr-o baz de date sau printr-un alt procedeu i Static: obiecte statice exist pe tot parcursul executrii programului ns se pierd dup ce

va continua s existe chiar i dup terminarea procesului ce l-a creat sau a programului.
2.

programul este terminat.

3.

Temporar: acest tip de obiecte exist un timp foarte scurt i este distrus odat cu Un mesaj (message) este legtura dintre obiecte unde unul din obiecte (client) cere altuia

terminarea procesului ce l-a creat. (server) s execute o operaie. La generarea codului mesajele sunt schimbate la apelarea funciilor. Diagramele succesive conin mesajele sub forma sgeilor trasate de la linia de via a unui obiect la linia de via a altui obiect. n diagramele de colaborare mesajele sunt de-a lungul legturior dintre obiecte. Lucrul cu mesajele pe diagrama de colaborare difer de cel pe diagrama succesiv. Mesajele pot fi transmise doar dac ntre obiecte exist o legtur (link). A doua diferen principal dintre cele dou diagrame de interaciune este c pe diagramele de colaborare este posibil de a arta fluxuri de date, ceea ce nu este posibil de artat pe diagramele de secven. Fluxurile de date se folosesc pentru a arta informaia trimis napoi dup ce un obiect i trimite un mesaj altui obiect. De obicei nu este necesar de a aduga un flux de date unui mesaj, aceasta va face dificil nelegerea diagramei. n dependen de valoarea sincronizrii mesajului se va schimba i sgeata lui. Sincronizarea mesajelor poate lua cinci valori: Simpl (Simple) se folosete implicit. nseamn c toate mesajele sunt executate ntr-un flux de control, se noteaz n felul urmtor:

Sincron (Synchronous) se folosete cnd clientul care a trimis mesaj ateapt rspunsul de la server. Diagramele succesive i cele de colaborare noteaz mesajele sincrone n felul urmtor:

Fr intrarea n lista de ateptare (Balking) dac serverul nu poate executa mesajul primit la momentul dat este pierdut. Acest mesaj se noteaz n felul urmtor:

Cu limit de timp (Timeout) clientul trimite mesaj i ateapt timpul predefinit, dac n acest timp mesajul nu este prelucrat el este pierdut, se reprezint n felul urmtor:

Asincron (Asynchronous) clientul trimite mesaj i nu ateapt rspuns de la server, se noteaz mesajele n felul urmtor:

Fig.3.1. Diagrama secvenelor cu gestionare asincron

Fig.3.2. Diagrama secvenelor cu flux procedural

Alt mod de reflectare a timpului de via al biletului la teatru:

Fig.3.3. Starea obiectului Object Message Sequence Chart n diagram Diagramele de secven i diagramele de colaborare sunt reprezentri alternative pentru interaciuni ntre obiecte. Diagrama de colaborare Diagramele de colaborare prezint interaciunile care au loc ntre diverse obiecte ale unui sistem, punndu-se accentul pe organizarea obiectelor cooperante i nu pe ordonarea cronologic a mesajelor, adic sunt reprezentri spaiale ale obiectelor, legturilor i interaciunilor. Diagramele de colaborare sunt asemntoare celor succesive, ns atenia aici este asupra realaiilor dintre obiecte. Sunt mai uor detectabile relaiile dintre obiecte, ns este mai greu s percepi succesiunea evenimentelor. Din aceast cauz de obicei n proiecte se creaz ambele tipuri i cele succesive i cele de colaborare. Exist posibilitatea de a transforma o diagram a succesiunilor n cea de colaborare i invers apsnd butonul F5. Deci o diagram de colaborare este o diagram de interaciuni care arat secvenele de mesaj ce implementeaz o operaie sau o tranzacie. O diagram de colaborare prezint obiectele, legturile i mesajele dintre ele. De asemenea, diagramele de colaborare pot conine simple instane de clase. Fiecare diagram de colaborare ofer o imagine asupra interaciunilor sau a relaiilor structurale care au loc ntre obiecte i a obiectelor ca entiti n modelul curent.

Diagramele de colaborare conin elemente reprezentnd obiecte. Se pot crea una sau mai multe diagrame de colaborare care s prezinte interaciunile pentru fiecare pachet logic din model; de asemenea, diagramele de colaborare sunt coninute la rndul lor de pachete logice care cuprind obiectele prezente n diagrame. O specificaie a unui obiect poate s indice i s modifice proprietile i relaiile obiectului. Informaia n specificaie este prezentat textual; de asemenea, unele informaii pot fi expuse n interiorul simbolurilor grafice reprezentnd obiecte n diagrama de colaborare. Dac modificm specificaiile obiectului, propietile sau relaiile, diagrama de colaborare ce conine respectivul obiect se va actualiza cu noile date. Dac modificrile proprietilor sau relaiilor unui obiect se fac n cadrul diagramei, atunci se vor actualiza specificaiile obiectului. Obiecte. Un obiect este caracterizat de stri, comportament i identitate. Structura i comportamentul unor obiecte similare sunt definite n clasa lor comun. Fiecare obiect n diagrame indic o instan a unei clase. Un obiect care nu este numit este referit ca o instan a unei clase. Dac ntr-o diagram de colaborare apar diferite obiecte cu acelai nume, ele se consider c reprezint acelai obiect; altfel se consider c fiecare simbol grafic al obiectelor din diagram reprezint obiecte distincte, obiectele ce apar n diagrame diferite sunt distincte, chiar dac numele lor sunt identice. Dac se specific numele clasei obiectului n specificaia obiectului, numele trebuie s identifice o clas definit n model. Reprezentarea grafic. Simbolul grafic pentru un obiect este similar cu cel al unei clase cu diferena c numele obiectului este subliniat:

Legturi. Un obiect interacioneaz prin intermediul legturilor cu alte obiecte. O legatur este o instan a unei asocieri, aa cum un obiect este o instan a unei clase. O legatur trebuie s existe ntre dou obiecte, incluznd utilitile clasei, doar dac este o relaie ntre clasele care corespund respectivelor obiecte. Existena unei relaii ntre dou clase simbolizeaz o cale de comunicaie ntre instanele claselor: un obiect poate trimite mesaje spre alt obiect. Legturile pot susine mai multe mesaje n orice sens. Reprezentarea grafic. ntr-o diagram de colaborare legturile se reprezint printr-o linie ntre obiecte sau ntre obiecte i instane de clase. Pot exista i legturi de la un obiect la el nsui.

n diagrama de colaborare pe legturile dintre obiecte se adaug mesajele corespunztoare acestora. Mesaje. Unitatea de comunicaie ntre obiecte se numete mesaj. Mesajul este suportul unei relaii de comunicaie care leag, n mod dinamic, obiectele care au fost separate prin procesul de descompunere. Ele permit interaciunea flexibil, fiind n acelai timp agent de cuplaj i agent de decuplare. Mesajul asigur delegarea sarcinilor i garanteaz respectarea constrngerilor. Mesajul este un integrator dinamic care permite reconstituirea unei funcii a aplicaiei prin punerea n colaborare a unui grup de obiecte. Puterea sa de integrare se bazeaz pe polimorfism i pe legturile dinamice. Un mesaj regrupeaz fluxurile de control i de date ntr-o entitate unic. Noiunea de mesaj este un concept abstract care poate fi implementat n mai multe variante, cum ar fi: a) apel de procedur; b) eveniment discret; c) ntrerupere; d) datagrama UDP; e) cutare dinamic, etc. Reprezentarea grafic. n diagramele de colaborare mesajele sunt reprezentate prin sgei plasate n lungul legturilor care unesc obiecte, cronologia acestora fiind figurat prin plasarea unui numr naintea mesajului.

unde k este numrul de ordine al mesajului.

Fig. 3.4. Diagrama de colaborare pentru cazul de utilizare a selectrii unui curs Fereastra BROWSER-ului iniial este amplasat n partea stng a interfeei de lucru, mai jos de setul de funcii standarde, i arat n felul urmtor:

Fig.3.5. Fereastra BROWSER-ului Browser-ul organizeaz reprezentarea modelului ntr-o structur ierarhic, ce uureaz navigarea i ne permite s gsim orice element a modelului din proiect. Orice element adugat n model ndat se reprezint i n browser. Browserul deasemenea ne permite s organizm elementele modelului n pachete i apoi cu uurin s le transportm dintr-o reprezentare a modelului n alta. La dorin fereastra dat poate fi amplasat n alt parte a interfeei de lucru sau

n general poate fi ascuns, folosind din meniul principal VIEW. Se poate deasemenea de modificat dimensiunile ferestrei date, cu ajutorul mouseul-ui. Cu ajutorul Browserului putem efectua urmtoarele operaii: Browse Class Diagram Browse Use Case Diagram evideniaz diagramele claselor din toate pachetele evideniaz diagramele variantelor de utilizare din pachete

Browse Interaction Diagram evideniaz diagramele de interaciune din toate pachetele Browse Component Diagram evideniaz diagramele componentelor din toate pachetele Browse Expand Browse Parent Browse Specification Browse Top Level anterioar Browse Referensed Item evideniat Browse Previous Diagram Browse Units (98) Setul special de instrumente Setul special de instrumente este amplasat n partea dreapt a BROWSERUL-ui, n partea central a interfeei de lucru. Iniial este propus setul de instrumente pentru construirea diagramei claselor modelului, acest set arat n felul urmtor: arat diagrama precedent lucreaz cu elementul condus arat diagrama principal a pachetului ce conine obiectul arat diagrama iniial elaborat pentru pachetul evideniat indic printele diagramei evideniate indic fereastra specificaiei obiectelor evideniate indic diagrama etapei anterioare pentru a o modela pe cea

Amplasarea acestui set de instrumente poate fi modificat cu uurin folosind mouse-ul. Exist posibilitatea de adugare sau tergere a butoanelor din setul acesta. Fereastra de diagrame este aria principal de lucru n care sunt vizualizate diferite viziuni a diagramelor proiectului. Iniial aceast ferestr se afl n partea stng a interfeei de lucru, ns pot fi modificate att amplasarea ct i dimensiunile acestei ferestre. La elaborarea unui proiect nou, n cazul cnd nu a fost folosit masterul de proiecte, fereastra este curat, i nu conine nici un element al diagramei.

Report: Show Usage afieaz lista locaiilor unde elementul selectat este folosit; Show Instances afieaz lista tuturor diagramelor de colaborare unde este prezent instanierea clasei selectate; Show Acces Violations afieaz lista tuturor conflictelor ntre pachetele unei diagrame a claselor; Show Participants in UC afieaz lista tuturor participanilor la o preceden selectat; Check Model permite gsirea referinelor nedeterminate ntr-un model. Rezultatul este pus n jurnalul evenimentelor. Model Properties Edit schimb specificrile modelului deschis; Replace nlocuiete setul de proprieti a modelului cu un nou set dintr-un fiier; Export export setul de proprieti a modelului ntr-un fiier; Add actualizeaz proprietile modelului cu datele dintr-un fiier; Update actualizeaz datele dintr-un fiier cu proprietile modelului deschis; Options permite modificarea proprietilor aplicaiei Rational Rose; Open Script deschide un fiier surs a limbajului RoseScript; New Script creeaz un nou cod surs a limbajului RoseScript; Synchronize lanseaz Rational Suite Synchronizer. Window Cascade aranjeaz ferestrele diagramelor deschise n cascad (una deasupra alteia); Title aranjeaz ferestrele diagramelor deschise astfel nct fiecare este vzut. Arrange Icons aranjeaz ferestrele minimizate a diagramelor deschise (doar cnd ele sunt amplasate haotic) Help Contents and Index apeleaz ghidul de utilizare a aplicaiei Rational Rose; Search for Help on... caut informaia cu privire la o anumit tem; Using Help folosete informaie cu privire la modul de folosire a ghidului de utilizare; Extended Help obine informaii cu ajutorul Rational Unified Process; Contacting Technical Support apeleaz la suportul tehnic prin Internet precum i alte metode (telefon, fax, e-mail); Rational on the Web obine Pagina Web a companiei Rational Rose; About Rational Rose obine informaii cu privire la versiunea programului Rational Rose precum i a componentelor sale standard i adiionale. Elaborarea diagramei interaciunilor n mediul Rational Rose

Aceast diagram poate fi activat prin una din metodele: Tastai click pe butonul cu imaginea acestei diagrame pe panoul de instrumente standard din meniul principal: Browse -> Interaction Diagram Dup efectuarea operaiunilor de mai sus apare un loc liber pentru aranjarea elementelor diagramei interaciunii, care sunt alese din setul de instrumente speciale specifice numai pentru aceast diagram:

Construirea diagramei interaciunilor se reduce la adugarea i eliminarea obiectelor separate i a mesajelor, ct i a specificaiei lor. Accesul la specificaia acestor elemente este organizat prin meniul contextual, sau prin punctul browse->specification. La adugarea mesajelor la diagram ele automat primesc un numr specific numai unui mesaj. Diagrame Sequence. Diagramele de secven prezint interaciunile care au loc ntre diverse obiecte ale unui sistem, ordonate cronologic. Ele determin obiectele i clasele implicate ntr-un scenariu i secvenele de mesaje transmise ntre obiectele necesare ndeplinirii funcionalitii scenariului. Diagramele de secven sunt asociate unui caz de utilizare. Fiecrui obiect, clas i corespunde o linie a timpului, reprezentat printr-o linie punctat sub reprezentarea obiectului. Mesajele transmise ntre obiecte sunt reprezentate prin sgei etichetate cu numele mesajului. Bara de instrumente special proprie Diagramei Sequence

1 2

6 7

1. Comanda de selectare. 2. Comanda de scriere a unui text. 3. Comanda de adugare a unui comentariu. 4. Comanda de legare a comentariului de elementul pe care-l nsoete. 5. Comanda de adugare a unui obiect. 6. Comanda de adugare a unui mesaj transmis de un obiect altui obiect. 7. Comanda de adugare a unui mesaj transmis de un obiect lui nsui. 8. Comanda de adugare a unui mesaj de rspuns. 9. Comanda de adugare a punctului terminus a liniei timpului (proprie fiecrui obiect).

Fig.3.6. Diagrama secvenelor pentru cazul de utilizare ncheie contract Productorul de energie electric propune gama sa de servicii i produse. Conducerea ntreprinderii Union Fenosa analizeaz oferta apoi negociaz preurile i condiiile cu productorul. n cazul cnd ajung la o nelegere comun este ncheiat contractul.

Fig.3.7. Diagrama secvenelor pentru cazul de utilizare Achit factura O dat ce factura este ntocmit, contabilitatea o transmite consumatorului. Consumatorul verific i el contorul i calculeaz consumul de energie. n cazul cnd calculele sale corespund cu cele din factur el achit factura la banc.

Fig.3.8. Diagrama secvenelor pentru cazul de utilizare Conectare O persoan sau o firm dac dorete s fie racordat la reelele Union Fenosa trebuie s nainteze o cerere conducerii Union Fenosa. Aceasta consult Departamentul Tehnic n vederea posibilitii conectrii persoanei date. Dac este posibil conectarea, persoana ce a naintat cererea trebuie s achite taxa de conectare. Contabilitatea primind banii anun conducerea, care d dispoziie de conectare. Departamentul Tehnic conecteaz solicitantul la reelele electrice.

Fig.3.9. Diagrama secvenelor pentru cazul de utilizare ntocmete factura

Un angajat al Departamentului control, responsabil de citirea datelor de la contoare consult contorul unui consumator. Datele citite sunt transmise altui angajat al aceluiai departament, care calculeaz consumul curent. Datele prelucrate sunt transmise la contabilitate, unde este ntocmit factura. Aceasta fiind transmis apoi consumatorului. Elaborarea diagramei de colaborare n mediul Rational Rose Diagrama de cooperare este un alt mod de reprezentare grafic a interaciunilor n model, la fel ca i diagrama interaciunilor opereaz cu obiecte i mesaje. Specificul acestei diagrame n mediul Rational Rose este c dup construirea diagramei interaciunilor la apsarea tastei F5 diagrama de colaborare se genereaz automat. Tot cu ajutorul acestei taste se face trecerea de la diagrama interaciunilor la diagrama de cooperare i invers. Dup ce a fost activat diagrama interaciunilor setul special de elemente primete urmtoarea form:

Fig.3.10. Setul special de elemente pentru diagrama de colaborare Pe acest panou sunt amplasate butoanele cu imaginea elementului respectiv. Lucrul cu aceast diagram n mare msur se aseamn cu celelalte diagrame, i const n adugarea i eliminarea elementelor din ea i a specificaiei acestor elemente. Fcnd schimbri n diagrama de cooperare totodat facem schimbri i n diagrama interaciunilor apsnd tasta F5 Diagramele de colaborare prezint interaciunile dintre obiecte organizate relativ la acestea i a legturilor dintre ele. Diagramele de colaborare conin: - obiecte, n reprezentarea lor grafic sub form de dreptunghiuri; - legturi ntre obiecte, reprezentate grafic prin linii de conectare; - mesaje, reprezentate ca etichete ale legturilor, i care conin o sgeat ndreptat spre obiectul server (receptor al mesajului). Bara de instrumente speciale proprie Diagramei Collaboration

9 10 11 12

1. Comanda de selectare. 2. Comanda de scriere a unui text.

3. Comanda de adugare a unui comentariu . 4. Comanda de legare a comentariului de elementul pe care-l nsoete. 5. Comanda de adugare a unui obiect. 6. Comanda de adugare a unei instane de clas. 7. Comanda de adugare a unei legturi dintre 2 obiecte. 8. Comanda de adugare a unei legturi a obiectului cu el nsui. 9. i 10. Comanda de adugare a unei legturi dintre 2 obiecte ntre care se transmit mesaje. 11. i 12. Comanda de adugare a unei legturi dintre 2 obiecte ntre care se transmite fluxul de informaie.

Fig.3.11. Diagrama de colaborare pentru cazul de utilizare ncheie contract

Fig.3.12. Diagrama de colaborare pentru cazul de utilizare Achit factura

Fig.3.13. Diagrama de colaborare pentru cazul de utilizare Conectare

Fig.3.14. Diagrama de colaborare pentru cazul de utilizare ntocmete factura

Spre deosebire de diagramele Collaboration care ne prezint doar interaciunile dintre obiecte i mesajele transmise ntre ele, diagramele Sequence ne prezint evoluia lor n timp, astfel ele sunt uor de citit i neles.

ntrebri de control: 1. Numii deosebirile dintre diagrama succesiunilor i diagrama de colaborare. 2. Care sunt caracteristicile de baz ale diagramei interaciunii? 3. Cte tipuri de persisten pentru obiecte accept mediul Rose? 4. Ce valori poate lua sincronizarea mesajelor? 5. Cum transformm automat diagrama succesiunilor n diagrama de colaborare? 6. Descriei diagrama de colaborare. 7. Definii noiunile de obiect, legturi i mesaje.

LUCRAREA DE LABORATOR NR. 4-5 TEMA: Studiul i analiza abstraciilor, claselor, pachetelor i obinerea codului surs n instrumentele CASE Scopul lucrrii: 1. Studierea abstraciilor, claselor, pachetelor i obinerea codului surs la diverse nivele n instrumentele CASE: Noiunile generale i exemplele lucrrii recente i din fiierul Supliment1_2GenCod.doc. Analizai i descriei exerciiile propuse. 2. Efectuai punct. 2-6 i expunei scenariile i rezultatele cu analiza de rigoare i cte 3 exerciii din respectivele compartimente [1. Boggs] 3. Crearea i precizarea diverselor tipuri de clase: active, abstracte, concrete, parametrizate i stereotipurilor pentru dezvoltarea propriilor modele din lucrrile (Ll) precedente. 4. Crearea, construirea exemplarelor claselor, categoriei claselor, metaclaselor i descriptoarelor. 5. Analiza architecturii produsului software implementat n pachetele claselor. 6. Generarea codului surs n limbajul C++ pentru diverse cazuri. 7. Descrierea scenariilor efecturii fiecrui punct. Sarcina: Pentru sistemul din lucrarea de laborator Nr.2 elaborai cte cinci diagrame a claselor. Pentru 2 clase generai codul n C++. Noiuni generale i exemple. Abstractizarea Tipurile abstracte de date reprezint una din principalele noiuni n modelarea obiect orientat, rolul principal n acest caz l joac noiunea de clase. Tendina spre elaborarea mecanismelor adecvate de abstarctizare poate fi considerat ca impuls n dezvoltarea metodicilor contemporane de modelare, ct i a limbajelor de programare. Deci absractizarea este rezultatul creterii volumului de informaii necesar pentru proiectarea i elaborarea sistemelor mari, corectitudinea algoritmilor fiind pe locul doi. Aadar sunt necesare mecanisme ce permit accesarea datelor n form independent de reprezentarea concret a acestora. Astzi este practic imposibil de creat o arhitectur (corect) a sistemului soft n ierarhia obiectual a cruia s nu existe nivele de abstarctizare, ce permit descrierea comportamentului, necesitilor i obligaiunilor sistemului soft. Abstarctizarea n diferite forme i sens este prezent pe parcursul ntregului ciclu de proiectare i elaborare, ceea ce permite o analiz mai calitativ, n rezultat contribuind la perfecionarea caracteristicilor sistemului.

Mecanismul ce permite accesarea entitilor n form independent de reprezentarea concret a abstraciilor, care pot fi: clase, clasificatori, precedente, semnale, metode, atunci cnd este posibil generalizarea. n cazul claselor, acestea nu pot avea instane (doar dac sunt derivate), i n cazul metodelor lipsete realizarea concret, fiind prezent numai apelul (aa metode se numesc virtuale). Abstractizarea reprezint rezultatul necesitii proiectrii i implimentrii unor sisteme enorme. Astfel atenia se concentreaz, considerabil, asupra formelor de informaie (pn ce date) i nu asupra algoritmilor de realizare. Unul din avantajele aplicrii tipurilor abstracte de date presupune identificarea, dar nu ntotdeauna. Modelul matematic ce permite descrierea formal a comportamentului acestui tip, n sensul complex al analizei sistemelor, se dezice de metode matematice deoarece devine imposibil de analizat masive enorme de informaie. n diferite limbaje, conceptul de abstractizare (lund n consideraie necesitile timpului) este realizat n mod diferit, principalul avantaj fiind ascunderea informaiei la trecerea de la un nivel la altul. La nceput au fost propuse module (aa cum ele au fost realizate n Modula 2 i Ada), dar ntruct acesta purta caracter pur sintactic (adic nu exist reguli ce ar rspunde la ntrebarea cum programul trebuie s fie divizat pe pri ?), i nu semantic, se consider neeficient n sensul secretizrii. Soluie eficient propune paradigma obiect orientat ncapsularea, motenirea (determin flexibilitatea) i constructive n diverse limbaje ce permit realizarea concret a tipurilor. Din punct de vedere formal realizarea abstraciei informaiei se poate considera una din metodele de specificare i verificare ale sistemelor soft. Din alt punct de vedere precum scrie Stroustrup, nafar de teoria matematic strict care st la baza acestora, neajunsul tipurilor de date abstracte este flexibilitatea, adic lipsa flexibilitii n msura necesar, ceea ce evideniaz necesitatea unor soluii. Obiectul n UML poate fi neles prin prezena sa abstract. Fiecare obiect are stare, comportament i individualitate. De exemplu, obiectul Proiect poate s aib 2 stri deschis i nchis. Comportamentul obiectului determin, cum obiectul interacioneaz cu alte obiecte. Individualitatea nseamn, c fiecare obiect este unic i difer de alte obiecte. Prin noiunea de clas se nelege descrierea obiectelor, care posed proprieti comune (atribute), comportament, interaciuni comune cu alte obiecte i semantic comun. Clasa poate fi privit ca un ablon pentru crearea obiectelor noi. Fiecare clas poate s aib atribute (clasa Customer Information (Informaie despre client) are atributele Customer ID (identificatorul clientului), Name (nume) i Account (cont)). n afar de aceasta, fiecare clas poate s aib metode (operations) anumite aciuni, care descriu comportamentul obiectelor clasei, adic metoda Check Account.

Clasele pot s aib legturi (relationship), numite relaii. La notarea UML exist cteva tipuri de relaii. Relaia de utilizare associations arat, c obiectul unei clase e legat cu unul sau mai multe obiecte ale altei clase. Relaia de agregare (aggregation) este cazul particular a relaiei de utilizare. Ea arat, c un obiect este partea altui obiect. La afectarea unui obiect, legat cu relaia de agregare, unele operaii n mod automat pot afecta i alt obiect. De exemplu, Customer Information (Informaie despre client) e legat prin relaia de agregare cu clasa Contract. La distrugerea obiectului clasei Customer Information (Informaie despre client) trebuie s fie distruse toate obiectele clasei Contract (Contracte ncheiate de clientul dat). Motenirea (inheritance) descrie interlegtura ntre clase, cnd o clas (numit subclas, subclass) motenete structura i/sau comportamentul unei sau mai multor clase. Subclasa VIP motenete proprietile i comportamentul clasei Customer Information (Informaie despre client). Legtura claselor n ierarhii de motenire se numete relaia de motenire (generalization). Fiecare legtur poate fi caracterizat printr-o fraz anumit, numit numele rolului. Legtura dintre clasele Customer Information (Informaie despre client) i Contract are nume negotiates. Fiecare legtur poate s aib indicatorul de multiplicitate, care arat cte obiecte dintro clas corespund obiectului din alt clasa (legtura negotiates are indicator 1..* (unu sau multe)). Clasele. O clas conine structura i comportamentul comun unui set de obiecte. O clas este o abstracie a entitilor lumii reale. Cnd acestea exist n lumea real, ele sunt instane ale clasei, i atribuite obiectelor. Pentru fiecare clas care are un comportament temporal semnificativ, putem crea o diagram de stare care s descrie acest comportament.

O clas se reprezint grafic printr-un dreptunghi mprit n trei compartimente, n compartimentul de sus se indic numele clasei, n cel din mijloc o list de atribute (cu tipuri opionale i valori), i n ultimul o list de operaii (cu lista de argumente opionale i tipuri de returnare). Compartimentele n care gsim atributele i operaiile pot fi ascunse (n cazul n care coninutul acestora nu este semnificativ pentru contextul diagramei) pentru a reduce detaliile. Ascunderea compartimentelor nu face nici o declaraie despre absena atributelor sau operaiilor, dar desennd compartimentele goale se exprim explicit c nu exist elemente n acele pri (atribute i operaii). Numele claselor. Fiecare clas trebuie s aib un nume. n diagramele claselor, toate simbolurile de clase cu acelai nume se consider c reprezint aceeai clas, indiferent de diagrama n care apare.

Atribute i operaii. Atributele i operaiile pot fi prezentate complet sau nu n compartimentele claselor. Prin convenie, din cele dou compartimente suplimentare ale clasei primul compartiment conine atributele, iar al doilea compartiment conine operaiile. Sintaxa utilizat pentru descrierea atributelor este: Nume_Atribut: Tip_Atribut = Valoare_Initiala Aceast descriere poate fi complet progresiv, de la analiz pn la proiectare. n faza analizei cerinelor se poate specifica de ctre utilizator proprieti redundante, care pot fi eliminate prin utilizarea atributelor derivate, indicnd clar faptul ca aceste proprieti sunt derivate din alte proprieti deja atribuite. Sintaxa utilizat pentru descrierea operaiilor este: NumeOperatie (NumeArgument: TipArg.=ValImplicita, ):TipReturnat Totui, dat fiind faptul c lungimea specificaiei poate fi mare, argumentele operaiilor pot fi suprimate n form grafic. Vizibilitatea atributelor i a operaiilor. UML definete 3 nivele de vizibilitate pentru atribute i operaii: public - element vizibil tuturor clienilor clasei (interfaa pur) (simbol +); protected - element vizibil subclaselor clasei (simbol #); private - element vizibil n interiorul clasei (implementare pur) (simbol -). Informaia privind vizibilitatea, chiar dac este definit n model, poate s nu fie ntotdeauna figurat n mod explicit. Implicit, nivelul de vizibilitate este simbolizat prin caracterele: +, #, - .

Fig.4-5.1. Vizibilitatea atributelor i operaiilor

Anumite atribute i operaii pot fi vizibile global, n toate expresiile lexicale ale clasei. Aceste elemente denumite variabile i operaiile de clas, sunt reprezentate ca i obiectele prin sublinierea numelor. Notaia se justifica prin faptul c o variabil de clas apare ca un obiect partajat de instanele clasei. Prin extensie, operaiile clasei sunt de asemenea subliniate. Reprezentarea atributelor i operaiilor din punct de vedere al vizibilitii acestora.

Fig.4-5.2. Atribute i operaii vizibile global n UML exist 4 tipuri de legturi ntre clase: 1) Asociere (association relationship)

Fig.4-5.3. Asocierea n notaie UML

Fig.4-5.4. Asociere multipl

Fig.4-5.5. Cardinalitatea asocierii

Fig.4-5.6. Asociere complex

Fig.4-5.7. Agregarea n notaie UML 2) Generalizare (generalization relationship); 3) Dependena (dependency relationship); 4) Realizare (realization relationship).

Asocierea spune despre existena unei relaii ntre clase. Dependena se folosete atunci cnd se arat dependena ntre dou esene. Agregarea se aplic pentru a arta c o clas conine n sine alt esen. Realizarea se utilizeaz pentru descrierea faptului c o clas motenete toate proprietile clasei printe. Asocierile sunt relaii structurale ntre clase de obiecte. O asociere simbolizeaz o informaie a crui durat de via este neneglijabil n raport cu dinamica general a obiectelor instane ale claselor asociate. Majoritatea asocierilor sunt binare, conectnd 2 clase. Asocierile sunt reprezentate prin linii care unesc clasele asociate. Asocierile pot fi reprezentate prin trasee rectilinii sau oblice, n funcie de preferinele utilizatorului. Experiena recomand utilizarea unui singur stil de reprezentare a traseelor pentru simplificarea citirii diagramelor unui proiect. Majoritatea asocierilor sunt binare, adic sunt relaii ntre dou clase. Totui pot exista asocieri multiple reprezentate prin intermediul unui romb ctre care vin trasee de la diferitele componente ale asocierii. Asocierile multiple pot fi reprezentate n general avansnd asocierea la rang de clas i adugnd constrngeri care bratele multiple ale asocierii se instaniaz toate simultan. Ca i la asocierile binare, extremitile unei asocieri multiple sunt denumite roluri i pot purta un nume. Dificultatea de a gsi un nume diferit fiecrui rol al unei asocieri multiple este adesea semnul unei asocieri de multiplicitate inferioar. Asocierile pot fi numite, numele asocierii fiind figurat cu litere italice (nclinate) la mijlocul liniei care simbolizeaz asocierea. Se recomand utilizarea unei faune verbale (limbaj verbal) pentru numirea asocierilor: activ i pasiv. n ambele cazuri, sensul citirii numelui poate fi precizat prin intermediul unui mic triunghi cu un vrf de unghi ndreptat ctre clasa indicat prin fauna verbala i plasat n apropierea asocierii. Pentru simplitate triunghiul poate fi nlocuit cu semnele < sau > disponibile tuturor font-urilor. Asocierile ntre clase exprim n primul rnd structura static, fapt pentru care numele sub forma verbal, care evoc mai degrab comportamentul, se gsesc puin n afara spiritului general al diagramelor de clase. De aceea, numirea extremitilor relaiilor permite clasificarea diagramelor ca i numirea asocierilor, dar ntr-o form mai pasiv, mai potrivit orientrii statice a diagramelor de clase. Numele rolurilor. O extremitate a unei asocieri poart numele de rol, astfel asocierile binare cu dou roluri, au la fiecare extremitate cte unul. Rolul descrie modul n care o clas vede o alt clas dincolo de o asociere. Rolul este numit prin intermediul unei forme nominale, vizual deosebindu-se de asociere prin faptul c este figurat cu litere obinuite i este plasat la una din extremitile unei asocieri.

Numirea asocierilor i a rolurilor nu se exclud reciproc, dei n practic cele dou construcii rar se combin. De obicei se ncepe prin completarea unei asocieri printr-un verb, care va servi mai trziu pentru a construi un substantiv verbal care denumete rolul corespunztor. Atunci cnd dou clase sunt legate printr-o singur asociere, numele claselor este adesea suficient pentru a caracteriza rolul, urmele rolurilor avnd eficien atunci cnd mai multe asocieri leag dou clase, fiecare exprimnd un concept distinct. Prezena unui numr mare de asocieri ntre dou clase poate fi suspect. Fiecare asociere adaug un cuplaj ntre cele dou clase, iar cuplajul puternic indic o descompunere greit. Pe de alt parte, acesta poate fi sensul figurrii de mai multe ori a aceleiai asocieri, numind fiecare asociere cu numele mesajelor care circul ntre obiectele instan ale claselor asociate. Sensul aplicrii claselor const n imitarea obiectelor lumii reale unificnd proprietile cu comportamentul, ceea ce simplific i contientizeaz perceperea esenei problemelor reale ce pot fi rezolvate aplicnd acest concept. Generalizarea comportamentului unui set de obiecte, ce poart denumirea de exemplare ale clasei date ([1] poate fi tratat ca un template pentru obiecte). n paradigma obiectual orientat, clasa este entitatea minimal ce posed denumire (identificatorul clasei trebuie s fie unical), proprieti i comportament, proprietile se numesc atributele clasei, iar comportamentul setul de operaii sau metodele clasei ce determin cile de comunicare cu lumea extern (deci obiectele acestor clase prin intermediul metodelor pot iniia schimb de informaii) aceasta se numete ncapsulare. Numele clasei numaidect trebuie s poarte sens n contextul corespunztor (CRect class rectangle) deoarece aceasta influeneaz asupra nelegerii locului i hotarelor clasei n ierarhie, aceasta este valabil i pentru atributele (bottom, left, ... ce vor indica dimensiunile zonei) i metodele (BottomRight indic coordonatele punctului bootom.reght).

Dac clasa intr n componena pachetului atunci numele clasei va fi precedat de numele pachetului, de exemplu Package_name::CRect. Conceptul dat permite n baza unor clase obinerea altor de generalizare sau de precizare, acest fenomen poart denumirea de motenire. Am menionat despre necesitatea unor soluii ce ar nltura dezavantajul n privina lipsei flexibilitii, referitor la clase aceast problem rezolv mecanismul de motenire (discuiile despre corectitudinea i eficiena acestui mecanism i astzi sunt actuale, mai ales n sensul motenirii

multiple). Dac privim clasele ca tipuri, atunci motenirea este mecanismul de sintez a tipurilor polimorfe. Deci o clas derivat din alt clas (numit clasa de baz), se consider subtipul clasei de baz (ce este privit ca tip). n afar de aceasta exist nc un moment important, existena mecanismelor de protecie a fragmentelor critice de informaie n cadrul clasei, aa numitor specificatorilor de acces (printre altele suportul specificatorilor de acces determin msura n care limbajul de programare susine paradigma obiect orientat). Necesitatea acestui mecanism este evident n cazul sintezei unui subtip, cnd exist pericolul afectrii contiente sau incontiente ale informaiei clasei de baz din partea celei derivate. Clasele abstracte Se numesc abstracte clasele ce nu posed instane, i se folosesc numai pentru sinteza noilor subclase ce ncapsuleaz proprieti i comportament asemntor (n calitate de leaf aceste clase nu sunt utile i se folosesc pentru susinerea ierarhiei) i n aa mod precizeaz cele preluate din clasa de baz aceste subclase deja pot avea instane i pot fi utilizate direct. [2] Clasele abstacte se creaz i atunci cnd exist un set de metode ce utilizeaz atributele i alte metode numai din clasa dat, i acest set poate fi abstractizat (simplu de prezentat comportament comun) pentru ncapsulare n subclase. Clasa abstract poate fi creat prin declararea unei metode virtuale, de exemplu aceasta poate fi destructorul (i nici ntr-un caz constructorul), pe cnd celelalte metode pot fi concretizate acele metode ce posed cod propriu i pot fi utilizate n clasa derivat. Abstracte pot fi i precedentele acestea prezint comportament dependent, adic intr n componena altor precedente prin utilizarea relaiilor de extindere (extend), includere (include) sau generalizare. Acest principiu rmne valabil i pentru celelalte elemente din model. Astfel putem ajunge la o claritate n proiectarea i analiza unui sistem soft. Calss A { virtual ~A() = 0; }; A::~A() { };

n privina exemplului CRect putem meniona c acesta poate fi n calitate de clas abstract pentru toate subclasele (ce prezint de exemplu elemente grafice) la baza crora este dreptunghiul

cum sunt butoanele din windows (n realitate n windows toate elementele vizuale de tip fereastr (de exemplu butoanele) iniial sunt motenite din CWnd).

Clasele root i clasele leaf Leaf sunt subclase finite n sens c nu se folosesc pentru obinerea altor clase, adic ele nu se utilizeaz pentru motenire ci sunt folosite direct prin crearea instanelor. Clasele leaf se gsesc pe ultimele nivele (cele de jos) ale arborelui ierarhic, i deci sunt cele mai specializate condiiilor concrete. Root sunt clasele generalizate ce sunt destinate pentru crearea altor clase specificate ntr-o msur mai mare (n schema precedent dac presupunem c din clasa CButton nu se vor deriva subclase, atunci Cbutton este leaf i CRect va fi root). De exemplu clasele abstracte pot fi de tip root (nu numai pot fi dar i trebuie s fie ns aceasta este doar o recomandare, nu se tie dinainte dac clasa dat rmne concret pn la finisarea proiectrii, n practic aceasta se ntlnete des de exemplu din cauza divizrii sarcinilor clasei) atunci prin motenire se creaz clase concrete, i nici ntr-un caz nu pot fi leaf, deoarece aceasta nu aduce nici un folos clasele abstracte nu posed instane (cum am menionat se folosesc pentru claritatea ierarhiei).

Clasele utilitare (utilite) Ex var SQL, selectClausem fromClause: string; .... selectClause = SELECT * ; fromClause = FROM ; n descrierea claselor abstracte SQL = selectClause + fromClause + numeRelaie; // primim: SELECT * FROM Staff am menionat despre faptul c putem crea

clase abstracte [2] n cazul cnd exit set de atribute i operaii ce folosesc atribute numai din clasa dat i totodat nu determin hotarele concrete, i pot fi ncapsulate total n diverse clase cu comportament diferit i destinaie diferit. Exist i alt soluie elegant clasele utilite (Utility class), ce prezint prin sine unificarea acesui set de operaii, apoi folosit n calitate de extensie pentru alte clase sau chiar extensii ale limbajelor de programare. De exemplu avem set de operaii destinat prelucrrii irurilor de caractere, i poate fi subset de operaii a mai multor clase ce folosesc string-uri, cum este TSQLQuery din Delphi ce pstreaz i prelucreaz masiv de string-uri fiecare fiind interogare SQL, i acest set de operaii simplific considerabil manipularea interogrilor. Clasele parametrizate, utilitele claselor parametrizate i clasele acumulatoare Reprezint un tip special de clase ce se utilizeaz pentru crearea familiilor de clase. Am menionat c o clas poate fi tratat ca template pentru obiecte, clase parametrizate (Parametrized class) deasemenea pot fi tratate ca template [1], dar deja pentru alte clase (deoarece ele reprezint meta clase i instanele lor sunt clase i nu obiecte. Din meta clase fac parte clasele parametrizate i utilitele lor. De exemplu avem nevoie s crem un tablou grafic, pentru aceasta putem utiliza clasa CRect, care vor fi elemente ale tabloului (apoi clasa CTable poate fi util pentru crearea Grid-ului, sau tabloului de butoane). Argumentul acestei clase se indic n dreptunghiul punctat, n baza acestui argument se creaz elementele clasei (n calitate de argument pot fi diverse elemente, att alte clase, ct i elemete simple: structuri, iruri sau numere numrul de argumente nu este limitat). Alt tip de clase parametrizate sunt clasele acumulatoare, argumentele acestora fiind valori efective, astfel prelund valoarea argumentului putem determina sublista unor obiecte ce se pstreaz n lista iniial. n UML clasele acumulatoare (Instantiated class) sunt vizual aseamenea claselor simple, deosebirea fiind numele clasei (mpreun cu argumentele) plasat ntre simbolurile <Numele clasei>. Clasele parametrizate deasemenea pot fi create n baza claselor utilite, pentru aceasta sunt destinate clasele utilite parametrizate (parametrized class utility), acestea reprezint template cu operaii pentru clasele parametrizate. Pentru clasele acumulatoare deasemenea exist utilitele claselor acumulatoare (instantiated class utility), parametrii acestora fiind valori efective. Instanele i caracteristicele lor. Instan (instance), exemplar sau obiect (object) reprezint descrierea unei entiti din lumea real (conform paradigmei obiect orientate) sau abstract (abstract entity). Deci este o abstracie cu hotarele implicit (garantat) determinate, sens i destinaie

concret n contextul sistemului soft. Oricare ar fi obiectul din sistem, acesta posed trei caracteristici necesare: stare, comportament, identificator. Starea (state) este o succesiune de condiii ce determin existena obiectului, starea obiectului se determin prin intermediul setului de atribute (valorilor acestor atribute) i legturi cu alte obiecte i cu timpul pot fi supuse modificrii. Comportamentul (behavior) cuprinde partea funcional a existenei (ciclului de via) obiectului i determin reacia lui la interogrile din partea altor obiecte, adic interogri din lumea extern, i se realizeaz prin intermediul operaiilor/metodelor. Identificatorul (identity) semnific proprietatea unic a obiectului.

n UML obiectele sun prezentate prin dreptunghi cu numele subliniat (mpreun cu numele obiectului se indic i tipul). Dac obiectul conine numai tipul i numele fiind lips atunci obiectul se numete anonim (din dreapta).

Mecanismele comune UML definete un mic numr de mecanisme comune care asigur integritatea conceptual a notaiilor. Aceste mecanisme comune cuprind: stereotipurile - specializeaz clasele metamodelului (ext.); etichetele - extind atributele claselor metamodelului (ext.); notele; constrngerile - extind semantica metamodelului (ext.); relaia de dependen; dualitile (tip, instana) i (tip, clasa). 1.Stereotipurile fac parte din mecanismele de extensibilitate prevzute de UML. Fiecare element de modelare al UML poate avea un stereotip atunci cnd semantica elementului este insuficient. Stereotipul: permite metaclasificarea unui element al UML; permite utilizatorului (metodologist, constructor de utilitare, analist, proiectant) s adauge noi clase de elemente de modelare, n plus fa de nucleul predefinit de UML; uureaz unificarea conceptelor apropiate, cum ar fi subsistemele sau categoriile, care sunt exprimate prin intermediul stereotipurilor de mpachetare; permite extinderea controlat a claselor metamodelului, de ctre utilizatorii UML, un element specializat printr-un stereotip S fiind semantic echivalent cu o nou clas a metamodelului, denumit ea nsi S.

De fapt, toat notaia UML poate fi construit pornind de la clasele Entitate i Stereotip, celelalte concepte putnd fi derivate (specializate) prin aplicarea mecanismului Stereotip asupra clasei Entitate. Creatorii UML au cutat un echilibru ntre: clasele incluse de la nceput; extensiile obinute prin stereotipizare, astfel nct: doar conceptele fundamentale au fost exprimate sub form de clase distincte; celelalte concepte, derivabile din cele de baz, au fost tratate ca stereotipuri. O clas poate conine i un stereotip cu proprietile sale. UML definete urmtoarele stereotipuri de clase: <<signal>>, o situaie special care declaneaz o tranziie ntr-un automat; <<interface>>, o descriere a operaiilor vizibile; <<metaclass>>, clasa de clase (ca n Smalltalk); <<utilitare>>, o clas redus la conceptul de modul i care nu poate fi instaniat. De exemplu este necesar s crem forme (cum este HTML Form) pentru diverse servicii ale sistemului nostru, pentru aceasta introducem stereotipul System Form, ce poate fi asociat clasei. Exemple de stereotipuri sunt entitate (entity), hotar (boundary), gestiune (control), excepie (exception), domeniu (domain), interfa (interface), enumerare (enum) uniune (union). [3] Stereotipurile divizeaz elemetele (comune) pe grupe cu comportament comun, aceasta este foarte util n sisteme mari permite organizarea clar a arhitecturii sistemului soft. n UML denumirea stereotipului se indic deasupra numelui elementului (de exemplu deasupra numelui clasei) plasat ntre simbolurile <<>> (<<System Form>>). Stereotipul este un mecanism ce ne d posibilitatea de a mpri n categorii clasele. n limbajul UML stereotipurile sunt de trei feluri : Boundary (Hotar), Entity (Obiect), Control (Control). Stereotipul clasa entitate (class entity). Clasele entitate modeleaz structura i comportametul datelor, ce difer prin caracterul su stabil (de regul aceste clase sunt create la etapa de planificare). Clasele acestui stereotip se utilizeaz pentru execuia funciilor interne ale sistemului i cel mai important reflect calitatea entitilor (abstraciilor) lumii reale i aceste clase sunt independente de mprejurri, adic nu sunt flexibile la faptul cum factorii externi influeneaz asupra funcionrii sistemului. Pentru depistarea stereotipurilor este necesar diferenierea sferelor

de responsabilitate ale sistemului, n baza analizei fluxului de evenimente, ce cuprinde anumite scenarii. Clasele entiti sunt necesare sistemului pentru susinerea funciilor diferitor sfere de responsabilitate. Stereotipul clas hotar (boundary class). Clasele hotare deservesc procesele de interaciune dintre sistem i lumea exterioar (sunt acea parte a sistemului ce nemjlocit comunic cu exteriorul adic clasele sunt necesare pentru modelarea mijloacelor de comunicare), asigurnd interfaa pentru utilizator sau alt sistem (subiect activ). Pentru depistarea claselor hotare se analizeaz perechile de tip subiect activ / scenariul. Aceste clase asemenea claselor entiti se depisteaz la etapa de planificare, i de regul se deosebesc prin gradul de detaliere sczut. Acum este de folos modelarea i documentarea funciilor interfeei grafice ce se privete n complex (n complex nseamn descrierea generalizat i nu concret de exemplu diferite butoane ale meniurilor i panourilor). n procesul proiectrii aceste clase se detalizeaz n dependen de mecanismele alese pentru implementarea lor. Stereotipul clas de gestiune (control class) Clasele de gestiune se utilizeaz pentru realizarea caracteristicilor de comportament ale sistemului ce sunt caracteristice unor scenarii i coordoneaz evenimentele, ce se produc pe parcursul funcionrii sistemului n cadrul acestor scenarii. Aceste clase pot fi considerate abstracii ce prezint dinamica scenariilor. Pentru depistarea lor asemenea claselor hotar se analizeaz perechile de tip subiect activ / scenariul n primele stadii ale ciclului de via i pentru fiecare pereche se creaz o clas de gestiune, sarcina lui fiind controlul fluxurilor de evenimente ce se produc pe parcursul acestui scenariu.

CerereOptionala Creare()

CerereCorecta Creare() Salvare() Refuz()

OrganizareaCererei Creare() Setare() Info()

Tranzactie Comitere() Salvare() Cerere Salvare()

Fig.4-5.8. Diagrama claselor prin stereotipuri Din diagram se observ c CerereCorecta rspunde de corectitudinea ndeplinirii cererii; CerereOptioanala permite opiuni adugtoare asupra cererii; Cerere este chiar cererea; Tranzactia urmrete ca s se ndeplineasc tranzacia cererii; OrganizareaCererei realizeaz cererea pentru a fi apoi transmis.

2. Etichetele. O etichet este o pereche (nume, valoare) care descrie o proprietate a unui element de modelare. Proprietile permit extinderea atributelor elementelor metamodelului. O etichet modific semantica (nelesul) elementului pe care l calific. 3.Notele. O not cuprinde ipotezele i deciziile aplicate n timpul analizei i reprezentrii grafice. Notele pot conine orice informaie, inclusiv textul planului, fragmente de cod sau referine la alt document. O not conine un volum nelimitat de text. n consecin, notele pot fi dimensionate. Notele se comport ca nite etichete. Ele se pot folosi n orice fel de diagram. Notele sunt doar explicaii oferite acolo unde apar n diagram. Ele nu sunt considerate ca facnd parte din model. Ele pot fi terse ca orice alt component a diagramei. 4.Ancora notei. Ancora notei conecteaz o not la un element pe care l simuleaz. Aceste elemete pot lega o not de un element sau mai multe elemente ale diagramei respective. O not poate s nu fie conectat, caz n care aceasta se refer la ntreaga diagram. 5.Constrngerile {..}. O constrngere este o relaie semantic ntre elementele de modelare. UML nu specific o sintax particular pentru constrngeri, care pot fi exprimate: n limbaj natural; n pseudocod; prin expresii de navigare; prin expresii matematice. 6.Relaia de dependen. Relaia de dependen definete o relaie de utilizare unidirecional ntre dou elemente de modelare, denumite sursa i inta relaiei. Notele i constrngerile pot fi de asemenea surse ale unei relaii de dependen. 7.Dualitile (tip, instana) i (tip, clasa). Multe elemente de modelare prezint dualitatea (tip, instana), n care: tipul denot esena elementului, iar instana cu valorile sale corespund unei manifestri ale acelui tip. De asemenea, dualitatea (tip, clasa) corespunde separrii ntre: tipul, clasa, care furnizeaz realizarea acestei specificri. Diagrame de clase Diagramele de clase exprim la modul general structura static a unui sistem, n termeni de clase i de relaii ntre aceste clase. Aa cum o clas descrie un ansamblu de obiecte, o asociere descrie un ansamblu de legturi: obiectele sunt instane ale claselor, legturile sunt instane ale asocierilor. Diagramele de clase i diagramele de obiecte sunt reprezentri alternative pentru modelele obiectelor. Diagramele de clase conin clase i diagramele de obiecte conin obiecte, dar se pot mixa clasele i obiectele atunci cnd este de vorba de diferite tipuri de metadate. Diagramele de clas sunt mult mai relevante dect cele de obiecte. De obicei, se construiesc diagramele de clase i ocazional diagramele de obiecte pentru a ilustra structuri de date complicate sau transmiteri de mesaje.

Diagramele de clase conin simboluri grafice pentru clase. Se pot crea una sau mai multe clase pentru a reprezenta clasele din nivelul de vrf al modelului curent. De asemenea, se pot crea una sau mai multe diagrame de clase pentru a reprezenta fiecare pachet din model, clase care sunt, coninute n pachetul ce cuprinde clasele de reprezentat. Dac se modific proprietile sau relaiile unei clase prin editarea specificaiilor sale, diagramele de clase ce conin aceste clase se actualizeaz conform acestor modificri. Dac modificrile au loc n cadrul unei diagrame de clase, se vor actualiza specificaiile clasei i celelalte diagrame de clase care conin aceast clas. Diagramele de clase se utilizeaz pentru analiza, n care se arat rolurile i responsabilitile comune ale entitilor ce descriu comportamentul sistemului i pentru proiectare, unde se indic structura claselor ce formeaz arhitectura sistemului. Construcia diagramelor de clase are loc n faza de elaborare a sistemului informatic fiind cele mai importante din aceast faz. Bara de instrumente speciale proprie Diagramei Class

9 10 11 12

1. Comanda de selectare. 2. Comanda de scriere a unui text. 3. Comanda de adugare a unui comentariu . 4. Comanda de legare a comentariului de elementul pe care-l nsoete. 5. Comand de adugare a unei clase. 6. Comand de adugare a unei interfee. 7. Comand de adugare a unei asociaii. 8. Comand de adugare a unei clase de asociere. 9. Comand de adugare a unui pachet. 10. Comand de adugare a unei dependene. 11. Comand de adugare a unei generalizri. 12. Comand de adugare a unei realizri.

Pachetele Esene de grup

Arhitectura presupune divizarea sistemului n elemente mai specifice (din punct de vedere al apartenenei sau funcional) subsisteme, i relaiile dintre ele, acest scop poate fi atins prin integrarea pachetelor n structur (conceptual). Deci sistemul poate fi divizat conform criteriului (sau combinaiei de criterii) funcional, adic toate clasele ce posed rspundere funcional asemntoare sunt plasate ntr-un pachet aparte, i atunci putem obine o imagine mai clar a funcionalitii. n calitate de exemplu poate servi setul de clase ce sunt obligate s gestioneze intrarea utilizatorului n baza de date, conectarea, autentificarea, certificarea, acordarea drepturilor, etc. Toate acestea pot fi privite ca un serviciu unic al sistemului de gestiune, adic subsistem, i deci prezint o esen de grup (atragei atenia c sistemul principal de asemenea este prezentat n form de pachet). Alt criteriu de grupare este apartenena unui stereotip fapt evident din definiia sensului stereotipurilor [3]. De exemplu avem clase ce sunt obligate s gestioneze evenimentele din exteriorul sistemului dac interfaa este reprezentat n mai multe nivele atunci, acesta poate fi prezentat ca subsistem pe unul din nivelele structurii interfeei grafice. Alt avantaj al utilizrii pachetelor este posibilitatea imbricrii lor (nested packages), adic pe parcursul sau chiar de la nceputul dezvoltrii sistemului pot fi depistate alte esene de grup i mai specifice ce vor fi plasate ntr-un pachet care la rndul su se va gsi n interiorul altui pachet (de exemplu n modelul nostru pachetul Forms poate fi imbricat n pachetul Grafics, deoarece Grafics este motorul interfeei grafice i Forms sunt elemente ale acestei interfee la un nivel mai nalt). Relaiile dintre esenele de grup Cum se observ din modelul anterior ntre pachete sunt realizate relaii de dependen, aceasta nseamn c clasele unui pachet numit client (n cazul nostru Forms sau DBMS) utilizeaz serviciile claselor din alte pachete numite furnizori (Open conectivity, Grafics). Aceste relaii (dintre pachete) se depisteaz la etapa de analiz a scenariilor de execuie i legturilor dintre clasele (ce se conin n pachete) sistemului proiectat. Relaiile de dependen din modelul nostru n alt context pot fi nlocuite cu relaiile de agregare ce semnific formarea sistemului principal din subsisteme. Deoarece acest proces poart caracter iterativ, cu timpul relaiile sunt supuse modificrilor, unele din ele dispar, altele apar. Proiectarea subsistemelor

[Kendall Scott The Unified Process Explained] Acest tip de activitate include n sine proiectarea subsistemelor de proiectare, care deja au fost menionate n procesul de proiectare al arhitecturii. Scopul fiind subsistemele de prestare a interfeelor, claselor de proiectare i realizarea precedentelor la nivel de proiectare, ce execut operaiile acestor interfee. Cu toate acestea sistemul principal nu devine strns legat cu subsistemele (aceasta nseamn c dependenele dintre subsisteme sunt reduse la minim). Evidena acestui tip de activitate o duce elaboratorul componentelor, de dorit acela care a depistat pachetele de analiz. Dac sistemul conine un numr mare de clase, atunci ele pot fi unite n pachete (package).

Generarea codului n limbajul C++ Unul din avantajele CASE-ului Rational Rose (se utilizeaz Rational Rose Enterprise Edition v2001a) este posibilitatea generrii carcasului preventiv al sistemului soft din modelul static (n unele cazuri pentru sistemele distribuite se permite generarea codului i din alte tipuri de diagrame), la generare se iau n consideraie proprietile proiectului n ntregime, dar i proprietile claselor, rolurile, atributele, operaiile, etc. Pe lng proprietile ce reglementeaz caracteristicile proiectului propriu-zis, exist i denumirile fiierelor proiectului, denumirea claselor container, parametrii ce indic deosebirile limbajelor n parte. Proprietile claselor indic posibilitatea crerii constructorilor/destructorilor (nu este necesar fixarea implicit a acestora n corpul claselor din diagrama claselor) de iniializare sau de copiere, proprietile operaiilor permit precizarea (common, virtual, abstract, static, friend) sau asignarea statutului constant. Rational Rose permite definirea/redactarea oricrui set de proprieti adecvat necesitilor proiectului. Pentru fiecare clas se genereaz dou fiiere, fiierul antet (.h, .h~ pentru backup file) i fiierul de specificare (.cpp, .cp~ pentru backup file), aceti parametri deasemenea pot fi modificai. Etapele pregtirii proiectului pentru generarea codului surs Procesul de generare const din ase etape de baz: I. Verificarea modelului mediul conine serviciile ce permit verificarea modelului independent de limbajul ales pentru generare, ce se utilizeaz pentru asigurarea calitii codului generat, aceasta permite depistarea erorilor i neclaritilor ce nu permit generarea, acest serviciu e de dorit s fie utilizat iterativ (de la nceputul modelrii elementelor statice), deoarece ntr-un model aglomerat procesul depistrii erorilor este mai complicat (deci, verificarea se poate face prin Check Model din meniul Tools). O alt opiune este Access Violation ce permite depistarea dereglrilor specificaiilor de acces, atunci cnd exist relaii ntre clasele diferitor pachete (opiunea este accesibil din meniu Report > Show Access Violation).

II. Crearea componentelor pentru realizarea claselor exist diferite forme de componente de la fiiere surs pn la componentele ActiveX. Preventiv clasele pot fi asociate unor componente, unde relaiile dintre ele vor reprezenta dependenele de compilare (pentru cazul nostru acest pas poate fi omis deoarece pentru C++ aceasta se face n mod automat). III. Asocierea claselor pe componente fiecare component reprezint un fiier cu codul surs pentru unul sau mai multe clase, n C++ pentru fiecare clas se creaz dou fiiere unul antet, cellalt corp ( pentru C++ aceasta se face automat). IV. Setarea parametrilor de generare aceti parametri (pentru C++ se acceseaz din meniul Tools>Options>C++) determin modul de generare a codului pentru clase, atribute, operaii, pachete, componente, etc (de exemplu dac nu dorim manual n diagrama claselor s definim pentru fiecare clas constructor i destructor, putem indica aceasta n opiuni i Rose o s genereze specificri corespunztoare n mod automat). V. Selectarea claselor, pachetelor sau componentelor codul poate fi generat n parte pentru fiecare clas sau pentru toate mpreun (dac selectm pachet se vor genera toate clasele din pachetul dat). VI. Generarea codului pentru C++ generarea codului se poate face (dac nu este definit default limbajul corespunztor) prin alegarea nemijlocit a opiunii Code Generation (Tools>C+ +>Code Generation). Preventiv selectm clasele (sau pachetele n care se afl clasele) ce vor fi generate, sau putem determina iniial limbajul de programare din meniu Tools> Options / Notation, pentru opiunea Default Language din list alegem C++, atunci codul poate fi generat din meniul de context, alegem opiunea C++>Code Generation. Exemplu de model pentru care se va genera codul n C++ Sunt prezentate dou pachete ce
Graphic primitives

reprezint

subsistemul

grafic

(de

exemplu nucleul grafic al unui sistem de operare) i un pachet cu primitive grafice ce vor fi utile pentru ntr-o programarea diagramelor

aplicaie de contabilitate.
<<subsystem>> Graphic device <<subsystem>> Integrafe

Pachetul Graphic device reprezint clasele ce realizeaz dispozitivul grafic mediul grafic abstractizat (asemenea SO Windows).

Pachetul Interface este subsistemul ce conine controalele de gestiune (meniuri, butoane, etc). n pachetul Graphic primitives de exemplu pot fi realizate tipuri speciale de date (figuri geometrice).
<<geometric>> CRectangle left : int top : int right : int bottom : int color : COLORREF m_hDC : CCD m_hWnd : CWindow <<constructor>> CRectangle() <<destructor>> ~CRectangle() <<function>> Move() <<function>> GetColor() <<procedure>> SetColor() <<function>> Draw()

CObject

CDeviceContect m_hA ttribDC : HDC = m _hDC m_hDC : HDC = m_hAtt ribDC <<const ructor>> CDC() <<destructor>> ~CDC() <<function>> CreateDC() <<function>> DeleteDC()

Coninutul pachetului Graphic device CDeviceContext conine stereotipul boundary

<<geometric>> CEl lipse <<function>> Draw()

deoarece clasa dat reprezint nivelul nalt al interfeei grafice (ce deriveaz din clasa CObject).

<<window>> CWindow m_hWnd : HWND <<constructor>> CWindow() <<destructor>> ~CWindow() <<function>> MoveWindow()

<<geometric>> CCircle <<const>> right : int = 0 <<const>> bottom : int = 0 radius : int <<function>> Draw()

Coninutul pachetului
<<button>> CButton <<include>> 0..n 1 <<bar>> CToolBar

Interface CWindows reprezint clasa de baz pentru elementele de control vizuale, cum sunt butoanele sau

meniurile.

Coninutul pachetului Graphic primitives Acest pachet prezint figurile geometrice necesare pentru desenarea elementelor grafice ale interfeei utilizatorului, de exemplu pentru desenarea butonului se folosete dreptunghi (CRectangle), dar avem posibilitatea s desenm i butoane circulare (CEllipse). Generare Dup formare nu uitm s verificm corectitudinea modelului, opiunile corespunztoare sunt Check Model (Tools > Check Model) i Accesss Violation (Report > Access Violation). Pentru generarea claselor n parte Deoarece limbajul de programare (C++) este indicat implicit, codul poate fi generat din meniul de context a ferestrei modelului, opiunea C++ > Code Genaration. Pentru generarea tuturor pachetelor (preventiv selectm pachetele necesare) din meniul Tools selectm opiunea C++ > Code Genaration.

Fig.4-5.9. Codul obinut dup generare (pentru clasa Ccircle) Dup generare obinem trei directorii, fiecare avnd semnificaie de pachet, n interiorul acestor directorii sunt fiiere de antet i corp pentru fiecare clas.

Modalitile de generare a codului n Rational Rose Pentru a putea genera codul n Rational Rose trebuie s avem construite cel puin diagramele de clas i de componente. Pentru fiecare clas de selectat limbajul n care trebuie de generat codul (n exemplul de mai jos am folosit limbajul C++), aceasta se face n felul urmtor: n diagrama de componente deschidem fereastra de specificaii a fiierului n care vom genera codul i pe pagina General la opiunea Language alegem limbajul C++. Pentru ca clasa s se genereze n fiierul respectiv n diagrama de clase deschidem fereastra de specificaii pentru clasa respectiv, pe pagina Components executm un click cu butonul drept al mouse-ului pe fiierul n care va fi plasat codul clasei i din meniu alegem opiunea Assign, codul poate fi generat.

Fig.4-5.8. Specificarea fiierului n care trebuie plasat codul clasei Generarea codului din diagrama de clase Pentru a genera codul din diagrama de clase efectum un click cu butonul drept al mouseului pe clasa respectiv i alegem opiunea C++ / Code Generation, codul a fost generat i plasat n mapa source din directorul programului Rational Rose .

Fig.4-5.9. Selectarea meniului Code Generation Codul generat conine carcasa programului final, clasele ce conin atributele i metodele declarate n model i o mulime de comentarii care ajut la dezvoltarea claselor. n fiier au fost generate clasele ce au fost asociate lui, deci clasa Administratorul de Procese i clasa Nucleul sistemului de operare, diagrama de clase arat n felul urmtor:

Sistem de Gestiunea Fisierilor

(f rom Use Case View)

tabelul_de_alocare : Double Scri e_in_fisier() deschide_fisier() inchide_fisier() citeste_fisier() creaza_fisi er() sterge_fisier() cauta_fisier() 1..* 1 <<nucleu>> Nucleul Sistemului Operational
(f rom Use Case View)

prelucrarea_datelor() generare_comanda() verifica_identitatea_utilizatorului () accepta_utili zatorului() declina_utili zator() da_identitatea_util izatorului() 0..n <<Modul_al_sistemului_operationa... GUI(graphic user interface)
(f rom Use Case View)

Procese

1 Administratorul de procese 1
(f rom Use Case View)

numarul_de_proces : Integer = 1 Periferic Memoria comuta_context() schi mba_prioritate() creaza_proces() sterge_proces() kil_proces() stopeaza_proces() executa_proces()

prelucrare_eveniment() genereaza_eveniment() afiseaza_date()

Fig.4-5.10. Diagrama de clase

Generarea codului din diagrama de Componente Dup ce fiecare clas din diagrama de clase a fost asociat unui fiier se poate de generat codul din diagrama de componente. Se efectueaz un click cu butonul drept al mouse-ului i alegem C++ / Code Generation (Figura 4-5.11). Codul se genereaz ca i n cazul de mai sus (n exemplu a fost generat componenta nucleu.exe n fiierul nucleu.exe.cpp i el arat ca listingul de mai sus).

Fig.4-5.11. Generarea codului din diagrama de Componente

Generarea codului din pachete n diagrama de clase se selecteaz pachetul necesar i din meniul principal se alege opiunea Tools>C++>Code Generation:

Fig. 4-5.12. Generarea codului din pachete A fost folosit pachetul procese ce conine urmtoarea diagram:

Proces
(from Logical View)

id_proces : int prioritate : double starea : int tipul : int spatiul_de_adrese : memoria_RAM

proces de sistem

proces utilizator

Fig. 4-5.13. Structura pachetului procese n mapa Source se va crea mapa Procese cu fiierele: proces de sistem.h, proces de sistem.cpp, proces utilizator.h, proces utilizator.cpp. n acest cod se psteaz ierarhia creat mai sus, adic clasele proces de sistem i proces utilizator sunt derivate de la clasa proces.

ntrebri de control:

1. Numii principalele avantaje ale abstractizrii.

2.

Ce numim clas?

3. Descriei tipurile de relaii utilizate n diagrama claselor. 4. Cte nivele de vizibilitate recunoate UML?
5.

Cum nelegei noiunea de clas abstract?

6. Care este diferena dintre clasele root i leaf? 7. Cte tipuri de stereotipuri sunt folosite n limbajul UML? 8. Descriei diagramele de clase. 9. Enumerai etapele pregtirii proiectului pentru generarea codului surs. 10. Cum are loc generarea codului din diagrama de clase, diagrama de componente i din pachete?

LUCRAREA DE LABORATOR NR. 6 TEMA: Dezvoltarea elaborrilor cu diagramele de stare (statechart diagram), activitilor i Reverse Engineering n mediul Rational Rose pentru modelele precedente cu modificri, perfectri i completrile respective

Scopul lucrrii: 1. Studierea prii teoretice i verificarea cunotinelor nsuite n mediul instrumentului CASE Rational Rose. 2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea i destinaia elementelor Statechart, activitilor i Reverse Engineering 3. Dezvoltarea modelului precedent din domeniul respectiv. nsuirea tehnicii de creare, modificare i salvare a respectivelor modele elaborate cu diverse automate i liste ale sistemului real-propus. 4. Studierea i descrierea modelrii comportamentale, componentele i operaiile de manipulare (generare, modificare i salvare a modelului). 5. Completarea codului surs obinut din Classe i Statechart, activitilor, fiind executabil, pentru evidenierea specificului operaiilor necesare i tehnicii eficiente de testare i reutilizare.

6. Verificarea codului surs completat n mediul limbajului C++, expunnd rezultatele, crearea modelul n UML prin metoda Reverse Engineering i compararea cu cel precedent. 7. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n procesul efecturii lucrrii de laborator/1/. Sarcina: Pentru sistemul din lucrarea de laborator Nr.2 elaborai cte trei diagrame a strilor i activitilor.

Consideraii teoretice generale. Modelarea comportamentului Alturi de evidenierea claselor i a relaiilor dintre ele, este necesar i descrierea laturii dinamice, respectiv a interaciunilor care au loc ntre clase i obiecte. Dou dintre conceptele abordrii obiectuale sunt n mod particular vizate aici: starea i comportamentul. Precedentele i scenariile se ntrebuineaz pentru descrierea comportamentului sistemului, adic relaiile dintre obiecte. Uneori este necesar de a urmri comportamentul n interiorul obiectului. Diagrama de stare (statechart diagram) reprezint poziia unui obiect singular, activitile sau mesajele, care creeaz schimbul de la o stare la alta. Aceast diagram nu este necesar pentru fiecare clas a sistemului, ci numai pentru clasele cu o comportare dinamic deosebit. Pentru a determina obiectele dinamice din sistem, adic obiectele ce trimit sau primesc un numr mare de mesaje, se pot folosi diagramele interaciunilor. Stare (state) este o poziie oarecare n viaa obiectului, pentru care el ndeplinete o anumit cerin, o oarecare activitate, sau ateapt un oarecare eveniment. Strile obiectului se pot descrie cu ajutorul valorilor unui sau mai multor atribute ale clasei. Diagrama de stare include toate mesajele, pe care obiectul le primete i le transmite. Scenariul este parcurgerea unic a ntregii diagrame. Intervalul dintre dou mesaje, transmise de obiect, de obicei reprezint o stare. De aceea pentru a determina strile obiectului este necesar de studiat diagrama secvenelor (privii intervalele dintre liniile de comunicaii, primite de obiect). Starea poate evolua n timp. n consecin, valorile prin care trec, declanatorii tranziiilor de la o stare la alta i condiiile necesare pentru ca aceasta s aib loc trebuie identificate i reprezentate corespunztor. Diagrama de stri este cea care servete n acest scop. Definirea comportamentului presupune identificarea modului n care obiectele, aparin diverselor clase, interacioneaz ntre ele. Aa cum s-a menionat deja, aceast interaciune are forma unui schimb de mesaje n care un obiect emitent adreseaz o solicitare altui obiect destinatar. Pentru a putea face acest lucru emitentul trebuie s poat cunoate i s aib acces la destinatar. Ceea ce nseamn, pur i simplu c ntre acestea respectiv ntre clasele corespunztoare,

trebuie s existe o cale, direct sau indirect. Aceast cale este constituit, n marea majoritate a cazurilor de asocieri. O prim concluzie: este posibil ca definirea comportamentului s impun adugarea de noi asocieri la ceea ce diagrama claselor conine deja. Pentru a putea primi un mesaj, destinatarul trebuie s aib o operaie corespunztoare acesteia. Mai mult dect att, destinatarul trebuie s reacioneze la mesajul primit. Aceast reacie poate fi strict local, constnd, de exemplu, n modificarea coninitului unor atribute, direct ca rezultat al unor calcule prealabile, sau poate presupune un rspuns ctre emitent. n acest caz apare o nou problem: ce face emitentul dup ce a emis mesajul? Se blocheaz n ateptarea rspunsului sau continu cu alte prelucrri, pn la sosirea acestuia. n unele sisteme aceste aspecte pot fi nu att de importante i deci ignorate, totul reducndu-se la un model de funcionare strict secvenial. Exist ns i cazuri n care rolul lor este important, i prin urmare trebuie stabilite riguros i reprezentate. Revenind acum la prelucrarea presupus de primirea unui mesaj, aceasta poate fi executat n totalitate de destinatar. La fel de bine este posibil ca aceasta s fie necesar s cear ajutorul altui obiect, evident tot printr-un mesaj, cu respectarea tuturor celor menionate nainte. Exist diverse aspecte i situaii, pentru a cror reprezentare nu se poate folosi un singur tip de diagram. UML propune, n consecin, trei reprezentri: diagrama de colaborri, diagrama strii i diagrama de activiti. Fiecare dintre acestea este adaptat anumitor utilizri. Alturi de simplitate aceste diagrame se mai caracterizeaz prin calitatea de a nu fi numai o modalitate de reprezentare ci i un suport n identificare i definitivare a elementelor de comportament. Anterior au fost menionate o serie de ntrebri. Dar nu a fost formulat cea mai important: cum se poate stabili care sunt emitenii i destinatarii, ce mesaje trebuie schimbate ntre acetia, care sunt operaiile necesare fiecrei clase de obiecte i ce trebuie s fac acetia exact. Rspunsul se bazeaz pe cazurile de utilizare. Diagramele amintite vor fi ntocmite pentru fiecare caz de utilizare i fiecare scenariu.
di agram a d e s tari c az de utiliz are di agr ama de ac ti vitat i

diagram a de s ec venta

s c enarii din des c riere

diagram a de c olabora ri

Fig. 6.1. Corelaiile dintre cazurile de utilizare i diagramele de comportament Cu ajutorul diagramelor de secven i de colaborri pot fi identificate i reprezentate configuraiile de obiecte i clase, interaciunile dintre acestea, necesare obinerii funcionalitilor

specifice fiecrui scenariu. Diagramele de activiti servesc pentru a completa descrierea cazului de utilizare, iar diagrama de stri, pentru acele clase participante la cazul de utilizare ale cror schimbri de stare sunt numeroase sau semnificative. Setul complet de operaii i de relaii aferent fiecrei clase se obine, n cele din urm, prin reunirea acestora din toate cazurile de utilizare i scenariile la care particip. Diagramele de stare. Conceptul de stare deine un loc important n diagrama obiectual. Schimbrile de stare pe care le poate suporta un obiect influeneaz comportamentul acestuia, ceea ce justific suficient de convingtor necesitatea evidenierii i studiului lor. Aceasta comport o dubl dimensiune: pe de o parte aceea a enumerrii strilor posibile i a eventualelor reguli sau restricii care guverneaz ordinea nlnuirii lor, n ali termeni, a ciclului de via al obiectului, i pe de alt parte, a stimulilor sau evenimentelor care declaneaz sau determin trecerea de la o stare la alta. Diagrama de stri servete pentru a reprezenta ansamblul de stri prin care poate trece un element de modelare fie acesta obiect sau interaciune n cursul execuiei sale, ca reacie la evenimentele survenite din exteriorul su. Starea este definit n aceast viziune, fie prin valorile sau combinaiile de valori luate de anumite atribute, fie printr-un calificativ de natur abstract, conceptual, determinat de logica activitii de afaceri. Diagramele de stare sunt destinate pentru modelarea diferitor stri n care poate s se afle obiectul. n timp ce diagrama claselor arat imaginea static a claselor i legturile lor, diagrama strilor se folosete la descrierea dinamic a comportamentului sistemului. Diagrama de stare reflect comportamentul obiectului. Principalele stri ale diagramei sunt: nceput i sfrit. nceputul grafic este reprezentat ca un cerc plin de culoare neagr, i corespunde strii obiectului n momentul crerii. Starea final se reprezint grafic prin dou cercuri unu n altul. Cel din mijloc este plin de culoare neagr. Sfritul corespunde strii obiectului nainte de distrugerea lui. Diagrama de stare poate avea numai o stare de nceput, iar stri finale cte sunt necesare. Cnd obiectul se afl ntr-o stare concret se pot ndeplini unele procese sau altele. Diagrama de stare nu trebuie numaidect construit pentru fiecare clas. Ele se construiesc numai n cazuri excepional de grele. Dac obiectul clasei poate exista n mai multe stri, i n fiecare se comport diferit probabil va trebui o astfel de diagram. ns n multe proiecte nu se folosesc. Dac totui diagramele de stare au fost construite, elaboratorii le pot folosi la crearea claselor. Diagramele de stare sunt necesare n majoritatea cazurilor pentru documentare. La generarea codului surs n Rose, la baza modelului nostru nu va fi nici un cod. Cu att mai mult la sistemele ce lucreaz n regim real de timp le sunt accesibile diferite extensii Rose, care permite generarea codului care se bazeaz pe diagramele de stare. n Rose se poate crea o diagram de Stare pentru o clas. Pe ea sunt reprezentate toate strile i trecerile acestei clase. Starea (State) se mai numete una din condiiile posibile, n care

poate exista un obiect. Pentru determinarea strii obiectului trebuie de cercetat dou regiuni ale modelului: valoarea atributelor obiectului i legturile cu alte obiecte. Starea obiectului se alege n dependen de faptul dac exist legtur sau nu. Acest tip de diagram e folosit pentru a modela comportamentul unui singur obiect. Ea specific o secven de stri prin care trece obiectul de-a lungul vieii sale ca rspuns la evenimente. Un eveniment reprezint ceva atomic ce se ntmpl la un moment dat i are ataat o locaie n timp i spaiu. Evenimentul modeleaz apariia unui stimul care poate conduce la efectuarea unei tranziii ntre stri. Evenimentele pot include: 1. 2. 3. 4. semnale - un stimul asincron care are nume i este aruncat de un obiect i apeluri de operaii (de obicei sincrone); trecerea timpului; schimbarea strii. recepionat de altul;

Starea are mai multe elemente: respectiv; active); tranziii interne; substri acestea pot fi disjuncte (secvenial active) sau concurente ( simultan nume indic n mod unic o stare; aciuni de intrare/ieire aciuni ce se produc la intrarea, respectiv ieirea din starea

O tranziie reprezint o relaie ntre dou stri indicnd faptul c un obiect aflat n prima stare va efectua un ir de aciuni i apoi va trece n starea a doua cnd se va petrece un anumit eveniment:
starea sursa eveniment[ conditia garda ] / actiune starea destinatie

Forma general a unei diagrame de stri este reprezentat n figura urmtoare. Aa cum se poate observa, exist numai dou tipuri de componente: tranziiile i strile, printre acestea din urm putndu-se evidenia dou tipuri particulare: stare iniial i stare final.

s tare initiala

NewS tate

s tare

tranz itie s i evenim ... NewS tate2

s tare finala

Fig. 6.2. Modelul general al unei diagrame de stare Tranziia constituie trecerea de la o stare la alta, asociat eventual cu executarea unei aciuni. O tranziie este, cel puin instantanee. Este posibil ca cele dou stri implicate ntr-o tranziie s fie identice. Tranziia poate fi declanat de ncheierea aciunilor i activitilor interne strii curente sau de producerea unui eveniment. Detaliile suplimentare privitoare la o tranziie pot fi furnizate prin ataarea la simbolul su grafic a unui text cu urmtoarea structur: Semntur-eveniment [ conditie-de-declansare] / expresie Semntura evenimentului opional cuprinde numele evenimentului, urmat de o eventual list de parametri, ncadrat n paranteze rotunde. Este considerat drept eveniment orice schimbare notificabil care determin o modificare de stare. Evenimentele pot consta din:

Verificarea unei condiii predefinite; UML propune pentru acest tip de evenimente o notaie de tipul: when expresie condiional. Scurgerea unui anumit interval de timp; UML propune pentru acest tip de evenimente o notaie de tipul: after (durat) sau when (moment); Primirea unui semnal de la un alt obiect (semnalul este el nsi un obiect); Invocarea unei operaiuni de ctre un alt obiect sau de ctre acelai obiect. Ultimele dou mai sunt numite evenimente mesaj. Un eveniment este vizibil pentru toate obiectele din cadrul pachetului n care apare.

Condiia de declanare este evaluat numai la producerea evenimentului i autorizeaz sau anuleaz producerea tranziiei. n oricare din aceste alternative, evenimentul este consumat i nu mai poate produce efecte chiar dac ulterior condiia de declanare devine adevarat. Expresia definete eventuala aciune de executat odat cu efectuarea tranziiei.
when (S firs itA nUnivers itar) [C redit e> = 120 S I M edie > = 6] A n II A n III

w hen ( S fi rs it A nUnivers itar) [Cr edi te< 1 20 S A U M edi e< 6] w hen (S firs itA nUnivers itar) [ Credite> = 120S I M edie > = 6]

N eprom ova t

O pti uneA nS upl imen tar

A n II s up lim enta

aft er (30 z ile ) w hen ( S fi rs it A nUnivers itar) Ex m at ri c ul at [C redit e< 120S A U M edi e< 6]

Fig.6.3. Diagrama de stare pentru promovarea studenilor n anul III de studii Figura dat conine un exemplu de diagram de stare referitoare la studenii care ncheie anul II de studii. Promovarea n anul III se face numai dac s-au acumulat cele 120 de puncte de credit prevzute de planul de nvmnt i media general este de cel puin 6. n caz contrar, se poate opta pentru un an suplimentar sau studentul este exmatriculat. La ncheierea anului II suplimentar trebuie

nu

joaca

da

nu

transfer

da

joc

nu

demisie

da

transferare

demisionare

respectate aceleai condiii. Nendeplinirea lor atrage dup sine exmatricularea. Fig.6.4. Diagrama Statechart (strilor) pentru clasa jucator

n aceast diagrama totul este construit pe baza strrii juctorului. Dac juctroul joac n acest club atunci el trece n starea joc, dac el se transfer atunci el trece n starea transferare etc. Dac el are o alt stare atunci automat trece spre sfrit. Starea surs reprezint starea din care se pleac. Evenimentul este cel care declaneaz tranziia. Condiia de gard este o expresie boolean, aceasta se evalueaz la producerea evenimentului care declaneaz tranziia. Tranziia poate avea loc numai dac e satisfcut condiia. Aciunea se poate specifica opional, ea se execut odat cu efectuarea tranziiei. Starea destinaie reprezint starea n care ajunge obiectul dup executarea tranziiei. Diagramele activitilor. Diagramele de activitate servesc pentru descrierea dinamicii sistemului n situaiile n care strile observate sunt reprezentate de aciuni sau subactiviti, iar evenimentele care declaneaz tranziia de la o stare la alta, sunt n totalitate sau n cea mai mare parte, constituite de ncheierea acestor aciuni sau subactiviti. Acest tip de diagram folosete urmtoarele elemente: aciuni, tranziii, puncte de decizie i bare de sincronizare. Termenul de tranziie este folosit n accepiunea de stare constnd din efectuarea unei anumite prelucrri; de altfel, numele folosit n UML este acela de stare - aciune. Finalizarea prelucrrii este evenimentul implicit care declaneaz tranziia spre starea urmtoare. Dac exist mai mult dect o singur stare ulterioar, se poate proceda n dou moduri: fie se alege doar una din aciuni pe baza unei expresii condiionale, iar selecia ca atare este semnalat prin plasarea n locul respectiv a unui punct de decizie, fie se execut simultan toate aciunile, dup care se marcheaz sincronizarea indispensabil continurii prelucrrilor. Documentaia UML precizeaz c o aciune se utilizeaz n mod normal pentru a modela un pas din execuia unui algoritm, proceduri sau proces de gestiune. n cele mai multe cazuri, diagramele de activitate sunt delimitate printr-un punct de start i un punct final, care marcheaz iniierea, i respectiv, ncheierea secvenei de activiti sau aciuni reprezentate. Pentru ilustare, n figura urmtoare este prezentat un model generic de diagram de activitate.
punct in itial actiune 1 decizie

cond 1

actiune 3

cond 2 actiune 2

ex ec utie s im ultana ac tiune 4 ac t iune5

punc t final

Fig.6.5. Modelul general al unei diagrame de activitate Subactivitatea constituie o secven bine definit de aciuni. Plasarea unei subactiviti n diagram nseamn execuia, n punctul respectiv, a aciunilor cuprinse de aceasta. Subactivitile constituie un mod eficient de simplificare a diagramelor, prin semnalarea compact a grupului de aciuni pe care-l reprezint. De asemenea, definirea de subactiviti permite s se evite repetarea anumitor secvene comune din diagrame diferite. Subactivitile sunt reprezentate grafic sub forma unei aciuni notate cu un simbol de imbricare. Diagramele de activiti sunt cazuri particulare ale diagramelor de stri. n ele sunt reprezentate trecerile fluxului de control de la o activitate la alta n cadrul sistemului. Acest tip de diagram este folosit pentru a modela dinamica unui proces sau a unei operaii. Spre deosebire de diagrama de interaciune care evideniaz controlul execuiei de la obiect la obiect, diagramele de activiti scot n eviden controlul execuiei de la o activitate la alta. Aceste diagrame pot conine: Stri-activiti sau stri-aciune: sunt stri ale sistemului. Ele modeleaz ceva ce se ntmpl (evaluarea unei expresii, apelul unei operaii a unui obiect, crearea sau distrugerea unui obiect). O stare-aciune reprezint execuia unei aciuni. Ea nu poate fi descompus, strile-aciune sunt atomice (nu pot fi ntrerupte) i au o durat nesemnificativ. Strileactiviti pot fi descompuse, activitatea lor putnd fi reprezentat cu ajutorul altor diagrame de activiti. Strile-activiti nu sunt atomice (ele pot fi ntrerupte de apariia unui eveniment) i ndeplinirea lor se face ntr-un interval oarecare de timp. Tranziii atunci cnd se termin execuia unei activiti sau aciuni, controlul este dat Obiecte Exist posibilitatea ca mai multe activiti s se execute n paralel. Pentru sincronizarea acestora se folosete aa-numita bar de sincronizare. Aceasta poate fi de 2 tipuri: a) Fork - are o tranziie de intrare i una sau mai multe tranziii de ieire, fiecare tranziie de ieire prezentnd un flux de control independent: urmtoarei aciuni sau activiti prin intermediul tranziiei -

b) Join poate avea 2 sau mai multe tranziii de intrare i una singur de ieire, n acest caz fiecare flux de control ateapt pn cnd toate celelalte fluxuri de intrare ajung n acel punct:

registrul de deplasare

magistrala interna

UAL

Registrul general

start

selecteaza registrul care contine operandul

inscrie operandul

transmite

trece operandul modificat

citeste operatia din registru

citeste rezultatul

comanda deplasarea stinga cu o pozitie

executa deplasarea

transmite rezultatul

selecteaza registrul

inscrie rezultatul

end

Fig.6.6. Diagrama de activitate Bara de instrumente speciale proprie Diagramei Statechart

2 3

8 9

1. Comanda de selectare. 2. Comanda de scriere a unui text. 3. Comanda de adugare a unui comentariu . 4. Comanda de legare a comentariului de elementul pe care-l nsoete. 5. Comanda de adugare a unei stri. 6. Comanda de adugare a unei stri iniiale. 7. Comanda de adugare a unei stri finale. 8. Comanda de adugare a unei tranziii de la o stare la alta. 9. Comanda de adugare a unei tranziii de la o stare la ea nsi. n continuare sunt prezentate diagrame de stare pentru modelarea elaborrii unui soft la mod general de ctre o echip de IT-specialiti n baza diagramei claselor. n aceast diagram avem prezentat componena echipei de IT specialiti. Astfel fiecare lucrtor intr n una sau alt categorie de specialiti grupai n clase: de programatori, designeri, testeri i project manageri. Fiecare clas face parte din clasa general, execut operaii din aceast clas precum i operaii proprii.

Fig.6.7. Diagrama claselor ce indic componena echipei de IT specialiti

Fig.6.8. Diagrama de stare privind strile ProjectManagerului

Fig.6.9. Diagrama de stare privind strile programatorului

Fig.6.10. Diagrama de stare privind strile designerului

Fig.6.11. Diagrama de stare privind strile testerului Reverse Engineering De creat modelul n UML prin metoda Reverse Engineering dintr-un cod surs C++. Fie c avem urmtorul cod de program care creaz clasa ca o ierarhie de tipuri main, transport de cltori i autobus. Pentru aceasta avem urmtorul cod de program n .cpp: //#include<iostream.h> //#include<string.h> //#include<conio.h> class Masina{ protected: char m_marca[20]; int nr_usi; int nr_roti; int nr_locuri; public: Masina(); //implicit Masina(char *marca, int nr_u, int nr_r, int nr_l); //de initializare Masina(Masina & m); //de copiere ~Masina() {}; Masina Init(char *marca, int nr_u, int nr_r, int nr_l); void ShowMasina(); }; //--------------------------------------------------------------class Transport_Calatori:virtual public Masina{ protected: char tc_ruta[30]; public: Transport_Calatori(); //implicit Transport_Calatori(char *ruta): Masina() {strcpy(tc_ruta,ruta);} //de initializare Transport_Calatori(Transport_Calatori & tc); //de copiere virtual ~Transport_Calatori() {}; virtual Transport_Calatori SetRuta(char *ruta); virtual Transport_Calatori GetRuta(); virtual void ShowTransport_Calatori(); };

//--------------------------------------------------------------class Autobus:virtual public Transport_Calatori{ public: Autobus(): Transport_Calatori() {}; //implicit Autobus(char marca, int nr_u, int nr_r, int nr_l, char ruta): //de initializare Transport_Calatori() {}; virtual ~Autobus() {}; virtual Autobus Init(char *marca, int nr_u, int nr_r, int nr_l, char *ruta); virtual void ShowAutobus(); }; //================== Descrierea claselor ================= //===================== MASINA ============================ Masina::Masina() {strcpy(m_marca,"Mazda"); nr_usi=4; nr_roti=4; nr_locuri=5;}; Masina::Masina(char *marca, int nr_u, int nr_r, int nr_l) { strcpy(m_marca,marca); nr_usi=nr_u; nr_roti=nr_r; nr_locuri=nr_l; } Masina::Masina(Masina & m) { strcpy(m_marca,m.m_marca); nr_usi=m.nr_usi; nr_roti=m.nr_roti; nr_locuri=m.nr_locuri; } Masina Masina::Init(char *marca, int nr_u, int nr_r, int nr_l) { strcpy(m_marca,marca); nr_usi=nr_u; nr_roti=nr_r; nr_locuri=nr_l; return *this;} void Masina::ShowMasina() { cout<<"=== MASINA ==="<<endl; cout<<"Marca: "<<m_marca<<endl; cout<<"Nr. usi: "<<nr_usi<<endl; cout<<"Nr. roti: "<<nr_roti<<endl; cout<<"Nr. locuri: "<<nr_locuri<<endl<<endl; } //=================== TRANSPORT_CALATORI ========================== Transport_Calatori::Transport_Calatori() {strcpy(tc_ruta,"Chisinau <> Paris");} Transport_Calatori::Transport_Calatori(Transport_Calatori & tc) { strcpy(tc_ruta,tc.tc_ruta); } Transport_Calatori Transport_Calatori::SetRuta(char *ruta) { strcpy(tc_ruta,ruta); return *this; } Transport_Calatori Transport_Calatori::GetRuta() { return tc_ruta;} void Transport_Calatori::ShowTransport_Calatori() { cout<<"=== Transport de Calatori ==="<<endl; cout<<"Ruta: "<<tc_ruta<<endl<<endl; } //===================== AUTOBUS =================================

Autobus Autobus::Init(char *marca, int nr_u, int nr_r, int nr_l, char *ruta) { strcpy(m_marca,marca); nr_usi=nr_u; nr_roti=nr_r; nr_locuri=nr_l; strcpy(tc_ruta,ruta); return *this; } void Autobus::ShowAutobus() { cout<<"=== AUTOBUS ==="<<endl; cout<<"Marca: "<<m_marca<<endl; cout<<"Nr. usi: "<<nr_usi<<endl; cout<<"Nr. roti: "<<nr_roti<<endl; cout<<"Nr. locuri: "<<nr_locuri<<endl; cout<<"Ruta: "<<tc_ruta<<endl<<endl<<endl; } //====================== MAIN =============================== void main() { Masina m1, m2("BMW",4,4,5), m3=m1; Transport_Calatori tc1, tc2("Chisinau <> Madrid"), tc3=tc1; Autobus a1,a2=a1; clrscr(); cout<<"M1: "<<endl; m1.ShowMasina(); cout<<"M2: "<<endl; m2.ShowMasina(); cout<<"M3: - copia M1"<<endl; m3.ShowMasina(); cout<<"M3: - ReInit"<<endl; m3.Init("Opel",4,4,5); m3.ShowMasina(); getch(); clrscr(); cout<<"TC1: "<<endl; tc1.ShowTransport_Calatori(); cout<<"TC2: "<<endl; tc2.ShowTransport_Calatori(); cout<<"TC3 - copia TC1: "<<endl; tc3.ShowTransport_Calatori(); cout<<"TC3: - ReInit"<<endl; tc3.SetRuta("Chisinau <> Roma"); tc3.ShowTransport_Calatori(); getch(); clrscr(); cout<<"A1.ShowMasina: "<<endl; a1.ShowMasina(); cout<<"A1.ShowTransport_Calatori: "<<endl; a1.ShowTransport_Calatori(); cout<<"A1 - copia A1: "<<endl; a2.ShowMasina(); a2.ShowTransport_Calatori(); a1.Init("Mercedes-Benz",4,4,40,"Chisinau <> Berlin"); cout<<"A1.ShowAutobus: - ReInit"<<endl; a1.ShowAutobus(); getch(); } Clasa dat conine: 1. modurile de acces: public (pentru metode), private (pentru variabile).

2. constructori i destructor

3. funcii de prelucrare a informaiei n timpul modelrii inverse analizatorul utilizeaz informaia obinut din codul surs, precum i valoarea parametrilor ai proiectrii inverse. Cu aceti parametri se stabilesc, n particular, ceea ce se creeaz pentru fiecare construcie C++. n timpul modelrii inverse analizatorul supune acest fiier recunoaterii gramaticale i determin care clase, atribute i alte elemente ale modelului trebuie create. n model sunt generate urmtoarele elemente: - nsi clasa, creat n reprezentarea logic - Atributele i operaiile clasei - Pachetul reprezentrii logice care conine clasa. Numele acestui pachet devine numele directoriului n care se conine fiierul surs. - Diagrama claselor, pe care sunt reprezentate clasele care sunt supuse proiectrii inverse. n mod implicit, numele acestei diagrame Reverse Engireered. Se poate de modificat numele diagramei, modificnd proprietile proiectrii inverse n C++ Analyzer - Diagrama pachetelor, n care sunt reprezentate pachetele claselor, supuse proiectrii inverse. n mod implicit numele acestei diagrame este Reverse Engineered, dar el poate fi modificat cu ajutorul proiectrii inverse.

Model de creare a modelului prin Reverse Engineering: Procesul de modelare invers const din urmtoarele etape: I. II. III. IV. V. VI. VII. VIII. IX. X. Lansarea aplicaiei C++ Analyzer Crearea unui proiect nou Stabilirea antetului proiectului Stabilirea listei de directorii Stabilirea listei extensiilor Alegerea proiectului de baz Alegerea fiierelor pentru proiectarea invers Analiza fiierelor Stabilirea parametrilor pentru export Exportarea n Rose

Etapa I: Lansarea aplicaiei C++ Analyzer

Proiectarea invers, n C++ se realizeaz cu ajutorul aplicaiei, extern n raport cu Rational Rose. Utiliznd-o, se pot alege fiiere pentru proiectare invers, se pot seta proprieti de proiectare revers i genera modelul Rose. Mai nti alegem Tools -> Reverse Engineering, dup care se execut C++ Analyzer. Etapa II: Crearea proiectului nou Dup executarea C++ Analyzer urmtorul pas este crearea proiectului nou. Proiectul reprezint un fiier al analizatorului, care conine un set de fiiere, care trebuie transferate n modelul Rational Rose. Alegem File > New, i proiectul nou al analizatorului este creat.

Etapa III: Stabilirea antetului proiectului Antetul proiectului reprezint o caracterizare succint a destinaiei proiectului. Dac este indicat antetul proiectului, iar apoi acest proiect se utilizeaz ca proiect de baz pentru un alt proiect, atunci antetul se introduce n lista de baz. Antetul nu este obligatoriu pentru a-l seta, alegem butonul Caption n fereastra project. Dup care se poate introduce antetul proiectului n fereastra Caption. Etapa IV: Stabilirea listei directoriilor Aceast etap nu este obligatorie. La alegerea fiierelor din etapa a VII-a, lista directoriilor se completeaz automat. Oricum, opional, aceast list poate fi modificat pn, sau dup alegerea fiierelor. n aceast list se prezint acele directorii, n care se conin fiiere C++, care vor fi supuse proiectrii inverse. Alegerea directoriilor i adugarea lor n aceast list poate fi fcut cu ajutorul butonului Directories n fereastra proiectelor. Dup alegerea acestui buton apare fereastra Project Directory List. Alegem directoriul necesar, i-l adugm tastnd pe butonul Add Current. Dac apsm pe butonul Add Subdirs, atunci se adaug acest directoriu, subdirectorii si i subdirectorii acestora imediat urmtoare, iar dac apsm pe Add Hierarchy, atunci se adaug acest directoriu i toi subdirecorii ultimilor. Etapa V: Stabilirea listei extensiilor Aceast etap nu este obligatorie. La alegerea fiierelor din etapa a VII-a n list automat apar extensiile acestor fiiere. Oricum, aceast list poate fi stabilit opional. Aceasta este o list de extensii a fiierelor surs, care vor fi supuse proiectrii inverse, precum i fiierele antet,

conectate la primele fiiere cu ajutorul operatorului #include. Extensiile adugate n aceast list, devin filtre alese implicit la alegerea fiierelor ce vor fi supuse proiectrii inverse la etapa VII. Spre exemplu, dac adugm n list extensia .cpp, atunci vor fi admise la proiectarea invers doar fiiere cu extensia .cpp. Etapa VI: Alegerea proiectului de baz Proiect de baz se numete fiierul proiectului C++ Analyzer, care conine informaii despre clasele de baz utilizate. Poate, spre exemplu, s existe proiectul analizatorului, n care se pstreaz date despre careva clase de baz C++, create la organizare. n fiecare proiect al companiei aceste clase vor fi considerate ca clase de baz. Proiectul analizatorului, unde se conin date despre calea spre fiier, numele fiierelor i alte informaii despre clasele de baz, devine pentru proiectul n cauz de baz. La avantajele proiectelor de baz se refer posibilitatea reutilizrii. Aceasta permite utilizarea repetat a componentelor n diferite proiecte, astfel asigurnd coordonarea proiectelor. Pentru proiectarea invers proiectele de baz nu sunt obligatorii. Pentru a aduga un proiect de baz n list, artm calea ctre fiier i a numelui su cu ajutorul cmpurilor Directories i File name i executm click cu mouse-ul pe butonul Add. n fereastra proiectelor va aprea proiectul de baz i antetul su. Etapa VII: Alegerea fiierului pentru proiectarea invers La aceast etap sunt alese toate fiierele C++ care vor fi supuse proiectrii inverse. Mai nti alegem butonul File n fereastra proiectului. Apare fereastra fiierelor proiectului. n ierarhia Directory structure alegem directoriul care conine fiierele necesare. n mod implicit fiierele din directoriul curent cu extensia .h, .hh, .hxx, .cpp, .cxx, .cc, .c sunt prezente n lista Files Not In List (Filtered). Dac n lista extensiilor au fost incluse careva extensii, atunci se utilizeaz ultimele. Pentru a alege fiierul, l alegem mai nti din lista Files Not In List(Filtered). Click pe butonul Add Selected, mutnd-ul n lista Files In List (Flitered), sau pe butonul Add All, trecnd astfel n list toate fiierele. Repetm acest proces, alegnd directoriile i fiierele, pn cnd n lista Files In List (Flitered) nu vor fi prezente toate fiierele, care vor fi supuse ulterior proiectrii inverse. Click pe OK i toate fiierele vor aprea n fereastra proiectului. Etapa VIII: Analiza fiierelor

La aceast etap informaia, necesar pentru proiectare invers, se analizeaz utiliznd fiierele alese la etapa VII. La apariia erorilor acestea sunt introduse n fereastra registrului. Pentru a trece la analiza fiierelor, alegei-le n lista Files. Pentru aceasta tastai Ctrl+A. Pentru nceperea analizei alegem Action ->Analyze sau tastai F3. n procesul de recunoatere gramatical i studierii fiierelor, rezultatele procesului vor fi scrise n registru. n fereastra listei Files se afieaz i numrul de erori din fiecare fiier. Pentru a analiza greelile fiierului, dublu click pe fiier din lista Files a ferestrei registrului. Ca rezultat pe ecran vor fi afiate informaii despre erori. Etapa IX: Stabilirea parametrilor pentru export Dup analiza codului program, aceast informaie se utilizeaz pentru crearea modelului Rose. n C++ Analyzer exist un set ntreg de parametri pentru proiectarea invers, la fel ca i pentru generarea codului din modelul Rational Rose. Pentru selectarea parametrilor coorespunztori alegei Edit -> Export Options sau tastai Ctrl+R.

Etapa X: Exportul n Rational Rose Ultima etap reprezint exportul fiierelor n modelul Rational Rose. Pentru aceasta alegem Action-> Export to Rose sau tastm F8. Apare fereastra de dialog Export to Rose. n aceast fereastr de dialog se poate stabili numele modelului generat, antetul proiectului i setul parametrilor pentru utilizarea ulterioar. n afar de aceasta aici se ofer viziunea parametrilor n fereastra Summary of Options. Pentru generarea modelului efectuai click pe butonul OK n aceast fereastr. Dac modelul cu numele fiierului indicat nu exist analizatorul va oferi posibilitatea rescrierii acestuia. Fiecare din elementele de date ale claselor n cauz devine sau atribut, sau legtur a modelului generat. Dac tipul de date a elementului de date este alt clas a modelului, atunci se creaz o legtur de agregare. Dac tipul de date nu este alt clas a modelului, el devine atribut. Funciile membru se genereaz n modelul Rose numai n calitate de operaii. Dac n calitate de tip de date pentru argument sau tip returnat se utilizeaz alt clas a modelului, atunci se genereaz i legtura corespunztoare, ca i pentru elementele de date. Declaraiile Friend din codul program C++ se genereaz n modelul Rose n calitate de dependene.

Legturile de motenire n C++ se modeleaz n Rose cu ajutorul legturilor de generalizare. Analizatorul execut proiectarea invers a clasei printe i celei copil, stabilindu-le pe diagrama claselor. n continuare se reprezint elementele generate de Rational Rose n tipmul Reengineeringului:
autobus

Fig.6.12. Pachetul cu numele modelului

autobus

Fig.6.13. Diagrama de componente (n cazul dat avem numai o component corp)

Masina m_marca : char [20] nr_usi : int nr_roti : int nr_locuri : int Masina() : Masina Masina(marca : char*, nr_u : int, nr_r : int, nr_l : int) : Masina Masina(m : Masina&) : Masina ~Masina() Init(marca : char*, nr_u : int, nr_r : int, nr_l : int) : Masina ShowMasina() : void

Transport_Calatori tc_ruta : char [30] Transport_Calatori() : Transport_Calatori Transport_Calatori(ruta : char*) : Transport_Calatori Transport_Calatori(tc : Transport_Calatori&) : Transport_Calatori ~Transport_Calatori() SetRuta(ruta : char*) : Transport_Calatori GetRuta() : Transport_Calatori ShowTransport_Calatori() : void

Autobus Autobus() : Autobus Autobus(marca : char, nr_u : int, nr_r : int, nr_l : int, ruta : char) : Autobus ~Autobus() Init(marca : char*, nr_u : int, nr_r : int, nr_l : int, ruta : char*) : Autobus ShowAutobus() : void

Fig.6.14. Diagrama de clase (avem o ierarhie de clase) ntrebri de control: 1. Ce reprezint diagrama de stare, cnd se utilizeaz? 2. Care sunt caracteristicile de baz ale diagramei de colaborri, diagrama strii i diagrama de activiti? 3. Caracterizai diagrama de activiti. 4. Cte tipuri de bare de sincronizare se folosesc n diagrama de activiti? 5. Descriei etapele procesului de modelare invers.

LUCRAREA DE LABORATOR NR. 7

TEMA: Dezvoltarea elaborrilor cu diagramele amplasrilor Scopul lucrrii: 1. Studierea prii teoretice i verificarea cunotinelor nsuite n mediul instrumentului CASE Rational Rose. 2. Recapitularea i aprofundarea cunotinelor despre mediul Rational Rose: amplasarea i destinaia elementelor diagramelor amplasrilor. 3. Dezvoltarea modelului precedent din domeniul respectiv. 4. Studierea i descrierea modelrii comportamentale, componentele i operaiile de manipulare (generare, modificare i salvare a modelului). 5. Descrierea succint i elocvent a scenariului de lucru, dotat cu exemple concrete, n procesul efecturii lucrrii de laborator. Sarcina: Pentru sistemul iniial elaborai cte trei diagrame ale componenetelor i desfurrilor. Consideraii teoretice. Diagrama amplasrii Diagramele amplasrilor prezint configuraia elementelor de procesare din timpul execuiei i componentele, procesele i obiectele care le conin. Fiecare model al unui sistem informatic are asociat o singur diagram de exploatare. Instanele componentelor soft reprezint manifestri a unor uniti de cod n cadrul execuiei. Componentele care nu exist ca entiti de execuie nu apar n aceste diagrame, ci doar n diagramele de componente. O diagram de exploatare este un graf de noduri conectate prin asocieri de comunicare. Nodurile pot conine instane ale componentelor (componenta exist sau se execut pe nodul respectiv). Componentele pot conine obiecte (acestea sunt localizate n componente). Componentele sunt conectate cu alte componente sau interfeele acestora prin intermediul unor relaii de dependen (sgei ntrerupte) ceea ce reprezint faptul c o component folosete serviciile altei componente. dependenei dintre componente. Un nod este o entitate fizic ce reprezint o resurs de procesare, avnd o memorie i anumite capabiliti de procesare (dispozitive de calcul, resurse umane, resurse de procesare mecanic). Aceast diagram arat distribuirea tuturor nodurilor reelei, legturile dintre ele i procesele care sunt efective la fiecre nod. Aici se folosesc doar relaiile de asociere.
N e w P ro ces s o r

Pot fi utilizate stereotipuri pentru a preciza n detaliu tipul

procesor- este numit orice main care are puterea de calcul, adic este capabil s prelucreze datele. La aceast categorie se refer: serverele, staiile de lucru, .a., echipamente care conin procesoare fizice. - periferic este numit aparatajul care nu are proprieti de prelucrare a datelor. La aceast
NewDe vice

categorie se refer: printerul, scanerul, terminale de intrare-ieire. Se folosete legtura de asociere. Exemplul acestei diagrame este pe pagina urmtoare. Diagrama de componente O diagram de componente prezint dependenele existente ntre diverse componente software (cod surs, cod binar, fiiere executabile, librrii cu legtur dinamic etc) ce compun un sistem informatic. Aceste dependene sunt statice (au loc n etapele de compilare sau link-editare) sau dinamice (au loc n timpul execuiei). O component este un modul soft (cod surs, cod binar, dll, executabil etc) cu o interfa bine definit. Un tip de component reprezint o parte distinct, realocabil, a implementrii unui sistem. Instana unei componente este o unitate de implementare n execuie i poate fi utilizat pentru reprezentarea unitilor de implementare care au o identitate n momentul execuiei. Crearea diagramei amplasrilor: Adugarea nodurilor la diagrama Amplasrilor: 1. Dublu click pe Deployment View n browser, deschidem diagrama amplasrilor. 2. Acionm butonul Processor pe panoul de instrumente. 3. Click cu mouse-ul pe diagram, punem procesorul. 4. l numim Serverul bazelor de date. 5. Repetnd paii 2-4, adugm urmtoarele procesoare: Serverul aplicaiei. Staia de lucru client nr.1. Staia de lucru client nr.2.

6. Pe panoul de instrumente acionm butonul Device. 7. Plasm dispozitivul pe diagram. 8. l numimPrinter. Adugarea legturilor: 1. Acionai butonul Connection pe panoul de instrumente. 2. Click pe procesorul Serverul bazelor de date.

3. Tragem linia de legtur la procesorul Serverul aplicaiei. 4. Repetm paii 1-3, adugm urmtoarele legturi: - de la procesorul Serverul aplicaiei la procesorul Staia de lucru client nr.1. - de la procesorulServerul aplicaiei la procesorul Staia de lucru client nr.2. De la procesorul Serverul aplicaiei la dispozitivul Printer. Adugarea proceselor: 1. Click cu dreptul pe procesorulServerul aplicaiei n browser. 2. n meniul deschis alegem punctul New-Process. 3. Numim OrderServerExe. 4. Repetm paii 1-3, adugm procesele: - procesul OrderClientExe pe procesorul Staia de lucru client nr.1 - procesul ATMClientExe pe procesorul Staia de lucru client nr.2. Prezentarea proceselor pe diagram: 1. Click cu dreptul pe procesorul Serverul aplicaiei. 2. n meniul deschis alegem punctul Show Process. 3. Repetm paii 1,2, pentru vizualizarea proceselor pe procesoarele: - Staia de lucru client nr.1 - Staia de lucru client nr.2.
Serverul bazelor de date

Serverul aplicatiei

Printer

OrderServerEXE

Statia de lucru clint nr.2 Statia de lucru client nr.1

ATMClientEXE

OrderCl ientEXE

Fig.7.1. Diagrama amplasrilor pentru sistemul de prelucrare a comenzilor ntrebri de control:

1. Definii noiunea de diagrama amplasrii, caracterizai elementele componente ale acestei diagrame. 2. Descriei paii parcuri la crearea diagramei amplasrii. 3. Ce prezint diagrama de componente?

Anexe:

Diagrama secvenelor care indic interaciunea dintre obiecte. Descrierea timpului de via a obiectelor Crearea obiectului n intervalul de timp descris de diagram

n momentul transmiterii mesajului obiectul deja exist

tergerea obiectului n intervalul de timp descris de diagram

Diagrama secvenelor care indic interaciunea dintre obiecte. Transmiterea mesajului obiectului lui nsui. Recursia Transmiterea de ctre obiect a mesajului update( ) lui nsui Transmiterea recursiv a mesajului more()

Diagrama secvenelor care indic interaciunea dintre obiecte. Transmiterea condiional de mesaje

Sincronizarea lucrului obiectelor. Apelul procedural, sau transmiterea mesajului cu ateptarea terminrii reaciei la mesaj Apelul asincron al operaiilor ntoarcerea din procedur. Aceast sgeat poate s nu fie artat, dac se vede clar, c mesajul este ultimul n lanul de mesaje

Diagrama secvenelor care indic interaciunea dintre obiecte. Indicarea intervalelor temporare

Diagrama secvenelor care indic interaciunea dintre obiecte. Exemplu: renoirea grafului pe diagram

Diagrama secvenelor care indic interaciunea dintre obiecte. Exemplu de folosire a diagramei la descrierea ablonului de proiectare

Diagrama secvenelor care indic interaciunea dintre obiecte. Descrierea timpului de via a obiectelor

Diagrama secvenelor care indic interaciunea dintre obiecte. Mesajul: apelul procedural i eveniment Mesajul-apelul procedural

Mesajul - eveniment. Apelul procedural are loc dup primirea mesajului

Bibliografie:

1. Saru Daniela, Ioni Anca D. Sisteme de programe orientate pe obiecte.Buc.All.2000, /UTM:004.4:004.43; s24/. 2. Ioni Anca Daniela. Modelarea UML n ingineria sistemelor de programe. Buc.: All. 2003. 3.Analiza 4.UML i Applied,Object gestiunea Oriented sistemelor Analysis and informatice Design Using complexe, the UML, http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/. www.ariadnetraining.co.uk. 5. Craig Larman UML M.: 2001. 6. Booch G., Jacobson L., 1997, The UML specification Documents. 7. Booch G., 1994, Object Oriented Analysis and Design. 8. Beck and Cunningham W., 1989, A Laboratory for Object oriented Thinking. 9. Buschman F., Mennier R., Robert H, Sommerlad P and Stal M., 1996, Pattern-Oriented Software Architecture : A System of Patterns , West Sussex, England :Wiley. 10. Boehm B., 1998, A Spiral Model of Software Development and Enhancement . IEEE Computer, May 1988. 11. Ambler S., 2000, Whitepaper : The Design of a robust persistence, Layer For Relational Databases. 12. W.Boggs, M.Boggs - Mastering UML with Rational Rose 2002, Sybex [2002]. 13. J.Rambaugh, I.Jacobson, G.Booch - The Unified Modeling Language Reference Manual, Addison Wesley [1999]. 14. Ariadne Training - UML Applied (Object Oriented Analysis and Design Using the UML), Ariadne Training [2001]. 15. OMG Unified Modeling Language Specification, Object Management Group Inc [2003]. 16. Dan Chiorean, Iulian Ober, Marian Scuturici, Dan Mircea Suciu, Present and Perspectives in the Object-Oriented Analysis & Design - The RO-CASE Experience, The Third International Symposium in Economic Informatics, Bucharest, mai 1997. 17. D. Bozga, D. Chiorean, A. Frentiu, B. Rus, V. Scuturici, D. M. Suciu, D. Vasilescu, Rocase CASE Tool for Object-Oriented Analysis and Design, Research Seminars, Seminar on Computer Science, Univ. "Babes-Bolyai" Cluj-Napoca, 1994. 18. Michael Boggs, Wendy Boggs, UML Rational Rose, Editura Lori, Moscova, 2001 (vezi pe harddisk versiunea electronic: cap.5, 6 (p.146-179), cap.7 (p.223-257), cap.11,12 (p.287-359), cap.20 (p.519-549). 19. Grady Booch, - ++ , Rational Santa-Clara, California, . . .

20. Chiorean D, Metode de analiz i proiectare orientat-obiect, PC-REPORT, 46, iulie 1996. 21. Fowler, M. and Scott, K. UML Distilled: Applying the Standard Object Modeling Language (1997) Addison-Wesley. 22. Ambler, S.W Building Object Applications That Work: Your Step-by-Step Handbook for Developing Robust Systems With Object Technology. (1997, 1998) Cambridge University Press/SIGS Books. 23. Booch, G. et. al.Unified Modeling Language User Guide (1998) Addison-Wesley. 24. Larman, C Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (1998) Prentice-Hall. 25. UML 2001. 26. M. Boogs, W. Boogs Mastering UML with Rational Rose, 2002. 27. T. Cvartani Modelarea n Rational Rose, 2002. 28. . UML. . .: . 2002. 29.UML Applied,Object Oriented Analysis and Design Using the UML, 30. www.ariadnetraining.co.uk. 31. http://lci.cs.ubbcluj.ro/ 32. http://www.citforum.ru/programming/oop_rsis/glava2_2.shtml 33. http://www. omg.org/gettingstarted/what_is_uml 34. http://www.interface.ru/fset.asp?Url=/rational/suite/Suite.htm 35. http://www.omg.org/technology/documents/formal/uml.htm 36. www.PC-report.ro 37. www.CodeNet.ru

Cuprins Introducere.........................................................................................................................3

Ce reprezint Rational Rose? .....................................................................................3

Lucrarea1. Familiarizarea cu

tehnologiile, metodologiile i principiile elaborrii modelelorn baza blocurilor constructive ale limbajului UML i CASE

Rational Rose ................7 Consideraii teoretice generale. Cerinele generale fa de metodologii i tehnologii n ingineria softului...7 Limbajul UML..14 Sistemul de notaii grafice18 Blocurile constructive n UML...19 Relaiile...23 Diagramele UML...24

Lucrarea2. Analiza sistemului n baza metodologiei APOO i elaborarea modelelor

prin diagramele cazurilor de utilizare n mediul Rational Rose i dezvoltarea lor n alte diagrame......................................................................32 Consideraii teoretice generale. Descriere general....................................................32 Determinarea i definirea scopului proiectului ..35 Modelul sistemului..35 Modelul conceptual.....36 Diagramele cazurilor de utilizare..................................................................................41 Elaborarea Diagramelor USE-CASE...49 Studierea i descrierea destinaiei funcionale a submeniurilor/opiunilor...51 Diagrame Interaction.55 Diagrame Sequence....56 Diagrame Colaboration..59

Lucrarea 3. Analiza rezultatelor modelrii din diagrama cazurilor de utilizare

i dezvoltarea n diagramele Sequence i Collaboration n mediul Rational Rose.................................................................................................62 Consideraii teoretice generale. Descriere general...................................................62 Diagrama succesiunilor.64 Diagrama de colaborare...67 Elaborarea diagramei interaciunilor n mediul Rational Rose73 Elaborarea diagramei de colaborare n mediul Rational Rose.76

Lucrarea 4,5. Studiul i analiza abstraciilor, claselor, pachetelor i obinerea

codului surs n instrumentele CASE.....................................................80 Noiuni generale i exemple. Abstractizarea..............................................................80 Clasele abstracte...........................................................................................................88 Clasele root clasele leaf........................................................................................89 Clasele utilitare (utilite)90 Clasele parametrizate, utilitele claselor parametrizate i clasele acumulatoare.90 Mecanismele comune ....92 Diagrame de clase......95 Pachetele Esene de grup.......................................................................................96

Generarea codului n limbajul C++.97 Exemplu de model pentru care se va genera codul n C++...99 Modalitile de generare a codului n Rational Rose.....101

Lucrarea 6. Dezvoltarea elaborrilor cu diagramele de stare (statechart diagram),

activitilor i Reverse Engineering n mediul Rational Rose pentru modelele precedente cu modificri, perfectri i completrile respective105 Consideraii teoretice generale. Modelarea comportamentului....105 Reverse Engineering..............................................................................................117

Lucrarea 7. Dezvoltarea elaborrilor cu diagramele amplasrilor....125

Consideraii teoretice. Diagrama amplasrii..125 Diagrama de componente......................................................................................126

Bibliografie.........................................................................................................................133

ANALIZA I MODELAREA SISTEMELOR INFORMAIONALE

ndrumar metodic pentru lucrri de laborator

Autori:

t. Marin

Redactor:

Bun de tipar 00.00.09 Hrtie offset.Tipar RISO Coli de tipar 3,5

Formatul hrtiei 60x84 1/16 Tirajul 100 ex. Comanda nr.

UTM, 2004, Chiinu, bd.tefan cel Mare, 168. Secia Redactare i Editare a UTM 2068, Chiinu, str. Studenilor, 9/9