Limbajul de modelare unificat (UML)

Limbajul de modelare unificat (UML)

1


2009-2010


2

CUPRINS

1. Introducere 2. Strategii de formalizare 2.1 Arhitectura UML 2.2 Modele 3. Modelarea cu UML 3.1 View-uri 3.2 Diagrame 4. Concluzii 5. Bibliografie

3 6 6 7 8 9 11 17 19

Limbajul de modelare unificat (UML) 1. Introducere

3

Pentru analiza si proiectarea programelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling Language). UML nu este un simplu limbaj de modelare orientat pe obiecte, ci n prezent, este limbajul universal standard pentru dezvoltatorii software din toata lumea. UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT, and OOSE). Uml se constituie din unirea acestor limbaje de modelare si n plus detine o expresivitate care ajuta la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. UML este un limbaj vizual de modelare, el nu este nc un limbaj vizual de programare, deoarece nu dispune de ntreg sprijinul semantic i vizual pentru a nlocui limbajele de programare. Limbajul este destinat vizualizrii, specificrii, construirii i documentrii sistemelor de aplicaii, dar are limitri n ceea ce privete generarea codului. UML reunete cele mai bune tehnici i practici din domeniul ingineriei programrii, care i-au dovedit eficiena n construirea sistemelor complexe. Limbajul de modelare modificat (UML - The Unified Modeling Language) ofera arhitecturi de sisteme ce functioneaza pe analiza si proiectarea obiectelor cu un limbaj corespunzator pentru specificarea, vizualizarea, construirea si documentarea artefactelor sistemelor sofware si de asemenea pentru modelarea n ntreprideri. UML este un limbaj de modelare care ofera o exprimare grafica a structurii si comportamentului software. Pentru aceasta exprimare grafica se utilizeaza notatiile UML. UML este un limbaj de modelare vizual, orientat obiect, care descrie (reprezint) proprietile structurale i dinamice ale unui sistem software. Prin sistem software se ntelege o BD sau un modul de cod n general. Spre deosebire de modelul EAE, UML este o colecie de tehnici de modelare, folosite pentru tratarea multor aspecte ale procesului de concepere i dezvoltare a software-ului, de la proiectarea BD la interaciunea modulelor de cod. Fiecare tehnic de modelare de mai sus d o vedere diferit, static sau dinamic, a unei aplicaii. Colecia de vederi se numete model. Iat unele din tehnicile de modelare UML: diagrame de clase, sau diagrame statice de structur, care modeleaz entitile unui sistem prin clase cu atribute i comportare. Diagramele de clas descriu, de asemenea, asocierile dintre clase i constrngerile asupra acestora. Apoi, alte tehnici: diagrame de obiecte, diagrame de "caz de utilizare", diagrame de stare, diagrame de secvene, diagrame de activitate, diagrame de colaborare. Notatiile UML constituie un element esential al limbajului pentru realizarea propriu-zisa a modelarii si anume partea reprezentarii grafice pe care se bazeaza orice limbaj de modelare. Modelarea n acest limbaj se realizeaza prin combinarea notatiilor UML n cadrul elementelor principale ale acestora denumite diagrame. n cadrul UML-ului descoperim 9 tipuri de diagrame: diagrama cazurilor de utilizare, diagrama de secventa, diagrama de colaborare, diagrama de clase (cea mai utilizata), diagrama de stari, diagrama de componente, diagrama de constructie, diagrama de obiecte, diagrama de activitati. n cele ce urmeaza vor fi prezentate notatiile UML care vor fi grupate dupa diagramele corespunzatoare fiecarei notatii n parte. Adoptarea specificaiei UML ca limbaj standard de modelare a fost semnalat la 17 noiembrie 1997. UML reunete cele mai bune tehnici i practici din domeniul ingineriei programrii, care i-au dovedit eficiena n construirea sistemelor complexe. Aa cum spune i vorba popular, o imagine exprim ct o mie de cuvinte. Mai mult dect att, cele o mie de cuvinte pot fi ambigue sau pot fi interpretate diferit. Aa cum tim, fiecare cuvnt poate avea mai multe sensuri (iar n limba romn aproape orice fraz poate fi


4

interpretat lejer ca o propunere indecent). Cu siguran c exprimarea cea mai sofisticat, mai complet i mai sigur se poate face direct n limbaj de programare, care, cel puin dup tiina mea, rareori las loc de interpretri. n ingineria mecanic pentru a realiza modelul complet al unei piese, inginerul folosete desenul tehnic ca limbaj pentru comunicare, iar ca mod de reprezentare, vederea n epur. Aceast vedere n epur nseamn vizualizarea unei piese din trei puncte (din fa, de sus i din lateral) astfel nct piesa s fie definit complet. Un cititor avizat al desenului n epur va ti ntotdeauna s refac mental piesa desenat.

