Sunteți pe pagina 1din 34

2. LIMBAJUL UML - UNIFIED MODELING LANGUAGE

2.1. Modelul UML

UML (Unified Modeling Language) reprezintă a treia generaţie de de limbaj de modelare, aparţinând OMG (Object Management Group). Versiunea iniţială a limbajului UML standard 1.1. a fost lansată în 1997 şi de atunci au fost realizate câteva modificări relativ minore. O revizuire majoră a limbajului a fost realizată la versiunea 2.0; actualmente, limbajul se află la versiunea 2.1 şi este disponibil pe www. uml.org. Scopul general al UML este acela de comunicare; adică de a oferi o notaţie cuprinzătoare pentru a comunica într-o manieră unitară cerinţele, arhitectura, maniera de implementare şi livrare precum şi stările unui sistem software. UML realizează această comunicare din perspectiva particulară a abordării orientate pe obiecte, totul fiind descris în termeni de clase şi obiecte: relaţiile dintre obiecte şi acţiunile asociate, schimbarea stării obiectelor, etc. În acest sens, UML are la bază analiza şi proiectarea orientată pe obiecte, focalizată pe conceptele de bază ale acesteia care implică obţinerea unui cod bine proiectat: încapsulare, moştenire şi polimorfism.

În esenţă, principale elemente care au stat la baza construirii limbajului de modelare UML au fost următoarele:

să furnizeze un limbaj vizual deosebit de expresiv pentru dezvoltarea de modele

ale unei aplicaţii, bazat pe o notaţie formală să pună la dispoziţia utilizatorilor mecanisme pentru a extinde conceptele de bază

ale limabajului, dacă se doreşte acest lucru să furnizeze suport pentru implementarea conceptelor avansate de modelare, ca

de exemplu şabloane (pattern-uri) obiectuale să permită modelarea aplicaţiei într-o manieră independentă faţă de un limbaj de

programare particular să încurajeze dezvoltarea uneltelor de proiectare obiectuală

În consecinţă, actualmente UML este un limbaj de modelare orientat pe obiecte care permite:

vizualizarea modelelor grafice dezvoltate utilizând o semantică bine definită

specificarea modelelor dezvoltate (ne-ambigua şi completă) prin posibilitatea de a

capta elementele esenţiale din faza de analiză a sistemului modelat dar şi de proiectare şi implementare construirea codului, prin faptul că modelele pot fi conectate direct la un limbaj de

programare dorit pentru implementare, cu posibilitatea de a realiza „ingineria inversă”; la modul general însă, UML este independent de limbajul de implementare documentarea diagramelor

UML este un limbaj vizual, bazat pe diagrame al căror conţinut are un anumit impact semantic, utilizat pentru a crea modele ale unui sistem software. Notaţia UML este utilizată pentru a construi modelul obiect al sistemului pornind de la specificaţii, utilizând în acest sens conceptele obiectuale de bază ca de exemplu conceptele de clasă, atribute, metode, precum şi diferitele tipuri de diagrame existente în cadrul limbajului (13 tipuri de diagrame începând cu versiunea 2.0). Această abordare porneşte de la faptul că, în general, sistemele complexe nu pot fi modelate în mod clar şi complet utilizând un singur tip de diagramă; în consecinţă, UML furnizează un set relativ mare de tipuri de diagrame, fiecare dintre acestea oferind o modalitate de vizualizare din alt punct de vedere al sistemului modelat.

Chiar dacă există întrucâtva ideea cum că UML dispune de prea multe diagrame, în realitate ele se rezumă la câteva categorii, şi anume: diagrame de structură sau de clase, diagrame de interacţiune (sequence şi collaboration), diagrame de stare, diagrame de activităţi, diagrame de livrare. Primele trei tipuri de diagrame reprezintă aşa numitele diagrame „de bază” sau fundamentale; restul pot fi utilizate pentru a descrie aspecte adiţionale legate de sistem, cum ar fi de exemplu modalitatea de mapare a software-ului către hardware-ul aferent (diagramele de livrare). Succesul UML , încă de la apariţie, stă în modelul semantic foarte bine definit pe care acesta în are la bază, aşa numitul metamodel UML. Acest model acoperă majoritatea aspectelor necesare vizavi de specificarea şi proiectarea sistemelor software, caracterizându-se totodată şi printr-o notaţie extrem de simplu de utilizat şi de înţeles.

Modelul constă dintr-un set integrat de abstractizări prin intermediul cărora se reprezintă sistemul de modelat, având în esenţă trei aspecte: structural, comportamental şi funcţional:

aspectul structural al modelului identifică elementele care, din punct de vedere structural, alcătuiesc sistemul modelat. De exemplu, un set de obiecte şi relaţiile dintre acestea care definesc starea sistemului la un moment dat (clasele şi relaţiile dintre ele definind posibilele seturi de obiecte ), sau, la o scară mai mare, putem vorbi din punct de vedere structural despre component, pachete şi subsisteme. Toate aceste concepte reprezintă abstractizări care permit descrierea structurală a sistemului pe diferite niveluri de abstractizare (diagrame de clase, diagrame de componente)

Diagrame UML Diagrame Diagrame structurale comportamentale Diagrame Diagrame de Diagrame Diagrame Diagrame de
Diagrame
UML
Diagrame
Diagrame
structurale
comportamentale
Diagrame
Diagrame de
Diagrame
Diagrame
Diagrame
de clase
componente
de activităţi
“use case”
de stare
Diagrame
de obiecte
Diagrame
Diagrame
Diagrame
de
de pachete
de
interacţiune
Diagrame de
structură
livrare
compusă
Diagrame de
Diagrame
Diagrame
interacţiune
Diagrame
“sequence“
“communication“
de ansamblu
de timp
Figura 2.1: Tipuri de diagrame în UML

aspectul comportamental al modelului defineşte modalitatea prin care elementele structurale interacţionează unele cu altele pentru a executa o anumită funcţie a sistemului. Aspectul comportamental poate fi văzut din punctul de vedere individual, al fiecărui element structural (diagrame de stare su de activităţi) sau poate implica ansambluri de elemente (diagrame de interacţiune – sequence şi collaboration). Un aspect comportamental aparte îl reprezintă aspectul funcţional al modelului, care se referă la comportamentul cerut al sistemului ( în termeni de cerinţe), fără a se referi în vre-un fel la implementare (diagrame use-case)

Modelul astfel rezultat poate fi vizualizat prin intermediul diferitelor tipuri de diagrame care oferă de fapt nişte vizualizări ale modelului,fiecare dintre acestea evidenţiind un subset particular de abstractizări ale modelului creat. Nu este necesară vizualizarea tuturor elementelor modelului într-o singură vizualizare: nici nu ar fi posibil, deoarece diagramele aferente expun aspecte diferite din modelul unic (fie structurale, fie comportamentale sau funcţionale). Astfel, modelul conţine toate elementele sistemului, precum şi modalitatea de prezentare vizuală a acestora; o diagramă, pe de altă parte, reprezintă o modalitate de vizualizare a unui anumit set de elemente. Totuşi, există o stânsă legătură între diferitele vizualizări, un element al unui model putând exista în mai multe diagrame.

