CUPRINS 1. Etapele principale de dezvoltare a limbajului UML ......................................................................3 2. Componente de baza ale limbajului UML ......................................................................................5 2.1.

Structura general a limbajului UML .......................................................................................7 2.2. Particularitatea (specificul) limbajului UML ...........................................................................8 2.2.1. UML limbaj de vizualizare ............................................................................................9 2.2.2. UML limbaj de specificare .............................................................................................9 2.2.3. UML limbaj de construire ..............................................................................................9 2.2.4. UML limbaj de documentare .......................................................................................10 2.3. Entiti n UML ......................................................................................................................11 2.4. Relaii UML ...........................................................................................................................14 2.5. Diagrame UML ......................................................................................................................16 3. Diagarama cazurilor de utilizare (use case diagram) ....................................................................17 3.1. Cazul de utilizare ....................................................................................................................17 3.2. Actori ......................................................................................................................................18 3.3. Interfee ..................................................................................................................................19 3.4. Legturile n diagrama a cazurilor de utilizare ......................................................................20 3.4.1. Relaia de asociere ...........................................................................................................20 3.4.2. Relaia de extindere .........................................................................................................22 3.4.3. Relaia de generalizare ....................................................................................................22 3.4.4. Relaia de tip include .......................................................................................................23 3.5. Exemplu de construirea diagramei cazurilor de utilizare .......................................................24 4. Diagrama de clase (class diagram) ................................................................................................26 4.1. Clasa .......................................................................................................................................27 4.1.1. Numele clasei ..................................................................................................................27 4.1.2. Atributele clasei ...............................................................................................................28 4.1.3. Operaiile .........................................................................................................................30 4.2. Relaii ntre clase ....................................................................................................................31 4.2.1. Relaia de dependena.......................................................................................................31 4.2.2. Relaia de asociere............................................................................................................32 4.2.3. Relaia de agregare ..........................................................................................................33 4.2.4. Relaia de compoziie ......................................................................................................33 4.2.5. Relaie de generalizare ....................................................................................................34 4.3. Interfee ..................................................................................................................................35 4.4. Obiecte ....................................................................................................................................35 5. Diagrama de stri (statechart diagram) .........................................................................................36 5.1. Automate ................................................................................................................................36 5.2. Stare ........................................................................................................................................37 5.2.1. Numele strii ...................................................................................................................38 5.2.2. Starea iniial ...................................................................................................................38 5.2.3. Starea final .....................................................................................................................38 5.3. Tranziie ..................................................................................................................................38 5.3.1. Eveniment ........................................................................................................................39 5.3.2. Condiie gard .................................................................................................................39 5.3.3. Expresia aciunei .............................................................................................................40 5.4. Stare i substare compus .......................................................................................................41 5.4.1. Substri disjuncte ............................................................................................................41 5.4.2. Substri concurente .........................................................................................................42 6. Diagrama de activiti (activity diagram).......................................................................................44 6.1. Starea activitii ......................................................................................................................44

6.2. Tranziii ..................................................................................................................................45 6.3. Partiii .....................................................................................................................................47 6.4. Obiecte ....................................................................................................................................49 7. Diagrama de secven (sequence diagram) ...................................................................................50 7.1. Obiecte ....................................................................................................................................50 7.1.1. Linia de via al obiectului ..............................................................................................51 7.2. Focus control ..........................................................................................................................51 7.3. Mesaje ....................................................................................................................................51 7.3.1. Stereotipuri de mesaje .....................................................................................................52 7.4. Restricii temporale n diagrama de secven .........................................................................52 8. Diagrama de colaborare (collaboration diagram) ..........................................................................53 8.1. Obiecte ....................................................................................................................................53 8.1.1. Multiobiect ......................................................................................................................55 8.1.2. Obiect activ .....................................................................................................................55 8.1.3. Obiect compus .................................................................................................................56 8.2. Legturi ..................................................................................................................................56 8.2.1. Tipuri de legturi .............................................................................................................57 8.3. Colaborare ..............................................................................................................................58 8.3.1. Diagrama de colaborare la nivel de specificare ...............................................................59 9. Diagrama de componente (component diagram) ..........................................................................60 9.1. Componente ............................................................................................................................61 9.1.1. Numele componentului ...................................................................................................62 9.1.2. Feluri de componente ......................................................................................................63 9.2. Interfee ..................................................................................................................................64 9.3. Dependene .............................................................................................................................64 9.4. Recomandri la construirea diagramei de componente ..........................................................66 10. Diagrama de plasare (deployment diagram) ...............................................................................67 10.1. Nod .......................................................................................................................................68 10.2. Conexare ...............................................................................................................................70 10.3. Recomandri la construirea diagramei de plasare ................................................................72

1. Etapele principale de dezvoltare a limbajului UML

Unele limbaje de modelare obiect orientate au nceput s apare n perioada ntre mijlocul anilor 1970 i sfritul anilor 1980, cnd diferii cercettori i programatori propuneau diverse metode de analiza i proiectare obiect orientat (APOO). n perioada ntre anii 1989-1994 numrul total al limbajelor de modelare cele mai cunoscute a crescut de la 10 pna la mai mult dect 50. Muli utilizatori au avut dificulti serioase la alegerea limbajului de APOO, fiindc nici unul din limbajele propuse nu satisfcea toate cerinele ctre modelarea (construirea modelelor) sistemelor compuse. Acceptarea unor metode i notaii grafice n calitatea de standarde (IDEF0, IDEF1X) nu a putut s schimbe situaia de concuren acut ntre limbaje la nceputul anilor 90ci. Spre mijlocul anilor 1990 unele metode au fost esenial perfecionate i au obinut semnificaie proprie la rezolvarea diferitor probleme APOO. Cele mai cunoscute n acea perioad au devenit:

Metoda lui Grady Booch, care este cunoscut ca Booch sau Booch91, Booch Lite (mai trziu Booch93). Metoda lui James Rumbaugh, cunoscuta ca Object Modeling Technique OMT (mai trziu OMT-2). Metoda lui Ivar Jacobson, cunoscuta ca Object-Oriented Software Engineering OOSE.

Fiecare metod a fost orientat spre susinerea unor etape aparte ale APOO. De exemplu, metoda OOSE coninea mijloace de prezentare a cazurilor de utilizare, care au semnificaie esenial la etapa analizei cerinelor n timpul proiectrii business-aplicaiilor. Metoda OMT-2 era cea mai potrivit pentru analiza proceselor de prelucrare a datelor n sistemele informaionale. Metoda Booch93 era cea mai aplicabil la etapele de proiectare i exploatare a diferitor sisteme program. Istoria dezvoltrii limbajului UML ncepe n luna octombrie a anului 1994, cnd Grady Booch i James Rumbaugh din Rational Software Corporation au nceput s lucreze mpreun asupra unificrii metodelor Booch i OMT. Cu toate c aceste metode fiecare n parte erau destul de cunoscute, lucrul n comun era organizat pentru cercetarea tuturor metodelor OO cu scopul unificrii celor mai avantajoase trsturi ale lor. Proiectul acestei aa zise metode unificate (Unified Method) versiunea 0.8 a fost pregtit i publicat n luna octombrie anului 1995. n toamna aceluiai an a aderat la ei i Iv. Jacobson, tehnologul principal al companiei Objectory AV (Suedia), cu scopul integrrii metodei sale OOSE cu celelalte dou precedente. ncepnd lucrul spre unificarea metodelor, G. Booch, J. Rumbaugh i Iv. Jacobson au formulat urmtoarele cerinele ctre limbajul de modelare. El trebuie:

S ofere posibilitatea de a modela nu numai produse soft dar i clase mai largi de sisteme i business-aplicaii cu utilizarea noiunilor obiect orientate. S asigure n mod evident legatura ntre noiunile de baz ale modelelor nivelurilor conceptual i fizic. S asigure scalarea modelelor, ce este o calitate important a sistemelor complicate. S fie clar pentru analiti i programatori, de asemenea trebuie s fie susinut de ctre mijloace instrumentale speciale, realizate pe diferite platforme de calculator.

Dezvoltarea sistemei de notaii pentru APOO s-a dovedit s nu fie asemntoare cu dezvoltarea unui nou limbaj de programare. n primul rnd era necesar de rezolvat dou probleme:

1. Notaia dat trebuie s includ n ea i specificarea cerinelor? 2. Este necesar de extins notaia dat pna la nivelul limbajului de programare vizual? n al doilea rnd era necesar de gsit echilibrul ntre expresivitatea i simplitatea limbajului. Pe o parte, o prea simpl notaie limiteaz sfera problemelor poteniale care pot fi rezolvate cu ajutorul sistemului de notaii corespunztor. Pe de alt parte, o prea complicat notaie creaza dificulti adugatoare pentru studierea i aplicarea de ctre analiti i programatori. n cazul unificrii metodelor existente este necesar de a lua n consideraie interesele specialitilor, care au experien de lucru cu aceste metode, fiindc introducerea schimbrilor semnificative poate atrage dup sine nenelegerea i respingerea din partea utilizatorilor altor metode. Pentru a exclude opunerea neevident din partea unor specialiti, este necesar de a lua n considerarie interesele pturilor largi ale utilizatorilor. n continuare lucrul asupra limbajului de modelare unificat (Unified Modeling Language) a trebuit s ia n consideraie toate aceste circumstane. n aceast period suportul elaborrii limbajului UML devine unul din scopurile consoriului OMG (Object Management Group). Cu totate c consoriul OMG a fost creat nca n anul 1989 cu scopul de a elabora propuneri de standartizare a tehnologiilor orientate pe obiecte i componente CORBA, limbajul UML a captat statutul de a doua direcie strategic n lucrul OMG. Anume n cadrul OMG este creat comanda de elaboratori sub conducerea lui Richard Soli care va asigura lucrul de mai departe asupra unificrii i standartizrii limbajului UML. Eforturile lui G. Booch, J. Rumbaugh i Iv. Jacobson au dus la apariia primelor documente care conineau descrierea limbajului UML versiunea 0.9 (n iunie 1996) i versiunea 0.91 (n octombrie 1996). Aceste documente cu statut de propuneri RTP (Request For Proposals) au servit ca catalizator pentru discutarea n mas a limbajului UML de ctre diferite categorii de specialiti. Primele preri i reacii n ce privete limbajul UML indicau necesitatea de a-l completa cu notaii i construcii. Compania Rational Software mpreun cu cteva organizaii, care au manifestat dorina de a aloca resurse pentru elaborarea definiiei stricte a versiunii 1.0 limbajului UML, au fondat consoriul partenerilor UML n care iniial au intrat aa companii ca Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI Unisys. Aceste companii au asigurat suportul lucrului n continuare asupra definirii unei notaiei nc mai stricte i precise, ceea ce a dus la apariia versiunii 1.0 limbajului UML. Particularitatea limbajului UML const n aceea ca limbajul definete metamodelul semantic, dar nu modelul unei interfee concrete i metodele de prezentare i realizare a componentelor. n prezent toate ntrebrile elaborrii n continuare a limbajului UML sunt concentrate n limitele consoriului OMG. Grupul corespunztor de specialiti asigur publicarea materialelor care conin descrierea versiunilor urmtoare ale limbajului UML i a propunerilor RFP de standardizarea. O urmtoare etap de dezvoltare a acestui limbaj s-a terminat n martie anului 2003 cind consoriul OMG a publicat descrierea limbajului UML 2.0. Istoria elaborrii i dezvoltrii urmtoare al limbajului UML este reprezentat grafic n fig. 1. Pe baza tehnologiei UML Microsoft, Rational Software i ali furnizori de medii de dezvoltare a sistemelor de programare au elaborat modelul informaional unic care a fost numit UML Information Model. Se presupune c acest model va da posibilitatea diferitor programe care suport ideologia UML s fac schimb de componente i descrieri. Toate acestea vor permite crearea interfeei standarde ntre mijloacele de elaborare i mijloacele de modelare vizuala.

Fig. 1. Istoria dezvoltrii limbajului UML. Deja n prezent sunt elaborate mijloace de programare vizual pe baza lui UML care asigura integrarea, inclusiv generare directa i invers a codului de programe cu cele mai raspndite limbaje i medii de programare, aa cum sunt MS Visual C++, Java, C#, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Deoarece la elaborarea limbajului UML au fost luate n consideraie multe idei i metode de frunte se poate de ateptat c versiunile urmtoare ale limbajului UML vor fi influenate i de alte tehnologii i conceptii de perspectiv. n plus la aceasta n baza limbajului UML pot fi definite multe metode perspective noi. Limbajul UML poate fi extins fr o redefinire nucleului su.

2. Componente de baza ale limbajului UML

Limbajul UML reprezint limbajul de destinaie general al modelrii vizuale, care este elaborat pentru specificarea, vizualizarea, construirea i documentarea componentelor produsului soft, business-proceselor i altor sisteme. Totodat limbajul UML este un mijloc de modelare simplu i puternic care poate fi utilizat efectiv pentru construirea modelelor conceptuale, logice i grafice ale sistemelor complexe de diferit destinaie. Acest limbaj conine cele mai bune caliti ale metodelor ingineriei de program care au fost utilizate cu succes pe parcursul ultimilor ani la modelarea sistemelor complexe. Limbajul UML este bazat pe un anumit numr de noiuni principale care pot fi studiate i aplicate de ctre majoritatea programitilor i elaboratorilor cunoscui cu metodele de analiza i proiectarea obiect orientate. Totodat noiunile de baz pot fi combinate i extinse n asa fel c specialitii modelrii orientate pe obiecte pot elabora de sinestttor modele ale sistemelor complexe n diferite domenii de aplicare.

Utilizarea constructiv a limbajului UML este bazat pe inelegerea principiilor comune de modelare a sistemelor complexe i a particularitilor procesului de analiza i proiectarea obiect orientate. Alegerea mijloacelor expresive pentru construcia modelelor ale sistemelor complexe stabilete din vreme problemele care pot fi rezolvate cu ajutorul utilizrii acestor modele. Totodat unul din principiile de baz pentru construirea modelelor ale sistemelor complexe este principiul de abstractizare care presupune includerea n model numai a acelor aspecte ale sistemului proiectat, care au nemijlocit legtura cu executarea de ctre sistem a funciilor sale sau cu destinaia lui de baza. Totodat toate detalii de importana secundar sunt omise pentru ca procesul de analiza i cercetare a modelului primit s nu fie foarte complicat. Alt principiu de construcie a modelelor ale sistemelor complexe este principiul de multi-modele. Acest principiu reprezint afirmaia c nici un model unic nu poate descrie diferite aspecte ale sistemului complex. Cu privire la metodologia APOO aceasta nseamn c un model destul de complet al unui sistem complex admite un anumit numr de reprezentri (views) legate reciproc, fiecare din ele reflectnd adecvat un anumit aspect de comportare sau structura a sistemului. Totodat cele mai generale reprezentri ale unui sistem complex sunt considerate reprezentri statice i dinamice care la rndul lor pot fi divizate n alte reprezentri particulare. nca un principiu al analizei aplicate de sistem este principiul de construire ierarhic a modelelor sistemelor complexe. Acest principiu presupune cercetarea procesului de construire a modelului la diferite nivele de abstractizare sau detaliere n limitele reprezentrilor stabilite. Totodat modelul iniial sau elementar al unui sistem complex are reprezentarea cea mai generala (meta-reprezentare). Un astfel de model se construiete la etapa iniial de proiectare i poate s nu conin multe detalii i aspecte ale sistemului modelat.
Reprezentare logica Utilizatorul final Relaii structurale exterioare i inferioare Reprezentare realizrii Programistul Relaii ntre componente ale produsului soft Reprezentare deplasrii componentelor Administratorul de sistem Topologia legaturilor i comunicaiilor ale componentelor Model fizic Model static

Reprezentare procesului de funcionare Integratorul de sistem Randamentul i volumul componentelor al unui sistem Model conceptual

Model al unui sitem complex

Model dinamic

Fig. 2 Schema comun legturilor modelelor i reprezentrilor ale unui sistem complex n procesul APOO. n aa fel, un proces APOO poate fi reprezentat ca o coborre pe nivele: de la cele mai generale modele i reprezentri de nivel conceptual spre reprezentri mai particulare i detaliate ale nivelului logic i fizic. Totodat la fiecarea etap a procesului APOO modelele date sunt completate consecvent cu un numr din ce n ce mai mare de detalii ce le premite s reflecte mai adecvat diferite aspecte ale realizrii unui anumit sistem complex. Schema comun legturilor modelelor APOO este reprezentat n fig. 2.

2.1. Structura general a limbajului UML

UML const din dou pari interdependente:

Semantica limbajului UML reprezint un careva metamodel, care definete sintaxa abstracta i semantica noiunilor modelrii orientate pe obiecte n limbajul UML. Notaia limbajului UML reprezint o notaie grafica pentru reprezentarea vizual a semanticii limbajului UML.

Sintaxa abstract i semantica limbajului UML sunt descrise cu ajutorul unei anumite submulimi de notaii ale UML. n completare la aceasta, notatia UML descrie corespunderea sau reprezentarea notaiei grafice n semantica noiunilor de baza. n aa fel din punct de vedere funcional aceste dou pri completeaz una pe alt. Totodat semantica limbajului UML este descris pe baza unui metamodel care are trei reprezentri aparte: sintaxa abstract, reguli de construcia corect a expresiilor i semantica. Cercetarea semanticii limbajului UML presupune un careva stil semiformal de redare, care unifica limbaje naturale i formale pentru reprezentarea noiunilor de baza i regulilor de extindere a lor. Semantica se definete pentru dou tipuri de modele de obiecte: de structura i de comportare. Modelele de structur, cunoscute ca modele statice, descriu structura entitilor sau a componentelor unui sistem inclusiv clase, interfee, atribute i relaii. Modelele de comportare, numite uneori dinamice, descriu comportarea sau funcionarea obiectelor unui sistem, inclusiv metodele lor, colaborarea ntre ele, i procesul de schimbare a strilor unor componente aparte i al sistemului ntreg. Pentru rezolvarea unui diapazon att de larg de probleme de modelare este elaborat semantica destul de complet pentru toate componentele notaiilor grafice. Cerinele semanticii limbajului UML sunt concretizate la construirea anumitor tipuri de diagrame. Notaia limbajului UML include n sine descrierea elementelor semantice care pot fi utilizate la construcia diagramelor. Descriere formal a limbajului UML se bazeaza pe careva structur ierarhic comun a reprezentrilor de model care const din patru nivele:

Meta-metamodelul Metamodelul Modelul Obiectele utilizatorului

Nivelul de meta-metamodel creaz o baz iniial pentru toate reprezentri de metamodele. Destinatia principal a acestui nivel const n definiia limbajului pentru specificarea metamodelului. Meta-metamodelul definete modelul limbajului UML la cel mai nalt nivel de abstractizare i cea mai compact descriere a lui. Din alt parte, meta-metamodelul poate specifica cteva metamodele ce permite atingerea flexibilitii poteniale de includere a noiunilor adugtoare. Ca exemple de notaii ale acestui nivel pot fi meta-clasa, meta-atribut, meta-operaie. Semantica meta-metamodelului nu intra n descrierea limbajului UML. Aceasta face limbajul UML mai simplu pentru studiere, fiindc nu cere cunoaterea teoriei limbajelor formale i a logicii formale. Metamodelul este un exemplar sau concretizarea meta-metamodelului. Scopul principal acestui nivel este definirea limbajului pentru specificarea modelelor. Acest nivel este mai constructiv dect cel precedent, fiindc semantica lui ale noiunilor de baz este mai dezvoltat. Toate noiunile de 7

baz ale limbajului UML sunt noiunile nivelului de metamodel. Exemple de aceste notiuni sunt clasa, atributul, operaia, componenta, asocierea i multe alte. Modelul n contextul limbajului UML este exemplarul metamodelului n sensul c fiecare model concret a unui sistem trebuie s utilizeze numai noiunile lui metamodel concretizndu-le cu privire la situaia dat. Acest nivel este pentru descrierea informaiei despre un domeniu concret (de obiecte).Ca exemple a acestui nivel pot fi numele cmpurilor ale bazei de date proiectate, de exemplu, numele i prenumele angajatului, vrsta, postul, adresa, numrul de telefon. Totodat noiunile date sunt utilizate numai ca nume ale atributelor informaionale corespunztoare. Descrierea semanticii limbajului UML presupune cercetarea noiunilor de baz numai ale nivelului metamodel care reprezint numai exemplu sau caz particular al nivelului meta-metamodel.

2.2. Particularitatea (specificul) limbajului UML

UML este un instrument standard pentru crearea carcaselor de documentare (desenelor) ale produsului soft. UML este un limbaj de vizualizare, specificare, construcie i documentare artefactelor sistemelor de program. Vom aminti c artifactul o diagrama, un document, un model, o lege .a. este ceva ce descrie o anumit noiune a domeniului de obiecte. UML este elaborat n aa fel c s poat satisface cerinele ctre modelarea oricrui sistem ncepnd cu sisteme informaionale de dimensiunea unei ntreprinderi pna la Web-aplicaii distribuite i sisteme integrate n timp real. UML este un limbaj expresiv care permite cercetarea sistemei din toate punctele de vedere care au legtura cu elaborarea i desfsurarea ei urmtoare. Nectind la numrul mare de posibilitti expresive, acest limbaj rmne simplu pentru intelegere i utilizare. Cercetarea UML vom incepe cu modelul lui conceptual care conine trei elemente de baz: construcii de baz, reguli, care determin felul n care construcii pot fi combinate, i unele mecanizme comune ale limbajului. Cu totate c UML nu depinde de realitate modelat este mai bine s fie utilizat cnd procesul de modelare este bazat pe cercetarea descrierei textuale a proceselor executate n domeniu de obiecte i sistemul are arhitectura strict evideniat. n asa fel limbajul este ideal pentru Unificarea procesului de elaborare. Ca i oricare limbaj, UML const dintr-un dicionar i reguli care permit combinarea cuvintelor de intare i primirea construciilor cu sens. n limbajul de modelare dicionarul i regulile sunt orientate spre reprezentarea conceptual i fizic ale unui sistem. Limbajul de modelare, aa cum este UML, este un mijloc standard pentru elaborarea desenelor produsului soft. Modelarea este necesar pentru inelegerea sistemului. n mod obinuit un model unic nu poate fi de ajuns. Din contra, pentru inelegerea practic a oricrui sistem netrivial este necesar dezvolaterea unui numr enorm de modele interdependente. n aplicare ctre sisteme de program aceasta nseamn necesitatea unui limbaj cu ajutorul cruia din toate punctele de vedere poate fi descris arhitectura unui sistem pe parcursul ciclului de dezvoltare. Dictionarul i regulile unui aa limbaj ca UML explic modul de creare i de citire a anumitor modele, dar nu explic care modele sunt mai potrivite pentru diferite cazuri. Aceasta este sarcina principal pentru tot procesul de elaborare a produsului soft. Organizarea unui aa proces este un lucru deosebit de individual n limitele diferitor companii de program i grupelor de elaboratori ai produsului soft. Un proces bine organizat trebuie s arate care artefacte trebuiesc, care resurse sunt necesare pentru crearea lor, cum pot fi utilizate aceste artefacte pentru aprecierea lucrului executat i administrarea proiectului n ntregime. 8

2.2.1. UML limbaj de vizualizare