Dac din cauza complexitii piesei, cele trei fotografii nu sunt suficiente, inginerul va desena i alte detalii, sau seciuni ale piesei, dar privite din aceleai trei unghiuri. Fiecare dintre cele trei puncte de vizualizare a piesei (noi le vom zice, view-uri) reprezint un submodel capabil s descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare view arat piesa vzut dintr-un anumit punct de vedere iar modelul complet utilizeaz toate punctele de vedere relevante. Aa cum inginerul proiectant comunic prin desen tehnic, echipei, sau oricrei alte persoane interesate ntr-un limbai standard, vizual (adic desenul tehnic), fcut s permit descrierea complet dar, in acelai timp, scutit de detalii inutile, inginerii software pot comunica cu maxim eficient Tn limbajul UML. La fel ca oricare limbai acesta trebuie nvat i exersat astfel nct fiecare cuvnt1' s fie neles, s tim unde i cum se folosete, astfel nct s ne putem exprima n fraze1' coerente, care s spun" exact ceea ce vrem s comunicm. Limbajul UML ne permite realizarea mai multor figuri, ca nite fotografii din diverse unghiuri, ale unei realiti, astfel nct aceast realitate s fie surprins prin toate aspectele ei relevante. In software vom utiliza dou puncte de vedere necesare unei descrieri suficiente a realitii: (1) structural i (2) comportamental.

Limbajul de modelare unificat (UML)Cteva date semnificative referitoare la apariie i evoluie:

5

n octombrie 1994, Grady Booch lider stiinific la Rational Corporation, autor al metodei ce-i poart numele i a unor cri de referint n domeniu face echip cu James Rumbaugh, autorul principal al metodei OMT, pe care-l determin s-si prseasc (cel puin temporar) vechiul loc de munc (General Electric) i s treac la firma Rational. Dup un an de activitate Booch i Rumbaugh, prezint n octombrie 1995 cu ocazia conferinei OOPSLA, caracteristicile de baz ale unei noi metode de analiz i proiectare, rezultat prin unificarea Metodei lui Booch (OOD) cu OMT, metod denumit Metoda unificat (Unified Method). Prima documentaie a metodei menionat anterior a fost fcut public n decembrie 1995, avnd numrul de versiune 0.8. La sfrsitul aceluiai an celor doi li se alatur i Ivar Jacobson. In iunie 1996 apare versiunea 0.9, urmat la scurt timp, octombrie 1996, de apariia versiunii 0.91. Versiunea 0.9 aduce i schimbarea denumirii din Metoda unificat (Unified Method) n Limbajul unificat de modelare (Unified Modeling Language). Cooptarea lui Jacobson n echip se concretizeaz printre altele n detalierea conceptului de cazuri de utilizare (use case) i prezentarea unei descrieri mai amnunite pentru diagramele cazurilor de utilizare. Conceptul de stereotip este mai bine explicitat, se modific denumirile unor diagrame. 1 septembrie 1997, a reprezentat un alt moment deosebit de important. Rational i alte firme care spijina UML, printre care i doi fosti competitori, IBM/ObjectTime i Taskon/Reich, a propus OMG o nou versiune 1.1. Noutatea semnificativ pentru aceast versiune o reprezint introducerea limbajului OCL, un limbaj folosit pentru descrierea regulilor de corectitudine ale metamodelului La 17 noiembrie 1997, OMG a anuntat adoptarea specificaiei UML ca limbaj standard de modelare Schimbarea denumirii din Metoda Unificat n Limbaj de Modelare Unificat a fost justificat prin: reaciile primite din partea utilizatorilor care au sugerat c este mult mai important s se acorde o atenie sporit conceptelor utilizate n dezvoltarea aplicaiilor. Recomandrile referitoare la desfurarea etapelor de realizare i nlntuirea lor au fost lsate n planul secund, faptul c eforturile de unificare au fost concentrate asupra limbajului grafic de modelare, asupra semanticii lui i abia dup aceea asupra modului de utilizare a conceptelor, UML a fost conceput ca un limbaj universal care s fie utilizat la modelarea sistemelor (indiferent de tipul i scopul pentru care au fost construite), la fel cum limbajele de programare sunt folosite n diverse domenii. Sublinierea aspectelor de limbaj nu semnific nici decum ignorarea modului de folosire a lor. UML presupune c metodologia este "ghidat" de cazurile de utilizare,


6