Datorită faptului că UML este un standard în domeniu, există la ora actuală numeroase unelte software de modelare care furnizează modelare bazată pe UML, printre care IBM Rational Software Modeler. Uneltele de modelare obiectuală bazate pe UML nu doar permit desenarea diagramelor corespunzătoare dar, de asemenea, ele permit şi gestionarea semanticii modelului sistemului, asigurându-se de consistenţa acestuia, realizând diverse tipuri de verificări şi chiar validări ale modelului prin simulare sau execuţie. De asemenea, unele unelte permit generarea automată a codului pe baza modelului creat; generarea automată a codului, acolo unde este posibilă, este deosebit de avantajoasă în sensul că reduce efortul de dezvoltare şi menţine consistenţa între model şi codul rezultat.

2.2. Elemente structurale în modelele UML

2.2.1. Diagrame de structură: diagrame de clase

Din punct de vedere structural, conceptele UML de bază sunt: obiectele, clase (inclusiv clase abstracte), interfeţe. Diagramele de clase sunt utilizate pentru a descrie tipurile (clasele) de obiecte existente în sistem împreună cu relaţiile între acestea, din perspectiva conceptuală, a specificării precum şi a implementării sistemului. Construcţia diagramelor de clase începe cu identificarea obiectelor. Un obiect în UML reprezintă o entitate care are atât atribute, cât şi un comportament, dat de metodele aferente acestuia. Astfel, obiectele în UML:

sunt entităţi care au atît atribute cît şi o comportare: de exemplu, un tip de date abstract (ADT) împreună cu operaţiile definite pentru acesta pot fi entităţi pur conceptuale, vizuale sau fizice

reprezintă unitatea fundamentală de descompunere în programarea orientată pe obiecte (maşini autonome) comunicarea inter-obiecte trebuie văzută ca o transmitere de mesaje între două obiecte; posibilităti de implementare: apel de funcţie, eveniment via sistemul de operare, întrerupere, o resursă comună protejată de semafor, etc. Interfaţa obiectului trebuie să reflecte caracteristicile esenţiale ale acestuia care necesită să fie vizibile altor obiecte obiectele sunt în mod inerent concurente: teoretic este posibil ca fiecare obiect să ruleze pe propriul procesor. Un thread este este un set de operaţii concurente executate în secvenţă. Thread-urile concurente pot rula pe procesoare separate. reprezintă inteligenţă distribuită: fiecare obiect are suficientă inteligenţă pentru a-şi manageriza propriile resurse şi pentru a funcţiona în felul său propriu. Este mai simplă construirea mai multor obiecte semi-deştepte în locul unui obiect foarte deştept care le face pe toate.

Clasele captează la un loc structura şi funcţionalitatea obiectelor similare, definind atributele şi metodele asociate obiectelor din acea clasă.

atributele şi metodele asociate obiectelor din acea clasă. Figura 2.2: Reprezentarea în UML a claselor Clasele

Figura 2.2: Reprezentarea în UML a claselor