Trstura caracteristica a majoritii programitilor este faptul c gndurile despre realizarea proiectului sunt echivalente scrierei codului pentru acest proiect. Dac gndim despre proiectul nseamn c l codificm, desigur, unele lucruri sunt mai bine exprimate n codul al unui anumit limbaj de programare, fiindc codul sursei (listingul programului) este cel mai scurt drum spre scrierea algoritmelor i calcului. n unele cazuri programistul se ocup cu modelarea cu toate c acest proces nu este formal. Tratare de aa fel este plin de neplceri. Mai nti schimbarea prrilor despre modelul proiectat se poate numai atunci cnd toi participanii se exprim n acelai limbaj. Aceasta nseamn ca compania Dstr n-ar putea s angajeze un programist excelent n C dac el utilizeaz Delphi! Sau noul angajat n-ar putea s ineleag despre ce merge vorba. n al doilea rnd nu putem s inelegem aspectele de program al unui sistem fr modelul respectiv marginele cruia nu intr n cadrul limbajului textual de programare. De exemplu rolul ierarhiei claselor se poate de ineles studiind codul fiecrei clase, dar de ineles toat structura este foarte greu. Analogic cercetarea codului unui sistem nu permite s avei o imagine complet despre distribuirea fizic sau despre migraia obiectelor n aplicaii Web. n al treilea rnd dac analistul de sistem al companiei D-stre niciodat n-a creat modelurile proiectate n form clar toat informaia va fi pierdut daca analistul va fi atras de firma concurent. n cel mai bun caz rezultatele analizei acestui analist vor fi restabilite parial reieind din realizarea lor. Utilizarea UML-lui permite rezolvarea acestor problemelor. Acest limbaj de programare nu este doar un set de simboluri grafice, fiecare din ele se bazeaz pe semantica respectiv, ce nseamn c modelul creat de un elaborator poate fi uniform interpretat de altul i nu neaparat de alt om, n calitate de al doilea elaborator poate fi i un anumit mijloc instrumental. Sfritul primei probleme. Unele trsaturi ale sistemului sunt mai bine modelate ca textuale, alte ca grafice. Pratica arat ca n toate sistemele interesante exist structuri care nu pot fi interpretate fr ajutorul unui limbaj de programare. UML este un limbaj grafic ce permite rezolvarea acestei probleme (a doua problem). n sfrit modelul clar uureaz comunicarea, ce nseman c a treia problem nu se mai pune.

2.2.2. UML limbaj de specificare

n contextul dat prin specificare subnelegem construirea modelelor precise i complete. UML permite specificarea tuturor soluiilor importante care se refer la analiza, proiectarea i realizarea n procesul elaborrii produsului soft.

2.2.3. UML limbaj de construire

UML nu este un limbaj de programare vizual, dar toate modele elaborate n baza lui pot fi transformate n codul surs a diverselor limbaje de programare obiect orientate. Acele noiuni care sunt uor reprezentate grafic aa i sunt transformate (incluse) n UML, dar acele care mai bine sunt decrise n codul sursei se transform cu ajutorul limbajului de programare. Aa mod de reprezentare n limbaj de programare permite proiectarea direct sau generarea codului dup modelul UML ntr-un anumit limbaj de programare. Problema invers tot poate fi rezolvat, ea permite reconstruirea unui model conform realizrii existente. Aceast proiectare invers nu prezint ceva neobinuit. Daca n-am codificat informaia n realizare atunci ea poate fi pierdut la trecerea direct de la modelul la codul sursei. nseamn c pentru proiectarea invers (indirecta) sunt necesare mijloace instrumentale i colaborarea programistului sau analistului de sistem. Combinarea generrii directe a codului i proiectrii indirecte permite a lucra n prezentare grafic 9

i textual dac programele instrumentale asigur coordonare ntre aceste dou prezentri al proiectului. n afar de reflectare direct datorit expresivitii i uniformitii limbajul UML permite executarea modelelor, imitarea colaborrii sistemului i controlul sistemului care funcioneaz.

2.2.4. UML limbaj de documentare

Compania ce lanseaz programul soft pe lnga codul surs produce i alte artefacte, inclusiv:

cerine ctre sistem; arhitectura; proiectul; codul iniial; planuri de proiecte; teste; prototipuri; versiuni s.a.

n dependena de metodica elaborrii stabilit unele lucrurile se execut mai formal dect altele. Artifactele menionate mai sus sunt necesare pentru administrarea, aprecierea rezultatelor i ca mijloc de comunicare ntre membrii colectivului n timpul elaborrii proiectului i desfurrii lui. UML permite rezolvarea problemei de documentare a arhitecturii sistemului, ofer limbajul pentru definirea formal a cerinelor ctre sistemul i ctre teste, definete mijloace pentru modelarea lucrurilor pe etapa planificrii proiectului i administrrii versiunelor. Limbajul UML este destinat n primul rnd elaborrii sistemului de programare. Utilizarea lui este cu mult mai eficienta n urmatoarele sfere:

sisteme informaionale; servicii bancare i financiare; telecomunicaie; transport; industria de aprare, aviaie, cosmonautic; sisteme comerciale; electronica medical; tiina; distribuirea sistemului Web.

Sfera de aplicare a limbajului UML nu se limiteaz la modelarea produsului soft. Expresivitatea lui permite modelarea documentelor n sisteme juridice, modelarea structurii i functionalitatea sistemelor de deservire a pacienelor n spitale, proiectarea aparaturii. Pentru inelegerea limbajului este necesar de cunoscut principiile de baz a structurii acestui limbaj. Sunt numai trei principii i limbajul parc const din trei pri: construcii de baz ale limbajului, reguli de colaborare i anumite mecanizme comune. tiind toate aceste ideile vom putea citi modelele n UML i s le proiectm, desigur c vom ncepe cu cele mai simple. Pe parcursul obinerii experienei de lucru cu limbajul vom nva s utilizm posibilitile limbajului mai avansate. Dicionarul limbajului nclude trei tipuri de construcii de baz: 10

entiti abstracii ce sunt elemente de baz a modelului; relaii legturi ntre entiti; diagrame ce grupeaz interesele entitilor i relaiilor.

2.3. Entiti n UML

n UML sunt patru tipuri de entiti:

de structur; de comportament; de grupare; de adnotare.

Entiti sunt elementele OO de baz ale limbajului. Cu ajutorul entitilor este posibil crearea modelelor corecte. Entittile de structur sunt substantivele n modelurile ale limbajului UML. De regul ele reprezint pri statice ale modelelor care corespund elementelor conceptuale i fizice ale sistemului. Exist apte varieti de entiti de structur: Clasa (class) este o descriere a unei totaliti de obiecte cu atribute, operaii, relaii i semantica comun. Grafic o clasa se reprezint printr-un dreptunghi n care se specific numele, atributele i operaiile clase, exemplu este artat n fig. 3.
NumeleClasei <<->> AtributPrivat : char <<#>> AtributProtejat <<+>> AtributPublic <<+>> op1() <<+>> op2()

Fig. 3. Clasa. Interfaa (interface) este o totalitate de operaii care definesc servicii oferite de clas sau component. n diagrame interfaa se reprezint printr-un cerc etichetat cu numele interfeei, fig. 4. Interfaa foarte rar exist aparte de obicei ea este legat cu clasa sau componenta care o realizeaz.

Interfata1

Fig. 4. Interfaa. Colaborarea (collaboration) definete o interaciune, ea reprezint o totalitate de roluri i alte elemente care produc un efect cooperativ i care nu se aduce numai la suma termenilor unei adunri. Grafic colaborarea se reprezint printr-o elips cu linie ntrerupt, interiorul creia conine numai numele colaborrii, fig. 5.

Colaborare1

Fig. 5. Colaborare. 11

Cazul de utilizare (use case) este o descriere a consecutivitii de aciuni ndeplinite de sistem care produc un rezultat semnificativ pentru un anumit actor. Grafic cazul de utilizare se reprezint printr-o elips cu linie continue n interiorul creia se conine denumirea cazului de utilizare, fig. 6.
Cazul de utilizare 1

Fig. 6. Caz de utilizare. Clasa activ (active class) se numete o clas obiectele creia sunt antrenate n unul sau mai multe procese sau n iruri (threads) i deaceea ele pot iniia o aciune administrativ. Grafic o clas activ se reprezint ca i o clas simpl, dar se limiteaz cu un dreptunghi cu marginile groase i care conine numele, atributele i operaiile clasei date, fig. 7.
NumeleClasei <<->> AtributPrivat : char <<#>> AtributProtejat <<+>> AtributPublic <<+>> op1() <<+>> op2()

Fig. 7. Clasa activ. Componenta (component) este o parte fizic a sistemului, care corespunde unui anumit set de interfee i asigur realizarea lui. Grafic o component se reprezint printr-un dreptunghi cu anexe, care de obicei conine numai numele componentei, fig. 8.
Componenta1

Fig. 8. Component. Nodul (node) este un element real (fizic) al unui sistem care reprezint un mijloc de calcul cu un anumit volum de memorie i deseori cu capacitate de prelucrare a informaiei i care exist n timpul funcionrii unui produs soft. Grafic pentru reprezentarea nodului se utilizeaz cubul care conine numele nodului, fig. 9.
Nod 1

Fig. 9. Nod. apte elemente de baz enumerate: clase, interfete, colaborri, cazuri de utilizare, clase active, componente i noduri sunt entitile principale de structur care pot fi utilizate n diagramele UML. Exist i alte varietti ale entitilor de structur: actori, semnale, utilite (tipurile de clase), procese

12

i iruri (tipuri de clase active), aplicaii, documente, fiiere, biblioteci, pagini i tabele (tipuri de componente). Entitile de comportament (behaviour things) sunt prile dinamice ale modelului UML. Acestea sunt verbele limbajului care descriu comportarea modelului n timpul i n spaiu. Exist numai doua tipuri de entiti de comportament. Interaciunea (interaction) este un mod de comportare care const n schimb reciproc de mesaje (messages) ntre obiecte n cadrul unui anumit context pentru a atinge un anumit scop. Cu ajutorul interaciunii se descrie att o operaie ct i comportarea unui set de obiecte. Interaciunea presupune un ir de alte elemente ca mesaje, consecutivitate de aciuni (comportare, iniializat de ctre mesaje) i legturi (ntre obiecte). Grafic mesajul se reprezint print-o sgeat deasupr careia se indic numele mesajului, fig. 10.
CreazaObiect()

Fig. 10. Mesaj. Automatul (state machine) este un algoritm de comportare care definete o succesiune de stri prin care trece un obiect sau o interaciune pe parcursul ciclului de viaa rspunznd la diferite evenimente i reaciile lui la aceste evenimente. Cu ajutorul automatului se descrie comportarea unei clase sau a unei colaborri de clase. Cu automatul este legat un ir de alte elemente: stri, tranziii de la o stare la alt, evenimente care sunt entitti ce iniiaz tranziii i tipuri de actiuni reacii la tranziii. Grafic o stare se reprezint printr-un dreptunghi cu coluri rotungite care conine numele strii sau posibil i strile intermediare, fig. 11.
Stare 1

Fig. 11. Stare. Interaciunile i automatele sunt entitile principale de comportament care pot fi utilizate n diagramele UML. Semantic ele sunt legate cu diferite elemente de structur, n primul rnd cu clase, cooperri i obiecte. Entitile de grupare sunt prile organizatorice ale modelului UML. Ele reprezint blocuri n care poate fi divizat modelul. O astfel entitate primar este unic pachetul. Pachetele (packages) reprezint un mecanism universal de organizare n grupe. n pachet pot fi plasate entitile de structur, de comportament i alte entiti de grupare. Spre deosebire de componentele care exist real, n timpul execuiei unui program, pachetele au caracter pur conceptual, adic ele exist doar n timpul elaborrii. Pentru reprezentarea unui pachet se utilizeaz notaia unei mape cu semn de carte care conine deseori numai numele i doar uneori i coninutul, fig. 12.

Fig. 12. Pachet. 13

Entitile de adnotare sunt prile explicative ale unui model UML. Acestea sunt comentarii destinate descrierii adiionale, explicaiei sau observaiei ctre orice element al unui model. Exist numai un singur tip de baz al elementelor de adnotare remarca. Remarca (note) este numai un simbol pentru reprezentarea comentariilor sau a constrngerilor, legate de un element sau de un grup de elemente. Grafic o remarc se reprezint printr-un dreptunghi cu colul de sus din dreapta ndoit i care conine comentariul textual sau grafic, fig. 13.

Fig. 13. Remarca. Acest element este entitatea de adnotare principal care poate fi utilizat n modelul UML. De obicei remarca se utilizeaz pentru a asigura diagramele cu comentarii sau cu constrngeri care pot fi reprezentate sub form de text formal sau neformal. Exist i variante ale acestui element, de exemplu cerine care descriu comportarea dorit a unui sistem din punct de vedere exterior modelului.

2.4. Relaii UML

In limbajul UML sunt definite patru tipuri de relaii:

Dependena Asocierea Generalizarea Realizarea

Aceste relaii sunt construcii principale de legare n UML i sunt utilizate pentru construirea modelelor corecte. Dependena (dependency) este o relaie semantic ntre dou entiti astfel nct modificarea uneia din ele,a celei independente, poate influena semantica celeilalte, dependente. Grafic pentru reprezentarea dependenei se utilizeaza o linie ntrerupt, deseori cu sgeat care poate conine o etichet.

Fig. 14. Dependena. Asocierea (association) este o relaie de structur care descrie o totalitate de legturi, prin legtur se subnelege conexiunea semantic ntre obiecte. n calitate de simboluri suplementare pot fi utilizate numele unei asocieri, numele i multiplicitatea claselor rolurile asocierii. Numele asocierii nu este un element obligatoriu. Dac numele este dat, atunci el se scrie cu majuscul lnga linia ce corespunde asocierei. Grafic asocierea se reprezint printr-o linie (care uneori se termin cu o sgeat sau este etichetat), fig. 15.
NewClass 1 -Angajat Angajeaza -Angajator * NewClass2

Fig. 15. Asocierea. 14

O form special sau caz particular al relaiei de asociere se socoate relaia agregrii care la rndul su are o form special compoziia. Agregare (aggregation) este o anumit relaie ntre ntreg i prile lui componente. Aceast relaie are un sens fundamental pentru descrierea sistemelor complexe fiindc se utilizeaz pentru reprezentarea legturilor parte-ntreg. Dezvluind structura interioar a sistemului, relaia de agregare arat din ce elemente const sistemul i cum elementele sunt legate. Din punct de vedere al modelului prile aparte ale sistemului pot fi socotite ca elemente i ca subsisteme care la rndul lor pot crea componente sau subsisteme. Grafic relaia de agregare se reprezint printr-o linie continu, unul din capetele creia reprezint un romb gol. Acest romb arat ntregul i restul - prile, fig. 16.
Intreg Parte

Fig. 16. Agregare. Relaia compoziie este cazul particular al relaiei de agregare. Aceast relaie este destinat prezentrii formei speciale a relaiei parte-ntreg n care prile componente sunt n interiorul priii ntregi. Specifica legturii ntre ele const n aceea c prile componente nu pot exista fr partea ntreag, adic cu distrugerea ntregului se destrug i prile componente a lui. Grafic relaia de compoziie se reprezint printr-o linie continu, unul din capetele cruia reprezint un romb haurat. Acest romb arat clasa-compoziie sau ntregul i restul sunt prile lui, fig. 17.

Fig. 17. Compoziie. Generalizarea (generalization) este o relaie de tip specializare/generalizare n urma creia un obiect al elementului specializat (descendent) poate substitui obiectul elementului generalizat (printe). Descendentul (child) motenete structura i comportamentul printelui (parent) su. Grafic relaia de generalizare se reprezint printr-o linie cu o sgeat goal care arat printe, fig. 18.
Child Parent

Fig. 18. Generalizarea. Realizarea (realization) este o relaie semantic ntre clasificatori n care un clasificator definete un contract, iar cellat garanteaz ndeplinirea lui. Relaia de realizare se ntlnete n cazurile urmtoare: ntre interfee i clase sau componente care realizeaz aceste interfee, i ntre cazuri de utilizare i colaborri care le realizez. Relaia de realizare se reprezint printr-o linie ntrerupt cu o sgeat goal, ca ceva intermediar ntre relaiile generalizare i dependena, fig. 19.

Fig. 19. Realizare. 15

2.5. Diagrame UML

n cadrul limbajului UML toate reprezentrile modelului unui sistem complex sunt fixate n calitate de construcii speciale grafice care deseori sunt reprezentate sub form de graf conex cu noduri entiti i muchii relaii. n UML sunt definite nou tipuri de diagrame:

Diagrame cazurilor de utilizare (use case diagram) Diagrame de clase (class diagram) Diagrame de comportament (behavior diagrams) o Diagrame de stri (statechart diagram) o Diagrame de activiti (activity diagram) o Diagrame de interaciune (interaction diagrams) Diagrame de secven (sequence diagram) Diagrame de colaborare (collaboration diagram) Diagrame de realizare (implementation diagrams) o Diagrame de componente (component diagram) o Diagrame de plasare (deployment diagram)

Lista acestor diagrame i denumirilor respective este canonica n caz dac diagramele reprezint partea integrant a notaiei grafice a limbajului UML. Mai mult dect att, procesul APOO este strns legat de procesul construirii acestor diagrame. Totodat o totalitate de diagrame construite n aa fel este suficient n caz dac diagramele conin informaia necesar pentru realizarea proiectului unui sistem complex. Fiecare din aceste diagrame detalizeaz i concretizeaz diferite reprezentri despre modelul unui sistem complex n termenii limbajului UML. Totodat diagrama cazurilor de utilizare reprezint cel mai general model conceptual al unui sistem complex care este iniial pentru construirea tuturor celorlalte diagrame. Diagrama de clase este un model logic care reflect aspectele statice ale procesului de construire structural a unui sistem complex. Diagramele de comportament la fel sunt varieti ale unui model logic care reflect aspectele dinamice ale procesului de funcionare a unui sistem complex. Diagramele de realizare sunt destinate reprezentrii fizice a componentelor sistemului complex i de aceea sunt atribuite modelului fizic. Modelul integrat al unui sistem complex n notaia UML (fig. 20) se reprezint ca totalitatea diagramelor enumerate mai sus.

Fig. 20. Model al unui sistem complex n notaia UML. 16

3. Diagarama cazurilor de utilizare (use case diagram)

Modelarea vizual n UML poate fi reprezentat ca un oarecare proces de lansare pe niveluri de la cel mai general i abstract model conceptual al sistemului iniial ctre model logic i mai apoi fizic, ce corespunde unui sistem de program. Pentru atingerea acestui scop de la nceput se creaz un model n form de diagarama cazurilor de utilizare (use case diagram) care descrie destinaia functional a sistemului sau cu alte cuvinte descrie ceea ce sistemul va executa n procesul su de funcionare. Diagrama cazurilor de utilizare reprezint un model iniial conceptual al unui sistem n procesul de proiectare i exploatare. Proiectarea a unei diagrame a cazurilor de utilizare urmrete scopurile urmtoare:

determinarea limitelor comune i a contextului domeniului de modelare la etapele iniiale de proiectare a unui sistem; formularea cerinelor comune ctre comportare funcional a sistemului proiectat; elaborarea modelului iniial conceptual al unui sistem pentru detalierea de mai trziu n forma modelelor logice i fizice; pregtirea documentrei iniiale pentru interaciunea elaboratorilor unui sitem cu clienii i utilizatorii.

Esena acestei diagrame const n faptul c: sistemul proiectat se reprezint ca o colecie de entiti i actori care colaboreaz cu sistemul cu ajutorul aa numitor cazuri de utilizare. Totodat orice entitate care colaboreaz cu sistemul din afar poate fi numit actor. Aceasta poate fi un om, o instalare tehnic, un program sau oricare alt sistem care poate fi surs de aciune pentru sistemul proiectat n aa mod, cum l determin colaboratorul. La rndul su, use case-ul este creat pentru descrierea serviciilor pe care sistemul le ofer actorului. Cu alte cuvinte fiecare caz de utilizare definete o colecie de aciuni executate de sistem n timpul dialogului cu actorul. Totodat nimic nu este spus despre aceea n ce mod va fi realizat colaborare ntre actori i sistem. n caz general, diagrama cazurilor de utilizare reprezint un graf deosebit, care este o notaie grafic pentru prezentarea cazurilor de utilizare concrete, actorilor, poate i a unora interfee i pentru prezentarea legturilor ntre aceste elemente. Totodat componente aparte ale diagramei pot fi incluse ntr-un dreptunghi, care semnific sistemul proiectat n ntregime. Trebuie de specificat c legturile acestui graf pot fi de numai anumite tipuri de interaciuni ntre actori i cazuri de utilizare, care mpreun descriu servicii i cerine funcionale ctre sistemul modelat.

3.1. Cazul de utilizare

Structura sau elementul standart al limbajului UML caz de utilizare se folosete pentru specificarea particularitilor comune ale comportrii unui sistem sau a oricrei alte entitti n domeniul de lucru fr cercetarea structurii interne a acestei entiti. Fiecare caz de utilizare determin o succesiune de aciuni care trebuie sa fie executate de ctre sistemul poiectat la colaborarea lui cu actorul corespunztor. Diagrama cazurilor de utilizare poate fi completat cu text explicativ, care desfoar sensul sau semantica componentelor ce o compun. Acest text se numete adnotare sau scenariu. Cazul de utilizare aparte se noteaz cu o elips n interiorul creia se conine denumirea prescurtat sau numele n form de verb cu cuvinte explicative (fig. 6). Scopul cazului de utilizare const n determinarea aspectului terminal sau fragmentului de comportare a unei entiti fr desfurarea structurii interne a acestei intiti. n calitate de aa 17

entitate poate fi un sistem iniial sau un element al modelului care dispune de comportament propriu, precum este subsitemul sau clasa n modelul unui sistem. Fiecare caz de utilizare corespunde unui serviciu aparte, care reprezint o entitate modelat sau un sistem la cererea utilizatorului (actorului), mai precis determin metoda aplicat ctre anumit entitate. Serviciul care este iniializat la cererea utilizatorului reprezint o succesiune terminat de aciuni. Aceasta nseamn c dup ce sistemul va termina prelucrarea cererii utilizatorului el (sistemul) trebuie sa se intoarc n starea iniial n care este gata pentru a indeplini cererile urmtoare. Cazurile de utilizare descriu nu numai colaborarea ntre utilizatori i entiti, dar i reacia entitii la primirea anumitor mesaje de la utilizatori i asupra percepiei acestor mesaje n afar entitii. Cazurile de utilizare pot include (conine) descrierea specificaiilor modurilor de realizare a serviciului i a diferitor situaii excepionale, aa cum este prelucrarea corect a erorilor unui sistem. Mulimea cazurilor de utilizare n total poate determina toate aspecte posibile comportrii ateptate a unui sistem. Pentru comoditate mulimea cazurilor de utilizare poate fi considerat ca un pachet aparte. Din punct de vedere sistemo-analitic cazurile de utilizare pot fi folosite pentru specificarea cerinelor externe ctre sistemul proiectat i pentru specificarea comportrii funcionale a sitemului deja existent. Exemple de cazuri de utilizare pot fi aciunile urmtoare: verificarea strii contului curent al clientului, intocmirea comenzii la procurarea mrfii, obinerea informaiei suplimentare despre solvabilitatea clientului, reprezentarea formei grafice la ecranul monitorului s.a.