c ea se bazeaz pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ i incremental. Detaliile acestui proces trebuie adaptate la domeniul aplicaiei, la modul de organizare al echipei de realizatori, la experiena echipei. UML nu trateaz aspecte de metodologie, permitnd astfel separarea limbajului de modelare de procesul aplicrii metodologiei.

2. Strategii de formalizare

Strategiile de formalizare considerate sunt legate de una din cele doua abordari care au fost investigate relativ la UML. Abordarea adoptata si propune descrierea UML la metanivel. Avantajele acestei abordari este utilitatea acesteia particulara de a investiga ambiguitatile din meta-modelul UML si devine astfel un mijloc de a dezvolta reguli generale si tehnici pentru constructia, manevrarea si rafinarea diagramelor UML. Cealalta abordare este una tranzactionala. Aceasta atribuie o semantica fiecarei diagrame UML prin translatarea acesteia ntr-o formula de logica modala. Deoarece logica modala ar e semantici bine definite, translatia da o semantica fiecarei diagrame. Tehnicile de probare care au fost dezvoltate pentru logica modala pot fi, n consecinta, aplicate, formulei astfel rezultate. Aceasta abordare este utila pentru probarea proprietatilor relative la sisteme exprimate prin diagrame UML (n opozitie cu diagramele UML nsele). 2.1 Arhitectura UML Pentru a ntelege arhitectura UML se considera modul n care programele si limbajele de programare sunt relationate ntre ele. Exista multe limbaje de programare, pe de o parte, iar fiecare program este dezvoltat utiliznd un limbaj de programare specific. Toate aceste limbaje vor sustine diferite constructii declarative pentru a declara datele, aspectele procedurale, definirea logicilor care manipuleaza datele. Deoarece modelul este o abstractizare, fiecare dintre aceste concepte poate fi captat ntr-o multime de modele relationate. Conceptele limbajelor de programare sunt, la rndul lor definite n metamodel. Fiecare limbaj de programare este definit ntr-un model care utilizeaza si specializeaza conceptele din interiorul metamodelului. Fiecare program implementat ntr-un limbaj de proiectare poate fi definit ntr-un model care se va numi model utilizator care utilizeaza si instantiaza conceptele modelului printr-un limbaj convenabil. Aceasta schema a metamodelului, de reprezentare a constructorilor de programare, modele care sa reprezinte, la rndul lor limbaje de programare si modele utilizator care sa reprezinte programe, exemplifica arhitectura UML. UML este definit n cadrul conceptual al modelarii care consta din urmatoarele patru nivele distincte de abstractizare: Nivelul meta-metamodelului, consta din elementele fundamentale pe care se bazeaza UML -conceptul de 'thing', care reprezinta orice ce poate fi definit. Acest nivel de abstractizare formalizeaza notiunea unui concept si defineste un limbaj pentru specificarea metamodelului. Nivelul metamodelului - consta din acele elemente care constituie UML, incluznd concepte din paradigmele orientate obiect si orientate componente. Fiecare concept al nivelului este o instanta (prin intermediul stereotipurilor) a conceptului metametamodelului 'Thig' Acest nivel de abstractizare este utilizat pentru formalizarea conceptelor paradigmei si la definirea unui limbaj pentru specificarea modelelor Nivelul model - consta din modele UML. Acesta este nivelul la care se produce: modelarea problemelor, solutia sau sistemul. Fiecare concept din acest nivel este o instanta (prin intermediul stereotipurilor) a unui concept din nivelul metamodelului. Acest nivel de abstractizare este utilizat la formalizarea conceptelor si la definirea limbajului


7