Clasele în UML sunt reprezentate utilizând dreptunghiuri cu până la trei compartimente: numele clasei (Dreptunghi - obligatoriu), lista de atribute (lungime, lăţime) şi lista operaţiilor (metodelor – setLungime, setLatime, Afiseaza, Calculeaza) definite pentru clasa respectivă. Simbolurile care precedă atributele sau numele metodelor se referă la vizibilitatea elementului respectiv. Notaţia standard UML implică următoarele simboluri: privat (-), protected (#) sau vizibilitate publică (+) sau la general la nivel de pachet(~). Pornind de la acestea, fiecare unealtă de modelare îşi defineşte simboluri proprii pentru a ilustra vizibilitatea elementelor, nu neapărat identice cu cele din notaţia UML; în cazul

exemplului de mai sus, atributele lungime şi latime precum şi metoda Calculeaza sunt private, metodele setLungime şi setLatime sunt publice respective metoda Afiseaza are vizibilitate de tip protected.

Afişarea tuturor detaliilor pentru o clasă în cadrul unui model poate încărca prea mult diagrama de clase; în consecinţă, UML permite ascunderea detaliilor referitoare la atributele şi metodele claselor. Acesta este principiul cheie în UML: diagramele nu expun în general conţinutul complet al modelului, ci doar un subset al acestuia. Astfel, toate reprezentările prezentate în Figura 2.3 sunt valide pentru clasa

Senzor_temperatura.

în Figura 2.3 sunt valide pentru clasa Senzor_temperatura . Figura 2.3: Diferite vederi ale aceluiaşi model
în Figura 2.3 sunt valide pentru clasa Senzor_temperatura . Figura 2.3: Diferite vederi ale aceluiaşi model
în Figura 2.3 sunt valide pentru clasa Senzor_temperatura . Figura 2.3: Diferite vederi ale aceluiaşi model

Figura 2.3: Diferite vederi ale aceluiaşi model de clase

O interfaţă este de fapt o colecţie de operaţii care poartă un nume. Interfeţele permit separarea unui set de servicii (operaţii) apelabile de către o clasă de implementarea acestora. Interfeţele nu pot avea atribute şi nu sunt direct instanţiabile: o clasă se spune că implementează o anumită interfaţă daca furnizează o metodă pentru fiecare operaţie specificată în cadrul interfeţei. În UML, interfeţele pot fi reprezentate în mai multe forme:

ca şi clasele, dar utilizând stereotipul <<interface>> (Figura 2.4). În această variantă de reprezentare lista operaţiilor furnizate de interfaţă este vizibilă utilizând un cerculeţ care poartă un nume (numele interfeţei) legat de clasa care implementează interfaţa (Figura 2.4 - aşa numita notaţie lollipop). În această variantă de reprezentare lista operaţiilor furnizate de interfaţă nu este vizibilă

Figura 2.4: Reprezentări alternative ale interfeţelor în UML Interfeţele sunt utilizate de regulă pentru a
Figura 2.4: Reprezentări alternative ale interfeţelor în UML Interfeţele sunt utilizate de regulă pentru a

Figura 2.4: Reprezentări alternative ale interfeţelor în UML

Interfeţele sunt utilizate de regulă pentru a asigura faptul că o clasă client invocă în mod consistent şi corect serviciile unei alte clase, pentru a se asigura conformitatea. O altă modalitate de a se realize acest lucru implică utilizarea claselor abstracte şi a relaţiei de generalizare. Clasele abstracte nu sunt instaţiabile, definesc doar operaţii fără implementare dar nu metode, în mod asemănător interfeţelor. UML diferenţiază clasele abstracte de cele non abstracte prin marcarea numelui clasei cu caractere italic (Figura 2.5).

marcarea numelui clasei cu caractere italic (Figura 2.5). Figura 2.5: Clasă abstractă în UML În cadrul

Figura 2.5: Clasă abstractă în UML

În cadrul unui sistem complex, clasele şi interfeţele nu sunt de sine stătătoare ci se află în diverse relaţii cu alte clase, astfel încât obiectele corespunzătoare să poată colabora pentru realizarea funcţionalităţii sistemului. Astfel, pentru ca două obiecte să-şi transmită mesaje unul altuia, trebuie să fie asociate într-un anumit mod. Exemple de asocieri sunt următoarele:

Obiect

Associere

Obiect

Motor

are un

Piston

Senzor liniar

este un tip de

Senzor

Lift

este chemat de

Buton de apel

Client

stochează banii în

Cont bancar

Ca un exemplu al modului în care relaţiile pot fi utilizate, putem să considerăm un sistem simplu în care un controler utilizează un senzor cu un convertor A/D pentru a obţine nişte informaţii; acelaşi controller utilizează apoi un element de execuţie

(actuator) prin intermediul căruia sistemul reacţionează la informaţiile obţinute anterior. Senzorul poate fi de exemplu de temperatură; funcţie de valoarea acesteia se activează fie un încălzitor fie un ventilator. În plus, acelaşi controler poate utiliza şi un senzor de presiune pentru a obţine informaţii despre presiunea unui gaz într-o conductă şi un robinet pe post de element de execuţie care se poate închide/deschide funcţie de valoarea presiunii, cu ajutorul unui motor pas cu pas. O diagramă de clase pentru un astfel de sistem este prezentată în Figura 2.6 :

pentru un astfel de sistem este prezentată în Figura 2.6 : Figura 2.6: O diagramă de

Figura 2.6: O diagramă de clase pentru problema senzor-controler-element de execuţie

În cadrul acesteia, dreptunghiurile reprezintă conceptele de bază ale sistemului sub formă de clase. Liniile care conectează clasele reprezintă diferite tipuri de relaţii între acestea. Astfel, există cinci de tipuri de relaţii între clase definite în UML, fiecare avînd o anumită semnificaţie proprie: asociere (association), agregare (aggregation),

compoziţie (composition), generalizare sau moştenire (generalization, inheritance) şi dependenţă sau instanţiere (dependency).

1. Relaţia de asociere

Asocierile sunt relaţii care se manifestă în timpul execuţiei şi permit schimbarea de mesaje între obiecte. Ele sunt utilizate pentru a reprezenta o relaţie structurală între obiecte, în general de diferite clase. Utilizarea relaţiei de asociere este potrivită pentru cazuri de genul:

obiectul utilizează serviciile altui obiect dar nu face parte din acesta

relaţia dintre cele două obiecte poate fi caracterizată de tipul client-server

obiectul utilizat îşi oferă serviciile şi altor obiecte în mod egal

Relaţia de asociere este marcată în cadrul diagramelor de clase utilizînd linii simple care conectează cele două clase. Dacă nu se specifică altfel, asocierile în UML sunt bidirecţionale; în caz contrar, trebuie punctate printr-o săgeată deschisă la capătul dinspre obiectul (clasa) primitor (ex: relaţia controller-senzor din Figura 2.6). Asocierile navigabile într-o singură direcţie sunt cunoscute sub denumirea de asocieri de tip client-server. Clientul este obiectul care conţine referinţa iar serverul este obiectul care conţine datele sau operaţia invocată de client. Obiectele client trebuie să “ştie” despre obiectele server suficient încît să le permită invocarea serviciilor acestora; obiectele server nu trebuie să ştie nimic despre client nimic întrucât acest lucru ar conduce la adăugarea mai complicată a unor noi clienţi.

conduce la adăugarea mai complicată a unor noi clienţi. Figura 2.7: O asociere de tip client-server

Figura 2.7: O asociere de tip client-server

O alternativă a asocierii client-server o reprezintă asocierea de tipul peer-to-peer. Mult mai puţin răspîndită ca şi cea client-server, aceasta implică o transmitere de mesaje bidirecţională între cele două obiecte. În general, acesta este implementată ca două relaţii independente de tip client-server, una pentru fiecare direcţie.

Figura 2.8: O relaţie de asociere bidirecţională Multiplicitatea asocierilor – pentru cazul relaţiilor de asociere

Figura 2.8: O relaţie de asociere bidirecţională

Multiplicitatea asocierilor – pentru cazul relaţiilor de asociere (dar şi, după cum se va vedea ulterior, de agregare şi compoziţie) se defineşte aşa numita multiplicitate a asocierilor prin care se indică cîte obiecte (instanţe) din fiecare clasă participantă la asociere pot exista în timpul execuţiei. Acest lucru este realizat prin introducerea de numere sau a caracterului * la capetele liniei ce marchează asocierea:

un număr fix, ca de exemplu 1 sau 3

o listă de numere separată prin virgulă, de exemplu 0,1

un domeniu de numere, de exemplu 0 10

un asterisk, care reprezintă multiplicitate de tipul “zero sau mai mulţi”

un număr şi un aterisk, de exemplu 1

*,

reprezentând “unul sau mai mulţi”

Multiplicitatea se marchează întotdeauna la capătul asocierii dinspre clasa căreia i se aplică. De exemplu, în Figura 2.6 poate exista un singur obiect din clasa Controler dar care poate fi asociat cu zero sau mai multe obiecte din clasa Senzor. Există posibilitatea nespecificării multiplicităţii unei asocieri; însă în acest caz nu există nici o valoare implicită specificată în UML.

De asemenea, fiecare capăt de asociere poate să poarte un nume, aşa numitul role name: acesta numeşte de fapt instanţa referită din cealaltă clasă, de obicei printr-un substantiv. Este o practică obişnuită să se denumească rolurile unei asocieri la capătul opus a asocierii faţă de pointerul care indică respectiva clasă; atunci când se va genera codul, numele rolurilor devin instanţe de variabile în clasa ţintă. De exemplu, echipa devine variabilă de instanţă în cadrul clasei Jucator. În plus, asocierea poate avea şi un nume: are.

Figura 2.9: O relaţie de asociere cu nume 2. Relaţia de agregare Agregarea este un

Figura 2.9: O relaţie de asociere cu nume

2. Relaţia de agregare

Agregarea este un tip special de asociere care implică conţinerea fizică sau logică a obiectelor component. Relaţia de agregare este utilizată atunci când un obiect conţine, în mod logic sau fizic un alt obiect. Obiectul (clasa) care conţine alte obiecte este aşa numit proprietar, iar obiectele conţinute sunt părţi ale acestuia. De exemplu,

în Figura 2.6 un obiect Senzor conţine un obiect Convertor

A/D .

Relaţia de agregare este indicată utilizându-se un simbol de tipul diamant la capătul obiectului proprietar. Acesta este de obicei responsabil cu crearea şi distrugerea obiectelor conţinute de el. Astfel, un obiect “parte” a unei agregări nu poate exista în afara obiectului proprietar. Practic, durata de viaţă a obiectului “parte” este legată de durata de viaţă a obiectului proprietar.

UML permite totuşi ca obiectele conţinute să fie împărţite între mai mulţi proprietari. În acest caz, trebuie însă specificat în mod clar cine este responsabil de crearea şi distrugerea obiectelor comune.

Întrucât agregarea reprezintă un caz particular de asociere, toate proprietăţile referitoare la navigabilitate, multiplicitate şi nume de roluri se aplică şi în cazul relaţiei de agregare. Atunci când multiplicitatea obiectelor conţinute este 1, se vorbeşte de agregare fizică; dacă multiplicitatea componentelor este mai mare decît 1, avem de-a face cu o agregare de tip catalog. Relaţia de agregare poate fi recursivă: adică poate conţine la rîndul ei alte agregate.

Agregarea poate fi ulterior rafinată în UML pentru a indica modul în care este implementată legătura între proprietar şi obiectele părţi. În mod implicit, aceasta se implementează prin referinţă, adică obiectul proprietar menţine un pointer sau o referinţă la componentele acestuia. Simbolul diamant gol este utilizat în această situaţie. Dacă însă agregarea este implementată prin valoare, adică în cadrul

obiectului proprietar se declară o instanţă a obiectului parte, se utilizează simbolul de diamant plin (Figura 2.10).

se utilizează simbolul de diamant plin (Figura 2.10). Figura 2.10: Tipuri de agregare Un alt exemplu
se utilizează simbolul de diamant plin (Figura 2.10). Figura 2.10: Tipuri de agregare Un alt exemplu

Figura 2.10: Tipuri de agregare

Un alt exemplu de agregare este prezentat în Figura 2.11:

de agregare Un alt exemplu de agregare este prezentat în Figura 2.11: Figura 2.11: Ilustrarea unor

Figura 2.11: Ilustrarea unor relaţii de agregare

3.Relaţia de compoziţie Compoziţia este o formă mai puternică de agregare în cadrul căreia obiectul proprietar este în mod explicit responsabil de crearea şi distrugerea obiectelor părţi. Datorită acestei cerinţe, obiectul proprietar sau compus trebuie să existe înainte ca părţile sale să fie create şi existenţa acestuia poate să dureze şi după ce obiectele părţi sunt distruse. Dacă părţile au multiplicitate fixă în cadrul obiectului agregat, este o practică comună să se creeze obiectele părţi în cadrul constructorului acestuia iar distrugerea lor să aibă loc de asemenea în cadrul destructorului obiectului compus. Dacă multiplicitatea nu este fixă, aceste operaţii de creare/distrugere a obiectelor părţi trebuie să aibe loc în mod dinamic, în momentul execuţiei. Deoarece obiectul agregat, compus, are responsabilităţi clare de creare şi distrugere a obiectelor componente, în acest caz nu este permis ca obiectele componente să fie împărţite între mai mulţi proprietari, acesta fiind unicul proprietar. Obiectele componente pot însă să fie utilizate în alte relaţii de asociere sau agregare. Grafic, relaţia de compoziţie este reprezentată în mod asemănător agregării, utilizând simbolul diamant plin. Un exemplu de compoziţie este prezentat în Figura 2.12:

Un exemplu de compoziţie este prezentat în Figura 2.12: Figura 2.12: Ilustrarea unor relaţii de compoziţie

Figura 2.12: Ilustrarea unor relaţii de compoziţie

Un alt mod uzual de utilizare a compoziţiei este cazul obiectelor active: adică obiecte care sunt rădăcinile unui thread. Aceste obiecte active crează thread-ul şi componentele acestora se execută în cadrul acestui thread.

4. Relaţia de generalizare sau moştenire

Atunci cînd o clasă este o specializare a alteia, extinzând clasa iniţială, relaţia dintre cele două este aceea de generalizare sau moştenire. Moştenirea este o facilitate extrem de puternică, în ciuda simplicităţii acesteia, permiţând obiectelor să fie specificate “prin diferenţă”. Practic, clasa părinte (superclass în UML sau clasă de bază) este o generalizare a clasei fiu, derivate (subclass în UML), care, la rândul său, reprezintă o specializare a clasei părinte. Un principiu important al relaţiei de moştenire/generalizare este Principiul Substituţiei al lui Liskov (LSP). Acesta spune că o subclasă (clasă derivată) trebuie să fie complet substituibilă pentru clasele sale superioare.

Moştenirea poate fi simplă sau multiplă. Relaţia se marchează cu o linie cu săgeată închisă la capătul dinspre clasa superioară din cadrul ierarhiei.

În termeni de implementare, moştenirea este reprezentată printr-un pointer sau o referinţă către clasa de bază. În ceea ce priveşte poziţionarea atributelor în ierarhia de clase, trebuie avut în vedere faptul că, clasele de bază reprezintă o generalizare a claselor derivate, deci acestea vor trebui să conţină atributele comune tuturor claselor din ierarhie. Structurarea ierarhiei de clase trebuie realizată utilizînd trei căi complementare:

clase derivate care extind capabilităţile claselor strămoş (top-down)

clase derivate care specializează capabilitătile claselor strămoş (top-down)

transmiterea către clasa părinte a atributelor şi metodelor comune claselor derivate (bottom-up)

Un exemplu de moştenire este prezentat în Figura 2.13:

Figura 2.13: Ilustrarea unor relaţii de moştenire Relaţia de moştenire reprezintă probabil unul dintre cele

Figura 2.13: Ilustrarea unor relaţii de moştenire

Relaţia de moştenire reprezintă probabil unul dintre cele mai interesante aspecte ale modelării obiectuale, furnizând mijloace de a construi componente reutilizabile. Datorită acestui lucru, ea este utilizată mult prea mult, chiar şi în cazurile în care agregarea sau alt tip de relaţie ar fi poate mai potrivită. Pentru a putea face deosebirea în aceste cazuri trebuie avute în vedere următoarele elemente:

atunci cînd un obiect este “un fel de “ alt obiect, moştenirea este cea mai potrivită atunci cînd un obiect este “o parte” sau “conţine” sau “are” un alt obiect, utilizarea agregării este opţiunea cea mai bună dacă nu se identifică nici una din situaţiile de mai sus, atunci o asociere simplă poate fi utilizată

5. Relaţia de dependenţă (dependency)

Relaţia de asociere (cu toate variantele sale, inclusiv agregare sau compoziţie) împreună cu relaţia de generalizare reprezintă relaţiile UML de bază. În afara acestora, există o serie de alte relaţii care pot apărea între diverse situaţii, şi toate acestea sunt încadrate sub denumirea generală de relaţii de dependenţă. UML defineşte patru tipuri de dependenţă: Abstractizare (abstraction), Legătură (binding), Utilizare (usage) şi Permisiune (permission); acestor tipuri de relaţii li se pot asocial stereotipuri: de exemplu rafinează sau realizează reprezintă un stereotip relaţia de dependenţă tip abstractizare, relaţie existentă de exemplu între o clasă

abstractă/interfaţă şi clasa care implementează clasa abstractă sau interfaţa; friend reprezintă un stereotip pentru relaţia de tip permission, de exemplu între o clasă în C++ şi o clasă friend a acesteia; leagă sau implementează este un stereotip pentru relaţia de tip legătură (binding), de exemplu dintre o clasă parametrizată şi clasa concretă (cu parametri actuali), asociată acesteia.

Astfel, la modul general, relaţia de dependenţă defineşte un tip special de dependenţă prin intermediul căreia un element implicat în relaţie furnizează o specificare pe care celălalt element o implementează. În general, relaţia de dependenţă preia o entitate incomplet definită (de exemplu o interfaţă sau o clasă parametrizată) şi crează pe baza acesteia o entitate completă. Acest tip de relaţie se consideră ca fiind în mare măsură similară cu cea de generalizare/moştenire. Exemple de rafinare sunt prezentate în Figura 2.14:

Exemple de rafinare sunt prezentate în Figura 2.14: Figura 2.14: Ilustrarea unor relaţii de tip dependenţă
Exemple de rafinare sunt prezentate în Figura 2.14: Figura 2.14: Ilustrarea unor relaţii de tip dependenţă

Figura 2.14: Ilustrarea unor relaţii de tip dependenţă

Relaţia de dependenţă este marcată asemănător moştenirii, cu deosebirea că linia este punctată.

2.2.2. Diagrame de structură: Diagrame de obiecte

Diagramele de obiecte pot fi considerate un caz particular al diagramelor de clase, fiind de fapt un subset al elementelor dintr-o diagramă de clase cu scopul de a accentua relaţiile dintre instanţele unor clase la un moment dat. Ele sunt utile pentru înţelegerea diagramelor de clase, în cadrul acestor identificându-se mai clar multiplicitatea şi rolurile.

Reprezentarea obiectelor (instanţelor) este diferită de a claselor: obiectele nu au mai multe compartimente iar numele obiectului apare subliniat. Opţional, poate apărea şi clasa obiectului.

subliniat. Opţional, poate apărea şi clasa obiectului. Figura 2.15 : Reprezentarea obiectelor Dacă se doreşte

Figura 2.15 : Reprezentarea obiectelor

Dacă se doreşte ilustrarea stării obiectului la un anumit moment dat, este posibil să se indice setul curent de valori al atributelor pentru instanţa curentă:

curent de valori al atributelor pentru instanţa curentă: Figura 2.16: Reprezentarea obiectelor versus a claselor
curent de valori al atributelor pentru instanţa curentă: Figura 2.16: Reprezentarea obiectelor versus a claselor

Figura 2.16: Reprezentarea obiectelor versus a claselor

Examplul din Figura 2.17 ilustrează o posibilă diagramă de obiecte corespunzătoare acestei diagrama de clase din Figura 2.7. Multiplicitatea relaţiei de agregare este unu (1) cu mai mulţi (*) aşa încât existenţa la un moment dat a trei instanţe de obiecte Cititor este corectă.

existenţa la un moment dat a trei instanţe de obiecte Cititor este corectă. Figura 2.17: O

Figura 2.17: O diagramă de obiecte

2.2.3 Alte diagrame de structură: subsisteme şi diagrame de pachete,

diagrame de componente, diagrame de livrare

Diagramele de clase conţin aşa numitul model logic al aplicaţiei, format din clase şi relaţiile existente între acestea. O diagramă de clase poate reprezenta în totalitate sau parţial structura de clase al modelului logic al sistemului; pentru o mai bună structurare însă, atunci când există legături strînse între acestea (coeziune mare), clasele din cadrul diagramelor de clase pot fi grupate în structuri de nivel mai înalt:

pachete (din punct de vedere logic), componente, subsisteme. De fapt, toate aceste tipuri de diagrame sunt similare, se încadrează în categoria diagramelor de structură.

Astfel, diagrama de clase repezintă în mod clar diagrama de structură de bază, furnizând prin intermediul claselor şi relaţiilor dintre acestea o primă vizualizare din punct de vedere structural a sistemului modelat. Dar, în cadrul sistemelor reale, complexe, este practic imposibil să se cuprindă întreaga structură a sistemului într-o singură diagramă de clase aşa încât apare necesitatea de a împărţi sistemul în mai multe diagrame. Criteriul după care se face această împărţire este important; ideea este aceea ca, pentru fiecare astfel de diagramă să existe la bază un concept comun:

de exemplu să conţină clase care colaborează în realizarea unui scenariu (use-case) al sistemului; astfel, dacă sistemul este constituit din trei use-case-uri va rezulta o descompunere în trei diagrame.

UML furnizează cîteva concepte cheie pentru a manageriza sistemele de mari dimensiuni.

2.2.3.1. Diagrame de pachete şi subsisteme

Pentru dezvoltarea pe scară largă, UML suportă conceptul de pachet (package). Pachetele reprezintă un mecanism de grupare (logic sau fizic) care poate fi utilizat pentru proiectarea grupurilor de clase, use-case-uri, componente, etc. Un pachet reprezintă o grupare de entităţi care prezintă legături între ele; un pachet poate conţine în mod normal elemente precum clasele, dar poate conţine de asemenea şi use-case-uri precum şi diferite diagrame, cum ar fi diagrame de interacţiune sau de clase.

Pachetele reprezintă elemente de modelare care la rândul lor conţin alte elemente de modelare, inclusiv alte pachete. Pachetele sunt utilizate pentru a împărţi modelul unui sistem complex în scopul unei manipulări mai uşoare; nu pot fi instanţiate, sunt utilizate strict numai în scopuri de organizare. Pachetele definesc spaţii de nume

pentru elementele componente, dar nu includ alt substrat semantic. Nu există nici o regulă clar definită pe baza căreia să se realizeze impărţirea în pachete: acestea reprezintă elemente constructive şi pot fi utilizate pentru a organiza structura modelului în orice modalitate doreşte proiectantul sistemului.

De exemplu, toate clasele dintr-un model pot fi incluse în pachete funcţie de domeniul la care acestea se referă: de exemplu clasele care se referă la interfaţa utilizator, clase care înglobează logica aplicaţiei, clase care interacţionează cu dispozitive de I/O, etc. Codul implementat poate fi în mod corespunzător împachetat în subsisteme care reprezintă componentele software ale sistemului. Notaţia folosită pentru pachete este aceea de tabbed folder (Figura 2.18):

pentru pachete este aceea de tabbed folder (Figura 2.18): Figura 2.18: Notaţia UML pentru pachet logic

Figura 2.18: Notaţia UML pentru pachet logic

În cadrul pachetului se pot, opţional, indica elementele pe care pachetul le conţine. De exemplu, pachetul cu Informatii_medicale ar putea include următoarea diagramă de clase:

ar putea include următoarea diagramă de clase: Figura 2.19: Diagrama de clase pentru pachetul

Figura 2.19: Diagrama de clase pentru pachetul Informatii_medicale

Se pot utiliza de asemenea stereotipuri prin care se clarifică tipul pachetelor (ex:

<<category>> pentru modelul de clase sau <<subsystem>> pentru modelul de cod). Subsistemele sunt bazate pe pachete în UML: un subsistem reprezintă de fapt un stereotip al pachetelor. De fapt şi una dintre notaţiile UML pentru subsisteme implică reprezentarea acestora ca nişte pachete, dar cu stereotipul <<subsystem>> (Figura 2.20).

cu stereotipul <<subsystem>> (Figura 2.20). Figura 2.20: O reprezentare a subsistemelor utilizând

Figura 2.20: O reprezentare a subsistemelor utilizând stereotipul <<subsystem>>

Spre deosebire de pachete însă, subsistemele sunt structuri organizatorice ale sistemului la execuţie (rulare), ele constând din instanţe. Criteriul care stă la baza includerii unui element într-un subsistem îl reprezintă îl reprezintă aderarea la un comportament comun. Subsistemele reprezintă un nivel mai înalt de abstractizare decît obiectele sau instanţele primare, acest nivel de abstractizare facilitând o mai simplă urmărire şi cunoaştere a comportării sistemelor complexe. În mod asemănător pachetelor, subsistemele pot de asemenea indica instanţele care formează subsistemul.

2.2.3.2. Diagrame de componente

Componentele diferă de subsisteme şi pachete doar prin modalitatea în care sunt utilizate: componentele sunt de regulă utilizate ca şi blocuri interschimbabile, ca de exemplu biblioteci, tabele de configurare, DLL-uri, etc. Ele sunt proiectate pentru a funcţiona într-un cadru specific şi reprezintă temelia filozofiei de dezvoltare bazată pe componente, care se axează pe ideea că dezvoltarea trebuie să bazeze pe utilizarea şi asamblarea (atunci când acest lucru este posibil) componentelor existente pentru a obţine funcţionalitatea dorită în loc să creeze totul de la zero, această abordare conducând la semnificative economii de resurse şi timp.

Diagramele de componente ilustrează componentele principale software ale sistemului modelat, furnizând o vedere din punct de vedere fizic al modelului curent. Vederea la nivel de componente are un grad mai ridicat de abstractizare decât diagramele de clase, chiar dacă, în mod normal, o componentă este de fapt implementată printr-una sau mai multe clase. Această viziune arată organizarea şi

dependenţele existente între diferitele componente software (de exemplu: surse, executabile, dll-uri, etc.). Interfaţa unei componente este reprezentată prin partea vizibilă din exterior a componentei. În cadrul diagramelor de componente pot exista relaţii de dependenţă între componente; de asemenea, şi componentele pot fi grupate în pachete. Pachetele de componente reprezintă ceva similar cu pachetele logice din cadrul diagramelor de clase. Ele permit partiţionarea modelului fizic al sistemului. O forma generală pentru o diagramă simplă de componente este prezentată în Figura 2.21. Componentele pot fi la rândul lor grupate în pachete.

Componentele pot fi la rândul lor grupate în pachete. Figura 2.21: Un exemplu de diagramă componente

Figura 2.21: Un exemplu de diagramă componente

Conceptele UML de sistem, subsistem şi componentă acoperă practic orice schemă de organizare pe care un sistem le-ar putea avea. Astfel:

sistemul – indicat printr-un pachet cu stereotipul <<system>> reprezintă întregul sistem dezvoltat subsistemele - indicat prin pachete cu stereotipul <<subsystem>> reprezintă componentele la scară largă a sistemului dezvoltat fiecare subsistem poate include, eventual, atât alte subsisteme cât şi numai componente

2.2.3.3. Diagrame de livrare

Diagramele de livrare (deployment) arată organizarea hardware-ului şi legarea software-ului de dispozitivele hardware (procesoare, dispozitive de I/O, conexiuni etc.). Fiecare model UML conţine o singură diagramă de livrare care indică conexiunile dintre procesoare şi diferitele dispozitive utilizate precum şi modul de alocare al proceselor pe procesoare (Figura 2.22).

modul de alocare al proceselor pe procesoare (Figura 2.22). Figura 2.22: O diagramă de livrare De

Figura 2.22: O diagramă de livrare

De cele mai multe ori diagramele de componente şi de livrare pot fi combinate într-o singură diagramă fizică, care, de obicei conţine noduri şi conexiuni: un nod reprezintă un element hardware din cadrul sistemului iar conexiunile marchează calea utilizată pentru comunicarea între noduri. În cadrul nodurilor, pot fi marcate componentele, sub forma pachetelor care înglobează mai multe module de cod. Dependenţele între componente ilustrează cum modificările din cadrul unei componente afectează şi alte componente, eventual din alte noduri: acest lucru este ilustrat printr-o linie punctată. De asemenea, diagramele de componente pot ilustra şi interfeţele utilizate de către componente pentru a comunica unele cu altele.

2.2.3.4. Diagrame de structură compusă (Composite structure diagrams)

Diagrame “composite structure” reprezintă o facilitate nou introdusă în UML 2 şi sunt utilizate pentru a vizualiza modalitatea de colaborare a anumitor instanţe care trebuie să comunice între ele, indicând rolul fiecărei instanţe în cadrul colaborării.

2.3. Elemente comportamentale în modelele UML

Din punct de vedere comportamental, în momentul dezvoltării unui sistem trebuie urmărite două aspecte: cum se comportă elementele structurale în izolare dar şi în interacţiune cu alte elemente.

Limbajul UML furnizează concepte pentru descrierea ambelor situaţii; astfel, pentru ilustrarea comportamentului obiectelor individuale se pot utiliza diagramele de activităţi şi de stare; pentru modelarea comportamentului colaborativ a unui set de obiecte se utilizează diagramele de interacţiune.

2.3.1. Diagrame comportamentale: Diagrame use-case

Diagramele use-case furnizează o viziune naturală de nivel înalt a funcţionalităţii unui sistem în interacţiunea cu unul sau mai mulţi actori externi, prin intermediul cărora se identifică scenariile posibile de execuţie. Un scenariu reprezintă o descriere formală a unui flux de evenimente se întâmplă într-o anumită secvenţă între sistem şi un actor extern. Un actor poate iniţia un use-case dar poate fi folosit pe post de recipient al rezultatului utilizării sistemului. Un scenariu sau use-case reprezintă o anumită capabilitate funcţională a sistemului care returnează un rezultat către unul sau mai mulţi actori externi cu care interacţionează, fără a implica niciun fel de informaţii despre implementarea internă a acelei funcţionalităţi. Un scenariu (use-case) este utilizat în special pentru a capta cerinţele funcţionale ale sistemului. Un sistem poate fi descris pe baza mai multor scenarii (use-case-uri). Use-case-urile sunt reprezentate prin ovale asociate cu anumiţi actori.

Figura 2.23: Un sistem format din 3 use-case-uri De asemenea, use-case-urile pot fi în legătură

Figura 2.23: Un sistem format din 3 use-case-uri

De asemenea, use-case-urile pot fi în legătură unele cu altele:

printr-o simplă asociere, în situaţia în care un use-case utilizează elemente funcţionale ale unui alt use-case prin extindere – extend - un use-case reprezintă o formă mai specializată a unui alt use-case extinzând aspectele funcţionale ale acestuia prin includere – include - un use-case include un alt use-case pentru a realiza propria funcţionalitate; în acest caz se presupune că scenariul inclus va fi apelat de fiecare dată când scenariul iniţial este în execuţie

O diagramă use-case poate include la rândul său alte diagrame

use-case. La rândul lor, use-case-urile pot fi grupate din punct de vedere logic în pachete. Scenariile se descriu la acest nivel în formă textual dar, ulterior, fiecare use-

case poate fi detaliat cu ajutorul diagramelor de interacţiune de tip sequence.

2.3.2. Diagrame comportamentale: Diagrame de interacţiune

Limbajul UML modelează comportamentul colaborativ al mai multor entităţi (instanţe) prin ilustrarea modalităţii de interacţiune a acestora. În mod general, aceste interacţiuni se referă la schimbarea secvenţială de mesaje (care pot fi reprezentate de evenimente, apeluri de operaţii, acţiuni de creare/distrugere, etc.) din cadrul unui set de obiecte.

Există două modalităţi de reprezentare prin intermediul UML a acestor interacţiuni:

diagrame sequence şi diagrame communication (foste collaboration). Acestea reprezintă reprezentări alternative ale interacţiunilor dintre obiecte. Practic, prin intermediul acestora se indică secvenţa de mesaje care implementează o anumită operaţie sau tranzacţie din interiorul sistemului modelat. Obiectele sunt ilustrate în ambele tipuri de diagrame utilizând dreptunghiuri, ca şi în cazul claselor. Pentru a face diferenţa între obiecte şi clase, numele obiectelor sunt subliniate. Clasa obiectului poate urma, în mod opţional, numele acestuia utilizînd “:”.

1. Diagrame sequence

Diagramele sequence utilizează icoane ale obiectelor implicate cu linii verticale proiectate în jos (aşa numitele lifeline), în cadrul diagramei. Liniile orizontale reprezintă mesajele schimbate între obiecte, care apar începând de la linia asociată obiectului sursă şi până la linia asociată obiectului destinaţie. Timpul curge de sus în jos. Dacă nu este specificat explicit, doar secvenţa de mesaje este stabilită, nu şi momentul exact al acestora. Diagramele sequence sunt potrivite pentru a ilustra care obiecte comunică cu alte obiecte şi ce (mesaje) declanşează această comunicare.

Forma generală a unui scenariu descrisă cu ajutorul unei diagrame sequence este ilustrată în Figura 2.24:

Figura 2.24: O diagramă sequence UML permite adăugarea de adnotări textuale la diagramele sequence. Notaţiile

Figura 2.24: O diagramă sequence

UML permite adăugarea de adnotări textuale la diagramele sequence. Notaţiile textuale sunt opţionale şi sunt referite ca şi script. Fiecare instrucţiune a script-ului explică unul sau un grup de mesaje care sunt transmise în cadrul diagramei. Un script poate deci să corespundă în mod direct cu scenariul care este modelat prin intermediul diagramei sequence.

Pentru specificarea timpului în cadrul diagramelor sequence, se pot utiliza două forme de notare:

linii orizontale scurte cu o indicaţie a timpului deasupra acestora

etichete asupra mesajelor prin intermediul cărora se specifică o expresie de timp, între acolade

2. Diagrame communication

O diagramă de tip communication, în variantele 1.x a limbajului UML acest tip de diagramă fiind denumită diagramă collaboration, este o diagramă de interacţiune care conţine informaţii similare cu diagrama de tip sequence, dar se focalizează pe relaţiile dintre obiecte şi nu pe secvenţierea în timp a mesajelor dintre acestea. Reprezintă o

modalitate alternativă pentru modelarea scenarilor. Un exemplu generalizat diagramă communication este prezentată în Figura 2.25.

diagramă communication este prezentată în Figura 2.25. Figura 2.25 : Diagrama din Figura 2.24 sub forma

Figura 2.25 : Diagrama din Figura 2.24 sub forma unei diagrame communication

Spre deosebire de diagramele sequence, în diagramele communication nu este ilustrată ordonarea în timp a secvenţei de mesaje; astfel, deoarece nu există un “punct de pornire” al diagramei communication, trebuie ataşate numere care să indice ordinea secvenţială a mesajelor. De asemenea, săgeţile indică direcţia mesajului. Se poate observa că ordinea mesajelor este mai proeminent vizibilă în diagrama sequence, dar structura este mai vizibilă în diagrama communication. Adnotări privind timpii pot fi făcute şi în cadrul diagramelor communication. Diagramele de interacţiune sunt utilizate atunci cînd se doreşte modelarea comportării obiectelor din cadrul unui use-case. Un obiect poate apărea în mai multe use-case-uri, si, implicit, în mai multe diagrame de interacţiune; totuşi, diagramele de interacţiune nu intră în detaliile comportării fiecărui obiect în parte: în acest scop se folosesc diagramele de stare.

2.3.3.Diagrame comportamentale: Diagrame de activităţi

Diagramele de activităţi descriu fluxul de activităţi din cadrul unui sistem. Diagramele de activităţi sunt similare diagramelor de stare prin aceea că activităţile sunt văzute ca fiind starea în care sistemul face ceva. Diagramele de activităţi pot ilustra activităţi

care se desfăşoară funcţie de o anumită condiţie sau în paralel. Sunt potrivite pentru descrierea unor algoritmi secvenţiali complicaţi sau modelarea aplicaţiilor care conţin procese care se desfaşoară în paralel.

care conţin procese care se desfaşoară în paralel. Figura 2.26: O diagrama de activităţi pentru extragere

Figura 2.26: O diagrama de activităţi pentru extragere numerar/afisare sold la ATM

2.3.4. Diagrame comportamentale: Diagrame de interacţiune de ansamblu (Interaction Overview diagrams)

Diagramale de interacţiune de ansamblu (UML 2.0) reprezintă o variantă de diagramă de activităţi în cadrul căreia nodurile sunt constituite din diferite tipuri de diagrame de interacţiune, adică pot fi diagrame sequence, communication, de interacţiune de ansamblu sau de timp. Astfel de diagrame oferă o viziune de ansamblu asupra logicii de control dintre diagramele de interacţiune individuale.

de control dintre diagramele de interacţiune individuale. Figura 2.27: O diagramă de interacţiune de ansamblu care

Figura 2.27: O diagramă de interacţiune de ansamblu care grupează mai multe diagrame de interacţiuni individuale (CautaProdus, VindeProdus, InregistreazaVanzare, AnuleazaVanzare)

2.3.5. Diagrame comportamentale: Diagrame de stare

Diagramele de stare ilustrează comportarea obiectelor de-a lungul diferitelor use- case-uri din cadrul sistemului, descriind toate stările prin care trece un obiect ca reacţie la evenimentele apărute. Fiecare diagramă reprezintă obiectele dintr-o singură clasă; nu toate clasele însă necesită realizarea unor diagrame de stare. Astfel:

o stare reprezintă o condiţie de-a lungul ciclului de viaţă al unui obiect, în decursul căreia acesta satisface anumite condiţii, realizează anumite activităţi sau aşteaptă un eveniment extern. un eveniment reprezintă apariţia unui stimul care poate declanşa o tranziţie către o altă stare o tranziţie reprezintă o relaţie între două stări indicînd că, pentru un obiect aflat într-o primă stare, atunci cînd un set specificat de evenimente şi condiţii sunt îndeplinite, se realizează anumite acţiuni şi apoi se intră într-o a doua stare stare.

Componentele unei tranziţii sunt :

starea sursă

evenimentul declanşator

acţiunea starea destinaţie Acţiunile sunt văzute ca acţiuni atomice şi pot include diverse operaţii, inclusiv crearea/distrugerea de obiecte sau transmiterea de semnale către alte obiecte. O

stare poate avea sub-stări (în acest caz avem de-a face cu o stare compusă); sub- stările pot fi încuibate la orice nivel.

Diagramele de stare conţin relativ puţine elemente:

dreptunghiuri rotunjite pentru reprezentarea stărilor

săgeţi pentru indicarea tranziţiilor dintr-o stare în alta

activităţile pe care un obiect le execută în timp ce se află în starea curentă Toate diagramele de stare încep cu o stare iniţială a obiectului: aceasta este starea imediat după crearea obiectului. Condiţiile bazate pe activităţi vor determina în care stare va trece obiectul la un moment dat. În Figura 2.28 este prezentată o diagramă de stare pentru un obiect aplicatie care poate să treacă prin mai multe stări:

starea Oprit (OFF) – aplicaţia nu este încă pornită

starea Defect – s-a detectat o eroare

starea Pornire şi Operational – reprezintă sub-stări ale unei aşa numite superstări Funcţionare OK. Aceasta înseamnă că, odată ce aplicaţia este în starea FuncţionareOK, ea trebuie să se afle de asemenea într-una dintre sub- stările acesteia.

Încuibarea stărilor într-o astfel de manieră permite descompunerea ierarhică a acestora, permiţând proiectantului să descompună diagramele de stare complexe în structuri mai simple. Un alt beneficiu al stărilor încuibate este acela că ele elimină existenţa stărilor duplicate şi micşorează numărul tranziţiilor. De exemplu în cazul tranziţiei eroare de la starea FuncţionareOK la starea de Eroare, deoarece Pornire şi Operational sunt sub-stări ale lui FuncţionareOK, această tranziţie se aplică ambelor sub-stări. Aceasta constituie o deosebire faţă de modelul Mealy-Moore, care ar necesita pentru acest exemplu mult mai multe tranziţii.

ar necesita pentru acest exemplu mult mai multe tranziţii. Figura 2.28: Diagrama de stare pentru obiectul

Figura 2.28: Diagrama de stare pentru obiectul aplicatie

2.3.6. Diagrame comportamentale: Diagrame de timp

Diagramele de timp (UML 2.0) sunt utilizate pentru a evidenţia schimbarea de stare sau de valoare a unor elemente în timp. De asemenea, diagramele pot indica interacţiunile în timp dintre evenimente precum şi constrângerile vizavi de durata acestora. Există două variante de diagrame de timp:

state lifeline – diagramă care indică schimbările de stare în timp, utilizând o linie orizontală value lifeline – spre deosebire de varianta de mai sus, utilizează valori în loc de stări, marcând printr-o pereche de linii orizontale care se interesctează la un moment dat, momentul în care a survenit o schimbare de valoare

2.4. Alte concepte UML

Limbajul UML are o mare variatate de notaţii şi semantici, care îl face aplicabil pentru modelarea unui set foarte variat de domenii. Astfel, UML furnizează diferite concepte şi notaţii avansate atunci cînd este necesară o modelare mai complexă. Unele dintre acestea sunt necesare doar pentru tratarea anumitor cazuri speciale, altele au izvorât din necesitatea extinderii limbajului UML într-o manieră controlată pentru a suporta modelarea la nivel înalt a sistemului.

Cîteva dintre aceste elemente sunt următoarele:

note de text şi comentarii – notele de text sunt elemente fără nici un impact semantic în UML (Figura 2.29). Sunt reprezentate vizual printr-un dreptunghi cu colţul dreapta-sus îndoit. Furnizează adnotări pentru o mai bună înţelegere a diagramei. Pot apărea oriunde în cadrul diagramelor. Spre deosebire de notele de text, care nu reprezintă elemente UML şi care apar doar în cadrul diagramelor (vizualizărilor), comentariile sunt elemente UML şi sunt incluse în modelul creat. Atât comentariile cât şi notele de text pot fi ataşate unor anumite elemente UML din cadrul diagamelor. Pot fi utilizate pentru a genera documentaţie (stereotipul <<documentation>>) sau pot indica o legătură URL care furnizează informaţii utile pentru elementul căruia i se asociază comentariul.

utile pentru elementul căruia i se asociază comentariul. Figura 2.29: Notaţia UML pentru note de text
utile pentru elementul căruia i se asociază comentariul. Figura 2.29: Notaţia UML pentru note de text

Figura 2.29: Notaţia UML pentru note de text şi comentarii

constrîngeri – reprezintă condiţii suplimentare aplicate pentru elementul modelat, şi care trebuie specificate în cadrul diagramei (Figura 2.30). Apar întotdeauna între acolade.

Figura 2.30: Notaţia UML pentru constrângeri Un exemplu important în acest caz îl reprezintă constrângerile

Figura 2.30: Notaţia UML pentru constrângeri

Un exemplu important în acest caz îl reprezintă constrângerile de timp.

în acest caz îl reprezintă constrângerile de timp. Figura 2.31: Constrângeri de timp stereotipuri – un

Figura 2.31: Constrângeri de timp

stereotipuri – un stereotip reprezintă o metaclasificare a unui element din UML. El identifică tipul unui element din UML. Stereotipurile sunt indicate printr-un nume inlus între << >> , de exemplu: << interface >> . O clasă stereotip este derivată din metaclasele existente în UML. De exemplu, clase stereotip predefinite în UML includ: Event, Exception, Interface, Metaclass şi Utility. Task-uri stereotip predefinite includ: Process şi Thread.

În concluzie, limbajul UML este a treia generaţie de limbaj de modelare orientat obiect, utilizat pentru proiectarea şi specificarea sistemelor software, şi care a devenit un standard în domeniul limbajelor de modelare pentru dezvoltarea orientată pe obiecte. Este destinat modelării diverselor tipuri de sisteme: sisteme client/server, sisteme în timp real, etc., el permiţând detalierea diferitelor aspecte ale sistemului inclusiv documentarea şi poate fi utilizat în diferite moduri pentru a suporta o metodologie de dezvoltare software. Furnizează un set bogat de semantici şi notaţii, majoritatea suportate de cea mai mare parte a uneltelor CASE existente pe piaţă (în particular, diagramele din cadrul acestui capitol au fost realizate utilizând IBM Rational Software Modeler). Utilizează în procesul de modelare diferite tipuri de diagrame, în esenţă grupate două categorii: structurale şi comportamentale. Prin intermediul acestora, UML furnizează o metodologie completă de modelare a sistemelor complexe, având în principal următoarele caracteristici:

modelul obiect

modelarea comportării obiectelor prin diagrame de stare şi activităţi

împachetarea şi gruparea diferitelor entităţi

modele care reflectă topologia fizică a aplicaţiei

suport pentru şabloanele (patterns) obiectuale, etc.