3.2. Actori
Actorul reprezint orice entitate extern sistemului modelat, care colaboreaz cu sistemul i utilizeaz posibilitile lui funcionale pentru atingerea anumitor scopuri i pentru rezolvarea problemelor particulare. Totodat actorii sunt utilizai pentru notarea mulimii rolurilor coordonate ale utilizatorilor n procesul de colaborare cu sistemul proiectat. Fiecare actor poate fi considerat un anumit rol aparte relativ unui caz de utilizare concret. Notaia grafic standard a unui actor n diagram este omuleul sub care se indic numele actorului (fig. 21).

Fig. 21. Actor. n unele cazuri actorul poate fi notat ca dreptunghiul clasei cu cuvntul-cheie actor i cu elementele comune ale clasei. Numele actorilor trebuie s fie scrise cu litere majuscule i trebuie s respecte recomandrile la utilizarea numelor pentru tipurile i clasele modelului. Totoadat simbolul actorului aparte leag descrierea corespunztoare a actorului cu un anumit nume. Numele actorilor abstraci, aa cum i a altor elemente abstracte n limbajul UML, se recomand de notat n italic. Ca exemplu de actori pot fi: clientul unei bnci, angajatul unei bnci, vnztorul unui magazin, managerul seciei de vnzare, pasagerul unui avion, conductorul unui auto, administratorul unui hotel, celularul i alte entiti, care au legtur cu modelul conceptual care corespunde domeniului de lucru. 18

Actorii sunt utilizai pentru modelarea entitilor exeterne sitemului de entiti proiectat, care acioneaz reciproc cu sistemul i pe care l utilizez n calitate de utilizatori separai. n calitate de actori pot fi i alte sisteme, subsisteme ale sistemului proiectat sau clase aparte. Este important s intelegem c actorul definete o anumit mulime de roluri coordonate, care pot fi utilizatorii unui sistem dat n procesul de colaborare. n fiecare moment de timp cu sistemul colaboreaz un anumit utilizator n unul din roluri date. Ca exemplu evident de actor poate fi un anumit utilizator al sistemului cu parametri de autentificare proprie.

3.3. Interfee
Interfaa (interface) specific parametrii modelului care sunt vizibili din afar fr indicarea structurii lor interne. n limbajul UML interfaa este clasificatorul care caracterizez numai o parte limitat a comportrii unei entiti modelate. Referitor la diagrama cazurilor de utilizare interfeele definesc o totalitate de operaii ce asigur serviciile necesare sau funcionalitatea pentru actorii. Interfeele nu pot conine nici atribute, nici stri, nici asocieri dirijate. Ele conin numai operaii fr indicarea specificaiilor de realizare a lor. O interfa este formal echivalent clasei abstracte fr atribute i metode numai cu prezena operaiilor abstracte. n diagrama cazurilor de utilizare o interfa este reprezentat ca un cercule mic lng care este indicat numele lui. (fig. 22, a). n calitatea de nume poate fi un substantiv, ce caracterizeaza informaia corespunztoare sau serviciu (de exemplu, sirena, camera video), dar mai des este oricare rnd de text (de exemplu, sensor, interpolare ctre baza de date, forma de introducere, dispozitiv de semnalizare sonor). Dac numele este nscris n limba englez, atunci acest nume trebuie s inceap cu majuscula I, de exemplu, ISecurelnformation, ISensor (fig. 22, ).

Fig. 22. Reprezentarea grafica a interfeelor n diagrama cazurilor de utilizare. Simbolul grafic al unei interfee aparte n diagram poate fi conectat cu cazul de utilizare ce l susine cu o linie nentrerupt (continu). Linia nentrerupt n acest caz indic faptul c cazul de utilizare legat cu interfaa trebuie s realizeze toate operaiile necesare pentru aceast interfa, sau poate i mai mult (fig. 23, a). n afar de aceasta, interfeele pot fi legate cu cazurile de utilizare cu o linie ntrerupt cu o sgeat (fig. 23, b), ce nseamna c cazul de utilizare specific numai cel serviciu, care este necesar pentru realizarea interfeei date.

Fig. 23. Reprezentarea grafic a legturilor ntre interfee i cazuri de utilizare. Din punct de vedere sistemo-analitic interfaa nu numai separ specificaia operaiilor unui sistem de la realizarea lor, dar i definete limetele comune ale sistemului proiectat. Ulterior interfaa poate fi specificat cu indicarea acelor operaii care specific un aspect de colaborare al sistemului. n acest caz el se reprezint n forma de dreptunghi cu cuvnt-cheie interface n secia de nume, cu 19

secia de atribute goala i cu secia de operaii completat. Dar aa fel de reprezentare grafic se utilizeaz n diagrama claselor sau n diagrame ce caracterizeaz comportarea sistemului modelat. Importana interfeelor const n faptul c ele definesc noduri de jonciune n sistemul proiectat, ce este necesar pentru organizarea lucrului colectiv asupra proiectul. Mai mult dect att, specificaia interfeelor contribuie la modificarea uoarla trecerea la soluii tehnologice ale unui sistem deja existent. n acest caz schimbrii este supus numai realizarea operaiilor, dar nu funcionalitatea sistemului. Aceasta asigur compatibilitatea versiunilor urmtoare de program cu cele iniiale la folosirea tehnologiei n spiral de creare sistemelor de program.

3.4. Legturile n diagrama a cazurilor de utilizare

ntre componentele diagramei cazurilor de utilizare pot s existe diferite legturi care desciu colaborarea exemplarelor unor actori i cazurilor de utilizare cu exemplarele altor actori i cazuri. Un anumit actor poate s colaboreze cu mai multe cazuri de utilizare. n acest caz actorul dat se adreseaz ctre cteva servicii ale sistemului dat. La rndul su un anumit caz de utilizare poate s colaboreze cu mai muli actori, pentru care el acord serviciul su. Trebuie de observat c dou cazuri de utilizare definite pentru aceeai entitate nu pot colabora unul cu altul, fiindc fiecare din ele descrie o variant propie terminal de utilizare a acestei entiti. Mai mult dect att, cazurile de utilizare ntotdeauna presupun careva semnale i mesaje pentru colaborarea cu actorii n afara limetelor sistemului. n acelai timp pot fi definite alte metode de colaborare ntre elemente n nteriorul sistemului. n limbajul UML sunt cteva tipuri standarde de relaii ntre actori i cazuri de utilizare:

relaia de asociere (association relationship) relaia de extindere (extend relationship) relaia de generalizare (generalization relationship) relaia de cuplare (include relationship)

Totodat proprietile generale ale cazurilor de utilizare pot fi reprezentate prin trei metode diferite, i anume cu ajutorul relaiei de extindere, generalizare i cuplare.

3.4.1. Relaia de asociere

Relaia de asociere este o noiune fundamental n limbajul UML i mai mult sau mai puin se utilizeaz la crearea tuturor modelelor grafice n forma diagramelor canonice. Cu privire la diagrama cazurilor de utilizare relaia de asociere specific rolul deosebit al actorului n cazul de utilizare aparte. Cu alte cuvinte, asocierea specific particularitatea semantic de colaborare a actorilor i cazurilor de utilizare n modelul grafic. n aa mod aceast relaie stabilete ce rol joac actorul la colaborarea cu exemplarul cazului de utilizare. n diagrama cazurilor de utilizare precum i n alte diagrame relaia de asociere se noteaz cu o linie nentrerupt ntre actor i cazul de utilizare. Aceast linie poate s aib condiii suplementare, de exemplu, numele i multiplicitatea (fig. 24).

Fig. 24. Reprezentare grafic relaiei de asociere ntre acotr i caz de utilizare. 20

Multiplicitatea (multiplicity) asocierei se indic lnga notaia componentului diagramei care este membru acestei asocieri. Multiplicitatea caracterizeaz cantitate total de exemplare concrete al unui component anumit care pot fi n calitate de elemente acestei asocieri. Cu privire la diagrame cazurilor de utilizare multiplicitate are o notaie specific n forma de una sau mai multe cifre i posibil simbolul special *. Pentru diagrama cazurilor de utilizare mai rspndite sunt patru forme de nscriere a multiplicitii relaiilor de asociere:

Numr ntreg nenegativ (inclusiv cifra 0) este destinat indicaiei multiplicitii care este strict fixat pentru elementul corespunztor asocierii. n acest caz cantitate de exemplare a actorilor sau cazurilor de utilizare, ce pot fi i elemente ale relaiei de asociere, ntocmai este egal cu numrul indicat.

Ca exemplu a acestei forme de nregistrare a multiplicitii relaiilor de asociere este indicarea multiplicitii 1 pentru actorul Clientul bncii (fig. 24). Aceast nregistrare nseamna c fiecare exemplar al cazului de utilizare Perfectarea creditului pentru clientul bncii poate s aib n calitate de element propriu un singur exemplar de actor Clientul bncii. Cu alte cuvinte, la perfectarea creditului n banc trebuie de luat n vedere c fiecare credit concret se perfecteaz pentru un singur client al acestei bnci.

Dou numere ntregi nenegative, separate cu dou puncte i scrise n forma: primul numr..al doilea numr. Aceast nregistrare n limbajul UML corespunde notaiei pentru o mulime sau pentru un interval de numere ntregi, care se utilizeaz n unele limbaje de programare pentru indicarea limitelor masivului de elemente. Aceast nregistrare trebuie s fie neleas ca o mulime de numere ntregi nenegative care sunt n ordinea crescatoare: {numar_1, numar_1+1, numar_1+2, , numar_2}. Evident c primul numr trebuie s fie strict mai mic dect al doilea numr n sens aritmetic, totodat primul numr poate fi egal cu 0.

Ca exemplu a acestei forme de nregistrare a multiplicictii asocierii 1..5. Aceast nregistrare nseamna c cantitatea de exemplare ale acestui component care pot fi i elemente ale acestei asocieri, este egal unui numr preliminar necunoscut din mulimea numerelor ntregi {1, 2, 3, 4, 5}. Aceast situaie are loc cnd n calitate de actor este clientul bncii, dar n calitate de caz de utilizare este procedura deschiderii contului n banc. Totodat cantitatea de conturi ale fiecrui client n aceast banca, reieind din consideraii tactice, poate fi nu mai mult dect 5. Aceste consideraii tocmai i sunt cerinele exterioare sistemului proiectat i sunt definite de ctre client la etapele iniiale de APOO.

Dou simboluri separate cu doua puncte. Totodat primul dintre ele este un numr ntreg nenegativ sau 0, iar al doilea este simbolul special *. Aici simbolul * nseamn un numr arbitrar ntreg nenegativ, valoarea cruia este necunoscut la momentul nregistrrii unei relatii de asociere.

Ca exemplu acestei forme de nregistrare de multiplicitate asocierei 2 ..*. Aceast nregistrare nseamn c cantitatea de exemplare ale acestui component, care pot fi i elementele acestei asocieri, este egal cu un numr anticipat necunoscut din mulimea numerelor ntregi {2, 3, 4}.

Simbolul *, care este prescurtarea nregistrrii intervalului 0..*. n acest caz cantitatea de exemplare ale acestui component al relaiei de asociere poate fi oricare numr ntreg nenegativ. Totodat 0 nseamn c pentru careva exemplare ale componentului corespunztor aceast relaie de asociere poate nici s nu aib loc. 21

Ca exemplu acestei forme de nregistrare poate fi cercetat multiplicitatea asocierei pentru cazul de utilizare ntocmire creditului pentru clientul bncii (fig. 24). n acest caz * nseamn fiecare client aparte al acestei bnci poate ntocmi pentru sine cteva credite, totodat numrul lor comun este necunoscut i nelimitat. Unele clieni pot s nu aib credite deloc (cazul valorii 0). Dac multiplicitatea asocierei nu este indicat atuinci implicit se ia valoarea egal cu 1.

3.4.2. Relaia de extindere

Relaia de extindere definete interconexiunea exemplarelor cazului de utilizare cu cazul general, proprietile cruia sunt definite pe baza modului de uniune a exemplarelor date. n metamodelul relaie de extindere este direct i indic care condiii concrete pot fi utilizate pentru unele exemple unui anumit caz de utilizare, definite pentru extinderea cazului de utilizare dat. Dac are loc relaie de extindere de la cazul de utilizare A la cazul de utilizare B, acest lucru nseamn c proprietile exemplarului cazului de utilizare B pot fi adugate datorit proprietilor extinse a cazului de utilizare A. Relaia de extindere ntre cazurile de utilizare reprezint o linie punctat cu sgeat (cazul relaiei de dependen), direct de la acel caz de utilizare, care reprezint extinderea cazului de utilizare iniial. Aceast linie cu sgeat este marcat cu cuvntul extend (extinde), fig. 25.

Fig. 25. Exemplu de reprezentare grafic a relaiei de extindere ntre cazurile de utilizare. Relaia de extindere indic acel fapt c unul din cazurile de utilizare poate fi conectat la comportamentul su care-va comportament adugtor, definit pentru un alt caz de utilizare. Relaia dat include o anumit condiie i exilri la puncte de extensie n cazul de utilizare de baz. Pentru alocarea extinderii este necesar de a executa o anumit condiie a relaiei date. Exilri la puncte de extensie definesc acele locuri n cazul de utilizare de baz n care trebuie s fie pus extinderea respectiv n timpul executrii condiiei. Unul din cazurile de utilizare pot fi extinderea pentru cteva cazuri de baz i pot avea ca extinderi proprii nc cte-va alte cazuri. Cazul de utilizare de baz poate fi adugtor independent de la alte extensii. Semantica relaiei de extensie este definit n felul urmtor. Dac exemplarul cazului de utilizare execut anumit consecven de aciuni, care definete comportamentul lui i n urma cruia exist un punct de extensie la alt exemplar a cazului de utilizare, care este unul din primele puncte de extensie a cazului iniial, atunci controleaz condiia relaiei date. Dac condiia este executat, consecvena iniial de aciuni extinde datorit includerea aciunii altui exemplar a cazului de utilizare. Trebuie de meninut, c condiia relaiei de extensie este controlat numai o dat n timpul exilrii la un punct de extensie i dac aceasta este executat, atunci toate cazurile de extindere utilizate se folosesc n cazul de baz.

3.4.3. Relaia de generalizare

Relaia de generalizare este folosit pentru indicarea faptului c care-va caz de utilizare A poate fi generalizat la cazul de utilizare B. n urma cruia, cazul A va fi cazul special cazului B. n urma cruia cazul B se numete printe relativ A, iar cazul A descendent relativ cazului de utilizare B. 22

Este nevoie de menionat, c descendentul motenete toate proprietile i comportamentul printelui su i poate avea proprietile i comportamentul su adugtor. Grafic relaia dat este reprezentat cu linia ntreag cu sgeat n forma de triunghi nehaurat, care indic cazul de utilizare printe (fig. 26). Aceast linie cu sgeat are un nume specific sgeata generalizare.

Fig. 26. Exemplu de reprezentare grafic a relaiei de generalizare ntre cazuri de utilizare. Relaia de generalizare ntre cazurile de utilizare este folosit n acele cazuri cnd este necesar de indicat c cazul de utilizare derivat conine toate atributele i particularitile comportamentului cazurilor de baz. n urma cruia cazurile de utilizare derivate pot participa n relaii cazurilor de baz. n urma sa cazurile derivate pot avea proprieti noi de comportament, care nu au cazurile de utilizare de baz, dar i de a preciza sau modifica proprietile de comportament motenite. Relativ cu relaia dat un variant de utilizare poate avea cte-va cazuri de baz. n acest caz se realizeaz motenirea multipl a proprietilor i comportamentului cazurilor de baz. Din alt parte un caz de utilizare poate fi printe pentru cte-va cazuri de utilizare derivate, ce corespunde caracterului taxonometric relaiei de generalizare. ntre actori aparte de asemenea poate exista relaia de generalizare. Aceast relaie este direct i indic faptul c specializarea unor actori este relativ cu alii. De exemplu, relaia de generalizare de la actorul A la actorul B indic faptul c fiecare exemplar a actorului A este concomitent cu exemplarul actorului B i are toate proprietile lui. n acest caz actorul B este printe relativ cu actorul A, iar actorul A este descendentul actorului B. n urma cruia actorul A are posibilitatea de joac a aceleeai mulimi de roluri ca i actorul B. Grafic relaia dat este reprezentat cu sgeata de generalizare, adic cu linia ntreag cu sgeat n form de triunghi nehaurat, care indic printele actorului (fig. 27).

Fig. 27. Exemplu de reprezentare grafic a relaiei de generalizare ntre actori.

3.4.4. Relaia de tip include

Relaia de tip include n dou cazuri de utilizare indic un comportament stabilit pentru un caz de utilizare este inclus ca component compus n consecutivitatea comporatamentului a altui caz de utilizare. Relaia dat este relaie binar ndrepatat, n acel sens c perechea de exemplare a cazului de utilizare ntodeauna se afl la locul ei n relaia de tip include. Semantica acestei relaii este definit n felul urmtor. Cnd exemplarul primului caz de utilizare n timpul executrii ajunge la punctul de includere n consecutivitatea comporatamentului exemplarului al doilea a cazului de utilizare, exemplarul primului caz de utilizare execut consecutivitatea aciunilor, care definesc comportamentul exemplarului al doilea a cazului de utilizare, dup ce continu executarea aciunilor comportamentului su. n urma cruia se presupune c dac exemplarul primului caz de utilizare poate include cteva exemplare a altor cazuri de 23

utilizare, aciunile lor trebuie s se sfreasc ntr-un anumit moment, dup ce trebuie s continue executarea aciunilor ntrerupe exemplarele primului caz de utilizare n conformitate cu comportamentul lui dat. Unul din cazurile de utilizare poate fi inclus n alte cazuri i poate include alte cazuri. Cazul de utilizare ce este inclus poate fi independent de cazul de baz, anume el d ultimului un comportament incapsulat, detalii realizaiei cruia sunt ascunse i pot fi liber mprite ntre cte-va cazuri de utilizare incluse. Mai mult, cazul de baz poate depinde numai de rezultatele executrii comportamentului inclus n el, sar nu de la structura cazurilor incluse n el. Relaia de tip include orientat de la cazul de utilizare A la cazul de utilizare B indic c fiecare exemplar al cazului A include proprieti funcionale stabilite pentru cazul B. Aceste proprieti specializeaz comportamentul cazului respectiv A n diagrama dat. Grafic relaiile date sunt indicate cu linia punctat cu sgeat (cazul relaiei de dependen), ndreptate de la cazul de utilizare de baz la cazul ce este inclus. n urma cruia linia cu sgeata este indicat cu cuvntulcheie include, (fig. 28).

Fig. 28. Exemplu de reprezentare grafic a relaiei de tip include ntre cazuri de utilizare.

3.5. Exemplu de construirea diagramei cazurilor de utilizare

Ca exemplu vom lua procesul de modelare a sistemului de vindere a mrfurilor dup catalog, care poate fi utilizat n timpul crerii sistemelor informaionale respective. n calitate de actori a sistemului dat pot fi dou subiecte, unu din care este vnztor, iar altul cumprtor. Fiecare din actori interacioneaz cu sistemul de vindere a mrfurilor dup catalog i este utilizatorul lui, adic ambele se adreseaz la servisul respectiv A perfecta comanda de cumprare a mrfii. Este evedent din cerinele adresate la sistem c servisul reprezint cazul de utilizare a diagramei, strutura de baz poate include numai doi actori i un singur caz de utilizare (fig. 29).

Fig. 29. Diagrama cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a mrfurilor dup catalog. Valorile divizibilitilor n diagrama dat reflect regulile de baz sau logica de formare a cerinelor la vinderea mrfurilor. Conform regulilor respective un vnztor poate participa n formarea a ctorva comenzi, n acelai timp fiecare comand poate fi format numai de un singur vnztor, care are responsabilitatea pentru corectitudinea formrii lui i respectiv va avea rsplat pentru formarea dat. Din alt parte, fiecare cumprtor poate forma cteva comenzi i n acelai timp fiecare comand trebuie s fie format la un singur cumprtor, care va avea drepturile de proprietate la marf dup achiziionarea ei. 24

Etapul urmtor n diagrama dat este A perfecta comanda de cumprare a mrfii poate fi precizat pe baza ntroducerii a patru cazuri de utilizare adugtoare. Acest lucru este evident din analiza mai detaliat a procesului de vindere a mrfii, ce permite de alege ca servicii separate acele aciuni ca asigurarea cumpratorului cu informaia despre marf, coordonarea condiiilor de plat i comandarea mrfii de la depozit. Evident c aciunile indicate desfoar comportamentul cazului de utilizare iniial i anume concretizarea lui i de aceea ntre ele v-a exista relaia de tip include. n cazul nostru catalogul cu mrfuri poate fi comandat de cumprtor sau vnztor cnd apare necesitatea de a alege marfa i precizarea detaliilor de vindere. Corect este reprezentat serviciul Cererea catalogului cu mrfuri ca caz de utilizare independent. Dup detalizare diagrama cazurilor de utilizare va avea 5 cazuri de utilizare i 2 actori (fig. 30), ntre care este stabilit relaia de tip includ i extend.

Fig. 30. Variantul mai detaliat a diagramei cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a mrfurilor dup catalog. Diagrama cazurilor de utilizare de mai sus, la rndul su poate fi mai detaliat pentru precizarea mai adnc, ce se cere de la sistemul de comand i concretizarea detaliilor pentru realizarea urmtoare. Detalizarea poate fi executat pe baza indicrii relaiilor adugtoare de tipul relaiei generalizareaspecializarea pentru componentele diagramei deja existente. n sistemul de vindere a mrfurilor poate avea valoarea independent i proprietile specifice o categorie independent de mrfuri calculatoare. n acest caz n diagram poate fi adugat un caz de utilizare Perfectarea comenzii de achiziionare a calculatorului i cu actori Cumprator de calculatoare i Vnztor de calculatoare, care sunt legate cu componentele corespunztoare a diagramei relaiei de generalizare (fig. 31).

25

Fig. 31. Unul din variantele de concretizare a diagramei cazurilor de utilizare pentru exemplul de sistem de vindere. Construirea diagramei cazurilor de utilizare este primul etap a procesului analizei a obiectului orientat i proiectri, scopul cruia este de reprezentarea totalitii de cereri la comportamentul sistemului proiectat. Specificaia de cereri la sistemul proiectat n form de diagram a cazurilor de utilizare reprezint un model independent, care se numete modelul cazurilor de utilizare n limbajul UML i are un nume propriu stanadard sau steriotip UseCaseModel.

4. Diagrama de clase (class diagram)

Locul central n APOO l ocup elaborarea modelului logic al unui sistem n forma diagramei de clase. Notaia claselor n limbajul UML este simpl i clar pentru toi. O notaie asemntoare se utilizeaz i pentru obiecte care sunt exemplare ale clasei, unica diferen este n aceea c la numele clasei se adaug numele obiectului i toat nregistrarea se subliniaz. Notaia limbajului UML ofer multe posibiliti pentru reflectarea informaiei suplimentare (operaii abstracte sau clase, stereotipuri, metode comune i particulare, interfee detaliate, clase parametrizate). Totodat este posibil utilizarea reprezentrii grafice pentru asocieri i proprietile lor specifice, astfel cum sunt relaiile de agregare, cnd ca pri componente ale clasei pot fi alte clase. Diagrama de clase (class diagram) se utilizeaz pentru reprezentarea structurii statice a unui model de sistem n terminologia claselor programrii OO. Diagrama de clase poate reflecta diferite legturi ntre entitile domeniului de obiecte (obiecte i subsisteme) i descrie structura lor intern i tipurile de relaii. n aceast diagram nu este menionat informaia despre aspectele temporare ale funcionrii sistemului. Din acest punct de vedere diagrama de clase este dezvoltarea ulterioar a modelului conceptual al sistemului proiectat.