pentru comunicarea expresiilor cu privire la un subiect dat. Modelele de pe acest nivel mai sunt numite clase sau modele ale tipurilor. Nivelul model utilizator - consta din acele elemente care exemplifica modelele UML. Fiecare concept din acest nivel este o instanta (prin intermediul clasificarii) a conceptelor din nivelul model si o instanta (prin stereotipuri) a unui concept din nivelul metamodel. Acest nivel de abstractizare este utilizat pentru a formaliza expresiile specifice cu privire la un subiect dat. Modelele din acest nivel sunt numite si obiecte sau instante ale modelului. 2.2 Modele Modelele capteaza caracteristicile structurale sau statice ale sistemelor si comportamentul, sau caracteristicile dinamice ale acestuia. Modelele pot fi privite ca prin intermediul unei multimi de dimensiuni (aspecte) independente care etaleaza calitati particulare ale modelului. Fundamental, modelele capteaza cunostinte (semantici). Perspectiva arhitecturala Perspectiva arhitecturala organizeaza modelele si cunostintele n jurul unei multimi specifice de interese (focusarea arhitecturala). UML da urmatoarele perspective arhitecturale cu privire la modele sau probleme si solutii: modelul utilizator - contine o problema si o solutie ca ntelese de elementele individuale carora li se adreseaza respectiva problema (solutie). Aceasta perspectiva este de asemenea numita use case sau scenariu; modelul structural - cuprinde dimensiunea structurala a unei probleme si solutii. Aceasta perspectiva este cunoscuta ca fiind perspectiva statica sau logica; modelul comportamental - cuprinde dimensiunea comportamentala a problemei si solutiei. Aceasta perspectiva este cunoscuta de asemenea ca fiind: dinamica, de proces, concurenta sau colaborativa; modelul implementarii cuprinde dimensiunea comportamentala si structurala a realizarii solutiilor, fiind cunoscuta si ca: de dezvoltare sau de componente; modelul de mediu - cuprind dimensiunea structurala si comportamentala a domeniului n care este realizata solutia. Este cunoscuta si ca perspectiva fizica; Se pot defini si alte perspective, n cazul n care este remarcata necesitatea acestora. O orientare arhitecturala este definita printr-o multime de continuturi. O perspectiva arhitecturala este definita prin intermediul unei multimi de elemente dintr-un model care refera o orientare arhitecturala. De exemplu, securitatea poate fi definita ca o orientare arhitecturala. O arhitecturalitate a securitatii va include multime a elementelor modelului care adreseaza securitatea. Fundamental, perspectiva arhitecturala organizeaza cunostintele n concordanta cu ghidurile date de exprimarea idiomurilor necesare utilizarii. Diagrame Diagramele prezinta cunostinte ntr-o forma comunicabila. UML furnizeaza urmatoarele diagrame, organizate n jurul perspectivei arhitecturale cu privire la modelele problemelor si a solutiilor: e perspectiva modelului utilizator - diagrame de scenarii care descriu functionalitatea sistemului e perspectiva modelului structural - clasa de diagrame care descriu structura statica a sistemului - diagrame obiect care descriu structura statica a sistemului la un moment particular de timp. e perspectiva comportamentala - diagrame de secvente care descriu o interactiune de-a lungul elementelor sistemului organizat n secventa temporale - diagrame de colaborare care descriu o interactiune de-a lungul elementelor unui sistem si a relatiilor acestora, organizate n timp si spatiu - diagrame de stare care descriu conditiile de stare si raspunsurile elementelor sistemului - diagrame de activitate care descriu activitatea elementelor sistemului. e perspectiva modelului implementare - diagramele de componente care descriu organizarea elementelor care realizeaza sistemul e perspectiva modelului de mediu

Limbajul de modelare unificat (UML)-

8

diagrame de desfasurare care descriu configuratia elementelor de mediu si maparea elementelor care realizeaza sistemul peste acestea e alte diagrame pot fi definite si utilizate dupa necesitati. Mecanismele de modelare Mecanismele sunt practici pentru abordarea modelarii si a realizarii diagramelor care valideaza creare de modele din ce n ce mai precise si ceea ce este mai important, din ce n ce mai comunicabile. Perspectivele definesc un punct de vedere particular de la care se pot elabora sau citi diagrame. Acestea valideaza asocierea de puncte de vedere clare cu diagrame si sunt utilizate pentru eficientizarea comunicarilor; Dihotomiile definesc modul n care ceva poate fi privit din doua perspective diferite. Acestea valideaza o privire asupra unei entitati din puncte de vedere multiple si sunt utilizate (fiind foarte eficiente n acest scop) la depistarea inconsistentelor dintre modele; Nivelele de abstractizare definesc un nivel particular si stabilesc nivelul de detaliu cu privire la un subiect (problema sau solutie). Acestea permit orientarea spre comunicare si sunt utilizate pentru organizarea tuturor diagramelor care apartin unui singur model ntrun singur corp de cunostinte, coerent; Extensia mecanismelor defineste mijlocul prin care se poate realiza personalizarea si extinderea UML. Aceasta permite UML sa fie flexibil si adaptiv si este utilizat pentru a asigura UML evolueaza, solutie mai buna dect redefinirea necesara pentru descrierea nevoilor de modificare sau a cerintelor. ntr-un proces problema - solutie, cunostintele cu privire la o problema si o solutie sunt captate, organizate n jurul deciziei si descrise utiliznd UML astfel nct pot fi comunicabile si plasate pe diferite nivele.

