UML - Limbajul de Modelare Orientat pe Obiecte (PDF)

**CUPRINS** [1. Etapele principale de dezvoltare a limbajului UML 3](#etapele-principale-de-dezvoltare-a-limbajului-uml) [2. Componente de baza ale limbajului UML 5](#componente-de-baza-ale-limbajului-uml) [2.1. Structura generală a limbajului UML 7](#structura-general%C4%83-a-limbajului-uml) [2.2. Particularitatea (specificul) limbajului UML 8](#particularitatea-specificul-limbajului-uml) [*2.2.1. UML -- limbaj de vizualizare* 9](#uml-limbaj-de-vizualizare) [*2.2.2. UML -- limbaj de specificare* 9](#uml-limbaj-de-specificare) [*2.2.3. UML -- limbaj de construire* 9](#uml-limbaj-de-construire) [*2.2.4. UML -- limbaj de documentare* 10](#uml-limbaj-de-documentare) [2.3. Entităţi în UML 11](#entit%C4%83%C5%A3i-%C3%AEn-uml) [2.4. Relaţii UML 14](#rela%C5%A3ii-uml) [2.5. Diagrame UML 16](#diagrame-uml) [3. Diagarama cazurilor de utilizare (use case diagram) 17](#diagarama-cazurilor-de-utilizare-use-case-diagram) [3.1. Cazul de utilizare 17](#cazul-de-utilizare) [3.2. Actori 18](#actori) [3.3. Interfeţe 19](#interfe%C5%A3e) [3.4. Legăturile în diagrama a cazurilor de utilizare 20](#leg%C4%83turile-%C3%AEn-diagrama-a-cazurilor-de-utilizare) [*3.4.1. Relaţia de asociere* 20](#rela%C5%A3ia-de-asociere) [*3.4.2. Relaţia de extindere* 22](#rela%C5%A3ia-de-extindere) [*3.4.3. Relaţia de generalizare* 22](#rela%C5%A3ia-de-generalizare) [*3.4.4. Relaţia de tip include* 23](#rela%C5%A3ia-de-tip-include) [3.5. Exemplu de construirea diagramei cazurilor de utilizare 24](#exemplu-de-construirea-diagramei-cazurilor-de-utilizare) [4. Diagrama de clase (class diagram) 26](#diagrama-de-clase-class-diagram) [4.1. Clasa 27](#clasa) [*4.1.1. Numele clasei* 27](#numele-clasei) [*4.1.2. Atributele clasei* 28](#atributele-clasei) [*4.1.3. Operaţiile* 30](#opera%C5%A3iile) [4.2. Relaţii între clase 31](#rela%C5%A3ii-%C3%AEntre-clase) [*4.2.1. Relaţia de dependenţa* 31](#rela%C5%A3ia-de-dependen%C5%A3a) [*4.2.2. Relaţia de asociere* 32](#rela%C5%A3ia-de-asociere-1) [*4.2.3. Relaţia de agregare* 33](#rela%C5%A3ia-de-agregare) [*4.2.4. Relaţia de compoziţie* 33](#rela%C5%A3ia-de-compozi%C5%A3ie) [*4.2.5. Relaţie de generalizare* 34](#rela%C5%A3ie-de-generalizare) [4.3. Interfeţe 35](#interfe%C5%A3e-1) [4.4. Obiecte 35](#obiecte) [5. Diagrama de stări (statechart diagram) 36](#diagrama-de-st%C4%83ri-statechart-diagram) [5.1. Automate 36](#automate) [5.2. Stare 37](#stare) [*5.2.1. Numele stării* 38](#numele-st%C4%83rii) [*5.2.2. Starea iniţială* 38](#starea-ini%C5%A3ial%C4%83) [*5.2.3. Starea finală* 38](#starea-final%C4%83) [5.3. Tranziţie 38](#tranzi%C5%A3ie) [*5.3.1. Eveniment* 39](#eveniment) [*5.3.2. Condiţie gardă* 39](#condi%C5%A3ie-gard%C4%83) [*5.3.3. Expresia acţiunei* 40](#expresia-ac%C5%A3iunei) [5.4. Stare şi substare compusă 41](#stare-%C5%9Fi-substare-compus%C4%83) [*5.4.1. Substări disjuncte* 41](#subst%C4%83ri-disjuncte) [*5.4.2. Substări concurente* 42](#subst%C4%83ri-concurente) [6. Diagrama de activităţi (activity diagram) 44](#diagrama-de-activit%C4%83%C5%A3i-activity-diagram) [6.1. Starea activităţii 44](#starea-activit%C4%83%C5%A3ii) [6.2. Tranziţii 45](#tranzi%C5%A3ii) [6.3. Partiţii 47](#parti%C5%A3ii) [6.4. Obiecte 49](#obiecte-1) [7. Diagrama de secvenţă (sequence diagram) 50](#diagrama-de-secven%C5%A3%C4%83-sequence-diagram) [7.1. Obiecte 50](#obiecte-2) [*7.1.1. Linia de viaţă al obiectului* 51](#linia-de-via%C5%A3%C4%83-al-obiectului) [7.2. Focus control 51](#focus-control) [7.3. Mesaje 51](#mesaje) [*7.3.1. Stereotipuri de mesaje* 52](#stereotipuri-de-mesaje) [7.4. Restricţii temporale în diagrama de secvenţă 52](#restric%C5%A3ii-temporale-%C3%AEn-diagrama-de-secven%C5%A3%C4%83) [8. Diagrama de colaborare (collaboration diagram) 53](#diagrama-de-colaborare-collaboration-diagram) [8.1. Obiecte 53](#obiecte-3) [*8.1.1. Multiobiect* 55](#multiobiect) [*8.1.2. Obiect activ* 55](#obiect-activ) [*8.1.3. Obiect compus* 56](#obiect-compus) [8.2. Legături 56](#leg%C4%83turi) [*8.2.1. Tipuri de legături* 57](#tipuri-de-leg%C4%83turi) [8.3. Colaborare 58](#colaborare) [*8.3.1. Diagrama de colaborare la nivel de specificare* 59](#diagrama-de-colaborare-la-nivel-de-specificare) [9. Diagrama de componente (component diagram) 60](#diagrama-de-componente-component-diagram) [9.1. Componente 61](#componente) [*9.1.1. Numele componentului* 62](#numele-componentului) [*9.1.2. Feluri de componente* 63](#feluri-de-componente) [9.2. Interfeţe 64](#interfe%C5%A3e-2) [9.3. Dependenţe 64](#dependen%C5%A3e) [9.4. Recomandări la construirea diagramei de componente 66](#recomand%C4%83ri-la-construirea-diagramei-de-componente) [10. Diagrama de plasare (deployment diagram) 67](#diagrama-de-plasare-deployment-diagram) [10.1. Nod 68](#nod) [10.2. Conexare 70](#conexare) [10.3. Recomandări la construirea diagramei de plasare 72](#recomand%C4%83ri-la-construirea-diagramei-de-plasare) 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 sfîrşitul anilor 1980, cînd diferiţi cercetători şi programatori propuneau diverse metode de analiza şi proiectare obiect orientată (APOO). În perioada între anii 1989-1994 numărul total al limbajelor de modelare cele mai cunoscute a crescut de la 10 pîna la mai mult decît 50. Mulţi utilizatori au avut dificultăţi serioase la alegerea limbajului de APOO, fiindcă nici unul din limbajele propuse nu satisfăcea toate cerinţele către modelarea (construirea modelelor) sistemelor compuse. Acceptarea unor metode şi notaţii grafice în calitatea de standarde (IDEF0, IDEF1X) nu a putut să schimbe situaţia de concurenţă acută între limbaje la începutul anilor 90ci. Spre mijlocul anilor 1990 unele metode au fost esenţial perfecţionate şi au obţinut semnificaţie proprie la rezolvarea diferitor probleme APOO. Cele mai cunoscute în acea perioadă au devenit: - Metoda lui Grady Booch, care este cunoscută ca Booch sau Booch'91, Booch Lite (mai tîrziu -- Booch'93). - Metoda lui James Rumbaugh, cunoscuta ca Object Modeling Technique -- OMT (mai\ tîrziu -- OMT-2). - Metoda lui Ivar Jacobson, cunoscuta ca Object-Oriented Software Engineering -- OOSE. Fiecare metodă a fost orientată spre susţinerea unor etape aparte ale APOO. De exemplu, metoda OOSE conţinea mijloace de prezentare a cazurilor de utilizare, care au semnificaţie esenţială la etapa analizei cerinţelor în timpul proiectării business-aplicaţiilor. Metoda OMT-2 era cea mai potrivită pentru analiza proceselor de prelucrare a datelor în sistemele informaţionale. Metoda Booch'93 era cea mai aplicabilă la etapele de proiectare şi exploatare a diferitor sisteme program. Istoria dezvoltării limbajului UML începe în luna octombrie a anului 1994, cînd Grady Booch şi James Rumbaugh din Rational Software Corporation au început să lucreze împreună asupra unificării 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 unificării celor mai avantajoase trăsături ale lor. Proiectul acestei aşa zise metode unificate (Unified Method) versiunea 0.8 a fost pregătit şi publicat în luna octombrie anului 1995. În toamna aceluiaşi an a aderat la ei şi Iv. Jacobson, tehnologul principal al companiei Objectory AV (Suedia), cu scopul integrării metodei sale OOSE cu celelalte două precedente. Începînd lucrul spre unificarea metodelor, G. Booch, J. Rumbaugh şi Iv. Jacobson au formulat următoarele cerinţele către limbajul de modelare. El trebuie: - Să ofere posibilitatea de a modela nu numai produse soft dar şi clase mai largi de sisteme şi business-aplicaţii cu utilizarea noţiunilor obiect orientate. - Să asigure în mod evident legatura între noţiunile de bază ale modelelor nivelurilor conceptual şi fizic. - Să asigure scalarea modelelor, ce este o calitate importantă a sistemelor complicate. - Să fie clar pentru analişti şi programatori, de asemenea trebuie să fie susţinut de către mijloace instrumentale speciale, realizate pe diferite platforme de calculator. Dezvoltarea sistemei de notaţii pentru APOO s-a dovedit să nu fie asemănătoare cu dezvoltarea unui nou limbaj de programare. În primul rînd era necesar de rezolvat două probleme: 1. Notaţia dată trebuie să includă în ea şi specificarea cerinţelor? 2. Este necesar de extins notaţia dată pîna la nivelul limbajului de programare vizuală? În al doilea rînd era necesar de găsit echilibrul între expresivitatea şi simplitatea limbajului. Pe o parte, o prea simplă notaţie limitează sfera problemelor potenţiale care pot fi rezolvate cu ajutorul sistemului de notaţii corespunzător. Pe de altă parte, o prea complicată notaţie creaza dificultăţi adăugatoare pentru studierea şi aplicarea de către analişti şi programatori. În cazul unificării metodelor existente este necesar de a lua în consideraţie interesele specialiştilor, care au experienţă de lucru cu aceste metode, fiindcă introducerea schimbărilor semnificative poate atrage după sine neînţelegerea şi respingerea din partea utilizatorilor altor metode. Pentru a exclude opunerea neevidentă din partea unor specialişti, este necesar de a lua în considerarţie interesele păturilor largi ale utilizatorilor. În continuare lucrul asupra limbajului de modelare unificat (Unified Modeling Language) a trebuit să ia în consideraţie toate aceste circumstanţe. În această periodă suportul elaborării limbajului UML devine unul din scopurile consorţiului OMG (Object Management Group). Cu totate că consorţiul 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 capătat statutul de a doua direcţie 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 unificării şi standartizării limbajului UML. Eforturile lui G. Booch, J. Rumbaugh şi Iv. Jacobson au dus la apariţia primelor documente care conţineau 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 către diferite categorii de specialişti. Primele păreri şi reacţii în ce priveşte limbajul UML indicau necesitatea de a-l completa cu notaţii şi construcţii. Compania Rational Software împreună cu cîteva organizaţii, care au manifestat dorinţa de a aloca resurse pentru elaborarea definiţiei stricte a versiunii 1.0 limbajului UML, au fondat consorţiul partenerilor UML în care iniţial au intrat aşa 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 notaţiei încă mai stricte şi precise, ceea ce a dus la apariţia versiunii 1.0 limbajului UML. Particularitatea limbajului UML constă în aceea ca limbajul defineşte metamodelul semantic, dar nu modelul unei interfeţe concrete şi metodele de prezentare şi realizare a componentelor. În prezent toate întrebările elaborării în continuare a limbajului UML sunt concentrate în limitele consorţiului OMG. Grupul corespunzător de specialişti asigură publicarea materialelor care conţin descrierea versiunilor următoare ale limbajului UML şi a propunerilor RFP de standardizarea. O următoare etapă de dezvoltare a acestui limbaj s-a terminat în martie anului 2003 cind consorţiul OMG a publicat descrierea limbajului UML 2.0. Istoria elaborării şi dezvoltării următoare al limbajului UML este reprezentată grafic în fig. 1. Pe baza tehnologiei UML Microsoft, Rational Software şi alţi furnizori de medii de dezvoltare a sistemelor de programare au elaborat modelul informaţional 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 interfeţei standarde între mijloacele de elaborare şi mijloacele de modelare vizuala. **Fig. 1.** Istoria dezvoltării 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 raspîndite limbaje şi medii de programare, aşa 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 consideraţie multe idei şi metode de frunte se poate de aşteptat că versiunile următoare ale limbajului UML vor fi influenţate ş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 fără o redefinire nucleului său. 2. Componente de baza ale limbajului UML ======================================== Limbajul UML reprezintă limbajul de destinaţie generală al modelării 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ă destinaţie. Acest limbaj conţine cele mai bune calităţi 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 număr de noţiuni principale care pot fi studiate şi aplicate de către majoritatea programiştilor şi elaboratorilor cunoscuţi cu metodele de analiza şi proiectarea obiect orientate. Totodată noţiunile de bază pot fi combinate şi extinse în asa fel că specialiştii modelării orientate pe obiecte pot elabora de sinestătător modele ale sistemelor complexe în diferite domenii de aplicare. Utilizarea constructivă a limbajului UML este bazată pe inţelegerea principiilor comune de modelare a sistemelor complexe şi a particularităţilor procesului de analiza şi proiectarea obiect orientate. Alegerea mijloacelor expresive pentru construcţia modelelor ale sistemelor complexe stabileşte din vreme problemele care pot fi rezolvate cu ajutorul utilizării 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 legătura cu executarea de către sistem a funcţiilor sale sau cu destinaţia lui de baza. Totodată toate detalii de importanţa secundară sunt omise pentru ca procesul de analiza şi cercetare a modelului primit să nu fie foarte complicat. Alt principiu de construcţie a modelelor ale sistemelor complexe este principiul de multi-modele. Acest principiu reprezintă afirmaţia 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 număr de reprezentări (views) legate reciproc, fiecare din ele reflectînd adecvat un anumit aspect de comportare sau structura a sistemului. Totodată cele mai generale reprezentări ale unui sistem complex sunt considerate reprezentări statice şi dinamice care la rîndul lor pot fi divizate în alte reprezentări 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 reprezentărilor stabilite. Totodată modelul iniţial sau elementar al unui sistem complex are reprezentarea cea mai generala (meta-reprezentare). Un astfel de model se construieşte la etapa iniţială de proiectare şi poate să nu conţină multe detalii şi aspecte ale sistemului modelat. **Fig. 2** Schema comună legăturilor modelelor şi reprezentărilor ale unui sistem complex în procesul APOO. În aşa fel, un proces APOO poate fi reprezentat ca o coborîre pe nivele: de la cele mai generale modele şi reprezentări de nivel conceptual spre reprezentări mai particulare şi detaliate ale nivelului logic şi fizic. Totodată la fiecarea etapă a procesului APOO modelele date sunt completate consecvent cu un număr din ce în ce mai mare de detalii ce le premite să reflecte mai adecvat diferite aspecte ale realizării unui anumit sistem complex. Schema comună legăturilor modelelor APOO este reprezentată în fig. 2. 2.1. Structura generală a limbajului UML ---------------------------------------- UML constă din două parţi interdependente: - Semantica limbajului UML reprezintă un careva metamodel, care defineşte sintaxa abstracta şi semantica noţiunilor modelării orientate pe obiecte în limbajul UML. - Notaţia limbajului UML reprezintă o notaţie grafica pentru reprezentarea vizuală a semanticii limbajului UML. Sintaxa abstractă şi semantica limbajului UML sunt descrise cu ajutorul unei anumite submulţimi de notaţii ale UML. În completare la aceasta, notatia UML descrie corespunderea sau reprezentarea notaţiei grafice în semantica noţiunilor de baza. În aşa fel din punct de vedere funcţional aceste două părţi completează una pe altă. Totodată semantica limbajului UML este descrisă pe baza unui metamodel care are trei reprezentări aparte: sintaxa abstractă, reguli de construcţia corectă a expresiilor şi semantica. Cercetarea semanticii limbajului UML presupune un careva stil semiformal de redare, care unifica limbaje naturale şi formale pentru reprezentarea noţiunilor de baza şi regulilor de extindere a lor. Semantica se defineşte pentru două tipuri de modele de obiecte: de structura şi de comportare. Modelele de structură, cunoscute ca modele statice, descriu structura entităţilor sau a componentelor unui sistem inclusiv clase, interfeţe, atribute şi relaţii. Modelele de comportare, numite uneori dinamice, descriu comportarea sau funcţionarea obiectelor unui sistem, inclusiv metodele lor, colaborarea între ele, şi procesul de schimbare a stărilor unor componente aparte şi al sistemului întreg. Pentru rezolvarea unui diapazon atît de larg de probleme de modelare este elaborată semantica destul de completă pentru toate componentele notaţiilor grafice. Cerinţele semanticii limbajului UML sunt concretizate la construirea anumitor tipuri de diagrame. Notaţia limbajului UML include în sine descrierea elementelor semantice care pot fi utilizate la construcţia diagramelor. Descriere formală a limbajului UML se bazeaza pe careva structură ierarhică comună a reprezentărilor de model care constă din patru nivele: - Meta-metamodelul - Metamodelul - Modelul - Obiectele utilizatorului Nivelul de meta-metamodel crează o bază iniţială pentru toate reprezentări de metamodele. Destinatia principală a acestui nivel constă în definiţia limbajului pentru specificarea metamodelului. Meta-metamodelul defineşte modelul limbajului UML la cel mai înalt nivel de abstractizare şi cea mai compactă descriere a lui. Din altă parte, meta-metamodelul poate specifica cîteva metamodele ce permite atingerea flexibilităţii potenţiale de includere a noţiunilor adăugătoare. Ca exemple de notaţii ale acestui nivel pot fi meta-clasa, meta-atribut, meta-operaţie. Semantica meta-metamodelului nu intra în descrierea limbajului UML. Aceasta face limbajul UML mai simplu pentru studiere, fiindcă nu cere cunoaşterea 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 decît cel precedent, fiindcă semantica lui ale noţiunilor de bază este mai dezvoltată. Toate noţiunile de bază ale limbajului UML sunt noţiunile nivelului de metamodel. Exemple de aceste notiuni sunt clasa, atributul, operaţia, 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 noţiunile lui metamodel concretizîndu-le cu privire la situaţia dată. Acest nivel este pentru descrierea informaţiei despre un domeniu concret (de obiecte).Ca exemple a acestui nivel pot fi numele cîmpurilor ale bazei de date proiectate, de exemplu, numele şi prenumele angajatului, vîrsta, postul, adresa, numărul de telefon. Totodată noţiunile date sunt utilizate numai ca nume ale atributelor informaţionale corespunzătoare. Descrierea semanticii limbajului UML presupune cercetarea noţiunilor 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, construcţie ş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ă noţiune a domeniului de obiecte. UML este elaborat în aşa fel că să poată satisface cerinţele către modelarea oricărui sistem începînd cu sisteme informaţionale de dimensiunea unei întreprinderi pîna la Web-aplicaţii distribuite şi sisteme integrate în timp real. UML este un limbaj expresiv care permite cercetarea sistemei din toate punctele de vedere care au legătura cu elaborarea şi desfăsurarea ei următoare. Necătind la numărul mare de posibilităti expresive, acest limbaj rămîne simplu pentru intelegere şi utilizare. Cercetarea UML vom incepe cu modelul lui conceptual care conţine trei elemente de bază: construcţii de bază, reguli, care determină felul în care construcţii pot fi combinate, şi unele mecanizme comune ale limbajului. Cu totate că UML nu depinde de realitate modelată este mai bine să fie utilizat cînd procesul de modelare este bazat pe cercetarea descrierei textuale a proceselor executate în domeniu de obiecte şi sistemul are arhitectura strict evidenţiată. În asa fel limbajul este ideal pentru Unificarea procesului de elaborare. Ca şi oricare limbaj, UML constă dintr-un dicţionar şi reguli care permit combinarea cuvintelor de intare şi primirea construcţiilor cu sens. În limbajul de modelare dicţionarul şi regulile sunt orientate spre reprezentarea conceptuală şi fizică ale unui sistem. Limbajul de modelare, aşa cum este UML, este un mijloc standard pentru elaborarea «desenelor» produsului soft. Modelarea este necesară pentru inţelegerea sistemului. În mod obişnuit un model unic nu poate fi de ajuns. Din contra, pentru inţelegerea practic a oricărui sistem netrivial este necesară dezvolaterea unui număr enorm de modele interdependente. În aplicare către sisteme de program aceasta înseamnă necesitatea unui limbaj cu ajutorul căruia din toate punctele de vedere poate fi descrisă arhitectura unui sistem pe parcursul ciclului de dezvoltare. Dictionarul şi regulile unui aşa 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 aşa 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. ### *2.2.1. UML -- limbaj de vizualizare* Trăsătura caracteristica a majorităţii programiştilor este faptul că gîndurile despre realizarea proiectului sunt echivalente scrierei codului pentru acest proiect. Dacă gîndim despre proiectul înseamnă că îl codificăm, 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 aşa fel este plină de neplăceri. Mai întîi schimbarea părărilor despre modelul proiectat se poate numai atunci cînd toţi participanţii se exprimă în acelaşi limbaj. Aceasta înseamnă ca compania D-stră n-ar putea să angajeze un programist excelent în C dacă el utilizează Delphi! Sau noul angajat n-ar putea să inţeleagă despre ce merge vorba. În al doilea rînd nu putem să inţelegem aspectele de program al unui sistem fără modelul respectiv marginele căruia nu intră în cadrul limbajului textual de programare. De exemplu rolul ierarhiei claselor se poate de inţeles studiind codul fiecărei clase, dar de inţeles toată structura este foarte greu. Analogic cercetarea codului unui sistem nu permite să aveţi o imagine completă despre distribuirea fizică sau despre migraţia obiectelor în aplicaţii Web. În al treilea rînd dacă analistul de sistem al companiei D-stre niciodată n-a creat modelurile proiectate în formă clară toată informaţia va fi pierdută daca analistul va fi atras de firma concurentă. În cel mai bun caz rezultatele analizei acestui analist vor fi restabilite parţial reieşind 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. Sfîrşitul primei probleme. Unele trăsaturi 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 fără ajutorul unui limbaj de programare. UML este un limbaj grafic ce permite rezolvarea acestei probleme (a doua problemă). În sfîrşit modelul clar uşurează comunicarea, ce însemană că a treia problemă nu se mai pune. ### *2.2.2. UML -- limbaj de specificare* În contextul dat prin specificare subînţelegem construirea modelelor precise şi complete. UML permite specificarea tuturor soluţiilor importante care se referă la analiza, proiectarea şi realizarea în procesul elaborării 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 noţiuni care sunt uşor reprezentate grafic aşa şi sunt transformate (incluse) în UML, dar acele care mai bine sunt decrise în codul sursei se transformă cu ajutorul limbajului de programare. Aşa 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 realizării existente. Această proiectare inversă nu prezintă ceva neobişnuit. Daca n-am codificat informaţia î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 generării directe a codului şi proiectării indirecte permite a lucra în prezentare grafică şi textuală dacă programele instrumentale asigură coordonare între aceste două prezentări al proiectului. În afară de reflectare directă datorită expresivităţii şi uniformităţii limbajul UML permite executarea modelelor, imitarea colaborării sistemului şi controlul sistemului care funcţionează. ### *2.2.4. UML -- limbaj de documentare* Compania ce lansează programul soft pe lînga codul sursă produce şi alte artefacte, inclusiv: - cerinţe către sistem; - arhitectura; - proiectul; - codul iniţial; - planuri de proiecte; - teste; - prototipuri; - versiuni s.a. În dependenţa de metodica elaborării stabilită unele lucrurile se execută mai formal decît altele. Artifactele menţionate mai sus sunt necesare pentru administrarea, aprecierea rezultatelor şi ca mijloc de comunicare între membrii colectivului în timpul elaborării proiectului şi desfăşurării lui. UML permite rezolvarea problemei de documentare a arhitecturii sistemului, oferă limbajul pentru definirea formală a cerinţelor către sistemul şi către teste, defineşte mijloace pentru modelarea lucrurilor pe etapa planificării proiectului şi administrării versiunelor. Limbajul UML este destinat în primul rînd elaborării sistemului de programare. Utilizarea lui este cu mult mai eficienta în urmatoarele sfere: - sisteme informaţionale; - servicii bancare şi financiare; - telecomunicaţie; - transport; - industria de apărare, aviaţie, cosmonautic; - sisteme comerciale; - electronica medicală; - ştiinţa; - 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 pacienţelor în spitale, proiectarea aparaturii. Pentru inţelegerea limbajului este necesar de cunoscut principiile de bază a structurii acestui limbaj. Sunt numai trei principii şi limbajul parcă constă din trei părţi: construcţii de bază ale limbajului, reguli de colaborare şi anumite mecanizme comune. Ştiind toate aceste ideile vom putea citi modelele în UML şi să le proiectăm, desigur că vom începe cu cele mai simple. Pe parcursul obţinerii experienţei de lucru cu limbajul vom învăţa să utilizăm posibilităţile limbajului mai avansate. Dicţionarul limbajului înclude trei tipuri de construcţii de bază: - entităţi -- abstracţii ce sunt elemente de bază a modelului; - relaţii -- legături între entităţi; - diagrame ce grupează interesele entităţilor şi relaţiilor. 2.3. Entităţi în UML -------------------- În UML sunt patru tipuri de entităţi: - de structură; - de comportament; - de grupare; - de adnotare. Entităţi sunt elementele OO de bază ale limbajului. Cu ajutorul entităţilor este posibilă crearea modelelor corecte. Entitătile de structură sunt substantivele în modelurile ale limbajului UML. De regulă ele reprezintă părţi statice ale modelelor care corespund elementelor conceptuale şi fizice ale sistemului. Există şapte varietăţi de entităţi de structură: *Clasa (class) este o descriere a unei totalităţi de obiecte cu atribute, operaţii, relaţii şi semantica comună. Grafic o clasa se reprezintă printr-un dreptunghi în care se specifică numele, atributele şi operaţiile clase, exemplu este arătat în fig. 3.* **Fig. 3.** Clasa. *Interfaţa (interface) este o totalitate de operaţii care definesc servicii oferite de clasă sau componentă. În diagrame interfaţa se reprezintă printr-un cerc etichetat cu numele interfeţei, fig. 4. Interfaţa foarte rar există aparte -- de obicei ea este legată cu clasa sau componenta care o realizează.* **Fig. 4.** Interfaţa. *Colaborarea (collaboration) defineşte o interacţiune, ea reprezintă o totalitate de roluri şi alte elemente care produc un efect cooperativ şi care nu se aduce numai la suma termenilor unei adunări. Grafic colaborarea se reprezintă printr-o elipsă cu linie întreruptă, interiorul căreia conţine numai numele colaborării, fig. 5.* **Fig. 5.** Colaborare. *Cazul de utilizare (use case) este o descriere a consecutivităţii de acţiuni î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 căreia se conţine denumirea cazului de utilizare, fig. 6.* **Fig. 6.** Caz de utilizare. *Clasa activă (active class) se numeşte o clasă obiectele căreia sunt antrenate în unul sau mai multe procese sau în şiruri (threads) şi deaceea ele pot iniţia o acţiune administrativă. Grafic o clasă activă se reprezintă ca şi o clasă simplă, dar se limitează cu un dreptunghi cu marginile groase şi care conţine numele, atributele şi operaţiile clasei date, fig. 7.* **Fig. 7.** Clasa activă. *Componenta (component) este o parte fizică a sistemului, care corespunde unui anumit set de interfeţe şi asigură realizarea lui. Grafic o componentă se reprezintă printr-un dreptunghi cu anexe, care de obicei conţine numai numele componentei, fig. 8.* **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 informaţiei şi care există în timpul funcţionării unui produs soft. Grafic pentru reprezentarea nodului se utilizează cubul care conţine numele nodului, fig. 9.* **Fig. 9.** Nod. Şapte elemente de bază enumerate: clase, interfete, colaborări, cazuri de utilizare, clase active, componente şi noduri sunt entităţile principale de structură care pot fi utilizate în diagramele UML. Există şi alte varietăti ale entităţilor de structură: actori, semnale, utilite (tipurile de clase), procese şi şiruri (tipuri de clase active), aplicaţii, documente, fişiere, biblioteci, pagini şi tabele (tipuri de componente). Entităţile de comportament (behaviour things) sunt părţile dinamice ale modelului UML. Acestea sunt verbele limbajului care descriu comportarea modelului în timpul şi în spaţiu. Există numai doua tipuri de entităţi de comportament. *Interacţiunea (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 interacţiunii se descrie atât o operaţie cât şi comportarea unui set de obiecte. Interacţiunea presupune un şir de alte elemente ca mesaje, consecutivitate de acţiuni (comportare, iniţializată de către mesaje) şi legături (între obiecte). Grafic mesajul se reprezintă print-o săgeată deasupră careia se indică numele mesajului, fig. 10.* **Fig. 10.** Mesaj. *Automatul (state machine) este un algoritm de comportare care defineşte o succesiune de stări prin care trece un obiect sau o interacţiune pe parcursul ciclului de viaţa răspunzînd la diferite evenimente şi reacţiile lui la aceste evenimente. Cu ajutorul automatului se descrie comportarea unei clase sau a unei colaborări de clase. Cu automatul este legat un şir de alte elemente: stări, tranziţii de la o stare la altă, evenimente care sunt entităti ce iniţiază tranziţii şi tipuri de actiuni - reacţii la tranziţii. Grafic o stare se reprezintă printr-un dreptunghi cu colţuri rotungite care conţine numele stării sau posibil şi stările intermediare, fig. 11.* **Fig. 11.** Stare. Interacţiunile şi automatele sunt entităţile principale de comportament care pot fi utilizate în diagramele UML. Semantic ele sunt legate cu diferite elemente de structură, în primul rînd cu clase, cooperări şi obiecte. Entităţile de grupare sunt părţile 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 entităţile de structură, de comportament şi alte entităţi de grupare. Spre deosebire de componentele care există real, în timpul execuţiei unui program, pachetele au caracter pur conceptual, adică ele există doar în timpul elaborării. Pentru reprezentarea unui pachet se utilizează notaţia unei mape cu semn de carte care conţine deseori numai numele şi doar uneori şi conţinutul, fig. 12.* ![](media/image10.png) **Fig. 12.** Pachet. Entităţile de adnotare sunt părţile explicative ale unui model UML. Acestea sunt comentarii destinate descrierii adiţionale, explicaţiei sau observaţiei către 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 constrângerilor, legate de un element sau de un grup de elemente. Grafic o remarcă se reprezintă printr-un dreptunghi cu colţul de sus din dreapta îndoit şi care conţine 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 constrângeri care pot fi reprezentate sub formă de text formal sau neformal. Există şi variante ale acestui element, de exemplu cerinţe care descriu comportarea dorită a unui sistem din punct de vedere exterior modelului. 2.4. Relaţii UML ---------------- In limbajul UML sunt definite patru tipuri de relaţii: - Dependenţa - Asocierea - Generalizarea - Realizarea Aceste relaţii sunt construcţii principale de legare în UML şi sunt utilizate pentru construirea modelelor corecte. *Dependenţa (dependency) este o relaţie semantică între două entităţi astfel încît modificarea uneia din ele, a celei independente, poate influenţa semantica celeilalte, dependente. Grafic pentru reprezentarea dependenţei se utilizeaza o linie întreruptă, deseori cu săgeată care poate conţine o etichetă.* ![](media/image12.png) **Fig. 14.** Dependenţa. *Asocierea (association) este o relaţie de structură care descrie o totalitate de legături, prin legătură se subînţelege 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ă lînga linia ce corespunde asocierei. Grafic asocierea se reprezintă printr-o linie (care uneori se termină cu o săgeată sau este etichetată), fig. 15.* **Fig. 15.** Asocierea. O formă specială sau caz particular al relaţiei de asociere se socoate relaţia agregării care la rîndul său are o formă specială -- compoziţia. *Agregare (aggregation) este o anumită relaţie între întreg şi părţile lui componente. Această relaţie are un sens fundamental pentru descrierea sistemelor complexe fiindcă se utilizează pentru reprezentarea legăturilor «parte-întreg». Dezvăluind structura interioară a sistemului, relaţia de agregare arată din ce elemente constă sistemul şi cum elementele sunt legate. Din punct de vedere al modelului părţile aparte ale sistemului pot fi socotite ca elemente şi ca subsisteme care la rîndul lor pot crea componente sau subsisteme. Grafic relaţia de agregare se reprezintă printr-o linie continuă, unul din capetele căreia reprezintă un romb gol. Acest romb arată «întregul» şi restul - «părţile», fig. 16.* **Fig. 16.** Agregare. Relaţia *compoziţie* este cazul particular al relaţiei de agregare. Această relaţie este destinată prezentării formei speciale a relaţiei «parte-întreg» în care părţile componente sunt în interiorul părţiii întregi. Specifica legăturii între ele constă în aceea că părţile componente nu pot exista fără partea întreagă, adică cu distrugerea întregului se destrug şi părţile componente a lui. Grafic relaţia de compoziţie se reprezintă printr-o *linie continuă, unul din capetele căruia reprezintă un romb haşurat. Acest romb arată clasa-compoziţie sau «întregul» şi restul sunt «părţile» lui, fig. 17.* **Fig. 17.** Compoziţie. *Generalizarea (generalization) este o relaţie de tip «specializare/generalizare» în urma căreia un obiect al elementului specializat (descendent) poate substitui obiectul elementului generalizat (părinte). Descendentul (child) moşteneşte structura şi comportamentul părintelui (parent) său. Grafic relaţia de generalizare se reprezintă printr-o linie cu o săgeată goală care arată părinte, fig. 18.* **Fig. 18.** Generalizarea. *Realizarea (realization) este o relaţie semantică între clasificatori în care un clasificator defineşte un «contract», iar celălat garantează îndeplinirea lui. Relaţia de realizare se întîlneşte în cazurile următoare: între interfeţe şi clase sau componente care realizează aceste interfeţe, şi între cazuri de utilizare şi colaborări care le realizeză. Relaţia de realizare se reprezintă printr-o linie întreruptă cu o săgeată goală, ca ceva intermediar între relaţiile generalizare şi dependenţa, fig. 19.* ![](media/image17.png) **Fig. 19.** Realizare. 2.5. Diagrame UML ----------------- În cadrul limbajului UML toate reprezentările modelului unui sistem complex sunt fixate în calitate de construcţii speciale grafice care deseori sunt reprezentate sub formă de graf conex cu noduri -- entităţi şi muchii -- relaţii. Î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) - Diagrame de stări (statechart diagram) - Diagrame de activităţi (activity diagram) - Diagrame de interacţiune (interaction diagrams) - Diagrame de secvenţă (sequence diagram) - Diagrame de colaborare (collaboration diagram) - Diagrame de realizare (implementation diagrams) - Diagrame de componente (component diagram) - Diagrame de plasare (deployment diagram) Lista acestor diagrame şi denumirilor respective este canonica în caz dacă diagramele reprezintă partea integrantă a notaţiei grafice a limbajului UML. Mai mult decît atât, procesul APOO este strîns legat de procesul construirii acestor diagrame. Totodată o totalitate de diagrame construite în aşa fel este suficientă în caz dacă diagramele conţin informaţia necesară pentru realizarea proiectului unui sistem complex. Fiecare din aceste diagrame detalizează şi concretizează diferite reprezentări 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 iniţial 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 varietăţi ale unui model logic care reflectă aspectele dinamice ale procesului de funcţionare a unui sistem complex. Diagramele de realizare sunt destinate reprezentării fizice a componentelor sistemului complex şi de aceea sunt atribuite modelului fizic. Modelul integrat al unui sistem complex în notaţia UML (fig. 20) se reprezintă ca totalitatea diagramelor enumerate mai sus. **Fig. 20.** Model al unui sistem complex în notaţia UML. 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 iniţial către 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 destinaţia functională a sistemului sau cu alte cuvinte descrie ceea ce sistemul va executa în procesul său de funcţionare. Diagrama cazurilor de utilizare reprezintă un model iniţial conceptual al unui sistem în procesul de proiectare şi exploatare.** Proiectarea a unei diagrame a cazurilor de utilizare urmăreşte scopurile următoare: - determinarea limitelor comune şi a contextului domeniului de modelare la etapele iniţiale de proiectare a unui sistem; - formularea cerinţelor comune către comportare funcţională a sistemului proiectat; - elaborarea modelului iniţial conceptual al unui sistem pentru detalierea de mai tîrziu în forma modelelor logice şi fizice; - pregătirea documentărei iniţiale pentru interacţiunea elaboratorilor unui sitem cu clienţii şi utilizatorii. Esenţa acestei diagrame constă în faptul că: sistemul proiectat se reprezintă ca o colecţie de entităţi şi actori care colaborează cu sistemul cu ajutorul aşa 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 acţiune pentru sistemul proiectat în aşa mod, cum îl determină colaboratorul. La rîndul său, use case-ul este creat pentru descrierea serviciilor pe care sistemul le oferă actorului. Cu alte cuvinte fiecare caz de utilizare defineşte o colecţie de acţiuni 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 notaţie grafică pentru prezentarea cazurilor de utilizare concrete, actorilor, poate şi a unora interfeţe şi pentru prezentarea legăturilor între aceste elemente. Totodată componente aparte ale diagramei pot fi incluse într-un dreptunghi, care semnifică sistemul proiectat în întregime. Trebuie de specificat că legăturile acestui graf pot fi de numai anumite tipuri de interacţiuni între actori şi cazuri de utilizare, care împreună descriu servicii şi cerinţe funcţionale către sistemul modelat. 3.1. Cazul de utilizare ----------------------- Structura sau elementul standart al limbajului UML -- caz de utilizare se foloseşte pentru specificarea particularităţilor comune ale comportării unui sistem sau a oricărei alte entităti în domeniul de lucru fără cercetarea structurii interne a acestei entităţi. Fiecare caz de utilizare determină o succesiune de acţiuni care trebuie sa fie executate de către sistemul poiectat la colaborarea lui cu actorul corespunzător. Diagrama cazurilor de utilizare poate fi completată cu text explicativ, care desfăşoară sensul sau semantica componentelor ce o compun. Acest text se numeşte adnotare sau scenariu. Cazul de utilizare aparte se notează cu o elipsă în interiorul căreia se conţine 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 entităţi fără desfăşurarea structurii interne a acestei intităţi. În calitate de aşa entitate poate fi un sistem iniţial 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ă către anumită entitate. Serviciul care este iniţializat la cererea utilizatorului reprezintă o succesiune terminată de acţiuni. Aceasta înseamnă că după ce sistemul va termina prelucrarea cererii utilizatorului el (sistemul) trebuie sa se intoarcă în starea iniţială în care este gata pentru a indeplini cererile următoare. Cazurile de utilizare descriu nu numai colaborarea între utilizatori şi entităţi, dar şi reacţia entităţii la primirea anumitor mesaje de la utilizatori şi asupra percepţiei acestor mesaje în afară entităţii. Cazurile de utilizare pot include (conţine) descrierea specificaţiilor modurilor de realizare a serviciului şi a diferitor situaţii excepţionale, aşa cum este prelucrarea corectă a erorilor unui sistem. Mulţimea cazurilor de utilizare în total poate determina toate aspecte posibile comportării aşteptate a unui sistem. Pentru comoditate mulţimea cazurilor de utilizare poate fi considerată ca un pachet aparte. Din punct de vedere sistemo-analitic cazurile de utilizare pot fi folosite pentru specificarea cerinţelor externe către sistemul proiectat şi pentru specificarea comportării funcţionale a sitemului deja existent. Exemple de cazuri de utilizare pot fi acţiunile următoare: verificarea stării contului curent al clientului, intocmirea comenzii la procurarea mărfii, obţinerea informaţiei 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ă posibilităţile lui funcţionale pentru atingerea anumitor scopuri şi pentru rezolvarea problemelor particulare. Totodată actorii sunt utilizaţi pentru notarea mulţimii 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. Notaţia grafică standardă a unui actor în diagramă este «omuleţul» sub care se indică numele actorului (fig. 21). ![](media/image19.jpeg) **Fig. 21.** Actor. În unele cazuri actorul poate fi notat ca dreptunghiul clasei cu cuvîntul-cheie «actor» şi cu elementele comune ale clasei. Numele actorilor trebuie să fie scrise cu litere majuscule şi trebuie să respecte recomandările la utilizarea numelor pentru tipurile şi clasele modelului. Totoadată simbolul actorului aparte leagă descrierea corespunzătoare a actorului cu un anumit nume. Numele actorilor abstracţi, aşa cum şi a altor elemente abstracte în limbajul UML, se recomandă de notat în italic. Ca exemplu de actori pot fi: clientul unei bănci, angajatul unei bănci, vînzătorul unui magazin, managerul secţiei de vînzare, pasagerul unui avion, conductorul unui auto, administratorul unui hotel, celularul şi alte entităţi, care au legătură cu modelul conceptual care corespunde domeniului de lucru. Actorii sunt utilizaţi pentru modelarea entităţilor exeterne sitemului de entităţi proiectat, care acţionează reciproc cu sistemul şi pe care îl utilizeză în calitate de utilizatori separaţi. În calitate de actori pot fi şi alte sisteme, subsisteme ale sistemului proiectat sau clase aparte. Este important să intelegem că actorul defineşte o anumită mulţime 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. Interfeţe -------------- Interfaţa (interface) specifică parametrii modelului care sunt vizibili din afară fără indicarea structurii lor interne. În limbajul UML interfaţa este clasificatorul care caracterizeză numai o parte limitată a comportării unei entităţi modelate. Referitor la diagrama cazurilor de utilizare interfeţele definesc o totalitate de operaţii ce asigură serviciile necesare sau funcţionalitatea pentru actorii. Interfeţele nu pot conţine nici atribute, nici stări, nici asocieri dirijate. Ele conţin numai operaţii fără indicarea specificaţiilor de realizare a lor. O interfaţă este formal echivalentă clasei abstracte fără atribute şi metode numai cu prezenţa operaţiilor abstracte. În diagrama cazurilor de utilizare o interfaţă este reprezentată ca un cerculeţ mic lîngă care este indicat numele lui. (fig. 22, a). În calitatea de nume poate fi un substantiv, ce caracterizeaza informaţia corespunzătoare sau serviciu (de exemplu, «sirena», «camera video»), dar mai des este oricare rînd de text (de exemplu, «sensor», «interpolare către 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 interfeţelor în diagrama cazurilor de utilizare. Simbolul grafic al unei interfeţe aparte în diagramă poate fi conectat cu cazul de utilizare ce îl susţine cu o linie neîntreruptă (continuă). Linia neîntreruptă în acest caz indică faptul că cazul de utilizare legat cu interfaţa trebuie să realizeze toate operaţiile necesare pentru această interfaţă, sau poate şi mai mult (fig. 23, a). În afară de aceasta, interfeţele pot fi legate cu cazurile de utilizare cu o linie întreruptă cu o săgeată (fig. 23, b), ce înseamna că cazul de utilizare specifică numai cel serviciu, care este necesar pentru realizarea interfeţei date. ![](media/image21.png) **Fig. 23.** Reprezentarea grafică a legăturilor între interfeţe şi cazuri de utilizare. Din punct de vedere sistemo-analitic interfaţa nu numai separă specificaţia operaţiilor unui sistem de la realizarea lor, dar şi defineşte limetele comune ale sistemului proiectat. Ulterior interfaţa poate fi specificată cu indicarea acelor operaţii care specifică un aspect de colaborare al sistemului. În acest caz el se reprezintă în forma de dreptunghi cu cuvînt-cheie «interface» în secţia de nume, cu secţia de atribute goala şi cu secţia de operaţii completată. Dar aşa fel de reprezentare grafică se utilizează în diagrama claselor sau în diagrame ce caracterizează comportarea sistemului modelat. Importanţa interfeţelor constă în faptul că ele definesc noduri de joncţiune în sistemul proiectat, ce este necesar pentru organizarea lucrului colectiv asupra proiectul. Mai mult decît atît, specificaţia interfeţelor contribuie la modificarea «uşoară» la trecerea la soluţii tehnologice ale unui sistem deja existent. În acest caz schimbării este supusă numai realizarea operaţiilor, dar nu funcţionalitatea sistemului. Aceasta asigură compatibilitatea versiunilor următoare de program cu cele iniţiale la folosirea tehnologiei în spirală de creare sistemelor de program. 3.4. Legăturile în diagrama a cazurilor de utilizare ---------------------------------------------------- Între componentele diagramei cazurilor de utilizare pot să existe diferite legături 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ă către cîteva servicii ale sistemului dat. La rîndul său un anumit caz de utilizare poate să colaboreze cu mai mulţi actori, pentru care el acordă serviciul său. Trebuie de observat că două cazuri de utilizare definite pentru aceeaşi entitate nu pot colabora unul cu altul, fiindcă fiecare din ele descrie o variantă propie terminală de utilizare a acestei entităţi. Mai mult decît atât, cazurile de utilizare întotdeauna presupun careva semnale şi mesaje pentru colaborarea cu actorii în afara limetelor sistemului. În acelaşi timp pot fi definite alte metode de colaborare între elemente în înteriorul sistemului. În limbajul UML sunt cîteva tipuri standarde de relaţii între actori şi cazuri de utilizare: - relaţia de asociere (association relationship) - relaţia de extindere (extend relationship) - relaţia de generalizare (generalization relationship) - relaţia de cuplare (include relationship) Totodată proprietăţile generale ale cazurilor de utilizare pot fi reprezentate prin trei metode diferite, şi anume cu ajutorul relaţiei de extindere, generalizare şi cuplare. ### *3.4.1. Relaţia de asociere* Relaţia de asociere este o noţiune fundamentală în limbajul UML şi mai mult sau mai puţin se utilizează la crearea tuturor modelelor grafice în forma diagramelor canonice. Cu privire la diagrama cazurilor de utilizare relaţia 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 aşa mod această relaţie stabileşte ce rol joacă actorul la colaborarea cu exemplarul cazului de utilizare. În diagrama cazurilor de utilizare precum şi în alte diagrame relaţia de asociere se notează cu o linie neîntreruptă între actor şi cazul de utilizare. Această linie poate să aibă condiţii suplementare, de exemplu, numele şi multiplicitatea (fig. 24). **Fig. 24.** Reprezentare grafică relaţiei de asociere între acotr şi caz de utilizare. Multiplicitatea (multiplicity) asocierei se indică lînga notaţia 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 notaţie specifică în forma de una sau mai multe cifre şi posibil simbolul special «\*». Pentru diagrama cazurilor de utilizare mai răspîndite sunt patru forme de înscriere a multiplicităţii relaţiilor de asociere: - Număr întreg nenegativ (inclusiv cifra 0) este destinat indicaţiei multiplicităţii care este strict fixată pentru elementul corespunzător asocierii. În acest caz cantitate de exemplare a actorilor sau cazurilor de utilizare, ce pot fi şi elemente ale relaţiei de asociere, întocmai este egală cu numărul indicat. Ca exemplu a acestei forme de înregistrare a multiplicităţii relaţiilor de asociere este indicarea multiplicităţii «1» pentru actorul «Clientul băncii» (fig. 24). Această înregistrare înseamna că fiecare exemplar al cazului de utilizare «Perfectarea creditului pentru clientul băncii» poate să aibă în calitate de element propriu un singur exemplar de actor «Clientul băncii». 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 bănci. - Două numere întregi nenegative, separate cu două puncte şi scrise în forma: «primul număr..al doilea număr». Această înregistrare în limbajul UML corespunde notaţiei pentru o mulţime 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 înţeleasă ca o mulţime de numere întregi nenegative care sunt în ordinea crescatoare: {numar\_1, numar\_1+1, numar\_1+2,..., numar\_2}. Evident că primul număr trebuie să fie strict mai mic decît al doilea număr în sens aritmetic, totodată primul număr poate fi egal cu 0. Ca exemplu a acestei forme de înregistrare a multiplicictăţii asocierii -- «1..5». Această înregistrare înseamna că cantitatea de exemplare ale acestui component care pot fi şi elemente ale acestei asocieri, este egală unui număr preliminar necunoscut din mulţimea numerelor întregi {1, 2, 3, 4, 5}. Această situaţie are loc cînd în calitate de actor este clientul băncii, dar în calitate de caz de utilizare este procedura deschiderii contului în bancă. Totodată cantitatea de conturi ale fiecărui client în această banca, reieşind din consideraţii tactice, poate fi nu mai mult decît 5. Aceste consideraţii tocmai şi sunt cerinţele exterioare sistemului proiectat şi sunt definite de către client la etapele iniţiale de APOO. - Două simboluri separate cu doua puncte. Totodată primul dintre ele este un număr întreg nenegativ sau 0, iar al doilea este simbolul special «\*». Aici simbolul «\*» înseamnă un număr arbitrar întreg nenegativ, valoarea căruia este necunoscută la momentul înregistrării 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 număr anticipat necunoscut din mulţimea numerelor întregi {2, 3, 4}. - Simbolul «\*», care este prescurtarea înregistrării intervalului «0..\*». În acest caz cantitatea de exemplare ale acestui component al relaţiei de asociere poate fi oricare număr întreg nenegativ. Totodată 0 înseamnă că pentru careva exemplare ale componentului corespunzător această relaţie de asociere poate nici să nu aibă loc. Ca exemplu acestei forme de înregistrare poate fi cercetată multiplicitatea asocierei pentru cazul de utilizare «Întocmire creditului pentru clientul băncii» (fig. 24). În acest caz «\*» înseamnă fiecare client aparte al acestei bănci poate întocmi pentru sine cîteva credite, totodată numărul lor comun este necunoscut şi nelimitat. Unele clienţi 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. Relaţia de extindere* Relaţia de extindere defineşte interconexiunea exemplarelor cazului de utilizare cu cazul general, proprietăţile căruia sunt definite pe baza modului de uniune a exemplarelor date. În metamodelul relaţie de extindere este directă şi indică care condiţii concrete pot fi utilizate pentru unele exemple unui anumit caz de utilizare, definite pentru extinderea cazului de utilizare dat. Dacă are loc relaţie de extindere de la cazul de utilizare A la cazul de utilizare B, acest lucru înseamnă că proprietăţile exemplarului cazului de utilizare B pot fi adăugate datorită proprietăţilor extinse a cazului de utilizare A. Relaţia de extindere între cazurile de utilizare reprezintă o linie punctată cu săgeată (cazul relaţiei de dependenţă), directă de la acel caz de utilizare, care reprezintă extinderea cazului de utilizare iniţial. Această linie cu săgeată este marcată cu cuvîntul „extend" („extinde"), fig. 25. ![](media/image23.png) **Fig. 25. Exemplu de reprezentare grafică a relaţiei de extindere între cazurile de utilizare.** Relaţia de extindere indică acel fapt că unul din cazurile de utilizare poate fi conectat la comportamentul său care-va comportament adăugător, definit pentru un alt caz de utilizare. Relaţia dată include o anumită condiţie şi exilări la puncte de extensie în cazul de utilizare de bază. Pentru alocarea extinderii este necesar de a executa o anumită condiţie a relaţiei date. Exilări la puncte de extensie definesc acele locuri în cazul de utilizare de bază în care trebuie să fie pusă extinderea respectivă în timpul executării condiţiei. Unul din cazurile de utilizare pot fi extinderea pentru cîteva cazuri de bază şi pot avea ca extinderi proprii încă cîte-va alte cazuri. Cazul de utilizare de bază poate fi adăugător independent de la alte extensii. Semantica relaţiei de extensie este definită în felul următor. Dacă exemplarul cazului de utilizare execută anumită consecvenţă de acţiuni, care defineşte comportamentul lui şi în urma căruia există un punct de extensie la alt exemplar a cazului de utilizare, care este unul din primele puncte de extensie a cazului iniţial, atunci controlează condiţia relaţiei date. Dacă condiţia este executată, consecvenţa iniţială de acţiuni extinde datorită includerea acţiunii altui exemplar a cazului de utilizare. Trebuie de menţinut, că condiţia relaţiei de extensie este controlată numai o dată în timpul exilării 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. Relaţia de generalizare* Relaţia de generalizare este folosită pentru indicarea faptului că care-va caz de utilizare A poate fi generalizat la cazul de utilizare B. În urma căruia, cazul A va fi cazul special cazului B. În urma căruia cazul B se numeşte părinte relativ A, iar cazul A -- descendent relativ cazului de utilizare B. Este nevoie de menţionat, că descendentul moşteneşte toate proprietăţile şi comportamentul părintelui său şi poate avea proprietăţile şi comportamentul său adăugător. Grafic relaţia dată este reprezentată cu linia întreagă cu săgeată în forma de triunghi nehaşurat, care indică cazul de utilizare părinte (fig. 26). Această linie cu săgeată are un nume specific -- săgeata „generalizare". **Fig. 26.** Exemplu de reprezentare grafică a relaţiei de generalizare între cazuri de utilizare. Relaţia de generalizare între cazurile de utilizare este folosită în acele cazuri cînd este necesar de indicat că cazul de utilizare derivat conţine toate atributele şi particularităţile comportamentului cazurilor de bază. În urma căruia cazurile de utilizare derivate pot participa în relaţii cazurilor de bază. În urma sa cazurile derivate pot avea proprietăţi noi de comportament, care nu au cazurile de utilizare de bază, dar şi de a preciza sau modifica proprietăţile de comportament moştenite. Relativ cu relaţia dată un variant de utilizare poate avea cîte-va cazuri de bază. În acest caz se realizează moştenirea multiplă a proprietăţilor şi comportamentului cazurilor de bază. Din altă parte un caz de utilizare poate fi părinte pentru cîte-va cazuri de utilizare derivate, ce corespunde caracterului taxonometric relaţiei de generalizare. Între actori aparte de asemenea poate exista relaţia de generalizare. Această relaţie este directă şi indică faptul că specializarea unor actori este relativ cu alţii. De exemplu, relaţia 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 proprietăţile lui. În acest caz actorul B este părinte relativ cu actorul A, iar actorul A este descendentul actorului B. În urma căruia actorul A are posibilitatea de joacă a aceleeaşi mulţimi de roluri ca şi actorul B. Grafic relaţia dată este reprezentată cu săgeata de generalizare, adică cu linia întreagă cu săgeată în formă de triunghi nehaşurat, care indică părintele actorului (fig. 27). ![](media/image25.png) **Fig. 27. Exemplu de reprezentare grafică a relaţiei de generalizare între actori.** ### *3.4.4. Relaţia de tip include* Relaţia 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. Relaţia dată este relaţie binară îndrepatată, în acel sens că perechea de exemplare a cazului de utilizare întodeauna se află la locul ei în relaţia de tip include. Semantica acestei relaţii este definită în felul următor. Cînd exemplarul primului caz de utilizare în timpul executării ajunge la punctul de includere în consecutivitatea comporatamentului exemplarului al doilea a cazului de utilizare, exemplarul primului caz de utilizare execută consecutivitatea acţiunilor, care definesc comportamentul exemplarului al doilea a cazului de utilizare, după ce continuă executarea acţiunilor comportamentului său. În urma căruia se presupune că dacă exemplarul primului caz de utilizare poate include cîteva exemplare a altor cazuri de utilizare, acţiunile lor trebuie să se sfîrşească într-un anumit moment, după ce trebuie să continue executarea acţiunilor î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 realizaţiei căruia sunt ascunse şi pot fi liber împărţite între cîte-va cazuri de utilizare incluse. Mai mult, cazul de bază poate depinde numai de rezultatele executării comportamentului inclus în el, sar nu de la structura cazurilor incluse în el. Relaţia de tip include orientată de la cazul de utilizare A la cazul de utilizare B indică că fiecare exemplar al cazului A include proprietăţi funcţionale stabilite pentru cazul B. Aceste proprietăţi specializează comportamentul cazului respectiv A în diagrama dată. Grafic relaţiile date sunt indicate cu linia punctată cu săgeată (cazul relaţiei de dependenţă), îndreptate de la cazul de utilizare de bază la cazul ce este inclus. În urma căruia linia cu săgeata este indicată cu cuvîntul-cheie „include", (fig. 28). **Fig. 28. Exemplu de reprezentare grafică a relaţiei 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 mărfurilor după catalog, care poate fi utilizat în timpul creării sistemelor informaţionale respective. În calitate de actori a sistemului dat pot fi două subiecte, unu din care este vînzător, iar altul cumpărător. Fiecare din actori interacţionează cu sistemul de vindere a mărfurilor după catalog şi este utilizatorul lui, adică ambele se adresează la servisul respectiv „A perfecta comanda de cumpărare a mărfii". Este evedent din cerinţele 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). ![](media/image27.png) **Fig. 29. Diagrama cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a mărfurilor după catalog.** Valorile divizibilităţilor în diagrama dată reflectă regulile de bază sau logica de formare a cerinţelor la vinderea mărfurilor. Conform regulilor respective un vînzător poate participa în formarea a cîtor-va comenzi, în acelaşi timp fiecare comandă poate fi formată numai de un singur vînzător, care are responsabilitatea pentru corectitudinea formării lui şi respectiv va avea răsplată pentru formarea dată. Din altă parte, fiecare cumpărător poate forma cîteva comenzi şi în acelaşi timp fiecare comandă trebuie să fie formată la un singur cumpărător, care va avea drepturile de proprietate la marfă după achiziţionarea ei. Etapul următor în diagrama dată este „A perfecta comanda de cumpărare a mărfii" poate fi precizat pe baza întroducerii a patru cazuri de utilizare adăugătoare. Acest lucru este evident din analiza mai detaliată a procesului de vindere a mărfii, ce permite de alege ca servicii separate acele acţiuni ca asigurarea cumpăratorului cu informaţia despre marfă, coordonarea condiţiilor de plată şi comandarea mărfii de la depozit. Evident că acţiunile indicate desfăşoară comportamentul cazului de utilizare iniţial şi anume concretizarea lui şi de aceea între ele v-a exista relaţia de tip include. În cazul nostru catalogul cu mărfuri poate fi comandat de cumpărător sau vînzător cînd apare necesitatea de a alege marfa şi precizarea detaliilor de vindere. Corect este reprezentat serviciul „Cererea catalogului cu mărfuri" 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ă relaţia de tip includ şi extend. **Fig. 30. Variantul mai detaliat a diagramei cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a mărfurilor după catalog.** Diagrama cazurilor de utilizare de mai sus, la rîndul său poate fi mai detaliată pentru precizarea mai adîncă, ce se cere de la sistemul de comandă şi concretizarea detaliilor pentru realizarea următoare. Detalizarea poate fi executată pe baza indicării relaţiilor adăugătoare de tipul relaţiei „generalizarea-specializarea" pentru componentele diagramei deja existente. În sistemul de vindere a mărfurilor poate avea valoarea independentă şi proprietăţile specifice o categorie independentă de mărfuri -- calculatoare. În acest caz în diagramă poate fi adăugat un caz de utilizare „Perfectarea comenzii de achiziţionare a calculatorului" şi cu actori „Cumpărator de calculatoare" şi „Vînzător de calculatoare", care sunt legate cu componentele corespunzătoare a diagramei relaţiei de generalizare (fig. 31). ![](media/image29.png) **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 proiectări, scopul căruia este de reprezentarea totalităţii de cereri la comportamentul sistemului proiectat. Specificaţia de cereri la sistemul proiectat în formă de diagramă a cazurilor de utilizare reprezintă un model independent, care se numeşte 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. Notaţia claselor în limbajul UML este simplă şi clară pentru toţi. O notaţie asemănătoare 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ă. Notaţia limbajului UML oferă multe posibilităţi pentru reflectarea informaţiei suplimentare (operaţii abstracte sau clase, stereotipuri, metode comune şi particulare, interfeţe detaliate, clase parametrizate). Totodată este posibilă utilizarea reprezentării grafice pentru asocieri şi proprietăţile lor specifice, astfel cum sunt relaţiile de agregare, cînd ca părţi 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 programării OO. Diagrama de clase poate reflecta diferite legături între entităţile domeniului de obiecte (obiecte şi subsisteme) şi descrie structura lor internă şi tipurile de relaţii. În această diagramă nu este menţionată informaţia despre aspectele temporare ale funcţionării sistemului. Din acest punct de vedere diagrama de clase este dezvoltarea ulterioară a modelului conceptual al sistemului proiectat. Diagrama de clase reprezintă un graf cu noduri -- elemente de tip «clasificatori» care sunt legate prin diferite tipuri de relaţii de structură. Trebuie de menţionat că diagrama de clase poate conţine interfeţe, pachete, relaţii şi chiar exemplare, aşa ca obiecte şi legături. Prin diagrama de clase se subînţelege modelul structural static al sistemului proiectat, de accea diagrama de clase deseori se socoate o reprezentare grafică a legăturilor structurale ale modelului logic al sistemului care sunt independente şi invariante în timp. 4.1. Clasa ---------- *Clasa* (class) în limbajul UML defineşte totalitatea de obiecte care au aceeaşi structură, comportament şi relaţii cu obiectele din alte clase. Grafic o clasă se reprezintă printr-un dreptunghi care poate fi divizat de linii orizontale în secţiuni, fig. 3. Elementul obligătoriu în notaţia clasei este numele lui. Pe etapele iniţiale ale elaborării diagramei, clase aparte pot fi notate prin dreptunghiuri simple cu indicaţia numelui clasei respective. Pe parcursul elaborării componentelor diagramei descrierea claselor este completată cu atribute şi operaţii. Se presupune că varianta finală a diagramei conţine descrierea completă a claselor care constă din cele trei secţiuni. Uneori în notaţia claselor se utilizează a patra secţiune suplementară în care se indică informaţia semantică de caracter informativ şi se indic situaţiile excepţionale. Dacă secţiunea atributelor şi operaţiilor clasei nu este completată, în notaţia clasei ea se evidentiază cu o linie orizontală pentru a deosebi clasa de alte elemente ale limbajului UML. Exemple de notaţii grafice ale claselor în diagrama de clase sunt arătate î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 poziţia. Pentru clasa «Fereastră» (fig. 32, b) sunt indicate numai operaţiile, secţiunea de atribute este lăsată necompletată. Pentru clasa «Contul» (fig. 32, c) suplementar este indicată secţiunea de excepţii -- refuz de la prelucrarea cartelei bancare expirate (nevalabile). **Fig. 32.** Exemple de notaţii grafice ale claselor în diagrame. ### *4.1.1. Numele clasei* Numele clasei trebuie să fie unic în cadrul pachetului, care este descris de către o totalitate de diagrame de clase. Numele se indică în prima secţiune de sus a dreptunghiului. În completare la regula generală de denumire a elementelor în limbajul UML numele clasei se scrie în centrul secţiunii cu caracter semigros (bold) şi trebuie să inceapă cu majuscula. Se recomandă în calitate de nume a claselor sa fie utilizate substantivele scrise fără spaţii. Este necesar de menţionat că numele claselor formează dicţionarul domeniului de obiecte pentru APOO. În prima secţiune a notaţiei clasei pot fi referinţe la modelele (şabloanele) standarte sau la clasele abstracte de la care este formată clasa dată şi respectiv de la care clasa moşteneşte proprietăţile şi metodele. În această secţiune poate fi indicată informaţia despre elaboratorul clasei date şi starea elaborării, încă pot fi indicate şi alte proprietăţi comune ale acestei clase care au legătura cu alte clase ale diagramei sau cu elementele standarde ale limbajului UML. Ca exemple de nume ale claselor pot fi aşa substantive ca: «Angajatul», «Compania», «Conducătorul», «Clientul», «Vînzătorul», «Managerul», «Oficiu» ş.a. care au legătură cu domeniul de obiecte proiectat şi cu destinaţia funcţională a sistemului proiectat. Clasa poate să nu aibă exemplare sau obiecte. În acest caz clasa devine abstractă, şi pentru notaţia denumirii acestei clase se utilizează caractere italice. În limbajul UML este adoptată o inţelegere (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 conţine numele clasei în acest caz va fi urmatoarea: \::\. 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 următor: «Banca::Cont». ### *4.1.2. Atributele clasei* În a doua secţie a dreptunghiului de clasă se înscriu atributele lui sau prorietăţile. În limbajul UML standardizarea înscrierii atributelor de clasă se supune regulelor sintactice. Fiecărui atribut de clasă îi corespunde rîndul 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 văzut din altă clasă de pachet, în care este stabilită diagrama. - Simbolul «\#». înseamnă atributul cu regiunea de vizibilitate de tip protecţie (protected). Atributul cu această regiune de viyibilitate nu poate fi accesat sau văzut pentru toate clase în afară de subclasele acestui clas. - În sfîrşit, simbolul «--» atributul cu regiunea de vizibilitate tipului privat. (private). Atributul cu această regiune de vizibilitate nu poate fi accesat sau văzut pentru toate clasele fără excepţie. Specificatorul de vizibilitate poate fi omis. În acest caz nu este present, pur şi simplu înseamnă că vederea acestui atribut nu este indicată. Această situaţie diferă de înţelegerile de bază în limbile de tradiţionale programare, cînd nu este prezent specificatorul de vizibilitate este tratat ca «public» sau «privat». Numele atributului prezintă aliniat de text, care este folosită în calitate de identificator a atributului corespunzător şi de aceea trebuie să fie unică în clasa corespunzătoare. Numele atributului este unic, un element obligator al însemnării sintaxice al atributului. Ca exemplu de multiplicitate al atributelor putem vedea următoarele variante: - \[0..1\] înseamnă că, multiplicitatea atributului poate primi semnificaţia 0 sau 1. În acest caz 0 înseamnă că semnificaţia pentru acest atribut nu este prezentă. - \[0..\*\] înseamnă că, multiplicitatea atributului poate primi orice semnificaţie 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 semnificaţie pozitivă întreagă mai mult sau egală cu 1. - \[1..5\] înseamnă că, multiplicitatea atributului poate primi orice semnificaţie din numerele: 1, 2, 3, 4, 5. - \[1..3,5,7\] înseamnă că, multiplicitatea atributului poate primi orice semnificaţie din numerele: 1, 2, 3, 5, 7. - \[1..3,7.. 10\] înseamnă că, multiplicitatea atributului poate primi orice semnificaţie din numerele: 1, 2, 3, 7, 8, 9, 10. - \[1..3,7..\*\] înseamnă că, multiplicitatea atributului poate primi orice semnificaţie din numerele: 1, 2, 3, de asemenea orice semnificaţie pozitivă întreagă mai mult sau egală cu 7. Dacă multiplicitatea atributului nu este specificată, atunci după starea iniţială voloarea ei este egală cu 1..1, adică exact 1. Tipul atributului prezintă o expresie, semantica căruia este definită după limbajul specificaţiei al modelului corespunzător. În notaţii 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 rîndul textului, care are un sens în limita pachetului sau modelului, la care are atitudinea clasa dată. Sublinierea rîndului atributului înseamnă că acest atribut corespunzător poate avea o submulţime de valori din oarecare domeniu al valorilor atributului, definită de tipul lui. Aceste valori pot fi considerate ca trusă de notiţe cu acelaşi 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 cîteva forme diferite, dintre care fiecare prezintă un dreptunghi. Ca alt exemplu poate fi atribut în formă de numărul\_contului:Integer, ce poate însemna pentru obiect Colaborator prezenţa submulţimii de conturi, valoarea totală cărora 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ă conţină toate exemplarele clasei, care vor fi create, fără excepâie. Această valoare este considerată ca valoare iniţială a atributului, care nu poate fi reiniţializată în continuare. Absenţa aliniatului -- proprietatea de bază se tratează în felul următor, valoarea atributului corespunzător 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 funcţie definită în oarecare organizaţie. Din altă parte, înscrierea atributului dat în formă de salariu:Currency = = {\$500} înseamnă alt ceva, şi anume -- în timpul formării a unui nou exemplar Colaborator (angajarea la lucru unui nou colaborator) pentru el salariul de \$500 este stabilit automat. Totuşi, pentru careva colaboratori pot fi făcute excepţii, cum ar fi în creştere sau descreştere, ce ar trebui fi prevăzut în program. ### *4.1.3. Operaţiile* În a treia secţie a dreptunghiului de clasă se înscriu operaţii sau metodele clasei. *Operaţia* (operation) prezintă un anumit serviciu, care prezintă fiecare exemplar al clasei după anumită cerinţă. Totalitatea de operaţii caracterizează un aspect funcţional în comportamentul clasei. Notaţia operaţiei clasei în limbajul UML este la fel standartizată şi este subordonată de careva regulli sintactice. În urma acesteia fiecare operaţie clasei corespunde un rînd aparte, care este compus din specificator de vizibilitate al operaţiei, numele operaţiei, expresiei de tipul valoarei returnată de opearaţia şi posibil, aliniat -- proprietate operaţiei date: \\(lista de parametri): \{aliniat - proprietate} Specificator de vizibilitate ca şi în cazul atributelor clasei, poate primi unul din trei valori posibile şi în mod corespunzător este specificat cu un simbol special. Simbolul «+» înseamnă operaţia cu specificator de vizibillitate de tip public(public). Simbolul «\#» înseamnă operaţia cu specificator de vizibilitate de tip protecţie(protected). În sfîrşit, simbolul «--» este utilizat pentru identificarea operaţiei cu regiunea de vizibilitate de tip privat (private). Specificator de vizibilitate pentru operaţie poate fi absent. În acest caz absenţa lui înseamnă că vizibilitatea operaţiei nu este indicată. În locul însemnării grafice convenţionale de asemenea poate înscrie un cuvînt -- cheie corespunzător: public, protected, private. Numele operaţiei prezintă aliniat de text, care este utilizată ca identificator al operaţiei corespunzătoare şi de aceea trebuie să fie unică în mediul clasei date. Numele atributului este un element unic obligator în indicarea sintactică operaţiei. Operaţia, care nu poate schimba starea sistemului şi în mod corespunzător nu are nici un efect suplimentar, este specificat cu aliniat -- proprietate «{interpelare}» («{query}»). În caz contrar operaţia poate schimba starea sistemului, deşi nu sunt garanţii că ea va face acest lucru. Lista parametrilor formate şi tipul de valoare redusă pot fi nespecificate. Specificator de vizibilitate atributelor şi operaţiilor pot fi indicate de un semn sau simbol special, care sunt utilizate pentru prezenţa modelelor grafice în careva mijloace de instrumente. Numele operaţiilor la fel ca şi a atributelor, sunt scrise cu minuscule, iar tipurile lor cu majuscule. În urma căruia o parte obligatorie al aliniatului de text al operaţiei este prezenţa numelelui şi parantezelor rotunde. Ca exemplu al înscrierei operaţiei pot fi următorii specificatori al operaţiilor: - +a crea() -- pot indica o operaţie abstractă în fondarea obiectului separat, care este publică şi nu conţine parametri formali. Această operaţie nu reduce nici o valoare după executarea sa. - +a desena(forma: multilateral=dreptunghi, culoarea\_inundării: Color =(0,0,255)) -- pot indica o operaţiune de înfăţişare pe ecranul monitorului regiunii dreptunghiului cu culoare albastră, dacă nu indică alte valori în calitate de argumente operaţiei date. - cererea\_contulului\_clientului(numărul\_contului: Integer): Currency -- înseamnă, operaţiunea de indicare în contul curent a clientului băncii. În urma căruia argumentul operaţiei date este numărul contului clientului, care este scris ca număr întreg (de exemplu: «123456»). Ca rezultat al executării operaţiei date va fi un număr întreg scris în formatul monetar(de exemplu: \$1,500.00). - a da\_mesajul():{«Eroare împărţirii la nul»} -- sensul operaţiei acestea nu este nevoie de a explica, deoarece este întreţinut în aliniat -- proprietatea operaţiei. Mesajul dat poate apărea pe ecranul monitorului în cazul cînd despărţim un număr la nul, ce este inadmisibil. 4.2. Relaţii între clase ------------------------ În afară de organizarea internă sau structură claselor în diagrama corespunzătoare sunt indicate diferite relaţii între clase. În urma căruia totalitatea tipurilor astfel de relaţii este fixată în limbajul UML şi este presupusă de semantica astfel tipurilor de relaţii. În limbajul UML relaţiile de bază şi legăturile sunt: - Relaţia de dependenţa (dependency relationship) - Relaţia de asociere (association relationship) - Relaţia de generalizare(generalization relationship) - Relaţia de realizare(realization relationship) Fiecare din relaţiile aceste are reprezentare grafică proprie pe diagramă, care reflectă interconexiunele între obiectele claselor corespunzătoare. ### *4.2.1. Relaţia de dependenţa* Relaţia de dependenţă în caz general indică o relaţie semantică între două elementele modele sau între două mulţimi de aceste elemente, care nu este o relaţie de asociere, generalizare sau realizare. Ea se referă numai la elementele modele şi nu cere o mulţime de exemple pentru explicarea sensului său. Relaţia de dependenţă se foloseşte în situaţia în care o schimbarea unui element al modelului poate cere după sine o schimbare în elementul dependent de elementul precedent al modelului. Grafic relaţie de dependenţă se prezintă grafic, printr-o linie punctată între elementele cu săgeată în capătul entităţii dependente(«-\>» sau «\

UML - Limbajul de Modelare Orientat pe Obiecte (PDF)

Document Details

Tags

Related

Summary

Full Transcript