26

Diagrama de clase reprezint un graf cu noduri elemente de tip clasificatori care sunt legate prin diferite tipuri de relaii de structur. Trebuie de menionat c diagrama de clase poate conine interfee, pachete, relaii i chiar exemplare, aa ca obiecte i legturi. Prin diagrama de clase se subnelege modelul structural static al sistemului proiectat, de accea diagrama de clase deseori se socoate o reprezentare grafic a legturilor structurale ale modelului logic al sistemului care sunt independente i invariante n timp.

4.1. Clasa
Clasa (class) n limbajul UML definete totalitatea de obiecte care au aceeai structur, comportament i relaii cu obiectele din alte clase. Grafic o clas se reprezint printr-un dreptunghi care poate fi divizat de linii orizontale n seciuni, fig. 3. Elementul obligtoriu n notaia clasei este numele lui. Pe etapele iniiale ale elaborrii diagramei, clase aparte pot fi notate prin dreptunghiuri simple cu indicaia numelui clasei respective. Pe parcursul elaborrii componentelor diagramei descrierea claselor este completat cu atribute i operaii. Se presupune c varianta final a diagramei conine descrierea complet a claselor care const din cele trei seciuni. Uneori n notaia claselor se utilizeaz a patra seciune suplementar n care se indic informaia semantic de caracter informativ i se indic situaiile excepionale. Dac seciunea atributelor i operaiilor clasei nu este completat, n notaia clasei ea se evidentiaz cu o linie orizontal pentru a deosebi clasa de alte elemente ale limbajului UML. Exemple de notaii grafice ale claselor n diagrama de clase sunt artate n fig. 32. n primul caz pentru clasa Dreptunghi (fig. 32, a) sunt indicate numai atributele clasei punctele pe planul de coordonate care i definesc poziia. Pentru clasa Fereastr (fig. 32, b) sunt indicate numai operaiile, seciunea de atribute este lsat necompletat. Pentru clasa Contul (fig. 32, c) suplementar este indicat seciunea de excepii refuz de la prelucrarea cartelei bancare expirate (nevalabile).
Dreptunghi p1.Pont p2.Pont Fereastra arata() ascunde() Cont verifica() exceptiile cartela bancara nu este valabila a) b) c)

Fig. 32. Exemple de notaii grafice ale claselor n diagrame.

4.1.1. Numele clasei

Numele clasei trebuie s fie unic n cadrul pachetului, care este descris de ctre o totalitate de diagrame de clase. Numele se indic n prima seciune de sus a dreptunghiului. n completare la regula general de denumire a elementelor n limbajul UML numele clasei se scrie n centrul seciunii cu caracter semigros (bold) i trebuie s inceap cu majuscula. Se recomand n calitate de nume a claselor sa fie utilizate substantivele scrise fr spaii. Este necesar de menionat c numele claselor formeaz dicionarul domeniului de obiecte pentru APOO.

27

n prima seciune a notaiei clasei pot fi referine la modelele (abloanele) standarte sau la clasele abstracte de la care este format clasa dat i respectiv de la care clasa motenete proprietile i metodele. n aceast seciune poate fi indicat informaia despre elaboratorul clasei date i starea elaborrii, nc pot fi indicate i alte proprieti comune ale acestei clase care au legtura cu alte clase ale diagramei sau cu elementele standarde ale limbajului UML. Ca exemple de nume ale claselor pot fi aa substantive ca: Angajatul, Compania, Conductorul, Clientul, Vnztorul, Managerul, Oficiu .a. care au legtur cu domeniul de obiecte proiectat i cu destinaia funcional a sistemului proiectat. Clasa poate s nu aib exemplare sau obiecte. n acest caz clasa devine abstract, i pentru notaia denumirii acestei clase se utilizeaz caractere italice. n limbajul UML este adoptat o inelegere (acord) despre ceea c orice text care se refer la elementele abstracte se scrie n italic. Aceast circumstan este un aspect semantic pentru descrierea elementelor respective ale limbajului UML. n unele cazuri este necesar de indicat clar la care pachet se refer clasa. Pentru acest scop se utilizeaz un simbol special de divizare dou puncte duble ::. Sintaxa liniei ce conine numele clasei n acest caz va fi urmatoarea: <Numele_pachetului>::<Numele_clasei>. Cu alte cuvinte nainte de numele clasei trebuie s fie indicat clar numele pachetului la care clasa se refer. De exemplu, dac este specificat pachetul cu numele Banca, atunci clasa Cont n aceast banca poate fi scris n fel urmtor: Banca::Cont.

4.1.2. Atributele clasei

n a doua secie a dreptunghiului de clas se nscriu atributele lui sau prorietile. n limbajul UML standardizarea nscrierii atributelor de clas se supune regulelor sintactice. Fiecrui atribut de clas i corespunde rndul textului, care este format din specificatorul de vizibilitate a atributului, numelui lui, tipul sensului i, posibil sensul final: specificatorul de vizibilitate numele atributului [multiplicitate]: tipul atributului=sensul final {aliniat-proprietate} Specificatorul de vizibilitate poate primi unul dintre cele trei sensuri i concomitent reflect cu ajutorul simbolurilor speciale:

Simbolul + nseamn atributul cu regiunea de vizibilitate de tip public (public). Atributul cu aceast regiune de vizibilitate poate fi accesat sau vzut din alt clas de pachet, n care este stabilit diagrama. Simbolul #. nseamn atributul cu regiunea de vizibilitate de tip protecie (protected). Atributul cu aceast regiune de viyibilitate nu poate fi accesat sau vzut pentru toate clase n afar de subclasele acestui clas. n sfrit, simbolul atributul cu regiunea de vizibilitate tipului privat. (private). Atributul cu aceast regiune de vizibilitate nu poate fi accesat sau vzut pentru toate clasele fr excepie.

Specificatorul de vizibilitate poate fi omis. n acest caz nu este present, pur i simplu nseamn c vederea acestui atribut nu este indicat. Aceast situaie difer de nelegerile de baz n limbile de tradiionale programare, cnd nu este prezent specificatorul de vizibilitate este tratat ca public sau privat.

28

Numele atributului prezint aliniat de text, care este folosit n calitate de identificator a atributului corespunztor i de aceea trebuie s fie unic n clasa corespunztoare. Numele atributului este unic, un element obligator al nsemnrii sintaxice al atributului. Ca exemplu de multiplicitate al atributelor putem vedea urmtoarele variante:

[0..1] nseamn c, multiplicitatea atributului poate primi semnificaia 0 sau 1. n acest caz 0 nseamn c semnificaia pentru acest atribut nu este prezent. [0..*] nseamn c, multiplicitatea atributului poate primi orice semnificaie pozitiv ntreag mai mult sau egal cu 0. Aceast multiplicitate poate fi scris mai scurt n calitate de simbolul - [*]. [1.:*] nseamn c, multiplicitatea atributului poate primi orice semnificaie pozitiv ntreag mai mult sau egal cu 1. [1..5] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, 4, 5. [1..3,5,7] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, 5, 7. [1..3,7.. 10] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, 7, 8, 9, 10. [1..3,7..*] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1, 2, 3, de asemenea orice semnificaie pozitiv ntreag mai mult sau egal cu 7.

Dac multiplicitatea atributului nu este specificat, atunci dup starea iniial voloarea ei este egal cu 1..1, adic exact 1. Tipul atributului prezint o expresie, semantica cruia este definit dup limbajul specificaiei al modelului corespunztor. n notaii UML-ului tipul atributului uneori este specificat n dependen de limbajul de programare, care va fi utilizat pentru realizarea modelului dat. n cazul elementar tipul atributului este specificat n rndul textului, care are un sens n limita pachetului sau modelului, la care are atitudinea clasa dat. Sublinierea rndului atributului nseamn c acest atribut corespunztor poate avea o submulime de valori din oarecare domeniu al valorilor atributului, definit de tipul lui. Aceste valori pot fi considerate ca trus de notie cu acelai tip sau ca masiv, care n ansamblu caracterizeaz fiecare obiect al clasei. De exemplu, dac oarecare atribut este dat n form de forma: Dreptunghi, aceasta va semna c toate obiectele clasei date poate avea cteva forme diferite, dintre care fiecare prezint un dreptunghi. Ca alt exemplu poate fi atribut n form de numrul_contului:Integer, ce poate nsemna pentru obiect Colaborator prezena submulimii de conturi, valoarea total crora nu este fixat din timp. Aliniat proprietatea este utilizat pentru indicarea valorilor atributului, care nu poate fi shimbat n program n lucrul cu tipul dat al obiectelor. n paranteze ... anume este indicat valorea fix al atributului propriu pentru toat clas, care trebuie s conin toate exemplarele clasei, care vor fi create, fr excepie. Aceast valoare este considerat ca valoare iniial a atributului, care nu poate fi reiniializat n continuare. Absena aliniatului proprietatea de baz se trateaz n felul urmtor, valoarea atributului corespunztor pot fi shimbat n program. De exemplu, aliniat proprietate n nscrierea atributului salariu:Currency = = {$500} poate fi utilizat pentru indicarea salariului fixat pentru fiecare obiect al clasei Colaborator pentru o funcie definit n oarecare organizaie. Din alt 29

parte, nscrierea atributului dat n form de salariu:Currency = = {$500} nseamn alt ceva, i anume n timpul formrii a unui nou exemplar Colaborator (angajarea la lucru unui nou colaborator) pentru el salariul de $500 este stabilit automat. Totui, pentru careva colaboratori pot fi fcute excepii, cum ar fi n cretere sau descretere, ce ar trebui fi prevzut n program.

4.1.3. Operaiile
n a treia secie a dreptunghiului de clas se nscriu operaii sau metodele clasei. Operaia (operation) prezint un anumit serviciu, care prezint fiecare exemplar al clasei dup anumit cerin. Totalitatea de operaii caracterizeaz un aspect funcional n comportamentul clasei. Notaia operaiei clasei n limbajul UML este la fel standartizat i este subordonat de careva regulli sintactice. n urma acesteia fiecare operaie clasei corespunde un rnd aparte, care este compus din specificator de vizibilitate al operaiei, numele operaiei, expresiei de tipul valoarei returnat de opearaia i posibil, aliniat proprietate operaiei date: <specificator de vizibilitate><numele operaiei>(lista de parametri): <expresie de tipul valoarei returnate>{aliniat - proprietate} Specificator de vizibilitate ca i n cazul atributelor clasei, poate primi unul din trei valori posibile i n mod corespunztor este specificat cu un simbol special. Simbolul + nseamn operaia cu specificator de vizibillitate de tip public(public). Simbolul # nseamn operaia cu specificator de vizibilitate de tip protecie(protected). n sfrit, simbolul este utilizat pentru identificarea operaiei cu regiunea de vizibilitate de tip privat (private). Specificator de vizibilitate pentru operaie poate fi absent. n acest caz absena lui nseamn c vizibilitatea operaiei nu este indicat. n locul nsemnrii grafice convenionale de asemenea poate nscrie un cuvnt cheie corespunztor: public, protected, private. Numele operaiei prezint aliniat de text, care este utilizat ca identificator al operaiei corespunztoare i de aceea trebuie s fie unic n mediul clasei date. Numele atributului este un element unic obligator n indicarea sintactic operaiei. Operaia, care nu poate schimba starea sistemului i n mod corespunztor nu are nici un efect suplimentar, este specificat cu aliniat proprietate {interpelare} ({query}). n caz contrar operaia poate schimba starea sistemului, dei nu sunt garanii c ea va face acest lucru. Lista parametrilor formate i tipul de valoare redus pot fi nespecificate. Specificator de vizibilitate atributelor i operaiilor pot fi indicate de un semn sau simbol special, care sunt utilizate pentru prezena modelelor grafice n careva mijloace de instrumente. Numele operaiilor la fel ca i a atributelor, sunt scrise cu minuscule, iar tipurile lor cu majuscule. n urma cruia o parte obligatorie al aliniatului de text al operaiei este prezena numelelui i parantezelor rotunde. Ca exemplu al nscrierei operaiei pot fi urmtorii specificatori al operaiilor:

+a crea() pot indica o operaie abstract n fondarea obiectului separat, care este public i nu conine parametri formali. Aceast operaie nu reduce nici o valoare dup executarea sa. +a desena(forma: multilateral=dreptunghi, culoarea_inundrii: Color =(0,0,255)) pot indica o operaiune de nfiare pe ecranul monitorului regiunii dreptunghiului cu culoare albastr, dac nu indic alte valori n calitate de argumente operaiei date. cererea_contulului_clientului(numrul_contului: Integer): Currency nseamn, operaiunea de indicare n contul curent a clientului bncii. n urma cruia argumentul operaiei date este 30

numrul contului clientului, care este scris ca numr ntreg (de exemplu: 123456). Ca rezultat al executrii operaiei date va fi un numr ntreg scris n formatul monetar(de exemplu: $1,500.00). a da_mesajul():{Eroare mpririi la nul} sensul operaiei acestea nu este nevoie de a explica, deoarece este ntreinut n aliniat proprietatea operaiei. Mesajul dat poate aprea pe ecranul monitorului n cazul cnd desprim un numr la nul, ce este inadmisibil.

4.2. Relaii ntre clase

n afar de organizarea intern sau structur claselor n diagrama corespunztoare sunt indicate diferite relaii ntre clase. n urma cruia totalitatea tipurilor astfel de relaii este fixat n limbajul UML i este presupus de semantica astfel tipurilor de relaii. n limbajul UML relaiile de baz i legturile sunt:

Relaia de dependena (dependency relationship) Relaia de asociere (association relationship) Relaia de generalizare(generalization relationship) Relaia de realizare(realization relationship)

Fiecare din relaiile aceste are reprezentare grafic proprie pe diagram, care reflect interconexiunele ntre obiectele claselor corespunztoare.

4.2.1. Relaia de dependena

Relaia de dependen n caz general indic o relaie semantic ntre dou elementele modele sau ntre dou mulimi de aceste elemente, care nu este o relaie de asociere, generalizare sau realizare. Ea se refer numai la elementele modele i nu cere o mulime de exemple pentru explicarea sensului su. Relaia de dependen se folosete n situaia n care o schimbarea unui element al modelului poate cere dup sine o schimbare n elementul dependent de elementul precedent al modelului. Grafic relaie de dependen se prezint grafic, printr-o linie punctat ntre elementele cu sgeat n captul entitii dependente(-> sau <-). n diagrama de clase aceast relaie unete clase separate ntre sine, n urma cruia sgeat este ndreptat de la clasa client, dependent de clasa independent sau clasa iniial (fig. 33). Pe desenul urmtor sunt prezentate dou clase: Clasa_A i Clasa_B, n urma cruia Clasa_B reprezint sursa unei relaii, iar Clasa_A este clientul acestei dependene.
Clasa_A Clasa_B

Fig.33. Reprezentarea grafic relaiei de dependena n diagrama de clase. Sgeata poate fi indicat sau nu poate fi indicat cu cuvntul-cheie standart n ghelimele i nu este necesar nume individual. Pentru relaia de dependen exist cuvintele cheie, care indic careva feluri de relaii speciale. Aceste cuvintele cheie (stereotipuri) sunt scrise n ghelimele alturi de sgeat, care corespunde relaiei date. Exemple de stereotipuri pentru relaie de dependen sunt urmtoarele:

access servete ca indicator de accesibilitate unor atribute i operaii clasei surs pentru claseclienii; bind clasaclient pote utiliza careva ablon pentru urmtoarea parametrizare; 31

derive atributul clasei client poate fi calculat dup atributele clasei surs; import atribute deschise i operaii publice clasei surs devine o parte a clasei client, care dac ar fi nemijlocit n el; refine indic c clasa client servete ca precizie a clasei surs n cauza caracterului istoric, cnd n timpul lucrului la un proiect apare informaia adugtoare.

4.2.2. Relaia de asociere

Relaia de asociere corespunde prezenei unei relaii ntre clase. Relaia dat se reprezint printr-o linie cu simboluri speciale adugtoare, care caracterizeaz unele proprieti a asocierii concrete. n calitate de simboluri adugtoare speciale poate fi folosit numele asocierii, dar i numele i multiplicitatea claselor rolurilor asocierii. Numele asocierei nu este un element obligatoriu pentru indicarea ei. Dac numele este indicat, atunci este scris cu litera majuscul alturi de linia asocierii corespunztoare. Cel mai simplu caz asocierii asociaia binar. Ea conecteaz exact dou clase, dar ca excepie poate conecta clasa cu sine. n diagrama pentru asociaia binar poate fi indicat ordinea consecinei claselor cu ajutorul triunghiului n form de sgeat alturi de numele asocierii date. Direcia acestei sgei indic ordinea claselor, unul dintre care este primul (din partea treunghiului), iar al doilea (din partea vrfului treunghiului). Absena acestei sgeei alturi de numele asocierii nseamn c ordinea consecinei a claselor n aceast relaie nu este indicat. Cel mai simplu exemplu a relaiei asociaiei binare poate fi relaia ntre dou clase clasa Companie i clasa Colaborator (fig. 34). Ele sunt legate ntre ele cu asociaia binar Lucru, numele cruia este indicat pe desen alturi de linia asocierii. Pentru relaia dat este indicat ordinea consecinei a claselor, prima este clasa Colaborator, iar al doilea clasa Companie.

Fig. 34. Reprezentarea gafic a relaiei asocierii binare ntre clase. Unul dintre simboluri adugtoare este numele rolului a clasei aparte, care ntr n asociere. Numele rolului reprezint aliniat de text alturi de captul asocierii pentru clasa respectiv. Ea indic un rol specific, care joac clasa, ce reprezint captul asociaiei. Numele rolului nu este un element obligatoriu i poate lipsi n diagram. Urmtorul element de indicare este multiplicitatea claselor, care sunt capetele asociaiei. Multiplicitatea unei clase reprezint un interval de numere intregi, analogic cu multiplicitatea atributelor i operaiilor claselor. Forma special sau caz particular a relaiei de asociere este relaia de agregare, care n rndul su are o form special relaie de compoziie. ntruct relaiile acestea au notaii speciale i aparin noiunelor de baz a limbajului UML, vor fi examinate consecutiv.

32

4.2.3. Relaia de agregare

Relaia de agregare exist ntre cteva clase n cazul cnd o clas reprezint o careva entitate care include n sine n calitate de pri componente alte entiti. Aceast relaie are un sens fundamental n descrierea structurei sistemelor compuse, deoarece este utilizat pentru reprezentarea interaciunelor sistematice de tipul parte-intreg. Dezvluind structura sistemei interne, relaia de agregare ne arat din care componente este compus sistema i cum este legat ntre ele. Din punct de vedere a modelului prile sistemului pot fi reprezentate n calitate de elemente dar i n calitate de subsistem. Aceast relaie descrie decompoziia sau mprirea unui sistem compus la un sistem de structurp mai simpl, care de asemenea pot fi decompuse dac aceast lucru va fi necesar n viitor. Ca exemplu de relaie de agregare vom lua interaciunea de tipul parte-ntreg, care este ntre entitate Calculator i componente Bloc de sistem, Monitor, Tastatura, Mouse. Reprezentarea grafic a relaiei de agregare este artat cu linia ntreag, unul din capetele cruia reprezint un romb nehaurat. Acest romb indic acea clas, care reprezint un ntreg. Alte clase prezint prile lui (fig. 35).
Calculator

Bloc de sistem

Monitor

Tastatura

Mouse

Fig. 35. Reprezentarea grafic a relaiei de agregare pentru PC n diagrama claselor.

4.2.4. Relaia de compoziie

Relaie de compoziie este un caz particular al relaiei de agregare. Aceast relaie se folosete pentru o form special de relaii parte-ntreg, n care componentele aparin unui ntreg (compozit). Specificarea interaciunii ntre ele const: prile nu pot exista independent, adic cu destrugerea compozitului se vor distruge toate prile lui componente. Relaia grafic de compoziie este reprezentat ca o linie ntreag, una din capetele cruia reprezint un romb haurat nauntru.Acest romb indic acea clas, care reprezint clasa compoziie sau ntregul. Alte clase sunt prile lui. n calitate de notaii adugtoare pentru relaii de compoziie i de agregare pot fi folosite notaii adugtoare folosite pentru relaia de asociere. i anume, specificarea divizibilitii clasei de asociere i numele asocierii date, care nu este obligatoriu. Ca exemplu de descriere vom lua clasa Fereastra programului i diagrama claselor va fi urmtoare (fig. 36).

Fig. 36. Reprezentarea grafic a relaiei de compoziie pentru Fereastra programului n diagrama claselor. 33

Acest exemplu poate ilustra i alte proprietile programei computerizate, care nu a fost specificat pentru acest exemplu. Deci, specificarea divizibitii 1 lng clasa Regiunea de lucru este utilizat n anexe unidocumentate (aplicaii).

4.2.5. Relaie de generalizare

Relaia de generalizare este o relaie taxonometric ntre dou elemente de acelai tip: elementul generalizat (printe) i elementul specializat (descendent). Aceast relaie poate fi utilizat pentru reprezentarea interaciunilor ntre pachete, clase, cazurile de utilizare i alte elemente ale limbajului UML. n diagrama de clase relaia dat descrie structura ierarhic a claselor i motenirea proprietilor i comportamentului lor. n urma cruia clasa-descendent motenete proprietile i comportamentul clasei-printe, dar are proprietile i comportamentul su propriu, care nu are clasa-printe. n diagrame relaiile de generalizare sunt reprezentate ca o linie ntreag cu sgeat n form de triunghi la unul din capete. Sgeata arat clasa generalizat (clasa-printe sau superclas), iar absena ei indic clasa special (clasa-descendent sau subclasa). Pentru simplificarea notaiei n diagrama claselor totalitatea de linii ce indic aceeai relaie de generalizare, poate fi unit ntr-o linie. n acest caz liniile sunt adunate la o singur sgeat i au un punct comun de intersecie (fig. 37).

Fig. 37. Variantul grafic a relaiei de generalizare n cazul unirii liniilor aparte. Lng sgeat de generalizare poate fi amplasat aliniat de text, care specific care-va proprieti adugtoare a acestei relaii. Textul dat va fi referitor la toate linile de generalizare, care trec n clase descendente. Cu alte cuvinte, proprietatea marcat se refer la toate subclase relaiei date. n urma cruia textul trebuie s fie examinat ca restricie i atunci el va fi scris n paranteze. Ca restricie pot fi folosite urmtoarele cuvintecheie din limbajul UML:

{complete} nseamn c n aceast relaie de generalizare sunt specificate toate clasele descendente i alte clase descendente nu pot exista n clasa dat. De exemplu, clasa Clientul_bncii este clasa printe pentru dou clase: Persoana_fizic i Companie i alte clase descendente el nu are. n diagrama acestei clase poate fi indicat evident cu ajutorul scrierii liniei de generalizare cu aceast aliniat limit; {disjoint} nseamn c clasele descendente nu pot conine obiecte, care concomitent sunt exemplare a dou sau mai multor clase. n exemplu precedent acest condiie se ndeplinete, deoarece este presupus c nici o persoan fizic nu poate fi concomitent i companie concret. n cazul acesta alturi de linie de generalizare poate fi scris aliniat limit dat; {incomplete} este cazul contrar a primului caz. Anume, presupune c n diagrama nu sunt indicate toate clase descendente. n continuare poate fi restabilit lista lor fr schimbarea n diagrama construit. Exemplu: diagrama de clas Automobil, pentru care indicarea 34