3. Modelarea cu UMLConceptele folosite n cadrul diagramelor UML se numesc elemente de modelare. Un element de modelare are o semantic, o definiie formal a elementului sau un neles exact a ceea ce reprezint el ntr-un anumit context, i o reprezentare grafic, sau un simbol grafic cu care se reprezint n cadrul diagramelor. Un element poate fi regsit n mai multe tipuri de diagrame i pentru fiecare context exist propriile reguli. n figura 1 sunt prezentate cteva exemple de elemente de modelare mpreun cu modul lor de reprezentare. A modela cu UML nseamn a construi mai multe modele pentru diferitele faze ale dezvoltrii i pentru diverse scopuri. Exist mai multe faze ce trebuie parcurse: faza de analiz - surprinde necesitile sistemului i modeleaz clasele de baz din "lumea real" i colaborrile dintre acestea; faza de design - se detaliaz modelul din faza de analiz i se formuleaz o soluie tehnic lund n considerare caracteristicile mediului n care acesta va fi reprezentat; faza de implementare - modelul este transpus n cod iar apoi compilat n programe; modelul de desfurare - se folosete o descriere care explic modul cum va fi adaptat sistemul arhitecturii fizice concrete. Analiza unei aplicaii implic realizarea mai multor categorii de modele, dintre care cele mai importante sunt:

Modelul de utilizare. realizeaz modelarea problemelor i a soluiilor acestora n maniera n care le percepe utilizatorul final al aplicaiei. Diagram asociat: diagram de cazuri de utilizare


9

Modelul structural: se realizeaz pe baza analizei statice a problemei i descrie proprietile statice ale entitilor care compun domeniul problemei. Diagrame asociate: diagram de module, diagram de clase Modelul comportamental: privete descrierea funcionalitiilor i a succesiunii n timp a aciunilor realizate de entitile domeniului problemei. Diagrame asociate: diagrama (harta) de stri, diagrama de colaborare, diagrama de interaciune Principalele pri ale UML sunt: Vederile (View) - surprind aspecte particulare ale sistemului de modelat. Un view este o abstractizare a sistemului, iar pentru construirea lui se folosete un numr de diagrame. Diagramele - sunt grafuri care descriu coninutul unui view. UML are nou tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului. Elementele de modelare - sunt conceptele folosite n diagrame care au coresponden n programarea orientat-obiect, cum ar fi: clase, obiecte, mesaje i relaii ntre acestea: asocierea, dependena, generalizarea. Un element de modelare poate fi folosit n mai multe diagrame diferite i va avea acelai nteles i acelai mod de reprezentare. Mecanismele generale - permit introducerea de comentarii i alte informaii despre un anumit element. 3.1 View-uri Modelarea unui sistem poate fi o munc foarte dificil. Ideal ar fi ca pentru descrierea sistemului s se foloseasc un singur graf, ns de cele mai multe ori acesta nu poate s surprind toate informaiile necesare descrierii sistemului. Un sistem poate fi descris lund n considerare diferite aspecte: Funcional: este descris structura static i comportamentul dinamic al sistemului; Non-funcional: necesarul de timp pentru dezvoltarea sistemului Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod; Aadar pentru descrierea unui sistem sunt necesare un numr de view-uri, fiecare reprezentnd o proiecie a descrierii intregului sistem i care reflect un anumuit aspect al sau. Fiecare view este descris folosind un numr de diagrame care conin informaii relative la un anumit aspect particular al sistemului. Aceste view-uri se acoper unele pe altele, deci este posibil ca o anumit diagram s fac parte din mai multe view-uri.

Figura 1: View-urile din UML


10

VIEW-UL CAZURILOR DE UTILIZARE (USE-CASE VIEW) - Acest view surprinde funcionalitatea sistemului, aa cum este ea perceput de actorii externi care interacioneaz cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. n componena lui intr diagrame ale cazurilor de utilizare i ocazional, diagrame de activitate. Cei interesai de acest view sunt deopotriv clienii, designerii, dezvoltatorii dar i cei care vor realiza testarea i validarea sistemului.