tuturor modelelor de automobile este echivant cu formarea catalogului respectiv. Din alt parte, pentru o alt problem ca elaborarea sistemului de vindere automobilelor de modele concrete nu este necesitate. Iar indicarea structurii incomplete a claselor descendente este necesar; {overlapping} nseamn c care-va exemplare a claselor descendente pot aparine mai multor clase. Exemplu: clasa Multilateral este clasa printe pentru clasa Dreptunghi i clasa Rombul. Totui exist clasa Ptrat, exemplarele cruia concomitent sunt obiectele a primelor dou clase. Este clar c aceast situaie trebuie s fie marcat cu aliniat limit.

4.3. Interfee
Interfeele sunt exemplarele diagramelor cazurilor de utilizare. Totui n construirea diagramei de clas care-va interfee pot fi precizate i n cazul dat pentru reprezentarea lor este folosit un simbol grafic special dreptunghi de clas cu cuvntul-cheie i stereotip interfaa (fig. 38). n urma cruia secia de atribute a dreptunghiului lipsete, iar este indicat numai secia de operaii.
"interface" Element_termomentric valoarea_temperaturii()

Fig.38. Exemplu de reprezentarea grafic a interfeei n diagrama de clase.

4.4. Obiecte
Obiect (object) este un exemplar special al clasei, care este creat n timpul executrii programului. El are un propriu nume i valoare concret atributelor. n urma care-va motivelor poate aprea necesitatea de reprezentare a interconexiunelor nu numai ntre clasele modelului, dar i ntre obiecte aparte, care realizeaz clase date. n acest caz poate fi elaborat diagrama de obiecte, care nu este canonic n metamodelul limbajului UML, dar are destinaie proprie. Pentru reprezentarea grafic a obiectelor este utilizat acelai simbol a dreptunghiului ca i pentru clase. Diferena este n indicarea numelelor obiectelor, care n cazul de obiecte este obligatoriu subliniat (fig. 39). n urma cruia notarea numelelui obiectului reprezint aliniat de text numele obiectului: numele clasei, separat cu dou puncte (fig. 39 a, b). Numele obiectului poate lipsi, n acest caz presupunem c obiectul este anonim i dou puncte indic acest lucru (fig. 39 d). Numele clasei poate lipsi. Atunci este indicat numele obiectului (fig. 39 c). Atributele obiectelor primesc valorile concrete.

Fig. 39. Exemplu de reprezentare grafic a obiectelor n diagramele limbajului UML.

35

5. Diagrama de stri (statechart diagram)

Pentru modelarea comporatamentului la nivelul logic n limbajul UML pot fi utilizate la rnd cteva diagrame canonice: de stri, de activitate, de secven i de cooperare, fiecare din care pune accentul la aspectul specificat de funcionare a sistemului. Spre deosebire de alte diagrame, diagrama de stri descrie procesul de modificare a strilor numai pentru o clas, pentru un exemplar a unei clase, adic de a modela toate modificrile posibile n starea unui propriu obiect. n urma cruia modificarea strii obiectului poate fi provocat de influena extern a altor obiecte sau din exterior. Anume pentru descrierea reaciei obiectelor la aa fel de influene externe sunt utilizate diagramele de stri. Aceast diagram este folosit pentru descrierea consecutivitilor de stri posibile i trecerilor, care n ansamblu caracterizeaz comportamentul elementelor modelului n timpul ciclului de via. Diagrama de stri reprezint comportamentul dinamic a entitilor n baza specificaiei reaciei lor la perceperea cror-va evenimente concrete. Dei diagramele de stri sunt mai rar utilizate pentru descrierea comporatamenrului de care-va exemplare a claselor (obiectelor), dar ele de asemenea pot fi utilizate i pentru specificarea funcionalitilor altor componente a modelului, aa cum cazurile de utilizare, actorii, subsisteme, operaii i metode. Diagrama de stri n realitate este un graf de nfiare special, care reprezint un automat. Definiia de automat n contextul UML are o semantic prea specific, bazat pe teoria automatelor. Vrfurile acestui graf sunt strile i alte elemente a automatului (pseudostri), care sunt reprezentate cu ajutorul simbolilor grafice speciale. Razele grafului sunt pentru marcarea trecerilor de la o stare la alt. Diagramele de stri pot fi depuse una n alta, formnd diagramele depuse de reprezentarea mai detaliat a cror-va elemente a modelului. Pentru nelegerea semanticii diagramei de stri concrete este necesar de a imagina nu numai deosebirile n comportamentul entitii modelate, dar i de a ti noiuni generale din teoria automatelor.

5.1. Automate
Un automat (state machine) n limbajul UML reprezint o formalizare pentru modelarea comportamentului elementelor modelului i a sistemului ntreg. n metamodelul UML automatul este un pachet, n care sunt definite o mulime de definiii, necesare pentru reprezentarea comportamentului entitii modelate n form de spaiu discret cu un numr finit de stri i treceri. Din alt parte, automatul descrie comportamentul obiectului n forma consecutivitilor de stri, care conine toate etapele ciclului de via, ncepnd cu formarea obiectului i sfrind cu destrugerea lui. Fiecare diagrama de stri reprezint un automat. Ca un simplu exemplu de reprezentare vizual de stri i treceri pe baz de formalizmul automatului poate servi situaia descris de mai sus cu funcionizarea echipamentului tehnic ca calculator. n acest caz sunt introduse dou stri: funcioneaz i nu funcioneaz i dou treceri: defect i reparare. n mod grafic aceast informaie poate fi reprezentat n form de urmtoarea diagram de stri pentru un calculator (fig. 40).

Fig. 40. Un simplu exemplu de diagram de stri pentru echipamentul tehnic de tip calculator. 36

Noiunile de baz care intr n formalizmul automatului sunt starea i trecerea. Diferena principal ntre ele este durata aflrii sistemului n stare aparte, care depete mult timpul, care este utilizat pentru trecerea de la o stare la alt. Presupune c iniial timpul de trecere de la o stare la alta este egal cu zero (dac nu exist informaie suplimentar). Cu alte cuvinte, trecerea obiectului de la o stare la alt este momental. n cazul general automatul reprezint aspecte dinamice a sitemului modelat n forma de graf orientat, vrfurile crui corespunde cu strile, iar arcurile cu trecerile. n urma cruia comportamentul modeleaz ca deplasare consecutiv n graful de stri de la vrf la vrf dup arcurile legate innd cont de orientaia lor.

5.2. Stare
n limbajul UML starea este subneles ca metaclas abstract, ce se utilizeaz pentru modelarea situaiei aparte, pe parcursul crei este prezent executarea anumitei condiii. Starea (state) poate fi n form de valori concrete a atributului clasei sau obiectului, n acest caz modificarea anumitelor valorilor va respinge modificarea clasei modelate sau obiectului. Trebuie de meninut c nu fiecare atribut al clasei poate caracteriza starea lui. Ca regul, sunt valoroase numai acele proprieti a elementelor sistemului, care respinge aspectul dinamic i funcional a comportamentului lui. n acest caz starea va fi caracterizat ca o condiie invariat, care include n sine numai cele mai semnificative clase a atributului pentru comportarea i semnificarea lor. De exemplu, invariant poate reprezenta o situaie static, cnd obiectul este n stare de ateptare a aprrii care-va eveniment extern. Din alt parte, invariantul este utilizat pentru modelarea aspectelor dinamice, cnd n timpul procesului sunt executate anumite aciuni. Atunci n cazul dat elementul modelat trece n starea dat n momentul iniial al activitii respective i iese din starea dat n momentul finalizrii ei.

Fig. 41. Reprezentarea grafic strilor n diagrama de stri. Starea pe diagram este reprezentat ca dreptunghi cu vrfurile rotungite (fig.41). Acest dreptunghi, la rndul su, poate fi desprit n dou seciuni cu ajutorul liniei orizontale. Dac este indicat numai o seciune, atunci n ea este scris numai numele strii (fig. 41, a). n caz contrar n prima din ele este scris numele strii, iar n a doilea lista cror-va aciuni interne sau treceri n starea dat (fig. 41, b). n urma cruia dup aciunea limbajului UML se subnelege o anumit operaie atomic, executarea creia duce la schimbarea strii sau red o anumit valoare (exemplu, adevr sau fals).

37

5.2.1. Numele strii

Numele strii reprezint aliniat de text, care dezvluie sensul strii date. Numele este ntodeauna scris cu litera majuscul. Deoarece starea sistemului este partea compus a procesului de funcionare, este recomandat de folosit n calitate de nume verbele n timpul prezent (sun, tiprete, ateapt) sau participiu corespunztor (ocupat, liber). Numele strii poate lipsi, adic el nu este obligatoriu pentru anumite stri. n acest caz starea este anonim i dac n diagrama de stri sunt cteva din ele, atunci ele toate trebuie s fie diferite ntre ele.

5.2.2. Starea iniial

Starea iniial reprezint un caz particular de stare, care nu conine nici o aciune intern (pseudostare). n acest caz exist iniial un obiect n starea iniial a timpului. Ea este utilizat pentru indicarea pe diagrama de stri a spaiului grafic, de la care ncepe procesul de modificare a strilor. Grafic starea iniial n limbajul UML este reprezentat n form de cerc haurat (fig. 42, a), de la care poate iei numai sgeata corespunztoare cu trecere.

Fig. 42. Reprezentarea grafic a strii iniiale i finale n diagrama de stri. La cel mai nalt nivel de reprezentare a obiectului trecerea de la starea iniial la starea final poate fi marcat ca aciunea de creare (iniializare) a obiectului dat. n cazul contrar tranziia nu esre marcat deloc. Dac acest tranziie nu este marcata, atunci ea este prima trecere n starea urmtoare.

5.2.3. Starea final

Starea final reprezint un caz particular al strii, care nu conine nici o aciune intern (pseudostare). n aceast stare obiectul se v-a afla n starea iniial dup finisarea lucrului automatului n ultimul moment de timp. El este utilizat pentru indicarea spaiului grafic pe diagrama de stri, unde se sfrete procesul de schimbare a strii sau ciclului de via a obiectului dat. Grafic starea final n limbajul UML este reprezentat n form de cerc haurat deplasat n circumferin (fig. 42, b), n care poate intra numai sgeata corespunztoare cu trecerea.

5.3. Tranziie
O simpl tranziie reprezint o relaie ntre dou stri consecutive indicnd faptul schimbrii a unei stri cu alt. Prezena obiectului modelat n prima stare va efectua anumite aciuni, dar trecerea n starea a doua va fi atunci cnd anumite aciuni vor fi terminate i dup ndeplinirea anumitor condiii adugtoare. Tranziia ncepe cnd un anumit eveniment se petrece: terminarea executrii aciunii (do activity), trimiterea mesajului sau emiterea semnalului. n trecere se indic numele aciunii. Mai mult, n tranziie poate fi indicat aciunea produs de un obiect ca reacia tranziiei de la o stare la alta. Executarea tranziiei poate depinde nu numai de petrecerea unui anumit eveniment, dar i de la ndeplinirea condiiei corespunztoare, care se numete condiie gard. Obiectul va trece de la o stare la alta, numai n caz dac a fost aciunea indicat i condiia de gard este adevrat.

38

n diagrama de stri tranziia este reprezentat ca linie ntreag cu sgeat, care este ndreptat n starea de int (exemplu, defect n fig. 40). Fiecare tranziie poate fi marcat cu aliniat de text, care are urmtorul format general: <signatura evenimentului>'['<condiia de paz>']' <exprimarea aciunii>. Signatura aciunii descrie un anumit eveniment cu argumentele necesare: <numele evenimentului>'('<lista parametrilor mprite cu virgule>')'.

5.3.1. Eveniment
Termenul eveniment (event) trebuie explicat aparte, deoarece el este un element independent al limbajului UML. Opional evenimentul reprezint specificaia anumitui fapt, care are ataat o locaie n timp i n spaiu. Despre fapte se spune c ele se petrec, n acelai timp evenimente aparte trebuie s fie aranjate n timp. Dup sosirea evenimentului este imposibil de a ne ntoarce la evenimentul precedent, dac aceast posibilitate nu este prevzut n model. n limbajul UML evenimentele joac rol de stimule, care iniializeaz treceri de la o stare la alta. n calitate de evenimente destingem semnale, apeluri, terminarea intervalurilor fixate de timp sau momentele de finisare a executrii anumitor aciuni. Numele evenimentului identific fiecare tranziie aparte n diagrama de stri i pot conine aliniat de text, care ncepe cu minuscul. n acest caz tranziia va fi triger, adic care specific un eveniment triger. De exemplu, tranziii n fig. 40 sunt trigere, deoarece cu fiecare din ei sunt legate care-va eveniment triger, care petrece asincron n momentul ieirii din funciune a echipamentului tehnic sau n timpul terminrii reparaiei lui. Dac alturi de sgeata trecerii nu este indicat nici un aliniat de text, atunci trecerea corespunztoare este netriger i n acest caz din contextul diagramei de stri trebuei s fie clar dup care terminare a aciunii el ncepe a funciona. Dup numele evenimentului pot urma paranteze rotungite pentru parametrii evenimentului triger. Dac nu exist aa parametri, atunci lista parametrilor cu paranteze pot lipsi.

5.3.2. Condiie gard

Condiia gard (guard condition), dac exist, atunci ntodeauna este scris n paranteze dreptungiulare dup evenimentul triger i reprezint expresie bulean. ntroducerea condiiei gard pentru tranziie permite specificarea semanticii lui de executare. Dac condiia gard primete valoarea adevrat, atunci tranziia respectiv poate executa, i ca rezultat obiectul va trece la starea obiectiv pe aceast tranziie. n cazul general de la o stare pot exista cteva tranziii cu tot acealai eveniment triger. Nici o condiie gard nu trebuei s conin concomitent valoarea adevr. Fiecare din condiii gard este necesar de calculat fiecare dat cnd sosete triger eveniment respectiv. Grafic fragmentul de modelare de logic programului potal poate fi reprezentat n forma de urmtoarea diagram de stri (fig. 43). Dup necesitatea emiterii potei, utilizatorul trebuie s stabileasc conectarea telefonului cu provaiderul, ce este indicat n diagrama cu trecerea de sus. Cu alte cuvinte, utilizatorul iniializeaz evenimentul triger de a stabili conectarea telefonului. Ca parametru al acestui eveniment trece un numr de telefon concret a provaiderului. Apoi urmeaz verificarea condiiei gard conectarea este stabilit, care se subnelege ca ntrebare. Numai n cazul rspunsului da, adic adevr, se ntmpl trecerea programului potal de la starea activarea programului potal n starea ncrcarea potei de la servelul provaiderului. n caz 39

contrar (linie ocupat, parol incorect) nici o ncrcare a potei nu va fi i programul va lsa n fosta stare.

Fig.43. Diagrama de stri pentru modelarea programului client potal. A doua trecere de triger pe diagram iniializeaz ntreruperea automat a conectrii telefonice cu provaiderul dup terminarea ncrcrii potei n calculatorul utilizatorului. n acest cazul eveniment-triger de a finisa ncrcarea potei se petrece dup verificarea condiiei gard pota electronic pe server este deeart, care tot trebuie sa fie subneles n form de ntrebare. Dac rspunsul este pozitiv (toat pota este ncrcat sau ea nu este n pota electronic) programul potal ntrerupe ncrcarea potei i trece n starea de activaie. Dar n cazul rspunsului negativ ncrcarea potei va continua.

5.3.3. Expresia aciunei

Expresia aciunii (action expression) se execut atunci i numai atunci cnd se execut tranziia. Reprezint operaia atomic, care se execut dup efectuarea tranziiei respective nainte de oricare aciune n starea obiectiv. Activitatea atomic nseamn c ea nu poate fi ntrerupt de nici o alt activitate pn cnd nu termin executarea lui. Aceast aciune poate influena ca la obiectul, dar i la mijlocul lui, dac aceast este evident din contextul modelului. Expresia se scrie dup semnul / n linia textului conectat cu tranziia respectiv. n cazul general, expresia aciunii poate conine o list ntreag de activiti particulare, separate cu simbolul ;. Condiie obligatorie toate aciune din list trebuie s fie difer ntre ele i s urmeze n ordinea scrierii lor. Sintaxa notaiei expresiei de aciune nu are care-va limite. Cel mai principal notarea lor trebuie s fie clar pentru elaboratorii modelului i programitilor. De aceea expresiile sunt scrise mai rar n unul din limbajele de programare, care este presupus de utilizare pentru realizarea modelului. Ca exemplu de expresie a aciunii (fig. 43) poate servi de a ntrerupe conectarea (numrul telefonului), care trebuie efectuat exact dup stabilirea adevrului (adevrul) condiiei gard pota electronic pe server este deeart. Ca un alt exemplu poate fi situaia evident cu alocarea obiectelor grafice pe ecranul monitorului prin apsarea butonului stng a mouse-ului. n acest caz tranziia respectiv poate avea urmtorul aliniat de text: este apsat i eliberat butonul stng a mouse-ului (coordonate) [coordonate n regiunea obiectului grafic] / de alocat obiectului (culoarea). Rezultatul trecerii acestui triger poate fi de exemplu activizarea anumitor proprieti a obiectului (dimensiunea failului n linia de stare) sau extragerea.

40

5.4. Stare i substare compus

Stare compus (composite state) este o stare compus, care este alctuit din alte stri depuse. Ultimile vor fi substrile (substate) pentru primul element. Dei ntre ele exist relaia de compoziie, grafic toate vrfurile diagramei, care corespund substrilor depuse, sunt reprezentate nuntrul simbolului strii compuse (fig. 44). n acest caz dimensiunele simbolului grafic a strii compuse se mrete n aa fel ca toate substrile vor fi incluse.

Fig. 44. Reprezentarea grafic a strii compuse. Starea compus poate conine dou sau mai multe subautomate paralele sau cte-va substri consecutive. Fiecare substare compus poate fi precizat numai ntr-un singur mod, artat mai sus. n urma cruia oricare din substri la rndul su pot fi stare compus i conine nuntru alte substri depuse. Cantitatea nivelelor depuse a strilor compuse nu sunt fixate n limbajul UML.

5.4.1. Substri disjuncte

Substri disjuncte (sequential substates) sunt utilizate pentru modelarea aa fel de comportament a obiectului, n timpul cruia n fiecare moment de timp obiectul poate fi numai ntr-o substare. Comportamentul obiectului n acest caz reprezint schimbarea disjunct a substrilor, ncepnd cu starea iniial i sfrind cu substarea final. Dei obiectul continu de a fi n starea compus, ntroducerea n examinarea substrilor disjuncte d posibilitatea de a enumera mai fin aspectele logice a comporatamentului lui intern. Ca exemplu lum n consideraie n calitate de obiectul modelat un telefon obinuit. El poate fi n diferite stri, una din care este starea conectrii cu abonatul. Evident, c pentru conectare este necesar de redicat receptorul, s ascult tonul semnalului, dup care formm numrul de telefon respectiv. n aa fel, starea de conectare cu abonatul este stare compus i const din dou substri disjuncte: ridicarea receptorului i formarea numrului de telefon. Fragmentul de diagram de stri pentru acest exemplu conine o stare compus i dou substri disjuncte (fig. 45).

Fig. 45. Exemplu de stare compus cu dou substri disjuncte depuse. 41

Oarecare lmuriri pot necesita tranziii. Dou din ele specific eveniment triger formarea numrului, care are numele de cifra cu parametru n. Ca exemplu parametrului menifest o cifr n discul telefonului. Tranziia din substarea iniial este netriger, deoarece ea nu conine nici un aliniat de text. Ultima tranziie n substarea final nu are eveniment-triger, dar are condiie gard, care verific corectitudinea formrii numrului abonatului. Numai n cazul cnd aceast condiie este adevrat aparatul de telefon poate duce n substarea final, care caracterizeaz superstarea conectarea cu abonatul n ntregime. Starea compus poate conine ca depozit substarea iniial i final. n urma creia substarea iniial este punct de plecare, cnd se ntmpl tranziia obiectului n starea compus. Dac starea compus conine nuntru substarea final, atunci tranziia n aceast stare final depus nseamn finisarea considerrii obiectului n starea depus. Este imporatant ca pentru substri disjuncte starea iniial i final trebuie s fie unic n fiecare stare depus.

5.4.2. Substri concurente

Substri concurente (concurrent substates) pot specifica dou sau mai multe subautomate, care pot executa paralel nuntrul strii compuse. Fiecare din subautomate ocup un anumit region nuntrul strii compuse, care este desprit de la altele cu linia orizontal punctat. Dac n diagrama de stri exist starea compus cu substrile paralele depuse, atunci obiectul poate fi concomitent n fiecare din aceste substri. Totui substrile paralele pot fi compuse din cte-va substri concomitente (subautomatele 1 i 2 n fig. 46). n acest caz dup definiia obiectul poate s se afle numai n una din substrile disjuncte automatului. Aadar, pentru un exemplu abstract (fig. 46) permitem prezena concomitent a obiectului n substrile (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Inadmisibil este prezena concomitent a obiectului n substrile (1,2,3) sau (3, 4, 5).

Fig.46. Reprezentarea grafic a strii compuse su substrile concurente depuse. Pentru ca fiecare region a strii depuse specific un anumit subautomat, atunci pentru fiecare din subautomate depuse pot fi definite substarea iniial i final (fig. 46). n timpul tranziiei n starea depus dat fiecare din subautomate devine n substarea sa iniial. Mai departe se ntmpl executarea concurent a fiecrui din subautomatele date, iar ieirea din starea depus va fiposibil numai n cazul cnd toate automatele vor fi n strile sale finale. Dac unul din subautomate a venit n starea sa final mai degrab dect altele, atunci el trebuie s ateapte pn cnd alte subautomate vor veni n strile sale finale. 42

Exemplu a diagramei de stri, care reprezint modelarea comportamentului obiectului concret este procesul funcionrii aparatului de telefon (fig. 47). Aceast diagram de stri reprezint un automat cu o stare depus. Din exteriorul strii depuse exist numai o stare ateptare, care caracterizeaz aparatul de telefon funcionat i conectat. Tranziia n starea urmtoare se ntmpl dup riricarea receptorului. Tranziia cu aciunea atomic emiterea semnalului de ton transfer aparatul n starea compus, adic n substarea lui iniial.

Fig. 47. Diagrama de stri a procesului de funcionare a aparatului de telefon. Apoi aparatul de telefon va fi n starea semnalul de ton. n urma cruia el va scoate acest semnal pn cnd nu v-a avea loc evenimentul-triger formarea cifrei(n), sau nu trec 15 secunde de la momentul ridicrii receptorului. n primul caz aparatul va trece n starea formarea numrului, dar n starea doua sfrirea timpului de ateptare. Ultima situaie poate fi ca rezultat a ndoielii s sun sau s nu sun!? n urma cruia auzim bipuri n receptor, n urma cruia noi nu avem ce s facem, n afar de a pune receptorul. n timpul formrii numrului se execut evenimentul-triger formarea cifrei (n) cu condiia gard numrul incomplet. Aceast luru nseamn c numrul format nu conine numrul necesar de cifre, atunci este nevoie de a continua formarea cifrei urmtoare, rmnnd n starea formarea numrului. Dac numrul format este incomplet, atunci putem duce n starea numrul greit sau conectarea. n cazul numrului greit (condiia gard greit este adevr) nu avem alt alternativ dect s ieim din starea compus cu punerea receptorului. Dar dac numrul este corect, atunci are loc conectarea pe acest numr. Totui n rezultatul conectrii poate s se ntmple ca aparatul abonatului este ocupat (trecerea n starea ocupat) sau liber (trecerea n starea sunetul la abonat). n primul caz sunetul poate fi 43

repetat, dup punerea receptorului (ieirea din starea compus). n al doilea caz se ntmpl controlarea condiiei gard convorbirea este accesibil. Dac ea este adevrat, ceea ce corespunde cu ridicarea receptorului cu abonatul, ncepe convorbirea telefonic. n caz contrar (aceast condiie nu se execut, adic este fals) telefonul abonatului va continua s sune, ceea ce ne spune c ori abonatul nu este, sau din care-va alt motiv nu putem continua cinvorbirea la telefon. n urma cruia noi nu avem alt soluie dect s punem receptorul. Dac convorbirea a avut loc, atunci dup cuvinte de adio i executarea condiiei de gard confirmarea la terminarea convorbirii noi iari punem receptorul la loc. n urma cruia aparatul de telefon trece n starea ateptarea, n care poate s se afle un timp nelimitat.

6. Diagrama de activiti (activity diagram)

Pentru modelarea procesului de executare a operaiilor n limbajul UML se utilizeaz aa numitele diagrame de activiti. Notaia grafica acceptat pentru aceste diagrame are mult comun cu notaia diagramei de stri ce se evideniaz prin notarea strilor i tranziiilor. Deosebirea const n semantica strilor care sunt utilizate pentru prezentarea aciunilor dar nu activitilor, i n aceea c tranziiile evenimentelor nu sunt etichetate. Fiecare stare n diagrama de activiti corespunde executrii unei operaiuni elimentare, dar trecere n alt stare se execut numai la terminarea operaiei n starea precedent. Grafic diagrama de activiti se reprezint n forma unui graf de activitate cu nodurile stri activitate i muchile tranziii de la o stare la alt. n aa fel, diagramele de activiti pot fi considerate cazuri particulare ale diagramelor de stri. Anume aceste diagrame permit realizarea administrrii procedurale i sincrone care depinde de terminarea activitii interne n limbajul UML. Sensul principal al utilizrii acestor diagrame const n vizualizarea particularitilor operaiilor unor clase pentru reprezentarea algoritmilor executrii lor. Totodat fiecare stare realizeaz operaiile unei clase anumite i permite utilizarea diagramei de activiti pentru descrierea reaciilor la evenimente interne acestui sistem. n contextul limbajului UML activitatea (activity) reprezint o totalitate de calcule executate de ctre automat. Totodat calculele elementare pot duce la un anumit rezultat sau careva aciune (action). n diagrama de activiti se reflect logica sau consecutivitatea tranziiilor de la o aciune la alta, totodat se evideniaz rezultatul activitii. Rezultatul, la rndul su poate duce la schimbarea strii sistemului dat sau la returnarea unei valori.

6.1. Starea activitii

Starea activitii este un caz particular a strii. Starea activitii nu poate avea tranziii interne fiindc ea nu este elementar. Starea activitii se utilizeaz pentru modelarea unui pas de executarea a algoritmului (procedurii) sau a unui flux de control. Grafic starea activitii se reprezint printr-o figur asemanatoare cu dreptunghiul, laturile laterale ale cruia sunt substituite cu arcuri convexe (printr-un dreptunghi cu coluri rotunjite) (fig. 48). n interiorul acestei figure se indic expresia unei aciuni care trebuie s fie unic n cadrul unei diagrame de activiti.

Fig. 48. Starea activitii (a actiune simpl, b expresie). 44

O aciune poate fi indicat n limbaj natural, n pseudocod sau n limbaj de programare. Nu sunt restricii suplimentare pentru indicarea aciunilor. Se recomand n calitate de nume al unei aciuni simple s se utilizeze un verb cu cuvinte explicative (fig. 48, a). Dac aciunea nu poate fi reprezentat ntr-un mod formal, atunci este util a-l indica n limbaj de programare pentru realizarea proiectului dat (fig. 48, b). Uneori este necesar a reprezinta n diagrama de activiti o aciune complex care la rndul su const din mai multe aciuni simple. n acest caz poate fi utilizat notaia special a strii de subactivitate (subactivity state). Aa fel de stare este un graf de activitate care se noteaz cu un semn special n colul drept de jos (fig. 49). Aceast construcie poate fi aplicat oricrui element al limbajului UML care susine imbricarea pentru structura sa. Totodat semnul special poate fi etichetat cu tipul structurii.

Fig. 49. Starea subactivitii. Fiecare diagrama de activiti trebuie s aib o singur stare iniial i o singur stare final.

6.2. Tranziii
Tranziia ca element al limbajului UML a fost studiat n capitolul despre diagrama de stri. La construirea diagramei de activiti se utilizeaz careva tranziii netrigere care acioneaz deodat dup perfectarea activitii sau dup executarea aciunii corespunzatoare. Aceast tranziie transmite activitatea n urmtoarea stare imediat dup ce se termin aciunea din starea precedent. n diagram aceast tranziie se reprezint printr-o linie continu cu o sgeat. Dac din starea dat iese numai o tranziie atunci ea poate s nu fie marcat (indicat), dar dac tranziiile de ieire sunt mai multe atunci poate s acioneze numai una din ele. Anume n acest caz pentru fiecare din tranziii trebuie s fie indicat n paranteze patrate o condiie de supraveghere. Totodat pentru toate strile de ieire trebuie s fie executat numai o cerin de veridicitate a unei tranziii. Acest caz are loc cnd activitatea consecvent executat trebuie s fie divizat n ramuri alternative independent de valoarea unui rezultat intermediar. Aceast situaie se numete ramificaie. Grafic ramificaie se reprezint printr-un romb gol (fig. 50). n acest romb numai o sgeat de la o aciune corespunztoare poate s intre. Sgeata de intrare se unete cu vrful de sus sau cu cel din stnga al simbolului de ramificaie. Pot fi mai multe sgei de ieire, dar pentru fiecare din ele trebuie s fie indicat condiia de supraveghere sub form de expresie boolean. Ca exemplu vom cerceta calcularea costului total al produciei procurate cu o cartel bancar. Dac costul depete 50$ atunci se acioneaz identificarea proprietarului cartelei bancare. n caz dac cartela este valabil i contul nu depete suma n 50$ atunci suma se scoate de pe cont i se achit 45

producia procurat. n caz contrar (dac cartela nu este valabil) achitarea nu se execut i producia rmne la vnztor.

Fig. 50. Diverse variante ale ramificaiilor n diagrama de activiti. Unul din cele mai semnificative neajunsuri ale schemelor-block sau ale schemelor ce reprezint algoritmi este legat cu problema reprezentrii ramurilor paralele ale unor calcule. Din motiv c divizarea calculelor n ramuri aparte marete viteza produsului soft, sunt necesare primitive grafice pentru reprezentarea proceselor paralele. n limbajul UML pentru acest scop se utilizeaz simboluri pentru diviziune i unire a calculelor paralele sau a fluxurilor de control. Acest simbol este o linie dreapt analogic notaiei unei tranziii n formalismul reelelor Petri. De regul aceast linie se reprezint printr-un segment al unei linii orizontale, grosimea creia este mai mare dect grosimea liniilor n diagrama de activiti. Totodat fork (diviziunea concurrent fork) are o tranziie de intrare i mai multe de ieire (fig. 51, a). Join (unirea concurrent join) invers are mai multe tranziii de intrare i numai o tranziie de ieire (fig. 51, b).

Fig. 51. Fork i join a mai multor fluxurilor paralele de control. Pentru ilustrarea particularitilor proceselor paralele de executare a aciunilor este util a cerceta exemplul devenit clasic de pregtire a a unei buturi. Avantajul acestui exemplu const n faptul c exemplul practic nu cere explicaii adugtoare, fiindc este considerat evident (fig. 52).

46

Fig. 52. Diagrama de activitate pentru un exemplu de preparare a buturii.

6.3. Partiii
Diagramele de stri pot fi utilizate nu numai pentru specificarea algoritmelor de calculare sau fluxurilor de control n sistemele de programare. Un domeniu de utilizare este legat cu modelarea busimes-proceselor. ntra-devr, activitatea oricrei companii reprezint totalitatea aciunilor independente ndreptate la atingerea rezultatului. Totui relativ de businesprocese este de dorit efectuarea fiecarei aciuni asociative cu subdivizare a companiei concrete. n acest caz aceste subdiviziuni au responsabilitatea de realizare a unor aciuni, iar businesprocesele reprezint trecerea aciunilor de la o subdivizare la alta. 47

Pentru modelarea acestor particulariti n limbajul UML se folosete construcia special, care are denumire de partiii (swimlanes), care sunt divizate unul cu altul cu linii verticale. Dou linii vecine formeaz o partiie, iar un grup de stri ntre aceste linii sunt executate de subdiviziunea separat (secie, filial, diviziuni) a companiei (fig. 53). Denumirele subdiviziunelor sunt indicate n partea de sus a partiiei. A ntretia linia partiiei pot numai tranzaciile, care n acest caz indic ieirea sau intrarea fluxului de control n subdiviziunea respectiv a companiei. Ordinea trecerii partiiilor nu are care-va informaie simantic i este definit dup motivele de comfortabilitate. Ca exemplu vom lua fragmentul diagramei de activitate a companiei de vindere, care servesc clienii cu ajutorul telefonului. Subdiviziunele companiei sunt secia de acceptare i perfectare a cerinelor, secia de vindere i depozitul. Acestor subdiviziuni vor corespunde trei partiii n diagrama de activitate, fiecare din care specific zona de responsabilitate a subdiviziunei. n cazul dat diagrama de activitate ntreine nu numai informaie despre consecutivitatea executrii a aciunii lucrtorilor, dar i care subdiviziuni a companiei de vindere trebuie s execute o aciune sau alta (fig. 53).

Fig. 53. Fragmentul diagramei de activitate pentru compania de vindere. Din aceast diagram de activitate este evident c dup acceptarea comandei de la client a seciei de acceptare i perfectare a cerinelor se realizeaz diviziunea activitii la dou fluxuri (tranzacie diviziune). Primul din ei rmne n aceeai secie i este legat cu acceptarea mrfurilor n secia de vindere (modelul mrfii, dimensiuna, culoarea, anul de editare etc.). Dup finisarea lucrului acesta iniializeaz aciunea de eliberare a marfurilor din depozit. Totui pregtirea mrfii pentru expedierea n secia de vindere ncepe numai dup achizionarea mrfii de la client i marfa va fi expediat din depozit (tranziie - conectare). Numai dup aceasta marfa este expediat la client i devine proprietatea lui. 48

6.4. Obiecte
n cazul general aciunile n diagrama de activitate sunt efectuate cu obiecte. Aceste obiecte sau iniializeaz executarea aciunelor sau definesc un anumit rezultat a acestor aciuni. n urma cruia aciunile specific apelurile, care trec de la un obiect a grafului de activitate la altul. ntruct n acest racurs obiectele joac un anumit rol n nelegerea procesului de activitate, uneori apare necesitatea indicrii lor n diagrama de activitate. Pentru reperezentarea grafic a obiectelor sunt utilizate dreptunghiurile clasei cu o deosebire: numele obiectului se subliniaz. Dup nume poate fi indicat caracteristica strii obiectului n paranteze ptrate. Aceste dreptunghiuri a obiectelor sunt unite cu strile de activiti a relaiei de dependen cu linia punctir cu sgeat. Dependena respectiv definete starea concret a obiectului dup efectuarea aciunii precedente. n diagrama de activitate cu partiii deplasarea obiectelor poate avea un sens adugtor. i anume, dac obiectul este amplasat la hotarul ambilor partiii, aceast lucru nseamn c trecerea la starea de aciune urmtoare n partiia vecin este asociat cu un document finit (obiectul n care-va stare). Dar dac obiectul este amplasat nuntrul partiiei, atunci starea acestui obiect este definit de aciunile partiiei date. Revenind la exemplul precedent cu compania de vindere, poate nota c obiectul central a procesului de vindere este comanda, anume starea ei de executare. La nceput, pn la primirea sunetului de la client, comanda ca obiect lipsete i apare numai dup ce a am primit sunetul de la client. Totui, aceast comand nu este ndeplinit pn la urm, deoarece este necesar de alege o marf concret din secia de vindere. Dup pregtirea lui el transfer marfa la depozit, unde mpreun cu eliberarea mrfurilor comanda este perfectat. La sfrit, dup trimiterea confirmrii despre achiziionarea mrfii aceast informaie nscrie n comand i el este ndeplinit i sfrit (fig. 54).

Fig. 54. Fragmentul diagramei de activitate a companiei de vindere cu obiect comand. 49

7. Diagrama de secven (sequence diagram)

n limbajul UML colaborarea ntre elemente se cerceteaz n aspectul informativ al comunicaiilor lor, adic obiectele care interacioneaz fac schimb de informaie anumit. Pentru modelarea colaborrii ntre obiecte n limbajul UML se utilizeaz diagramele de secven. Vorbind despre aceste diagrame se iau n consideraie dou aspecte. Mai nti, colaborarea ntre obiecte poate fi cercetat n timp i atunci pentru reprezentarea particularitilor temporale i modului de acceptare a mesajelor se utilizeaz diagrama de secven. n al doilea rnd pot fi cercetate particularitile structurale ale colaborrii ntre obiecte. Pentru reprezentarea particularitilor de transmitere i acceptare a mesajelor ntre obiecte se utilizeaz diagrama de colaborare.

7.1. Obiecte
n diagrama de secven se reprezint numai obiectele care acioneaz i nu se reflect asocierile statice cu alte obiecte. Pentru diagrama de secven momentul principal este dinamica colaborrii ntre obiecte n timp. Grafic fiecare obiect se reprezint printr-un dreptunghi i se plaseaz n partea de sus a ciclului su de via (fig. 54). n nteriorul dreptunghiului se indic numele obiectului i numele clasei desprite prin dou puncte. Totodat toat nregistrare se subliniaz, ce indic c obiectul este exemplarul unei clase. n caz dac numele obiectului lipsete, atunci se indic numai numele clasei i obiectul se consider anonim.

Fig. 55. Primitivele grafice ale diagramei de secven. Obiectul din stnga diagramei este cel care iniiaz colaborarea (obiectul 1 n fig. 55). Mai la dreapt se reprezint obiectul care interacioneaz cu primul. Totate obiecte n diagrama de secven formeaz o anumit ordine determinat de activitatea colaborrii lor. A dou msur a diagramei de secven este axa vertical de timp (din sus n jos). Momentului iniial de timp i corespunde partea de sus al diagramei. Totodat colaborarea obiectelor este realizat prin mesajele transferate. Mesajele se reprezint sub forma de sgei drepte cu numele mesajelor, ele de asemenea sunt ntr-o ordine anumit n timp. Cu alte cuvinte, mesajele plasate n diagrama de secven mai sus sunt iniiate mai devreme dect cele din jos. Totodat proporiile pe axa temporal nu se indic fiindc diagrama de secven modeleaz doar ordonarea n timp a legturilor de tip mai devrememai trziu.

50

7.1.1. Linia de via al obiectului

Linia de via a obiectului (object lifeline) se reprezint printr-o linie vertical punctat asociat cu un singur obiect n diagrama de secven. Linia de via definete intervalul de timp n care obiectul exist i interacioneaz cu sistemul dat. Obiecte aparte, dup terminarea activitii sale, pot fi distruse pentru eliberarea resurselor alocate. Pentru aceste obiecte linia lor de viata se rupe n momentul de distrugere. Pentru reprezentarea momentului de distrugere al unui obiect n limbajul UML se utilizeaz un simbol special sub forma de litera latin X. Mai jos de acest simbol, linia punctat nu poate fi desenat fiindc obiectul n sistemul deja nu este i acest obiect este exclus din toate interaciunile ulterioare. Nu este obligatoriu a crea obiecte la momentul iniial de timp. Obiecte aparte n sistemul dat pot fi create la necesitate, economisind resursele acestui sistem i majornd randamentul lui. n acest caz dreptunghiul obiectului respectiv se desenaz n partea diagramei care corespunde momentului de creare a obiectului.

7.2. Focus control

n procesul de funcionare a sistemelor OO unele obiecte pot fi n stare activ executnd aciuni anumite sau pot fi pasive ateptnd mesaje de la alte obiecte. Pentru a evidenia obiectele active n limbajul UML se utilizeaz notaia special focus control (focus of control). Focus control se reprezint n form de dreptunghi subire, latura de sus a cruia determin (reflect) nceputul activitii, latura de jos terminaia focusului de control (activitii). n unele cazuri ca iniiator al activitii n sistem poate fi un actor sau utilizatorul extern. n acest caz actorul se deseneaz primul din stnga cu focus control respectiv. Totodat actorul poate s aib un nume propriu sau s rmn anonim.

7.3. Mesaje
Scopul colaborrii n contextul limbajului UML const n specificarea comunicaiei ntre o mulime de obiecte. Fiecare legtura se descrie cu o totalitate de mesaje transferate cu care obiecteleparticipante se schimb. n acest sens mesajul (messaje) reprezint un fragment de informaie care este transferat de ctre un obiect altuia. Totodat acceptarea mesajului iniializeaz anumite aciuni ndreptate spre rezolvarea problemei de ctre obiectul cruia mesajul i este transferat. Mesajele nu numai transmit informaia, ele presupun executarea aciunilor ateptate de ctre obiectul acceptabil. Mesajele pot iniia executarea operaiilor de ctre obiectul unei clase, dar parametrii acestor operaii sunt transferai mpreun cu mesajul. n diagrama de secven toate mesajele sunt coordonate dup timpul de apariie n sistemul modelat. n context dat mesajul este destinat de ctre obiect care iniiaz sau transfer mesajul ctre obiectul care l accept. Uneori expeditorul al unui mesaj este numit clinet, dar destintarul server. Totodat mesajul de la un anumit client este o cerin a unui server. Reacia acesctui server la cerina dup primirea mesajului presupune executarea anumitor aciuni i transmiterea informaiei sub forma a unui mesaj ctre client. n limbajul UML sunt cteva varieti de mesaje, fiecare din ele are notaia grafic proprie. n unele cazuri obiectul poate transmite mesaje ctre sine iniializnd mesaje reflexive. 51

7.3.1. Stereotipuri de mesaje

n limbajul UML sunt presupuse numai aciuni standarde, care se execut la primirea mesajului respectiv. Ele pot fi indicate n diagrama de secven sub forma de stereotipuri lnga mesaje respective. n acest caz ele se scriu n ghilimele. Se utilizeaz notaiile urmtoare:

"call" invoc o operaie sau procedur a obiectului-destinatar; "return" returneaz valoarea operaiei executate obiectului apelant; "create" creaz alt obiect pentru executarea anumitor aciuni; "destroy" distruge un obiect. Se transmite n caz dac este necesar a termina aciunile din partea obiectului existent sau dac obiectul trebuie s elibereze resursele alocate; "send" trimite un semnal unui obiect care se iniializeaz asincron de ctre un obiect i este acceptat de altul. Diferena ntre un semnal i un mesaj const n fapt c semnalul trebuie s fie descris n clasa obiectul creia iniializeaz transmiterea lui.

Mesajele pot avea notaii proprii pentru operaii, apelarea crora ele o iniializeaz. n acest caz lng sgeat se scrie numele operaiei cu paranteze rotunde n care se indic parametrii sau argumentele operaiei respective. Dac parametrii lipsesc atunci parantezele rmn neaprat dup numele operaiei.

Fig. 56. Notaiile mesajelor in diagrama de secven.

7.4. Restricii temporale n diagrama de secven

n unele cazuri executarea unor aciuni n diagrama de secven poate necesita specificaia unor restricii temporale ctre intervalul executrii unei operaii sau transmiterii mesajelor. n limbajul UML pentru scrierea restriciilor temporale se utilizeaz acoladele. Ca exemple de restricii n diagrama de secven sunt situaii de specificare a timpului pentru transmiterea a unui mesaj de la client ctre server sau situatii de prelucrare a cerinei clientului.

{timpul_de_ateptare_a_rspunsului < 5 sec.} {timpul_de_trnsmitere_a_pachetului < 10 sec.}

52

a : Abonat

c: Aparat de telef on ridica receptorul signal ton() roteste discul

: Comutator

d: Aparat de telef on

b : Abonat

f ormeaza un numar

: Conv orbire "create" conexare() conexare(a) pune receptorul termina conv orbire "destroy " termina conv orbire "send" "send" sunet() ridica receptorul conexare(b) pune receptorul

Dupa conexare Abonatul a si Abonatul b pot incepe conv orbire

Fig. 57. Exemplu de construcie a unei diagrame de secven.

8. Diagrama de colaborare (collaboration diagram)

Particularitatea principal a diagramei de colaborare const n posibilitatea de a reprezenta grafic nu numai consecutivitatea colaborrii dar i toate relaii structurale ntre obiecte. n primul rnd n diagrama de colaborare sub form de dreptunghiuri se reprezint obiectele care conin numele obiectului, clasei, valorile atributului. Mai departe, ca i n diagrama de clase se indic asocierile ntre obiecte sub forma de linii de conectare. Totodat pot fi indicate numele asocierilor i al rolurilor obiectelor pentru asocierea dat. Suplimentar pot fi reprezentate legturile dinamice fluxurile de mesaje. Ele se reprezint ca linii ntre obiecte cu sgei care indic derecia, numele mesajului i numrul de ordine n consecutivitatea de iniializare a mesajelor. Spre deosebire de diagrama de secven n diagrama de colaborare sunt reprezentate relaiile ntre obiecte care sunt importante pentru colaborare. Din alt parte n aceast diagrama nu se indic timpul n calitate de msur. Consecutivitatea de aciuni i flux paralel pot fi determinate cu ajutorul numerelor de ordine, deci este posibil specificarea legturilor ntre obiecte n timp real. Pentru atingerea unui scop sau pentru realizarea unui serviciu comportamentul unui sistem poate fi descris la nivelul obiectelor care fac schimb de mesaje. Din punct de vedere a unui analist sau a unui constructor este important reflectarea legturilor structurale ale obiectelor aparte. Diagrama de colaborare reflect un fel de reprezentare static a unui sistem ca totalitate de obiecte dependente.

8.1. Obiecte
Obiecte sunt elementele de baz sau primitivele grafice din care const diagrama de colaborare. Pentru reprezentarea grafic a obiectelor se utilizeaz acelai dreptunghi ca i pentru reprezentarea clasei. 53

Obiectul (object) este un exemplar aparte al clasei care este creat la etapa executrii a unui program. El poate avea un nume propriu i valorile atributelor. Referitor la obiecte formatul liniei ce conine clasificatorul se completeaz cu numele obiectului: <Numele obiectului>'/' <Numele rolului al clasificatorului> ':' <Numele clasificatorului> [':' <Numele clasificatorului >]* Aici Numele rolului clasificatorului poate s nu fie indicat. n acest caz el se exclude din context mpreun cu dou puncte. Numele rolului poate fi omis n caz daca exist mai multe roluri n colaborarea obiectelor create pe baza clasei date. Pentru definirea rolului clasificatorului este de ajuns a indica numele clasei (mpreuna cu dou puncte) sau numele rolului (mpreuna cu /). n caz contrar dreptunghiul va corespunde clasei ordinare. Dac rolul unui obiect se motenete de la mai multe clase, atunci ele toate trebuie s fie indicate i desprite prin virgul i dou puncte. Urmtoarele sunt variante de indicare a textului n nteriorul dreptunghiului.

: un obiect anonim creat pe baza clasei . / R un obiect anonim cu rolul R. / R : un obiect anonim creat pe baza clasei cu rolul R. / R un obiect cu numele O cu rolul R. : un obiect cu numele O creat pe baza clasei . / R : un obiect cu numele O creat pe baza clasei cu rolul R. sau obiectul cu numele . : un "obiect orfan" cu numele . / R un rol cu numele R. : un rol anonim pe baza clase . / R : un rol cu numele R pe baza clase .

Fig. 58. Exemple de moduri de indicare a numelor obiectelor, rolurilor i claselor n diagrama de colaborare. n primul caz (fig. 58, a) obiectul cu numele client cu rolul iniiatorul cerinei. n cazul (fig. 58, b) este indicat un obiect anonim cu rolul iniiatorului cerinei. n ambele cazuri nu este indicat clasa pe baza creia sunt create aceste obiecte. n cazul (fig. 58, c) clasa este determinat, dar obiectul rmne anonim. Referitor la nivelul de specificare n diagramele de colaborare pot fi specificate clase denumite cu indicarea rolurilor (fig. 58, d) sau clase anonime dar tot cu indicarea rolurilor (fig. 58, e). Ultimul caz reflect situaia cnd n model pot fi prezente cteva clase cu numele Client, de aceea este necesar specificarea numelui pachetului Baza de date (fig. 58, f).

54

8.1.1. Multiobiect
Multiobiect (multiobject) reprezint o mulime de obiecte n una din terminaiile asocierei. n diagrama de colaborare multiobiectul se utilizeaz pentru a arat operaiile i semnalele care sunt adresate ctre toat mulimea de obiecte. Multiobiectul se reprezint n forma a dou dreptunghiuri, unul din care iese n afara laturei de sus a altui dreptunghi (fig. 59, a). Totodat sgeata mesajului se refer la toat mulime de obiecte care definesc multiobiect dat. n diagrama de colaborare poate fi indicat relaia compoziiei (structura) ntre multiobiect i un obiectul aparte din mulime care l definete (fig. 59, b).

Fig. 59. Multiobiect.

8.1.2. Obiect activ

n contextul limbajului UML toate obiecte se mpart n doua categorii: pasive i active. Obiectul pasiv folosete numai datele i nu poate iniializa activitatea de control. Obiecte pasive pot transmite semnale pe parcursul procesului de realizare a cerinelor. Obiectul activ (active object) are un fir (thread) de control propriu i poate iniializa activitatea de control. Totodat sub noiune de fir se subnelege un anumit flux de control care poate fi executat n paralel cu alte fire de calcul sau cu fire de control n cadrul unui proces de calcul sau control. Obiectele active n diagramele canonice sunt reprezentate n form de dreptunghi cu laturi groase (fig. 60). Uneori pentru a evidenia obiectul activ n diagram poate fi indicat cuvntul-cheie (valoarea marcat) {active}. Fiecare obiect activ poate iniia un singur fir sau proces de control i s prezinte punctul iniial al fluxului de control. n fragmentul diagramei de colaborare dat obiect activ a: Abonatul arogant este iniiatorul procesului de stabilire convorbirii pentru schimb de informaie ntre aboneni.
1: create a : Abonatul arogant c: Conectare

Fig. 60. Obiect activ. n exemplu urmtor se cerceteaz situaia de apelare a funciei de tipar a unui redactor textual (fig. 61). Obiectul activ anonim Redactor textual mai nti trimite mesajul ctre multiobiectul Imprimant care iniiaz alegearea unui singur obiect Imprimant care satisface cerinele suplementare. Dup aceea obiectului ales i se transmite mesajul de tipar al unui document ncrcat n redactorul textual.

55

1: aImprimanta:=alege() : Redactor textual : Imprimanta

F

2: tipar(document) : Imprimanta

Fig. 61. Fragmentul diagramei de colaborare pentru apelare funciei de tipar din redactor textual.

8.1.3. Obiect compus

Obiectul compus (composite object) sau obiectul-container este destinat pentru reprezentarea obiectului care are structura proprie i fire interne de control. Obiectul compus este exemplarul clasei compuse care este legat cu parile sale prin relaii de agregare sau compoziie. Relaii analogice leag obiectele respective. n diagramele de colaborare aa fel de obiecte compuse se reprezint n forma a unui obiect ordinar care const din dou secii. n secia de sus se indic numele obiectului compus, n cea de jos prile compuse n locul listei atributelor lui (fig. 62). Totodat n calitate de pri pot fi obiecte compuse.

Fig. 62. Obiect compus.

8.2. Legturi
Legtura (link) este exemplarul sau exemplul asocierii arbitrare. Legtura ca element al limbajului UML poate fi ntre dou sau mai multe obiecte. Legtura binar n diagrama de colaborare se reprezint n form de segment al liniei drepte care leag dou dreptunghiuri ale obiectelor (fig. 61). La fiecare terminal al acestui segment pot fi indicate numele rolurilor asocierii date. Lng linie, n mijlocul ei, se indic numele asocierii respective. Legturile nu au numele proprii fiindc sunt identice ca exemplare ale asocierii. Cu alte cuvinte toate legturile n diagrama de colaborare pot fi numai anonime i se indic fr dou puncte naintea numelui asocierii. Pentru legaturi nu se indic nici multiplicitatea. ns alte reprezentri ale cazurilor particulare de asociere (agregare, compoziia) pot fi la terminaiile legturilor. De exemplu, simbolul de tip compoziia ntre multiobiectul Imprimant i obiectul aparte Imprimant (fig. 61). 56

8.2.1. Tipuri de legturi

Tipul de legtura se nscrie lnga terminaia ei i indic posibilitatea realizrii acestei legturi. n limbajul UML pentru acest scop se utilizeaz:

"association" asociere (se presupune implicit, de aceea acest tip poate s nu fie indicat). "parameter" parametrul metodei. Obiectul respectiv poate s fie doar paramentru al unei metode. "local" variabila local a metodei. Domeniul ei de vizibilitate este limitat de ctre obiectul vecin. "global" variabila global. Domeniul ei de vizibilitate este toat diagrama de colaborare. "self" legtura reflexiv a obiectului care presupune transferul mesajelor ctre sine. n diagrama de colaborare legtura reflexiv se reprezint n form de bucl n partea de sus al dreptunghiului obiectului.

Unele exemple de legturi cu diferite stereotipuri sunt prezentate n fig. 63. Aici este reprezentat schema unei companii cu numele C care const din secii (multiobiect anonim Secie). Seciile constau din angajai (multiobiect anonim Angajat). Legtura reflexiv indic faptul c managerul seciei este i angajatul acesteia.
c : Compania

"local" subsectie : Sectie "self" manager "local" executa lucrul

: Angajat

Fig. 63. Legturi de diferite tipuri. Pentru obiectul Convorbire2 se indic valoarea {transient} care nseamn c obiectul este creat pe parcursul executrii procesului i se distruge nainte de terminaia lui.

57

5: comutati e(a,b)

: Comutator
4: formeaza un numar(i) 8: apeleaza_abonatul(b)

legatura telefonica c : Aparat de telefon

7: confirma()

legatura telefonica
6: creaza()

d : Aparat de telefon

1: ridica_receptorul() 3: roteste_discul ()

"local"

2: signal_ton()

: Convorbire
transient

10: ridica_receptorul()

"local"
11: i ncepe_convorbire()

9: sunet()

12: i ncepe_convorbire()

"global" participant_convorbirei

"global" participant_convorbire

a : Abonat

b : Abonat

Fig. 64. Exemplu de construire a diagramei de colaborare.

8.3. Colaborare
Noiune de colaborare (collaboration) este una din noiunile fundamentale ale limbajului UML. Ea nseamn o mulime de obiecte care interacioneaz n contextul comun al sistemului modelat. Scopul colaborrii const n specificarea particularitilor realizrii a celor mai semnificative operaii n sistem. Colaborarea determin structura comportamentului sistemului dat n termeni de colaborare a participanilor. Colaborarea poate fi prezentat n dou nivele:

Nivelul de specificare arat rolurile clasificatorilor i rolurile asocierilor n colaborarea dat. Nivelul de exemple indic exemplare i legturi, roluri n colaborare.

Diagrama de colaborare la nivel de specificare arat rolurile elementelor ce particip n colaborare. Elementele colaborrii la acest nivel sunt clase i asocieri care reprezint rolurile unor clasificatori i asocieri ntre participanii acestei colaborari. Diagrama de colaborare la nivel de exemple reprezint o totalitate de obiecte (exemplare de clase) i legturi (exemplare de asociere). Totodat legturi sunt completate cu sgeile mesajelor. La acest nivel sunt reflectate numai obietce relevante, adic obiectele care au legtur cu realizarea operaiei sau clasificatorului. n colaborare la nivel de exemple sunt definite proprieti fiecrui exemplar pentru participarea n colaborare. n afara de proprietile obiectului, n diagrama de colaborare sunt indicate asocierile ntre obiectele acestei colaborri. n momentul cnd clasificatorul necesit descrierea complet a tuturor exemplarilor, rolul clasificatorului necesit descrierea numai proprietilor i asocierilor pentru participarea ntr-o colaborare anumit. 58

Una i aceeai totalitate de obiecte poate participa n mai multe colaborri. Totodat, n dependen de colaborarea cercetat, unele proprieti ale obiectelor pot s se schimbe aa precum i legturile ntre ele. Anume acest fapt deosebete diagrama de colaborare de diagrama de clase n care sunt indicate toate proprietile i asocierile ntre elementele diagramei.

8.3.1. Diagrama de colaborare la nivel de specificare

Colaborarea la nivel de specificare se reprezint printr-o elips punctat n interiorul creia se indic numele acestei colaborri (fig. 65). Aa fel de reprezentare se refera la un caz de utilizare particular i care detaliaz particularitile realizrii lui urmtoare. Simbolul elipsei a colaborrii se leag cu fiecare din participanii acestei colaborri (care pot fi obiecte sau clase) cu segmente de linie punctat. Fiecare din aceste segmente punctate se marcheaz cu rolul (role) participantului. Rolurile corespund numelor elementelor n contextul ntregii colaborri. Aceste numele sunt tractate ca parametrii care limiteaz specificarea elementelor la orice apariie a lor n reprezentrile modelului.

Fig. 65. Colaborarea n diagrame la nivel de specificare. Clasa elementar n diagrama de colaborare se reprezint printr-un dreptunghi n nteriorul creia se indic textul. Acest text este (definete) rolul clasificatorului (classifier role). Rolul clasificatorului specific utilizarea obiectelor clasei date. Deseori n dreptunghi se indic numele clasei, dar nu se exclude posibilitatea de a indica atribute i operaii. Textul n dreptunghi este de fel urmtor: '/' <Numele rolului clasificatorului> ':' <Numele clasificatorului> [':' < Numele clasificatorului >]* Aici Numele clasificatorului poate s conin direcia tuturor pachetelor componente. Totodat un pachet se divezeaz de altul prin dou puncte duble ::. Dac aceast nu ncurc atunci se poate de indica numai pachetul apropiat care conine colaborare dat. Simbolul * arat posibilitatea de repetare iterativ a numelui clasificatorului. Dac colaborarea permite reprezentarea generalizat, atunci n diagrame pot fi indicate relaii de generalizare a elementelor respective. Acest principiu determin colaborri aparte, care sunt cazuri particulare sau specializare ale altei colaborri. Aceasta situaie deseori se reprezint n form de sgeat de generalizare ndreptat de la simbolul colaborrii al descendentului spre simbolul colaborrii alunui printe (fig. 66).

59

Fig. 66. Relaii de generalizare ntre colaborrii la nivel de specificare. n unele cazuri apare necesitatea de a indica faptul c colaborarea este realizarea unei operaii sau a unui clasificator. Acest fapt poate fi reprezentat n doi feluri. n primul rnd simbolul colaborrii poate fi conectat cu ajutorul liniei punctate cu sgeata generalizrii cu simbolul clasei, realizarea operaiei cruia specific colaborarea data (fig. 67, a). Dac n calitate de clas va fi cercetat Comanda la procurarea produciei care are operaia ntocmirea_comandei() atunci realizarea ei poate fi specificat n form de colaborare.

Fig. 67. Metode de reprezentare a colaborrii care realizeaz operaiunea clasei. n al doilea rnd este uor de reprezentat simbolul colaborrii n nteriorul cruia se poate de indicat toat informaia necesar conform regulii speciale (fig. 67, b). Aceste reguli definesc formatul de nregistrare a numelui de colaborare, dup care se scriu dou puncte i numele clasei, dup numele clasei se scriu dou puncte duble i numele operaiei. Aa fel de reprezentare generalizat a colaborrii la nivel de specificare se utilizeaz la etapele iniiale de proiectare. Ulterior fiecare din colaborri poate fi detaliat la nivel de exemple, la care se desfoar coninutul i structura legturilor elementelor acestei colaborri n diagrama de colaborare aparte. Totodat n calitate de elemente ale diagramei pot fi obiecte i legturi completate cu mesaje. Anume astfel de elemente sunt obiectul cercetrii n capitolul dat.

9. Diagrama de componente (component diagram)

Toate diagramele cercetate mai sus reflectau aspectele conceptuale de proiectare a unui model de sistem i se referiau la nivelul logic de reprezentare. Specificul reprezentrii logice const n faptul c el utilizeaz noiuni care nu au personificare material proprie. Cu alte cuvinte diferite elemente ale reprezentrii logice (clase, asocieri, stri, mesaje) nu exist n mod material sau fizic. Ele numai reflect nelegerea noastr despre sistemul fizic sau despre aspectele comportamentului acestui sistem.

60

Destinaie principala a reprezentrii logice const n analiza relaiilor structurale i funcionale ntre elementele unui model de sistem. Pentru crearea unui sistem fizic real este necesar a transforma toate elementele reprezentrii logice n entiti materiale. Pentru descrierea acestor entiti este destinat aspectul reprezentrii modelare fizice. Pentru a explica diferena ntre reprezentarea logic i fizic vom cerceta procesul de elaborare a unui sistem de program. n calitate de reprezentare logic iniial a acestui sistem pot fi schemele structurale ale algoritmelor i procedurilor, descrieri a unor interfee i baza de date conceptual. Pentru realizarea acestui sistem este necesar de a elabora codul surs n anumit limbaj (C++, Pascal, Basic/VBA, JAVA). Totodat n codul surs se presupune divizarea acestui cod n module aparte. Cu toate c codurile surs iniiale sunt fragmente ale reprezentrii fizice a unui proiect, ele nu prezint realizarea final a lui. Sistemul program poate fi considerat realizat numai n caz daca el va putea executa funciile destinaiei sale. Aceasta este posibil dac codul surs al unui sistem va fi realizat n forma de module executate, biblioteci ale claselor i procedurilor, interfeelor grafice standarde, fiierelor bazelor de date. Anume aceste componente sunt necesare pentru reprezentarea fizic a unui sistem. Proiectul complet al unui sistem al programului reprezint o totalitate de modele ale reprezentrii logice i fizice care sunt coordonate ntre ele. n limbajul UML pentru reprezentarea fizic a unui model al sistem sunt utilizate diagramele de realizare (implementation diagrams) care includ dou diagrame canonice: diagrama de componente i diagrama de plasare. Specifica crerii primei din ele va fi cercetat n capitolul dat, al ultimei diagrame n capitolul urmtor. Diagrama de componente, spre deosebire de diagramele cercetate, descrie particularitile reprezentrii fizice a unui sistem. Diagrama de componente permite determinarea arhitecturii sistemului elaborat prin stabilirea dependenei ntre componentele de program n calitate de care poate fi codul iniial, binar i executabil. n mai multe domenii de elaborare modul i componenta corespund fiierului. Sgeile punctate care leag modulele arat relaiile de dependena analogice celor ce au loc la compilarea codurilor sursei iniiale. Elementul grafic de baz al diagramei de componente sunt componentele, interfeele i dependenele ntre ele. Diagrama de componente se elaboreaz pentru urmatoarele scopuri:

Vizualizarea structurii comune a codului surs a unui sistem de program. Specificarea variantei executabile a unui sistem de program. Asigurarea utilizrii repetate a unor fragmente ale codului surs. Reprezentarea conceptual i fizic a schemelor bazei de date.

n elaborarea diagramei de componente particip analitii de sistem, arhitectorii, i programitii. Diagrama de componente asigur trecere coordonat de la reprezentare logic spre o realizare a unui proiect n form de cod surs. Unele componente pot exista numai la etapa compilrii codului sursei, altele la etapa realizrii lui. Diagrama de componente reflect dependenele ntre componente la cercetarea componentelor n calitate de clasificatori.

9.1. Componente
Pentru reprezentarea entitilor fizice n limbajul UML se utilizeaz componenta (component). Componenta realizeaz un set de interfee i desemneaz elementele reprezentrii fizice a unui model. Grafic componenta se reprezint printr-un dreptunghi cu anexe (fig. 67). n nteriorul acestui dreptunghi se indic numele componentei i posibil informaia suplementar. Reprezentarea acestui simbol variaz n dependen de informaia asociat cu componenta dat. 61

n metamodelul limbajului UML componentul este descendentul clasificatorului. El reprezint organizaia n cadrul unui pachet fizic cu care el este asociat cu ajutorul elementelor unui model. n calitate de clasificator componentul poate s aib aa proprieti ca atribute i operaii.

Fig. 68. Componenta. n primul caz (fig. 68, a) cu exemplarul componentei se leag numai numele lui, n al doilea caz (fig. 68, b) se leag n completare numele pachetului i valoarea marcat. Adnotare Reprezantarea componentului devine de la marcare modulului programului, care a fost utilizat un anumit timp pentru reprezentarea particularitilor incapsularii datelor i procedurilor. n aa fel, un dreptunghi mic de sus se asociaz cu datele, care realizeaz acest component (anterior a fost semnat cu oval). Un dreptunghi mic de jos se asociaz cu operaii i metode, realizate de component. n cazurile mai simple numele de date i metode au fost scrise n aceste dreptunghiuri mici, totui ele nu sunt indicate n limbajul UML.

9.1.1. Numele componentului

Numele componentului este subardonat de regulele generale a numelelor elementelor modelului n limbajul UML i poate fi compus din orice numr de litere, cifre i anumite semnuri de punctuaie. Un component poate fi reprezentat la nivel de tip sau de exemplar. Dei reprezentarea grafic lui n ambele cazuri este identic, regulile de notare a numelui componentului difer puin. Dac componentul este reprezentat la nivelul tipului, atunci ca numele lui este scris numai numele tipului cu majuscul. Dar dac componentul este reprezentat la nivelul exemplarului, atunci numele este scris <numele componentului:numele tipului>. n urma cruia toat alinierea numelui este subliniat. Adnotare Dei regulile de notare a obiectelor n limbajul UML cere sublinierea numelor anumitor exemplare, relativ de componentele n literatur sublinierea numelelor lor nu este obligatorie. n acest caz notarea numelui componentului cu majuscul va caracteriza componentul nivelului de exemplar. n calitate de nume simple sunt utilizate numele fiierelor executabile (cu indicarea extensiei.exe dup punct), numele librriilor dinamice (cu extensia .dll), numele Web paginilor (cu extensia .html), numele fiierilor de text (cu extensia .txt sau .doc) sau fiiere de adeverin (.hip), numele fiierelor bazelor de date (.db) sau numele fiierelor cu texturi iniiale a programelor( cu extensia .h, .cpp pentru limbajul C++, cu extensia .java pentru limbajul Java), scripturi (.pi,.asp) i altele. ntruct realizarea concret reprezentrii logice modelului a sitemei depinde de instrumentarea programului utilizat, de aceea numele componentelor vor fi definite de particularitile sintaxei limbajului de programare respectiv. 62

9.1.2. Feluri de componente

ntruct componentul ca element a realizrii fizice a modelului reprezint un modul al codului, deseori el este comentat cu indicarea simbolelor grafice adugtoare, care marcheaz particularitile concrete realizrii lui. Aceste notaii adugtoare pentru adnotare nu sunt specificate n limbajul UML. Totui utilizarea lor simplific nelegerea diagramei de componente i perfecioneaz reprezentarea ei grafic. Unele notaii pentru componente sunt prezentate mai jos (fig. 69). n limbajul UML sunt specificate trei feluri de componente:

n primul rnd componente de regrupare, care specific executarea de ctre sistem a funciilor sale. Aa fel de componente pot fi librrii conectate dinamic cu extensia .dll (fig. 69, a), Web pagini n limbajul de trasare hipertextului cu extensia .html (fig. 69, b) i fiierele de adeverin cu extensia .hip (fig. 69, c). n al doilea rnd, componente produse de lucru. Ca regul acestea sunt fiierele cu texte iniiale a programului, de exemplu, cu extensia .h sau .cpp pentru limbajul C++ (fig. 69, d). n al treilea rnd, componentele de executare, ce reprezint modulele fiierele cu extensia .exe. Ei se indic obinuit.

Fig. 69. Variantele reprezentrii grafice a componentelor diagramei de componente. Aceste elemente sunt uneori numite artefacte, subliniaz n aa fel coninutul lor informaional finit, dependent de tehnologie de realizare concret a componentelor respective. Mai mult dect att, elaboratorii pentru acest scop pot utiliza notaii independente, deoarece n limbajul UML nu exist notare strict pentru reprezentarea grafic a notaiilor. Un alt mod de specificare a diferitor feluri componentelor este indicarea steriotipului componentului naintea numelui lui. n limbajul UML pentru componente sunt specificate urmtori steriotipuri:

Librrie (library) definete prima specie a componentuluui, care reprezent librrie dinamic sau static. Tabel (table) definete prima specie a componentului, care reprezent un tabel de baze de date. Fiier (file) definete a doua specie a componentului, care reprezint un fiier cu texte iniiale a programului. Document (document) definete a doua specie a componentului, care reprezint un document. Executare (executable) definete a treia specie componentului, care poate fi executat n nod.

63

9.2. Interfee
Urmtorul element a diagramei a componentelor sunt interfeele. Ultimele au fost desrise mai sus, de aceea aici vor fi indicate numai acele proprieti, care sunt tipice pentru reprezentarea la diagramele de componente. Ne reamentim c n cazul general interfaa este reprezentat n form de circumferin, care este legat cu componentul cu ajutorul liniei fr sgeat (fig. 70, a). n urma cruia numele interfeei, care obligatoriu trebuie s fie scris cu majuscul I, este scris alturi de circumferin. Semantic linia nseamn interfaa, iar prezena interfeelor la componente nseamn c componentul dat realizeaz trus de interfee respective.

Fig. 70. Reprezentarea grafic interfeelor n diagrama de componente. Un alt mod de reprezentare a interfeelor n diagrama de componente este reprezentarea lui n forma de dreptunghi a clasei cu stereotipul interfaa i cu seciuni posibile a atributelor i operaiilor (fig. 70, b). Ca regul, acest caz de notare este utilizat pentru reprezentarea structurii interne a interfeei, care poate fi important pentru realizarea. n urma elaborrii sistemelor de programare interfeele asigur nu numai coinciderea diferitor versiuni, dar i posibilitatea de ntroducere a schimbrilor n unele pri a programului neschimbnd altele pri a ei. n aa fel, destinaia interfeilor este mai adnc, dect specificaia interaciunii cu utilizatorii sistemului (actorii). Adnotare Caracter de utilizare a interfeelor cu unele componente poate fi diferit. De aceea exist dou feluri de legtur a interfeei i componentului. Dac componentul realizeaz o anumit interfa, atunci aceast interfa este numit de export, deoarece acest component prezint n el modul de serviciu pentru altele componente. Dac componentul utilizeaz o anumit interfa, care este realizat de un alt component, atunci acea interfa pentru primul component este numit de import. Particularitile interfeei de import const n aceea c n diagrama de componente aceast relaie este reprezentat cu ajutorul dependenei.

9.3. Dependene
n cazul general relaia de dependen a fost examinat mai sus. Reamentim c relaia de dependen nu este asociere, dar este utilizat numai pentru reprezantarea faptului existenei acestei legturi, cnd modificarea unui element a modelului nflueneaz sau duce la schimbarea altui element a modelului. Relaia de dependen n diagrama de componente reprezint o linie punctir cu sgeat orientat de la client (element dependent) la surs (element independent). Relaia poate indica legturile modulelor programului la etapa de compilare i generare a codului. n alt caz dependena poate indica existena n componentul independent descrierea clasei, care sunt utilizate n componentul dependent pentru crearea obiectelor respective. n diagrama de 64

componente dependenele pot conecta componentele i interfeele de import de component, dar i diferite feluri de componente ntre sine. n primul caz se deseaneaz sgeat de la component client la interfaa de import (fig. 71). Prezena sgeii nseamn c componetul nu realizeaz interfaa respectiv, dar utilizeaz n ea procesul su de executare. n aceast diagram mai poate exista i un alt component, care realizeaz aceast interfa. De exepmplu, fragmentul diagramei de componente prezentat mai jos reprezint o informaie despre componentul cu numele main.exe dependent de interfaa de import I dialog, care la rndul su este realizat de componentul cu numele image.java. Pentru al doilea component aceai interfa este de export.

Fig. 71. Fragmentul diagrameide componente cu relaie de dependena. Observm, c de a reprezentarea al doilea component cu numele image.java n form de variant de adnotare nu este posibil, deoarece acest component realizeaz interfaa. Un alt caz de relaie de dependen n diagrama de componente este relaia ntre diferite feluri de componente (fig. 72). Prezena dependenei acestea nseamn c shimbrile n texte a programelor sau librrii dinamice vor duce la schimbarea componentului. n urma cruia caracterul schimbrii poate fi indicat adugtor.

Fig. 72. Reprezentarea grafic relaie de dependena ntre componente. i n sfrit, n diagrama de componente pot fi reprezentate relaiile de dependen ntre componente i realizate n ele clase. Aceast informaie este foarte imporatant pentru coordonarea reprezentrii logice i fizice a modelelor sistemului. Shimbrile n structura descrierii claselor poate duce la schimbarea componentului. Mai jos este prezentat fragmentul dependenei, cnd un anumit component depinde de clase respective.

Fig. 73. Reprezentarea frafic dependenei ntre componente i clase. 65

n cazul dat, din diagrama de componente nu reiese c clasele sunt realizate de acest component. Dac este necesar de subliniat c care-va component realizeaz anumite clase, atunci pentru indicarea componentului este utilizat simbolul n form de dreptunghi. n urma cruia dreptunghiul componentului divizeaz n dou seciuni cu linia orizontal. Secia de sus este utilizat pentru notarea numelui componentului, iar cea de jos pentru indicarea informaiei adugtoare (fig. 74).

Fig. 74. Reprezentarea grafic a componentului cu informaia adugtoare despre clase realizate. nuntrul simbolului a componentului sunt indicate alte elemente a notaiei grafice, aa clase ca (componentele nivelului de tip) sau obiectele (componentele nivelului de exemplare). n acest caz simbolul componentului este reprezentat n aa fel ca s ntroduc aceste simboluri adugtoare. De exemplu, componentul realizat mai jos (fig. 75) este exemplar i realizeaz trei obiecte.

Fig. 75. Reprezentarea grafic a componentului nivelului de exemplar, ce realizeaz obiectele. Obiecte, care se afl n componentul exemplar sunt reprezentate ntr-un fel de elementele depuse n simbolul componentului dat. Aa fel de depunere nseamn c efectuarea componentului duce la executarea obiectelor respective. Cu alte cuvimte, existena componentului n timpul executrii programului a aprozivionat existena i posibil accesul tuturor obiectelor depuse. Ce se refer la accesul acestor obiecte, el poate fi adugtor specificat cu ajutorul specificatorul de vizibilitate ca i la vizibilitile pachetelor. Sensul vizibilitii poate fi diferit pentru diferite feluri de pachete. De exemplu, pentru pachetul programului cu text iniial vizibilitatea nseamn posibilitatea ntroducerii schimbrii n texte a programului respectiv cu recompilarea lor. Pentru componente cu codul programului executabil vizibilitatea poate caracteriza posibilitatea de a executa componentul respectiv sau chemarea operaiilor sau metodelor realizate n el.

9.4. Recomandri la construirea diagramei de componente

Elaborarea diagramei de componente presupune utilizarea informaiei despre reprezentarea logic a modelului sistemului, dar i despre particularitile realizrii ei fizice. nainte de elaborare este necesar de a face o decizie despre alegerea programei de calcul i sistemului operaional, dup care s realizm sistema, dar i alegerea bazelor de date concrete i limbajelor de programare. 66

Dup ce putem duce la structurizarea general a diagramei de componente. n primul rnd este necesar de a hotr din care pri (fiiere) fizice va fi compus sistemul de programare. La aceast etap este necesar de a ateniona la aa fel de realizare a sistemului care va garanta nu numai posibiliatea utilizrii repetate a codului pe seama decompoziiei componentelor, dar i crearea obiectelor n urma necesitii. Merge vorba despre producerea general sistemului de programare care n mare parte depinde mult de utilizarea raional a ei de resursele de calcul. Pentru acest scop este necesar descrierea marii pri a claselor, operaiilor i metodelor lor de a scoate n librriile dinamice, lsnd n componentele de executare numai cele mai necesare fragmente pentru iniializare a codului programului. Dup structurizarea general reprezentrii fizice a sistemului este necesar de adugat modelul cu interfee i schemele bazei de date. n elaborarea interfeelor este necesar de a atrage atenia la coordonarea diferitor pri a sistemului de programare. Includerea n modelul bazelor de date presupune specificarea tabelelor i stabilirea legturilor informaionale ntre tabele. n sfrit, etapa final de construire a diagramei de componente este legat de stabilirea i depunerea n diagram a nteraciunilor ntre componente i relaiile de realizare. Aceste relaii trebuie desfurate n toate aspectele importante a realizrii fizice a sistemului, ncepnd cu particularitile compilrii textelor iniiale a programului i terminnd cu ndeplinirea unor pri a programului la etapa de executare. Pentru aceast scop pot fi utilizate diferite feluri de reprezentare grafic a componentelor. n timpul alaborrii programului trebuie de inut cont de principiile generale a crerii modelului n limbajul UML. i anume, n primul rnd este necesar de a utiliza componente i stereotipuri, care exist n limbajul UML. Pentru majoritatea proiectelor tipice aceast trus nu este suficient pentru reprezentarea componentelor i dependenelor ntre ele. Dar dac proiectul conine anumite elemente fizice, descrierea crora lipsete n limbajul UML, atunci trebuie de utilizat mecanizmul de extindere. i anume, utilizarea stereotipuri adugtoare pentru unele componente netipice sau valorile marcate pentru precizarea unor caracteristici a lor. n sfrit trebuie de atras atenia c diagrama de componente este, ca regul, elaborat cu diagrama de plasare, care reprezint informaia despre deplasarea fizic a componentelor sistemului a programei dup nodurile ei. Particularitile construirii diagramei de plasare vor fi definite n capitolul urmtor.

10. Diagrama de plasare (deployment diagram)

Reprezentarea fizic a sistemului de programare nu poate fi plin, dac lipsete informaia despre programele i metode de realizare a calcului. Dac este elaborat un simplu program, care poate fi executat local la calculatorul utilizatorului fr ntroducearea echipamentelor periferice i resurselor, atunci n acest caz nu este necesitate de a elabora diagrame adugtoare. Totui, n timpul elaborrii anexei situaia este alta. n primul rnd, sistemele de programare compuse pot fi realizate n form de reea n diferite programe de calcul i tehnologiile de accesare la baze de date. Prezena reelei locale corporative necesit rezolvarea totalitii de probleme adugtoare despre amplasarea raional a componentelor dup nodurile reelei, ce definesc producerea general a sistemului de programare.

67

n al doilea rnd, integrarea sistemului de programare cu Internet definete necesitatea deciziei ntrebrilor adugtoare n timpul proiectrii sistemului n aa fel ca asigurarea securitii, ... i accesul stabil la informaie pentru clienii corporativi. Aceste aspecte depind mult de realizarea proiectului n form de noduri a sistemului, care exist fizic, aa ca serveri, centralele funcionale, brandmauzeri, canale de conectare i pstrrile de date. Tehnologiile de acces i de manipulare a datelor n schema general clientul-server tot trebuie de amplasat baze de date mair n diferite segmente de reelei corporative, copierea lor rezerv, arhivarea pentru garantarea producerii necesare a sistemului. Aceste aspecte tot necesit reprezentarea vizual pentru specificarea particularitilor tehnologice i de programare a realizrii arhitecturei distribuite. n capitolul 9 prima diagrama reprezentrii fizice este diagrama de componente. Al doilea form de reprezentarea fizic sistemului de programare este diagrama de plasare. Ea este utilizat pentru reprezentarea general configurarei i topologiei sistemului de programare distribuite i conine repartizarea componentelor dup nodurile a sistemului. Pe lng c diagrama de plasare indic prezint legturile fizice rutele de transfer a informaiei ntre echipamente, utilizate n realizarea sistemului. Diagrama de plasare este specific pentru vizualizarea elementelor i componentelor a programului, ce exist numai la etapa executrii lui (runtime). n urma cruia sunt prezentate numai componente exemplare a programului, care sunt fiiere de executare sau librriile dinamice. Acele componente, care nu sunt utilizate la etapa executrii, n diagrama de plasare nu sunt indicate. Componente cu texte iniiale a programului pot fi numai n diagrama de componente. n diagrama de rezervare nu sunt indicate. Diagrama de rezervare conine reprezentarea grafic a procesorilor, echipamentelor, proceselor i legturilor ntre ele. n deosebire de diagrama reprezentrii logice, diagrama de plasare este un sistem unic, deoarece trebuie s desfoare toate particularitile realizrii ei. Aceast diagram finalizeaz procesul pentru un sistem concret de programare i elaborarea ei este ultima etapa de specificarea a modelului. Aadar, enumrm scopurile, ce sunt urmrite n timpul elaborrii diagramei de plasare:

De definit distribuirea componentelor a sistemului dup nodurile fizice. De prezentat legturile fizice ntre toate nodurile de realizare a sistemului la etapa de executare. De a gsi locurile nguste a sistemului i de a reconfigura topologia ei pentru atingerea producerii necesare. Pentru garantarea cerinelor diagramei de plasare se elaboreaz mpreun cu analistele a sistemului, ingineri de reele i altele. Apoi vom examena elemente din care sunt coninute diagramele de plasare.

10.1. Nod
Nodul (node) reprezint un anumit element fizic a sitemului, care are o anumit resurs de calculare. Ca resurs de calculare a nodului poate fi o valoarea electronic sau magnitioptic a memoriei sau procesorului. n ultima versiune a limbajului UML definiia nodului este extins i pot conine nu numai echipamente pentru calculare, dar i mprimant, modemuri, camere digitale, scanere i altele.

68

Adnotare Posibilitatea de a include oamenii (personal) n definiia nodului d posibilitate de a crea mijloacele limbajului UML modele a diferitor sisteme, inclusiv bisnes procese i complexe tehnice. Realizarea business logicei ntreprinderii trebuie de examinat n calitate de noduri a sitemului, subdiviziunele organizatorice, care este compus din personal. Automatizarea conducerii complexurilor tehnice trebuie de examinat ca element independent omul operator, care are posibilitate de a accepta deciziile n situaii complicate i de a purta rspunderea pentru diferite consecine a deciziilor lui. Reprezentaea grafic a nodului n diagrama de plasare este n form de cub trigonometric. Nodul are un propriu nume, care este indicat nuntrul acestui simbol grafic. Nodurile pot fi prezentate n form de tipuri (fig. 76, a), dar i n calitate de exemplare (fig. 76, b).

Fig. 76. Reprezentarea grafic a nodului n diagrama de plasare. n primul caz numele nodului este scris fr subliniere i ncepe cu majuscul. n al doilea caz numele nodului exemplar este scris n form de <numele nodului ':' numele tipului nodului>. Numele tipului nodului indic specia nodurilor, ce se afl n modelul sistemului. De exemplu, partea de aparat a sistemului poate fi compus din cte-va calculatoare, fiecare din cre corespunde nodului exemplar n model. Totui toate nodurile exemplare sunt legate cu un tip de noduri, anume nodul cu numele de tip Calculator. n desenul precedent (fig. 76, a) nodul cu numele Server se refer la tipul general i nu se concretizeaz. Al doilea nod (fig. 76, b) este nodul exemplar anonim a modelului concret a imprimantei. La fel ca n diagrama de componente reprezentarea nodurilor poate fi extins pentru includerea informaiei adugtoare despre specificarea nodului. Dac informaia adugtoare este legat cu numele nodului, atunci ea este scris mai jos de nume ca valoare marcat (fig. 77).

Fig. 77. Reprezentarea grafic a nodului exemplar cu informaie adugtoare ca valoare marcat. Dac este necesar de indicat componentele, care sunt deplasate n nodul separat, atunci pentru aceast exist dou moduri. Primul din ei d posibilitate de a mpri simbolul grafic n dou secii 69

cu linie orizontal. n seciunea cea de sus este scris numele nodului, iar n cea de jos- componente deplasate la nodul dat (fig. 78, a). Al doilea mod permite deplasarea n diagrama de plasare nodurile cu componentele depuse (fig. 78, b). Ca componente depuse pot fi numai componentele executante.

Fig. 78. Reprezentarea grafic a nodurilor exemplare cu componentele deplasate. Ca adugare la numele nodului pot fi utilizate diferite stereotipuri, care specific destinaia nodului. Dei n limbajul UML stereotipuri pentru noduri nu sunt specificate, n literatur exist urmtoarele variante: procesorul, modem, reea i altele, care pot fi specificate de elaborator. Mai mult dect att, n diagramele de plasare pot fi indicaii speciale pentru diferite echipamente fizice, reprezentarea grafic clarific destinaia sau funciile lor. Adnotare Vorbind despre reprezentri grafice adugtoare pentru nodurile diagramei de plasare au n vedere evidena lor n prezentare. De exemplu, procesorul poate fi prezenat ca un nod general (Fig. 11.1) i ca interfaa calculatorului. n mod corespunztor, consoli pot fi prezentate n mod de tastatur. Elaboratorul trebuie s aib adugtor i nsuiri creatoare.

10.2. Conexare
Pe lng reprezentarea nodurilor n diagrama de plasare sunt indicate relaiile ntre ele. n calitate de relaii sunt conectri fizice ntre noduri i dependena ntre noduri i componente, reprezentarea crora poate fi n diagramele de plasare. Conectrile sunt un fel de asociere i sunt prezentate n form de linii fr sgei. Prezena liniei indic necesitatea organizrii canalului fizic pentru schimbarea informaiei ntre nodurile respective. Caracter de conectare poate fi adugtor specificat de adnotare, indicat de valoare sau restricie. n fragmentul prezentat mai jos n diagrama de plasare (fig. 79) sunt specificate nu numai cererea la viteza de transfer a datelor n reea local cu ajutorul valorii indicate, dar i recomandarea la tehnologia fizic a realizrii conexelor n form de adnotare.

Fig. 79. Fragmentul diagramei de plasare cu conectri ntre noduri. 70

n afar de conectri n diagrama de plasare pot fi relaiile de dependen ntre nod i componentele lui. Acest caz este alternativ pentru reprezentarea componentelor depuse nuntrul simbolului al nodului, ce nu este ntodeauna comod, deoarece simbolul devine valoros. De aceea cnd exist mulimea de componente desfurate n nod, o informaie respectiv poate fi reprezentat n fel de relaie de dependen (fig. 80). Diagrama de plasare poate avea o structur mai compus, care include componentele, interfee i alte echipamente. n diagrama de plasare mai jos (fig. 81) este prezentat fragmentul reprezentrii fizice a sistemului serviciului ndreptat pentru clienii bncii. Nodurile acestui sistem sunt terminalul ndreptat (nodul - tip) i serverul bncii (nodul - exemplar).

Fig. 80. Diagrama de plasare cu relaia de dependen ntre nod i componenii desfurrii n el.

Fig. 81. Diagrama de plasare pentru sistemul serviciului ndreptat clienelor bncii. n aceast diagram de plasare este indicat dependena componentul de realizare a dialogului dialog.exe n terminalul ndreptat de la interfaa Iuthorise, realizat de componenii main.exe, care la rndul su se desfoar la nodul exemplar anonim Serverul bncii. Ultimul depinde de componentul bazei de date Clienii bncii, care de asemenea este desfurat la acest nod. Adnotarea indic necesitatea utilizrii liniei protejate de comunicare pentru schimbarea datelor n sistemul dat. Alt variant a acestei notaii a informaiei este n adugarea nodului n diagrama cu stereotipul reea inchis. Elaborarea sistemelor depuse presupune nu numai crearea codului programului, dar i coordonarea totalitii de mijloace de aparate i echipamente macanice. Ca exemplu, vom urmri fragmentul modelul de conducere a mijloacelor mecanice ndreptate de tip platformei de transport. Aceast platform este specificat pentru deplasarea n regiunele de agresiune, unde prezena omului este imposibil n urma cazurilor fizice.

71

Platforma de transport are un propriu microprocesor, camer digital, cu indicatoare de temperatur i amplasament, de asemenea dispozitiv de conducere pentru schimbarea direciei i vitezei de deplasare a platformei. Informaie de conducere i telemetric de la platform dup linii radio este transferat n centrul de conducere, dotat cu calculator de conducere, manipulatoare de conducere i un tablou mare de informaie. n microprocesor platformele sunt desfurate componentele de program pentru realizarea influenei simple de conducere la dispozitive, ce permite de a schimba discret direcia i viteza de deplasare a platformei. n calculator centrele de conducere sunt desfurate componentele de program a analizei informaiei telemetrice, care caracterizeaz starea unor echipamente a platformei i sunt realizate algoritmele conducerii deplasrii platformei. Varianta reprezentrii grafice acestui sistem de transport este prezentat n urmtoare diagrama de plasare (fig. 82).

Fig. 82. Diagrama de plasare pentru modelul sistemului de conducere a platformei de transport. Diagrama dat conine informaia general despre desfurarea sistemului i n continuare poate fi detalizat n timpul elaborrii componentelor de conducere a programului. Este evident din desen c n timpul elaborrii acestui program de plasare sunt utilizai steriotipul adugtor receptoremitor, care lipsete n descrierea limbajului UML i descriere special pentru care-va echipamente mecanice.

10.3. Recomandri la construirea diagramei de plasare

Elaborarea diagramei de plasare nncepe cu identificarea tuturor tipuri de echipamente, care sunt necesare pentru executarea de ctre sistem funciilor sale. n primul rnd sunt specificate nodurile de calculare a sistemului,ce conin memorie i/sau procesorul. n urma cruia sunt utilizate steriotipuri limbajului UML, iar n cazul de lipsirea lor, elaboratorii pot specifica stereotipurile noi. Unele cerinele la coninutul mijloacelor de aparate pot fi n forma de restricie, particulariti i valorilor marcate. Construirea urmtoare a diagramei de plasare este legat de deplasare tuturor componentelor executabile a diagramei dup nodurile sistemului. Dac unele componente executate n-au fost

72

deplasate, atunci aceast situaie trebuie s fie exclus prin introducerea n modelul nodutilor adugtori, care conin procesorul i memorie. n timpul elaborrii programelor simple, care sunt executate local n un calculator aa ca n cazul de diagrama de componente necesitatea n diagrama de plasare pot lipsi deloc. n cazurile mai compuse diagrama de plasare este construit pentru aa restricii ca:

Modelarea sistemelor de programare, ce realizeaz tehnologie de acces la datele clientserver. Pentru aa fel de sisteme este caracter divizare strict a puterilor i respectiv componentelor ntre stanii lucrtoare a clienilor i serverul bazei de date. Posibilitatea realizrii clienelor fine n terminalele sau organizarea accesului la depozitul de date duce la necesitatea preciziei nu numai topologiei sistemului,dar i la coninutul componentelor . Modelarea arhitecturilor desfurate diferite. Aceast este despre intrareelele corporative,ce conin sute de calculatoare i altor echipamentelor pereferice, care funcioneaz n diferite platforme i sub diferite sisteme operaionale. n urma cruia unele noduri sistemului acest au distana ntre sine sute de kilometre (filialele companiei). n cazul acest diagrama de plasare devine un instrument important de vizualizare topologiei generale a sistemului i controlului migraiei unor componente ntre noduri. n sfrit, sistemele cu microprocesoare, care pot funciona autonom. Aa fel de sisteme pot conine diferite echipamente adugtoare, care garanteaz autonomia funcionrii lor i rezolvarea problemelor. Pentru aceste sisteme diagrama de plasare d posibilitate de a vizualiza coninutul acestor echipamente i intreconexiunea lor n sistemul.

Ca regul, elaborarea diagramei de plasare este realizat la etapa final a OOAP, ce caracterizeaz sfiritul fazei de proiectare reprezentrii fizice. Din alt parte, diagrama de plasare poate fi construit pentru analiza sistemului respectiv cu scopul analizei i modificrii urmtoare. n urma cruia analiza presupune elaborarea acestei diagrame la etapa ei iniial ,ce caracterizeaz direcia general analizei de la reprezentarea fizic la logic. n timpul modelrii busines-proceselor diagrama de plasare n afar de calculatoare reelei corporative poate conine n calitate de noduri diferite mijloace a orgtehnicei (fax, staii multicanale de telefon). n urma cruia fiecare din echipamente respective poate funciona autonom i n structura reelei corporative. Dac este necesar de introdus n model surs de Internet, atunci n diagrama de plasare Internet reprezint norul cu numele respectiv. Aceast indicare nu este specificat n limbajul UML, totui ea este rar utilizat n timpul elaborrii modelelor a sistemelor desfurate. n sfrit este necesar de a nota o situaie important, caracter elaborrii tuturor diagramelor canonive. Dei n limbajul UML este definit notarea grafic pentru toate elemente a diagramelor canonice, metode de reprezentare grafic a unor mijloacelor instrumentale au particularitile specifice. Utilizarea CASE- mijloc instrumental duce la restricie la vizualizarea modelelor sistemelor de programare. Merge vorba despre aceea c, unele elemente a limbajului UML pot lipsi n CASE mijloace. Ieirea din aceast situaie poate fi legat ori cu alegearea altui instrument, ce susine ultimile versiuni a limbajului UML, ori simplificarea modelului la baza de tipizrii ei. n capitolul 12 care-va din aceste aspecte vor fi desfurate mai detaliat n exemplul CASE mijloace Rational Rose 98/981.

73