VIEW-UL LOGIC (LOGIC VIEW) - Spre deosebire de view-ul cazurilor de utilizare, un view logic "privete" nuntrul sistemului i descrie att structura intern a acestuia (clase, obiecte i relaii) ct i colaborrile care apar cnd obiectele trimit unul altuia mesaje pentru a realiza funcionalitatea dorit. Structura static este descris n diagrame de clas, n timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secvent, de colaborare sau de activitate. Prin urmare, cei care sunt interesai de acest tip de vizualizare a sistemului sunt designerii i dezvoltatorii. VIEW-UL COMPONENTELOR (COMPONENT VIEW) - Componentele sunt module de cod de diferite tipuri. n funcie de coninutul lor acestea pot fi: componente care conin cod surs, componente binare sau excutabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem i dependenele ce exist ntre ele, precum i resursele alocate acestora i eventual alte informaii administrative, cum ar fi de exemplu un desfaurtor al muncii de dezvoltare. Este folosit n special de dezvoltatorii sistemului, iar n componena sa intr diagrame ale componentelor. VIEW-UL DE CONCUREN (CONCURENT VIEW) - Sistemul poate fi construit astfel nct s ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncional, este util pentru o gestionare eficient a resurselor, execuii paralele i tratri asincrone ale unor evenimente din sistem, precum i pentru rezolvarea unor probleme legate de comunicarea i sincronizarea theadu-urilor. Cei care sunt interesai de o astfel de vizualizare a sistemului sunt dezvoltatorii i integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secvent, colaborare i activitate) i diagrame de implementare (ale componentelor sau de desfurare). VIEW-UL DE DESFURARE (DEPLOYMENT VIEW) - Desfurarea fizic a sistemului, ce calculatoare i ce device-uri (numite i noduri) vor fi folosite pentru realizarea efectiv a implementrii, cum sunt acestea conectate, precum i ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse n view-ul de desfurare. Aceast tip de vizualizare a sistemului prezint interes sunt dezvoltatori, integratorii de sistem i cei care realizeaz testarea sistemului, iar pentru construirea view-ului este folosit diagrama de desfurare. 3.2 Diagrame n UML sunt nou tipuri de diagrame pe care le vom prezenta pe scurt n cele ce urmeaz. Diagramele UML pot fi mprite n: diagrame pentru modelarea structurii statice i diagrame pentru modelarea comportamentului.


11

1. Diagramele structurale sunt folosite pentru a vizualiza, specifica, construi i documenta aspectele statice ale sistemului. Acestea sunt organizate n jurul grupelor majore de elemente ce pot fi gsite n modelarea unui sistem. Din aceast categorie fac parte: Diagrama claselor (Class Diagram) - prezint structura fizic a claselor identificate n sistem. Clasele reprezint "lucruri" gestionate de sistem. Este cel mai utilizat tip de diagrame n modelarea sistemelor orientate obiect. Diagrama componentelor (Component Diagram) - prezint structura fizic a codului n termenii componentelor de cod. Se folosete pentru a ilustra vederea static de implementare a unui sistem. Diagrama obiectelor (Object Diagram) - este o variant a diagramei claselor care, n locul unei clase, prezint mai multe instane ale ei. Diagrama de stare (State Diagram) - prezint toate strile prin care trece un obiect al clasei, precum i evenimentele care-i cauzeaz modificrile de stare. 2. Diagramele comportamentale sunt folosite pentru a vizualiza, specifica, construi i documenta aspectele dinamice ale unui sistem. Acestea sunt organizate n jurul modalitilor principale de a modela dinamica unui sistem. Din aceast categorie fac parte: Diagrama cazurilor de utilizare (Use Case Diagram) - prezint actorii externi i cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, aa cum este el perceput de utilizatorii lui ?) nu i din interior, precum i conexiunile identificate ntre actori i cazurile de utilizare. Diagrama de secven (Sequence Diagram) - prezint colaborarea dinamic ntre un numr de obiecte, mai precis, secvenele de mesaje trimise ntre acestea, pe msura scurgerii timpului. Diagrama de colaborare (Collaboration Diagram) - surprinde colaborarea dinamic ntre obiecte, ntr-o manier similar cu a diagramei de secven, dar pe lng schimbul de mesaje (numit i interaciune) prezint obiectele i relaiile dintre ele (cteodat referite ca i context). Diagrama de activitate (Activity Diagram) - prezint fluxul secvenelor de activiti i este de obicei folosit pentru a descrie activitile realizate n cadrul unei operaii, folosind dac este cazul decizii i condiii. Diagrama de tranziie - se folosete pentru a ilustra vederea dinamic a unui sistem. Cum lum decizia folosirii unui anumit tip de diagram ? Dac cel mai important aspect este timpul sau secvena de mesaje vom folosi diagrama de secven, dar dac trebuie scos n eviden contextul, vom apela la o diagram de colaborare. Mesajele vor fi reprezentate prin sgei ntre obiectele implicate n mesaj i pot fi nsoite de etichete care specific ordinea n care acestea vor fi transmise. De asemenea, se pot vizualiza condiii, iteraii, valori returnate, precum i obiectele active care se execut concurent cu alte obiecte active. Diagramele sunt grafuri care prezint simboluri ale elementelor de modelare (model element) aranjate astfel nct s ilustreze o anumit parte sau un anumit aspect al sistemului. Un model are de obicei mai multe diagrame de acelai tip. O diagram este o parte a unui view specific, dar exist posibilitatea ca o diagram s fac parte din mai multe view-uri, n funcie de coninutul ei. n UML sunt nou tipuri de diagrame pe care le vom prezenta n cele ce urmeaz.

Limbajul de modelare unificat (UML)Diagrama cazurilor de utilizare (Use Case Diagram)

12

Un caz de utilizare este o descriere a unei funcionaliti (o utilizare specific a sistemului) pe care o ofer sistemul. Diagrama prezint actorii externi i cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, aa cum este el perceput de utilizatorii lui?) nu i din interior, precum i conexiunile identificate ntre actori i cazurile de utilizare. Un exemplu de diagram a cazurilor de utilizare este prezentat n figura 2.

Figura 2: O diagram a cazurilor de utilizare dintr-un sistem de asigurri. Diagrama claselor (Class Diagram) O diagram a claselor prezint structura fizic a claselor identificate n sistem. Clasele reprezint "lucruri" gestionate de sistem; clasele pot fi legate n mai multe moduri: asociate (conectate ntre ele), dependente (o clasa depinde/folosete o alt clas), specializate (o clas este specializarea altei clase) sau mpachetate (grupate mpreun n cadrul unei unitai). Toate aceste relaii se materializeaz n structura intern a claselor n atribute i operaii. Diagrama este considerata statica, in sensul ca este valida in orice moment din ciclul de viata al sistemului. Un exemplu de diagrama a claselor este prezentat in figura 3.

Figura 3: O diagram a claselor pentru un sistem de asigurri.

Limbajul de modelare unificat (UML)Diagrama obiectelor (Object Diagram)

13

Acest tip de diagram este un variant al diagramei claselor care n locul unei clase prezint mai multe instane ale ei. Diagrama obiectelor folosete aproape aceleai notaii ca i diagrama claselor cu dou mici diferene: obiectele sunt scrise subliniat i sunt vizualizate toate instantele relaiei (figura 4). Dei nu este la fel de important ca diagrama claselor, cea o obiectelor este folosit pentru exemplificarea unei diagrame a claselor de complexitate mare, permind vizualizari ale instanelor actuale i a relaiilor exact aa cum sunt ele realizate. Mai poate fi folosit ca o parte a diagramelor de colaborare, n care sunt vizualizate colaborrile dinamice existente n cadrul unui set de obiecte.

Figura 4: O diagram a claselor i o diagram a obiectelor (instanele claselor). Diagrama de stare (State Diagram)

Figura5


14

O stare este de obicei un complement al descrierii unei clase. O diagram de stare prezint toate strile prin care trece un obiect al clasei precum i evenimentele care-i cauzeaz modificrile de stare. Modificarea strii se numete tranziie. Un exemplu de diagram de stare este prezentat n figura 5. Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea care au un numr de stri bine definit iar comportamentul clasei este afectat i modificat de acestea. Diagrama de secven (Sequence Diagram)

O diagram de secven prezint colaborarea dinamic ntre un numr de obiecte (figura 6), mai precis secvenele de mesaje trimise ntre acestea pe msura scurgerii timpului. Obiectele sunt vzute ca linii verticale distribuite pe orizontal, iar timpul este reprezentat pe axa vertical de sus n jos. Mesajele sunt reprezentate prin sgei ntre linile verticale ce corespund obiectelor implicate n mesaj.

Figura 6: Diagrama de secven pentru un server de imprimant Diagrama de colaborare (Collaboration Diagram) Aceast diagram surprinde colaborarea dinamic ntre obiecte, ntr-o manier similar cu a diagramei de secven, dar pe lng schimbul de mesaje (numit i interaciune) prezint obiectele i relaiile dintre ele (cteodat referite ca i context). Cum decidem ce tip de diagram s folosim? Dac cel mai important aspect este timpul sau secvena de mesaje vom folosi diagrama de secven, dar dac trebuie scos n evident contextul, vom apela la o diagram de colaborare. Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor. Mesajele vor fi reprezentate prin sgei ntre obiectele implicate n mesaj i pot fi nsoite de etichete care specific ordinea n care acestea vor fi transmise. De asemenea se pot vizualiza condiii, iteraii, valori returnate, precum i obiectele active care se execut concurent cu alte obiecte active (vezi figura 7).


15

Figura 7: O diagram de colaborare pentru un server de imprimant. Diagrama de activitate (Activity Diagram) O diagram de activitate prezint fluxul secvenelor de activitai, ca n figura 8, i este de obicei folosit pentru a descrie activitaile realizate n cadrul unei operaii, folosind dac este cazul decizii i condiii. Diagrama conine stri de aciune (action states), i mesaje care vor fi trimise sau recepionate ca parte a aciunii realizate.

Figura 8: O diagram de activitate pentru un server de imprimant. Diagrama componentelor (Component Diagram) O diagram a componentelor prezint structura fizic a codului n termenii componentelor de cod, realiznd o mapare de la view-ul logic la view-ul componentelor. O component poate s conin un cod surs sau poate s fie ntr-o forma binar sau executabil. n cadrul diagramei vor fi ilustrate i dependenele dintre componente, ceea ce permite o vizualizare simpl a componentelor care vor fi afectate de modificarea uneia dintre ele.


16

Figura 8: O diagram a componentelor

Diagrama de desfurare (Deployment View) Arhitectura fizic pe care va fi implementat sistemul, calculatoarele, device-urile (referite ca nodurile sistemului), mpreun cu conexiunile dintre ele, vor putea fi prezentate n cadrul unei diagrame de desfaurare. Componentele i obiectele executabile sunt alocate n interiorul nodurilor, ceea ce ne va permite o vizualizare a unitailor care se vor executa pe fiecare nod.

Figura 9: O diagram de desfaurare care prezint structura fizic a sistemului.

Limbajul de modelare unificat (UML) 4. Concluzii

17

n trecut, programatorii dezvoltau programe fr o bun analiz i o bun proiectare a respectivelor programe. Faza de analiz i proiectare a unui sistem informatic trebuie s fie gata nainte de realizarea codului, pentru a obine o atenie mrit din partea diverilor dezvoltatori. Aceste etape au fost ignorate n trecut, dar n prezent orice dezvoltator recunoate importana acestor faze, deoarece s-a dovedit c de acestea depinde producerea de software adecvat i competitiv. Pentru analiza i proiectarea sistemelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling Language). UML nu este un simplu limbaj de modelare orientat obiect, ci n prezent, este limbajul universal standard pentru dezvoltatorii software din toat lumea. UML deine o expresivitate, care ajut la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. n prezent, UML ofer arhitecturi de sisteme ce funcioneaz pe analiza i proiectarea obiectelor cu un limbaj corespunztor pentru specificarea, vizualizarea, construirea i documentarea. Notaiile UML constituie un element esenial al limbajului pentru realizarea propriuzis a modelrii i anume, partea reprezentrii grafice pe care se bazeaz orice limbaj de modelare. Este absolut necesar deci s cunoatem principalele elemente ale unui limbaj de modelare nainte de a iniia proiectarea i dezvoltarea unui sistem, mai ales dac acesta este att de complex ca sistemul informatic cadastral. Vom ncerca, drept preocupare de viitor, s introducem prezentarea sub form de diagrame UML chiar n procesul de prezentare didactic a unor fluxuri de activitate - nu neaprat din domeniul cadastral, deoarece modalitatea aceasta de descriere este mult mai inteligibil i mai fidel, precum i mai uor de asimilat, reinut i reprodus, dezvoltnd totodat i logica celor care o studiaz.

Limbajul de modelare unificat (UML) BIBLIOGRAFIE:

18

1. 2. 3.

4. 5. 6. 7. 8. 9.

Gheorghe Andrei Avram (2002) - Sisteme informationale, Editura Aisteda Badea, A.C. (2004) - Contribuii privind integrarea cadastrului general i a crii funciare, Badea, G., Badea, A.C., Sion, I.G. (2004) - Sisteme Informatice de Eviden Cadastral, Curs postuniversitar de perfecionare, volumul I, modulul A, "Eviden cadastral", Ed. Conspress, Bucureti; Bdard, Y. (1999) - Visual Modeling of Spatial Databases: Towards Spatial PVL and UML, Geomatica, vol. 53, no. 2, pg. 169-186; Brown, A.W. .a. (1994) - Principles of CASE Tool Integration, Oxford University Press, Oxford; Fowler, M.(2000) - UML Distilled, A Brief Guide to the Standard Object Modeling Language, Addison-Wesley; Gheorghie, O., Apetrei, A. (2003) - Ingineria Programrii, Facultatea de Informatic, Universitatea "Al. I. Cuza", Iai; Giurc, A. (2004) - Proiectare n UML, Universitatea din Craiova, Facultatea de Matematic Informatic; Ioni, A.D. (2003) - Modelarea UML n ingineria sistemelor de programe, Ed. BIC ALL, Bucureti, 2003;

Limbajul de modelare unificat (UML)

Documents

Transcript of Limbajul de modelare unificat (UML)